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

[Armedbear-devel] loading Maxima via ASDF
by Robert Dodier 15 May '14

15 May '14

After some flailing around, I managed to figure out how to load Maxima via ASDF + ABCL. For the record, ASDF 3.1.0.103 + ABCL 1.3.1. The problem I reported about ASDF not looking in the right place for the .abcl files might be due to the maxima.asd specifying a place without telling ASDF (?? not sure). By disabling ASDF's output translation stuff, the problem went away. Alternatively, one could nuke the assignment to ASDF:*BINARY-OUTPUT-DIR* in maxima.asd and let ASDF figure out where to put stuff (somewhere below ~/.cache/ common-lisp, it appears). It appears to be necessary now to specify something for ASDF:*CENTRAL-REPOSITORY*. I hadn't found that necessary before. (Last time I tried might have been a couple of years ago.) So with maxima-5.33.0.tar.gz unpacked, this recipe worked for me: (0) cd maxima-5.33.0/src (1) edit maxima.asd to say binary-abcl instead of binary-ecl for ASDF:*BINARY-OUTPUT-DIR*. (Not strictly necessary.) ASDF thens writes stuff into ./binary-abcl. (2) launch ABCL via: java -jar path/to/abcl.jar (3) in ABCL repl: (require 'asdf) (setf asdf:*central-registry* '(*default-pathname-defaults*)) (asdf:disable-output-translations) (asdf:operate 'asdf:load-op :maxima) (4) launch Maxima interpreter: (cl-user::run) Plotting, help, run_testsuite all work as expected; test suite has a few unexpected errors, mostly numerical. FWIW Robert Dodier _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] HEADS-UP: r14694 changes semantics (sometimes) of CL:NIL to Java from JAVA:+NULL+ to JAVA:+FALSE+
by Mark Evenson 15 May '14

15 May '14

With [r14694][], we now convert CL:T and CL:NIL to JAVA:+TRUE+ and JAVA:+FALSE+ respectively when invoking JVM methods through the JAVA package, establishing the "natural" equivalence for boolean truth values. This may break some existing usage in that previously CL:NIL was converted to a Java 'null' reference. Users now need to specify JAVA:+NULL+ explicitly when desiring to pass 'null' Java references as an argument in invoking JVM methods. As far as I can tell from what I can from testing examples of available consumers of the JAVA package, this doesn’t break existing usage, as we have been advising use JAVA:+NULL+ to denote a null reference explicitly since its introduction some three years ago [r13359][]. And until I inspected the underlying JAVA code yesterday, I wasn’t even aware of the conversion of CL:NIL to JAVA:+NULL+. Nevertheless, please speak up if this breaks something for you that you relied upon. Unless I hear otherwise, I am going to back port this change to abcl-1.3.1 as the last change before a release. While strictly speaking from a release engineering perspective, this sort of change should wait until a major revision release, I am planning on using abcl-1.3.1 in production next week with [lsw2][], which sort of relies on this behavior. I beg the ABCL community’s indulgence in this deviation from release engineering best practices, unless somebody speaks up soon that this is a very bad idea. This change implements the requests in [ticket-84][] and [ticket-339][]. [ticket-84]: http://abcl.org/trac/ticket/84> [ticket-339]: http://abcl.org/trac/ticket/339 [r14694]: http://abcl.org/trac/changeset/14694 [r13359]: http://abcl.org/trac/changeset/13359 [lsw2]: https://code.google.com/p/lsw2/ -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] ABCL on iOS via RoboVM?
by John Pallister 07 May '14

07 May '14

Hello list, I was wondering whether anyone has tried to get ABCL running on iOS by means of RoboVM [1]? I see that people have done this with Clojure [2]. Also, can I ask how the Android build target is coming along? I'm weighing up LambdaNative [3] vs. alternatives for Lisp development on iOS and Android. Cheers, John :^P [1] http://www.robovm.org/ [2] https://github.com/oakes/lein-fruit [3] http://www.lambdanative.org/ -- John Pallister john(a)johnp.net john(a)synchromesh.com _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] [CfP] International Lisp Conference 2014, Aug. 14-17, Montreal
by Didier Verna 07 May '14

07 May '14

ILC 2014 - International Lisp Conference "Lisp on the Move" August 14-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users In cooperation with: ACM SIGPLAN http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. We invite high quality submissions in all areas involving Lisp dialects and any other languages in the Lisp family, including, but not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. The conference proceedings will be published in the ACM Digital Library. This year's focus will be directed towards integrated solutions, including mobile computing. We especially invite submissions in the following areas: * Pervasive computing Interoperability Portability Implementation * challenges/tradeoffs for embedded/mobile platforms Language * support for mobile toolkits and frameworks Language support for * distribution Language support for reliability, availability, and * serviceability Mobile IDEs Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation Language integration, * inter-operation and deployment Applications (especially * commercial) Reflection, meta-object protocols, meta-programming * Domain-specific languages Programming paradigms and environments * Efficient parallel and concurrent computation Language support for * managing both manual and automatic GC Theorem proving Scientific * computing Data mining Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May 18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference 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 and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Damir Cavar, Eastern Michigan University, USA Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USA Irène Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Möller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org For more information, see http://www.international-lisp-conference.org -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] symbol-macrolet + nth-value
by James M. Lawrence 06 May '14

06 May '14

Hello, (defun foo () (symbol-macrolet ((x 3)) (symbol-macrolet ((y (nth-value 0 x))) y))) Compiling this with COMPILE (C-c-c in slime) warns about X being undefined, and an unbound X error occurs when FOO is run. (macroexpand-1 '(defun foo () (symbol-macrolet ((x 3)) (symbol-macrolet ((y (nth-value 0 x))) y)))) ;;=> (PROG1 (SYSTEM:%DEFUN 'FOO (SYSTEM:NAMED-LAMBDA FOO NIL (BLOCK FOO (LOCALLY (LOCALLY (NTH-VALUE 0 X))))))) X didn't get expanded. There is no problem when compiling the DEFUN form with COMPILE-FILE (C-c-k). _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Asdf-devel] ASDF 3.1.2 released
by Robert P. Goldman 06 May '14

06 May '14

The release version of ASDF 3.1, version 3.1.2, has finally arrived. It is loaded with bug-fixes, more portability (substantially better support on Windows; several new lisp implementations), better documentation (extensive revisions to the Texinfo manual), and new convenience features such as PACKAGE-INFERRED-SYSTEMs. We urge the maintainers of lisp implementations to move to version 3.1.2 directly, as it is clearly superior to its predecessors. This is especially true if you are currently bundling a pre-release version of ASDF. For a list of changes, see the attached changelog. Special thanks to Dave Cooper and Anton Vodonosov (alphabetically) for testing support. Thanks to all those who have participated in the discussions on ASDF-devel for bug fixes, suggestions, and course corrections. Thanks to Pete Keller for proofreading this announcement; any remaining errors are mine alone. Although he is no longer the lead maintainer, François-René Rideau (Fare), has continued to expend vast amounts of effort on ASDF, and provided invaluable guidance to the code submitted by the rest of us. The latest version of ASDF is available at the project website: http://common-lisp.net/project/asdf/ Robert P. Goldman ASDF maintainer-in-chief _______________________________________________ Asdf-devel mailing list Asdf-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

1 0

[Armedbear-devel] ABCL 1.3.1 testgrid results - no regressions
by Anton Vodonosov 01 May '14

01 May '14

Hi, I have tested ABCL 1.3.1, no regressions comparing to 1.3.0 and 1.2.1: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff23.html http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff24.html _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] Fixing #352 / JSS fails to introspect foo(long) methods
by olof＠macrolet.net 17 Apr '14

17 Apr '14

Hi, I've been trying to improve my idea in [1]. Attached is a slightly different patch, still with the same general idea though. I've added two tests, however I'd still like to do a bit more than that, especially testing the correct resolution of methods, i.e. Java::isMoreSpecialized. My current understanding is that with this patch all possible methods (like for the attached class DummyMethods) are found, but that isMoreSpecialized doesn't actually do what its name implies, namely finding the most specialized method. That is, I'm assuming that JCALL is supposed to use the (exact) same kind of method resolution as Java (if no method signature is given)? Additionally I actually wanted to add DummyMethods for testing from java-tests.lisp, but didn't work out for now. Best regards, Olof [1]: http://abcl.org/trac/ticket/352 _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 2

[Armedbear-devel] PROBE-DIRECTORY borks on wildcard character
by Faré 15 Apr '14

15 Apr '14

EXTENSIONS:PROBE-DIRECTORY fails when the directory name has wildcard characters See: https://bugs.launchpad.net/asdf/+bug/1307571 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Meta is Better. Anything you can do, I can do Meta. — Patrick Logan _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[armedbear-devel] ASDF-JAR vs ASDF3 deployment support
by Erik Huelsmann 04 Apr '13

04 Apr '13

Hi all, Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and their dependencies in JARs. As it turns out, the solution chosen has some problems with correctly packaging ASDs for systems which use the #. reader macro. As an example: bordeaux-threads uses a version.lisp-sexp file to canonically define the version number and the system definition reads that file in a #. form. However, this file isn't packaged because it's not part of the file listing in the system definition. This means asdf can't load the definition after deployment. With the advent of ASDF3, its developers have created infrastructure to combine fasls of a single system and even fasls of a system and all its dependencies into a single large combined FASL. Among others, this new infrastructure does not run into the issue ASDF-JAR is running into. While not completely equivalent to the JAR solution, using this infrastructure would help us a huge step along that way of getting better deployment. My current thinking is that if the single-packed-FASL needs to end up as a jar, we can work on that as a next step. The first step to take would be to create "concatenate fasls" functionality, which would do the following: * Detect all the file entries in all the passed-in fasls * Create a new output zip file with directories for each fasl being packed, populated with the files and directories of that fasl * create a toplevel ._ file which loads the sub-fasls' ._ files Comments? Bye, Erik.

5 8

[armedbear-devel] REMOVE CACHES: r14460 changes FASL entry point name
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi all, Commits between r14456 and r14460 change the FASL entry point name. Everybody tracking trunk will need to blow their caches away. Bye, Erik.

1 0

[armedbear-devel] Patch for ASDF2.26.32 to support concatenated fasls for ABCL
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! In order for these commands to generate a fasl per ASDF system, I had to apply the patch below to ASDF. $ ./abcl CL-USER(1): :ld c:/users/erik/quicklisp/setup CL-USER(2): (ql:quickload :bordeaux-threads) CL-USER(3): (asdf:oos 'asdf:binary-op :bordeax-threads) The commands above work with current trunk (r14460) and produces 2 concatenated fasls in my cache directory: 1 for alexandria and 1 for bordeaux-threads. This patch is required (also attached, to prevent line wrapping): diff --git a/bundle.lisp b/bundle.lisp index 568f894..24fbf90 100644 --- a/bundle.lisp +++ b/bundle.lisp @@ -185,7 +185,7 @@ (or #+ecl (or (equalp type (compile-file-type :type :object)) (equalp type (compile-file-type :type :static-library))) #+mkcl (equalp type (compile-file-type :fasl-p nil)) - #+(or allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) + #+(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) (defgeneric* (trivial-system-p) (component)) diff --git a/uiop/lisp-build.lisp b/uiop/lisp-build.lisp index e2e376d..4b7e819 100644 --- a/uiop/lisp-build.lisp +++ b/uiop/lisp-build.lisp @@ -669,11 +669,12 @@ it will filter them appropriately." ;;; Links FASLs together (with-upgradability () (defun combine-fasls (inputs output) - #-(or allegro clisp clozure cmu lispworks sbcl scl xcl) + #-(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (error "~A does not support ~S~%inputs ~S~%output ~S" (implementation-type) 'combine-fasls inputs output) #+clozure (ccl:fasl-concatenate output inputs :if-exists :supersede) #+(or allegro clisp cmu sbcl scl xcl) (concatenate-files inputs output) + #+abcl (sys:concatenate-fasls inputs output) #+lispworks (let (fasls) (unwind-protect

1 0

[armedbear-devel] Support for concatenated fasls
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF: Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip. My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._". How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation? Bye, Erik.

2 2

[armedbear-devel] bug in format ~f
by Carlos Ungil 03 Apr '13

03 Apr '13

Hello, comparing output from different implementations I've found the following (minor) bug: > (format t "~,2f" 0.999) 1.0 ;; should be 1.00 I think there is a problem here as well: > (format t "~5f" 0.00000001) .0000 ;; should print " 0.0" Only SBCL gives the output I would expect, most implementations print ".0000" as ABCL does. From the HyperSpec 22.3.3.1: "If the parameter d is omitted, then there is no constraint on the number of digits to appear after the decimal point. A value is chosen for d in such a way that as many digits as possible may be printed subject to the width constraint imposed by the parameter w and the constraint that ___no trailing zero digits may appear in the fraction, except that if the fraction to be printed is zero, then a single zero digit should appear after the decimal point___ if permitted by the width constraint." This problem appears only when the value is close to zero, otherwise the output is fine: > (format t "~5f" 1.00000001) 1.0 ;; OK I guess those zero digits are not considered trailing because there is no non-zero digit before but I think the specification still requires the fraction to be printed with a single zero digit after the decimal point. Regards, Carlos Ungil

2 1

[armedbear-devel] Other findings (was Re: Questions about r14452 (Fix cl-cont))
by Erik Huelsmann 02 Apr '13

02 Apr '13

> Well, to some extent I can see your problem. Indeed there seem to be no > slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The > layoutFuncallableStandardClass is what confused me, but that's indeed the > layout of the metaclass. > > So, you're correct that the fix works by accident. The solution should be > to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. > That slot can contain the name of the object (ie function) for which the > item is defined. In that case, we should probably remove the direct slot > MOP::NAME on the standard generic function, since it's already defined on > the superclass if we decide to do that. > > While studying this problem using DESCRIBE, it seems our current implementation dispatches (DESCRIBE (MAKE-INSTANCE 'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the STANDARD-OBJECT way... Yet more to investigate... Bye, Erik.

2 2

Re: [armedbear-devel] Questions about r14452 (Fix cl-cont)
by Rudolf Schlatte 02 Apr '13

02 Apr '13

What makes me suspicious is the output of (describe (make-instance 'funcallable-standard-object)) vs (describe (make-instance 'standard-generic-function)) . There's a layout called layoutFuncallableStandardClass, defined in StandardClass.java, which has NAME as first slot, but that's for class objects with metaclass funcallable-standard-class, not for instances of these classes. I'll think a bit in the next days and try to either resolve my doubts or come up with another fix for the problem. Maybe I'm simply confused; wouldn't be the first time. :) Rudi On Apr 2, 2013, at 19:52, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi Rudi, > > Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear? > > Bye, > > Erik. > > sent from my phone > > On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: > Hi, > > I suspect that the changes in commit r14452 only work by accident. > > The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since > (class-slots (find-class 'funcallable-standard-object)) > returns NIL, these assumptions hold only when the objects are in fact generic functions. > > Amusingly, > (function-lambda-expression (make-instance 'funcallable-standard-object)) > runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though > (typep (make-instance 'funcallable-standard-object) 'function) => T > so I can't trigger the array-out-of-bounds error right now. > > Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. > > Cheers, > > Rudi >

2 2

Re: [armedbear-devel] Questions about r14452 (Fix cl-cont)
by Erik Huelsmann 02 Apr '13

02 Apr '13

Forgot to mention: Pre 14452 it was enough to just quickload cl-cont to trigger the bug. Bye, Erik sent from my phone On Apr 2, 2013 7:52 PM, "Erik Huelsmann" <ehuels(a)gmail.com> wrote: > Hi Rudi, > > Basically the expectation we violated was the fact that %set-lambda-name > didn't want to take a funcallable instance as its function argument. The > commit changed that and used the first slot of the funcallable instance > class layout (called NAME) to store the name. I guess we forget to finalize > the class somewhere, so the spots don't appear? > > Bye, > > Erik. > > sent from my phone > On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: > >> Hi, >> >> I suspect that the changes in commit r14452 only work by accident. >> >> The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs >> FuncallableStandardObject are no problem, since the latter simply isn't >> used anywhere. But the new methods getName() and setName() assume that a) >> the FuncallableStandardObject instance has at least one slot, and b) that >> slot holds a name. Since >> (class-slots (find-class 'funcallable-standard-object)) >> returns NIL, these assumptions hold only when the objects are in fact >> generic functions. >> >> Amusingly, >> (function-lambda-expression (make-instance >> 'funcallable-standard-object)) >> runs into the type error on line 2666 of Primitives.lisp ("The value >> #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even >> though >> (typep (make-instance 'funcallable-standard-object) 'function) => T >> so I can't trigger the array-out-of-bounds error right now. >> >> Could I have a recipe for triggering the bug? I'd like to see how >> cl-cont uses funcallable-standard-objects, and what expectations we >> violate. I believe I can fix this properly. >> >> Cheers, >> >> Rudi >> >>

1 0

[armedbear-devel] Fwd: Re: Questions about r14452 (Fix cl-cont)
by Erik Huelsmann 02 Apr '13

02 Apr '13

sent from my phone ---------- Forwarded message ---------- From: ehuels(a)gmail.com Date: Apr 2, 2013 7:51 PM Subject: Re: Questions about r14452 (Fix cl-cont) To: Rudolf Schlatte <rudi(a)constantly.at> Cc: Hi Rudi, Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear? Bye, Erik. sent from my phone On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: Hi, I suspect that the changes in commit r14452 only work by accident. The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since (class-slots (find-class 'funcallable-standard-object)) returns NIL, these assumptions hold only when the objects are in fact generic functions. Amusingly, (function-lambda-expression (make-instance 'funcallable-standard-object)) runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though (typep (make-instance 'funcallable-standard-object) 'function) => T so I can't trigger the array-out-of-bounds error right now. Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. Cheers, Rudi

1 0

[armedbear-devel] Questions about r14452 (Fix cl-cont)
by Rudolf Schlatte 02 Apr '13

02 Apr '13

Hi, I suspect that the changes in commit r14452 only work by accident. The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since (class-slots (find-class 'funcallable-standard-object)) returns NIL, these assumptions hold only when the objects are in fact generic functions. Amusingly, (function-lambda-expression (make-instance 'funcallable-standard-object)) runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though (typep (make-instance 'funcallable-standard-object) 'function) => T so I can't trigger the array-out-of-bounds error right now. Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. Cheers, Rudi

1 0

[armedbear-devel] Using ASDF/BUNDLE for ABCL
by Erik Huelsmann 01 Apr '13

01 Apr '13

Hi, Some time ago Mark Evenson created ASDF-JAR on ABCL. It has some issues packaging ASD files which uses #. syntax to read e.g. version files (version.lisp-sexp) such as bordeaux-threads does. We know ECL started hooking into the ASDF/BUNDLE machinery for ASDF to overcome problems like these. Could you help me/us out and explain how we can plug ABCL into the same machinery? From what I've seen, it's most efficient if the resulting code be committed to ASDF. That's fine by me. At this point, I'd just be happy with an explanation on how to do the hooking up: the new ASDF/BUNDLE functionality doesn't seem to be documented in the manual yet. Thanks for any help you may be able to provide! Bye, Erik.

2 3

[armedbear-devel] How to .... generate abcl-diff9.html?
by Erik Huelsmann 30 Mar '13

30 Mar '13

Hi Anton, The test run has completed. How do I generate a new difference report? Bye, Erik.

2 1

[armedbear-devel] test results for 1.2.0-dev
by Anton Vodonosov 29 Mar '13

29 Mar '13

Hello. Got the test results from Erik's machine few days ago, but only now have time to report them to the mailing list. Comparison of 1.1.1 and 1.2.0-dev on quicklisp 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff3.html It doesn't present big difference as I hoped, because closer-mop now compiles on any version of ABCL, including 1.1.1. Maybe runtime behavior will be different, but we have no test suites which highlight this difference. Note some regressions: uiop, metacopy-with-contextl, xcvb-bridge. I haven't analyzed what is the cause. Probably something ASDF-related. To give you sense of ABCL progress, here is the report comparing ABCL 1.1.1 on two quicklisps: 2013-02-17 and 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff4.html As you see, much more libraries compile OK in new quicklisp. Note, these two quicklisps were tested on different machines, and the later quicklisp was tested with absence of gcc. This explains failure of cl-gss for example, which can be ignored. Pay attention to some CRASH results in new quicklisp. These crashes reproduce in 1.2.0-dev too and are caused by various errors in ABCL (like index out of bounds, assertion failed). Command line to reproduce it at the cl-test-grid.cloud.efficito.com machine, as user testgrid: rm -r .cache/common-lisp/ java -XX:MaxPermSize=1024m -jar /home/testgrid/lisps/abcl/dist/abcl.jar --noinit --nosystem --batch --eval '(require :abcl-contrib)' --load /home/testgrid/quicklisp/setup.lisp --eval '(ql:quickload :cl-l10n)' > log 2>&1 Finally, here is the load failures report for 1.2.0-dev: http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.h… Recall, that the default sorting in this report tries to present on top the libraries fixing which will give bigger "outcome". More detailed explanation of the report columns is here: https://github.com/cl-test-grid/cl-test-grid/tree/master/reporting#combinin… As you see, there are several directions to dig further, depending on what you are more interested to start with. Let me know what other reports you want to see, or what configurations to test, or how to reproduce certain errors. Best regards, - Anton

3 17

[armedbear-devel] Fwd: cl-l10n: GETENV on ABCL
by Erik Huelsmann 26 Mar '13

26 Mar '13

---------- Forwarded message ---------- From: Attila Lendvai <attila.lendvai(a)gmail.com> Date: Tue, Mar 26, 2013 at 6:28 AM Subject: Re: cl-l10n: GETENV on ABCL To: Erik Huelsmann <ehuels(a)gmail.com> Cc: Armed Bear <armedbear-devel(a)common-lisp.net> hi Erik, > cl-l10n seems to lack a GETENV for ABCL. > Could you use the the function > EXT:GETENV for it? sure, pushed. thanks! -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39

1 0

[armedbear-devel] Bordeaux-threads test hangs
by Erik Huelsmann 25 Mar '13

25 Mar '13

>From a mail by Stellian Ionescu: From: Stelian Ionescu <sionescu(a)cddr.org> To: armedbear-devel(a)common-lisp.net Cc: Date: Sat, 23 Mar 2013 01:07:04 +0000 (UTC) Subject: Bordeaux-threads test hangs The B-T test suite hangs on test "condition-variable". If I do a ^C ABCL exits, so I'm not sure how to debug it. CL-USER(1): (lisp-implementation-version) "1.1.1" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02" "amd64-Linux-3.7.10-10-default"

4 5

[armedbear-devel] cl-l10n: GETENV on ABCL
by Erik Huelsmann 24 Mar '13

24 Mar '13

Hi Attila, cl-l10n wants to use GETENV. Now that ABCL seems to support closer-mop rather well, we're testing many more libraries to see if they're loading correctly on ABCL. cl-l10n seems to lack a GETENV for ABCL. Could you use the the function EXT:GETENV for it? Example: (ext:getenv "PATH") --> "some path string" Or NIL if no env var by the given name exists. Thanks in advance! Bye, Erik.

1 0

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

24 Mar '13

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

6 14

[armedbear-devel] preparing to test ABCL trunk
by Anton Vodonosov 19 Mar '13

19 Mar '13

Today Erik configured for me a VM on his server, where I can run cl-test-grid tests. We were trying the recent ABCL trunk (1.2.0-dev-svn-14436) on the very very recent quicklisp 2013-03-12, which includes long awaited releases for closer-mop and cffi with ABCL patches. Some notes I collected: 1. New CFFI tries to (require :jss) and fails, because (require :abcl-contrib) hasn't been done. If we do (require :abcl-contrib) then CFFI loads. 2. But when we test actual work, for example by doing (ql:quickload :drakma) (drakma:http-request "https://google.com/") it fails with strange error "UNDEFINED-FUNCTION is called". On SBCL these calls work. 3. (ql:quickload "cl-l10n") fails with ArrayIndexOutOfBounds - may be an ABCL bug. Aside from this, closer-mop seems working (at leas compilation of dependent library "access" doesn't fail anymore). Mark, If you want to quickly reproduce the above problems, you can access the server at cl-test-grid.cloud.efficito.com. Username - testgrid. Erik have added your ssh public key from common-lisp.net to that server. To start ABCL you can use rlwrap java -jar ~/lisps/abcl/dist/abcl.jar (ql:quickload :cl-l10n) => ERROR: java.lang.ArrayIndexOutOfBoundsException: 0 Before starting cl-test-grid tests, I would like to understand, should cl-test-grid always pass --eval "(require :abcl-contrib)" parameter to ABCL when starting it to run a test? Previously cl-test-grid only tested pure ABCL, without contribs. Feedback on this question is very welcome. Best regards, - Anton

3 4

[armedbear-devel] Gray streams aren't streams
by James M. Lawrence 12 Mar '13

12 Mar '13

...they're just grays :) (require :gray-streams) (subtypep 'gray-streams:fundamental-stream 'stream) ;; => NIL, T This doesn't matter for flexi-streams and other libs, but cl-store has a few DECLAREs. I don't know exactly when a type declaration is an assertion in ABCL, but at least it is for a stream with nonzero safety. Best, lmj

3 3

[armedbear-devel] Tests broken?
by Rudolf Schlatte 06 Mar '13

06 Mar '13

Hi, Seems our tests are currently broken - e.g., the (asdf:operate 'asdf:load-op :abcl) form on line 994 of build.xml fails for me. Does this ring a bell for anyone? Rudi

2 2

[armedbear-devel] ASDF 2.32 released
by Faré 06 Mar '13

06 Mar '13

Dear ABCL hackers, ASDF 2.32 was released in time for inclusion in the upcoming CCL 1.9. Once again, we invite all implementation vendors and distributors to upgrade the version of ASDF included in their releases. Yes, I know, that's a lot of releases in a bit more than a month. But it was also a lot of development, and a lot of adjustment to reality after that development was first released. We will keep fixing bugs and improve ASDF based on our growing internal test suite and results from Anton Vodonosov's cl-test-grid. This is still a pre-release for ASDF3. Here are the changes, since previous release 2.31, and since previous public announcement for 2.30. >From 2.31 to 2.32: * deferred-warning checks are now disabled by default, to enhance backward compatibility with ASDF 2.26 and earlier. In the future, we will enable them by default, but not until we implement a smoother transition plan. Also, CCL-specific fixes to deferred-warning support. * UIOP is the new official name for ASDF-DRIVER. "Utilities for Implementation- and OS- Portability". Old names remain as package and system nicknames: ASDF/DRIVER ASDF-DRIVER ASDF-UTILS * require-system so systems may depend on implementation-provided modules. * auto-upgrade attempt in operate *before* the implicit find-system. * class specification for components can now be a string to be read as a symbol. * feature conditional dependencies are now debugged and tested: :depends-on ("some-system" (:feature :foo "other-system)) we only recommend them for dependencies between systems; within systems, we recommend you use feature-conditional components with :if-feature :foo and we only provide limited support for the deprecated legacy way of using feature-conditionals with a module having :if-component-dep-fails :ignore while its components specify things like: :in-order-to ((compile-op (feature :foo))) * read-from-file for :version specification is made more useful by using the ASDF-USER package rather than CL (into which interning is forbidden) to read the files. Changes from 2.30 to 2.31: * *default-encoding* is now UTF-8. As tested with cl-test-grid, This is a boon for most programs, that will compile in a more predictable way in a wider range of settings. A handful of unmaintained outliers still need to be fixed. * Downgrade is now explicitly avoided. ASDF will issue a warning if your system is misconfigured in a way that specifies downgrade, but will then ignore the specified ASDF downgrade. * version specifications, when invalid, will lead only to a warning for now; a future ASDF3 may restore the behavior of ASDF 2.27, that raises an errors when there is a bad :version specification, but for now, backward compatibility prevails. * ECL support received several bug fixes. * precompiled-system support was notably fixed, enabling single-fasl deployment of SBCL contribs. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is, jam to-morrow and jam yesterday, but never jam today. — Lewis Carroll

2 1

[armedbear-devel] [Extended Deadline] European Lisp Symposium 2013 - Madrid - June 1-4
by Didier Verna 05 Mar '13

05 Mar '13

;; ______ _ _____ _ __ ____ ;; | ____| | | / ____| ( ) /_ | |___ \ ;; | |__ | | | (___ |/ | | __) | ;; | __| | | \___ \ | | |__ < ;; | |____ | |____ ____) | | | ___) | ;; |______| |______| |_____/ |_| |____/ ;; ;; European Lisp Symposium 2013 - ELS'13 ;; Madrid, Spain ;; ;; June 1-4, 2013 ;; ;; http://els2013.european-lisp-symposium.org/ ** DEADLINE EXTENSION: March 17th ** 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 and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2013 European Lisp Symposium is on the use of these languages with respect to the current grand challenges: big tables, open data, semantic web, network programming, discovery, robustness, runtime failures, etc. The European Lisp Symposium 2013 solicits the submission of papers with these specific themes in mind, alongside the more traditional tracks which have appeared in the past editions. 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 and http://www.acm.org/about/class/1998. Invited speakers: Florian Loitsch, Google: Dart, why you should care. Gérard Assayag, Ircam: Lisp and Music Research. Important dates: March, 17th 2013: submission deadline ** EXTENDED ** April, 5th 2013: acceptance results June, 1-4 2013: symposium Program Commitee: Pascal Costanza, Intel, Belgium Ludovic Courtes, INRIA, France Theo D'Hondt, Vrije Universiteit Brussel, Belgium Florian Loitsch, Google, Denmark Christian Queinnec, UPMC, France Kurt Noermark, Aalborg University, Denmark Olin Shivers, Northeastern University, USA Manuel Serrano, INRIA, France Didier Verna, EPITA, France Chair: Juan Jose Garcia-Ripoll, local organizer Christian Queinnec, PC co-chair Manuel Serrano, PC co-chair -- 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] Fwd: variable-information?
by Erik Huelsmann 03 Mar '13

03 Mar '13

---------- Forwarded message ---------- From: James M. Lawrence <llmjjmll(a)gmail.com> Date: Sat, Mar 2, 2013 at 5:21 PM Subject: Re: [armedbear-devel] variable-information? To: Erik Huelsmann <ehuels(a)gmail.com> On Sat, Mar 2, 2013 at 10:38 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi James, > > Are you in a macro expansion environment? If that's the case, then we could > quite easily make that available, I'm sure. > > Could you provide a bit more detail on what your usecase is? (I'm not > familiar with cltl2, I'm affraid) Hi, Yes by environment I mean the &environment parameter to defmacro. The distributed version of lparallel uses variable-information to create closures which are executed on remote machines. Since at least four implementations offer variable-information (SBCL, CCL, LispWorks, Allegro), this technique amounts to a somewhat portable way to serialize closures. [Did you mean to respond to the list?] Regards, lmj

1 0

[armedbear-devel] variable-information?
by James M. Lawrence 02 Mar '13

02 Mar '13

Is there something akin to variable-information in CLTL2? For a given environment I would like to know if a symbol is a lexical variable or a symbol macrolet.

2 1

[armedbear-devel] Package-local nicknames landed
by Rudolf Schlatte 01 Mar '13

01 Mar '13

Hi, I just committed support for package-local nicknames in abcl. This follows the lead of sbcl and lets you introduce short, meaningful nicknames ("XML" for "COM.WHATEVER.FOO.XML-PARSER") in your own packages without fear of package (nick)name collisions. Here's the example from Nikodemus' documentation: (defpackage :bar (:intern "X")) (defpackage :foo (:intern "X")) (defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar))) (find-symbol "X" :foo) ; => FOO::X (find-symbol "X" :bar) ; => BAR::X (let ((*package* (find-package :quux))) (find-symbol "X" :foo)) ; => BAR::X (let ((*package* (find-package :quux))) (find-symbol "X" :bar)) ; => FOO::X This puts :package-local-nicknames on *features*; I had to increase the fasl version since %defpackage got a new parameter. Cheers, Rudi

2 1

[armedbear-devel] strange interaction between ql:quickload and ABCL
by Anton Vodonosov 28 Feb '13

28 Feb '13

Hello. I have very strange behaviour of ql:quickload that I observer only on ABCL. It happens when I run (ql:quickload :modf). Precondition: the system :modf is NOT installed into quicklisp. > java -jar abcl.jar --noinit --nosystem Armed Bear Common Lisp 1.1.0 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.945 seconds. Startup completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "C:\\Users\\anton\\quicklisp\\setup.lisp") T CL-USER(2): (ql:quickload :modf) Error loading C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 (offset 1649) #<THREAD "interpreter" {40773F4B}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system closer-mop from pathname C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128 -darcs/closer-mop.asd: Unrecognized keyword argument ("closer-mop-packages" "closer-mop-shared") Restarts: 0: REINITIALIZE-SOURCE-REGISTRY-AND-RETRY Retry finding system closer-mop after reinitializing the source-registry. 1: ABORT Give up on "modf" 2: TOP-LEVEL Return to top level. [1] ASDF0(3): As you see it is trying to load closer-mop. Why? If :modf ASDF is not available, quicklisp should not load anything other systems yet. Moreover, modf.asd has :depends-on (:alexandria #-abcl :closer-mop :iterate) So on ABCL it does not depend on closer-mop. I got backtrace using this command: [1] ASDF0(3): (with-open-file (stream "C:\\Users\\anton\\unpacked\\abcl\\abcl-bin-1.1.0\\backtrace.txt" :direction :output :if-exists :supersede :if-does-not-exist :create) (let ((*debug-io* stream)) (top-level::backtrace-command "10000"))) The resulting file is here: https://dl.dropbox.com/u/5708042/backtrace.txt. @abcl dvelopers: this backtrace seem to contain not only the current invocation stack, but also previous calls, already finished. For example the (LOAD "C:\\Users\\anton\\quicklisp\\setup.lisp") at the very bottom of the file. Do I retrieve backtrace incorrectly? Back to the ql:quickload problem. I know that if I install :modf with CCL, this problem doesn't happen anymore, and ABCL can load it. Zach, how it works? Best regards, - Anton

3 5

[armedbear-devel] encoding issues with ABCL
by Faré 26 Feb '13

26 Feb '13

Dear ABCL developers, it looks like ABCL is not doing the Right Thing with respect to LOAD's :EXTERNAL-FORMAT argument, instead reading everything with some dubious default from the environment. Can you fix it? For instance, in Robert Golman's test below, the file is read as MacRoman. Please check COMPILE-FILE too in case it has the same bug. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Men have a much better time of it than women; for one thing they marry later; for another thing they die earlier. — H.L. Mencken ---------- Forwarded message ---------- From: Robert Goldman <rpgoldman(a)sift.info> Date: Mon, Feb 25, 2013 at 4:15 PM Subject: Re: [asdf-devel] Test results on Mac OSX To: Faré <fahree(a)gmail.com> Cc: ASDF-devel <asdf-devel(a)common-lisp.net> On 2/25/13 Feb 25 -10:34 AM, Faré wrote: >> But when I look for "should be" in my test output file, it is many lines >> away from the failure message. >> > That's autoloading for you. > > Can you trace LOAD* COMPILE-FILE* and/or COMPILE-FILE LOAD > and check that indeed :EXTERNAL-FORMAT :UTF-8 is used? > > If it isn't, then it's a bug in our code or test > (Note: considering the portable nature of the code, > and the fact that it works for me, that is unlikely.) > > If it is, then it's time to file a bug against ABCL. > (Note: considering that I already had to disable most of the test > for ABCL, that is very likely.) > > rlwrap abcl > (load "test/script-support.lisp") (da) (la) (trace load compile-file > load* compile-file*) (load "test/test-encodings.script") Done. I'm afraid the results are Greek to me. Or would be if I could get ABCL to print non-ASCII! ;-) ASDF-TEST(7): (load "test-encodings.script") 0: (LOAD "test-encodings.script") ; Loading /Users/rpg/lisp/asdf/test/test-encodings.script ... Test TEST-ENCODING-EXPLICIT-U8: should be UTF-8 ; Registering #<ASDF/SYSTEM:SYSTEM "test-encoding-explicit-u8"> 1: (ASDF/LISP-BUILD:LOAD* #P"/Users/rpg/lisp/asdf/test/lambda.lisp" :EXTERNAL-FORMAT :UTF-8) 2: (LOAD #P"/Users/rpg/lisp/asdf/test/lambda.lisp" :EXTERNAL-FORMAT :UTF-8) ; Loading /Users/rpg/lisp/asdf/test/lambda.lisp ... ; Loaded /Users/rpg/lisp/asdf/test/lambda.lisp (0.0020 seconds) 2: LOAD returned T 1: LOAD* returned T Error loading /Users/rpg/lisp/asdf/test/test-encodings.script at line 43 (offset 1675) #<THREAD "interpreter" {9C2DF08}>: Debugger invoked on condition of type SIMPLE-ERROR On sub-test Encoding test EXPLICIT-U8. These two expressions fail comparison with EQUAL: (ASDF-TEST::STRING-CHAR-CODES "λ") evaluates to (338 170) (ASDF-TEST::EXPECTED-CHAR-CODES (QUOTE :UTF-8)) evaluates to (955) Best, r

2 5

Re: [armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Mark Evenson 25 Feb '13

25 Feb '13

JDK 7 before 1.7.0_04 had some funkiness with loading things, which I never fully investigated. Please try to update to 1.7.0_15 to see if you have the same problems. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email? On Feb 23, 2013, at 8:39 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: > Thanks in advanced, Mark. Now it works for some symbols (e.g. DISASSEMBLE). > > But, every time I performed this on all symbols, it threw exceptions and crashed. > > D:\mefcl-0.2\abcl>java -jar dist\abcl.jar org.armedbear.lisp.Main --load "mefcl-init.lisp" > Armed Bear Common Lisp 1.1.1 > Java 1.7.0_02 Oracle Corporation > Java HotSpot(TM) Client VM > Low-level initialization completed in 0.305 seconds. > Startup completed in 4.078 seconds. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. > Unable to autoload CLASS-DIRECT-SLOTS > Exception in thread "interpreter" org.armedbear.lisp.IntegrityError > at org.armedbear.lisp.Autoload.load(Autoload.java:156) > at org.armedbear.lisp.Autoload$pf_resolve.execute(Autoload.java:339) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:553) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_when.execute(Primitives.java:844) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:154) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:824) > at org.armedbear.lisp.Primitives$sf_tagbody.execute(Primitives.java:3684) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Primitives$pf_mapc.execute(Primitives.java:2961) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:553) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.SpecialOperators._flet(SpecialOperators.java:362) > at org.armedbear.lisp.SpecialOperators$sf_flet.execute(SpecialOperators.java:290) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Primitives$pf_mapc.execute(Primitives.java:2961) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.SpecialOperators._flet(SpecialOperators.java:362) > at org.armedbear.lisp.SpecialOperators$sf_flet.execute(SpecialOperators.java:290) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.eval(Lisp.java:511) > at org.armedbear.lisp.Lisp.eval(Lisp.java:516) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > 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:508) > at org.armedbear.lisp.Load.loadStream(Load.java:606) > at org.armedbear.lisp.Load.loadFileFromStream(Load.java:574) > at org.armedbear.lisp.Load.load(Load.java:206) > at org.armedbear.lisp.Load.load(Load.java:128) > at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:333) > at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) > at org.armedbear.lisp.Main$1.run(Main.java:46) > at java.lang.Thread.run(Thread.java:722) > > When I loaded `mefcl-init.lisp'(just the code I wrote before to change the source location) after the REPL started, it crashed without stack trace printed. > > D:\mefcl-0.2\abcl>java -jar dist\abcl.jar org.armedbear.lisp.Main > Armed Bear Common Lisp 1.1.1 > Java 1.7.0_02 Oracle Corporation > Java HotSpot(TM) Client VM > Low-level initialization completed in 0.309 seconds. > Startup completed in 4.086 seconds. > Type ":help" for a list of available commands. > CL-USER(1): (load "mefcl-init.lisp") > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. > Unable to autoload CLASS-DIRECT-SLOTS > > So I tried to restart ABCL and resolve CLASS-DIRECT-SLOTS manually. > CL-USER(1): (autoload 'class-direct-slots) > T > CL-USER(2): (resolve 'class-direct-slots) > #<THREAD "interpreter" {EF89C6}>: Debugger invoked on condition of type ERROR > Failed to find loadable system file 'class-direct-slots' in boot classpath. > Restarts: > 0: TOP-LEVEL Return to top level. > > Did I miss something ? Or say, how to solve this problem ? > > > Best regards, > Xiaofeng Yang > > > 2013/2/23 Mark Evenson <evenson(a)panix.com> >> Congratulations! You've met the autoloader, now level up... >> >> In order to reduce initial system boot times (and also to partially optimize for booting over the network), not all functions corresponding to symbols in the base ABCL system are loaded initially. Instead, the symbol function slot contains a stub which when first executed as a function loads the necessary code, which as a side effect also populates the symbol plist. >> >> Users of the implementation may currently interact with this mechanism meaningfullly through the EXT:AUTOLOADP and EXT:RESOLVE functions, which tell you if a symbol needs to be autoloaded and to resolve it, respectively. >> >> Using these functions we may define >> >> (defun maybe-resolve-symbol-plist (symbol) >> (when (autoloadp symbol) >> (resolve symbol)) >> (symbol-plist symbol)) >> >> which you can then use in your code to change the source locations. >> >> yers, >> Mark >> >> -- >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad idea? >> A: Top-posting. >> Q: What is the most annoying thing in email? >> >> On Feb 23, 2013, at 7:25 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: >> >>> Thanks. >>> >>> More details, I found that after the REPL started: >>> ; SLIME 2011-10-19 >>> CL-USER> (symbol-plist 'disassemble) >>> NIL >>> CL-USER> (disassemble 'disassemble) >>> ; Compiled from "disassemble.lisp" >>> ... very long output >>> NIL >>> CL-USER> (symbol-plist 'disassemble) >>> (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/disassemble.lisp" . 1693)) >>> >>> After I called DISASSEMBLE, the result of (symbol-plist 'disassemble) was not NIL. How can I make the result of the first (symbol-plist 'disassemble) no NIL? >>> >>> >>> >>> Best regards, >>> Xiaofeng Yang >>> >>> >>> 2013/2/23 Mark Evenson <evenson(a)panix.com> >>>> On 2/22/13 4:01 PM, Xiaofeng Yang wrote: >>>> > Hi, all >>>> > >>>> > I built ABCL 1.1.1 using Ant. After I built it, I found that the source >>>> > locations of all the symbols are absolute path. For exmaple: >>>> > [1] CL-USER(1): (symbol-plist 'defun) >>>> > (SYSTEM::%SOURCE >>>> > (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) >>>> > PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) >>>> > >>>> > I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS >>>> > "sys") by myself, and even deleting system.lisp from the jar. But the >>>> > source location didn't change. >>>> > >>>> > How can I build ABCL 1.1.1 without recording the absolute path of the >>>> > source ? Or, making the source location changable so that I can locate >>>> > it even if I change the path of the source code ? I think I can do it >>>> > manually by i.g. >>>> > (dolist (pkg (list-all-packages)) >>>> > (do-symbols (sym pkg) >>>> > if there exists system::%source in symbol-plist, replace it)). >>>> > Is there any other way to do this ? >>>> >>>> Currently, there is no way of building to not recording the physical >>>> pathname, but there should be. The values stored in the symbol plists >>>> should use the SYS:SRC logical pathname. I've recorded this as ticket >>>> [#301][]. >>>> >>>> >>>> [#301]: http://trac.common-lisp.net/armedbear/ticket/301 >>>> >>>> -- >>>> >>>> "A screaming comes across the sky. It has happened before, but there is >>>> nothing to compare it to now." >

2 2

[armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Xiaofeng Yang 23 Feb '13

23 Feb '13

Hi, all I built ABCL 1.1.1 using Ant. After I built it, I found that the source locations of all the symbols are absolute path. For exmaple: [1] CL-USER(1): (symbol-plist 'defun) (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS "sys") by myself, and even deleting system.lisp from the jar. But the source location didn't change. How can I build ABCL 1.1.1 without recording the absolute path of the source ? Or, making the source location changable so that I can locate it even if I change the path of the source code ? I think I can do it manually by i.g. (dolist (pkg (list-all-packages)) (do-symbols (sym pkg) if there exists system::%source in symbol-plist, replace it)). Is there any other way to do this ? Thanks Best regards, Xiaofeng Yang

3 3

Re: [armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Mark Evenson 23 Feb '13

23 Feb '13

Congratulations! You've met the autoloader, now level up... In order to reduce initial system boot times (and also to partially optimize for booting over the network), not all functions corresponding to symbols in the base ABCL system are loaded initially. Instead, the symbol function slot contains a stub which when first executed as a function loads the necessary code, which as a side effect also populates the symbol plist. Users of the implementation may currently interact with this mechanism meaningfullly through the EXT:AUTOLOADP and EXT:RESOLVE functions, which tell you if a symbol needs to be autoloaded and to resolve it, respectively. Using these functions we may define (defun maybe-resolve-symbol-plist (symbol) (when (autoloadp symbol) (resolve symbol)) (symbol-plist symbol)) which you can then use in your code to change the source locations. yers, Mark -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email? On Feb 23, 2013, at 7:25 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: > Thanks. > > More details, I found that after the REPL started: > ; SLIME 2011-10-19 > CL-USER> (symbol-plist 'disassemble) > NIL > CL-USER> (disassemble 'disassemble) > ; Compiled from "disassemble.lisp" > ... very long output > NIL > CL-USER> (symbol-plist 'disassemble) > (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/disassemble.lisp" . 1693)) > > After I called DISASSEMBLE, the result of (symbol-plist 'disassemble) was not NIL. How can I make the result of the first (symbol-plist 'disassemble) no NIL? > > > > Best regards, > Xiaofeng Yang > > > 2013/2/23 Mark Evenson <evenson(a)panix.com> >> On 2/22/13 4:01 PM, Xiaofeng Yang wrote: >> > Hi, all >> > >> > I built ABCL 1.1.1 using Ant. After I built it, I found that the source >> > locations of all the symbols are absolute path. For exmaple: >> > [1] CL-USER(1): (symbol-plist 'defun) >> > (SYSTEM::%SOURCE >> > (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) >> > PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) >> > >> > I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS >> > "sys") by myself, and even deleting system.lisp from the jar. But the >> > source location didn't change. >> > >> > How can I build ABCL 1.1.1 without recording the absolute path of the >> > source ? Or, making the source location changable so that I can locate >> > it even if I change the path of the source code ? I think I can do it >> > manually by i.g. >> > (dolist (pkg (list-all-packages)) >> > (do-symbols (sym pkg) >> > if there exists system::%source in symbol-plist, replace it)). >> > Is there any other way to do this ? >> >> Currently, there is no way of building to not recording the physical >> pathname, but there should be. The values stored in the symbol plists >> should use the SYS:SRC logical pathname. I've recorded this as ticket >> [#301][]. >> >> >> [#301]: http://trac.common-lisp.net/armedbear/ticket/301 >> >> -- >> >> "A screaming comes across the sky. It has happened before, but there is >> nothing to compare it to now." >

2 2

[armedbear-devel] ASDF 2.30 released
by Faré 21 Feb '13

21 Feb '13

Dear Lisp hackers, ASDF 2.30 is another stability release in preparation for ASDF 3. Since 2.29, in addition to specific portability fixes for CCL and CMUCL, it notably restores some backward compatible behavior for syntax tables around loading .asd files, using mutable global tables, instead of standard syntax tables. Just like 2.29, 2.28 and 2.27 before it, ASDF 2.30 is a pre-release of ASDF 3, an almost complete rewrite of ASDF, and includes a vast number of improvements since ASDF 2.26. http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… We invite all implementation vendors to update to ASDF 2.30. We also invite all implementations to make the standard *readtable* and *print-pprint-dispatch* tables immutable, with useful error messages when a modification is attempted. See how the CLHS forbids conformant programs from modifying them: http://clhs.lisp.se/Body/26_glo_s.htm#standard_readtable http://clhs.lisp.se/Body/26_glo_s.htm#standard_pprint_dispatch_table Such modification can only result in problems down the line for users, and it would be nice if at least when SAFETY isn't 0, that were checked. In some unspecified future, we'd like to revert to ASDF 2.29's behavior of binding the syntax tables to their standard values, and then we hope that most implementations will immediately catch misguided attempts by users to modify them (SBCL is the only implementation enforced immutability on both tables). Many thanks to stassats and avodonosov for their help in testing ASDF and helping make it more robust, more portable and more backward compatible. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a free market there are no market failures, only market opportunities. In a bureaucracy there is no possible success, only a perpetual ever-worsening crisis.

2 1

[armedbear-devel] Seamless ABCL / Java integration proposal
by Blake McBride 20 Feb '13

20 Feb '13

I have an idea for a largely seamless integration method for ABCL with Java that involves changing the ABCL REPL. It would work as follows. 1. From within Java or lisp, have the ability to register any number of Java classes with ABCL. 2. When executing lisp code of the form (fun args ...), try running the code as regular lisp code as it does now, but if it fails to find the lisp function and has at least one argument then: 3. Examine the arguments and, through reflection, try to find a Java method (with the same name as the lisp function) in one of the registered Java classes that matches the number and types of arguments and execute that. So, it would auto translate (in effect): (fun arg1 arg2 arg3 ...) into Java arg1.fun(arg2, arg3, ...); 4. There must be better auto-translation of lisp <-> java data types to include arrays and lists in order for this to work. So, in other words, when executing a lisp function passing a lisp array as one of the arguments, the Java reflection query will see a Java array argument type. It will also be auto-converted when making the call. 5. There must be some sort of cacheing mechanism to avoid redundant Java reflection calls. 6. This mechanism must take into account and correctly handle similar Java method names with different number and types of arguments both within and across different classes. It must also handle the fact that methods may be declared in Java superclasses. 7. This functionality can be enabled or disabled through some (Java and/or lisp function). Off by default to avoid troubles. Adding this functionality would make ABCL a plugin-and-go extension to Java. Any code could be written in Java or lisp immediately without complicated and cumbersome interface/translation code in most cases. There would be no huge initial hill to climb (to create all the interface code), and the usage would be natural and uncomplicated. Thanks. Blake McBride

5 14

Re: [armedbear-devel] Catching CL errors in java
by Alessio Stalla 20 Feb '13

20 Feb '13

I don't think the package is the culprit. Your package most probably USEs the CL package, or many other things would not work as you'd expect. Answering your earlier question, the correct way would be (setf *debugger-hook* ...) rather than defparameter, or even better binding instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)). But I don't think that can make a difference between working and not working at all. It is more of a question of good style. Perhaps you're not considering thread-local bindings? If you run your defparameter/setf form on one thread, but .eval is called on another thread (and with a GUI involved, that is very probable), then chances are that the code in your .eval call is running in a dynamic environment where *debugger-hook* is locally rebound, and thus the global binding that you modify with defparameter/setf is shadowed. You can detect it by printing the value of *debugger-hook* in an .eval call triggered by the GUI. If that is the case, you should make sure to assign a new value to *debugger-hook* on the right thread, or, better, to use (let ...) as shown above. Let me stress that using LET is usually what you want in Lisp, especially when dealing with dynamic variables; a good rule of thumb is: avoid SETF and friends (defparameter is a friend) unless you're working on local variables. Of course, experts know when and how to break the rules :D but if you're a beginner, sticking to that style will make things easier to understand and debug, once you enter the right mindset. hth, Alessio On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg <odyssomay(a)gmail.com> wrote: > It might be that I'm in the wrong package. Although the repl is in cl-user, > and even if I change to that package the code in the previous mail has no > effect. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg > <odyssomay(a)gmail.com> wrote: >> >> I don't know if this is the correct way to do it, but I did: >> >> (defparameter *debugger-hook* #'sys::%debugger-hook-function) >> >> In the repl (from running java -jar abcl.jar), this worked as expected. >> However, I can't seem to get it working with the .eval function of my >> interpreter instance. >> >> Jonathan >> >> >> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com> >> wrote: >>> >>> Short story: if you call into Lisp using the JSR-223 API, conditions >>> are automatically rethrown as Java exceptions. >>> >>> Long story: the way this is implemented is by binding *debugger-hook* >>> to an internal, probably undocumented function, that already does what >>> you want. It is called sys::%debugger-hook-function. >>> >>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >>> <odyssomay(a)gmail.com> wrote: >>> > I should add that a solution from inside CL would also work. I'm using >>> > the >>> > ABCL eval to execute all code, so maybe I could wrap the call with >>> > something >>> > like this: >>> > >>> > (handler-case >>> > (... do-stuff ...) >>> > (... catch CL-condition + throw java exception ...)) >>> > >>> > I don't know if that would work. Also, my CL skills are not good enough >>> > to >>> > finish the code above (how do I capture all conditions?), so help would >>> > be >>> > appreciated. >>> > >>> > Jonathan >>> > >>> > >>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >>> > <odyssomay(a)gmail.com> wrote: >>> >> >>> >> Hi again, :) >>> >> >>> >> I'm currently running CL-code from java. The gui is completely >>> >> implemented >>> >> on the java side. It would be nice if all errors occuring inside abcl >>> >> could >>> >> be captured from the java side (to be displayed in the gui as an >>> >> error). Is >>> >> that possible? >>> >> >>> >> Jonathan >>> > >>> > >>> > >>> > _______________________________________________ >>> > armedbear-devel mailing list >>> > armedbear-devel(a)common-lisp.net >>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >>> > >>> >>> >>> >>> -- >>> Some gratuitous spam: >>> >>> http://ripple-project.org Ripple, social credit system >>> http://villages.cc Villages.cc, Ripple-powered community economy >>> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >>> http://code.google.com/p/tapulli my current open source projects >>> http://www.manydesigns.com/ ManyDesigns Portofino, open source >>> model-driven Java web application framework >> >> > -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

2 6

[armedbear-devel] Fwd: Catching CL errors in java
by Jonathan Fischer Friberg 19 Feb '13

19 Feb '13

Sorry! Accidentally sent mail only to Alessio. If anyone else would like to help, the info/questions are below. Jonathan ---------- Forwarded message ---------- From: Jonathan Fischer Friberg <odyssomay(a)gmail.com> Date: Tue, Feb 19, 2013 at 5:50 PM Subject: Re: [armedbear-devel] Catching CL errors in java To: Alessio Stalla <alessiostalla(a)gmail.com> It might be that I'm in the wrong package. Although the repl is in cl-user, and even if I change to that package the code in the previous mail has no effect. Jonathan On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg < odyssomay(a)gmail.com> wrote: > I don't know if this is the correct way to do it, but I did: > > (defparameter *debugger-hook* #'sys::%debugger-hook-function) > > In the repl (from running java -jar abcl.jar), this worked as expected. > However, I can't seem to get it working with the .eval function of my > interpreter instance. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com>wrote: > >> Short story: if you call into Lisp using the JSR-223 API, conditions >> are automatically rethrown as Java exceptions. >> >> Long story: the way this is implemented is by binding *debugger-hook* >> to an internal, probably undocumented function, that already does what >> you want. It is called sys::%debugger-hook-function. >> >> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >> <odyssomay(a)gmail.com> wrote: >> > I should add that a solution from inside CL would also work. I'm using >> the >> > ABCL eval to execute all code, so maybe I could wrap the call with >> something >> > like this: >> > >> > (handler-case >> > (... do-stuff ...) >> > (... catch CL-condition + throw java exception ...)) >> > >> > I don't know if that would work. Also, my CL skills are not good enough >> to >> > finish the code above (how do I capture all conditions?), so help would >> be >> > appreciated. >> > >> > Jonathan >> > >> > >> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >> > <odyssomay(a)gmail.com> wrote: >> >> >> >> Hi again, :) >> >> >> >> I'm currently running CL-code from java. The gui is completely >> implemented >> >> on the java side. It would be nice if all errors occuring inside abcl >> could >> >> be captured from the java side (to be displayed in the gui as an >> error). Is >> >> that possible? >> >> >> >> Jonathan >> > >> > >> > >> > _______________________________________________ >> > armedbear-devel mailing list >> > armedbear-devel(a)common-lisp.net >> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >> > >> >> >> >> -- >> Some gratuitous spam: >> >> http://ripple-project.org Ripple, social credit system >> http://villages.cc Villages.cc, Ripple-powered community economy >> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >> http://code.google.com/p/tapulli my current open source projects >> http://www.manydesigns.com/ ManyDesigns Portofino, open source >> model-driven Java web application framework >> > >

1 0

[armedbear-devel] Catching CL errors in java
by Jonathan Fischer Friberg 19 Feb '13

19 Feb '13

Hi again, :) I'm currently running CL-code from java. The gui is completely implemented on the java side. It would be nice if all errors occuring inside abcl could be captured from the java side (to be displayed in the gui as an error). Is that possible? Jonathan

2 2

[armedbear-devel] Predicate Dispatching
by Blake McBride 18 Feb '13

18 Feb '13

The following is a link to an article talking about Predicate Dispatching in CLOS. I think this may solve the problem I have been speaking about - dispatching based on number and types of arguments. Thought I'd share the idea: http://people.csail.mit.edu/jrb/Projects/ucko-thesis.pdf Would love to hear some opinions. Thanks. Blake

1 0

[armedbear-devel] Problem building documentation
by Blake McBride 16 Feb '13

16 Feb '13

In order to build the tex documentation from the trunk I had to edit abcl.tex as follows: --- abcl.tex~ 2013-02-16 09:01:31.000000000 -0600 +++ abcl.tex 2013-02-16 09:02:04.000000000 -0600 @@ -892,7 +892,7 @@ will load and execute the Quicklisp setup code. The implementation currently breaks \textsc{ANSI} conformance by allowing the -types able to be \code{CL:READ} for the \var{DEVICE} to return a possible \code{CONS} of +types able to be \code{CL:READ} for the \code{DEVICE} to return a possible \code{CONS} of \code{CL:PATHNAME} objects. %% citation from CLHS needed. In order to ``smooth over'' the bit about types being \code{CL:READ} from

2 1

[armedbear-devel] ASDF 2.29 released
by Faré 16 Feb '13

16 Feb '13

Dear ABCL developers, ASDF 2.27 was a major rewrite of ASDF, and everything since then should be considered as candidate releases for ASDF 3: http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… ASDF 2.28 was released shortly after 2.27, without an announcement, to fix an issue found by Stelian Ionescu using TEST-OP on some systems. ASDF 2.29 is a stability release, with which I'm once again inviting implementers to update the ASDF they distribute. Please update ABCL to use ASDF 2.29. NB: I haven't looked at ASDF-JAR yet, but it would probably be a good thing to merge it with our bundle support. Since ASDF 2.27, ASDF 2.29 further brings: * deferred-warnings support for Allegro, CMUCL, SCL; fixes to the CCL support. * Upgrade fixes regarding fallback system versions; making it possible (via massive use of eval-when) to compile ASDF without loading it first. * Compatibility with private use of :D package nickname by not claiming it for package ASDF/DRIVER anymore. Also explicitly handle NIL in safe-file-write-date, in case the implementation doesn't issue a file-error in that case; make UTF-8 the default encoding for with-input-file. Be portable to #+(and sbcl (not sb-eval)). * Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393), defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Inside of many liberals is a fascist struggling to get out. — John McCarthy

2 1

[armedbear-devel] Using ABCL with large Java app
by Blake McBride 16 Feb '13

16 Feb '13

Greetings, I have a large Java app with more than 15K Java classes. I linked it up with ABCL and successfully used it in several places. However, I had a couple of problems that caused me to use ABCL significantly less than I had hoped. I thought I would share my problems and perhaps there might be a helpful suggestion. Although I don't interface with most of the 15K Java classes, there are still a lot of classes to interface ABCL with. I wrote some lisp code that, through Java reflection, creates CLOS classes that mirror the Java classes I wish to interface with. In CLOS it encapsulates the Java instance, mirrors the class hierarchy, and creates generics to match the Java methods. I found a way to create variable argument generics that feed fixed argument methods in order to handle the fact that similarly named methods can take different arguments across different Java classes. I ran into two problems that have caused me to use ABCL much less than I'd like to. The first seems like won't be too hard to solve, but the second is something I still need to find a solution to. Remember, I cannot build this interface manually. There are too many classes and methods. The first problem is that I have Java classes and instances mirrored as CLOS classes and instances. At times it was more convenient (from lisp) to deal with Java objects directly instead of CLOS mirrors. While it was more convenient, it ended up being too confusing. With all these classes, objects, and methods, it was too easy to forget what the heck I was dealing with at any point in the code. I think the only answer to this is to only deal with lisp objects when in lisp. This would avoid the confusion at the cost of wrapping and unwrapping certain Java objects at times - not too bad. I would need to have a way to pack Jeve arguments from Jave when calling Lisp. Doing it in Lisp is a problem because I am back to the confusion of knowing when I am dealing with a Java object and when a lisp object. The second problem has to do with the fact that a single Java class can use the same method name multiple times with different arguments. Remember, I am using variable argument generics to handle similar Java method names taking different argument across different classes. I still have argument checking because I dispatch to a fixed argument CLOS method. However, I cannot do this within a single class. The first obvious answer is to name mangle the generics. This is too sloppy. The other answer would be to name mangle the methods and have the generic be smart enough to dispatch to the correct method based on the argument number and types (all in CLOS). This would be a lot of work so I thought I might solicit alternative suggestions. Perhaps there is a simple answer that I hasn't come to me. Thanks. Blake McBride

3 6

[armedbear-devel] abcl-1.1.1 released
by Mark Evenson 14 Feb '13

14 Feb '13

On behalf of the ABCL developers, I am pleased to announce the release of abcl-1.1.1, a maintenance release which addressed the following issues: * (A)MOP All reported errors with the MOP implementation have been addressed. * SETF autoloader An autoloader for SETF expansion functions has been implemented, eliminating the errors associated with not being able to use (SETF SYMBOL) without first invoking SYMBOL as a function. * ANSI Tests All outstanding regressions in the ANSI test suite with respect to abcl-1.0.1 have been fixed. * ABCL-ASDF The ability to resolve Maven components in ASDF system definitions has been restored. downloads: http://common-lisp.net/project/armedbear/releases/1.1.1/ source: http://svn.common-lisp.net/armedbear/tags/1.1.1/abcl/ manual: http://abcl-dynamic-install.googlecode.com/files/abcl-20130214a.pdf -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Running abcl outside awt thread
by Jonathan Fischer Friberg 04 Feb '13

04 Feb '13

Hi, It seems that abcl is currently running on the awt thread. As when I get an error, it says something along the lines "#<THREAD "AWT-EventQueue-0" {3C6B5}>" This has some nasty side effects, namely: 1. eval blocks the ui (until the eval has finished) 2. On error, the version 1.1.0 locks down the ui completely. That is, the ui locks and doesn't come back. So it would be nice if I could run abcl on it's own separate thread. Is such a thing possible? I guess in worst case I'll have to start up a separate thread in the eval (that is, in common lisp), which I think would do what I want. I would prefer to have the whole of abcl in its' own thread though. Jonathan

4 3

[armedbear-devel] patch for automagical JAR loading
by Milos Negovanovic 30 Jan '13

30 Jan '13

Hi all, patch is attached. With it this kind of .asd spec works out of the box and resolves all JARs and puts them in classpath: (require :asdf) (require :abcl-contrib) (require :abcl-asdf) (require :jss) (asdf:defsystem #:test-asdf :serial t :description "" :author "" :license "Specify license here" :components ((:module jetty :serial t :components ((:mvn "org.eclipse.jetty/jetty-server/8.1.8.v20121106") (:mvn "org.freemarker/freemarker/2.3.19"))) (:module source :pathname "" :serial t :components ((:file "package") (:file "example")) :depends-on (:jetty)))) The bug is someplace in abcl-asdf:resolve ... didnt figure out where, i just used abcl-asdf:resolve-dependencies ... not sure why you want resolving code in 2 places anyway :). Regards -- Milos Negovanovic milos.negovanovic(a)gmail.com

1 0

[armedbear-devel] patch for runtime-class.lisp
by Milos Negovanovic 29 Jan '13

29 Jan '13

Hi all, As mentioned on #abcl on freenode, I needed the following patch to make my simple jetty example work. Patch is attached. Example for which I needed this is at: http://paste.lisp.org/display/134966 Regards -- Milos Negovanovic milos.negovanovic(a)gmail.com

2 1

[armedbear-devel] ASDF support for deferred warnings in ABCL?
by Faré 27 Jan '13

27 Jan '13

Dear ABCL developers, I've been adding support for ASDF to save deferred warnings (typically, forward function references) in a file, so that if you do an incremental compilation, warnings from previously compiled files are still correctly handled at the end of the virtual with-compilation-unit. I've added support for SBCL and CCL myself, which was made much easier by being able to read the source code to their compilers, but I don't feel like groveling through four more free sofware compilers. Would you be interested in implementing the same feature for ABCL, or at least in guiding me on how to do so? The code is mainly in asdf/lisp-build.lisp functions reify-deferred-warnings unreify-deferred-warnings reset-deferred-warnings. http://common-lisp.net/gitweb?p=projects/asdf/asdf.git Best regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I don't know if might makes right, but lack of might sure makes lack of right.

2 1

[armedbear-devel] abcl-1.1.0 vs. abcl-1.1.0.2 known differences
by Mark Evenson 26 Jan '13

26 Jan '13

To address a question that came up on #abcl: what is the difference between the abcl-1.1.0 and abcl-1.1.0.2 releases? The short answer is that there should be no difference. The release of abcl-1.1.0 (and accompanying signatures) were updated "in-place" within twenty-four hours of their release. As stated in the abcl-1.1.0.2 release announcement, the only known initial difference between the 1.1.0 and 1.1.0.2 releases of ABCL was that somehow the ABCL-CONTRIB ASDF definition in 1.1.0 was syntactically invalid as it included an extra comma (",") character preventing it from loading. After this was discovered, the abcl-1.1.0 release was rebuilt and "updated" in place on common-lisp.net. Because googlecode requires that published URIs point idempotently to their resources over time (probably to make universal distribution easier) a release designated abcl-1.1.0.2 release was made to googlecode.com If there are any observed differences between the two releases, I would appreciate knowing more details accompanied by information on how the distribution was obtained. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Upgrade issues
by Faré 24 Jan '13

24 Jan '13

ABCL is one of the three implementations, together with CLISP and CMUCL, where I ultimately punted on ASDF hot-upgrade, by just trying to rename away the ASDF package if it's too old. I don't know if you're interested in making the kind of package surgery I was indulging in work, but it involves rehoming symbols from ASDF to subpackages such as ASDF/COMPONENT, including for class slot names. Anyway, please test the latest ASDF with ABCL, I think it's ripe for release, but I'd like your feedback considering the massive amount of hacking that happened. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If the human mind were simple enough to understand, we'd be too simple to understand it. — Pat Bahn

4 7

[armedbear-devel] Android support?
by Andrew Pennebaker 22 Jan '13

22 Jan '13

What's the state of Android support for ABCL? Can we have some demo apps and tutorials? It would be awesome to write mobile apps in Lisp! -- Cheers, Andrew Pennebaker www.yellosoft.us

1 0

Re: [armedbear-devel] [asdf-devel] CMUCL fails tests (Was Re: Just pulled an update and now CCL fails the tests)
by Faré 20 Jan '13

20 Jan '13

> I guess its yet another issue with merging with *d-p-d* which defaults > to #p"" (current directory) on cmucl. > > Ray > Yup. Fixed. Which reminds me I have no implementation of getcwd for ABCL or GCL; I don't know what type it returns on Corman. ABCL hackers: is there such a thing as getcwd in ABCL, and if so how do I get to it? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A pretty face is not a passport; it's a visa and it runs out fast.

2 1

[armedbear-devel] Pre ASDF-2.27 failing to compile on ABCL
by Mark Evenson 15 Jan '13

15 Jan '13

On 1/11/13 5:53 PM, Faré wrote: > Dear Lisp hackers, > > I've completed yet another major pass of refactoring of ASDF. […] Coolness! Keep it coming! Failing to compiled the concatenated fasl from ASDF master tip (local : UNDEFINED-FUNCTION: ;COMMON-LISP:CELL-ERROR-NAME triggers autoloading of org.armedbear.lisp.cell_error_name ... ; Autoloaded org.armedbear.lisp.cell_error_name (0.0050 seconds) The function ASDF/PACKAGE::WHEN-FISHY is undefined. Have I missed some packaging in the implemenation (abcl-1.2.0-dev)? ABCL trunk currently has some problems with autoloading (some) COMMON-LISP functions via SETF expanders, which I am in the process of fixing. ; SLIME 2012-11-23 CL-USER> (lisp-implementation-version) "1.2.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Sun_Microsystems_Inc.-1.6.0_37-b06" "amd64-SunOS-5.11" Thanks, Mark <evenson(a)panix.com>

1 0

[armedbear-devel] function (setf documentation) has disappeared
by Eric Marsden 06 Jan '13

06 Jan '13

Hi, It seems that the DEFSETF for DOCUMENTATION has disappeared recently. -- Eric Marsden

2 3

[armedbear-devel] default-initargs not respected for funcallable-standard-class
by Pascal Costanza 05 Jan '13

05 Jan '13

Hi, What the subject line says. Here is a test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-method (standard-method) ()) #<STANDARD-CLASS MY-METHOD {1EE9DE5F}> CL-USER(3): (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class) (:default-initargs :method-class (find-class 'my-method))) #<FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION {6E06D676}> CL-USER(4): (defgeneric my-function () (:generic-function-class my-generic-function)) #<MY-GENERIC-FUNCTION MY-FUNCTION {2EA1569}> CL-USER(5): (generic-function-method-class #'my-function) #<STANDARD-CLASS STANDARD-METHOD {4E513D61}> The reason is that the defaulting happens in the keyword arguments for ensure-generic-function (in clos.lisp), which thus overrides any default initargs. However, the defaulting should be left to the class. Pascal -- Pascal Costanza

2 6

[armedbear-devel] PortableAserve on ABCL
by Dave Cooper 05 Jan '13

05 Jan '13

Happy New Year everybody! Welp it seems my porting binge which started over the holidays isn't quite settling down yet... So. What are the chances of getting Portableaserve to work in ABCL? Note that I'm not asking if there are better ways of serving web from ABCL (I'm sure there are). I'm just asking specifically about portableaserve on ABCL. Any opinions if this is within the realm of possibility, or would there be some obvious show-stopper? I guess most of the challenge would be getting an acl-compat working for ABCL... -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

2 1

[armedbear-devel] soap calls using java interop
by Kevin Raison 04 Jan '13

04 Jan '13

I am having trouble getting certain aspects of a soap client working using abcl's java interop; most likely, this is the result of my ignorance of how certain things map from java to lisp. Any help would be appreciated! The soap service is defined by this wsdl: http://chatsubo.net/~raison/usaepay.wsdl. The provider has a java library available for download at http://wiki.usaepay.com/developer/soap-1.4/howto/javajaxws. I have been able to use this library successfully in abcl (creating objects, calling methods on those objects, etc.), except when I need to call any of the methods defined in the java.rmi.Remote UeSoapServerPortType interface. For example, the method addCustomer is defined in the files http://chatsubo.net/~raison/UeSoapServerBindingStub.java and http://chatsubo.net/~raison/UeSoapServerPortType.java. No matter how I try to find the method (using jcall or various combinations of jmethod and class refs), I simply cannot find this method. What am I missing here? Thanks for any assistance! -Kevin -- Kevin Raison Founder Chatsubo.net, LLC http://chatsubo.net/ (p) 206-801-5728 (f) 206-801-5729

2 2

[armedbear-devel] ABCL on Android?
by Nitralime 04 Jan '13

04 Jan '13

Is there any effort to port ABCL to Android? Regards Nik

2 1

[armedbear-devel] ABCL-1.1.1
by Mark Evenson 02 Jan '13

02 Jan '13

We're approaching the "thirty days" timer for abcl-1.1.1. I would propose dusting off the readme versions, publishing abcl-1.1.1-dev as abcl-1.1.1-rc-0. I've backported from trunk what Rudi has fixed specific to (A)MOP (and therefore CLOSER-MOP). Need a locally patched Quicklisp for closer-mop, cffi, hunchentoot. I've started to dig through how to implement an "abcl" distribution for Quicklisp, but this will take more time than I probably have over the next few days (but who knows?). Excited to bring ABCL to Android, fix ANSI Streams, and more in 2013, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Additional slots in function classes screw up std-compute-discriminating-function
by Pascal Costanza 23 Dec '12

23 Dec '12

Hi, What the subject says. Here is a test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-function (standard-generic-function) ((a-slot :initarg :a-slot :accessor a-slot)) (:metaclass funcallable-standard-class)) #<FUNCALLABLE-STANDARD-CLASS MY-FUNCTION {24DF7EA4}> CL-USER(3): (defgeneric test (x y z) (:generic-function-class my-function)) #<THREAD "interpreter" {14BAAEA8}>: Debugger invoked on condition of type TYPE-ERROR The value TEST is not of type LIST. The reason is that std-compute-discriminating-function is also called for subclasses of standard-generic-function that don't override compute-discriminating function. The specialization in std-compute-discriminating-function should only occur if the passed function is _extactly_ a standard-generic-function (or if it doesn't add any slots on top of standard-generic-function). By the way, we're getting closer (ha!). More and more test cases in my test suites work. I'm pretty confident that I can add full support for ABCL in Closer to MOP for the next version of ABCL. Pascal -- Pascal Costanza

2 2

[armedbear-devel] Concatenating fasls
by Dave Cooper 21 Dec '12

21 Dec '12

Dear ABCLers, Is it possible to concatenate fasl files (.abcl files) in ABCL, to produce a single loadable .abcl file? -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

2 1

[armedbear-devel] abcl-1.1.0.2
by Mark Evenson 19 Dec '12

19 Dec '12

abcl-1.1.0.2 has been tagged and released. The abcl-1.1.0.2 release is functionally the same as artifacts built from the abcl-1.1.0 source , but not to the artifacts released on 07-DEC-2012, which were incorrectly compiled so that the JSS contrib would not load. The abcl-1.1.0 binaries available from [common-lisp.net][1] have been updated "in-place" with cryptographic signatures updated. [1]: http://common-lisp.net/project/armedbear/ The GoogleCode repository which feeds the MacPorts source doesn't allow re-publishing, so [uniquely named abcl-1.1.0.2 artifacts have been published there][2]. [2]: https://code.google.com/p/abcl-dynamic-install/downloads/list We still plan on releasing abcl-1.1.1 around New Year's Eve. hopefully getting better at managing releases, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[armedbear-devel] ABCL 1.1.0 re-published
by Mark Evenson 17 Dec '12

17 Dec '12

For reasons that are not entirely clear, JSS was not working with the images I published for abcl-1.1.0, even though building from the source on the tag worked fine. I have re-published and re-signed the release to common-lisp.net. Still sort of waiting for Quicklisp 2012-12 to drop before mailing an official announcement. Maybe we should just wait for abcl-1.1.1 at this point. mea culpa, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] ABCL 1.1.0
by Mark Evenson 10 Dec '12

10 Dec '12

Sometime later today, I intend to make [the current snapshots abcl-1.1.0-rc-2][rc-2] the functional base for [ABCL-1.1.0][]. Please speak up loud if we shouldn't do this. We will have a maintenance release within 30 days. [rc-2]: https://code.google.com/p/abcl-dynamic-install/downloads/list [ABCL-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 For the Mgmt., Mark <evenson(a)panix.com> P.S. Multiple cryptographic signatures when tag is created would be a nice thing. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

3 8

Re: [armedbear-devel] jss wouldn't load in trunk, fixed in r14313
by Mark Evenson 07 Dec '12

07 Dec '12

I think this us fixed, but I am currently visiting my doctor so won't be able to verify until later. -- Mark Rudolf Schlatte <rudi(a)constantly.at> wrote: >Hi, > >I just removed a spurious dot in jss.asd which caused loading e.g. cffi to fail. If this . is also in the release candidate, it should be removed before release. :) (I fail at git-svn and so only see trunk.) > >Cheers, > >Rudi >_______________________________________________ >armedbear-devel mailing list >armedbear-devel(a)common-lisp.net >http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >

1 1

[armedbear-devel] jss wouldn't load in trunk, fixed in r14313
by Rudolf Schlatte 07 Dec '12

07 Dec '12

Hi, I just removed a spurious dot in jss.asd which caused loading e.g. cffi to fail. If this . is also in the release candidate, it should be removed before release. :) (I fail at git-svn and so only see trunk.) Cheers, Rudi

1 0

[armedbear-devel] abcl-1.1.0 release status
by Mark Evenson 07 Dec '12

07 Dec '12

Overall, I think we are more-or-less ready to release the long awaited abcl-1.1.0 with the exception of resolving the outstanding ANSI regression failures. I have moved all previously outstanding issues to the abcl-1.1.1 milestone, and I have added as three blocker tickets to the abcl-1.1.0 milestone to decide on what to do. http://trac.common-lisp.net/armedbear/ticket/265 http://trac.common-lisp.net/armedbear/ticket/266 http://trac.common-lisp.net/armedbear/ticket/267 For each of these issues, I have identified the changeset that caused the regression via bisecting the source tree. If the result of the bisection is correct, all three issues should be relatively easy to track down, as "not much happened" in the commits. But maybe something was screwy in my process (I did it "on the road" from an iPad ssh client last week in a non-traditional--for me--working environment). Additionally, we should probably check the Novemeber Quicklisp test reports to see if anything has been broken. I seem to see a problem with Hunchentoot under SLIME regarding the PATHNAME reader, but this may be something local to me. I need to finish writing up the CHANGES, and make a quick pass through the manual, updating the grovelled docstring sections. Hopefully, we can have a quick consultation on #abcl tonight at 2100 CST to see if these plans make sense. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

5 21

[armedbear-devel] ABCL 1.1.0 RC2
by Mark Evenson 06 Dec '12

06 Dec '12

All reported outstanding bugs with CLOSER-MOP addressed in [abcl-1.1.0][rc2]. Please test. [rc2]: http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] JFLI bug
by Carlos Ungil 05 Dec '12

05 Dec '12

Hello, I think this bug report has gone unnoticed: there is a reference to sys::ensure-class (has to be changed to mop:ensure-class) in http://trac.common-lisp.net/armedbear/browser/trunk/abcl/contrib/jfli/jfli.… Thanks, Carlos On Wed, Nov 28, 2012 at 11:10 PM, Carlos Ungil <carlos.ungil(a)gmail.com> wrote: > Mark, Erik, > > thank you for those fixes. > > There is another bug in jfli.lisp, at line 366 there is a call to > sys::ensure-class > but it seems that this function has been moved to another package: > mop:ensure-class > > I have two more comments about jfli.lisp (but these are not critical issues). > > 1) the function unbox-string (never used, probably it can be removed) > calls the undefined function convert-from-java-string > > 2) I used to have an additional clause in infer-box-type (I don't > remember the details, but I think I had to add it to be able to pass a > Float argument to some java API): > > ((typep x '(integer -9223372036854775808 +9223372036854775807)) long.type) > + ((typep x 'single-float) float.type) > ((numberp x) double.type) > > Cheers, > > Carlos > > On Wed, Nov 28, 2012 at 10:26 AM, Mark Evenson <evenson(a)panix.com> wrote: >> >> On Nov 26, 2012, at 11:34 PM, Carlos Ungil <carlos.ungil(a)gmail.com> wrote: >> >>> Dear ABCL developers, >>> >>> I apologize if this is not the right channel for this kind of request, >>> but I'd like to suggest the following change to >>> src/org/armedbear/lisp/Lisp.java (for CFFI to identify the platform >>> properly on MacOSX). >>> >>> @@ -2378,9 +2378,9 @@ >>> } >>> // Processor architecture >>> if(osArch != null) { >>> - if (osArch.equals("amd64")) >>> + if (osArch.equals("amd64")||osArch.equals("x86_64")) >>> featureList = new Cons(Keyword.X86_64, featureList); >>> - else if (osArch.equals("x86")) >>> + else if (osArch.equals("x86")||osArch.equals("i386")) >>> featureList = new Cons(Keyword.X86, featureList); >>> } >>> Symbol.FEATURES.initializeSpecial(featureList); >>> >> >> Erik applied this in [r14256][]. Thanks for the patch! >> >> [r14256]: http://trac.common-lisp.net/armedbear/changeset/14256 >> >>> Also, there is a problem with contrib/jfli/test/yanking.lisp, there is >>> a referece to abclidea:*lisp-dir* and that package is not part of >>> ABCL. >>> As a workaround I've changed contrib/jfli/jfli.asd to remove the >>> (:module test :components ((:file "yanking")) >> >> Since there is no need for runtime dependency for JFLI on IntelliJ, >> I [have moved the JFLI IntelliJ test suite into its own ASDF system >> definition][r14257]. Please let us know if this does' work for you >> for some reason. >> >> [r14257]: http://trac.common-lisp.net/armedbear/changeset/14257 >> >> -- >> "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #266: PSETF.47 ANSI regression
by Erik Huelsmann 05 Dec '12

05 Dec '12

That's correct. sent from my phone On Dec 5, 2012 5:02 PM, "armedbear" <armedbear-devel(a)common-lisp.net> wrote: > #266: PSETF.47 ANSI regression > > -----------------------------+---------------------------------------------- > Reporter: mevenson | Owner: nobody > Type: defect | Status: new > Priority: blocker | Milestone: 1.1.0 > Component: java | Version: 1.1.0-dev > Keywords: ansi-regression | > > -----------------------------+---------------------------------------------- > > Comment(by rschlatte): > > (setf mask-bit) is undefined until mask-bit is called. Maybe outoloading > is to blame? > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/266#comment:1> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[armedbear-devel] reinitialize-instance on class metaobjects incorrect
by Pascal Costanza 05 Dec '12

05 Dec '12

Hi, Consider the following test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass a () ()) #<STANDARD-CLASS A {794563AA}> CL-USER(3): (defclass b (a) ()) #<STANDARD-CLASS B {62F6FB59}> CL-USER(4): (finalize-inheritance (find-class 'a)) NIL CL-USER(5): (finalize-inheritance (find-class 'b)) NIL CL-USER(6): (class-precedence-list (find-class 'b)) (#<STANDARD-CLASS B {62F6FB59}> #<STANDARD-CLASS A {794563AA}> #<STANDARD-CLASS STANDARD-OBJECT {23309E87}> #<BUILT-IN-CLASS T {100C62C8}>) CL-USER(7): (reinitialize-instance (find-class 'b)) #<STANDARD-CLASS B {62F6FB59}> CL-USER(8): (class-precedence-list (find-class 'b)) (#<STANDARD-CLASS B {62F6FB59}> #<STANDARD-CLASS STANDARD-OBJECT {23309E87}> #<BUILT-IN-CLASS T {100C62C8}>) The invocation of reinitialize-instance obviously reinitialized the direct-superclasses slot, and thus removed the superclass a. However, according to the HyperSpec, the general protocol for reinitialize-instance is always that slots for which no initargs are provided through reinitialize-instance should be left untouched. This also restated implicitly in the CLOS MOP specification, for example in the section "Initialization of Class Metaobjects:" The defaulted superclass list is specified to be only assigned during initialization, but not during reinitialization. Pascal -- Pascal Costanza

2 2

[armedbear-devel] defmethod doesn't call add-method
by Pascal Costanza 04 Dec '12

04 Dec '12

Hi, There is a problem that a defmethod may not call add-method as it should. Here is a transcript: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class)) #<FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION {3606AFA2}> CL-USER(3): (defgeneric f (x) (:generic-function-class my-generic-function)) #<MY-GENERIC-FUNCTION F {589D4D84}> CL-USER(4): (defmethod add-method :after ((gf my-generic-function) (m standard-method)) (print :foo)) #<STANDARD-METHOD ADD-METHOD :AFTER (MY-GENERIC-FUNCTION STANDARD-METHOD) {3F4C428F}> CL-USER(5): (defmethod f ((x integer)) (+ x x)) #<STANDARD-METHOD F (INTEGER) {27A5DAC0}> CL-USER(6): (add-method #'f *) :FOO #<MY-GENERIC-FUNCTION F {589D4D84}> CL-USER(7): (f 5) 10 …or maybe just :after methods on add-method are not called… Pascal -- Pascal Costanza

2 2

[armedbear-devel] compiler macro, flet, inline => Failed AVER: "NIL"
by James M. Lawrence 03 Dec '12

03 Dec '12

Armed Bear Common Lisp 1.2.0-dev-svn-14276 Java 1.7.0_04 Oracle Corporation The warning and error occurs on the second COMPILE call. The AVER is in COMPILE-VAR-REF. (defun foo (n) n) (define-compiler-macro foo (n) `(flet ((bar (k) k)) (declare (inline bar)) (bar ,n))) (compile nil '(lambda () (foo 3))) (compile nil '(lambda () (foo 3))) ; Caught STYLE-WARNING: ; The variable K is defined but never used. compile-var-ref general case ; Compilation unit finished ; Caught 1 STYLE-WARNING condition => Failed AVER: "NIL" [Condition of type SIMPLE-ERROR]

2 1

[armedbear-devel] Incomplete file lisp/digest.lisp in r14198
by Eric Marsden 02 Dec '12

02 Dec '12

Hi, File src/org/armedbear/lisp/digest.lisp in current SVN contains an incomplete function named SHA256 (unbalanced parentheses). -- Eric Marsden

5 7

[armedbear-devel] abcl-1.1.0 RC0
by Mark Evenson 01 Dec '12

01 Dec '12

First release candidate of abcl-1.1.0 now available. [source]: svn://common-lisp.net/project/armedbear/svn/branches/1.1.x/ [binaries]: http://code.google.com/p/abcl-dynamic-install/downloads -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Unix domain sockets for abcl
by Rudolf Schlatte 26 Nov '12

26 Nov '12

Hi, I'm having a go at getting clx to run on abcl. Seems the jvm doesn't support unix domain sockets out-of-the-box and we need a library like junixsocket (http://code.google.com/p/junixsocket/) or juds (https://github.com/mcfunley/juds) to avoid connecting to localhost:6000 over IP where the X server might not be listening depending on how it's configured. What's the best way to proceed? (I'm a bit jetlagged or I could maybe answer this one myself..) Rudi

2 1

[armedbear-devel] Mobile ports of ABCL?
by Andrew Pennebaker 24 Nov '12

24 Nov '12

Any interest in porting ABCL to Android, iPhone, and Windows Phone? Even just a basic REPL would be really useful for Lispers. -- Cheers, Andrew Pennebaker www.yellosoft.us

2 1

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

09 Nov '12

Hello, We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method: ;;;---------------- (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com")))) ; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers))))) ;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName") ; Java exception 'java.lang.NoSuchMethodException: No applicable method named size found in java.lang.Object or java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) ;;;---------------- I chased this into org.armedbear.lisp.Java, where findMethod is returning null. - Jonathan Bona

4 7

[armedbear-devel] cffi requires maven
by Anton Vodonosov 09 Nov '12

09 Nov '12

Hello. In ABCL CFFI requires maven. Maven is used to fetch jna.jar. This is done via abcl-contrib.jar/mvn/jna.asd What I think is inconvenient is that maven is tried even if jna.jar is in classpath. IMHO it would be to not require maven installed if JNA is available. The current workaround is (provide 'jna). With that I can do: (java:add-to-classpath "my-jna/jna.jar") (provide 'jna) (ql:quickload :drakma) BTW, I think it's probably makes sense to ship jna.jar together with official ABCL release. Best regards, - Anton

3 8

[armedbear-devel] has anyone reviewed ticket #247?
by Anton Vodonosov 09 Nov '12

09 Nov '12

Hello. It's not a pressing issue for me. Just to ensure the ticket is not overlooked before the release, has anyone reviewd #247?

2 2

[armedbear-devel] Compiler bug in call to MAX
by Eric Marsden 29 Oct '12

29 Oct '12

Hi, The following illustrates what looks like a bug in the compiler's handling of type propagation (bug disappears without the type declaration). CL-USER(25): (lisp-implementation-version) "1.1.0-dev-svn-14222M" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_03-b21)" "amd64-Linux-3.3.0-trunk-amd64)" CL-USER(26): (defun foo (a b) (declare (type (integer * 6488318769) b)) (max 1 (the (integer * 5711538578) a) b 2 1351352470)) FOO CL-USER(27): (foo 5711538444 6488318765) 6488318765 CL-USER(28): (compile 'foo) FOO NIL NIL CL-USER(29): (foo 5711538444 6488318765) 1351352470 -- Eric Marsden

2 1

[armedbear-devel] BABEL-TESTS on ABCL
by Erik Huelsmann 28 Oct '12

28 Oct '12

Hi Luis, Today we've been working on ABCL being able to compile and load BABEL; actually, it could do that already, but didn't work with BABEL-TESTS. We've committed some fixes which handle reader issues uncovered by the library, but we're now stuck: there's a bit of code commented out on CCL. It seems we're running into the same problems as CCL, due to strictness of interpretation of code points. Could you mark the #-ccl section in tests/tests.lisp as #-(or ccl abcl)? That solves our problem with the #\udcf0 code point. Thanks in advance! Bye, Erik.

2 1

[armedbear-devel] Current CFFI and Hunchentoot patches for ABCL
by Mark Evenson 28 Oct '12

28 Oct '12

With [my latest CFFI patches][1], I am able to at least get CFFI to load for its tests under OSX and Solaris. Currently, the test suite fails around 32 tests depending on the hosting operating system. [1]: http://slack.net/~evenson/abcl/cffi/cffi-abcl-20121021a.patch This patch at least allows one to run the tests against Hunchentoot if [it has been patched for socket timeouts][2]. [2]: http://slack.net/~evenson/abcl/hunchentoot/hunchentoot-1.2.6-abcl-20121020a… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 1

[armedbear-devel] Fwd: Re: [armedbear-cvs] r14218 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 27 Oct '12

27 Oct '12

sent from my phone ---------- Forwarded message ---------- From: "Erik Huelsmann" <ehuels(a)gmail.com> Date: Oct 27, 2012 11:24 AM Subject: Re: [armedbear-cvs] r14218 - trunk/abcl/src/org/armedbear/lisp To: <mevenson(a)common-lisp.net> Cc: <Armedbear-devel(a)lists.sf.net> Hi mark, If the intended type is right, this should not be required, right? Then my question is: why isn't the intended type correct? Bye, Erik. sent from my phone On Oct 27, 2012 10:50 AM, <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Sat Oct 27 01:50:30 2012 > New Revision: 14218 > > Log: > Always bypass method access checks for JSTATIC. > > Enables a (to be released) patched CFFI to actually use callbacks. > > Modified: > trunk/abcl/src/org/armedbear/lisp/Java.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Java.java > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Java.java Fri Oct 26 23:40:54 2012 > (r14217) > +++ trunk/abcl/src/org/armedbear/lisp/Java.java Sat Oct 27 01:50:30 2012 > (r14218) > @@ -472,6 +472,7 @@ > else > methodArgs[i-2] = arg.javaInstance(argTypes[i-2]); > } > + m.setAccessible(true); > Object result = m.invoke(null, methodArgs); > return JavaObject.getInstance(result, translate, > m.getReturnType()); > } > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] lisp source files encoding
by Anton Vodonosov 21 Oct '12

21 Oct '12

Hello. Starting from ASDF 2.21 it is possible to specify lisp source files encoding in defsystem (see asdf manual: http://common-lisp.net/project/asdf/asdf.html#Miscellaneous-additional-func…) ABCL now comes with ASDF 2.25. But still encoding specification doesn't work on ABCL. See this log for example: https://cl-test-grid.appspot.com/blob?key=564037 The system being compiled specifies :encoding :ut8 in its defsystem, and we saw the encoding specification working - it fixed compiilation on SBCL. But on ABCL it still fails. Does anyone have idea why so? Is it because of the way ASDF is integrated into ABCL? Or ABCL just doesn't support utf-8 lisp files at all? Best regards, - Anton

3 4

[armedbear-devel] Change in merge semantics which fixes loading CFFI
by Mark Evenson 21 Oct '12

21 Oct '12

After extensive testing and refactoring, I have pushed a series of changes (from [r14176][] through [r14179][]) to trunk that should, among other things, finally fix the issues associated with loading CFFI. To affect the fixes, I have introduced a slight change in the merge pathname semantics in [r14178][], which I described in the Manual by the following text: When merging pathnames and the defaults point to a JAR-PATHNAME, we set the DEVICE of the result to :UNSPECIFIC if the pathname to be be merged does not contain a specified DEVICE, does not contain a specified HOST, does contain a relative DIRECTORY, and we are not running on a MSFT Windows platform. The intent of this rather arcane sounding deviation from conformance is so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the CLHS description of MERGE-PATHNAMES (the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device"). A future version of the implementation may return to conformance by using the HOST value to reflect the type explicitly. Additionally TRUENAME on non-Windows now fills in the DEVICE component with :UNSPECIFIC, but this is conforming behaviour. I will close the relevant tickets when I get a chance (and no one has proved me a liar in the meantime). [r14176]: http://trac.common-lisp.net/armedbear/changeset/14176 [r14178]: http://trac.common-lisp.net/armedbear/changeset/14178 [r14179]: http://trac.common-lisp.net/armedbear/changeset/14179 Comments, criticisms, usage reports (especially of the "Yay! CFFI works now!" variety), solicited. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

[armedbear-devel] cl-test-grid results for ABCL rev 14200 - all regressions are gone
by Anton Vodonosov 17 Oct '12

17 Oct '12

Hello. The last revision tested by test gird is 14200. The report is here: http://common-lisp.net/project/cl-test-grid/abcl.html As you can see, all the regressions comparing the 1.0.1 release have gone. The red result for shelly in the right column is not problem of ABCL. It's just because new ABCL has upgrated ASDF and shelly was not ready to work with new ASDF (BTW, fixed in the shelly repository). Best regards, - Anton

2 1

[armedbear-devel] The road to abcl-1.1.0
by Mark Evenson 11 Oct '12

11 Oct '12

# Features ## CLOSER-MOP ## CFFI ## Quicklisp ## JSS ## ABCL-ASDF ## JFLI Follow the [release engineering for abcl-1.1.0][abcl-1.0.0] [abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] BigNum question
by archisman rudra 09 Oct '12

09 Oct '12

Is this correct behavior? CL-USER(17): (type-of 1234567898723618080928927362387) (INTEGER 2147483648) The relevant java code is in Bignum.java: (the value field is a java BigInteger) @Override public LispObject typeOf() { if (value.signum() > 0) return list(Symbol.INTEGER, new Bignum((long)Integer.MAX_VALUE + 1)); return Symbol.BIGNUM; } for comparison: CL-USER(23): (type-of -1234567898723618080928927362387) BIGNUM which makes intuitive sense.

4 9

[armedbear-devel] Question about jnew-runtime-class
by archisman rudra 09 Oct '12

09 Oct '12

Hi, hopefully this is the correct list. If not please let me know. Background: I am trying to use abcl to generate jars to send off to a hadoop cluster for execution. The svn version of the jnew-runtime-class does not store the actual method bodies in the generated class file, but rather loads the generated class file and sets the relevant field. Here is the relevant code : (multiple-value-bind (class-file method-implementation-fields) (apply #'java::%jnew-runtime-class class-name stream args) (sys::put-memory-function memory-class-loader class-name (sys::%get-output-stream-bytes stream)) * (let ((jclass (java:jcall "loadClass" memory-class-loader class-name)))* * (dolist (method method-implementation-fields)* * (setf (java:jfield jclass (car method)) (cdr method)))* jclass)))) This means that the generated jar file cannot be easily used from standard java code. I would like to add some code in the static initialization block of generated class file to do something equivalent. I will have to save the lambda expression for the method and have been experimenting as follows: (defvar *cf*) (defvar *mif*) (with-open-file (stream "test.class" :direction :output :element-type '(unsigned-byte 8)) (multiple-value-bind (class-file method-implementation-field) (java::%jnew-runtime-class "test" stream :methods `(("forty_two_method1" :int () ,(lambda (this) 42)))) (setf *cf* class-file) (setf *mif* method-implementation-field))) (with-open-file (stream "test_forms" :direction :output) (dolist (m *mif*) (system:dump-form (list (car m) (function-lambda-expression (cdr m))) stream))) This assumes that the lambda expression does not refer to any variable or user defined function, but perhaps the asdf-jar contrib might help here. I was going to write the relevant code and start using it for my project, but I was wondering if I am duplicating work that others have already done or are doing and whether there are other libraries (jffli perhaps, I am not very familiar with it) that have similar functionality. Also if there are other interactions with other parts of the system that I am perhaps missing. I would e grateful for any advice. Archi

2 3

[armedbear-devel] Status of my work towards abcl-1.1
by Mark Evenson 08 Oct '12

08 Oct '12

After much banging around against issues involved in merging PATHNAME objects when the defaults points to a JAR-PATHNAME, I think I am finally converging on a solution. I have [committed a design document][1] that describes my approach. The main user visible result here would be the successful location and retrieval from the network of the JNA component necessary for loading CFFI. [1]: http://trac.common-lisp.net/armedbear/changeset/14172 The gist of the problem lies in that on non-Windows, the default DEVICE component is NIL, which when merged with a JAR-PATHNAME which represents the filesystem location of the jar archive in DEVICE, results in some rather bad interactions. At the top of problem, on non-Windows when the defaults contain a JAR-PATHNAME: 1. (truename #p"/") fails. 2. Loading ASDF systems from jar files which declare dependencies on other ASDF systems will fail. My proposed solution is to: 1. On non-Windows, TRUENAME for a non-JAR-PATHNAME will set the DEVICE of the result to :UNSPECIFIC. 2. Treat a JAR-PATHNAME as implicitly having a different HOST from normal file PATHNAME, so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the [CLHS description of MERGE-PATHNAMES][2] (the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device…"). [2]: http://www.lispworks.com/documentation/HyperSpec/Body/f_merge_.htm My (uncommitted) patches seem to resolve all the problems, and work on both Windows and non-Windows. I still have two remaining ANSI failures that the changes introduced, involving the value of *COMPILE-FILE-TRUENAME* for which I need to rewrite the form which the compiler dumps pathnames from #p"/foo/bar" to the #p(:directory (:absolute "foo") :name "bar") form. Somehow, the new form isn't being read correctly (Erik I could use your advice here). In addition, since namestrings are no longer always roundtrippable as they discard an :UNSPECIFIC DEVICE, I've had to change a bit of code in the compiler and the Pathname implementation which assumed otherwise. A cleaner solution would probalby have been to actually populate the HOST field with a type nonce, like SBCL does. But we already use HOST to store information for a URL-PATHNAME. And given the reality that we should release an abcl-1.1.0 as soon as realistically possible, when I estimated that going down this route would change much more code I opted for the current solution where we take a cut at "Do What I Mean" reasoning we could potentially retrofit this with HOST containing various HOST forms for abcl-1.2.x if enough objections were raised. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Fixes to trunk for cl-test-grid regressions
by Erik Huelsmann 04 Oct '12

04 Oct '12

Hi, Last two weeks I've committed several fixes for regressions reported by cl-test-grid on http://common-lisp.net/project/cl-test-grid/abcl.html. The page might be updated today or tomorrow based on r14163 (I think). Today I committed a fix for CL-ROUTES, which means the MAPPER-TEST-SUITE regressions shown in that page (even after the update) have also been fixed. That's it for the update for now :-) Bye, Erik.

1 0

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

30 Sep '12

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

2 6

[armedbear-devel] Update to code for running ABCL on the Cygwin version of Emacs
by Mark Evenson 24 Sep '12

24 Sep '12

The change to SLIME on 2011-12-24 changed the way that the inferior Lisp image is invoked, breaking [my previous instructions on how to get SLIME working under Cygwin][1]. After a bit of wrangling, I have [posted modified code to get ABCL working under the Cygwin Emacs again, changing the canonical location should further updating be necessary][2]. I decided to implement my changed version as a "code walker" that transforms the s-expr emitted by SLIME-INIT-COMMAND, utilising the ability of SLIME-LISP-IMPLEMENTATIONS to specify an init function. I reasoned that this would be better than an Emacs DEFADVICE as the .emacs initialization can now be reasonably shared between different Lisp implementations. DEFADVICE might have been a bit cleaner, but it would probably break just as easily in the future the next someone changes the way SLIME invokes things. For those suitably inclined, comments on this implementation choice would be welcome, as I am not the most experienced elisp hacker. Bug reports as to the new procedure are solicited if it fails to work for you. [1]: http://abcl-dev.blogspot.co.at/2010/05/running-slime-under-cygwin-with-abcl… [2]: http://slack.net/~evenson/abcl/slime-under-cygwin.html -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[armedbear-devel] Long stack overflow stack trace
by Theam Yong Chew 22 Sep '12

22 Sep '12

Hi devs, I'm getting a really unwieldy stack trace with what I think is a simple error. Starting from this file, ======== Debug.java ============ // Some imports might be a bit redundant, copy & pasted... import org.armedbear.lisp.Interpreter; import org.armedbear.lisp.Package; import org.armedbear.lisp.Packages; import org.armedbear.lisp.Symbol; import org.armedbear.lisp.JavaObject; public class Debug { public static Interpreter getOrCreateInterpreter(){ if (null == Interpreter.interpreter) { return Interpreter.createInstance(); } else { return Interpreter.interpreter; } } public static void main(String[] args) throws Exception { Interpreter in = getOrCreateInterpreter(); in.eval("(load \"non-existent-file.lisp\")"); System.exit(0); } } ==================== If I now attempt to run it, $ javac -cp ../jars/abcl.jar Debug.java $ java -cp ../jars/abcl.jar:. Debug I get the stack overflow & long stack trace shown below. What gives? What's a better way to avoid this type of error? I'm running out of an old svn tree: Armed Bear Common Lisp 1.1.0-dev-svn-13990 Java 1.6.0_18 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Incidentally, I have another question concerning Interpreter.createInstance. Calling it a more than once results in a return value of null. I can see this behaviour in the source. Why is this? Yong The long stack trace (with minor edits to tidy up the console output): $ java -cp ../jars/abcl.jar:. Debug #<THREAD "main" {4B5386C2}>: Unhandled condition of type FILE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: #<THREAD "main" {4B5386C2}>: Unhandled condition of type SIMPLE-ERROR: Exception in thread "main" java.lang.StackOverflowError at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Lisp.progn(Lisp.java:684) at org.armedbear.lisp.Closure.execute(Closure.java:211) at org.armedbear.lisp.Closure.execute(Closure.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.format_65.execute(format.lisp:379) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.pprint_153.execute(pprint.lisp:718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.format_190.execute(format.lisp:1894) at org.armedbear.lisp.LispThread.execute(LispThread.java:719) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_184.execute(format.lisp:1754) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.format_183.execute(format.lisp:1740) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.format_182.execute(format.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:135) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.Lisp.funcall(Lisp.java:178) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.Condition.printObject(Condition.java:205) at org.armedbear.lisp.Lisp.format(Lisp.java:2049) at org.armedbear.lisp.Primitives$pf__format._format(Primitives.java:1702) at org.armedbear.lisp.Primitives$pf__format.execute(Primitives.java:1679) at org.armedbear.lisp.Symbol.execute(Symbol.java:837) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_28.execute(clos.lisp:222) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.Lisp.funcall(Lisp.java:176) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2835) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.clos_248.execute(clos.lisp:2273) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.clos_234.execute(clos.lisp:2052) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:106) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_14.execute(print.lisp:281) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.print_16.execute(print.lisp:301) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) $

1 0

[armedbear-devel] Fwd: Question about jnew-runtime-class
by archisman rudra 21 Sep '12

21 Sep '12

[Possibly duplicate post, sorry] Hi Alessio, Thanks for the quick and detailed response. Interesting! I'm answering because I wrote the current (incomplete) > version of jnew-runtime-class. Just FYI, you can find some notes about > it at <http://trac.common-lisp.net/armedbear/wiki/JavaFfi/RuntimeClass>. > I read that, and that did help a lot in understanding the new code. BTW, regarding the constructors, shouldn't you be able to define a method entry with name as :constructor and have that work? From looking at the function map-method-name in jvm-class-file.lisp, but not actually tested it yet. > What I wanted to achieve is to have methods that can be: > * arbitrary functions, including closures > * possibly redefined after the class has been loaded. Redefinition is > possible by using symbols as method implementations. > > There's also a hidden goal that is to keep the implementation simple > enough, and compiling Lisp code to the body of methods in an arbitrary > class is not easy at the moment. > > What explicitly is NOT a requirement is to have the generated class be > independent from ABCL (the methods are implemented in Lisp and will > always need runtime support). So, no matter how you arrange things, > you will never be able to distribute your class without abcl.jar. Note > that it is the same for Clojure, Scala, Groovy, etc. > > I don't know specifically how Hadoop works, but, as I see things, you need > to > 1. provide abcl.jar + your class to it > 2. have Hadoop execute enough code to load ABCL and initialize your class. > > Right. This is the same in clojure where I implemented something similar, but the language was unfamiliar and the way to actually call compile felt clunky, but some of that surely was simply unfamiliarity. So what I want to do is the following: 1. have abcl.jar and generated_filename_with_method_implementations.lisp in the classpath 2. Do the jvm equivalent of the following java code: Interpreter interp = Interpreter.createInstance(); interp.eval("(load \"generated_filename_with_method_implementations.lisp\")"); in the static initialization block of the class. > Now, probably the key point is who loads your class. > * if you can arrange to have ABCL load it and pass it to Hadoop, you > should be good with the current design. > * if Hadoop wants to load it by itself from a jar, then yes, you have > to somehow dump the method implementations somewhere and have the > class auto-load them from there when it is initialized. > > For the second case, I propose an intermediate design that is, imho, > simpler than dumping arbitrary forms: special-case the situation when > a method implementation is a symbol. In that case, directly generate > an instruction in the class file to find that symbol in its package > and assign it to the appropriate field. If the implementation of a > method is not a symbol nothing changes. That way, you will still need > to init ABCL before loading your class, but, when all your method > implementations are symbols, the class will be able to initialize > itself without external support. If some methods are proper functions, > instead, the class won't be self-contained, but will need some Lisp > code to be executed to be properly initialized. > > Does it make sense to you? Do you find it acceptable? If yes, I can > give a shot at implementing it, if you want. > > This certainly seems reasonable, but I don't understand the bit about "directly generate an instruction to find the package and do the assignement". Do I not need to change the compile infrastructure to get at the jvm representation of the (fdefinition name) ? The code in %jvm-compile (in compiler-pass2.lisp) seems to do the compilation to a (sys::%make-byte-array-output-stream) rather than to arbitrary output-streams. Don't know the reason for this. If this can be changed, we can do this for arbitrary forms, rather than just symbols. ie, we can compile the relevant forms into classname_methodname.abcl and generate a static method call to Load.load(filename) in the static init block as before, to do the autoloading, and then we will know the LispObject name holding the jmethod and can assign that to the appropriate field as you suggest above. Other than this (the compile issue), I find this entirely reasonable and would love it if you do implement it. much regards, Archi > Peace, > Alessio > > -- > Some gratuitous spam: > > http://ripple-project.org Ripple, social credit system > http://villages.cc Villages.cc, Ripple-powered community economy > http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM > http://code.google.com/p/tapulli my current open source projects > http://www.manydesigns.com/ ManyDesigns Portofino, open source > model-driven Java web application framework >

1 0

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

19 Sep '12

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

3 17

[armedbear-devel] NEWBIE
by emeka okafor 13 Sep '12

13 Sep '12

Hello Guys, I would like to use abcl on some project and I have a couple of questions for you guys: - What IDE do you guys use? - What build system do you use? - Can I integrate abcl in maven? Thx.

5 6

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

05 Sep '12

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

2 2

[armedbear-devel] changes to autoloading affecting PermGen space?
by Alan Ruttenberg 05 Sep '12

05 Sep '12

I've recently been getting ; Evaluation aborted on #<JAVA-EXCEPTION java.lang.OutOfMemoryError: PermGen space {2D9FD5EA}>. I'm wondering whether it is possible that the recent changes to autoloading are filling more of this space, leading to my (and presumably others at some point) errors. -Alan

3 5

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

31 Aug '12

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

3 12

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

26 Aug '12

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

1 0

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

24 Aug '12

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

2 1

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

22 Aug '12

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

1 0

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

22 Aug '12

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

1 1

[armedbear-devel] BUG: ClassCastException in MAKE-PATHNAME
by Eric Marsden 22 Aug '12

22 Aug '12

Hi, The following behaviour is not ideal. ,---- | Armed Bear Common Lisp 1.1.0-dev-svn-14131M | Java 1.7.0_03 Oracle Corporation | OpenJDK 64-Bit Server VM | Low-level initialization completed in 0.3 seconds. | Startup completed in 1.456 seconds. | Loading /home/emarsden/.abclrc completed in 0.66 seconds. | Type ":help" for a list of available commands. | CL-USER(1): (make-pathname :device (list "foo")) | java.lang.ClassCastException: org.armedbear.lisp.SimpleString cannot be cast to org.armedbear.lisp.Pathname | at org.armedbear.lisp.Pathname.getNamestring(Pathname.java:657) | at org.armedbear.lisp.Pathname.printObject(Pathname.java:909) | at org.armedbear.lisp.Primitives$pf__output_object.execute(Primitives.java:907) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_8.execute(print.lisp:127) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_14.execute(print.lisp:281) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) `---- -- Eric Marsden

1 0

[armedbear-devel] Problem with defstruct accessor functions and included structures in combination with conc-names
by Ralf Moeller 18 Aug '12

18 Aug '12

The following file causes a problem in ABCL (1.1.0-dev-svn-14041) when compiled (!) and loaded. (in-package cl-user) (defstruct a (s1 nil)) (defstruct (b (:include a) (:conc-name foo-)) (s2 nil)) (defstruct (c (:include a) (:conc-name foo-)) (s3 nil)) (defun test () (let ((x (make-b :s1 1 :s2 2))) (foo-s1 x))) CL-USER(4): (test) #<THREAD "interpreter" {2EF7D41F}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<B {564434F7}> is not of type C. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(6): (lisp-implementation-version) "1.1.0-dev-svn-14041" [1] CL-USER(7): The problem is that the defstruct declaration for c "overwrites" the accessor foo-s1 generated by defstruct b. If foo-s1 is called for a b instance, the type assertions introduced by define-reader (and define-writer, see the ABCL implementation for defstruct) cause the error described above. The code above runs fine in ACL, Lispworks, SBCL, and other Lisps. I had to remove the generation of type assertions in define-reader and define-accessor (see below) to make the code work in ABCL. Note, however, that there is no type checking pursued with the code below. Thus, a better solution might be developed. Regards, Ralf Moeler http://www.sts.tu-harburg.de/~r.f.moeller/ (defun define-reader (slot) (let ((accessor-name (dsd-reader slot)) (index (dsd-index slot)) (type (dsd-type slot))) (cond ((eq *dd-type* 'list) `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-list-reader ,index)))) ((or (eq *dd-type* 'vector) (and (consp *dd-type*) (eq (car *dd-type*) 'vector))) `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-vector-reader ,index)) (define-source-transform ,accessor-name (instance) `(aref ,instance ,,index)))) (t `((declaim (ftype (function * ,type) ,accessor-name)) (setf (symbol-function ',accessor-name) (make-structure-reader ,index ',*dd-name*)) (define-source-transform ,accessor-name (instance) ,(if (eq type 't) ``(structure-ref ,instance ,,index) ``(the ,',type (structure-ref ,instance ,,index))))))))) (defun define-writer (slot) (let ((accessor-name (dsd-reader slot)) (index (dsd-index slot))) (cond ((eq *dd-type* 'list) `((setf (get ',accessor-name 'setf-function) (make-list-writer ,index)))) ((or (eq *dd-type* 'vector) (and (consp *dd-type*) (eq (car *dd-type*) 'vector))) `((setf (get ',accessor-name 'setf-function) (make-vector-writer ,index)) (define-source-transform (setf ,accessor-name) (value instance) `(aset ,instance ,,index ,value)))) (t `((setf (get ',accessor-name 'setf-function) (make-structure-writer ,index ',*dd-name*)) (define-source-transform (setf ,accessor-name) (value instance) `(structure-set ,instance ,,index ,value)))))))

3 5

[armedbear-devel] ABCL development surprises
by Erik Huelsmann 18 Aug '12

18 Aug '12

Every time I create a new feature or new behaviour for ABCL, the system surprises me: with all the automatic detection of autoloaders, one would say that the system should have slowed down. Nothing of that sort happened. In fact, build time for ABCL seems to have gone down from over 6 minutes (can't remember: 6'15 or 6'30) to roughly 5'30! Unfortunately, start up times have gone up to 4s. Bye, Erik.

1 0

[armedbear-devel] Autoloaders: status report and a question
by Erik Huelsmann 18 Aug '12

18 Aug '12

Hi all, Sorry for the bumpy ride while I reorganized the auto loader system. Thanks for taking the time to respond to my earlier questions on auto loaders. This is the time to explain what I did with your answers (and what I did in general). To reiterate what this is all about: the autoloader is an important part of the start up efficiency and internal file dependency resolution of ABCL: it establishes function and macro bindings on symbols without loading the actual code to bind to. Instead, loading the FASL is being delayed until some part of the system (or a user) needs it. There are two variants of autoloaders: Java class autoloaders and lisp (fasl) autoloaders. Their purpose is the same and they operate roughly the same way, but one operates by forcing a class to be loaded while the other causes a FASL to be loaded. Most parts of the system don't know about autoloaders and simply evaluate code. The autoloaders take special action when evaluated: their purpose is not to execute the intended action, but instead, they load the fasl in which the actual code is located. Then, when the actual code is loaded, the function (or macro) call is forwarded to the loaded code. The FASL loader process replaces the content of the function symbol slot with the true function so the autoloader gets garbage collected after replacement. This entire system works pretty well, that is: *if* you know which symbols you have to install an autoloader on. Before my changes, we didn't know which symbols we had to install autoloaders on. Instead, we maintained a list of symbols by hand through trial and error. When a change caused total havoc, you'd look for the cause and - hopefully - debugged the problem to a missing autoloader. That's when you would add an autoloader to autoloads.lisp. That works as long as our only purpose is to build ABCL. However, we actually intend for ABCL to be used by our users. Users may not be aware of what autoloaders do for them and choose to start calling some random function in the AMOP definition. Since we hand-maintain a list of functions to be decorated with autoloaders, that probably doesn't work. So, in order to provide more stability for our users we need to decorate all functions with autoloaders. What's more: having all functions decorated with autoloaders -if done well- should also help ABCL development quite a bit: the chances of a change causing havoc because a non-decorated function is being used have been reduced to next-to-none. What then did I do? The change involves a few steps: 1. Extraction of symbols to be decorated ============================= The file compiler now generates (when compiling our own system, that is) two extra output files: basename.funcs and basename.macs. These files contain a single s-exp with all the symbols which have been DEFUNed or DEFMACROed respectively. With this information, we can generate decoration information. Analysis of the extracted symbols leads to the conclusion we can't assign an autoloader to each and every extracted symbol for 2 reasons: a. There is a built-in function associated with the symbol to help bootstrapping b. There are multiple DEFUNs or DEFGENERIC/DEFMETHODs 2. Determination of what to decorate symbols with ==================================== Autoloaders - at this time - can only be used to load a single FASL. So, when a symbol is in multiple files, we need to choose which file it load the FASL for (and hence not the others). Most symbols which occur in multiple files are DEFMETHODs which is perfectly fine. Most symbols with double locations stem from the EXTENSIBLE-SEQUENCES implementation. We want to exclude those FASLs, which reduces the number of multi-homed symbols to only a few. All single-homed symbols excluding those which have bootstrap functions attached can be decorated with autoloaders. 3. Generate code to install the autoloaders =============================== We just used to have autoloads.lisp (and Autoload.java). But that file will contain only the manual bits which can't be auto-generated. So there's now a second file autoload-gen.lisp. This file is being generated during the build and populated with all symbols which need an autoloader. Today's autoload.lisp has been stripped to the bare minimum of AUTOLOAD and AUTOLOAD-MACRO forms. With the stripped autoload.lisp and the fact that the autoloaders are bootstrapping helpers, I had to take additional measures to help us bootstrap again. The result is autoloads-gen.lisp in the source directory. It is loaded at build time to help bootstrapping. It's an unmodified version I took from the build directory: build/classes/org/armedbear/lisp/autoloads-gen.lisp - the one which is generated on each build. 4. Exporting the right symbols ====================== Not a problem related to autoloading per se, but definitely related to the fact that we don't load all fasls at boot time: autoload.lisp - as the canonical location being loaded at startup - had grown to be a listing of EXPORT forms. Having EXPORT forms and actual code widely apart is counter-intuitive: to the occasional developer it's inexplicable how some symbols become exported and some don't. (We had files with additional EXPORT forms.) So, when the above was "solved", I created another facility which collects all the symbols in the second argument of EXPORT throughout our source tree. Those symbols are added to the autoload-gen file and the EXPORT forms executed at start up as well. Even though the developer still doesn't know what's going on, the system should be working transparently. All of the above has happened over the last week(s) - last week, mostly. Then there is the question: As it turns out, the macroexpansion for DEFSTRUCT happens in a way such that the file compiler can't detect the slot accessors as being defined as functions. The advantage is that we're *not* seeing a whole slew of symbols to be attached to autoloaders and hence limiting the number of autoloaders (the contructor function *is* detected). Now: what do others think: should we depend on the constructor being called before any of the accessors to make sure the autoloaders have been run? Or should we attach an autoloader to each accessor function just to be sure? (This requires small changes to the file compiler and defstruct macro expansion.) Bye, Erik.

1 0

[armedbear-devel] SLIME && ABCL autoloaders
by Erik Huelsmann 18 Aug '12

18 Aug '12

Hi Mark, While working on the autoloaders, I found a very interesting thing: SLIME doesn't know about ABCL's autoloaders. To maximize the benefit of SLIME for ABCL (yea, I even started using it to debug ABCL itself, after you pointed out to me that these tools generally help productivity), I think it would be beneficial to teach it about autoloaders. The case I'm talking about is this: When using M-. SLIME looks up the source code location for the source associated with the symbol. However, when you do that to a symbol which hasn't been autoloaded yet, that source code location information isn't available. SLIME could easily resolve that by evaluating the form (SYS::RESOLVE <symbol>) and look for the info after that. SLIME could do the same when looking up function lambda list information to present in the minibuffer for auto-completion. How about that? Bye, Erik.

2 1

[armedbear-devel] SLIME broken on current svn because export statement is in autoloaded file
by Rudolf Schlatte 18 Aug '12

18 Aug '12

Hi, Subject says most of it, I guess. Currently, threads.lisp line 36ff. contains the export form that exports make-thread-lock from the threads package ... which will be evaluated as soon as one of the autoloaded functions is called. This first function call must use notation for unexported symbols to avoid a reader error. Cheers, Rudi

2 1

[armedbear-devel] Forward referenced classes woes
by Stas Boukarev 15 Aug '12

15 Aug '12

Consider the following code: (defclass whitespace-normalizer (sax-proxy)) (defclass sax-proxy (broadcast-handler) ()) (defclass broadcast-handler () ((handlers :initform nil :initarg :handlers :accessor broadcast-handler-handlers))) Doing the followoing results in errors: (setf (broadcast-handler-handlers (make-instance 'whitespace-normalizer)) 10) There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION (SETF BROADCAST-HANDLER-HANDLERS) {6621477C}> when called with arguments (10 #<WHITESPACE-NORMALIZER {14BAAEA8}>). (setf (broadcast-handler-handlers (make-instance 'sax-proxy)) 10) The slot HANDLERS is missing from the class #<STANDARD-CLASS SAX-PROXY {1700FFDB}>. The problem is that whitespace-normalizer and sax-proxy are finalized too early. Finalization happens in std-after-initialization-for-classes http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/… by calling maybe-finalize-class-subtree, which in its turn finalizes the class and its subclasses in case the class has all its superclasses finalized. When (defclass whitespace-normalizer (sax-proxy)) is executed it creates a forward-referenced-class for sax-proxy, and when sax-proxy is defined it calls a method for ensure-class-using-class http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/… for forward-referenced-classes. Before calling reinitialize-instance it does (change-class class metaclass) to change from forward-referenced to normal class. change-class in its turn calls shared-initialize method, which calls the aforementioned std-after-initialization-for-classes, but it doesn't supply any direct-superclass arguments. So, when maybe-finalize-class-subtree is called it thinks that sax-proxy's sole superclass is standard-object, so it goes ahead finalizing sax-proxy and whitespace-normalizer at the wrong time with wrong information. And ensure-class-using-class later call with the right direct-superclass information doesn't matter anymore, since the classes were already badly finalized -- With best regards, Stas.

2 2

[armedbear-devel] [patch] compile slightly broken for compiled functions
by Vladimir Sedach 14 Aug '12

14 Aug '12

Hi, (compile nil (compile nil (lambda ()))) => NIL (compile '+) => + The first result is obviously wrong, and the second one is actually as well (according to the HyperSpec, compile should return the function definition of +). The fix is rather trivial: Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 14055) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -7483,7 +7483,7 @@ (resolve name) ;; Make sure the symbol has been resolved by the autoloader (setf definition (fdefinition name))) (when (compiled-function-p definition) - (return-from jvm-compile (values name nil nil))) + (return-from jvm-compile (values definition nil nil))) (let ((catch-errors *catch-errors*) (warnings-p nil) (failure-p nil) Index: test/lisp/abcl/compiler-tests.lisp =================================================================== --- test/lisp/abcl/compiler-tests.lisp (revision 14055) +++ test/lisp/abcl/compiler-tests.lisp (working copy) @@ -472,11 +472,10 @@ (not (null result)))) t) +(deftest compile-named + (compile '+) + (symbol-function '+)) - - - - - - - \ No newline at end of file +(deftest compile-compile + (compiled-function-p (compile nil (compile nil (lambda ())))) + t) Happy hacking, Vladimir

2 3

[armedbear-devel] Wrongly initialized generic function method combination
by Stas Boukarev 13 Aug '12

13 Aug '12

When compile a file with (defgeneric test (a b) (:method-combination progn :most-specific-last)) (defmethod test progn (a b) (list a b)) TEST receives a wrong method-combination (mop:generic-function-method-combination #'test) => #<METHOD-COMBINATION STANDARD {6E99175D}> When defgeneric is called, the generic function TEST is already created by the defmethod macro at macroexpansion time, but not completely initialized, so defgeneric ends up calling reinitialize-instance with :method-combination, but the slot for method-combination is called %METHOD-COMBINATION and its initarg is :%METHOD-COMBINATION, so nothing gets initialized. This was changed in the following commit: http://trac.common-lisp.net/armedbear/changeset?new=13947%40trunk%2Fabcl%2F… -- With best regards, Stas.

2 1

[armedbear-devel] [Patch]: Make listen work on gray-streams.
by Stas Boukarev 13 Aug '12

13 Aug '12

gray-listen functions weren't plugged into cl:listen for some reason. -- With best regards, Stas.

2 1

[armedbear-devel] LISTEN doesn't work on non-character streams
by Stas Boukarev 13 Aug '12

13 Aug '12

(with-open-file (stream "/dev/zero" :element-type '(unsigned-byte 8)) (listen stream)) #<FILE-STREAM {5CF9DE08}> is not a character input stream. -- With best regards, Stas.

1 0

[armedbear-devel] Stack overflow when compiler macro with fallback is triggered
by James M. Lawrence 12 Aug '12

12 Aug '12

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

5 5

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

12 Aug '12

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

3 3

[armedbear-devel] compile doesn't return correct values for warnings-p and failure-p
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile nil '(lambda () (char=))) ; Caught WARNING: ; Wrong number of arguments for CHAR=. ; Compilation unit finished ; Caught 1 WARNING condition #<FUNCTION (LAMBDA ()) {456E3EB3}> NIL NIL while it should be T, T. jvm-compile, which handles this doesn't succeed because the underlying with-compilation-unit eats all the warnings and errors so that jvm-compile's handler-bind doesn't get a piece of them. Binding *resignal-compiler-warnings* to T inside jvm-compile resolves this. -- With best regards, Stas.

1 0

[armedbear-devel] char= compilation warning
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile (defun test (a b c) (if (char= a b c) t))) ; Caught WARNING: ; Wrong number of arguments for CHAR= (expected 2, but received 3). The error is caused by p2-test-char= in compiler-pass2.lisp:2667 calling (check-arg-count form 2). -- With best regards, Stas.

1 1

[armedbear-devel] [Patch]: Which allows drakma to run.
by Stas Boukarev 11 Aug '12

11 Aug '12

Drakma uses its own type OCTET as element-type for streams it's defined as (deftype octet () '(unsigned-byte 8)) But read-byte and friends don't recognize type because it's not expanded before-hand. So, what I did is to apply EXPAND-DEFTYPE beforehand. Perhaps UPGRADED-ELEMENT-TYPE would've been better, or something entirely different in an another place or more places. But it allows me to use drakma successfully. So, one can do (push :drakma-no-ssl *features*) ;; I can't load CFFI needed for cl+ssl (asdf:load-system :drakma) (drakma:http-request "http://bing.com") => fancy results On another note, I couldn't get usocket to work on Debian until I discovered that I need to either do echo 0 > /proc/sys/net/ipv6/bindv6only or launch java with -Djava.net.preferIPv4Stack=true Otherwise usocket returns a very cryptic error SOCKET-TYPE-NOT-SUPPORTED-ERROR which is in reality "java.net.SocketException: Network is unreachable". -- With best regards, Stas.

2 2

[armedbear-devel] MACROLET environment issue in DO?
by Theam Yong Chew 11 Aug '12

11 Aug '12

Hi devs, I've just stumbled upon something that looks buggy. In the following form, I am particularly focusing on the end-test-form in the do macro. (macrolet ((foo () '(print "macrolet foo"))) (foo) (do ((p 0 (1+ p))) ((foo)) (print "LOOP"))) Prints "macrolet foo" "macrolet foo" then returns ==> NIL Looks fine, but if I wrap that in a function, (defun use-foo () (macrolet ((foo () '(print "macrolet foo"))) (foo) (do ((p 0 (1+ p))) ((foo)) (print "LOOP")))) (use-foo) Prints "macrolet test" then raises an error: The function FOO is undefined. [Condition of type UNDEFINED-FUNCTION] 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 FOO. 3: [RETRY] Retry SLIME interactive evaluation request. 4: [*ABORT] Return to SLIME's top level. 5: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {1879842}> #<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>) 1: (APPLY #<FUNCTION {1879842}> (#<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>) 3: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {1426780}>) 4: (ERROR #<UNDEFINED-FUNCTION {1426780}>) 5: (SYSTEM:UNDEFINED-FUNCTION-CALLED FOO NIL) 6: (FOO) Locals: "??" = "??" 7: (USE-FOO) Locals: "??" = "??" 8: (SYSTEM::%EVAL (USE-FOO)) Locals: "??" = "??" 9: (EVAL (USE-FOO)) Locals: "??" = "??" .... If I define a function with same name as the local macro, (defun test () (print "function test")) (defun use-test () (macrolet ((test () '(print "macrolet test"))) (test) (do ((p 0 (1+ p))) ((test)) (print "LOOP")))) (use-test) Prints "macrolet test" "function test" then returns ==> NIL If I manually macroexpand the do form & substitute the expansion back into the function (with some gensym tidy up), (defun macro-expanded-do () (macrolet ((test () '(print "macrolet test"))) (test) (BLOCK NIL (LET ((P 0)) (TAGBODY (GO G4759) G4758 (PRINT "LOOP") (PSETQ P (1+ P)) G4759 (UNLESS (TEST) (GO G4758)) (RETURN-FROM NIL (PROGN))))))) (macro-expanded-do) Prints "macrolet test" "macrolet test" ; No value and returns ==> NIL Is this a bug? I'm running on Windows, using (lisp-implementation-version) ==> "1.0.1-svn-13750-13751" Thanks, Yong.

2 1

[armedbear-devel] breakage in r14066
by James M. Lawrence 09 Aug '12

09 Aug '12

(defstruct foo (data nil)) (defun test () (let ((foo (make-foo))) (symbol-macrolet ((x (foo-data foo))) (setf x 99)) (foo-data foo))) (test) ;=> NIL

2 1

[armedbear-devel] IGNORE declaration in inline function not heeded
by James M. Lawrence 09 Aug '12

09 Aug '12

(declaim (inline foo)) (defun foo (x) (declare (ignore x)) 99) (defun bar (a) (foo a)) compile-file emits ; Caught STYLE-WARNING: ; The variable X is defined but never used. 1.1.0-dev-svn-14066

2 1

[armedbear-devel] Bogus error signaled when compiling bogus RETURN call
by James M. Lawrence 09 Aug '12

09 Aug '12

CL-USER> (lisp-implementation-version) "1.1.0-dev-svn-14066" CL-USER> (defun foo () (return)) FOO CL-USER> (compile 'foo) ; Caught ERROR: ; RETURN-FROM NIL: no block named NIL is currently visible. The value #<EQUAL HASH-TABLE 0 entries, 11 buckets {AE9DCF}> is not of type STRUCTURE-OBJECT. [Condition of type TYPE-ERROR] 0: (#<FUNCTION {1FA8BA4}> #<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>) 1: (APPLY #<FUNCTION {1FA8BA4}> (#<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {1E5E70E}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:423) 6: org.armedbear.lisp.LispObject.getSlotValue(LispObject.java:1241) 7: org.armedbear.lisp.compiler_pass2_389.execute(compiler-pass2.lisp:7453) 8: org.armedbear.lisp.compiler_pass2_375.execute(compiler-pass2.lisp:7408) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:628)

1 0

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

08 Aug '12

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

5 5

[armedbear-devel] abcl-1.1.0 engineering scrum @ 2100 CET (1900 GMT) on #abcl
by Mark Evenson 06 Aug '12

06 Aug '12

We will be holding the weekly abcl-1.1.0 engineering scrum @ 2100 CET on #abcl. Anyone with questions, priorities, patches, welcome to join. The meeting will probably be sparsely attended, so I will just work on recording the [current status as I see it on the Armed Bear Trac Wiki][1]. We can move to audio/video if there is a need. [1]: http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Unqualified FIND-PACKAGE call in ABCL compiled files
by Vladimir Sedach 06 Aug '12

06 Aug '12

Hi, Currently, ABCL doesn't qualify the package of FIND-PACKAGE when it serializes a package in a compiled file. This causes a bug when loading a compiled file that has code (for example, the EOS:TEST macro from the EOS unit-testing library) that serializes a package, and occurs after an IN-PACKAGE into a package that either shadows or does not import FIND-PACKAGE from COMMON-LISP. I didn't work out a minimum test case, but the problem can be observed when trying to load the Parenscript test suite: (ql:quickload :parenscript.test) Here's the fix: Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 14055) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -1191,7 +1191,7 @@ (defun serialize-package (pkg) "Generate code to restore a serialized package." - (emit 'ldc (pool-string (concatenate 'string "#.(FIND-PACKAGE \"" + (emit 'ldc (pool-string (concatenate 'string "#.(CL:FIND-PACKAGE \"" (package-name pkg) "\")"))) (emit-invokestatic +lisp+ "readObjectFromString" (list +java-string+) +lisp-object+)) Index: src/org/armedbear/lisp/Package.java =================================================================== --- src/org/armedbear/lisp/Package.java (revision 14055) +++ src/org/armedbear/lisp/Package.java (working copy) @@ -865,7 +865,7 @@ public String printObject() { if (_PRINT_FASL_.symbolValue() != NIL && name != null) { - StringBuilder sb = new StringBuilder("#.(FIND-PACKAGE \""); + StringBuilder sb = new StringBuilder("#.(CL:FIND-PACKAGE \""); sb.append(name); sb.append("\")"); return sb.toString(); Happy hacking, Vladimir

2 1

[armedbear-devel] Monday progress meeting
by Erik Huelsmann 05 Aug '12

05 Aug '12

Hi Mark, Dunno if I'll be making it to our monday progress meeting tomorrow (travelling to be done). But this is my status: * My work on DEFINE-METHOD-COMBINATION can be considered Done; I left some todo's behind which should be relatively small in comparison to the original problem. It's now just a matter of changing the symbols in the backquote patterns. * My work on the autoloader has been mostly done as far as our current infrastructure allows; next steps: - Clean autoload.lisp for any symbols which automatically end up in autoload-gen.lisp - Create infrastructure for autoloading of SETF functions (ie function names not designated by a symbol) * Crashes evaluating a form referencing an undefined function in a clean image --> solved by requiring PRINT-OBJECT in the right place With respect to this point: it's possibly a good idea to do a search of the code base and find out if we're doing this everywhere PRINT-OBJECT methods are being defined * COMPILER-UNSUPPORTED-FEATURE-ERROR derived from CONDITION --> solved * Autoloader fails when *READ-xxx* variables bound to unexpected values --> solved * Implement USE-FAST-CALLS properly --> resolved by deleting the USE-FAST-CALLS infrastructure from the interpreter; the compiler already does the right thing * Compiling #n# causes stack overflow --> solved; however, Stas Boukarev reports that the case I've fixed only fixes in-memory compilation and the issue still exists in file compilation. Ticket #191 should be re-opened to and should say so. All in all a pretty good result for one week. However, from here on $WORK will start again which means I'll only be able to address the bigger issues in small steps. Or just the smaller issues, of course. Which is why I'm glad to have worked out the D-M-C stuff. That was a week more than full time work to completely comprehend the spec and macrology going on in our implementation. That's it for now. If I'm available tomorrow at 21:00 CET, I'll be on #abcl. Bye, Erik.

1 0

[armedbear-devel] Trouble compiling functions with cyclic structures.
by Stas Boukarev 05 Aug '12

05 Aug '12

compile-file has trouble with (defun bar () '#1=(cycle . #1#)) -- With best regards, Stas.

1 0

[armedbear-devel] special operators without a macro definition
by Pascal J. Bourguignon 03 Aug '12

03 Aug '12

Here is a "bug-report"/enhancement suggestion: ------------------------------------------------------------------------ The following special operators don't have a corresponding macro definition. THREADS:SYNCHRONIZED-ON EXTENSIONS:TRULY-THE JVM:WITH-INLINE-CODE While the standard doesn't specify anything for special operators not in the CL package, it would still be nice if they followed the same rule as for CL macros implemented as special operators: 3.1.2.1.2.2 Macro Forms An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided. since this would ensure that portable code walkers can be written. ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 0

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

01 Aug '12

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

4 4

[armedbear-devel] RFC: Autoloading and "multi-homed symbols"
by Erik Huelsmann 01 Aug '12

01 Aug '12

Hi all, Just committed my progress on the automatically generated autoloads. The next step is to clean up "autoloads.lisp" (the file which still exists to allow manual addition/manipulation. While I can do that step by myself, I'd like to discuss a problem we already have today, just never encountered: Generic functions can have methods defined in more than one file. Example: PRINT-OBJECT has its GF defined in print-object.lisp, but has methods defined in print-object.lisp, java.lisp and format.lisp. Clearly, when PRINT-OBJECT is being called for the first time (and hence needs to be autoloaded), it's not correct to autoload java.lisp or format.lisp: we would miss the generic function and if print-object.lisp is loaded later, it'll overwrite the methods already defined. On the other hand, *only* loading print-object.lisp isn't correct either: we have no idea if the arguments passed to the call should have caused the methods in java.lisp or format.lisp to be triggered. My current thinking about the above is that we'd need to load all files in which methods are being defined for PRINT-OBJECT. These files should makes sure (through REQUIRE) that they load the file with the generic function first. The autoloading facility should then hook into require in some way or another to make sure it doesn't load files which have been loaded through REQUIRE to prevent out-of-order loading. Then my next issue is that if one of the files being loaded in the loaded group has symbols which are multi-homed in a different (but overlapping) set of files, those files need to be loaded as well, for the same reasons. My question is: what are your thoughts on the subject? BTW: I have some more questions I'd like to discuss regarding autoloading, but since they are unrelated, I'm holding off posting until discussion on this subject has settled on a general direction for development. What was autoloading again? Autoloading is a mechanism which allows ABCL to start up quickly by deferring loading of FASLs which it only needs later. Also, helps ABCL to run in memory-restrained environments by loading only the support necessary to run the code at hand. Autoloading is a feature used *only* for ABCL's own FASLs. User-FASLs will always be fully loaded (although I suppose it should be possible to leverage the existing autoloader infrastructure to help users who think they need this for themselves). Bye, Erik.

3 2

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

01 Aug '12

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

2 1

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

31 Jul '12

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

1 0

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

31 Jul '12

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

1 0

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

30 Jul '12

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

1 0

[armedbear-devel] bug in FASL loader
by Durward McDonell 29 Jul '12

29 Jul '12

Hello. I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl. Consider the following code: (defmacro foo-bar (s) `(sublis '((foo . bar)) ,s)) (defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it))) Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis". -- Durward McDonell durward.mcdonell(a)jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)

4 7

[armedbear-devel] Planning for abcl-1.1.0
by Mark Evenson 29 Jul '12

29 Jul '12

Yesterday (and today), Erik and I spent time discussing and preparing for the engineering work necessary to get abcl-1.1.0 released. This release will obviously feature Rudi's hard work as a reasonably stable version of AMOP that CLOSER-MOP can be patched to reference, but we have other goals as well which I want to capture so I now transcribe a bit about our thinking, decisions, and plans going forward. Comments, objections, innovations, etc. solicited. We now have [some 34 active bugs][abcl-1.1.0] in the ABCL 1.1.0 milestone that we intend to address. We have assigned an owner to most of the bugs of either Erik or myself. This does not mean that others shouldn't be working on the bug as well if they have time to contribute to it, just that they should co-ordinate to the "owner" (a quick #abcl message like "ehu: I have stuff for #19?, do you have any patches?" would be fine to avoid duplication). Roughly, Mark got everything dealing with abcl-contrib and Pathnames, and Erik got everything dealing with the compiler. We intend to have a weekly meeting on #abcl, tentatively for set for Mondays around 2100 CET which we will review what we have gotten done, ask questions, and generally try to move the release forward. Everyone is welcome to contribute feedback, volunteer help, etc. as these will be open meetings. We plan on an abcl-1.1.1 maintenance release 30 days after abcl-1.1.0 that will fix everything that we can. [abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 An explanation of the criteria for bugs we selected: # Criteria for issues In order of importance: 0. Enable CLOSER-MOP. 1. No regressions with respect to the behavior of abcl-1.0.1. Fortunately, there only seems to be one categorized with "regression" tag (is this really the correct situation?) 2. Load a wider range of Quicklisp systems. Fix the ANSI test-grid problem if it is still active, using the source code distributed by Quicklisp as the basis for a more robust system. We might not necessarily fix the compiler in all cases, but instead implement a fallback strategy to include source forms in our FASLs for which to pass to EVAL for forms that we can't compile. This is under active consideration, as it presents the single largest unknown in terms of necessary resources to address. 3. Fix all known "ansi-conformance" problems. 4. Fix everything reported as broken by users. In the weekly meetings, we may start "jettisoning" some issues for later releases as time goes on. We estimate that given just Erik's and my time, it will take roughly three months from now to release abcl-1.1.0. If you want to make this happen faster, we welcome all helping hands. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Space leak due to threads stuck in LispThread map
by Pendergrass, James A. 27 Jul '12

27 Jul '12

Hello all, I'm having some trouble with space leakage that looks to be because the static map in LispThread isn't letting go of completed JavaThreads. Basically what I'm doing on the Java side looks like: > class Foo { > public static int main(){ > manager = new Manager(); > fun = getLispFunction("processResults"); > > new Thread() { > public void run() { > LispObject res = generateSomeLisp(); > fun.execute(manager, res); > }.run(); > manager = null; > while(1); > } > } The lisp side looks like: > (defun processResults (manager res) > (let ((*manager* manager)) > (declare (special *manager*)) > (eval res))) But the manager never gets destroyed. I used the eclipse Java Memory Analysis tool to track this down to the created JavaThread being referenced as a key in the static map variable in LispThread. Any suggestions on how to get around this? The whole code base is pretty memory intensive so garbage collecting that manager is really a must (and cleaning up the thread is probably a good plan too). Thanks, -Aaron

3 6

[armedbear-devel] Saturday ABCL hacking meeting on #abcl from Austria
by Erik Huelsmann 26 Jul '12

26 Jul '12

Hi all, Mark and I are going to work together this Saturday all day from my holiday address in Austria to see if we can work on tickets (especially ANSI compliance and "needs tests"), test trunk with the latest Quicklisp libraries, and hopefully find out what's required to get to 1.1.0. We'd like to invite you into #abcl on freenode.org and get your input and participation: we'll be logged in most of the day and evening. (To those who don't know: our nicks are easye (Mark) and ehu (me, obviously)). Bye, Erik.

2 1

[armedbear-devel] asdf 2.23 released
by Faré 20 Jul '12

20 Jul '12

I am pleased to announce the release of ASDF 2.23. Since previous release 2.22, the changes are as follow: * add new :compile-check argument to compile-file* and around-compile-hook. This allows for consistency check of .fasl output before the file can possibly be seen by other builds (i.e. no race condition). This change makes the asdf-finalizers extension possible. * export more utilities for dealing with pathnames from environment. These changes are few and subtle, but nonetheless significant to those who'd use these features. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is only one basic human right, the right to do as you damn well please. And with it comes the only basic human duty, the duty to take the consequences. — P. J. O'Rourke

2 1

[armedbear-devel] Longs, Bytes, or casting in general
by Theam Yong Chew 20 Jul '12

20 Jul '12

Hi folks, I was wondering how we can conveniently pass longs, bytes into normal Java functions/constructors, for example, (jnew "java.lang.Byte" 23) ==> Java exception 'java.lang.NoSuchMethodException: Byte(java.lang.Integer)'. [Condition of type JAVA-EXCEPTION] Here only constructor available is for "byte" inputs. It's a pain to have to use this every time we use a byte, long, or similar: (jnew (jconstructor "java.lang.Byte" "byte") 23) #<java.lang.Byte 23 {3A9300BF}> Relatedly/alternatively, is there a way convenient to coerce values to a certain type, forcing 23 above (default int/Integer) to be a byte or long? Yong

3 5

[armedbear-devel] wrong FASL version with 1.0.1
by Durward McDonell 18 Jul '12

18 Jul '12

Hello. I'm using abcl-1.0.1. My code loads just fine, but when I try to run it, I get FASL version mismatch; found '38' but expected '26' in sublis I'm running this in slime. If I do something like (sublis '((foo . bar)) '(foo)) it works as expected, and THEN I can run my code and it works. Is there something cached somewhere I need to blow away, or is something else I need to do? If I look at the abcl.jar I'm using, I can see that sublis.abcl says it's FASL version 38, just like everything else in abcl.jar. Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)

2 1

[armedbear-devel] cffi, asdf question
by Durward McDonell 12 Jul '12

12 Jul '12

Hello. I noticed that there is currently some difficulty getting cffi to load properly. I've gotten it to load using Mark Evenson's patches (I think), but it still required loading something, getting an error, and loading it again, and then assuming it was loading correctly. In the interest of doing it The Right Way, I have some questions. I hope they make some sense. ASDF doesn't know about loading systems from jar files -- that seems to be the job of abcl-asdf. But abcl-asdf has to be loaded from a jar file, right? So there's a bootstrapping problem. Where is this dealt with? Or is there some other magic I haven't yet figured out to load systems from jar files? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)

2 1

[armedbear-devel] Wrong symbol after loading fasl
by James M. Lawrence 12 Jul '12

12 Jul '12

(defpackage :foo (:use :cl)) (in-package :foo) (defvar *data* nil) (defpackage :bar (:use :cl)) (in-package :bar) (eval-when (:compile-toplevel) (import 'foo::*data*)) (setf *data* 99) Compile this, restart ABCL, and load the fasl. foo::*data* is NIL and bar::*data* is 99. It's possible the code is somehow nonconforming, however it sure seems that foo::*data* should be written and later loaded, which is the behavior of other Lisps. The issue is also exhibited with (compile-file "test.lisp") (delete-package :foo) (delete-package :bar) (load "test.abcl")

1 0

[armedbear-devel] BUG: JVM stack inconsistency triggered by compiler
by Eric Marsden 11 Jul '12

11 Jul '12

Hi, CL-USER(50): (lisp-implementation-version) "1.1.0-dev-svn-13998M" CL-USER(51): (lambda (a b c) (declare (optimize (safety 0))) (ash 3 (min 2 (the integer (block b (catch 'ct a)))))) #<FUNCTION (LAMBDA (A B C)) {374FB6BE}> CL-USER(52): (compile nil *) ; Caught STYLE-WARNING: ; The variable B is defined but never used. ; Caught STYLE-WARNING: ; The variable C is defined but never used. #<THREAD "interpreter" {5D4AAA93}>: Debugger invoked on condition of type INTERNAL-COMPILER-ERROR Stack inconsistency detected in NIL at index 36: found 2, expected 1. Restarts: 0: CONTINUE Eventually use interpreted form instead 1: TOP-LEVEL Return to top level. -- Eric Marsden

2 1

[armedbear-devel] BUG: threads:mailbox-send
by Uchida Yasuo 05 Jul '12

05 Jul '12

Hi folks, The function threads:mailbox-send seems not working. In the example below, (threads:mailbox-peek mbox) returns NIL. It should be "item". The attatched patch fixes this problem. Armed Bear Common Lisp 1.1.0-dev-svn-13992 Java 1.6.0_24 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.396 seconds. Startup completed in 4.0 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf mbox (threads:make-mailbox)) #S(MAILBOX :QUEUE NIL) CL-USER(2): (threads:mailbox-send mbox "item") NIL CL-USER(3): (threads:mailbox-peek mbox) NIL T CL-USER(4): Many thanks. -- Yasuo Uchida

2 1

[armedbear-devel] asdf::*OPERATING-SYSTEM* => :solaris for (LISP-IMPLEMENTATION-VERSION) => "1.0.1-svn-13750-13751"
by Alan Ruttenberg 28 Jun '12

28 Jun '12

Don't know if this is fixed in a later version, but I was noticing asdf put my binaries in an odd-looking directory. -Alan

2 1

[armedbear-devel] Fwd: How to compile and run Maxima with ABCL?
by Phuc Luoi 24 Jun '12

24 Jun '12

---------- Forwarded message ---------- From: Phuc Luoi <phucluoi(a)gmail.com> Date: Tue, Jun 19, 2012 at 12:51 PM Subject: Re: [armedbear-devel] How to compile and run Maxima with ABCL? To: Robert Dodier <robert.dodier(a)gmail.com> Thanks for your answer. I tried this and got these errors: Can't intern zero-length symbol. Restarts: 0: RETRY Retry compiling #<ASDF:CL-SOURCE-FILE "maxima" "utilities" "mformt">. 1: ACCEPT Continue, treating compiling #<ASDF:CL-SOURCE-FILE "maxima" "utilities" "mformt"> as having been successful. 2: TOP-LEVEL Return to top level. by compiling the file /maxima-5.27.0/src/mformt.lisp (step 9) I have choose the option 1 to accept this. I got some more errors by compiling. After all I got Out of memory PermGen space Restarts: 0: TOP-LEVEL Return to top level. and abcl did not compiled maxima. Can you tell me why I got these error? And how can repair them? On Tue, Jun 19, 2012 at 5:04 AM, Robert Dodier <robert.dodier(a)gmail.com> wrote: > On 2012-06-16, Phuc Luoi <phucluoi(a)gmail.com> wrote: > >> How can I compile and run Maxima with ABCL? > > (1) Unpack a Maxima tarball. > http://sourceforge.net/projects/maxima and follow links to download page. > Look for "Maxima-source". > > (2) cd /path/to/maxima-5.27.0 > > (3) java -jar /path/to/abcl.jar > > (4) (configure) ;; you can probably accept defaults for most/all questions > > (5) (quit) > > (6) cd src > > (7) java -jar /path/to/abcl.jar > > (8) (require 'asdf) > > (9) (asdf:operate 'asdf:load-op :maxima) > > (10) (quit) > > (11) java -jar /path/to/abcl.jar > > (12) (require 'asdf) > > (13) (asdf:operate 'asdf:load-op :maxima) ;; yes, same as (9) > > (14) (cl-user::run) ;; should bring up Maxima banner & input prompt > > >> Furthermore can I emmbed maxima in a Java Programm with ABCL? > > Yes. I've appended an example program. Command line to compile it: > > javac -cp /path/to/abcl.jar -d /path/to/compiled/class abcl_maxima.java > > To execute it: (you must be in the Maxima src directory) > > java -cp /path/to/compiled/class:/path/to/abcl.jar abcl_maxima > > I get: (takes a minute or two to load Maxima) > > loading Maxima ... finished. > x.getClass => class org.armedbear.lisp.Cons > x = org.armedbear.lisp.Cons@1748ba8 > x.javaInstance => org.armedbear.lisp.Cons@1748ba8 > x.javaInstance.getClass => class org.armedbear.lisp.Cons > 4 factors of 12341234 > factor: 2, multiplicity: 1 > factor: 73, multiplicity: 1 > factor: 137, multiplicity: 1 > factor: 617, multiplicity: 1 > > > Note that all user functions have names which begin with dollar sign. > E.g. user function ifactors <==> $IFACTORS in Lisp > > If you need help with Lisp programming for Maxima, ask questions on the > mailing list. See: http://maxima.sourceforge.net/maximalist.html > > Hope this helps, have fun, & good luck. > > Robert Dodier > > PS. Example program abcl_maxima.java: > > // abcl_maxima.java -- example program for calling Maxima from Java via ABCL > // copyright 2012 by Robert Dodier > // I release this work under terms of the GNU General Public License > > import org.armedbear.lisp.Interpreter; > import org.armedbear.lisp.Package; > import org.armedbear.lisp.Packages; > import org.armedbear.lisp.Symbol; > import org.armedbear.lisp.Function; > import org.armedbear.lisp.LispObject; > import org.armedbear.lisp.Fixnum; > import org.armedbear.lisp.Bignum; > import org.armedbear.lisp.Cons; > > public class abcl_maxima > { > public static void main (String [] args) throws Exception > { > int a; > > if (args.length > 0) > a = Integer.parseInt (args [0]); > else > a = 12341234; > > Interpreter I = Interpreter.createInstance (); > System.out.print ("loading Maxima ... "); > I.eval ("(require 'asdf)"); > I.eval ("(asdf:operate 'asdf:load-op :maxima)"); > System.out.println ("finished."); > Package P = Packages.findPackage ("MAXIMA"); > > // java.util.List <Symbol> L = P.getAccessibleSymbols (); > // for (Symbol S : L) > // { > // if (P.equals (S.getPackage ())) > // System.out.println (S.toString ()); > // } > > Symbol S = P.findAccessibleSymbol ("$IFACTORS"); > Function F = (Function) S.getSymbolFunction (); > LispObject x = Bignum.getInstance (a); > x = F.execute (x); > System.out.println ("x.getClass => " + x.getClass ()); > System.out.println ("x = " + x); > System.out.println ("x.javaInstance => " + x.javaInstance ()); > System.out.println ("x.javaInstance.getClass => " + x.javaInstance () . getClass ()); > > int n = ((Cons) x).length (); > System.out.println ((n - 1) + " factors of " + a); > > for (int i = 1; i < n; i++) > { > Cons x1 = (Cons) ((Cons) x).NTH (i); > Fixnum f = (Fixnum) x1.NTH (1); > Fixnum m = (Fixnum) x1.NTH (2); > System.out.println ("factor: " + f.intValue () + ", multiplicity: " + m.intValue ()); > } > } > } > > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 16

[armedbear-devel] Does ABCL reload abcl.jar after it starts up?
by Marshall 21 Jun '12

21 Jun '12

I have a quick (I hope) question. Does ABCL reload abcl.jar after it starts up? Or do something else unusual with the jar once it's running? Context: I'm exploring using ABCL as an add-on to NetLogo, an agent-based modeling environment. (It might be more correct to say that I'm using NetLogo as an add-on to ABCL, since the primary code is in Lisp.) With the add-on method, NetLogo "extensions", one usually doesn't have to tell NetLogo where additional jars such as abcl.jar can be found. As long as they're in the extension's own directory, NetLogo will find the extra jars. This is apparently due to a little bit of voodoo that NetLogo engages in. However, in the case of my ABCL extension, NetLogo will load the extension, but then generate an error when I invoke ABCL via Interpreter.evaluate(). The problem is avoided if specify abcl.jar in the classpath explicitly, either on the command line (undesirable for NetLogo), or by adding abcl.jar to the classpath in Java (which works fine--so that's what I'm doing). Just curious about what ABCL is doing--thanks. (The ABCL NetLogo extension is very simple, now that I've figured out the details, and seems to be working beautifully, by the way. I'm surprised that there haven't been some glitches. It just works.) Marshall Abrams mabrams(a)uab.edu

2 1

[armedbear-devel] How to compile and run Maxima with ABCL?
by Phuc Luoi 19 Jun '12

19 Jun '12

Hello, How can I compile and run Maxima with ABCL? Furthermore can I emmbed maxima in a Java Programm with ABCL? Hong Phuc

2 1

[armedbear-devel] asdf 2.22 released
by Faré 13 Jun '12

13 Jun '12

I am pleased to announce the release of ASDF 2.22. Since previous release 2.21, the changes are as follow: * require is now mapped to the recently defined require-system, not to load-system anymore. * more sensible inheritance semantics for default-component-class, which can be either a class or a class name. (hat tip to Nikodemus) * accept wildcards in directory-files for physical pathnames. (hat tip to Erik Pearson). These changes are few and subtle, but nonetheless significant to those who'd use these features. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pyramid schemes are illegal. Social Security is a pyramid scheme.

2 1

[armedbear-devel] jfli-abcl revisited
by Alex Mizrahi 12 Jun '12

12 Jun '12

hi Some people mentioned that keeping jfli interface is desirable. Also I've noticed a problem with Ole's version: java array accessor (jref) doesn't do boxing correctly. It isn't a big deal, but I kinda used that functionality, and I have no idea what motivated those changes so I don't know to to fix them correctly. So I went back to original jfli-abcl version by Andras Simon and did minimal amount of changes to make it work with new version. Also there are several conservative improvements. Here it is: https://gist.github.com/2916760#file_jfli.lisp And here's a diff against jfli-abcl.lisp still available on Andras' site: https://gist.github.com/2916760#file_jfli_abcl.diff (This one: http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar ) Here's a description of changes: 1. make-immediate-object is deprecated now, so we use java:+null+ and friends 2. boxing extension by A. Vodonosov is described in comment 3. ensure-java-class was renamed to %ensure-java-class to avoid collision with java:ensure-java-class which does completely different thing. (I thought about shadowing it, but I think renaming makes it clearer.) 4. support for both int and long in overloads (or however they are called in Java) 5. new-class functionality was commented out because abcl-side interface have changed. (together with its helper jrc) As I understand, Alessio already reimplemented jnew-runtime-class, so we just need some brave soul to adapt code to new APi and implement missing parts This isn't particularly hard, I think, but I'm not interested in new-class at all, so I wouldn't do this. And for the sake of completeness here's diff between original jfli-abcl and Ole's version: https://gist.github.com/2916945 It seems that the major difference is "Ripped out CLOS mirror support". I have no idea if 'CLOS mirror support' is required according to jfli spec or it is useless. Also there is a lot of refactoring. Which is great, but it can break things... So again, unless somebody has resources to check Ole's changes and verify that they adhere to jfli documentation, I recommend replacing it with my 'conservative' version in ABCL's contrib repo. Also, I've noticed that jfli maintainer said it would be cool to merge different versions, but I don't think it's necessary: the only common part is defpackage, pretty much all the code is specific to ABCL. (This was true for old jfli version, at least.) So it's better to treat jfli as a specification rather than as a library.

2 1

[armedbear-devel] Figuring out the provenance of trunk
by Mark Evenson 11 Jun '12

11 Jun '12

Over the course of maintaining the Bear, it has become clear to me that we have pieces of code in trunk whose original licensing terms indicate that their author should be contacted as to their status, especially when they would conflict with the terms we distribute under, namely those of the GNU Public License. Recently I discovered such a licensing lacunae [in working with Jorge Tavares to patch the CL:SORT and CL:STABLE-SORT routines][1], that 'sort.lisp' contains code that has both SBCL and ECL code attributions. Are we in violation of anything here? Dunno. But we certainly have *lots* of SBCL tucked into our tree… We obviously need an estimate of our non-compliance. As a first step, it seems useful to construct/use a tool that allows us to establish provenance of all commits to ABCL trunk. With this history in hand, we can start figuring out the set of all authors to work through potential conflicts. A fair amount of work for a non-specialist, but anyone who does this regularly should have an analysis toolset lying around that they could apply to [ABCL trunk][2]. Is there a language lawyer geek in the house? [1]: http://trac.common-lisp.net/armedbear/ticket/196 [2]: https://code.google.com/p/abcl-dynamic-install/source/browse/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

3 3

[armedbear-devel] Patch to quicklisp/cffi-0.7.1 for abcl-1.1.0-dev
by Mark Evenson 30 May '12

30 May '12

Mebbe [this can help somewhat with the problems loading JNA automatically for CFFI on ABCL][1]. I still need to figure out exactly what is broken under which JVM/OS combinations. Interesting stuff in analyzing regressions. [1]: http://slack.net/~evenson/quicklisp/cffi-abcl-1.1.0-dev-20120530a.patch -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Is anybody interested in jfli-abcl?
by Alex Mizrahi 29 May '12

29 May '12

jfli-abcl, basically, allows one to quickly create Lisp function wrappers for Java classes. E.g. (def-java-class "java.sql.DriverManager") (use-package :|java.sql|) (DriverManager.getConnection ...) The benefit over java:jcall and JSS is that it looks more-or-less like normal Lisp function calls, pretty similar to a wrapper you could write yourself. Also, potentially, it might carry less runtime overhead because everything can be resolved at compile-time. And if you use SLIME, auto-completion works. It doesn't like mixed case, though, so you need to write it like (|java.sql|:drivermanager.getcollection ...) Still, better than nothing. As far as I can tell, jfli-abcl isn't currently maintained. But as I'm used to jfli-abcl I maintain my own version with some fixes. If there is any interest in jfli-abcl I could, perhaps,. publish my version and polish it a bit. (I'm personally not interested in new-class functionality which allows one to create Java class from Lisp.) (I've found this updated version: https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/… But haven't yet checked if it works with latest ABCL and what are improvements against old one.)

6 11

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

[forwarding Alessio's reply to the list - was my mistake to send the previous letter to him directly, instead of Reply All] ----------------------------------------------------------------------------------------------------- 28.05.2012, 17:25, "Alessio Stalla" <alessiostalla(a)gmail.com>: On Mon, May 28, 2012 at 3:18 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > 28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: >> On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>>> If independent version of new-class is not ready, probably it's possible to >>>> deliver runtime-class a a contrib [...] >>> I've checked the ABCL sources and see that runtime-class.lisp is now >>> included into ABCL. So we don't even need to create a contrib for it. >>> >>> Could anyone help me understand the problem with new-class, why removing >>> it? Namely, when the asm.jar will be needed, >>> >>> What I understand now: >>> >>> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >>> 2. java:jnew-runtime-class needs asm.jar. >> 2. is wrong. jnew-runtime-class used to require asm, was disabled, and >> was reintroduced (incomplete) without a dependency to asm and with a >> slightly different API. In other words, jrc right now is probably >> broken. >> >> To restore jrc right now, you'd need to restore runtime-class.lisp >> from version control, and bundle it in contrib under a different >> package (assuming it still works with present-day asm). > Ah I see, it's different runtime-class. Thanks for the explanation. >> That would be possible, but I object that having 2 different APIs for >> the same thing is a potential source for confusion. > Yes, but it's also the way of software evolution: we use some API, > notice it's deficiencies, deprecate it and introduce new, better > API. Let me note that it could have been called runtime-class2 > to avoid confusion and compatibility issues. Yes, maybe it could, but the situation as I saw it was that runtime-class was effectively dead code nobody was using (and in fact, until now nobody asked about it on this list). > Probably now, if packaging the old runtime-class as a contrib, we will > need to rename it to old-runtime-class, or even deprecated-runtime-class. Or just deprecated:runtime-class, or backwards-compatibility:..., so you can shadowing-import-from it and forget about it. > Could you explain about the asm.jar dependency in case of the > deprecated-runtime-class? Would it be a load-time dependency, > or a call-time dependency? IIRC, it is a call-time dependency, but note that I never used the old runtime-class, so I may be wrong. Alessio -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

1 1

[armedbear-devel] Fwd: Is anybody interested in jfli-abcl?
by Anton Vodonosov 28 May '12

28 May '12

28.05.2012, 17:08, "Alessio Stalla" <alessiostalla(a)gmail.com>: > On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >> 28.05.2012, 16:22, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>> If independent version of new-class is not ready, probably it's possible to >>> deliver runtime-class a a contrib [...] >> I've checked the ABCL sources and see that runtime-class.lisp is now >> included into ABCL. So we don't even need to create a contrib for it. >> >> Could anyone help me understand the problem with new-class, why removing >> it? Namely, when the asm.jar will be needed, >> >> What I understand now: >> >> 1. abcl-jfli function jrc calls java:jnew-runtime-class. >> 2. java:jnew-runtime-class needs asm.jar. > 2. is wrong. jnew-runtime-class used to require asm, was disabled, and > was reintroduced (incomplete) without a dependency to asm and with a > slightly different API. In other words, jrc right now is probably > broken. > > To restore jrc right now, you'd need to restore runtime-class.lisp > from version control, and bundle it in contrib under a different > package (assuming it still works with present-day asm). Ah I see, it's different runtime-class. Thanks for the explanation. > That would be possible, but I object that having 2 different APIs for > the same thing is a potential source for confusion. Yes, but it's also the way of software evolution: we use some API, notice it's deficiencies, deprecate it and introduce new, better API. Let me note that it could have been called runtime-class2 to avoid confusion and compatibility issues. Probably now, if packaging the old runtime-class as a contrib, we will need to rename it to old-runtime-class, or even deprecated-runtime-class. Could you explain about the asm.jar dependency in case of the deprecated-runtime-class? Would it be a load-time dependency, or a call-time dependency? Best regards, - Anton

1 0

[armedbear-devel] abcl trunk build doesn't work for me
by Alex Mizrahi 27 May '12

27 May '12

hi When I run ABCL built from trunk I get this error when I run it: ---- Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_21 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.072 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.Lisp.error(Lisp.java:380) at org.armedbear.lisp.Load.loadSystemFile(Load.java:276) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:703) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) at org.armedbear.lisp.Lisp.eval(Lisp.java:515) at org.armedbear.lisp.Load.loadStream(Load.java:570) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:538) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:428) at org.armedbear.lisp.Load.loadSystemFile(Load.java:327) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:679) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads' in boot classpath. ---- I tried both version from SVN and from Mark's (?) hg repo, upgraded OpenJDK to 1.6.0_21, upgraded ant from 1.7.1 to 1.8.0 (that's top version I can get via package manager for Ubuntu 10.04). I was able to build and run ABCL 1.0.1. I noticed a bug on abcl 1.0.1: in certain rather contrived code return-from was ignored, i.e. evaluation continued as if it wasn't called. And was going to check whether it's present in the latest devel version before investigating it further.

4 7

[armedbear-devel] Connection to database via JDBC and classpath
by Francisco Vides Fernández 24 May '12

24 May '12

Hello everyone I intend to use ABCL in one of my projects. I've started to connectiing to a postgresq database via jdbc. I've tried something like: -------8<------- (add-to-classpath (merge-pathnames #p".m2/repository/postgresql/postgresql/8.4-702.jdbc4/postgresql-8.4-702.jdbc4.jar" (user-homedir-pathname))) (jstatic "forName" "java.lang.Class" "org.postgresql.Driver") -------8<------- But it always returns -------8<------- Java exception 'java.lang.ClassNotFoundException: org.postgresql.Driver'. [Condition of type JAVA-EXCEPTION] -------8<------- The jar file exists, and has the proper class inside. I've read the manual, and googled a bit, but still get the same error. I'm using Ubuntu Linux, with OpenJDK 1.6.0_24, and the latest and greatest ABCL downloaded as a binary from ABCL website. Can someone point me what I'm doing wrong? Many thanks for this great project!! -- +----------------- | Francisco Vides Fernández <fvides(a)neoclinic.es> | Director Ejecutivo | Teléfono fijo: 952 60 29 59 | Fax: 952 60 29 59 | Neoclinic http://www.neoclinic.es/ +------

6 13

[armedbear-devel] ABCL has an incorrect belief about hostname and cpu in its fasl storage
by Paul Nathan 18 May '12

18 May '12

Dear all, I installed Armed Bear Common Lisp 1.0.1-svn-13750-13751 in order to run it on my OSX 10.6 (Snow Leopard) 64-bit system (Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64), for the purpose of executing cl-test-grid. However, I observed that the fasls were being stored in ~/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86 You will quickly note that my system is neither solaris nor x86. However, I checked some of the environment settings: java -jar abcl.jar Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.6.0_31 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.619 seconds. Startup completed in 1.511 seconds. Type ":help" for a list of available commands. CL-USER(1): *features* (:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :DARWIN :CDR6) CL-USER(2): (machine-instance) "elendil.local" CL-USER(3): (machine-type) "X86_64" CL-USER(4): (software-type) "Mac OS X" CL-USER(5): (software-version) "10.6.8" CL-USER(6): (machine-version) NIL And they turn out correct. I am not a regular ABCL user, so pardon me if this is already known. If an OSX Snow Leopard system is not available for testing, I volunteer my time and machine to test a patch. Regards, Paul Nathan

2 2

[armedbear-devel] One (probably) stupid question
by Francisco Vides Fernández 18 May '12

18 May '12

I'm aware that this must be a stupid question, but after googling for a while can't find the right answer: How can I invoke a method with a boolean as an argument. I try to do the following: ---8<--- (let* ((jlclass (jclass "java.lang.Class")) (for-name (jmethod jlclass "forName" (jclass "java.lang.String") (jclass "boolean") (jclass "java.lang.ClassLoader")))) (jstatic for-name jlclass "org.postgresql.Driver" t (get-current-classloader))) ---8<--- But it raises the error: The value T is not of class boolean [Condition of type ERROR] I tried replacing '(jclass "boolean") for '(jclass "java.lang.Boolean"), but in that case it doesn't find the for-name method. How am I supposed to invoke the method! Thanks in advance! -- +----------------- | Francisco Vides Fernández <fvides(a)dedaloingenieros.com> | Gerente | Teléfono fijo: 952 60 29 59 | Fax: 952 60 29 59 | igaleno http://www.igaleno.com/ +------

2 1

[armedbear-devel] sockets in CLISP
by Santiago Carbonell 18 May '12

18 May '12

Hi, I'm trying to send some strings using the format function in LISP to a sockets but always I obtain NIL I'm using this function: (defun sockets_fun() (WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 49729 "localhost")) (let ((*standard-output* socket)) (format socket "The color is ~A" "red") (force-output socket) (finish-output nil) ))) But always I obtain NIL in the socket Instead of that function I've tried to use this another function: (defun geetings() (print "hi")) and works fine, appears hi in the socket Why there are problems with sockets with the format function? Thanks

2 1

[armedbear-devel] JSS issues: bug in jss::with-constant-signature, jss::invoke-find-method?
by Jonathan P. Bona 16 May '12

16 May '12

I'm working with Alan Ruttenberg to port LSW from the old version of JSS to the JSS that is now part of abcl-contrib. We've run into the following bug when using with-constant-signature: ; these first two work fine: (#"substring" "some string" 2 4) ; "me" (#"substring" "some string" 2) ; "me string" ; and so does this (with-constant-signature ((substring "substring")) (substring "some string" 2 4)) ; "me" ; but this breaks: (with-constant-signature ((substring "substring")) (substring "some string" 2)) ; Wrong number of arguments for public java.lang.String java.lang.String.substring(int,int): expected 2, got 1 ; [Condition of type PROGRAM-ERROR] A problem seems to be in jss::invoke-find-method, which is finding the two argument version of java.lang.String.substring no matter how many arguments its given: (jss::invoke-find-method "substring" "this is a string" '(1)) ; should return the java.lang.String.substring method with one int arg ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2) ) ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6 7 8) ) ; should be an error ; #<method public java.lang.String java.lang.String.substring(int,int)> - Jonathan Bona

3 5

[armedbear-devel] how to redirect format function to a socket stream
by Santiago Carbonell 13 May '12

13 May '12

Hi, I've a socket stream named "socket" in this port and host: 50362 and localhost I've written this function to redirect format function to the socket but only appears NIL. How can I redirect format t lisp function to a socket? (defun colors() (WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 50362 "localhost")) (let ((*standard-output* socket)) (format t "The color is ~A" "red") ))) Thanks

2 1

[armedbear-devel] Error building abcl-servet
by aditya siram 09 May '12

09 May '12

Hi all, I am trying to build abcl-servlet and running into the following error: > ant -find build.xml dist -Dlibs.CopyLibs.classpath=/home/deech/Java/netbeans/java/ant/extra/org-netbeans-modules-java-j2seproject-copylibstask.jar ... /home/deech/Lisp/abcl-servlet/build.xml:36: org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: #<MISSING-COMPONENT {98F805}> at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:568) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.debug_6.execute(debug.lisp:105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:808) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.debug_7.execute(debug.lisp:114) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:808) at org.armedbear.lisp.LispThread.execute(LispThread.java:683) at org.armedbear.lisp.asdf_250.execute(asdf.lisp:1692) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_249.execute(asdf.lisp:1692) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_248.execute(asdf.lisp:1692) at org.armedbear.lisp.clos_297.execute(clos.lisp:2120) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_239.execute(asdf.lisp:1623) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_238.execute(asdf.lisp:1623) at org.armedbear.lisp.clos_297.execute(clos.lisp:2120) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_244.execute(clos.lisp:1381) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_247.execute(clos.lisp:1400) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_493.execute(asdf.lisp:2565) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.asdf_492.execute(asdf.lisp:2565) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.asdf_491.execute(asdf.lisp:2565) at org.armedbear.lisp.clos_295.execute(clos.lisp:2016) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.clos_282.execute(clos.lisp:1934) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.clos_275.execute(clos.lisp:1768) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_244.execute(clos.lisp:1381) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.clos_247.execute(clos.lisp:1400) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:796) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2842) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:820) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.asdf_497.execute(asdf.lisp:2625) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_eval_when.execute(Primitives.java:3874) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Load.loadStream(Load.java:567) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:535) at org.armedbear.lisp.Load.load(Load.java:670) at org.armedbear.lisp.Load$_load_returning_last_result.execute(Load.java:648) at org.armedbear.lisp.Symbol.execute(Symbol.java:820) at org.armedbear.lisp.LispThread.execute(LispThread.java:701) at org.armedbear.lisp.load_2.execute(load.lisp:46) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Primitives$sf_multiple_value_prog1.execute(Primitives.java:3969) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Primitives$sf_unwind_protect.execute(Primitives.java:3840) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) 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:503) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.eval(Lisp.java:511) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:146) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) 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:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) 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:503) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:513) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) 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:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:503) at org.armedbear.lisp.Lisp.progn(Lisp.java:682) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:561) at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:234) at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:243) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) My ABCL version is 1.0.1. -deech

2 3

[armedbear-devel] Patch with improvements to stable-sort and sort
by Jorge Tavares 07 May '12

07 May '12

Hi, I send in attach a patch with further improvements to sort and stable-sort for sequences other than lists. In short, the patch includes a merge sort for vectors. To allow different types I've written the algorithm using macros and these generate the appropriate code according to the vector type. This way the algorithm is in a single place avoiding duplication of code. The macros also take care of the situation of when no key is present, avoiding the use of unnecessary funcalls. The quicksort algorithm was also refactored in the same way. I've tested the algorithms and they seem to be working correct. Stable sort is now considerably faster since the fix before converted the sequences to a list and used the sort-list function. I've made some benchmarking to verify how fast is sort and stable-sort. The tables with the results are also in a file sent in attach [1]. For stable-sort I've compare the current trunk version with the patched one while for sort I've compared 1.0.1, the trunk and with the patch. For unsorted vectors sort has a speed up of 7.5 from 1.0.1 and this considers only vectors of size 8 to 8192 (1.0.1 hits the worst-case quite fast). For stable-sort the speed up is around 90.2 from vectors of size 8 to 32768. The sort functions become even faster for the nearly sorted vectors. I think the tables clearly show the speed-ups :-) Naturally these benchmarks cannot be used to draw definite conclusions since they lack rigorous testing but I think they can provide some indications. With this patch, I think ABCL gets good performant sorting functions, especially for large vectors. As for lists, I haven't looked at them so probably they can also be improved (but I really don't know). Cheers, Jorge [1] The tables result from the generation of simple-vectors of sizes 8 to 524288 (powers of 2 from 3 to 19) with distinct integer: unsorted, nearly sorted (distances 0, 4 and 16), sorted and reversed sorted. The nearly sorted vectors were constructed by selecting pairs where they would swap with a neighbor at a certain distance. I did 100 runs and timed only the sorting operation. The tables contain the averages of the 100 runs. They were performed in an iMac (2.5GHz i5, 4GB) with Mac OS X 10.7.3. -- http://jorgetavares.com

2 2

[armedbear-devel] *load-pathname* with incorrect value
by wl chiu 06 May '12

06 May '12

Hi again, I have a file: ---- load-pathname.lisp ----- (print *load-pathname*) ----------------------------- When loaded, I get this: java.exe -cp "abcl.jar" org.armedbear.lisp.Main --load load-path.lisp==> #P"load-path.lisp" According to CLHS, I believe this is wrong? During a call to load, *load-pathname* is bound to the pathname denoted by the the first argument to load, merged against the defaults; that is, it is bound to (pathname (merge-pathnames filespec)). During the same time Cheers, Wei-Lun Chiu

2 1

[armedbear-devel] asdf 2.21 released
by Faré 30 Apr '12

30 Apr '12

I am pleased to announce the release of ASDF 2.21. Since previous release 2.20, the changes are as follow: * New features: * Most importantly, encodings. ASDF now lets you specify an :encoding for a system, module or component, that is used when loading or compiling Lisp files. See the documentation. By default, the only useful value is :utf-8, and we recommend you use UTF-8 everywhere. We intend to make UTF-8 the default in the future (current default is the legacy behavior of using whichever implicit default your underlying implementation is currently configured to use). An extension asdf-encodings is available that supports more encodings, including autodetection of encoding from either emacs-style declaration -*- Mode: Lisp ; coding: utf-8 -*- or content. * require-system works like load-system, but won't try to load or update systems that have already been loaded, as listed by loaded-systems. More generally, you can specify a list of systems as :force-not argument to load-system and the specified systems won't be loaded or updated. * You can specify :force-not and a list of systems when loading a system, * You can now specify :hostname in your asdf-output-translations, so you can easily share a home directory via the network yet split its fasl cache between several subtly different machines. * Bug Fixes: * lp#982285. since 2.014.4, the default source-registry was skipping anything from /usr or XDG_DATA_DIRS, because of a missing test in getenv-absolute-pathnames. Fixed in .15. * In 2.019.9 aka 2.20, ECL support was broken by using a function in the wrong package (defined in cl-user). Fixed in .1. * logical-pathname support was somewhat broken since 2.017.6, due to the way most implementations fail to read physical namestrings when *default-pathname-defaults* is a logical-pathname. Fixed, together with other logical-pathname issues, and a test case was added to the test suite to ensure no further regression. Works great modulo quirks around implementation bugs on CLISP and Allegro. * Make upgrading ASDF more robust on CMUCL, LispWorks, SBCL. * Minor tweaks: * Use :unspecific in pathname components on more implementations. * export and/or document more utilities. * add a few missing compatfmt for Genera. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A single flaw in someone else's beliefs, they are discredited. Repeated obvious flaws in your own, you keep the blind faith. Government saves!

2 1

[armedbear-devel] Package redefinition issue in REPL.
by wl chiu 28 Apr '12

28 Apr '12

Hello dear developers, I' just experienced an odd issue with defpackage. It looked like the package will not be modified if I call defpackage again. For example, I define a package called "a-package". After a while I wanted to export a function that I've just implemented called "a-new-foo". Naturally I would add a new entry under the :export section of defpackage, and then eval the expression again. However, I still cannot access "a-new-foo" as the REPL gives me "such symbol is not external of package [a-package]" error message. Please advice and many thanks, Wei-Lun Chiu

4 4

[armedbear-devel] Funny behavior about flet after compilation.
by wl chiu 25 Apr '12

25 Apr '12

Hi dear devs, I encountered some funny behaviour between compiled and interpretedcode with flet. I'm not sure if this is a duplicate bug? -------- flet-bug.lisp -------------- (defun foo (x) (print x)) (defun test1 () (flet ((foo1 () (foo 3))) (foo1))) (defun test2 () (flet ((foo () (foo 3))) (foo))) ------------------------------------ We compile the following file, (compile-file "c:/me/temp/flet-bug.lisp") ; Compiling C:/me/temp/flet-bug.lisp ... ; (DEFUN FOO ...) ; (DEFUN TEST1 ...) ; (DEFUN TEST2 ...) ; Wrote c:/me/temp/flet-bug.abcl (2.62 seconds) Then either load it interpreted or compiled. Interpreted, everything'sfine: > (load "c:/me/temp/flet-bug.lisp") T > (test1) 3 3 > (test2) 3 3 Compiled, we get an error in test2: > (load "c:/me/temp/flet-bug.abcl") T > (test1) 3 3 > (test2) ; Evaluation aborted on #<PROGRAM-ERROR {797E7B}>. The stack trace for this is: Wrong number of arguments for #<FOO {CCA5B9}>. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {490A12}> #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>) 1: (APPLY #<FUNCTION {490A12}> (#<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {19430CA}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:381) 5: org.armedbear.lisp.Function.execute(Function.java:312) 6: org.armedbear.lisp.Primitive.execute(Primitive.java:113) 7: (FOO 3) 8: (TEST2) 9: (SYSTEM::%EVAL (TEST2)) 10: (EVAL (TEST2)) 11: (SWANK::EVAL-REGION "(test2) ") ... etc ... Thanks for your attention, Wei-Lun Chiu

1 0

[armedbear-devel] SLIME reconnection on ABCL 1.1.0-dev fails
by aditya siram 24 Apr '12

24 Apr '12

Hi all, If I connect to a repl with M-x slime , disconnect using M-x slime-quit-lisp and reconnect it loads the fasls and then fails with: WARNING: #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR Maximum error depth exceeded (11 nested errors). CL-USER(2): CL-USER(2): The prompt "CL-USER(2)" works but emacs stays locked with a "Polling "/tmp/slime.2616".. (Abort with `M-x slime-abort-connection'.)" One possible indication of the problem is that there is no file /tmp/slime.2616. If I delete the fasls and start slime, it re-compiles them all and starts fine. This does not happen with abcl-1.0.1. Thanks! -deech

4 11

[armedbear-devel] asdf encodings and abcl
by Faré 18 Apr '12

18 Apr '12

Dear ABCL developers, I'm currently adding source file encoding support to ASDF. It will hopefully be part of ASDF 2.21, though the plan is that anything but :utf-8 and :default requires an extension :asdf-encodings. I didn't find any way with ABCL to detect the list of external formats, or to determine is a given keyword is an acceptable name for an external format. How do I do that? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If there's a book you really want to read but it hasn't been written yet, then you must write it. — Toni Morrison [same with software, —♯f]

2 7

[armedbear-devel] Bug in abcl/contrib/jss/invoke.lisp - trying to call JScheme's jsint.Invoke.poke, jsint.Invoke.pokeStatic
by Jonathan P. Bona 11 Apr '12

11 Apr '12

An issue in invoke.lisp (below): set-java-field calls the poke and pokeStatic methods from jscheme's jsint.Invoke class. This should be replaced, right? ;;; http://svn.common-lisp.net/armedbear/tags/1.0.1/abcl/contrib/jss/invoke.lisp (defun set-java-field (object field value &optional (try-harder *running-in-osgi*)) (if try-harder (let* ((class (if (symbolp object) (setq object (find-java-class object)) (if (equal "java.lang.Class" (jclass-name (jobject-class object)) ) object (jobject-class object)))) (jfield (if (java-object-p field) field (find field (#"getDeclaredFields" class) :key 'jfield-name :test 'equal)))) (#"setAccessible" jfield t) (values (#"set" jfield object value) jfield)) (if (symbolp object) (let ((class (find-java-class object))) (#"pokeStatic" 'invoke class field value)) (#"poke" 'invoke object field value)))) - Jonathan Bona

3 2

[armedbear-devel] Cannot get abcl 1.0.1 working with slime
by Arnaud Bailly 06 Apr '12

06 Apr '12

Hello, I am trying to use ABCL 1.0.1 with slime under emacs and get the following errors: (progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "/tmp/slime.3985" :coding-system "iso-latin-1-unix")) Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.297 seconds. Startup completed in 0.935 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ... Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at line 143 (offset 5611) #<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of type READER-ERROR The package "ASDF" can't be found. Restarts: 0: TOP-LEVEL Return to top level. [1] SWANK-LOADER(2): Here is my .emacs: (add-to-list 'load-path "/usr/share/emacs/site-lisp/slime") ;;(setq inferior-lisp-program "/usr/local/bin/sbcl") (setq inferior-lisp-program "java -cp /home/arnaud/soft/abcl-bin-1.0.1/abcl-contrib.jar -jar /home/arnaud/soft/abcl-bin-1.0.1/abcl.jar") ;; from http://functionalrants.wordpress.com/2008/09/06/how-to-set-up-emacs-slime-s… (require 'slime) (slime-setup '(slime-fancy)) Help greatly appreciated. Thanks Arnaud

3 3

[armedbear-devel] Calling java from lisp
by Arnaud Bailly 06 Apr '12

06 Apr '12

Hello (again), I am trying to invoke java code from lisp code following http://common-lisp.net/project/armedbear/doc/abcl-user.html. Here is the code I am trying to run: CL-USER> (defun java-format (fmtstring &rest args) (let* ((string-class (jclass "java.lang.String")) (array-of-objs (jclass "[Ljava.lang.Object;")) (method (jmethod string-class "format" string-class array-of-objs))) (jcall method fmtstring args))) JAVA-FORMAT And here is what I got when I try to run it: > (java-format "" "%d %08.d %s" 1 2 3) Wrong number of arguments for public static java.lang.String java.lang.String.format(java.lang.String,java.lang.Object[]): expected 2, got 1 [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {53C470B}> #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>) 1: (APPLY #<FUNCTION {53C470B}> (#<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {76F2D004}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:381) 5: org.armedbear.lisp.Java.jcall(Java.java:880) 6: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:755) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 8: (JCALL #<java.lang.reflect.Method public static java.lang.String j.... {451CF2D}> "" ("%d %08.d %s" 1 2 3)) 9: (JAVA-FORMAT "" "%d %08.d %s" 1 2 3) 10: (SYSTEM::%EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3)) 11: (EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3)) --more-- What am I doing wrong ? Arnaud

2 2

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 31 Mar '12

31 Mar '12

On 29 March 2012 17:15, Rudolf Schlatte <rudi(a)ifi.uio.no> wrote: > asdf doesn't use run-program for abcl, just run-shell-command. But I see your point about API changes, especially for a non-major release. I guess right now we're bike-shedding. Let's hear what Pascal prefers, but I'm leaning towards your version as well at the moment. I'm not hell-bent on it, just wanted to point that out since I did consider that even though my patch doesn't mention such considerations. Ville-code is sometimes like that, it's well thought-out and minimal, modify anything and things break (for certain values of "break"), but I'm not the best user of explanatory comments on the planet. :)

1 1

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 29 Mar '12

29 Mar '12

Forwarding my reply to the list too. :) On 29 March 2012 16:55, Ville Voutilainen <ville.voutilainen(a)gmail.com> wrote: > On 29 March 2012 16:41, Rudi Schlatte <rudi(a)ifi.uio.no> wrote: >> Ville Voutilainen <ville.voutilainen(a)gmail.com> writes: >>> Here's a tentative patch. I opted for a new keyword argument, since >>> the new function approach would've led to duplication or to a macro >>> that has the new argument anyway. Untested so far, so this is for >>> general review. Also lacking the docstring changes. >> Here's my version, using your getenv and process-builder changes. I >> get by with only the :environment key, see the docstring for an example >> on how to overwrite PATH and keep the rest. Lightly tested. > > Looks reasonable. Some questions though: > >> -(defun run-program (program args &key environment (wait t)) >> +(defun run-program (program args &key (environment nil environment-p) (wait t)) > > Ah, yes, this works too, no need for a separate clear-env. But, does > this change the > semantics? Our previous code did an environment-merge if an > environment is supplied. > This one will clear and insert, and requires using getenv-all if you > want to replace > only some parts. I don't want to do such a semantics change. By > avoiding the semantics > change, I don't need to worry about breaking asdf. > > For that point, I'm still biased towards the clear-env keyword arg > approach. In that > approach, getenv-all is just an utility function that you can use if > you want to do > weird-complex environment processing, but possibly the most common use cases are > still "replace a couple of values by providing an environment without > clearing" and > "run in a very restricted environment with only a handful of > variables", neither of > which requires the use of getenv-all. > > Comments?

1 0

Re: [armedbear-devel] run-program :environment nil
by Rudi Schlatte 29 Mar '12

29 Mar '12

[Originally sent to Ville only because of a disagreement between Gnus and me]

1 0

[armedbear-devel] run-program :environment nil
by Pascal J. Bourguignon 29 Mar '12

29 Mar '12

(lisp-implementation-version) --> "1.0.1" The documentation of extensions:run-program is misleading: :environment An alist of STRINGs (name . value) describing the new environment. The default is to copy the environment of the current process. The alist doesn't describe the NEW environment, it is only MERGED into the current environment. Now of course, I consider the current behavior to be a bug: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash" …) I would expect: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> () and: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment '(("LC_CTYPE" . "C"))))) --> ("LC_CTYPE=C")) Which would match what the documentation says. Also, in a shell environment, an empty variable is not the same as an inexistant variable, so I cannot just loop over all the existing variables to set them to an empty string. I see no SYSTEM::%PROCESS-BUILDER-ENV-REM function… -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

4 8

[armedbear-devel] ABCL on jdk-1.7.0_03
by Mark Evenson 21 Mar '12

21 Mar '12

I've just run abcl-1.1.0-dev the ANSI-COMPILED tests on jdk-1.7.0_03 with reasonable looking results of 31 failures, which is roughly the same number as those run with jdk-1.6.0_31 (some of the tests use randomly generated data so they sometimes either fail or succeed). Previously, I think that we weren't even completing the ANSI-COMPILED test suite due to issues in the character set encoding, so I think we should now more fully endorse running ABCL on Java7.

1 0

[armedbear-devel] compiled errors: debug.assertTrue()
by scarbonell＠ono.com 06 Mar '12

06 Mar '12

Hi, When I try to compile the mcs-core.cl file (attached) with java abcl, I get this error: Failed to get InputStream for 'jar:file:D:/otro/kernel/modules/fmcs.bin!/mcs_core_4.cls'ABCL Debug.assertTrue() assertion failed!java.lang.Error: ABCL Debug.assertTrue() assertion failed! Why is this happening? How can I resolved it? Thanks

3 3

[armedbear-devel] compiling lisp files outside Java and calling it after with abcl
by scarbonell＠ono.com 02 Mar '12

02 Mar '12

Hi,I'm trying to compile a lisp application and I get a lot of errors with java abcl. I thought that if I try to compile this lisp files outside of abcl with other systems, perhaps, I could then call this compiled functions lisp files from ABCL (look like a jar file of lisp compiled files). Is this possible?How can I compiled this files outside ABCL? Some examples?Thanks

5 10

[armedbear-devel] Upcoming abcl-1.1 branch
by Mark Evenson 25 Feb '12

25 Feb '12

On [#abcl]() yesterday, ehu and easye discussed how it would be a good idea to start packing up for shipping abcl-1.1 out the door. [#abcl]: http://webchat.freenode.net/?randomnick=1&channels=abcl&prompt=1&uio=d4 Out of our brief discussion, we'd like to branch the trunk in about a week, stabilize with testing, and then release abcl-1.1.0 on 14-FEB-2012. So, unless there are objections, we'd like to start by asking everyone who was thinking of patching something, to think about getting some time in the next week to get something done. All potential contributions are welcome. If you were going to document something, now's the time! [Rudi added real BibTex-based markup to the Manual][1], so even something as trivial as fixing the references would be appreciated. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=5c7faeeb35408… yers in CONS, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Patch for ABCL to dynamically load CFFI JNA requirement
by Mark Evenson 24 Feb '12

24 Feb '12

Please consider the referenced patch for inclusion in cffi-0.10.7. Comments towards improvments solicited. Improvements to ABCL CFFI implementation: o autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev) o initial implementation of callbacks Needs ABCL specific tests, but I can load CL+SSL with this patch. [1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff Cheers, easyE -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] 김영태님이 Abcl님을 Facebook으로 초대하셨습니다
by Young Tae Kim 05 Feb '12

05 Feb '12

안녕하세요, Abcl님! 내 사진, 동영상, 이벤트를 게시할 수 있는 Facebook 프로필을 만들었습니다. 귀하가 저의 프로필을 볼 수 있도록 친구로 추가하고 싶습니다. 그러려면 먼저 귀하가 Facebook에 가입해야 합니다! 회원으로 가입하면 귀하도 프로필을 만들 수 있습니다. 고맙습니다! Young Tae Facebook에 가입하려면 아래 링크를 클릭하세요. http://www.facebook.com/p.php?i=100003305725765&k=AQCtufVGAiIaS35gg9kHoIHhT… 이미 계정을 갖고 계신가요? 계정에 이 이메일 주소를 추가하세요. http://www.facebook.com/n/?merge_accounts.php&e=armedbear-devel%40common-li… ======================================= 메시지가 armedbear-devel(a)common-lisp.xn--net()-7s4ut57e 전송되었습니다. 앞으로 이러한 이메일을 그만 받으려면 아래의 링크를 눌러서 수신을 거부해 주세요. http://www.facebook.com/o.php?k=a23045&u=100003558065807&mid=5989382G5af3e4… Facebook, Inc. Attention: Department 415 P.O Box 10005 Palo Alto CA 94303

1 0

[armedbear-devel] Patch that fixes ticket #187 (Stack Overflow for Worst-case Vector Sort)
by Jorge Tavares 05 Feb '12

05 Feb '12

Hi, I'm sending a patch that solves the issue reported in ticket #187. The quicksort function picks the pivot by selecting a midpoint and also sorts the smaller partition first. These are enough to avoid the stack overflow problem as reported. I've performed some tests and it looks it is correct. Below I include a sample session, including the test case in the ticket: idesk:abcl jast$ ./abcl Armed Bear Common Lisp 1.1.0-dev-svn-13848M Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.307 seconds. Startup completed in 0.945 seconds. Loading /Users/jast/.abclrc completed in 4.528 seconds. Type ":help" for a list of available commands. CL-USER(1): (ql:quickload "alexandria") To load "alexandria": Load 1 ASDF system: alexandria ; Loading "alexandria" ("alexandria") CL-USER(2): (defparameter *sorted* (make-array 1000000 :initial-contents (alexandria:iota 1000000))) *SORTED* CL-USER(3): (defparameter *numbers* (alexandria:shuffle (copy-seq *sorted*))) *NUMBERS* CL-USER(4): (equalp *sorted* *numbers*) NIL CL-USER(5): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 2.157 seconds real time 3 cons cells NIL CL-USER(6): (equalp *sorted* *numbers*) T CL-USER(7): (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) NIL CL-USER(8): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 1.074 seconds real time 3 cons cells NIL CL-USER(9): With these changes, sort seems to be a little faster (for vectors) although I was not worried with optimizations. In ABCL 1.0.1, in my machine, sorting 1000000 random integers takes around 10s on average while now it takes 2s. However, I must point out I didn't do any serious and proper benchmarking, just some runs. I will be happy to answer any questions if necessary. Cheers, Jorge Tavares -- http://jorgetavares.com

2 2

[armedbear-devel] Java Collections, ABCL, and you
by Alessio Stalla 04 Feb '12

04 Feb '12

Hello list, I'd like to talk a bit about our Java Collections API integration, and especially a topic that has been lumbering in my mind for quite a lot of time and which has been raised today by Rudi Schlatte on #abcl. Warning: the mail turned out to be quite long. As you probably know, some time ago I added to ABCL an implementation of Christophe Rhodes' extensible sequences proposal[1], until then only implemented in SBCL (as far as I know). It's not loaded by default, but you can get it with (require :extensible-sequences). Some time later I used that API to integrate ABCL with the Java Collections framework, so that (certain) Java collections are Lisp SEQUENCEs. Again, to get it you need to (require :java-collections). However, there are, I think, two interesting limitations in the ext. seq. protocol, which I'm going to discuss. Since it was designed as an extension to CL's sequences, the protocol builds directly upon the concept of CL sequences (lists and vectors) - and in particular it assumes sequences are ordered (accessible by index) and mutable. The only basic operations one must absolutely define to provide a custom sequence implementation are ELT, (SETF ELT), and LENGTH; anything else is defined by default upon those operations, albeit inefficiently. That concept of sequences roughly matches that of Java Lists (except the fact that mutability of Lists is optional). List is a subtype of Collection which implies ordering and access by index. Collection is basically an Iterable thing with a length and optional mutability (in the form of adding elements to the end and removing elements destructively). The concept of a Collection or better an Iterable is missing from the extensible sequences protocol, although it provides an iterator sub-protocol. This makes it unsuitable for those kinds of sequences that do not fully respect CL's definition of sequence (e.g. because they are not mutable of because they can only be iterated once and not accessed by index, like a stream), but that would nevertheless benefit from adhering at least in part to the sequence protocol (because then you might LOOP or, shameless plug, DO+ over them, for example). That would also allow to expose arbitrary Java Collections, and not just Lists, as Lisp sequences - including thus Sets and various specialized Collection types. So the first point is: I'd like to extend the protocol with the concept of an Iterable. How? Ideally, Iterable would be a more basic concept than Sequence, but we cannot modify the class hierarchy of SEQUENCE because it's defined by the standard. So, either ITERABLE must be completely disjoint from SEQUENCE, or it must be a subtype of it. Of the two, I favor the latter, because many sequence operations are supposed to signal errors in case their argument is not a proper sequence, and deviating from that would probably constitute a violation of the standard. So I would define an Iterable as a special SEQUENCE that is defined in terms of an iterator; by default ELT, (SETF ELT) and LENGTH create a new iterator and, very inefficiently, use it to walk the Iterable and do their work. Of course specialized, more efficient implementations are possible. Java Collections would be Iterables, and Java Lists would retain their specialized implementation of ELT and (SETF ELT) which do not necessarily walk the list each time (depending on the type of list). The second idea is that I think it would be beneficial to explicitly state that mutability of sequences is optional. The CL standard doesn't say anything about it (or so it seems to me), although you can clearly see that in certain passages it assumes that list and vector (which are both mutable) are the only subtypes of sequence, whereas list and vector are explicitly said not to constitute an exhaustive partition of the type sequence[2]. Currently a number of sequence functions in the protocol implementation assume mutability, for example SUBSEQ by default creates a copy of the same type and sets elements one by one using an iterator. However, to eliminate the mutability requirement, at least another piece is missing: a generalization of CONS, i.e. an operation that appends a single element to the beginning of a sequence nondestructively. This is roughly what Clojure calls conj (except that conj does not specify where the element is added, which is a very awkward decision to me) and could be defined as (concatenate (class-of sequence) (list item) sequence)... if only concatenate wasn't implemented in terms of (SETF ELT) :P The possible negative sides of such a decision are: 1. it could in the end be an aspect of non-conformity to the ANSI standard (although only relevant to non-standard sequence subtypes) 2. it would make the default implementation of certain sequence operations even more inefficient for custom mutable sequences (that could be mitigated by checking for a marker mixin class MUTABLE-NONSTANDARD-SEQUENCE) 3. it would make ABCL's implementation of sequences a bit more complex. Note also that lifting mutability would NOT benefit Java collections because, inconsistently, they provide no general means to extend a collection without mutating it. What do you think? Cheers, Alessio [1] doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pd [2] http://www.lispworks.com/documentation/HyperSpec/Body/t_seq.htm

2 1

[armedbear-devel] New fasl format: steps to success
by Erik Huelsmann 04 Feb '12

04 Feb '12

After having mailed a few weeks ago about my ideas regarding a new fasl format, I'm now mailing regarding the next steps that I've come up with to implement the new scheme. But first I'd like to mention that I've come to the conclusion that our "each function is its own class" scheme can't be entirely eliminated: since we don't use invokedynamic yet, there are only two ways to create the function objects that we still require (to stick in the symbol function slot): 1. By using the reflection API to extract the XEPs (eXternal Entry Points) from the fasl class and create a single forwarder class which calls the XEP using reflection or 2. By still creating our multitude of classes which each implement a simple forwarder method which calls the fasl's XEP method I'm not sure of the performance implications of either. Maybe we need to test both schemes before we decide which one would be best. My preference is with method (1), btw, if it performs on par with method (2). So, now about the approach: I. We need to be able to have multiple argument list parsers (the equivalent of Closure.processArgs()) in a single class --> To achieve this, we need to factor out the relevant bits from Closure.java In fact, I did that over the past week: step completed. II. Our compiler should no longer specifically compile output to a class; we need to find a way for the COMPILE and COMPILE-FILE infrastructures to use the same basic compiler which compiles into a context provided by the respective callers. The trick here will be to develop a 'protocol' between the basic compiler and COMPILE/COMPILE-FILE which can be used to flatten the nested structure of compilands. III. Re-enable compilation of the content of the ._ file; we used to have that, but it didn't make a difference in start-up performance, so I disabled it again. Now, we need it to prevent having as many init_xxx() routines as we have functions. After all, at this time, we currently run a mix of ._ and initialization code by intermixing class loading and ._ file execution. IV. Develop a way to split overly big fasl classes, <clinit> (class initialization code) and <init> (constructor code) methods V. Change the base compiler to directly link to method/class combinations when instructed to do so by their caller / through some protocol. VI. COMPILE-FILE should start generating functions and XEPs -- within the current structure VII. Change the file compiler to direct its output to one or a small number of fasl classes, replacing the current output classes with either one of the two options presented earlier in the mail. Step (I) is - as mentioned - already completed. I'm envisioning steps (II) through (VI) to be done on trunk. I expect step (VII) to be associated with experimentation, which would best served by a separate branch. Comments? Ideas? Helpers? :-) Bye, Erik.

1 0

[armedbear-devel] HEADS UP: recent changes require full build
by Erik Huelsmann 04 Feb '12

04 Feb '12

Some of the changes I committed yesterday and today change the ABI of the org.armedbear.lisp.Closure class. Due to this change, a full build is required. Bye, Erik.

1 0

Re: [armedbear-devel] [armedbear-cvs] r13841 - trunk/abcl/contrib/abcl-asdf
by Ville Voutilainen 01 Feb '12

01 Feb '12

On 1 February 2012 15:25, <mevenson(a)common-lisp.net> wrote: > (truename (read-line (sys::process-output > - (sys::run-program "which" `(,mvn-path))))) > + (sys::run-program "which" `(,mvn-path))))) ;; TODO equivalent for MSDOS See http://stackoverflow.com/questions/304319/is-there-an-equivalent-of-which-o…, where.exe does it on windows, where /? gives help for it, and for example C:\Users\vilvouti>where notepad.exe C:\Windows\System32\notepad.exe C:\Windows\notepad.exe So just run 'where' for it and pick the first line if successful, I guess.

2 1

[armedbear-devel] bug report: stable-sort is only stable for lists
by Jorge Tavares 01 Feb '12

01 Feb '12

Dear ABCL developers, Recently I started to investigate the different CL sort implementations and found that stable-sort in ABCL does not execute as required. The problem is that stable-sort is only stable for lists and not for all type of sequences (i.e., elements considered equal by the predicate should stay in their original order). A very simple test shows this error: idesk:~ jast$ abcl Armed Bear Common Lisp 1.0.1 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.399 seconds. Startup completed in 1.069 seconds. Loading /Users/jast/.abclrc completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (defparameter *stuff* #((1 0.31648433) (0 0.2704757) (0 0.48931926) (1 0.9958766) (0 0.49251676))) *STUFF* CL-USER(2): (setf *stuff* (stable-sort *stuff* #'< :key #'first)) #((0 0.49251676) (0 0.2704757) (0 0.48931926) (1 0.31648433) (1 0.9958766)) The above test is short and simple to understand: *stuff* contains an array where each element is a pair. The first element of a pair is the key and the second the data. With this in mind, the expected result should have been: #((0 0.2704757) (0 0.48931926) (0 0.49251676) (1 0.31648433) (1 0.9958766)). The same error happens with larger arrays and other types of data. I also tested it in SBCL, CCL, ECL and CLisp and for these implementations the results are the expected. Only ABCL differs form the major open source implementations (I didn't test in ACL or LW). The reason for this bug is actually quite simple. In sort.lisp, in the definition of stable-sort, seq-dispatch calls for the non-list sequences the quicksort algorithm, which is not stable. For lists it calls merge sort (which is stable) and the problem does not arise. As a quick fix, I send in attach a patch that uses in stable-sort merge sort for all sequences. This is done by coercing the sequence to list, calling merge sort and coercing it back to the original sequence type. However, as a long term improvement, the best solution would be to implement a merge sort for non-list sequences. Cheers, Jorge Tavares -- http://jorgetavares.com

2 2

[armedbear-devel] Bugs(?) in pathnames
by Theam Yong Chew 01 Feb '12

01 Feb '12

Hi devs, I've observed a few issues (some I'm not so sure about) with pathnames: 1. CL-USER> (make-pathname :device '("c:/a.b.jar") :directory '(:absolute "cl-ppcre")) ; Evaluation aborted on NIL. Why am I not getting any errors (and not dropping into a debugger)? I know the error is because the device is not a list of a pathname ie missing a #P. 2. What's printed out is not what was read in (trailing /) CL-USER> #P"jar:file:c:/a/b.jar!/cl-ppcre/" #P"jar:file:c:/a/b.jar!/cl-ppcre" 3. Should this repeated jar:file:jar:file thing throw an error? #P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre/" ==> #P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre" I think that was all I found, at least for now :-), thanks. Yong.

2 3

[armedbear-devel] Correct README to indicate that JSS 3 has a namespace [ on 2012-01-27 10:11 GMT]
by Mark Evenson 27 Jan '12

27 Jan '12

Corrected documentation to indicate that JSS:NEW needs to be explicitly imported, or if you wish to pollute the namespace , then invoke JSS:ENSURE-COMPATIBILITY to import JSS symbols into CL-USER. Begin forwarded message: > From: abcl-dynamic-install(a)googlecode.com > Subject: [abcl-dynamic-install] push by evenson....(a)gmail.com - Correct README to indicate that JSS 3 has a namespace. on 2012-01-27 10:11 GMT > Date: January 27, 2012 11:11:44 AM GMT+01:00 > To: evenson.not.org(a)gmail.com > > Revision: 06d8a71be52d > Author: mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f > Date: Fri Jan 27 02:10:22 2012 > Log: Correct README to indicate that JSS 3 has a namespace. > http://code.google.com/p/abcl-dynamic-install/source/detail?r=06d8a71be52d > > Modified: > /contrib/jss/README.markdown > > ======================================= > --- /contrib/jss/README.markdown Mon Jul 11 06:57:21 2011 > +++ /contrib/jss/README.markdown Fri Jan 27 02:10:22 2012 > @@ -17,8 +17,11 @@ > > Java methods look like this: #"toString". Java classes are represented > as symbols, which are resolved to the appropriate java class > -name. When ambiguous, you need to be more specific. A simple example: > - > +name. When ambiguous, you need to be more specific. A simple example > +from CL-USER: > + > + (require 'jss) > + (jss:ensure-compatibility > (let ((sw (new 'StringWriter))) > (#"write" sw "Hello ") > (#"write" sw "World") > @@ -94,7 +97,6 @@ > > (jcmn class-name) lists the names of all methods for the class > > - > Compatibility > ------------- > > @@ -109,3 +111,24 @@ > Since we are no longer using Beanshell, this is no longer present. > For obtaining the current classloader use JAVA:*CLASSLOADER*. > > +# API > + > + 1.0 > + Equivalent to Alan Ruttenberg's version included with the original > + [lsw](). > + > +[lsw]: http://mumble.net:8080/svn/lsw/trunk/ > +[lsw2]: let-me-google-that-for-you > + > + > + 3.0 > + In the JSS package loaded from [abcl-contrib]() > + > +abcl-contrib: http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/ > + > +# Colophon > + > +<> dc:created "2005" ; > + dc:author "Mark <evenson.not.org(a)gmail.com>"; > + revised: "27-JAN-2012" . > +

2 1