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

[armedbear-devel] jss issues
by Brian Guarraci 27 Jan '12

27 Jan '12

Hi, I recently built and ran abcl and jss, and hit some strange issues. I wonder if there's something wrong with the docs or my environment: [tried using latest bin release and svn repo codes] $cd abcl $./abcl CL-USER(1): (require 'abcl-contrib) Adding jar:file:/home/bguarrac/src/abcl-src-1.0.1/dist/abcl-contrib.jar!/jss/ to ASDF. Adding jar:file:/home/bguarrac/src/abcl-src-1.0.1/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. Adding jar:file:/home/bguarrac/src/abcl-src-1.0.1/dist/abcl-contrib.jar!/asdf-install/ to ASDF. Adding jar:file:/home/bguarrac/src/abcl-src-1.0.1/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. ("MOP" "CLOS" "PRINT-OBJECT" "FORMAT" "ASDF" "ABCL-CONTRIB") CL-USER(2): (require 'jss) ("LOOP" "COMPILER-TYPES" "KNOWN-FUNCTIONS" "DUMP-FORM" "OPCODES" "JAVA" "KNOWN-SYMBOLS" "COMPILER-PASS1" "COMPILER-PASS2" "JVM" "JSS") CL-USER(3): (let ((sw (new 'StringWriter))) (#"write" sw "Hello ") (#"write" sw "World") (print (#"toString" sw))) #<THREAD "interpreter" {61181C24}>: Debugger invoked on condition of type UNDEFINED-FUNCTION * The function NEW is undefined.* Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to NEW. 3: TOP-LEVEL Return to top level. CL-USER(6): (new 'StringWriter) #<THREAD "interpreter" {61181C24}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function NEW is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to NEW. 3: TOP-LEVEL Return to top level. *[1] CL-USER(7): (jss:new 'StringWriter)* #<java.io.StringWriter {49E6F7CB}> [1] CL-USER(8): (#"write" (jss:new 'StringWriter) "hello") #<THREAD "interpreter" {61181C24}>: Debugger invoked on condition of type READER-ERROR No dispatch function defined for #\" Restarts: 0: ABORT Return to debug level 1. 1: CONTINUE Try again. 2: USE-VALUE Specify a function to call instead. 3: RETURN-VALUE Return one or more values from the call to NEW. 4: TOP-LEVEL Return to top level. Thanks! Brian

2 1

[armedbear-devel] Idea for new FASL format: smaller, faster
by Erik Huelsmann 26 Jan '12

26 Jan '12

The spec allows functions in a fasl to hard code references to each other, except when declared not-inline. Currently, we take advantage of that fact only a little bit: the only bit we eliminate is the function lookup from the symbol. Anything else works just like function calls which are not in the same file. The mail below comes from my long-standing desire to take better advantage of the room offered by the spec. What things would I like to improve on? 1. We only inline backward referenced functions in the same fasl 2. We parse the argument list of each function call with respect to keywords and optional parameters 3. We store the names of symbols referenced in many .cls files each of which gets separately zipped 4. We store (cache) function references to inlined functions as objects What's the basic idea? The idea is to shift paradigms: instead of compiling each Lisp function into a class, we will start compiling each lisp function to a Java function. A FASLs would become one or more classes -- depending on if everything fits into a single class or not. The idea is by the way not to change the way we model functions in symbol function slots, but instead to change the way everything is stored in a fasl. Does it address the items mentioned above? 1. Since class files are written once the class is complete, we have to delay serializing the lisp functions to disk until they're all known. This means that we will know all functions defined in a fasl before it's serialized. With an appropriate linker phase, we could easily resolve all forward referenced function calls. 2. Because lisp functions have become Java functions, we can't directly expose them to the Lisp world anymore. This basically creates the option to have an 'internal function signature' and an 'external function signature'. SBCL has this: XEPs -- eXternal Entry Points. These entry points into a function sort the arguments into the right order before calling the internal entry point. Code which is compiled into the same fasl pre-sorts the arguments at compile time (when possible) and calls the internal entry point -- eliminating the need to sort keyword parameters. 3. By having a single (or fewer) class files, we can achieve higher re-use ratios of the same constants which would otherwise be included in many-many .cls files. 4. Because function calls to 'inline' functions will become calls to sibling methods, they will become clear candidates for inlining to the JIT. With the object references, it is not clear this is an option. What I think needs to happen to get this designed: a. The file compiler and function compiler should be based on a shared 'method compiler' which takes its context from the caller instead of the existing way of basing the file compiler on the function compiler. b. We need to implement a linker phase separate from the pass2 phase, which can re-order arguments and call sibling methods instead of Lisp Function objects. c. We need to find a way to correctly handle the interaction between the successive IN-PACKAGE, DEFPACKAGE, EVAL-WHEN, etc, forms appearing in the input file and the initialization of fields in the resulting class file. d. We need a way to expose the external entry points to the lisp world. e. We need to find a way to split fasls over multiple class files. Comments? Bye, Erik.

2 4

[armedbear-devel] asdf-jar on Windows
by Theam Yong Chew 22 Jan '12

22 Jan '12

Hi devs, I looked into the asdf jar loading mechanism in the contrib, and found that it doesn't work well on Windows (mainly pathname issues). Attached patch provides a suggested fix (please review). Additionally, I think a suitable (OS portable?) argument for asdf-jar:package's &key out #P"/var/tmp" would be nice. This was tested informally, seems to work. What do you think? Thanks for the good work! Yong. PS Any ideas on how we can avoid bundling the source too (maybe only the .asd file will still be needed). This will make jar files look more like binaries in a way... I tried to add a :exclude-source argument to package, but the resulting jar file failed to load (asdf wants source files still).

3 4

[armedbear-devel] Testing code review mechanism
by Mark Evenson 20 Jan '12

20 Jan '12

Testing the [GOOG's code review mechanism on a (more-or-less)][1] [random commit of Alessio's][r13792]. [e13792]: http://trac.common-lisp.net/armedbear/changeset/13792 [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=713f68f07d738…

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13787 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 17 Jan '12

17 Jan '12

The commit below reduces the number of ANSI failures on my system from 18 to 14! Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Tue, Jan 17, 2012 at 8:39 PM Subject: [armedbear-cvs] r13787 - trunk/abcl/src/org/armedbear/lisp To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Tue Jan 17 11:39:54 2012 New Revision: 13787 Log: Implement keyword argument verification in the method invocation protocol. Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp ============================================================================== --- trunk/abcl/src/org/armedbear/lisp/clos.lisp Tue Jan 17 11:38:01 2012 (r13786) +++ trunk/abcl/src/org/armedbear/lisp/clos.lisp Tue Jan 17 11:39:54 2012 (r13787) @@ -2027,13 +2027,72 @@ (unless (subclassp (car classes) specializer) (return (values nil t))))))) +(defun check-applicable-method-keyword-args (gf args + keyword-args + applicable-keywords) + (when (oddp (length keyword-args)) + (error 'program-error + :format-control "Odd number of keyword arguments in call to ~S ~ +with arguments list ~S" + :format-arguments (list gf args))) + (unless (getf keyword-args :allow-other-keys) + (loop for key in keyword-args by #'cddr + unless (or (member key applicable-keywords) + (eq key :allow-other-keys)) + do (error 'program-error + :format-control "Invalid keyword argument ~S in call ~ +to ~S with argument list ~S." + :format-arguments (list key gf args))))) + +(defun compute-applicable-keywords (gf applicable-methods) + (let ((applicable-keywords + (getf (analyze-lambda-list (generic-function-lambda-list gf)) + :keywords))) + (loop for method in applicable-methods + do (multiple-value-bind + (keywords allow-other-keys) + (function-keywords method) + (when allow-other-keys + (setf applicable-keywords :any) + (return)) + (setf applicable-keywords + (union applicable-keywords keywords)))) + applicable-keywords)) + +(defun wrap-emfun-for-keyword-args-check (gf emfun non-keyword-args + applicable-keywords) + #'(lambda (args) + (check-applicable-method-keyword-args + gf args + (nthcdr non-keyword-args args) applicable-keywords) + (funcall emfun args))) + (defun slow-method-lookup (gf args) (let ((applicable-methods (%compute-applicable-methods gf args))) (if applicable-methods - (let ((emfun (funcall (if (eq (class-of gf) +the-standard-generic-function-class+) - #'std-compute-effective-method-function - #'compute-effective-method-function) - gf applicable-methods))) + (let* ((emfun (funcall (if (eq (class-of gf) +the-standard-generic-function-class+) + #'std-compute-effective-method-function + #'compute-effective-method-function) + gf applicable-methods)) + (non-keyword-args + (+ (length (gf-required-args gf)) + (length (gf-optional-args gf)))) + (gf-lambda-list (generic-function-lambda-list gf)) + (checks-required (and (member '&key gf-lambda-list) + (not (member '&allow-other-keys + gf-lambda-list))) + ) + (applicable-keywords + (when checks-required + ;; Don't do applicable keyword checks when this is + ;; one of the 'exceptional four' or when the gf allows + ;; other keywords. + (compute-applicable-keywords gf applicable-methods)))) + (when (and checks-required + (not (eq applicable-keywords :any))) + (setf emfun + (wrap-emfun-for-keyword-args-check gf emfun non-keyword-args + applicable-keywords))) (cache-emf gf args emfun) (funcall emfun args)) (apply #'no-applicable-method gf args)))) @@ -2407,6 +2466,7 @@ (%set-method-function method function) (%set-method-fast-function method fast-function) (set-reader-method-slot-name method slot-name) + (%set-function-keywords method nil nil) method)) (defun add-reader-method (class function-name slot-name) @@ -2830,8 +2890,7 @@ ((null tail)) (unless (memq initarg allowable-initargs) (error 'program-error - :format-control "Invalid initarg ~S in call to ~S ~ -with arglist ~S." + :format-control "Invalid initarg ~S in call to ~S with arglist ~S." :format-arguments (list initarg call-site args)))))))) (defun merge-initargs-sets (list1 list2) @@ -2949,7 +3008,8 @@ &rest initargs &key &allow-other-keys)) -(defmethod shared-initialize ((instance standard-object) slot-names &rest initargs) +(defmethod shared-initialize ((instance standard-object) slot-names + &rest initargs) (std-shared-initialize instance slot-names initargs)) (defmethod shared-initialize ((slot slot-definition) slot-names @@ -3372,7 +3432,6 @@ (:method ((method standard-method)) (%function-keywords method))) - (setf *gf-initialize-instance* (symbol-function 'initialize-instance)) (setf *gf-allocate-instance* (symbol-function 'allocate-instance)) (setf *gf-shared-initialize* (symbol-function 'shared-initialize)) _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

2 1

[armedbear-devel] ABCL Debug.assertTrue() assertion failed!
by Santiago Carbonell 17 Jan '12

17 Jan '12

Hi, I'm trying to compile and execute a project that was coded in Lisp in Java using ABCL. When I try to execute it, I always obtain this error when try to execute a defstruct sentence: ABCL Debug.assertTrue() assertion failed! Someone can help me? Thanks

3 2

[armedbear-devel] HEADS-UP: Those following trunk need to remove SLIME/ASDF fasls
by Mark Evenson 16 Jan '12

16 Jan '12

With [r13781][], if one is compiling from trunk one will need to clear any intermediate SLIME/ASDF fasls, as the indices of the CLOS slots have been renumbered. [r13781]: http://bit.ly/xPxljS Under 'NIX, the following will reset things: cmd$ rm -rf ~/.slime ~/.cache

2 1

[armedbear-devel] regression of bordeaux-threads tests on ABCL 1.0.1 (comparing to 1.0.0)
by Anton Vodonosov 12 Jan '12

12 Jan '12

Hello. I am running tests of some lisp libraries on various cl implementations. Just noticed a regression. Here are test logs of the same version of bordeaux-threads: Of ABCL 1.0.0 https://cl-test-grid.appspot.com/blob?key=AMIfv959vw8OTYbBwH_qli8d6EeL6-Roh… of ABCL 1.0.1 https://cl-test-grid.appspot.com/blob?key=AMIfv97tbGEUijVGZDqkxNzUOVSNQ_Fr9… As you see, 1.0.0 passes the tests, while 1.0.1 fails to build them. (But I don't know if it's a bug in ABCL 1.0.1, or it's a bug in bordeaux-threads tests which just wasn't detected by old ABCL). Best regards, - Anton

2 6

[armedbear-devel] Armed Bear Common Lisp abcl-1.0.1 maintenance release
by Mark Evenson 12 Jan '12

12 Jan '12

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 1.0.1 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release squashes bugs in the ABCL 1.0 release, most notably it features a working ABCL-CONTRIB symbol to the ANSI REQUIRE mechanism and it ships with ASDF 2.019. You can find more in the release notes at: http://common-lisp.net/project/armedbear/release-notes-1.0.1.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/tags/1.0.1/abcl/CHANGES Source and binary distribution archives with associated cryptographic signatures can be downloaded in ZIP or gzipped tar from: http://common.lisp.net/project/armedbear/releases/1.0.1 If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net

2 3

[armedbear-devel] Welcome to the team: Rudi Schlatte
by Erik Huelsmann 10 Jan '12

10 Jan '12

Rudi Schlatte has been working toward getting us AMOP compatibility. That goal hasn't been reached, but he's very much welcome to join the team! Help improve ABCL any way you can! Thanks for your contributions so far and all those which will come. I've added you to the armedbear group, meaning you should now be able to commit to our repository. BTW: If you feel a patch needs review, you can still send your patches to the list for review and discussion. Bye, Erik.

1 0

[armedbear-devel] Patch for bug 172
by Rudolf Schlatte 10 Jan '12

10 Jan '12

Hi, ; SLIME 2012-01-06 CL-USER> (defgeneric foo (x) (:documentation "Hi there!")) #<STANDARD-GENERIC-FUNCTION FOO {78189538}> CL-USER> (documentation 'foo 'function) "Hi there!" CL-USER> LispObject.java didn't know that things other than Function could be in a symbol's function slot. Regards, Rudi Changes in HEAD Modified src/org/armedbear/lisp/LispObject.java diff --git a/src/org/armedbear/lisp/LispObject.java b/src/org/armedbear/lisp/LispObject.java index ce52169..e0d3f35 100644 --- a/src/org/armedbear/lisp/LispObject.java +++ b/src/org/armedbear/lisp/LispObject.java @@ -658,7 +658,7 @@ public class LispObject //extends Lisp return ((Cons)entry).cdr; } if(docType == Symbol.FUNCTION && this instanceof Symbol) { - Object fn = ((Symbol)this).getSymbolFunction(); + LispObject fn = ((Symbol)this).getSymbolFunction(); if(fn instanceof Function) { DocString ds = fn.getClass().getAnnotation(DocString.class); if(ds != null) { @@ -672,6 +672,9 @@ public class LispObject //extends Lisp return doc; } } + } else if (fn instanceof StandardGenericFunction) { + return StandardGenericFunction.checkStandardGenericFunction(fn) + .slots[StandardGenericFunctionClass.SLOT_INDEX_DOCUMENTATION]; } } return NIL;

1 0

[armedbear-devel] Patch for failing ansi method-combination tests
by Rudolf Schlatte 10 Jan '12

10 Jan '12

Hi, Here's a patch for the newly-faililng ansi tests mentioned on irc, moving creation of short-method-combination objects inline. (The same could be done for long-method-combination objects -- the make-long-method-combination function is a remnant of the time when method combinations were implemented as structures.) Rudi

1 0

[armedbear-devel] HEADS-UP: freezing branch soon for abcl-1.0.1
by Mark Evenson 09 Jan '12

09 Jan '12

I'd like to get a release out for abcl-1.0.1, as we shipped with [several things broken][1] notably the ABCL-CONTRIB. Since everyone seems quite busy, I'd like to volunteer to sign and ship this one, helping to strengthen our release process. I've set the milestone in Trac for the middle of January, but would rather this happen on the order of days. It looks like we're going to be able to get to working with closer-mop with abcl-1.1.0, so I want to separate out a stable ABCL that at least works something like what [the Manual][abcl-1.0-user-manual.pdf] describes. [1]: http://trac.common-lisp.net/armedbear/milestone/1.0.1 [abcl-1.0-user-manual.pdf]: http://abcl-dynamic-install.googlecode.com/files/abcl-20111108a.pdf @Erik: I'll merge the byte array bug you addressed. @Alessio: There's a distribution POM for abcl-contrib ('abcl/contrib/pom.xml') that seems to work. Can you eventually ensure that the update is pushed to Sonatype? I assume we can easily add new artifacts under the GroupID we currently push abcl-1.0.0.jar with, right? Fine touches on the Manual; editing CHANGES; testing of the [abcl-1.0.1 branch][2] are all welcome. I will backport any significant contributions from trunk. And patches are always more than welcome. [2]: http://svn.common-lisp.net/armedbear/branches/1.0.x/abcl/ yers in CONS, Mark <evenson(a)panix.com>

1 1

[armedbear-devel] Reworked patch: convert (long|short)-method-combination into CLOS classes
by Rudolf Schlatte 06 Jan '12

06 Jan '12

Hi, After Mark's question about "what are you really trying to do?" I realized that in clos.lisp we have defun and friends available, so the accessor functions for method combinations can be implemented there. Attached is a reworked patch. I believe that the class definitions need to stay inside StandardClass.lisp, since we can't call ensure-class yet. I also attach a patch that gets rid of the ill-fated EqualSpecializerObject.java and replaces it with 3 lines of Lisp code ... (Thanks for tolerating my stumbling-about in your project, guys..) Rudi

1 0

[armedbear-devel] Patch: convert method-combination from structure to class representation
by Rudolf Schlatte 06 Jan '12

06 Jan '12

Hi, Another day, another conversion ... This was the error (apart from some un-exported symbols, which I plan to collect in a separate patch) that brought mop-feature-tests to a halt last time. I'll try to re-run it soon and see how much farther we get now. Any feedback that makes your work easier gladly welcomed, including code style, documentation etc. Rudi

2 2

[armedbear-devel] [Patch] add classes METAOBJECT, SPECIALIZER
by Rudolf Schlatte 05 Jan '12

05 Jan '12

Hi, These two patches add the metaobject and specializer classes (ref. Table 5.1 in AMOP). They are at the proper place in the class hierarchy as far as possible -- there are some structures that should be classes (eql-specializer, method-combination) and [standard-]generic-function still have the wrong metaclass and superclasses. Regards, Rudi

3 11

[armedbear-devel] invoke.lisp can't find jsint.Invoke
by Peter Olsen 26 Dec '11

26 Dec '11

Ladies and Gentlemen, I've been trying to run ABCL with JSS. I load ABCL then I try to '(load "invoke.lisp")'. I always get an error Peters-MacBook-Pro:bin pcolsen$ java -cp jscheme.jar -jar abcl-1.0.0.jar Armed Bear Common Lisp 1.0.0 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.315 seconds. Startup completed in 1.06 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "invoke.lisp") Error loading /Users/pcolsen/bin/invoke.lisp at line 194 (offset 8509) #<THREAD "interpreter" {1DC2DAD7}>: Debugger invoked on condition of type ERROR Class not found: jsint.Invoke Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): I the past several years I have used Java only to support ABCL, so I may be making some simple mistake that I have not the wit to recognize. Please feel free to tell me to RTFM, but please give me a hint about what part of TFM I should R. Thanks! Peter Peter Olsen pcolsen(a)gmail.com Scientists study the world; engineers change it.

2 1

[armedbear-devel] stack overflow when compiling alexandria-tests
by Anton Vodonosov 20 Dec '11

20 Dec '11

Hello I am running tests of some libraries with ABCL (I decided to setup an test environment for CL libraries). When compiling alexandria tests by (quicklisp:quickload :alexandria-tests) it encounters StackOverflow. I am using the latest quicklisp. I've tried to increase the java stack size by -XX:ThreadStackSize=12048, but it doesn't help. Best regards, - Anton

2 1

[armedbear-devel] Bug in reader case handling
by Blake McBride 12 Dec '11

12 Dec '11

Greetings, Given a file name ff.lisp containing the following: (setf (readtable-case *readtable*) :invert) (defpackage "abc" (:use "COMMON-LISP") (:export "MYFUN")) (in-package "abc") (defun myfun (a b) (+ a b)) ; EOF Then try: (use-package "abc") (myfun 4 5) (abc:myfun 4 5) ; this should not work (ABC:myfun 4 5) ; this should work This works as described in sbcl, cmucl, clisp and ecl but doesn't work in abcl. It seams abcl takes into account the case of the entire "ABCL:myfun" when dealing with case. All the other lisps treat "ABC" and "myfun" separately in terms of string case. Blake McBride

1 0

[armedbear-devel] FORMAT dollarsign with negative numbers
by Marshall Abrams 05 Dec '11

05 Dec '11

It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's handling of negative numbers when it has to round up. (Forgive me if this is a known issue--I didn't find it when I searched the bug list and mailing list archives--or if there's something I'm misunderstanding.) The first group of examples use the F directive for comparison to show that the problem seems to be specific to dollarsign. (I added blank lines between example groups for easy reading.) The second group of examples illustrates a problem using dollarsign with negative numbers. The output is about 10x too large, and doesn't seem to be getting rounded properly. I'm guessing that the out of bounds error is the result of the same issue. The third group of examples shows that the problem doesn't seem to occur with positive numbers, although there's still an extra negative sign preprended. Thank you- Marshall Abrams Armed Bear Common Lisp 1.0.0-svn-13663 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.7 seconds. Startup completed in 2.211 seconds. Type ":help" for a list of available commands. CL-USER(1): (format t "~,vf" 3 -0.1768522) -0.177 NIL CL-USER(2): (format t "~,vf" 2 -0.1768522) -0.18 NIL CL-USER(3): (format t "~,vf" 1 -0.1768522) -0.2 NIL CL-USER(4): (format t "~,vf" 0 -0.1768522) -0. NIL CL-USER(5): (format t "~$" -0.1768522) --1.6 NIL CL-USER(6): (format t "~v$" 3 -0.1768522) --1.75 NIL CL-USER(7): (format t "~v$" 2 -0.1768522) --1.6 NIL CL-USER(8): (format t "~v$" 1 -0.1768522) #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type TYPE-ERROR Array index out of bounds: 2 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(9): 0 CL-USER(10): (format t "~v$" 0 -0.1768522) --0. NIL CL-USER(11): (format t "~$" 0.1768522) 0.18 NIL CL-USER(12): (format t "~v$" 3 0.1768522) 0.177 NIL CL-USER(13): (format t "~v$" 2 0.1768522) 0.18 NIL CL-USER(14): (format t "~v$" 1 0.1768522) 0.2 NIL CL-USER(15): (format t "~v$" 0 0.1768522) 0. NIL

2 1

[armedbear-devel] [Patch] implement mop:extract-specializer-names
by Rudolf Schlatte 05 Dec '11

05 Dec '11

... as specified in AMOP page 189. The internal function extract-specializers did exactly the same, so the attached patch renames and exports it. Cheers, Rudi

2 1

[armedbear-devel] (defpackage :foo (:import-from "COMMON-LISP" "NIL")) fails
by Rudolf Schlatte 01 Dec '11

01 Dec '11

Hi, Subject says it all, I suppose. :) Patch enclosed. Rudi

1 0

[armedbear-devel] BUG: invalid treatment of UNSIGNED-BYTE type specifiers
by Eric Marsden 18 Nov '11

18 Nov '11

Hi, The following code seems to be miscompiled (works fine with an INTEGER type declaration). CL-USER(23): (lisp-implementation-version) "1.1.0-dev-svn-13695M" CL-USER(24): (compile nil (lambda (a) (declare (type unsigned-byte a)) (max 28105919 a 1016934843))) #<FUNCTION (LAMBDA (A)) {2D53EAFD}> NIL NIL CL-USER(25): (funcall * 10545160975) 1955226383 (From ansi-test/random suite) -- Eric

2 1

Re: [armedbear-devel] [fset-devel] FSet on ABCL
by Alessio Stalla 08 Nov '11

08 Nov '11

Hi, to follow up on the topic of running FSet on ABCL, I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine. However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization? Bye, Alessio On Thu, Oct 27, 2011 at 1:19 AM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott(a)sympoiesis.com> wrote: >> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla >> <alessiostalla(a)gmail.com> wrote: >>> Greetings, >>> >>> as part of my nth plan to conquer the world (which of course I won't >>> unveil right now), I tried FSet on ABCL. I managed to make it run, but >>> I had to patch it; you can find the patch attached (it's taken against >>> the version in Quicklisp, but I believe it's the latest version). >> >> Thanks for the patch! >> >> Did you run the test suite? Were any non-default JVM settings >> required, e.g. stack size? >> >> Do you have any performance comparisons (of FSet operations in >> particular) vis-a-vis, say, SBCL? > > I haven't run the test suite yet, nor made any performance > comparisons. Regarding JVM settings, in order to compile and load FSet > (under SLIME) I had to increase the maximum heap size from the (iirc) > 64M default. I set it at 256M but it may well be that a lower value is > sufficient. In the next few days I'll do a few tests and benchmarks > and I'll keep you informed on the results. > >> >>> Besides some minor #+abcl porting stuff, the one thing that stuck out >>> was the DEFLEX macro for defining global lexical variables, which >>> conflicts with ABCL's implementation of symbol macros. >>> (deflex var) expands basically into (define-symbol-macro var >>> (symbol-value 'var)). The problem: ABCL stores symbol macros in the >>> value cell of symbols, so you can't have a symbol which is both a >>> variable and a symbol macro. >>> Now, I believe deflex as written is non portable CL. This is because >>> accessing the symbol-value of an unbound variable is, to my >>> interpretation, unspecified [*]; and if you use defvar/defparameter >>> with var, then you cannot use it as a symbol macro. Thus, I patched it >>> (taking inspiration from Rob Warnock's version of deflex/defglobal). >> >> Heh -- I had seen Rob's implementation and wondered why he created a >> second symbol. Now I know :-) > > I don't particularly like the second interned symbol solution... I > tried initially with a gensym, but it's hard to get right the > interplay between compile-time, load time, and the file compiler > possibly losing gensym identity, so I guess Rob's approach is the most > practical. > >> >>> I don't think a symbol for which there is no special declaration in >>> scope can be considered to name a dynamic variable, and thus to have a >>> value cell at all. >> >> On a strict reading, you're probably correct. But I had never seen an >> implementation for which this was not the case. > > Yes, me neither, and I'd like to get ABCL fixed in that regard. You > might keep your implementation of deflex as-is; in the meantime I will > use my patched version, until ABCL is fixed. > > Thanks, > Alessio >

1 0

[armedbear-devel] stack overflow for worst-case vector sort
by James M. Lawrence 08 Nov '11

08 Nov '11

ABCL-1.0.0 (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) => Stack overflow. [Condition of type STORAGE-CONDITION] 0: (#<FUNCTION {7F535BDF}> #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 1: (APPLY #<FUNCTION {7F535BDF}> (#<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {74A2B3B8}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:374) 5: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1315) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 8: org.armedbear.lisp.swank_469.execute(swank.lisp:2116) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:683) 10: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) 11: (JAVA:JRUN-EXCEPTION-PROTECTED #<FUNCTION {39B4CEC7}>) It looks like the quick-sort function (attributed to ECL) pivots off the first element. I would suggest using a midpoint instead. ABCL's sort also seems a little slow. The psort benchmarks show too much speedup for only 2 cores (http://lparallel.com/download) size 1000 | op < | SORT 11 size 1000 | op < | SORT 11 size 1000 | op < | SORT 12 size 1000 | op < | SORT 12 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 50000 | op < | SORT 1014 size 50000 | op < | SORT 1011 size 50000 | op < | SORT 1012 size 50000 | op < | SORT 1013 size 50000 | op < | PSORT 413 size 50000 | op < | PSORT 417 size 50000 | op < | PSORT 415 size 50000 | op < | PSORT 416 size 200000 | op < | SORT 4703 size 200000 | op < | SORT 4701 size 200000 | op < | SORT 4715 size 200000 | op < | SORT 4712 size 200000 | op < | PSORT 1977 size 200000 | op < | PSORT 1975 size 200000 | op < | PSORT 1979 size 200000 | op < | PSORT 1994 psort is based upon the following (posted to usenet by Roger Corman; free license). (defun quicksort (vec lo hi comp-func) (if (> hi lo) (let* ((mid (round (+ lo hi) 2)) (i lo) (j (+ hi 1)) (p (elt vec mid))) (rotatef (elt vec mid) (elt vec lo)) ;; swap mid element to first (loop (loop do (incf i) until (or (> i hi) (funcall comp-func p (elt vec i)))) (loop do (decf j) until (or (<= j lo) (funcall comp-func (elt vec j) p))) (if (< j i) (return)) (rotatef (elt vec i)(elt vec j))) (rotatef (elt vec lo) (elt vec j)) ;;put partition element in place (quicksort vec lo (- j 1) comp-func) (quicksort vec i hi comp-func))) vec) (defun qsort (sequence comp-func) (quicksort sequence 0 (- (length sequence) 1) comp-func))

2 1

[armedbear-devel] Patch: sequence implementations can be structures
by Alessio Stalla 08 Nov '11

08 Nov '11

Hello, again musing with FSet on ABCL, thinking about integrating it with the CL sequence API (where it makes sense). FSet collections are structures, so I wrote the attached hack^H^H^H^Hpatch to create a special structure class that extends cl:sequence. This can be used to make user-defined structures obey the sequence protocol without wrappers, though I haven't used it with FSet yet. What do you think about it? Bye, Alessio

1 1

[armedbear-devel] Patch to dynamically load jna.jar for CFFI
by Mark Evenson 06 Nov '11

06 Nov '11

If you have the the [contrib mechanism working correctly, post abcl-1.0.0][1], one can get ABCL to dynamically load the required shared objects to enable [via the following code in your ~/.abclrc][2]: #+abcl (eval-when (:load-toplevel) (require 'abcl-contrib) (require 'abcl-asdf) (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.sun.jna" "jna" "3.0.9"))) ASDF shouldn't really be patched in [this way][1], but it involves debugging the Pathname internals (yet again) which is a task I am postponing until I can string together a bunch of consecutive hours. [1]: http://trac.common-lisp.net/armedbear/changeset/13692 [2]: http://bit.ly/v6OQFf

1 0

[armedbear-devel] adjust-array bug
by Helmut Eller 06 Nov '11

06 Nov '11

Evaluating this form (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) prints a longish stacktrace that doesn't seem right: Armed Bear Common Lisp 1.1.0-dev-svn-13692M Java 1.6.0_18 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 0.771 seconds. Startup completed in 2.209 seconds. Type ":help" for a list of available commands. CL-USER(1): (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:291) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:40) at org.armedbear.lisp.adjust_array.execute(adjust_array.java:95) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.Autoload.execute(Autoload.java:258) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.arrays_2.execute(arrays.lisp:46) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) 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:541) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:496) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) 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$1.execute(Lisp.java:277) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) 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.top_level_51.execute(top-level.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.Interpreter.run(Interpreter.java:360) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:636) #<THREAD "interpreter" {3DC13D}>: Debugger invoked on condition of type ERROR Caught java.lang.ArrayStoreException. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): Helmut

2 1

[armedbear-devel] Symbol-macro patch
by Alessio Stalla 02 Nov '11

02 Nov '11

Greetings, following up from my earlier mail about FSet and ABCL, I propose a patch (attached) to fix ABCL's symbol-macro implementation not to use the symbol's global value slot. Local symbol macros still use the same storage location as variables, since it's not possible to use symbol-value on local variables and it is forbidden to both declare a variable special and associate a symbol macro to its name. I also simplified some code that did not make use of this assumption, and specially handled cases where a symbol was both naming a special variable and a symbol macro. An inconsistency remains: (defvar foo) (define-symbol-macro foo nil) signals an error, while (define-symbol-macro foo nil) (defvar foo) does not. This behaviour is present in stock ABCL as well, and apparently it's allowed by the ANSI standard, although at least SBCL consistently signals an error in both cases. I believe we should do so, too. But I think it pertains to another patch. Please test the patch with your own code; I ran the ANSI test suite and got no regressions, but I'm not very confident about it - apparently it doesn't cover symbol macros very well or at all, since at one time I ran it with define-symbol-macro effectively unimplemented and it happily reported the same 19-20 failures it did before. Cheers, Alessio

2 2

[armedbear-devel] Manual format
by Blake McBride 29 Oct '11

29 Oct '11

Greetings, I was looking at the ABCL manual for ABCL 1.0 under the 'manual' directory. I noticed that it is in LaTeX format. I have been using TeX, LaTeX and Texinfo for many years. Among many other things, I have written two longish user manuals in Texinfo. They are located (including source) at: http://blake.mcbride.name/software/dynace/downloads.html under the 'manual' directory. With the experience I've had with TeX, LaTeX, and Texinfo, I feel very strongly that these are unbelievably great tools, and, in fact, the right tools for the job. However, I also feel strongly that Texinfo is the better format for the particular task of a manual on ABCL. I use LaTeX pretty often, but I have found Texinfo better suited for user manuals of computer topics for several reasons. First, the macros defined are more natural for the topic. Second, Texinfo supplies much better index creation tools for functions, variables, classes, etc.. Lastly, if you use Texinfo, you get online documentation for free! Texinfo is specifically designed for exactly this kind of technical document. LaTeX is equally good, but at writing non-technical books. Latex is not a natural fit for technical documents in my opinion. So, in conclusion: 1. I recommend switching to Texinfo. It would be especially easy at this early juncture. 2. The manuals I wrote come out, IMO, nicely. These documents could be used as templates. 3. My time is a real problem but I think I can convert the existing document so that you'd have it all setup to continue with if that is desired. I welcome your thoughts. Blake McBride

4 4

[armedbear-devel] FSet on ABCL
by Alessio Stalla 26 Oct '11

26 Oct '11

Greetings, as part of my nth plan to conquer the world (which of course I won't unveil right now), I tried FSet on ABCL. I managed to make it run, but I had to patch it; you can find the patch attached (it's taken against the version in Quicklisp, but I believe it's the latest version). Besides some minor #+abcl porting stuff, the one thing that stuck out was the DEFLEX macro for defining global lexical variables, which conflicts with ABCL's implementation of symbol macros. (deflex var) expands basically into (define-symbol-macro var (symbol-value 'var)). The problem: ABCL stores symbol macros in the value cell of symbols, so you can't have a symbol which is both a variable and a symbol macro. Now, I believe deflex as written is non portable CL. This is because accessing the symbol-value of an unbound variable is, to my interpretation, unspecified [*]; and if you use defvar/defparameter with var, then you cannot use it as a symbol macro. Thus, I patched it (taking inspiration from Rob Warnock's version of deflex/defglobal). However, I do think ABCL's implementation is very brittle (and probably conflicting with ANSI as well), because if you setf the symbol-value of a symbol with a global symbol macro attached, you remove the symbol macro! So, I think we should fix it for 1.0.1. Perhaps I can do the fix myself, but we better discuss it before because I fear this might be a deep change. [*] symbol-value ... Accesses the symbol's value cell. [1] value cell n. Trad. (of a symbol) The place which holds the value, if any, of the dynamic variable named by that symbol, and which is accessed by symbol-value. [2] dynamic variable n. a variable the binding for which is in the dynamic environment. [3] I don't think a symbol for which there is no special declaration in scope can be considered to name a dynamic variable, and thus to have a value cell at all. [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-v… [2] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#value_ce… [3] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#dynamic_… Cheers, Alessio

1 0

[armedbear-devel] Support for specialized arrays?
by Blake McBride 26 Oct '11

26 Oct '11

Greetings, I presume ABCL supports specialized arrays (element-type:) syntactically but I am wondering if ABCL actually creates more efficient, type specific, arrays rather than generic, arrays of objects? Thanks. Blake McBride

3 3

Re: [armedbear-devel] bug of resolve-symlinks
by Gábor Balázs 25 Oct '11

25 Oct '11

hY, I think there is a bug in the list-directory function. The resolve-symlinks flag seems to always resolve the directory symlinks even when the flag is set to nil. Let's have a directory as : total 4 drwxr-xr-x 2 bege users 4096 Oct 23 23:52 dir lrwxrwxrwx 1 bege users 3 Oct 23 23:53 dir-link -> dir -rw-r--r-- 1 bege users 0 Oct 23 23:53 file lrwxrwxrwx 1 bege users 4 Oct 23 23:53 file-link -> file Then Armed Bear Common Lisp 0.26.2 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 1.436 seconds. Startup completed in 5.385 seconds. Type ":help" for a list of available commands. CL-USER(1): *(directory "./*" :resolve-symlinks nil)* (#P"/home/bege/TEST/./file" *#P"/home/bege/TEST/dir/"*#P"/home/bege/TEST/./file-link" *#P"/home/bege/TEST/dir/"*) Sorry, if this has been already fixed... Best, `bg`

2 1

Re: [armedbear-devel] destroy-thread and unwind-protect
by Mark Evenson 25 Oct '11

25 Oct '11

On Oct 24, 2011, at 17:59 , James Lawrence wrote: […] > Thanks for the response. > > That seems like a different issue. The purpose is not to guarantee > that the thread is destroyed. > > The behavior sought is: when the protected form stops executing, run > the cleanup forms. […] > In my case I am only interested in detecting the termination of a > thread without polling. Maybe there is an ABCL-specific way to do > that. THREADS:THREAD-ALIVE-P Function: Boolean predicate whether THREAD is alive.

2 4

[armedbear-devel] asdf and windows vs unix on abcl
by Faré 24 Oct '11

24 Oct '11

ABCL is special in that it can run on either Windows or Unix. The problem is that ASDF 2.017 determines which of Windows or Unix at compile-time, which causes confusion when ABCL's builtin ASDF is compiled on Windows and used on Unix or vice-versa. And I can tell your binary was definitely produced on Windows. (I found this issue while testing cl-launch. I also noticed that you fixed your ext:*command-line-argument-list* albeit in a necessarily incompatible way.) I suppose the solution is that the test of unixness vs windowsness should happen at runtime. Crazy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

5 13

[armedbear-devel] Minor doc patch for table of contents
by Ville Voutilainen 22 Oct '11

22 Oct '11

The basic TOC should be simple. It seems that pdflatex automagically makes the TOC entries to be hyperlinks, so this should be a relative no-brainer? We can use a more elaborate toc-package later if need be. I haven't pushed this in yet, because the manual is sort-of-Mark's turf, so I'm getting my feet wet before committing directly. ;)

2 1

Re: [armedbear-devel] ABCL manual, PDF with suggestions
by Mark Evenson 21 Oct '11

21 Oct '11

On Oct 21, 2011, at 08:34 , Philipp Marek wrote: > Hello Mark, > > here's the ABCL manual with a few ;) annotations. > > Please take them with a grain of salt, yadda yadda yadda. Thanks a lot! There's a lot of detailed work that you point out that I didn't get a chance to finish, but I tried to incorporate your large-scale criticism in [the abcl-20111021a release of the Armed Bear Common Lisp User Manual][1]. The [LaTex sources to the manual][2] are on the abcl 1.0.x branch for which diffs are solicited. [1]: http://abcl-dynamic-install.googlecode.com/files/abcl-20111021a.pdf [2]: http://svn.common-lisp.net/armedbear/branches/1.0.x/abcl/doc/manual/abcl.tex

1 0

[armedbear-devel] abcl-1.0.x branched. Please test.
by Mark Evenson 20 Oct '11

20 Oct '11

In preparation for the release of ABCL-1.0.0 on October 22, 2011 I have [created the 1.0.x branch][1]. It seems to do pleasantly well under Java 7, so I have removed the compile time warning. [1]: svn://common-lisp.net/project/armedbear/svn/branches/1.0.x/abcl

1 1

[armedbear-devel] closure-html compiling again (was Re: SVN r13600 breaks clean trunk Build)
by Mark Evenson 20 Oct '11

20 Oct '11

On Sep 20, 2011, at 15:51 , Erik Huelsmann wrote: > Hi Mark, > > On Tue, Sep 20, 2011 at 11:22 AM, Mark Evenson <evenson.not.org(a)gmail.com> wrote: > > On Sep 20, 2011, at 10:34 , ehuels(a)gmail.com wrote: > > > Hi Mark, > > > > You fixed it already, I see. Sorry about the breakage. Which library fails next? :-) > > > > Unfortunately, I'm having problems compiling closure-common (closure-common-20101107-git), upon which closure-html depends: > With the abcl-1.0.x branch, closure-html from Quicklisp is compiling again.

1 0

[armedbear-devel] packaging of abcl 0.27.0
by Ljungberg, Magnus - 0661 - MITLL 20 Oct '11

20 Oct '11

In the past you've published abcl as a maven artifact over at sonatype.org, something I benefit from daily for my project. Can you please continue that for new releases? Thanks Magnus Ljungberg

4 3

[armedbear-devel] Maxima, once again
by Reinhard Oldenburg 20 Oct '11

20 Oct '11

Hi everybody, I check the staus of ABCL every few month to see how well it runs Maxima. The findings are, that .... - The testsuite goes through, but ABL is more then 10 times slower than native Lisps. - However, tehre are problems with several packages, e.g. load(fmin_cobyla); fails - Loading Maxima with ASDF fails. - There is still no way to produce an image file. Last year I was told that ABCL can load from URL, but I fear that doing this takes a couple of days 8which I can't afford). So is seems that there is not yet a good way to write Applets using Maxima. If anyone can produce a maxima.jar, I'd be happy. Any comments? reinhard

2 1

[armedbear-devel] abcl-1.0 -- The Manual
by Mark Evenson 23 Sep '11

23 Sep '11

We have always informally answered the question as to when ABCL would deserve a 1.0 release number when it was a conforming ANSI implementation. Since we are more or less ANSI complete at this point from a feature standpoint with the recent implementation of the long form of DEFINE-METHOD-COMBINATION, it makes some sense to push for an ABCL 1.0 release which we could potentially announce at ECLM 2011, since Erik, Alessio, and I will attend. The [CLHS outlines the requirements for conforming implementation][1] as including […] 1.5.1.2 Documentation of Implementation-Dependent Features 1.5.1.3 Documentation of Extensions […] 1.5.1.5 Conformance Statement […] [1]: http://www.lispworks.com/documentation/HyperSpec/Body/01_ea.htm To this end, I started an [ABCL manual written in LaTex][2]. With LaTeX we have the ability to include diagrams rather easily, something that despite Texinfo's claims to the contrary, I think should not be prohibited in documentation. I have not found a suitable LaTex2HTML translator (although many exist), but would probably approach this as a problem to be addressed after we produce an initial manual. [2]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/manual To render the manual in PDF, install [TeX Live 2011][3], and simply issue cmd$ pdflatex abcl.tex in a the manual directory. [3]: http://www.tug.org/texlive/ The structure of the manual is roughly in place, from which I have been cribbing ideas from the [SBCL][4] and [CCL][5] manuals [4]: http://www.sbcl.org/manual/ [5]: http://ccl.clozure.com/ccl-documentation.html but have still not committed to a final structure. I have started to create LaTeX macros in 'abcl.sty' to create an environment in which contributors can work on the manual without necessarily understanding that much of LaTeX by creating a semantics/presentation layer. Currently, this mostly consists of ways of marking up text as being Lisp, Java, or Shell source code. I plan to at least to produce a method to indicate that text refers to a given Lisp symbol in a given package so a reasonable cross referencing system can produce an index and page references. A tension exists in the current effort between being a manual, and a tutorial with examples. I would propose we concentrate on the manual aspects, while allowing inclusion of examples as the existing text gives a pretty reasonable introduction to extending ABCL via Java that would be a shame to lose. But I could be persuaded to remove or move to an appendix if we wanted to emphasize concision. Since TeX easily allows comments in documents with '%' characters, one can find various notes and ideas present in the current document to bring one up to speed on what I have in mind. I intend to document the JAVA, EXTENSIONS, and SYSTEM packages by adding doctstrings to out implementation for all exported symbols, following the convention that there should be a short synopsis statement for the function as the first sentence, followed by a newline, followed by more explicit text. I intend to write a Lisp tool that "scrapes" these docstrings from a live ABCL process, transforming into the appropriate LaTeX source which we would then include in the manual. This isn't sufficient but necessary in my opinion to meet the criteria of documenting implementation dependent features. If someone wished to help, getting our exported docstrings in order would be a task somewhat orthogonal to the production of the manual. So, I would invite potential contributors to the manual to look at the source, build the PDF version, and consider what sections they would like to tackle. Then we can divide this manual up into sections by file, so people can work somewhat in isolation. As an informal deadline, I think we should have a plan in place by October 1 to have a chance of finishing things by ECLM 2011. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] FASL Format bump on trunk
by Erik Huelsmann 20 Sep '11

20 Sep '11

Everybody running off trunk should be warned that I just updated the FASL format number: the fixes for CLOSURE-HTML changed the format in a backward incompatible way. The new format number is 38, the old one 37. Format bumps are relatively rare and format 37 has been in use for quite a while now. I'm sorry for the inconvenience caused, if any. Bye, Erik.

1 0

Re: [armedbear-devel] SVN r13600 breaks clean trunk Build
by ehuels＠gmail.com 20 Sep '11

20 Sep '11

Hi Mark, You fixed it already, I see. Sorry about the breakage. Which library fails next? :-) bye, Erik. Sent from my Nokia phone -----Original Message----- From: Mark Evenson Sent: 20/09/2011, 10:00 To: Armed Bear Subject: [armedbear-devel] SVN r13600 breaks clean trunk Build Unfortunately, the recent commit to fix the compilation of circularity in FASL has broken the compilation of jvm.lisp when building from scratch. It is not immediately obvious to me how to fix this, as it seems to involve the forms emitted by the compiler. … ; Compiling /home/evenson/work/abcl/src/org/armedbear/lisp/jvm.lisp ... ; (IN-PACKAGE "JVM") ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp (0.0010 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp (0.074 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp (0.095 seconds) ; (DEFVAR *CLOSURE-VARIABLES* ...) ; (DEFVAR *ENABLE-DFORMAT* ...) ; (DEFVAR *CALLBACKS* ...) ; (DECLAIM (INLINE INVOKE-CALLBACKS)) ; (DEFUN INVOKE-CALLBACKS ...) ; (DEFMACRO DFORMAT ...) ; (DECLAIM (INLINE U2 ...)) ; (DEFKNOWN U2 ...) ; (DEFUN U2 ...) ; (DEFKNOWN S1 ...) ; (DEFUN S1 ...) ; (DEFKNOWN S2 ...) ; (DEFUN S2 ...) ; (DEFMACRO WITH-SAVED-COMPILER-POLICY ...) ; (DEFVAR *COMPILER-DEBUG* ...) ; (DEFVAR *POOL* ...) ; (DEFVAR *STATIC-CODE* ...) ; (DEFVAR *CLASS-FILE* ...) ; (DEFVAR *EXTERNALIZED-OBJECTS* ...) ; (DEFVAR *DECLARED-FUNCTIONS* ...) ; (DEFSTRUCT (ABCL-CLASS-FILE # ...) ...) ; (DEFUN CLASS-NAME-FROM-FILESPEC ...) ; (DEFUN MAKE-UNIQUE-CLASS-NAME ...) 69.461 seconds real time 150877519 cons cells PROGRAM-ERROR: Wrong number of arguments for #<DUMP-OBJECT {1BE20C}>. -- "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

2 1

[armedbear-devel] SVN r13600 breaks clean trunk Build
by Mark Evenson 20 Sep '11

20 Sep '11

Unfortunately, the recent commit to fix the compilation of circularity in FASL has broken the compilation of jvm.lisp when building from scratch. It is not immediately obvious to me how to fix this, as it seems to involve the forms emitted by the compiler. … ; Compiling /home/evenson/work/abcl/src/org/armedbear/lisp/jvm.lisp ... ; (IN-PACKAGE "JVM") ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/compiler-error.lisp (0.0010 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-instructions.lisp (0.074 seconds) ; Loading /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp ... ; Loaded /home/evenson/work/abcl/src/org/armedbear/lisp/jvm-class-file.lisp (0.095 seconds) ; (DEFVAR *CLOSURE-VARIABLES* ...) ; (DEFVAR *ENABLE-DFORMAT* ...) ; (DEFVAR *CALLBACKS* ...) ; (DECLAIM (INLINE INVOKE-CALLBACKS)) ; (DEFUN INVOKE-CALLBACKS ...) ; (DEFMACRO DFORMAT ...) ; (DECLAIM (INLINE U2 ...)) ; (DEFKNOWN U2 ...) ; (DEFUN U2 ...) ; (DEFKNOWN S1 ...) ; (DEFUN S1 ...) ; (DEFKNOWN S2 ...) ; (DEFUN S2 ...) ; (DEFMACRO WITH-SAVED-COMPILER-POLICY ...) ; (DEFVAR *COMPILER-DEBUG* ...) ; (DEFVAR *POOL* ...) ; (DEFVAR *STATIC-CODE* ...) ; (DEFVAR *CLASS-FILE* ...) ; (DEFVAR *EXTERNALIZED-OBJECTS* ...) ; (DEFVAR *DECLARED-FUNCTIONS* ...) ; (DEFSTRUCT (ABCL-CLASS-FILE # ...) ...) ; (DEFUN CLASS-NAME-FROM-FILESPEC ...) ; (DEFUN MAKE-UNIQUE-CLASS-NAME ...) 69.461 seconds real time 150877519 cons cells PROGRAM-ERROR: Wrong number of arguments for #<DUMP-OBJECT {1BE20C}>. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Bug in handling of keyword arguments
by Eric Marsden 19 Sep '11

19 Sep '11

Hi, ,---- | Armed Bear Common Lisp 0.27.0-dev-svn-13545M | Java 1.6.0_23 Sun Microsystems Inc. | OpenJDK 64-Bit Server VM | Low-level initialization completed in 1.02 seconds. | Startup completed in 1.96 seconds. | CL-USER(10): (defun foo (a b) | (find a '(1 2 3) b 1)) | FOO | CL-USER(11): (compile 'foo) | #<THREAD "interpreter" {12BC8F01}>: Debugger invoked on condition of type PROGRAM-ERROR | Unrecognized keyword argument B | Restarts: | 0: TOP-LEVEL Return to top level. `---- I should be able to invoke FOO with :start or :end values for B. -- Eric Marsden

2 2

[armedbear-devel] BUG: Stack inconsistency (java.lang.VerifyError)
by eric.marsden＠free.fr 06 Sep '11

06 Sep '11

Hi, Attempting to use ABCL to build a current development checkout of SBCL on Linux/i686, I encountered the following error. ABCL builds SBCL on Linux/AMD64 correctly, with the same openjdk version. ------------------ file foo.lisp ------------------------------------------ (in-package :cl-user) (defun symbolicate (&rest things) (let* ((length (reduce #'+ things :key (lambda (x) (length (string x))))) (name (make-array length :element-type 'character))) (let ((index 0)) (dolist (thing things (values (intern name))) (let* ((x (string thing)) (len (length x))) (replace name x :start1 index) (incf index len)))))) (macrolet ((def (name &optional variant) `(defun ,(if variant (symbolicate name "/" variant) name) (function mutex) (declare (function function)) (flet ((%call-with-system-mutex () (dx-let (got-it) (unwind-protect (when (setf got-it (get-mutex mutex)) (funcall function)) (when got-it (release-mutex mutex)))))) (declare (inline %call-with-system-mutex)) ,(ecase variant (:without-gcing `(without-gcing (%call-with-system-mutex))) (:allow-with-interrupts `(without-interrupts (allow-with-interrupts (%call-with-system-mutex)))) ((nil) `(without-interrupts (%call-with-system-mutex)))))))) (def call-with-system-mutex) (def call-with-system-mutex :without-gcing) (def call-with-system-mutex :allow-with-interrupts)) ---------------------- Armed Bear Common Lisp 0.13.0-dev Java 1.6.0_23 Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 0.344 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/tmp/foo") ; Compiling /tmp/foo.lisp ... ; (IN-PACKAGE :CL-USER) ; (DEF CALL-WITH-SYSTEM-MUTEX) ; in (MACROLET (#) ...) ; Caught STYLE-WARNING: ; Undefined variable: GOT-IT Stack inconsistency at index 63: found 3, expected 1. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Inconsistent stack height 1 != 3 at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.getConstructor(Class.java:1674) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1147) at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1074) at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:186) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_4.execute(compile-file.lisp:63) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.compile_file_8.execute(compile-file.lisp:103) at org.armedbear.lisp.LispThread.execute(LispThread.java:680) Eric

1 1

[armedbear-devel] [ANNOUNCE] ABCL 0.27.0 released
by Erik Huelsmann 03 Sep '11

03 Sep '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.27.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among other things - wider compatibility for Quicklisp encapsulated systems basedon reports for problems with ABCL: fixes for PARENSCRIPT, NAMED-READTABLES and CL-INTERPOL (CL-UNICODE fix). Additionally, ABCL has regained the ability to build SBCL. The release notes can be found at: http://common-lisp.net/project/armedbear/release-notes-0.27.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-src-0.27.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.ta… http://common-lisp.net/project/armedbear/0.27.0/releases/abcl-src-0.27.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.ta… http://common-lisp.net/project/armedbear/releases/0.27.0/abcl-bin-0.27.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.27.0.zip.asc

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13546 - trunk/abcl
by Erik Huelsmann 29 Aug '11

29 Aug '11

Hi Mark, Could you add the changes related to JSS, JAR packaging and the like that you have been putting on trunk? The current list is compiled based on r13382 (branch point 0.26) up to HEAD, manually eliminating the revisions which have been merged into the 0.26 branch. Looking at the list, I'd like to create another release soon: the pretty printer fixes haven't made it in a public release yet, nor have many of the JAR packaging fixes and improvements that you committed. As always, if you see things differently, discussion welcome, of course! Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 28, 2011 at 10:36 PM Subject: [armedbear-cvs] r13546 - trunk/abcl To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 28 13:36:34 2011 New Revision: 13546 Log: More CHANGES updates. Modified: trunk/abcl/CHANGES Modified: trunk/abcl/CHANGES ============================================================================== --- trunk/abcl/CHANGES Sun Aug 28 13:11:41 2011 (r13545) +++ trunk/abcl/CHANGES Sun Aug 28 13:36:34 2011 (r13546) @@ -14,6 +14,13 @@ Changes ------- + * Renamed LispObject.writeToString() method to (more lispy) printObject() + + * New LispObject.princToString() for user readable output + + * Changed behaviour of LispObject.unreadableString() to signal + errors when *PRINT-READABLY* is non-NIL + * Static initializers moved to <clinit>() (java: static { }) to prevent repeated execution when invoking the constructor multiple times @@ -24,6 +31,11 @@ * File compiler (COMPILE-FILE) clean-ups + * When calling a function with the wrong number of arguments, + report the expected (range) of arguments + + * Upgraded ASDF to 2.017 + Fixes ----- @@ -39,6 +51,15 @@ * [ticket #163] Local functions shadow global macro and function bindings (fixes PARENSCRIPT support) + * [ticket 158] Readable printing of the string "#<abc>" does not signal + a PRINT-NOT-READABLE error anymore + + * Fixed SYNTAX.SHARP-BACKSLASH.6 and SYNTAX.SHARP-BACKSLASH.7 + + * Fixed many PPRINT.* test suite failures + + * [ticket #151] LOAD fails for whitespace in JAR-PATHNAME + Version 0.26.2 ============== _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

2 1

[armedbear-devel] Compiling large Java-classes slow?
by Ole Myren Rohne 24 Aug '11

24 Aug '11

Hi ABCL-developers, Is there a recent change (since May?) that would have made compiling files containing large wrapped Java-classes excessively slow? If so, is there any hope of this eventually improving? Ole

2 3

[armedbear-devel] More efficient compilation of forward references -- WAS: r13536 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 23 Aug '11

23 Aug '11

When you look at the ### FASLATONCE comments, you may be wondering what I'm doing here. Well, I'm looking at a way to make our own compilation much faster again, but also to make our compiled code much faster. The problem - as I understand it now - with our slow compilation since the introduction of the jvm-class-file.lisp file is NOT so much the fact that we store lots of data in structures now (I thought it was when I did that work though). Rather, my current understanding is that the declaration order of functions in a file is extremely important for the performance of said fasl: Backward referenced functions (those being defined first and called from code "further down the file") are being called through direct calls of the execute() method of a final static field in the class of the calling function. Since the value is final, the JVM is allowed to assume the jump is always going to go to the same class's execute() method which can be very easily optimized. Forward referenced functions (those being called before they are defined -- although still defined in the same file) are being resolved through a call to the getSymbolFunctionOrDie() function of the function's symbol. Since that variable is *not* final, the call to the return value of getSymbolFunctionOrDie() can't be as easily JITted. Hence my idea to compile all toplevel compilands *after* the entire file has been processed and all toplevel functions have been discovered. At that time, the functions can be compiled and all forward references can be resolved and hard coded using final static fields. However: this introduces the risk of circularity during fasl loading. My remarks relate to that problem. Bye, Erik. On Tue, Aug 23, 2011 at 11:34 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Tue Aug 23 14:34:33 2011 > New Revision: 13536 > > Log: > Move more static field initialization to the static class initializer > <clinit>() code. > > Additionally, place some remarks where I expect issues once I start > compiling forward references the same way as backward references. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 13:35:32 2011 (r13535) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Tue Aug 23 > 14:34:33 2011 (r13536) > @@ -1392,7 +1392,7 @@ > (local-function-compiland local-function)))) > (field-name (local-function-field local-function))) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > ;; fixme *declare-inline* > (declare-field field-name +lisp-object+) > (emit-new class-name) > @@ -1416,7 +1416,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; strings may contain evaluated bits which may depend on > ;; previous statements > (declare-field g +lisp-object+) > @@ -1432,7 +1432,7 @@ > (with-code-to-method > (*class-file* > (if *declare-inline* *method* > - (abcl-class-file-constructor *class-file*))) > + (abcl-class-file-static-initializer *class-file*))) > ;; The readObjectFromString call may require evaluation of > ;; lisp code in the string (think #.() syntax), of which the outcome > ;; may depend on something which was declared inline > @@ -1455,7 +1455,7 @@ > ;; fixme *declare-inline*? > (remember g obj) > (with-code-to-method > - (*class-file* (abcl-class-file-constructor *class-file*)) > + (*class-file* (abcl-class-file-static-initializer *class-file*)) > (declare-field g +lisp-object+) > (emit 'ldc (pool-string g)) > (emit-invokestatic +lisp+ "recall" > @@ -4149,6 +4149,11 @@ > (emit-load-local-function local-function) > (emit-move-from-stack target)) > ((inline-ok name) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-function name) +lisp-object+) > (emit-move-from-stack target)) > @@ -4166,6 +4171,11 @@ > (emit-load-local-function local-function)) > ((and (member name *functions-defined-in-current-file* :test > #'equal) > (not (notinline-p name))) > + ;; ### FASLATONCE: when compiling fasl functions after the > + ;; full fasl has been processed, forward referenced functions > + ;; may not be available during the load process > + ;; This case is particularly triggered with circular referencing > + ;; functions, both marked as 'notinline' > (emit-getstatic *this-class* > (declare-setf-function name) +lisp-object+) > (emit-move-from-stack target)) > > _______________________________________________ > 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] ticket #124: SBCL build host / "the" pretty printer issue
by Erik Huelsmann 23 Aug '11

23 Aug '11

Talking to Mark on IRC, we were discussing about how to restore ABCL's capability of being an SBCL buildhost. We were a buildhost some years back: it was one of the things Peter Graves used to stress test ABCL's conformance. However, we've not been able to build SBCL for quite some time now, as ticket #124 [1] witnesses. In IRC Mark kept referring to this problem as "the issue with our Gray streams conformance". I'm writing this mail to explain that our "Gray streams conformance" is not the issue that's causing this breakage. Basically, we have two issues with our streams: 1. Gray streams conformance 2. Our pretty printer implementation While our Gray streams conformance may not be ideal - I'd have to investigate where we stand exactly on that issue - our pretty printer is breaking our ability to build SBCL. (Our Gray streams conformance is good enough to support flexi-streams, so, that's good enough for me.) The usual way a pretty printer is implemented -and that's the way SBCL implements it as well- is by wrapping a stream around the stream which is being pretty printed to. That way, the pretty printer receives all output being printed and is in a position to appropriately add tabbing, indenting and other formatting. Then it sends the output to the actual target stream. Now, our implementation is a little bit different, but different enough to cause problems, I guess. We wrap the stream being printed to, however, we wrap the stream with a structure object instead of another stream. Then, in order to mitigate the negative effects from our wrapping using a structure-object (XP-STRUCTURE). On the Java side of things, input values are being checked to be a STREAM, however, this XP-STRUCTURE isn't a derived class from a class which is a stream. So, our Java side type checking fails. Any conforming code should expect the stream argument to PRINT-OBJECT to be a stream (but it cannot make more assumptions than that), an expectation we violate. Possibly, there are other spots where we fail to meet the STREAMP checks. My idea to resolve the situation would be to create streams the way SBCL does it: SBCL knows two types of streams: Gray streams and ansi-streams. Anything not an ansi-stream follows the Gray stream dispatch path. ANSI-STREAM is a structure-object which holds slots for input and output functions. The pretty printer structure includes the ANSI-STREAM structure by virtue of which it becomes a stream itself. The STREAM type is simply DEFTYPEd to be equal to ANSI-STREAM. The I/O routines (it only sets the output routine) simply forwards its writes to the to the wrapped stream. This way, their pretty printer wrapper stream doesn't violate any of the expectations user code may have about the STREAM argument of PRINT-OBJECT. My idea would be that we should investigate if and how we can implement a similar approach. Mark or anybody else, could you comment on the above? Bye, Erik. [1] http://trac.common-lisp.net/armedbear/ticket/124

1 0

[armedbear-devel] Read tables
by Blake McBride 22 Aug '11

22 Aug '11

Dear Erik, Based on your input, I have been thinking more about making my interface case sensitive. It would be better. After doing a little research I tried: (setf (readtable-case *readtable*) :invert) This seems to have made all the standard stuff ("car, cons, etc.") lowercase as I'd prefer. After that I tried creating lists: (setq x '(HELLO There how)) and the case seems to be preserved - not inverted. I also tried things like: (defun fun (x) (+ 1 x)) (defun Fun (x) (+ 2 x)) (defun FUN (x) (+ 3 x)) And it worked as expected. I'm a bit confused. Why aren't symbols (as in '(HELLO There how)) inverted? (I understand that :invert doesn't change case on mixed case symbols but then all upper or all lower should be inverted.) Is *print-case* being affected? At first test, it seems like :invert does exactly what most people want - case sensitive lisp that has system symbols all lower case. Are there instances in which this doesn't work? Will this affect lisp-java usage when it comes to case? Any pointers would be appreciated. Thanks. Blake McBride

2 1

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #164: Cannot quit SLIME REPL
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:21, armedbear <armedbear-devel(a)common-lisp.net> wrote: > Further analysis reveals that ProcessingTerminated is a pure Java-side > construct so there is currently no way to hook in from Lisp, so that part > of the concern is unfounded. > Still, calling System.exit() seems really wrong. Need to reconsider the > reason under which ProcessingTerminated exception was introduced. Sounds like ext:exit has been converted to do ProcessingTerminated, but it shouldn't actually do that. This strongly suggests that too much has been changed over to ProcessingTerminated; the original reason for converting some uses over is still valid, because in order to work as a library, abcl should avoid exitting.

3 5

Re: [armedbear-devel] [armedbear-cvs] r13530 - trunk/abcl/src/org/armedbear/lisp
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:52, <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Mon Aug 22 02:52:28 2011 > New Revision: 13530 > > Log: > All LispThread objects can act on a ProcessingTerminated exception. > Without this modifications, threads created with the > THREADS:MAKE-THREADS cannot successfully call the EXT:QUIT or EXT:EXIT > functions. This prevented the SLIME quit implementation from > successfully quitting implementations. > Note that all threads can always execute a form like > (jstatic "exit" "java.lang.System" 0) > to uncermoniously exit the JVM, so there is nothing gained > security-wise by preventing threads from using the official Lisp > interfaces. > + catch (ProcessingTerminated e) { > + System.exit(e.getStatus()); > + } This looks.. ..unfortunate. We should not get into a situation where a LispThread catches this exception, the exception is supposed to be used for terminating the repl if it can't load. It's fine as a stopgap measure, but exit requests from threads shouldn't end up throwing that exception.

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13516 - svn:log
by Erik Huelsmann 20 Aug '11

20 Aug '11

Hi Alessio, Thanks for the read tables research last week. I went ahead and implemented a fix. Could you confirm the fix works for your testing? Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sat, Aug 20, 2011 at 12:06 PM Subject: [armedbear-cvs] r13516 - svn:log To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Revision: 13516 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1,3 @@ -Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. \ No newline at end of file +Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. + +Note: Fix based on research by Alessio Stalla. \ No newline at end of file _______________________________________________ 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] type mismatch for "asList"
by Patrice Seyed 19 Aug '11

19 Aug '11

Hello, With the following expression: (#"asList" 'Arrays "test") I get the error: Java exception 'SchemeException: java.lang.IllegalArgumentException: argument type mismatch ARGUMENT MISMATCH for method public static java.util.List java.util.Arrays.asList(java.lang.Object[]) called with ("test")'. [Condition of type JAVA-EXCEPTION] But "test" is of java.lang.String, which is a subclass of java.lang.Object, so I'm not sure what the mismatch is. Any help appreciated. Patrice

2 1

[armedbear-devel] Using ABCL in Android
by Joe Mendoza 18 Aug '11

18 Aug '11

To ABCL developers, I tried to use the java to lisp interpreter in Android, however, I received an error message; "Could not find method java.beans.Introspector.getBeanInfo, referenced from method org.armedbear.lisp.Java.getPropertyDescriptor". I've learned that Android doesn't support the use of Java beans. Would there be another way to compile ABCL without implementing Java beans? Thanks, Joe

3 4

[armedbear-devel] anonymous inner class in abcl
by Patrice Seyed 17 Aug '11

17 Aug '11

Right, Hello abcl developers, Let's say I want to implement an anonymous inner class, just for example ActionListener with method actionPerformed: JButton button = new JButton("Enter"); button.addActionListener(new ActionListener (){ public void actionPerformed(ActionEvent e){ System.out.println("The Enter button was pressed"); } }); What is the best way to do this in abcl? Cheers, Patrice On Tue, Aug 16, 2011 at 4:09 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com>wrote: > > > On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > >> How about a boolean? >> > > (make-immediate-object nil :boolean) > (make-immediate-object t :boolean) > > >> Next, I'm trying to work my way up to defining anonymous inner classes >> from within abcl. >> > > That's a bit more problematic, at least for me. > Can you write up a specific small code example you want to implement and > send a note the armedbear-devel(a)common-lisp.net asking for what the > recommended approach would be? > > -Alan > > > >> >> Patrice >> >> On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg < >> alanruttenberg(a)gmail.com> wrote: >> >>> null = (make-immediate-object nil :ref) >>> >>> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> >>> wrote: >>> > Alan, >>> > >>> > If I wanted to pass as an argument that I would specify as null in >>> > java, from abcl to java, how would I do that? >>> > >>> > For example a method called method1 that takes two argument that I >>> > want to pass a string and the second argument null: >>> > >>> > (#"method1" 'ClassName "string" nil) >>> > >>> > If I specify nil as i did here I get a java exception "argument type >>> mismatch". >>> > >>> > Patrice >>> > >>> >> >> >

3 2

Re: [armedbear-devel] lsw2
by Alan Ruttenberg 17 Aug '11

17 Aug '11

On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > How about a boolean? > (make-immediate-object nil :boolean) (make-immediate-object t :boolean) > Next, I'm trying to work my way up to defining anonymous inner classes from > within abcl. > That's a bit more problematic, at least for me. Can you write up a specific small code example you want to implement and send a note the armedbear-devel(a)common-lisp.net asking for what the recommended approach would be? -Alan > > Patrice > > On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com > > wrote: > >> null = (make-immediate-object nil :ref) >> >> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: >> > Alan, >> > >> > If I wanted to pass as an argument that I would specify as null in >> > java, from abcl to java, how would I do that? >> > >> > For example a method called method1 that takes two argument that I >> > want to pass a string and the second argument null: >> > >> > (#"method1" 'ClassName "string" nil) >> > >> > If I specify nil as i did here I get a java exception "argument type >> mismatch". >> > >> > Patrice >> > >> > >

2 1

[armedbear-devel] readtable-case :invert does not invert uninterned symbols
by Ole Arndt 16 Aug '11

16 Aug '11

This prevents loading a newer parenscript, which uses an inverted readtable case via named-readtables: Armed Bear Common Lisp 0.26.0-dev-svn-13273 Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.712 seconds. Startup completed in 3.154 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf (readtable-case *readtable*) :invert) :invert CL-USER(2): (string :cl) "CL" CL-USER(3): (string '#:cl) "cl" Cheers Ole -- Ole Arndt http://www.sugarshark.com

3 5

[armedbear-devel] Refactoring compile-file.lisp
by Erik Huelsmann 14 Aug '11

14 Aug '11

Yesterday while refactoring compiler-pass2 I found that moving a function from the top of the file to the bottom can cause serious performance degradation (and performance win, the other way around). That somehow doesn't feel like what one would expect of a good enough compiler these days. To see if I can create a change to our file-compiler which doesn't exhibit this issue, I'm preparing an experiment where COMPILE-FILE will batch up all class files to be generated until the end of the processing of the input file. Then, all functions will be known in advance and calling functions being forward-referenced should have the same properties as calling backward referenced functions. In order to be able to even start working on the above, compile-file.lisp should at least be readable and understandable. My refactoring of today is in preparation of the experiment (which I could conduct on a branch), to clean up compile-file.lisp and cut it down to readable chunks of code with well-defined calling conventions. Just thought I'd explain my current work on compile-file.lisp. Bye, Erik.

1 0

[armedbear-devel] Bad Windows regression fixed; time for abcl-0.26.2?
by Mark Evenson 11 Aug '11

11 Aug '11

Today, [I fixed a bad bug in which fasls with whitespace in their path under Windows were failing to load][13460]. Given how common whitespace in pathnames under Windows should be, I would suggest that we should make an abcl-0.26.2 release in the next week or so. Maybe we can use this as an exercise for someone other than Erik to make a release (namely me)? I think Erik has signed my PGP key at this point, although I haven't checked. [13460]: http://trac.common-lisp.net/armedbear/changeset/13460 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 07 Aug '11

07 Aug '11

Hi Mark, Maybe you want to check if CL-CONTAINERS now wants to load? At least we now support SETF of APPLY with user-defined functions. And, yes, I did check that the order of evaluation of the arguments remains in tact: (defvar b 0) --> B (defun m () (incf b)) --> M (defvar v nil) -->V (defun (SETF MYFUN) (new-value &rest rest) (setf v new-value)) --> (SETF MYFUN) (setf (apply #'myfun (list (m) (m) (m))) (m)) --> 4 Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 7, 2011 at 10:18 PM Subject: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 7 13:17:59 2011 New Revision: 13450 Log: Fix #141 (SETF of APPLY not working with arbitrary function) by "adding" the feature. Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp ============================================================================== --- trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 07:20:58 2011 (r13449) +++ trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 13:17:59 2011 (r13450) @@ -88,11 +88,6 @@ `(getf ,get ,ptemp ,@(if default `(,def-temp))))))) (define-setf-expander apply (functionoid &rest args) - (unless (and (listp functionoid) - (= (length functionoid) 2) - (eq (first functionoid) 'function) - (memq (second functionoid) '(aref bit sbit))) - (error "SETF of APPLY is only defined for #'AREF, #'BIT and #'SBIT.")) (let ((function (second functionoid)) (new-var (gensym)) (vars (make-gensym-list (length args)))) _______________________________________________ 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] Building support for inspection of local variables in (compiled) code
by Erik Huelsmann 07 Aug '11

07 Aug '11

This summer, Mark and I met in person. We discussed several things, we wanted to improve on ABCL. One of the most important things to improve on ABCL, or so it seems to us, is to be able to inspect - given high enough debug settings - the locals in the current stackframe. Since I have had a good idea how to do this for a long time now, I'm writing down how I want to do it, making it work for both compiled and interpreted functions. The basic requirements are simple: while walking the stack, being able to focus on any single frame and retrieving the locals from it, as well as their values for inspection, of course. Being able to STEP code isn't a requirement - although that may be subject to another change later. My idea is really actually very simple. We already have an interpreter which creates Environment objects to record the lexical variables and their values (as well as temporary "specialness"). The missing bit is the link between the environment and the stack frame. Note that within the scope of a single stack frame, multiple environments may be cycled through, one after another. This typically happens with new binding blocks such as DO/DO*, LET/LET*, M-V-B, etc. Since this information is all readily available, I'm envisioning a method on LispThread which sets the environment of the current stack frame. Then, when the debugger is invoked, the environment object of the stack frame to be inspected can be retrieved and the bindings referred to it can be walked to print the state of the lexical environment. The impact of this change is relatively limited: everywhere we find a "new Environment", we want to review if adding the environment to the stackframe is applicable. So far so good. Now about compiled code. It doesn't have Environment objects, because the environment is hard coded into the compiled functions. If we were to step away from that concept, we might as well completely stop compiling the program. So now what? I see a middle road: values reachable through an Environment are stored in a linked list of Binding objects. We could create these Binding objects, adding them to the environment, but still keeping a reference to them. Then, our performance would only suffer a single additional level of indirection. The thing to be figured out would be how to 'model' closures. The environment model works well with closures in interpreted mode, but with this 'faked' environment it works less well. One solution would be to add the closure variables to the Environment upon function entry. That might cost some performance, but would require no access to the outer Environment. Other solutions - which I haven't evaluated yet - might involve the array of ClosureBindings, which is a way to carry information from one closure to another. Comments? Bye, Erik.

1 0

[armedbear-devel] About fixing #90 (resetSpecialBindings efficiency)
by Erik Huelsmann 07 Aug '11

07 Aug '11

Yesterday, I was looking at some of our tickets and decided to hack the compiler to support ticket #90 [1]. As with earlier special bindings fixes, I've tested this feature on Maxima which - at least in older versions - is highly sensible to the performance of special variables. The performance test shows no relevant difference in performance between the clean and the patched version (1140sec patched, 1087sec unpatched - I attribute the difference to statistical variation). So, the question is: even though the generated code is cleaner and smaller, do we want to make the compiler more complex to support it? The patch in question is attached for those interested. Bye, Erik. [1] http://trac.common-lisp.net/armedbear/ticket/90

1 0

Re: [armedbear-devel] ABCL threading questions
by David Wang 04 Aug '11

04 Aug '11

Thanks for that very helpful reply. I'll look into both threading libraries. In the meantime, I created a ".swank.lisp" in my home directory, and added the text "(setf swank:*globally-redirect-io* t)". I restarted emacs and abcl, and now my threading example as well as my actual code works great. I can see all the formats.

1 0

[armedbear-devel] ABCL threading questions
by David Wang 03 Aug '11

03 Aug '11

Hello, I just started working with ABCL's (version 0.26.1) threading functionality and had two questions along those lines: 1. Is there documentation for the threading support somewhere? Even a list of applicable methods and which src files they are defined in would be useful. I already found threads.lisp and abcl's swank interface. I was wondering if there were conditional-variables or conditional-waits, and was just interested in seeing what other functionality is currently supported. 2. This question is a little more complicated, and deals with when (format t "text") will print to std-out/repl and when it won't. When I make a thread that uses (format t ...), I can see the output on the std-out/repl when I run abcl from a terminal, but not when I run it from emacs/slime. I'm guessing the reason for this is that swank doesn't redirect output from the other threads to emacs. a.) Is there a reason for not redirecting this output? i.e. will it interfere with swank's operation? b.) Is there a fix or some places I should look to see if I can write a fix? For those interested in code, I've included some below, the following code starts two threads that send "thread1" and "thread2" messages to one mailbox. It then starts a third thread that reads from that mailbox and prints its contents. The third thread's output can be seen if this code is loaded from a terminal/prompt, but not within slime. - Thank you. ============================================================ (in-package #:cl-user) (defun mailbox-send (mailbox item) "Sends an item into the mailbox, notifying 1 waiter to wake up for retrieval of that object. Copied and fixed from threads.lisp" (threads:synchronized-on mailbox (setf (threads::mailbox-queue mailbox) (nconc (threads::mailbox-queue mailbox) `(,item))) (threads:object-notify mailbox))) (defun mailbox-read (mailbox &key (blocking t)) "Blocks on the mailbox until an item is available for reading. When an item is available, it is returned." (threads:synchronized-on mailbox (when blocking (loop (unless (threads:mailbox-empty-p mailbox) (return)) (threads:object-wait mailbox))) (if (threads:mailbox-empty-p mailbox) (values nil nil) (values (pop (threads::mailbox-queue mailbox)) t)) )) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; THREAD TEST (defparameter *mailbox* (threads:make-mailbox)) (defvar *stop-mailbox* (threads:make-mailbox)) (defun send-stop () (mailbox-send *stop-mailbox* :stop)) (defun read-stop () (eq (threads:mailbox-peek *stop-mailbox*) :stop)) (defun clear-stop () (threads:synchronized-on *stop-mailbox* (setf (threads::mailbox-queue *stop-mailbox*) '()))) (defun tfn1 () (loop (when (read-stop) (return)) (mailbox-send *mailbox* (format nil "thread1")) (sleep 1))) (defun tfn2 () (loop (when (read-stop) (return)) (mailbox-send *mailbox* (format nil "thread2")) (sleep 1))) (defun tprint-mailbox () (loop (when (read-stop) (return)) (format t "~s~%" (mailbox-read *mailbox*)))) (defparameter *thread1* (threads:make-thread #'tfn1)) (defparameter *thread2* (threads:make-thread #'tfn2)) (defparameter *thread3* (threads:make-thread #'tprint-mailbox))

2 1

[armedbear-devel] [ANNOUNCE] ABCL 0.26.1 released
by Erik Huelsmann 30 Jul '11

30 Jul '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.26.1 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among lots of other things - a major reduction in the number of failures in the ANSI test suite: dropping from 26 to 16 failures on some systems (of 21699 tests in total). Additionally, ABCL now runs Hunchentoot and several other packages from the top downloads from Quicklisp. http://common-lisp.net/project/armedbear/release-notes-0.26.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-src-0.26.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.zip.asc

2 2

[armedbear-devel] Release 0.26.1 -- status?
by Erik Huelsmann 27 Jul '11

27 Jul '11

The two issues below have been fixed and a few other issues which were resolved in the mean time have been backported to 0.26.1 as well. I was able to build the binaries using the abcl.release target (instead of using the separate abcl.binary.* targets), so it seems all our issues are now fixed and we can move to 0.26.1 next week. Is there anybody with any remaining issues or fixes up his sleeve? Anybody wants to report an issue with the current 0.26.x branch? If not, I'm planning to roll the 0.26.1 release mid next week. Bye, Erik. On Mon, Jul 11, 2011 at 10:18 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi, > > On Mon, Jul 11, 2011 at 7:51 PM, Mark Evenson <evenson(a)panix.com> wrote: > >> On 7/10/11 12:53 AM, Erik Huelsmann wrote: >> >>> I've created the 0.26 release branch after updating CHANGES. >>> >>> If there are no further objections, I'll continue the release process by >>> signing the release. >>> >>> It'd be very helpful if one of the other committers can update the >>> webpages, as I won't have time to do that today or tomorrow. >>> >> >> Unfortunately, the abcl-0.26.0-src release won't build because that >> archive is missing the newly added org.armedbear.lisp.protocol package. >> >> [Fixed and backported to the abcl-0.26.x branch][1]. >> >> [1]: http://trac.common-lisp.net/**armedbear/changeset/13391<http://trac.common-lisp.net/armedbear/changeset/13391> >> >> My vote would be to figure out the stack overflow reported in [ticket >> #154][2] as well as whatever is causing the ansi-interpreted errors that >> Ville is noticing, and move to releasing an abcl-0.26.1. >> >> [2]: http://trac.common-lisp.net/**armedbear/ticket/154<http://trac.common-lisp.net/armedbear/ticket/154> >> >> Erik is on his first day of vacation, and probably has limited upload >> bandwidth, so we may be a bit constrained here. >> > > Yea, it'd be very convenient for me to fix any remaining issues and go for > a 0.26.1 in 2 weeks. Also because my signing key is most easily operated at > home. > > Let's take some time to solve these regressions and scrap the brown paper > bag release :-) > > > Bye, > > > Erik. >

3 3

[armedbear-devel] Adjustable arrays and Java
by Theam Yong Chew 20 Jul '11

20 Jul '11

Hi all, I might have found an interop issue with adjustable arrays. First create an adjustable array with some "empty unfilled space". (defparameter *arr* (let ((x (make-array 0 :fill-pointer 0 :adjustable t :element-type 'base-char))) (vector-push-extend #\a x) (vector-push-extend #\b x) (vector-push-extend #\c x) (vector-push-extend #\d x) x)) Pass the array into Java and copy it back into Lisp. CL-USER> (jcall "getText" (jnew "javax.swing.JButton" *arr*)) "abcd^@^@^@" CL-USER> (jcall "getText" (jnew "javax.swing.JButton" (copy-seq *arr*))) "abcd" I've hand edited the above -- the ^@ character is actually a #\Null of course. More examples: CL-USER> (jnew "java.lang.String" *arr*) #<java.lang.String abcd^@^@^@ {F10A53}> Yong.

2 2

[armedbear-devel] Anybody going to ECLM (Amsterdam) in October?
by Erik Huelsmann 18 Jul '11

18 Jul '11

This morning, I completed my own registration process for my own entry. Will I be seeing any other ABCL users/ developers? Bye, Erik.

3 2

[armedbear-devel] The purpose of the writeToString() method (before we can rename it to printObject() or anything else)
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I thought I'd address ticket #160. That ticket is about %OUTPUT-OBJECT (a primitive) checking the string returned for the non-readable "#<" marker. The problem is that it'll raise a PRINT-NOT-READABLE error on any output containing that marker, even if it's part the serialized presentation which *is* readable, like the uninterned symbol #:|#<32|. The solution I'm aiming at is to make every writeToString() method raise an error when it can't return a readable representation when a readable representation is requested. In preparation of this change I'm investigating the uses of writeToString(). There are 213 occurrences of the string ".writeToString()", many of which are related to the creation of error messages. It'd be particularly impractical to generate errors while creating an error message. On the other hand, there are also uses, such as the one by %OUTPUT-OBJECT which typically *should* obey those values and generate the PRINT-NOT-READABLE error accordingly. So, simply renaming writeToString() to printObject() is still an option. We can even make the printObject() functions check whether they are allowed to return unreadable output. However, it seems to me we additionally need a function which returns - optionally unreadable - output without generating errors. I'm thinking of a function which resets the variables to the values WITH-STANDARD-IO-SYNTAX except that it binds *PRINT-READABLY* to NIL. Maybe that function should be called printUnreadableObject() or something alike. I've also thought about renaming writeToString() to printObjectInternal() and creating a new printObject(boolean requireReadable) which does the required work if the argument is true. Hmm. I hope the above is something people want to comment on. At least I've tried to describe my findings so far. I'm interested to know what others think. Bye, Erik.

1 1

[armedbear-devel] Fixing PRINT.RANDOM-STATE.1
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I was looking at fixing some of our PRINT.* failures in the ansi test suite. Hoping to get an easy start, I started looking PRINT.RANDOM-STATE.1 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but there's no way to extract a 'seed' value from the object to be used to initialize an object into the same state. So, I'm now pondering what action to take. I'm seeing several options: 1. build our own pseudo random number generator with its own random state 2. serialize the Random object to a byte array and use that array as some sort of printed representation (sure, we'll definitely need to look into ways to load) The advantage of (1) is that we can create it all in Lisp, however, it's pure additional code, since we won't be leveraging what's already there. The advantage of (2) is that we can use what Java maintains for us and even better: we can use the random number generator shared between Lisp and Java code. I imagine the disadvantage of this solution is that the serialization of the random state can differ between Java versions and implementations. Any ideas?? Bye, Erik.

4 6

Re: [armedbear-devel] [armedbear-cvs] r13407 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 16 Jul '11

16 Jul '11

This commit fixes a number of test cases related to circularity detection. Some of these cases showed loss of data. Even in the remaining failures, there's no longer any loss of data. The cases that still fail do however show loss of structure. That's on my list to be fixed. As it stands, I'm very happy to finally be fixing this long standing issue in our pretty printer. Bye, Erik. On Fri, Jul 15, 2011 at 11:18 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Jul 15 14:18:28 2011 > New Revision: 13407 > > Log: > Eliminate a series of PPRINT.* ansi test suite failures > (dropping my test failure count from 27 to 20!). > > Modified: > trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 09:34:23 > 2011 (r13406) > +++ trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 14:18:28 > 2011 (r13407) > @@ -611,12 +611,14 @@ > (if (xp-structure-p stream) > (apply fn stream args) > (let ((*abbreviation-happened* nil) > - (sys::*circularity-hash-table* > - (if (and *print-circle* (null sys::*circularity-hash-table*)) > - (make-hash-table :test 'eq) > - sys::*circularity-hash-table*)) > (*result* nil)) > - (xp-print fn (sys:out-synonym-of stream) args) > + (if (and *print-circle* (null sys::*circularity-hash-table*)) > + (let ((sys::*circularity-hash-table* (make-hash-table :test > 'eq))) > + (xp-print fn (make-broadcast-stream) args) > + (let ((sys::*circularity-counter* 0)) > + (xp-print fn (sys:out-synonym-of stream) args) > + )) > + (xp-print fn (sys:out-synonym-of stream) args)) > *result*))) > > (defun xp-print (fn stream args) > > _______________________________________________ > 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] RfC: Renaming LispObject.writeToString() to LispObject.printObject()
by Erik Huelsmann 15 Jul '11

15 Jul '11

Yesterday, we fixed #154 -- the PRINT-OBJECT regression in 0.26.0. Once again, it turns out that our object printing and stringification routines are confusingly named. Additionally, they are also under documented: The writeToString() method calls toString(), but doesn't document the difference between the two. My idea would be to disambiguate the two functions by making writeToString() a java-side PRINT-OBJECT, renaming it to printObject() and documenting that's what it does. Then, probably, the lisp side function %write-to-string should be renamed to %print-object too. Probably, more adjustments are required throughout the code base, but those are probably at the 'implementation detail' level. So, what's your take on it? Bye, Erik.

3 6

[armedbear-devel] Problems with making binary release?
by Mark Evenson 13 Jul '11

13 Jul '11

Erik reported problems making a binary release yesterday on #abcl related to the presence of the version information in the "build/classes/org/armedbear/lisp/version" file. I did indeed change the build process to try to be smarter about needing to create this file by creating the 'abcl.stamp.version.uptodate' task to compare the date of this file to the corresponding class of Version.java. But I can't reproduce a problem here via various permutations of manually removing the file, updating the timestamps of various files via touch(1), etc. If someone can provide instructions to reproduce the error here, I will endeavor to fix it. Maybe this is a problem under MSFT Windows environments? P.S. In looking over the build.xml code, I notice that the use of setting the 'abcl.version' system property to override is slightly sub-optimal which I will fix as well. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

Re: [armedbear-devel] [armedbear-cvs] r13381 - trunk/abcl
by Erik Huelsmann 11 Jul '11

11 Jul '11

I've created the 0.26 release branch after updating CHANGES. If there are no further objections, I'll continue the release process by signing the release. It'd be very helpful if one of the other committers can update the webpages, as I won't have time to do that today or tomorrow. Bye, Erik. On Sun, Jul 10, 2011 at 12:49 AM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sat Jul 9 15:49:04 2011 > New Revision: 13381 > > Log: > Update CHANGES with 0.26.0 items. > > Modified: > trunk/abcl/CHANGES > > Modified: trunk/abcl/CHANGES > > ============================================================================== > --- trunk/abcl/CHANGES Fri Jul 8 01:40:37 2011 (r13380) > +++ trunk/abcl/CHANGES Sat Jul 9 15:49:04 2011 (r13381) > @@ -1,3 +1,91 @@ > +Version 0.26.0 > +============== > +svn://common-lisp.net/project/armedbear/svn/tags/0.26.0/abcl > +(?? ???? 2011) > + > +Features > +-------- > + > + * Add support for weak reference objects > + > + * Add support for finalizers on LispObject derived classes > + > + * Upgrade ASDF to 2.0.16.1 > + > + * #\ reader macro now understands #\uNNNN as unicode codepoints > + > + * JAVA:JRESOLVE-METHOD returns same method as would have been > + called by JAVA:JCALL with the same arguments > + > + * Ant 'update' target to upload application to Google App Engine > + > + * Simple RUN-PROGRAM implementation > + > + * Support for custom slot definitions according to AMOP > + > + * New JAVA:*JAVA-OBJECT-TO-STRING-LENGTH* variable to control pretty > + printing of Java objects > + > + * JSS - more dynamic Lisp/Java FFI - ( > http://lsw2.googlecode.com/svn/trunk) > + imported > + > + * (REQUIRE :ABCL-CONTRIB) adds 'abcl-contrib.jar' to the ASDF search path > + > + * Support for weak references in hash tables through a :WEAKNESS keyword > + argument to MAKE-HASH-TABLE; with SYS:HASH-TABLE-WEAKNESS for > inspection > + > + * Support for loading ASDF systems from JAR archives > + > + * Fast SHA1, SHA256 and SHA512 cryptographic hashes for files > + > + * Beginnings of a manual > + > + * ABCL/ASDF integration with Maven provided systems > + > + * ASDF-JAR:PACKAGE function to package ASDF systems into JARs > + > +Changes > +======= > + > + * Reduced code size in the compiler by changing COMPILE-TEST-FORM > + > + * Enhanced SLIME inspector for JAVA:JAVA-OBJECT > + > + * Reimplemented MERGE-PATHNAMES > + > + * TRANSLATE-PATHNAME aligned with SBCL's behaviour if version is wild > + > + * Removed PRINT-OBJECT methods duplicating Java side code > + > + * Refactored code in SYSTEM:ZIP function > + > + * Allow JCOERCE to convert any number to java.lang.Byte (using > + its two's complement) > + > + * Replace MAKE-IMMEDIATE-OBJECT with +NULL+, +TRUE+ and +FALSE+ constants > + (the only supported ones) > + > + * Better separation between java-collections package and Java FFI > + > + * JAVA:ADD-TO-CLASSPATH is now a generic function > + > +Fixes > +===== > + > + * Google App Engine example fixed > + > + * MAKE-PATHNAME erroneously merges directories as in MERGE-PATHNAME > + > + * Pretty printer routines using SYS:OUTPUT-OBJECT with GRAY-STREAM > + > + * Value of *PRINT-CASE* affects file (to FASL) compilation > + > + * MAKE-PATHNAME ignores version in :DEFAULTS > + > + * URI decoding algorithm in Pathname.java > + > + * JNEW-ARRAY-FROM-ARRAY should create byte[] arrays > + > Version 0.25.0 > ============== > svn://common-lisp.net/project/armedbear/svn/tags/0.25.0/abcl > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

3 5

[armedbear-devel] Spaces in pathnames (jar:file:/x/y/z/a space/...)
by Theam Yong Chew 11 Jul '11

11 Jul '11

Dear ABCL developers, While ABCL can handle spaces (& others) in file pathnames just fine, a space in jar file pathnames still doesn't work. I have confirmed this on Linux, Mac and Windows. An example using Cygwin, $ java -jar abcl.jar Armed Bear Common Lisp 0.24.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.625 seconds. Startup completed in 4.438 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "jar:file:e:/My Dropbox/temp/a space/hello.jar!/hello.abcl") #<THREAD "interpreter" {9AC0F5}>: Debugger invoked on condition of type FILE-ERROR Failed to create URI from 'e:/My Dropbox/temp/a space/hello.jar': Illegal character in opaque part at index 10: file:e:/My Dropbox/temp/a space/hello.jar Restarts: 0: TOP-LEVEL Return to top level. (and yeah, this particular path already has a space character in "My Dropbox" along with my original intended "a space" folder) By the way, thanks for the :wildcard directory support (I've only just tested that, it works for me now!). Yong.

4 15

[armedbear-devel] IRONCLAD cannot be compiled on ABCL now
by Chun Tian (binghe) 08 Jul '11

08 Jul '11

Hi, ABCL developers The crypto library IRONCLAD [1] cannot be compiled on latest ABCL any more, I got following errors when compiling one of its source file. To show the core issue, create a lisp file with following single line and compile it, you'll see the same error: (defconstant a #.(make-array '(8 256) :element-type '(unsigned-byte 32) :initial-element 0)) I don't know how to fix this, have to ask help from ABCL maintainers. Regards, Chun Tian (binghe) [1] http://method-combination.net/lisp/ironclad/ -- Original error outputs: ; Compiling /Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp ... ; (IN-PACKAGE :CRYPTO) ; (DEFTYPE WHIRLPOOL-REGS ...) ; (DEFUN INITIAL-WHIRLPOOL-REGS ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-HASH-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-K-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-STATE-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-L-OFFSET+ ...) ; (DEFCONST +PRISTINE-WHIRLPOOL-REGISTERS+ ...) ; (DEFUN WHIRLPOOLREGS-DIGEST ...) ; (DEFCONSTANT +WHIRLPOOL-ROUNDS+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +RC+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +C-EVEN+ ...) #<THREAD "interpreter" {78D08435}>: Debugger invoked on condition of type PRINT-NOT-READABLE #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> cannot be printed readably. Restarts: 0: TRY-RECOMPILING Try recompiling whirlpool 1: RETRY Retry compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool">. 2: ACCEPT Continue, treating compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool"> as having been successful. 3: TOP-LEVEL Return to top level. [1] CRYPTO(9): :bt 20 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<PRINT-NOT-READABLE {6EA518B6}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:373) 3: org.armedbear.lisp.SimpleArray_UnsignedByte32.writeToString(SimpleArray_UnsignedByte32.java:287) 4: org.armedbear.lisp.Primitives$pf__stream_output_object.execute(Primitives.java:887) 5: (SYSTEM:%STREAM-OUTPUT-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 6: (SYSTEM::DUMP-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 7: (SYSTEM::DUMP-CONS (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 8: (SYSTEM::DUMP-OBJECT (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 9: (SYSTEM::DUMP-CONS (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 10: (SYSTEM::DUMP-OBJECT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 11: (SYSTEM:DUMP-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 12: (SYSTEM::OUTPUT-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 13: (SYSTEM::PROCESS-DEFCONSTANT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 14: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}> NIL) 15: (SYSTEM::PROCESS-TOPLEVEL-FORM (IRONCLAD::DEFCONST IRONCLAD::+C-EVEN+ #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}> NIL) 16: (#<FUNCTION {1F97D330}>) 17: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1F97D330}>) 18: (JVM::%WITH-COMPILATION-UNIT #<FUNCTION {28AA0484}>) 19: (COMPILE-FILE #P"/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/ASDF-TMP-whirlpool.abcl" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.abcl")

4 8

[armedbear-devel] ABCL Usage Problem
by Nishant Trivedi 27 Jun '11

27 Jun '11

Hi All, We are trying to use ABCL for a project which requires a system coded in LISP to talk to another coded in JAVA. We are facing some issues and I would appreciate any help anyone can afford. For this project, I am using Windows 7 platform. I downloaded and built ABCL jar on my machine using ANT. I also setup the required system variables (JAVA_HOME, PATH and CLASSPATH). However, when I try to run the example code to call Java from Lisp ( as described at http://common-lisp.net/project/armedbear/doc/abcl-user.html) I keep getting the following error in ABCL: #<THREAD "interpreter" {13BC30A}>: Debugger invoked on condition of type ERROR Class not found: Main I have also manually compiled the Main.java file and placed the ".class" in the same folder as the lisp file that calls it. I am able to get built-in Java classes like "int". At this point I am stuck and would appreciate if anyone can help me out with this issue. Thanks in advance. Regards, Nishant.

2 1

[armedbear-devel] MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-VALUE conceptual problem
by Mark Evenson 22 Jun '11

22 Jun '11

Today, I spent a bit of time trying to figure out a way to efficiently compute message digest for Quicklisp. After confirming that java.security.MessageDigest implements the required digests, I noticed we didn't have a way to easily get at the underlying Java byte[] array in (SIMPLE-VECTOR (UNSIGNED-BYTE 8)). So, I patched the underlying Java code as attached, and wrote the following routine: (defun sha-256 (path) (let ((buffer (make-array 8192 :element-type '(unsigned-byte 8)) (digest (jstatic "getInstance" "java.security.MessageDigest" "SHA-256"))) (with-open-file (in path :element-type '(unsigned-byte 8)) (loop :for bytes = (read-sequence buffer in) :while (plusp bytes) :do (jcall-raw "update" digest (make-immediate-object buffer) 0 bytes)) (jcall "digest" digest))))) But then I noticed that MAKE-IMMEDIATE-OBJECT calls JOBJECT-LISP-VALUE which makes no conceptual sense. The doc for MAKE-IMMEDIATE-OBJECT reads "[a]ttempts to coerce a given Lisp object into a java-object" while the doc JOBJECT-LISP-VALUE reads "Attempts to coerce JAVA-OBJECT into a Lisp object". This seems wrong here, but I don't understand how exactly. I think we need to distinguish three types of values here: JAVA-OBJECT, LispObject, and the "raw" value of the Java. How should we really structure our Java FFI here? With my patch, for an underlying lisp value of type (SIMPLE-VECTOR (UNSIGNED-BYTE 8)), both MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-OBJECT return the byte[] array. I would think that MAKE-IMMEDIATE-OBJECT should just do this, which JOBJECT-LISP-OBJECT should .... return an error if its argument isn't of type JAVA-OBJECT? I don't know. I am confused. Can someone help me understand the right way forward here? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

[armedbear-devel] ASDF-JAR contrib packages systems in jar files
by Mark Evenson 20 Jun '11

20 Jun '11

The ASDF-JAR contrib now packages up ASDF systems in jar archives. Comments and/or additional needs from this system are welcome. From the documentation: ASDF-JAR ======== Mark Evenson Created: 20-JUN-2011 Modified: 20-JUN-2011 ASDF-JAR provides a system for packaging ASDF systems into jar archives for ABCL. Given a running ABCL image with loadable ASDF systems the code in this package will recursively package all the required source and fasls in a jar archive . To install ASDF systems, [Quicklisp]() is probably the best contemporary solution, although a version of ASDF-INSTALL is also packaged in ABCL contribs. [Quicklisp]: http://www.quicklisp.org Once the requisite ASDF systems have been installed, ensure that this contrib is loaded via CL-USER) (require :abcl-contrib) CL-USER> (require :asdf-jar) Then, to say package the Perl regular expression system ("CL-PPCRE"), one uses the ASDF-JAR:PACKAGE as follows: CL-USER> (asdf-jar:package :cl-ppcre) ; Loading #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" ... ; Loaded #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" (0.029 seconds) Packaging ASDF definition of #<ASDF:SYSTEM "cl-ppcre"> as /var/tmp/cl-ppcre-all-2.0.3.jar. Packaging contents in /var/tmp/cl-ppcre-all-2.0.3.jar with recursive dependencies. #P"/var/tmp/cl-ppcre-all-2.0.3.jar" The resulting jar contains all source and fasls required to run the ASDF system including any transitive ASDF dependencies. Each asdf system is packaged under its own top level directory within the jar archive. The jar archive itself is numbered with the version of the system that was specified in the packaging. To load the system from the jar one needs to add the ASDF file locations to the ASDF *CENTRAL-REGISTRY*. If one wishes to load the fasls from the jar alone, one needs to tell ASDF not to override its output translation rules. The function ASDF-JAR:ADD-TO-JAR does both of these options serving as the basis for customized load strategies tailored to end-user deployment needs. So, after CL-USER> (asdf-jar:add-to-asdf "/var/tmp/cl-ppcre-all-2.0.3.jar") a subsequent CL-USER> (asdf:load-system :cl-ppcre) should load the ASDF system from the jar. Setting CL:*LOAD-VERBOSE* will allow one to verify that the subsequent load is indeed coming from the jar. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-cvs] r13338 - trunk/abcl/doc/manual
by Ville Voutilainen 18 Jun '11

18 Jun '11

On 17 June 2011 10:01, <mevenson(a)common-lisp.net> wrote: > Separate content/presentation rules via LaTeX include directives. > Properly use the as yet unwritten \code{} markup. The listings-package might be useful for source code listings. At any rate, writing a macro for it manually would be just wrong. :) There are existing packages for that, let's use them, ok? On the choice of LaTeX, +1 high praise, I love it, although I've never used it much to generate html with proper links/frames and all. The little dabbling I've done seemed non-problematic, though, and the output on non-html in TeX has always been superior to anything I've tried.

2 1

Re: [armedbear-devel] [quicklisp] The "kitchen" behind quicklisp repositories
by Mark Evenson 14 Jun '11

14 Jun '11

On 6/10/11 13:52 , Zach Beane wrote: […] > I'm not exactly sure what I will need, yet, but certainly if it was easy > for ABCL to provide a fast way to compute the SHA1/SHA256/SHA512 digest > of disk files, that would be helpful. […] Attached please find code for ABCL which directly manipulates the underlying JVM APIs for fast I/O ("NIO") and uses the built-in MessageDigest computation. Is this sufficient for your needs? ABCL needs to look at how to make such things happen natively in Lisp a lot faster, but that won't be happening in the near future. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] Using print and read together.
by Ted Kosan 13 Jun '11

13 Jun '11

Hello, I am currently working through the "Land of Lisp" book by Conrad Barski and I am using ABCL to run all of the code in the book. In the following code, the prompt that is printed by 'print' is not seen until after 'read' returns: (defun add-five() (print "Pleaser enter a number:") (let ((num (read))) (print "When I add five I get") (print (+ num 5)))) Is it possible to configure ABCL to have the output from 'print' be visible immediately so that it can be used to prompt the user to input some information? Thanks in advance, Ted

3 2

[armedbear-devel] ASDF 2.016 released
by Faré 09 Jun '11

09 Jun '11

Dear Lisp implementors, below is the announcement for ASDF 2.016, as posted on the asdf-announce mailing-list, also accessible via its gmane mirror gmane.lisp.asdf.announce. Please have me take your list off my forwarding aliases if unappropriate. Can you upgrade your implementation to ship with the latest ASDF? Thanks! If you're still using 2.015 (or something even older), there have been many bug fixes, robustness, portability and upgradability enhancements and a few features implemented since. We recommend that you keep (require :asdf) working as well as (require "asdf"). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Consider this: the first hole ever dug on the moon by a man-made machine is now done. It is the most expensive hole in the history of the human race. Now, what does that mean? How do we know whether this is one of man's noblest achievements or if it is a game being played by a small group of lunatics for their own amusement — at our expense?" — Neil Postman, "Teaching as a Subversive Activity" ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 7 June 2011 20:30 Subject: ASDF 2.016 released To: asdf-announce(a)common-lisp.net Cc: ASDF-devel <asdf-devel(a)common-lisp.net> Dear CL users, I released ASDF 2.015.12 as 2.016. Please test, and upon success update your implementations and lisp distributions. Since 2.015, we have the following improvements: * Portability: Fixes for ECL, RMCL. Tweaks for CLISP. Improvements to Windows configuration, notably for LispWorks. * Fix to load-source-op (broken in 2.014.13 - oops). * Avoid infinite loops in defsystem in cases of bad interference between quicklisp and your source-registry. * Small fixes regarding upgrade, compile-file* :output-file. * Make defsystem-depends-on actually useful by allowing a system thus depended on to define the class of the system depending on it. The XCVB bridge notably relies on this feature. * Some documentation updates. Notably, for the sake of CLISP, (require "asdf") is the new canonical way to load ASDF, instead of (require :asdf). Sigh. * Better tests, notably wrt hot upgrade. Happy hacking! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American diplomat to the Russian: "My country too is free: in the USA too anyone may freely publish the dirty little secrets of president Medvedev!"

2 3

[armedbear-devel] Patch to get ABCL working with TRIVIAL-GARBAGE
by Mark Evenson 07 Jun '11

07 Jun '11

Thanks to Erik's recent work to support both object finalizers and weak reference, and my own recent implementation of weak hash tables, ABCL as of [r13310][] now supports [trivial-garbage][] with the [attached patch][trivial-garbage-20101006-darcs-abcl-20110607a.diff]. [r13310]: http://trac.common-lisp.net/armedbear/changeset/13310 [trivial-garbage]: http://www.cliki.net/trivial-garbage [trivial-garbage-20101006-darcs-abcl-20110607a.diff]: http://detroit.slack.net/~evenson/abcl/trivial-garbage-20101006-darcs-abcl-… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #150: MAKE-PATHNAME ignores version in :DEFAULTS
by Erik Huelsmann 04 Jun '11

04 Jun '11

Same commit-simulation, please ignore. On Sat, Jun 4, 2011 at 11:25 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #150: MAKE-PATHNAME ignores version in :DEFAULTS > -----------------------+---------------------------------------------------- > Reporter: mevenson | Owner: mevenson > Type: defect | Status: closed > Priority: minor | Milestone: 0.26 > Component: java | Version: 0.24 > Resolution: fixed | Keywords: pathname asdf > -----------------------+---------------------------------------------------- > > Comment(by mevenson): > > (In [13294]) Fix #150: MAKE-PATHNAME ignores version in :DEFAULTS. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/150#comment:8> > 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] ABCL and multithreading
by Matus Kmit 01 Jun '11

01 Jun '11

Hi Does ABCL supports multithreading? Greetings, Matus

2 1

[armedbear-devel] The value :LONG is not of type (MEMBER NIL :BOOLEAN)
by Chun Tian (binghe) 30 May '11

30 May '11

Hi, ABCL developers I found my program have some CLOS code which could get the weakness of ABCL ... It's cl-net-snmp [1], which I just release a whole new version few days ago. My goal on ABCL is to make sure the server-side version (a pure Lisp SNMP Agent) run as a separated thread in JVM, so that people can use my program to remotely monitor any Java (or ABCL) servers. (I know some ABCL people are fixing bordeaux-threads, I'm watching this work and hope it could be done soon) Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6 and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN). I have no idea how to fix it. Regards, Chun Tian (binghe) [1] http://common-lisp.net/project/cl-net-snmp/snmp.html Below are the error outputs when compiling a lisp file from cl-net-snmp: #<THREAD "interpreter" {24CCF86}>: Debugger invoked on condition of type TYPE-ERROR The value :LONG is not of type (MEMBER NIL :BOOLEAN). Restarts: 0: TRY-RECOMPILING Try recompiling pdu 1: RETRY Retry compiling component ("snmp" "pdu"). 2: ACCEPT Continue, treating compiling component ("snmp" "pdu") as having been successful. 3: TOP-LEVEL Return to top level. [1] SNMP(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {6BA52C90}>) 2: (JVM::COMPILE-FORM #<JVM::LET/LET*-NODE {2910D926}> JVM::STACK :LONG) 3: (JVM:COMPILE-DEFUN NIL (LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) NIL "/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/packages/snmp/ASDF_TMP_pdu_6.cls" #<FILE-STREAM {6539DEFE}> NIL) 4: (#<FUNCTION {753896F2}>) 5: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {753896F2}>) 6: (SYSTEM::C-E-M-1 (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FUNCTION) 7: (SYSTEM::CONVERT-ENSURE-METHOD (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))))

3 13

[armedbear-devel] Tentative inclusion of JSS with ABCL contrib
by Mark Evenson 27 May '11

27 May '11

Sick of having Clojure eat ABCL's lunch, I've decided to [start trying to include JSS as an ABCL contrib][1] to bring forward a more public platform for Java interop experiments on ANSI CL. Or at least the example of one such platform. [1]: http://trac.common-lisp.net/armedbear/changeset/13281 I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network). With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner. One question for Alan about the #1"something" form of the JSS macro: is relied on outside of JSS? It seems like it was introduced to get around a bug in abcl-0.18, but doesn't seem to be used anywhere inside the lsw2 code base. I've eliminated it in my port of JSS, but would like confirmation that nothing should be using it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[armedbear-devel] ABCL and ASDF
by Faré 27 May '11

27 May '11

Dear ABCL developers, another bug in ABCL: (defparameter *wild-file* (make-pathname :name :wild :type :wild :version :wild :directory nil)) (describe *wild-file*) (describe (make-pathname :defaults *wild-file*)) Apparently, make-pathname fails to copy the version from the defaults. ASDF currently works around this somehow. PS: in a future ABCL release, please include ASDF 2.015.5 or later. Maybe 2.016 will have been released by then. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The difference between a contemporary liberal and a socialist is that to a liberal the most beautiful word in the English language is 'forbidden', whereas to a socialist the most beautiful word is 'compulsory'. — John McCarthy

3 8

[armedbear-devel] patch to stop NPE in PATHNAME.WINDOWS.6
by Matthew L Daniel 27 May '11

27 May '11

Hello, When running `abcl.test' against r13286, I am experiencing a NullPointerException caused by the Pathname's URI having a null Path property. The patch below fixes this by reporting an error instead of just blindly passing it into java.io.File. Hope this helps, -- /v\atthew ---8<---patch-----8<-- --- a/src/org/armedbear/lisp/Pathname.java +++ b/src/org/armedbear/lisp/Pathname.java @@ -356,8 +356,12 @@ public class Pathname extends LispObject { + "'" + url.toString() + "'" + ": " + ex.toString())); } - File file = new File(uri.getPath()); - Pathname p = new Pathname(file.getPath()); + final String uriPath = uri.getPath(); + if (null == uriPath) { + error(new FileError("The URI has no path: "+uri)); + } + final File file = new File(uriPath); + final Pathname p = new Pathname(file.getPath()); this.host = p.host; this.device = p.device; this.directory = p.directory; --->8--end-patch-->8-- ---8<--exception-----8<-- ; (DEFTEST WINDOWS.4 ...) ; (DEFTEST WINDOWS.5 ...) ; (DEFTEST PATHNAME.WINDOWS.6 ...) Exception in thread "interpreter" java.lang.NullPointerException at java.io.File.<init>(File.java:222) at org.armedbear.lisp.Pathname.init(Pathname.java:359) at org.armedbear.lisp.Pathname.<init>(Pathname.java:174) at org.armedbear.lisp.Pathname.parseNamestring(Pathname.java:1021) at org.armedbear.lisp.Stream.readPathname(Stream.java:538) at org.armedbear.lisp.LispReader$15.execute(LispReader.java:247) --->8--end-exception-->8--

2 1

[armedbear-devel] ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)
by Mark Evenson 17 May '11

17 May '11

On 5/17/11 3:28 PM, Faré wrote: […] > Hope this helps. I'm gonna need a bit more time to chew over the ASDF code, but thanks for the general direction. I must confess that in spite of the reasonable looking documentation and having contributed the function translation code to ASDF, its whole output translation API has never really gelled in my understanding as a totality. Maybe I can contribute some examples to the texinfo file when the fuzz in my understanding resolves a bit. > BTW, for cl-launch and XCVB, I indeed am looking for a way to create > bundles from compiled stuff. How do I create a jar from ABCL and a set > of lisp files, precompiled or not? A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of ASDF system definitions that works well in a Java ecosystem is precisely the itch I'm in the process of scratching for ABCL right now. The base unit of packaging in Java is the jar file, which is nothing more than a ZIP archive with (possibly) some Java-the-language specific metadata. Currently, one can package an ASDF definition in a jar file, push the location of the asd file into ASDF:*CENTRAL-REGISTRY* using the [ABCL JAR-PATHNAME conventions][1] for which a subsequent ASDF:LOAD-SYSTEM will do the right thing. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… For instance, if you were to package up cl-ppcre installed via [quicklisp][10^9monkey-wants-this] in a jar file via unix$ cd ~/quicklisp/dists/quicklisp/software && jar cfv /tmp/cl-ppcre-2.0.3.jar cl-ppcre-2.0.3 [10^9monkey-wants-this]: http://www.quicklisp.org one could subsequently enable an ASDF controlled load of this system via CL-USER> (push "jar:file:/tmp/cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" asdf:*central-registry) When loaded, ASDF will compile the system to the user cache. Some problems here that I'm working through: 1) You can't immediately load FASL out of the jar. In my current hackish way—i.e. without comprehending your advice yet—one has first ASDF compile the system with output translations disabled, and then (defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file))) (setf (asdf::output-translations) '((t t)))) in the target JVM to load the ABCL FASLS from the jar. 2) One has to specify the absolute path on the local filesystem (or potentially via a URI) for the jar, which makes things a bit fragile in the typical Java ecosystem usage which shuffles jars around like win32 DLLs (or, to be fair, Unix dynamic libraries) relying merely on the filename to keep things straight. My current insight into a way around would be to define another PATHNAME extension in ABCL for CLASSPATH entries, i.e. "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar in the JVM CLASSPATH if it exists. 3) ABCL [has a bug][#149] that currently prevents ASDF systems located in the top-level entry of a JAR from being accessed. [#149]: http://trac.common-lisp.net/armedbear/ticket/149 4) The extremely nice use of [JSS][jss] and [ABCLD's slight modification][abcld] of ASDF to also refer to jar files to dynamically load into the JVM probably needs to be rewritten, otherwise we run into the situation whereby we have jars (i.e. the packaged Java code) within the ASDF packaged jar which A) needs changes within ABCL to completely work and B) would be rather inefficient in that the naive implementation each request for a new entry in the JAR within a JAR would require a complete "reseek" through the enclosed ZIP file. [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld 5) A fear of mine: if I enable all this, I presume that people would start going around creating 'abcl.jar' files with different inclusions of different ASDF packagings. Without a real smart dynamic introspection system that essentially solves the problems in JVM's classpath we would end up with, at the minimum, a rather hostile situation for the end user. "Put 'abcl.jar' in your classpath." "I did, and it still didn't load Maxima." "Well, what's the checksum of your abcl.jar?" "c48d359a23ee" "Oh, you need 846f78c279cb". Ideally, I would like to come up with a mechanism that would require that 'abcl.jar' come from "official" ABCL packaging, but would somehow be able to introspect the JVM classpath to include ASDF definitions. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 5

[armedbear-devel] ABCL-0.25.0
by Paul Bowyer 17 May '11

17 May '11

Hello: I'm very new to lisp and decided to try ABCL to see how it works. I have some experience (not much though) with SBCL and CMUCL using Slime. I've also tried ClozureCL, but it is a little more problematic. I built ABCL with: Netbeans-6.9 (ant-1.8.2) and with: Netbeans-7.0 (ant-1.11.1) as Java Free-Form Projects In both cases, ABCL built without noticeable problems. I'm running PCLinuxOS, so I used the install instructions for Linux from: "http://common-lisp.net/project/armedbear/doc/abcl-install-with-java.html" by copy/paste of "test.lisp" and running : "java -jar <mypath>/abcl.jar --load test.lisp" which also went without problems. I then created a shell script (named "abcl") in my home directory by copy/paste of your "/usr/bin/lisp" with the corrected "ABCL_JAR=" set for the location of my newly built "abcl.jar" but when I run that script from a Konsole shell, the "CL-USER(1):" prompt copies itself plus the character I typed for each character I type at the prompt. As I type, the screen fills with "CL-USER(1):" until I press the enter key and then the lisp form is evaluated and the CL-USER(2): is now at the normal expected location at the lower- left corner of the shell. I have "rlwrap 0.30" installed for use with ABCL. Startup of ABCL: ---------------------------------------------------------------------- Armed Bear Common Lisp 0.25.0 Java 1.6.0_24 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.746 seconds. Startup completed in 2.318 seconds. Type ":help" for a list of available commands. ---------------------------------------------------------------------- I tried using ABCL with Slime and it starts up OK, but it would not compile and load some lisp files that work properly with SBCL and CMUCL. From a Konsole shell using: 'java -jar "<mypath>/abcl.jar"' to run ABCL so as to avoid the prompt problem, I tried: :cload <mypath-to-files>/util.lisp and it went through the compile, but choked at loading with the following: ---------------------------------------------------------------------------------------------------------------------------------------- ; Compiling <mypath-to-files>/util.lisp ... ; (IF (NOT #) ...) ; (IN-PACKAGE "UTIL") ; (DEFUN ELEMENTP ...) ; (DEFTYPE ELEMENT ...) ; (DEFUN LIST-DUP-EL-SRCH ...) ; (DEFUN BAGP ...) ; (DEFTYPE BAG ...) ; Wrote <mypath-to-files>/util.abcl (0.644 seconds) Error loading <mypath-to-files>/util.abcl at line 6 (offset 274) #<THREAD "interpreter" {993730}>: Debugger invoked on condition of type PACKAGE-ERROR The symbol COMMON-LISP-USER::ELEMENTP is not accessible in package UTIL. Restarts: 0: TOP-LEVEL Return to top level. ---------------------------------------------------------------------------------------------------------------------------------------- This was one of the files that compiles and loads without problems with SBCL or CMUCL. ClozureCL will compile and load this file from Slime if I coax it through the process, but it takes more effort than SBCL or CMUCL. I have attached the source for this file if it is needed. It is just some code built by following (kind of) some common lisp tutorial instructions. pbowyer

2 2

[armedbear-devel] Fwd: ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)
by Mark Evenson 17 May '11

17 May '11

-------- Original Message -------- Subject: ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation) Date: Tue, 17 May 2011 21:47:07 +0200 From: Mark Evenson <evenson-VmQCmMdMyN0AvxtiuMwx3w(a)public.gmane.org> To: asdf-devel-F1HGIaG5STRyXAeb93iumQ(a)public.gmane.org CC: Armed Bear <armedbear-devel-F1HGIaG5STRyXAeb93iumQ(a)public.gmane.org> Newsgroups: gmane.lisp.asdf.devel References: <iqtmt0$7ec$1(a)dough.gmane.org> <BANLkTin8YBewU_=NnwOB53sxsn=rkqsOxA(a)mail.gmail.com> On 5/17/11 3:28 PM, Faré wrote: […] > Hope this helps. I'm gonna need a bit more time to chew over the ASDF code, but thanks for the general direction. I must confess that in spite of the reasonable looking documentation and having contributed the function translation code to ASDF, its whole output translation API has never really gelled in my understanding as a totality. Maybe I can contribute some examples to the texinfo file when the fuzz in my understanding resolves a bit. > BTW, for cl-launch and XCVB, I indeed am looking for a way to create > bundles from compiled stuff. How do I create a jar from ABCL and a set > of lisp files, precompiled or not? A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of ASDF system definitions that works well in a Java ecosystem is precisely the itch I'm in the process of scratching for ABCL right now. The base unit of packaging in Java is the jar file, which is nothing more than a ZIP archive with (possibly) some Java-the-language specific metadata. Currently, one can package an ASDF definition in a jar file, push the location of the asd file into ASDF:*CENTRAL-REGISTRY* using the [ABCL JAR-PATHNAME conventions][1] for which a subsequent ASDF:LOAD-SYSTEM will do the right thing. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… For instance, if you were to package up cl-ppcre installed via [quicklisp][10^9monkey-wants-this] in a jar file via unix$ cd ~/quicklisp/dists/quicklisp/software && jar cfv /tmp/cl-ppcre-2.0.3.jar cl-ppcre-2.0.3 [10^9monkey-wants-this]: http://www.quicklisp.org one could subsequently enable an ASDF controlled load of this system via CL-USER> (push "jar:file:/tmp/cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" asdf:*central-registry) When loaded, ASDF will compile the system to the user cache. Some problems here that I'm working through: 1) You can't immediately load FASL out of the jar. In my current hackish way—i.e. without comprehending your advice yet—one has first ASDF compile the system with output translations disabled, and then (defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file))) (setf (asdf::output-translations) '((t t)))) in the target JVM to load the ABCL FASLS from the jar. 2) One has to specify the absolute path on the local filesystem (or potentially via a URI) for the jar, which makes things a bit fragile in the typical Java ecosystem usage which shuffles jars around like win32 DLLs (or, to be fair, Unix dynamic libraries) relying merely on the filename to keep things straight. My current insight into a way around would be to define another PATHNAME extension in ABCL for CLASSPATH entries, i.e. "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar in the JVM CLASSPATH if it exists. 3) ABCL [has a bug][#149] that currently prevents ASDF systems located in the top-level entry of a JAR from being accessed. [#149]: http://trac.common-lisp.net/armedbear/ticket/149 4) The extremely nice use of [JSS][jss] and [ABCLD's slight modification][abcld] of ASDF to also refer to jar files to dynamically load into the JVM probably needs to be rewritten, otherwise we run into the situation whereby we have jars (i.e. the packaged Java code) within the ASDF packaged jar which A) needs changes within ABCL to completely work and B) would be rather inefficient in that the naive implementation each request for a new entry in the JAR within a JAR would require a complete "reseek" through the enclosed ZIP file. [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld 5) A fear of mine: if I enable all this, I presume that people would start going around creating 'abcl.jar' files with different inclusions of different ASDF packagings. Without a real smart dynamic introspection system that essentially solves the problems in JVM's classpath we would end up with, at the minimum, a rather hostile situation for the end user. "Put 'abcl.jar' in your classpath." "I did, and it still didn't load Maxima." "Well, what's the checksum of your abcl.jar?" "c48d359a23ee" "Oh, you need 846f78c279cb". Ideally, I would like to come up with a mechanism that would require that 'abcl.jar' come from "official" ABCL packaging, but would somehow be able to introspect the JVM classpath to include ASDF definitions. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." _______________________________________________ asdf-devel mailing list asdf-devel(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

1 0

[armedbear-devel] JAVA:*JAVA-OBJECT-TO-STRING-LENGTH* controls pretty print length
by Mark Evenson 17 May '11

17 May '11

[r13277][1] now places the control of the elision of PRINT-OBJECT representation of otherwise an unspecialized JAVA-OBJECT by the value of JAVA:*JAVA-OBJECT-TO-STRING-LENGTH*. [1]: http://trac.common-lisp.net/armedbear/changeset/13277 The addresses the problem Blake McBride reported as follows (in an email that mysteriously didn't make it to the armedbear-devel list) On 5/14/11 03:19 , Blake McBride wrote: > I am trying to pretty-print an object. I'm getting: > > #(#<java.lang.reflect.Field private static final long com.ar... {6666F55B}> > #<java.lang.reflect.Field public static final java.lang.St... {43D027D5}> > #<java.lang.reflect.Field public static final java.lang.St... {7CDF3533}> > #<java.lang.reflect.Field public static final java.lang.St... {221DE751}> > #<java.lang.reflect.Field public static final java.lang.St... {593D8856}>) > > I need to be able to see the "..." parts in order to debug a problem I > am having. I tried virtually every combination of printer control > variables I could think of with no changes at all. I have also changed the elision character sequence from "..." to "...." to avoid confusing users that this has anything to do with the standard pretty printer variables (*PRINT-LENGTH* uses "..." to indicate its elision). -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] How to use ABCL's debugger
by David C Wang 16 May '11

16 May '11

I recently started using ABCL, and until now I've been able to use it fine through the Emacs/Slime interface. I'm now trying to use ABCL directly from the command line, but I have no idea what the debugger commands are. Once a runtime error occurs and I am offered the list of possible restarts, how do I check the current frame and step through the backtrace? Is there documentation on this somewhere? Or, can someone tell me what some of the basic commands are? I'm running the latest ABCL on Fedora 14 x64. - Thank you! - David W.

2 2

[armedbear-devel] test, please ignore
by Alessio Stalla 14 May '11

14 May '11

This is a test message. Blake McBride reported that one mail of his got rejected.

1 0

Re: [armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Erik Huelsmann 04 May '11

04 May '11

Dan, On Mon, May 2, 2011 at 10:08 AM, Dan Corkill <corkill(a)gbbopen.org> wrote: > >> It'll take more than the 20 minutes I had to analyze the best >> solution. I'll come back hopefully later this week. > > Thanks Erik. I'm using the short-term workaround of allowing > ABCL to shout back at me (by not setting *print-case* to my > usual :downcase personal preference...). Just committed the fix to trunk. Enjoy! Bye, Erik.

2 1

[armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Dan Corkill 02 May '11

02 May '11

Compiling the following file in the latest ABCL (r13272) illustrates the error: --------------------------- (in-package :cl-user) (eval-when (:compile-toplevel :load-toplevel :execute) (setf *print-case* ':downcase)) (defstruct rec a b) --------------------------- Alternatively, remove the EVAL-WHEN and set *PRINT-CASE* as :downcase before compiling the file containing only the DEFSTRUCT.

3 2

[armedbear-devel] Patch: call reinitialize-instance on metaclass on class redefinition
by Alessio Stalla 01 May '11

01 May '11

Hello, I found out that ABCL, when redefining a class, modifies the old class metaobject in-place, slot by slot. This has the implication that the redefinition of an instance of a custom metaclass does not update custom slots. Now, I didn't check on the AMOP, but I'm pretty sure the proper class redefinition protocol is more articulate than the one implemented in ABCL; still, applying the patch that you find attached fixes the problem of custom slots not being updated by calling reinitialize-instance where the old code manually updated the class metaobject, so it is, I think, a valid temporary solution until we have a full MOP. However, before committing the patch, I'd like to hear your opinion about it. The patch also includes some tabs converted to spaces, sorry for the noise. Bye, Alessio

1 2

[armedbear-devel] json-rpc?
by Axel Rauschmayer 27 Apr '11

27 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] Mixing Java/Lisp abstraction barrier in ABCL implementation
by Mark Evenson 16 Apr '11

16 Apr '11

Alessio has nicely [committed an simple implementation of RUN-PROGRAM][1] to help out Faré's request for XCVB. [1]: http://trac.common-lisp.net/armedbear/changeset/13270 As I think most of would rather do things in Lisp than Java were possible, his implementation uses the JAVA package FFI primtives (JCALL, JMETHOD, etc) to manipulate the underlying JVM ProcessBuilder abstraction. When I was mucking around with the PATHNAME work, Ville objected to code that I had written in a similar manner, and I re-wrote my patch in Java. As I understand it his objection stememd from the architectural principle that the core ABCL Lisp is to be written without direct calls to Java classes to maintain the Java/Lisp abstraction barrier. So, theoretically, if all the ABCL primitives written in Java were running on a different JVM (say Dalvik or the CLR), the rest of ABCL would run as well, modulo the compiler. But since getting features like RUN-PROGRAM implemented quickly helps everyone out, maybe we should relax this somehow? Maybe placing such code in a different directory ("org/armedbear/lisp/jvm"?) Or use the CL package system to have a SYSTEM-JVM from which SYSTEM can inherit symbols? Does this architectural principle still make sense? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

Re: [armedbear-devel] XCL and ASDF
by Faré 14 Apr '11

14 Apr '11

> Thanks! I've committed asdf.lisp 2.014.2 to XCL's tree on github. Thanks! > Fixed on github. (quit :status 42) or (exit :status 42) should work now. Excellent. >> * Your make-pathname erroneously merges directories as in >> merge-pathnames. It shouldn't. > > Can you give an example of this misbehavior, and what the correct > behavior should be? > for i in sbcl ccl clisp ecl ccl abcl xcl gclcvs allegro scl ; do echo $i ; cl-launch -l $i -s asdf -f ~/bug/xcl-make-pathname.lisp; done 2> /dev/null |& tee /tmp/foo Everyone correctly replies #p"" except abcl and xcl that reply #p"/home/fare/". the bug file contains: (defparameter *h* "/home/fare/") (defparameter *make* (make-pathname :directory nil :defaults *h*)) (format t "~S~%" *make*) I wonder why I didn't detect the bug in abcl earlier. Cc'ing the abcl mailing-list. Also, it's very annoying for cl-launch that xcl doesn't have a --no-inform mode. Even more annoying when some output goes to standard-output *after* I print my stuff and call quit. Can you fix this? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] In a centralized society social status is a zero-sum game along a single hierarchy. That's why politics can never help the weak, only swap roles.

2 2

[armedbear-devel] Function.execute and in-package
by Pablo Duboue 12 Apr '11

12 Apr '11

Hello, How can I issue a Function.execute so that it executes in the context of a given package? That is, I have an instance of the Function class, obtained from a .getSymbolFunction() call on a findAccessibleSymbol over a Package instance, per the examples in the source tree. This function call executes fine, but it runs on package "CL". I need it to run on package, say, "FOO". I have tried a number of things, to no avail: * Issuing an interpreter.evaluate("(in-package "FOO")") beforehand. That seemed very reasonable, but doesn't work. Looking into the code, it seems related to packages being special bindings and said bindings being reset between calls to evaluate. * Fiddling with the thread.markSpecialBindings calls which seem to reset in-package bindings in Lisp, Interpreter and Function. I haven't had much success there, am I on the right track at all? * Trying to use other calls instead of function.execute, which include an environment and a thread, that was very cumbersome (and didn't work either). Might this work at all...? * Using the JSR-223 interface. That did work, but as I'm planning to put this in a Web service, I don't want any interpreter on the way (for security reasons). By the way, the JSR-223 page is the only instance of "in-package" in the whole wiki. (The mailing list search function for 'in-package' split it as two words and return half the mailing list as output.) Any pointers will be appreciated and I'll add the information to the wiki afterward (suggesting where to put it will also be appreciated). You can also reply on #abcl, my nick there is DrDub. Gracias! P.

2 3

[armedbear-devel] ABCL and XCVB
by Faré 11 Apr '11

11 Apr '11

Dear ABCL developers, did you ever get to look at the make-pathname bug? for i in sbcl ccl clisp scl allegro ecl gclcvs abcl xcl ; do cl-launch -l $i -iw '(make-pathname :directory nil :defaults #p"/home/fare/")' ; done Also, I'd like to support ABCL in XCVB, and for that I need something more powerful than run-shell-command, since I need to be able to grab the output. I support I could write to a temporary file with a shell redirect, but it's dirty and racy and requires figuring out where the temporary files are to be located. Could you implement a variant of run-program? It might require some trickery to support both Unix and Windows, but it would be very useful, probably beyond just XCVB. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe

4 4

[armedbear-devel] Fwd: ASDF 2.014 released
by Faré 28 Mar '11

28 Mar '11

[Note: I have skipped ECL and Allegro maintainers from the notification, since I know they subscribe to the announcement. You too can subscribe to the asdf-announce mailing-list or its gmane mirror gmane.lisp.asdf.announce and ask me to take your list off the Cc:] ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 28 March 2011 14:08 Subject: ASDF 2.014 released To: asdf-announce(a)common-lisp.net, ASDF-devel <asdf-devel(a)common-lisp.net> Dear ASDF users, I just blessed ASDF 2.013.7 as 2.014. As compared to 2.013, it includes a significant quality item that makes it essential for everyone who distributes ASDF without an implementation (e.g. Quicklisp). It also includes better SCL support, cosmetic improvements, and robustification of some corner cases. Tests have been added to prevent the regressions observed in the 2.013 release. * Fixed bug preventing upgrade from 2.000 to 2.008 (test added) * Better support for URL pathnames on SCL (test added) * Robustified defsystem-depends-on * Cosmetic changes: * better more portably readable error messages. * remove forward references, again (test added) * canonicalize system names earlier (slight robustness improvement) As usual, I invite people who distribute ASDF to update the version they ship, be it with their implementations, with their software distribution, etc. Happy Happy Joy Joy [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." — Howard Aiken

2 1

[armedbear-devel] Improvements to our Gray streams implementation
by Mark Evenson 28 Mar '11

28 Mar '11

As part of the long continuing road to Hunchentoot, I am pleased to announce that with [r13255][1], ABCL can now pass the flexi-streams-1.0.7 test suite as long as [trivial-gray-streams is patched to recognize the new FILE-POSITION generic][2]. [1]; http://trac.common-lisp.net/armedbear/changeset/13255 [2]: http://detroit.slack.net/~evenson/abcl/trivial-gray-streams-abcl-20110320a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Patches for metatilities-base and lift
by Mark Evenson 22 Mar '11

22 Mar '11

Patches to get [metatilities-base][1] and [lift][2] as distributed by Quicklisp MAR2011. We really need to either a) make our own Quicklisp distribution or (my preference) b) make a QUICKLISP-PATCH system to apply patches as QL:QUICKLOAD happens. [1]: http://detroit.slack.net/~evenson/abcl/metatilities-base-20101006-darcs-abc… [2]: http://detroit.slack.net/~evenson/abcl/lift-20110320-git-abcl-20110322.diff -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 8

Re: [armedbear-devel] [Bordeaux-threads-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Chun Tian (binghe) 21 Mar '11

21 Mar '11

Hi, Mark I'm interesting in your work. First, I'd like to know, how to do a "condition variable wait with timeout" with your exist work, Second, do you think it's possible to make ABCL supporting some atomic operations, something like ATOMIC-INCF or ATOMIC-PUSH, this can be very useful to implement some lockless algorithms. Regards, Chun Tian (binghe) 在 2011-3-18，15:50， Mark Evenson 写道： > On 3/2/11 8:50 PM, Martin Simmons wrote: > >> I think that the implementation of condition-wait has some major problems: > > Thanks very much for the comments. > > I have an [updated patch][1] that attempts to address these issues for > further review for inclusion in BORDEAUX-THREADS. > > [1]: > http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff > >> 1) If no other threads are trying to claim the lock, then condition-wait will >> return immediately rather than waiting. > > I couldn't reproduce this behavior. In ABCL, the THREADS:OBJECT-WAIT > implementation is mainly a simple wrapping of the underlying > [java.lang.Object.wait()][2] which clearly should wait. > > [2]: > http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%… > >> 2) If two threads are waiting in condition-wait and two other threads call >> condition-notify, then it is possible that only one thread will return from >> condition-wait because the call to acquire-lock in one of them might return >> nil causing it to wait again. > > The DO looping construct has been replaced with a simpler subsequent > BT:ACQUIRE-LOCK that should solve this bug. > >> 3) If condition-notify is called by one thread when a waiting thread is just >> about to enter the threads:synchronized-on form (but before it gets >> synchronized), then the notify will be lost. This happens because the >> underlying threading primitives have no "memory" of calls to notify when >> nothing it waiting (which is also the expected semantics for POSIX condition >> variables BTW). > > THREADS:SYNCHRONIZED-ON is now the first form executed by > BT:CONDITION-WAIT so the window here is considerably narrowed. > >> Also, I think condition-notify should be using threads:object-notify rather >> than threads:object-notify-all. > > We now use THREADS:OBJECT-NOTIFY. > > > > > -- > "A screaming comes across the sky. It has happened before, but there > is nothing to compare to it now." > > > _______________________________________________ > Bordeaux-threads-devel mailing list > Bordeaux-threads-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

3 3

[armedbear-devel] ASDF 2.013 released
by Faré 20 Mar '11

20 Mar '11

Dear Armed Bear developers, congratulations for your many releases since I last contacted you. I've just released ASDF 2.013. I don't know which version you're using, but there have been numerous small bug fixes and improvements in ASDF. For the sake of sharing those improvements, I think it would be a good time to push ASDF to all Lisp implementations. Could you include it in yours? While abcl is used as part of my automated test suite, I don't often upgrade my abcl copy (currently 0.22.0) -- it would help if there were a debian package. Please make sure ASDF suits your purposes, and contact me with any patch you use for inclusion upstream. PS: I created a mailing-list asdf-announce. Maybe someone amongst you could join it, so I don't need to push my announces to this mailing-list. Or maybe I can just Cc: my announce to this mailing-list and not bother with further explanations? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 20 March 2011 00:29 Subject: ASDF 2.013 released To: asdf-announce(a)common-lisp.net Dear Common Lisp Users, I just blessed ASDF 2.012.12 as 2.013. It includes many small improvements since previous release, for portability, robustness, usability. For the sake of making these improvements available to all users, I invite all vendors and packagers to update their software to include this latest release. Improvements since 2.012: * Fixes and cleanups for CLISP, ECL, SBCL. * Added support for two legacy platforms: (R)MCL, Genera * Cleanup features: now using #+asdf-unix and #+asdf-window * Many cleanups and improvements regarding our portable pathname layer * Fixes a regression in source-registry scanning from 2.011.4 * Remember *source-registry-parameter* and *output-translations-parameter* * Export and document coerce-pathname (f.k.a merge-component-name-type) * allow description and long-description for all components * Several documentation updates Happy hacking, [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I hold that America, Champion of the World is a betrayal of its humble beginnings as One Nation Underdog.

2 2

Re: [armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Mark Evenson 18 Mar '11

18 Mar '11

On 3/18/11 4:41 PM, Ville Voutilainen wrote: > On 18 March 2011 17:37, Mark Evenson<evenson(a)panix.com> wrote: >> This was the previous implementation, which was the subject of the >> criticism: >> >> (defun condition-wait (condition lock) >> (check-type condition condition-variable) >> (release-lock lock) >> (do () >> ((acquire-lock lock nil)) >> (threads:synchronized-on condition >> (threads:object-wait condition)))) > > If this is directly mapped to a pthread implementation, the loop must be there. I think it is slightly different, as the semantics of BT:CONDITION-WAIT are merely that the lock is always reacquired before returning. The caller of BT:CONDITION-WAIT is required to check for spurious wakeups. > >> I believe the race condition is on the the synchronization on the condition >> variable, not on the mutex lock. > > The condition variable needs to use the mutex lock given, not a separate lock. The condition variable interface is using the mutex lock specified in BT:CONDITION-WAIT. For the ABCL implementation, I'm using the Java monitor associated with the condition variable for the additional synchronization needed to implement BT:CONDITION-NOTIFY which couldn't use the mutex lock without contention problems. But definitely check my logic here, as it has been faulty before. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

Re: [armedbear-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD
by Mark Evenson 18 Mar '11

18 Mar '11

On 3/2/11 8:50 PM, Martin Simmons wrote: > I think that the implementation of condition-wait has some major > problems: Thanks very much for the comments. I have an [updated patch][1] that attempts to address these issues for further review for inclusion in BORDEAUX-THREADS. [1]: http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff > 1) If no other threads are trying to claim the lock, then > condition-wait will return immediately rather than waiting. I couldn't reproduce this behavior. In ABCL, the THREADS:OBJECT-WAIT implementation is mainly a simple wrapping of the underlying [java.lang.Object.wait()][2] which clearly should wait. [2]: http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%… > 2) If two threads are waiting in condition-wait and two other threads > call condition-notify, then it is possible that only one thread will > return from condition-wait because the call to acquire-lock in one of > them might return nil causing it to wait again. The DO looping construct has been replaced with a simpler subsequent BT:ACQUIRE-LOCK that should solve this bug. > 3) If condition-notify is called by one thread when a waiting thread > is just about to enter the threads:synchronized-on form (but before > it gets synchronized), then the notify will be lost. This happens > because the underlying threading primitives have no "memory" of > calls to notify when nothing it waiting (which is also the expected > semantics for POSIX condition variables BTW). THREADS:SYNCHRONIZED-ON is now the first form executed by BT:CONDITION-WAIT so the window here is considerably narrowed. > Also, I think condition-notify should be using threads:object-notify > rather than threads:object-notify-all. We now use THREADS:OBJECT-NOTIFY. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[armedbear-devel] svn r13244 breaks DIRECTORY with wildcard
by Mark Evenson 16 Mar '11

16 Mar '11

Even though the commit message notes for r13244 "The wildcard filtering is broken atm, working on that" it would be preferable to not have patches that break things remain long on trunk. Among other things, this prevents the ANSI compiled tests from being run. CL-USER> (DIRECTORY "/Users/evenson/work/ansi-tests/scratch/*") produces The value NIL is not of type FIXNUM. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to sldb level 1. 2: [RETRY] Retry SLIME REPL evaluation request. 3: [*ABORT] Return to SLIME's top level. 4: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {3541D281}> #<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>) 1: (APPLY #<FUNCTION {3541D281}> (#<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {75EE0563}> #<FUNCTION {3541D281}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {75EE0563}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:373) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:414) 6: org.armedbear.lisp.find_20.execute(find.lisp:171) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:138) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:825) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:688) 10: org.armedbear.lisp.pathnames_8.execute(pathnames.lisp:53) 11: org.armedbear.lisp.pathnames_7.execute(pathnames.lisp:53) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:670) 14: org.armedbear.lisp.pathnames_11.execute(pathnames.lisp:86) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:670) 17: org.armedbear.lisp.pathnames_14.execute(pathnames.lisp:131) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:801) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:653) 20: org.armedbear.lisp.directory_6.execute(directory.lisp:98) 21: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:636) 23: org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) 24: org.armedbear.lisp.Lisp.eval(Lisp.java:505) 25: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:343) 26: (POSITION-IF #<FUNCTION {7A4CBCAF}> "*" :START NIL) 27: (SYSTEM::COMPONENT-MATCH-WILD-P "foo.txt" "*" NIL) 28: (SYSTEM::COMPONENT-MATCH-P "foo.txt" "*" NIL) 29: (PATHNAME-MATCH-P #P"foo.txt" #P"*") 30: (DIRECTORY "/Users/evenson/work/ansi-tests/scratch/*") -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Supporting object finalizers (to support trivial-garbage)
by Erik Huelsmann 13 Mar '11

13 Mar '11

One of the higher systems on the list of Quicklisp downloads is the trivial-garbage system (http://www.cliki.net/trivial-garbage) One of the things this package does is to provide 'normalized' access to object finalization functionality. I thought I'd quickly add that support (and did so in r13248). However, it seems our bootstrap compilation has now slowed down to a crawl. So, I'm ready to revert the commit and reopen the ticket I had opened to track progress. However, are you seeing the same? Do you have any good alternatives? I'd love some discussion on this subject: supporting Quicklisp downloaded packages looks like a good way to promote ourselves. Bye, Erik.

2 2

[armedbear-devel] Bug triaging / new milestones available
by Erik Huelsmann 11 Mar '11

11 Mar '11

Following the release, I closed the 0.25 milestone, opening the 0.26 .. 0.30 milestones. These are still empty, but could be filled with the outstanding tickets. If you don't have Trac access, please express your preferences here; if you have Trac access, please update the tickets according to your preference. Bye, Erik.

2 2

[armedbear-devel] [ANNOUNCE] ABCL 0.25.0 released
by Erik Huelsmann 11 Mar '11

11 Mar '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.25.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among lots of other things - a major refactoring of the compiler to be more robust in light of Java class file verification and object instantiation (MAKE-INSTANCE) speed-ups. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.25.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-src-0.25.0.ta… http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-src-0.25.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.25.0/releases/abcl-src-0.25.0.ta… http://common-lisp.net/project/armedbear/0.25.0/releases/abcl-src-0.25.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-bin-0.25.0.ta… http://common-lisp.net/project/armedbear/releases/0.25.0/abcl-bin-0.25.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.25.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.25.0.zip.asc

2 1

[armedbear-devel] [Final CfPart] European Lisp Symposium, Hamburg, March 31 - April 1
by Didier Verna 09 Mar '11

09 Mar '11

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ Sponsors: EPITA, TUHH, Lispworks, Franz Inc., NovaSparks and Freiheit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ News: ~~~~~ * The final program is now online. * The early registration deadline is in 3 days, so hurry! Registration will still be possible afterwards. Invited Speakers: ~~~~~~~~~~~~~~~~~ Craig Zilles -- Compiling for the common case Marc Battyani -- Reconfigurable computing on steroids Apostolos Syropoulos -- Scala: an OO surprise Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Release branch (0.25) created: please test
by Erik Huelsmann 04 Mar '11

04 Mar '11

After the merge of the UNSAFE-P-REMOVAL branch to trunk, Mark Evenson discovered a regression: we failed to compile Montezuma. With some help of Alessio Stalla, I've been able to fix this regression last night, clearing up the last blocking issue for branching for a release. In order to make sure our release works with your software, please test the release branch with it. You can check out the branch using Subversion, from svn://common-lisp.net/project/armedbear/svn/branches/0.25.x Any findings can be reported to this list, or, if you have Trac access, directly as a Trac ticket. Thanks in advance for your efforts! Bye, Erik.

1 0

[armedbear-devel] Getting directory listing with symlinks included
by Zach Beane 02 Mar '11

02 Mar '11

If I have a directory containing a file named a.txt and a symlink b.txt that points to a.txt, is there any ABCL function I can call to get both directory entries as separate objects, i.e. the list (#p"a.txt" #p"b.txt")? The semantics of CL:DIRECTORY seem to require resolving the b.txt symlink, so I'm trying to figure out an extra-standard way to do it in ABCL, if possible. Thanks, Zach

2 7

Re: [armedbear-devel] Bordeaux Threads and ABCL
by Mark Evenson 01 Mar '11

01 Mar '11

On Feb 28, 2011, at 08:05 , Andrew Pennebaker wrote: > I'm having trouble getting threads to work on ABCL. I've filed [ticket #135][1] to track the current status of BORDEAUX-THREADS on ABCL. Apparently, among other things that affect trunk is that we have mistakenly left references to THREAD-LOCK and THREAD-UNLOCK in our autoloads which I will remove as soon as a track down the svn commit that removed ThreadLock.java. [1]: http://trac.common-lisp.net/armedbear/ticket/135 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] translate-logical-pathname downcasing paths inconsistently
by Jonathan P. Bona 27 Feb '11

27 Feb '11

As the following code and transcript demonstrate, translate-logical-pathname appears to be downcasing paths inconsistently: ;;; test.cl (setf (logical-pathname-translations "foo") '(("foo:bar;*.lisp" "/FooRoot/bar/*.lisp") ("foo:*.lisp" "/FooRoot/*.lisp"))) ;;; In the following pathname translation, the entire path is downcased (pprint (translate-logical-pathname "foo:bar;foobar.lisp")) ;;; In each of the next two, the entire path EXCEPT for the host is downcased -- ;;; the host is unchanged (pprint (translate-logical-pathname "foo:foobar.lisp")) (pprint (translate-logical-pathname "foo:Foobar.lisp")) --- Armed Bear Common Lisp 0.24.0 Java 1.6.0_22 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.478 seconds. Startup completed in 1.386 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "test.cl") #P"/fooroot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/foobar.lisp" T CL-USER(2): --- SBCL and CLISP both produce the following output for the above code: #P"/FooRoot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/foobar.lisp" Allegro's ALISP and MLISP both produce the following: #P"/FooRoot/bar/foobar.lisp" #P"/FooRoot/foobar.lisp" #P"/FooRoot/Foobar.lisp"

2 1

[armedbear-devel] :case :common
by pjb＠informatimago.com 27 Feb '11

27 Feb '11

CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" And that I understand "yeld strings in component values" to mean that the processing should be done on each parameter independently. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 4

[armedbear-devel] abcl and maxima
by Reinhard Oldenburg 27 Feb '11

27 Feb '11

Dear All, after quite a while I came back to running maxima on abcl becaus there is an increasing interest in incorporationg maxima in Java based projects. Some time ago Mark explained that in principal loadinf form jars can be done, but it seems that it ned some time to twea maxima-load.lisp so that it loadsfrom a jar containing all the abcl files. Has anything happend on this in the meantime? Reinhard -- Prof. Dr. Reinhard Oldenburg Goethe-Universität Frankfurt Institut für Didaktik der Mathematik und Informatik Senckenberganlage 9 (Sekretariat) Robert-Mayer-Str. 10 (Dienstzimmer) D-60325 Frankfurt/Main Telefon +49 (0)69 798 23770 Telefax +49 (0)69 798 22553 E-Mail oldenbur(a)math.uni-frankfurt.de WWW www.math.uni-frankfurt.de/~oldenbur

2 1

[armedbear-devel] Support for -- in parameter lists
by Ville Voutilainen 20 Feb '11

20 Feb '11

It's common that a double-dash (--) alone can be used to tell a command line parser to stop interpreting further arguments. So, I implemented that very feature for ABCL in r13226. Lo and behold: given a test snippet, saved in cmdline.lisp: (loop for item in *command-line-argument-list* do (format t "got arg ~a~%" item)) we can do ./abcl --batch --eval '(load "cmdlinetest.lisp")' -- hops hups jee jee --eval '(format t "hah~%")' -- -- -- Armed Bear Common Lisp 0.25.0-dev-svn-13225M Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.626 seconds. Startup completed in 1.778 seconds. got arg hops got arg hups got arg jee got arg jee got arg --eval got arg (format t "hah~%") got arg -- got arg -- got arg --

1 0

Re: [armedbear-devel] newbie question
by Lukas Georgieff 17 Feb '11

17 Feb '11

Hi "all", thanks for the great amount of answers. Seems that the best way to handle my problem is to pack the necessary file within the jar file. Best regards Lukas -----Original Message----- From: Alessio Stalla Sent: Wednesday, February 16, 2011 5:35 PM To: Mark Evenson Cc: armedbear-devel(a)common-lisp.net Subject: Re: [armedbear-devel] newbie question On Wed, Feb 16, 2011 at 5:23 PM, Mark Evenson <evenson(a)panix.com> wrote: > To use more CL-like language: a file "test.lisp" has a FASL "test.abcl". > Our FASL is a zip of the initialization code ('%%%._'), the classes > our bytecode compiler emits ('%%%-nnn.cls') for each top-level form in > the corresponding ('%%%.lisp') source file. The contents of the > bootstraip ('%%%._') are executed when this FASL is (re)loaded. Replace "for each top-level form" with "for each function definition" and it's 100% correct ;) A. _______________________________________________ armedbear-devel mailing list armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[armedbear-devel] newbie question
by Lukas Georgieff 16 Feb '11

16 Feb '11

Hi, I am new to ABCL and have a question to it's capabilities:My goal is to load an exsting part of a system coded in lisp into Java and to use the lisp code as basic library for a java application. Currently my approach is to load the lisp code with:Interpreter interpreter = Interpreter.createInstance();interpreter.eval("(load \"my-lisp-code.lisp\")");... So the lisp code must be present in the project every time it is running.Is there any chance to translate the lisp code to a Java source file by using ABCL? So it would not be necessary to provide the lisp code in the java application after it is translated once. Best regards Lukas

4 6

[armedbear-devel] 'unsafe-p-removal' branch integrated in trunk
by Erik Huelsmann 15 Feb '11

15 Feb '11

Just a second ago, I've merged the unsafe-p-removal branch to trunk. It's been sitting in its own branch, completed, for about 4 weeks, waiting for us to release 0.24.0 - which cleared trunk for destabilizing changes. The purpose of the change is to push the responsibility of maintaining stack consistency (ie. prevent 'stack inconsistency' class verification exceptions) to pass2. Before, this responsibility was a joint effort between pass1 and pass2, with a heavy focus on pass1. However since we started inlining local functions, not enough information is available in pass1 anymore to execute its responsibilities correctly. In pass2 all information is available to take on this responsibility and with some additional infrastructure, that's what this change achieves. Due to the fact that quite a bit of pass2 code has been refactored, the change could have a slightly destabilizing effect on trunk. Please help test your software on ABCL to make sure we release - when we do - code as stable as ever! Bye, Erik.

1 0

[armedbear-devel] GSoC2011 project proposals
by Erik Huelsmann 15 Feb '11

15 Feb '11

Hi, In order to see if we have enough material to contend timeslots in GSoC2011, I've started a list of proposed projects right here: http://trac.common-lisp.net/armedbear/wiki/GSoC2011 Please, if you have Trac access feel free to nominate and describe your project directly on the wiki, or send your reaction as a response to this one if you don't! Bye, Erik.

1 0

[armedbear-devel] [CfPart] 4th European Lisp Symposium, registration open!
by Didier Verna 15 Feb '11

15 Feb '11

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ Sponsored by EPITA, TUHH, Lispworks, Franz Inc., NovaSparks and Freiheit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Registration is now open! See http://www.european-lisp-symposium.org/content-registration-full.html for details. The deadline for early registration is March 12. There is a reduced fee for students and accompanying persons. You may also subscribe to mailing lists for this year's occurrence on the registration page. Invited Speakers: ~~~~~~~~~~~~~~~~~ Craig Zilles -- Compiling for the common case Marc Battyani -- Reconfigurable computing on steroids Apostolos Syropoulos -- Scala: an OO surprise The complete program will be available shortly. Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL and so on. We encourage everyone interested in Lisp to participate. Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Registering Java Exceptions
by William 14 Feb '11

14 Feb '11

Hi, I am trying to register Java exceptions using REGISTER-JAVA-EXCEPTION but it does not seem to work for me as evidenced by the transcript below. Is there anything that I may have missed? Armed Bear Common Lisp 0.23.1 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.354 seconds. Startup completed in 1.579 seconds. Type ":help" for a list of available commands. CL-USER(1): (define-condition java-illegal-argument-error (java-exception) ()) JAVA-ILLEGAL-ARGUMENT-ERROR CL-USER(2): (register-java-exception "java.lang.IllegalArgumentException" 'java-illegal-argument-error) NIL CL-USER(3): (ignore-errors (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" "12")) NIL #<JAVA-EXCEPTION {4A6F19D5}> CL-USER(4): (jstatic (jmethod "java.lang.String" "valueOf" "int") "java.lang.String" "12") #<THREAD "interpreter" {2690ED81}>: Debugger invoked on condition of type JAVA-EXCEPTION #<JAVA-EXCEPTION {74D8C3EE}> Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): 0 CL-USER(6): Kind regards, Martin.

2 1

Re: [armedbear-devel] [armedbear-cvs] r13219 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 13 Feb '11

13 Feb '11

Some testing showed that this commit increases instance creation throughput by 100% (ie. doubles the number of instances created in a certain amount of time.) With this change, I was creating 1000 instances of the slot-less class A in 0.020 and 0.018 seconds. That's still way too slow: clisp does it in 0.007s but anyway, before the change it was 0.038. Would be nice to find out how the others get their performance from - which tricks and optimizations. Bye, Erik. On Sun, Feb 13, 2011 at 10:08 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Feb 13 16:08:31 2011 > New Revision: 13219 > > Log: > Add caching to CHECK-INITARGS: cache sets of allowable initargs > per class. > > Note: This change *only* implements caching for "case 1" out of the 4 > cases that check-initargs now supports. (Case 1 being instance creation.) > > Modified: > trunk/abcl/src/org/armedbear/lisp/clos.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/clos.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/clos.lisp Sun Feb 13 16:08:31 2011 > @@ -693,7 +693,8 @@ > (let ((class (std-allocate-instance +the-standard-class+))) > (check-initargs (list #'allocate-instance #'initialize-instance) > (list* class initargs) > - class t initargs) > + class t initargs > + *make-instance-initargs-cache*) > (%set-class-name name class) > (%set-class-layout nil class) > (%set-class-direct-subclasses () class) > @@ -740,6 +741,10 @@ > (list (find-class 'sequence) > (find-class 'java:java-object))) > > +(defvar *make-instance-initargs-cache* > + (make-hash-table :test #'eq) > + "Cached sets of allowable initargs, keyed on the class they belong to.") > + > (defun ensure-class (name &rest all-keys &key metaclass &allow-other-keys) > ;; Check for duplicate slots. > (remf all-keys :metaclass) > @@ -786,11 +791,14 @@ > new-class)) > (t > ;; We're redefining the class. > + (remhash old-class *make-instance-initargs-cache*) > (%make-instances-obsolete old-class) > (setf (class-finalized-p old-class) nil) > - (check-initargs (list #'allocate-instance #'initialize-instance) > + (check-initargs (list #'allocate-instance > + #'initialize-instance) > (list* old-class all-keys) > - old-class t all-keys) > + old-class t all-keys > + nil) > (apply #'std-after-initialization-for-classes old-class all-keys) > old-class))) > (t > @@ -1585,10 +1593,31 @@ > all of the keyword arguments defined for the ~ > generic function." method-lambda-list name))))) > > +(defvar *gf-initialize-instance* nil > + "Cached value of the INITIALIZE-INSTANCE generic function. > +Initialized with the true value near the end of the file.") > +(defvar *gf-allocate-instance* nil > + "Cached value of the ALLOCATE-INSTANCE generic function. > +Initialized with the true value near the end of the file.") > +(defvar *gf-shared-initialize* nil > + "Cached value of the SHARED-INITIALIZE generic function. > +Initialized with the true value near the end of the file.") > +(defvar *gf-reinitialize-instance* nil > + "Cached value of the REINITIALIZE-INSTANCE generic function. > +Initialized with the true value near the end of the file.") > + > (declaim (ftype (function * method) ensure-method)) > (defun ensure-method (name &rest all-keys) > (let ((method-lambda-list (getf all-keys :lambda-list)) > (gf (find-generic-function name nil))) > + (when (or (eq gf *gf-initialize-instance*) > + (eq gf *gf-allocate-instance*) > + (eq gf *gf-shared-initialize*) > + (eq gf *gf-reinitialize-instance*)) > + ;; ### Clearly, this can be targeted much more exact > + ;; as we only need to remove the specializing class and all > + ;; its subclasses from the hash. > + (clrhash *make-instance-initargs-cache*)) > (if gf > (check-method-lambda-list name method-lambda-list > (generic-function-lambda-list gf)) > @@ -2565,18 +2594,11 @@ > ;; methods, along with the predefined initialization argument :ALLOW-OTHER-KEYS." > ;; 7.1.2 > > -(defun check-initargs (gf-list args instance shared-initialize-param initargs) > - "Checks the validity of `initargs' for the generic functions in `gf-list' when > -called with `args' by calculating the applicable methods for each gf. > -The applicable methods for SHARED-INITIALIZE based on `instance', > -`shared-initialize-param' and `initargs' are added to the list of > -applicable methods." > - (when (oddp (length initargs)) > - (error 'program-error > - :format-control "Odd number of keyword arguments.")) > - (unless (getf initargs :allow-other-keys) > - (let* ((methods > - (nconc > +(defun calculate-allowable-initargs (gf-list args instance > + shared-initialize-param > + initargs) > + (let* ((methods > + (nconc > (compute-applicable-methods #'shared-initialize > (list* instance > shared-initialize-param > @@ -2584,26 +2606,48 @@ > (mapcan #'(lambda (gf) > (compute-applicable-methods gf args)) > gf-list))) > - (method-keyword-args > - (reduce #'merge-initargs-sets > - (mapcar #'method-lambda-list methods) > - :key #'extract-lambda-list-keywords > - :initial-value nil)) > - (slots-initargs > - (mapappend #'slot-definition-initargs > - (class-slots (class-of instance)))) > - (allowable-initargs > - (merge-initargs-sets > - (merge-initargs-sets slots-initargs method-keyword-args) > - '(:allow-other-keys)))) ;; allow-other-keys is always allowed > - (unless (eq t allowable-initargs) > - (do* ((tail initargs (cddr tail)) > - (initarg (car tail) (car tail))) > - ((null tail)) > - (unless (memq initarg allowable-initargs) > - (error 'program-error > - :format-control "Invalid initarg ~S." > - :format-arguments (list initarg)))))))) > + (method-keyword-args > + (reduce #'merge-initargs-sets > + (mapcar #'method-lambda-list methods) > + :key #'extract-lambda-list-keywords > + :initial-value nil)) > + (slots-initargs > + (mapappend #'slot-definition-initargs > + (class-slots (class-of instance))))) > + (merge-initargs-sets > + (merge-initargs-sets slots-initargs method-keyword-args) > + '(:allow-other-keys)))) ;; allow-other-keys is always allowed > + > +(defun check-initargs (gf-list args instance > + shared-initialize-param initargs > + cache) > + "Checks the validity of `initargs' for the generic functions in `gf-list' > +when called with `args' by calculating the applicable methods for each gf. > +The applicable methods for SHARED-INITIALIZE based on `instance', > +`shared-initialize-param' and `initargs' are added to the list of > +applicable methods." > + (when (oddp (length initargs)) > + (error 'program-error > + :format-control "Odd number of keyword arguments.")) > + (unless (getf initargs :allow-other-keys) > + (multiple-value-bind (allowable-initargs present-p) > + (when cache > + (gethash (class-of instance) cache)) > + (unless present-p > + (setf allowable-initargs > + (calculate-allowable-initargs gf-list args instance > + shared-initialize-param initargs)) > + (when cache > + (setf (gethash (class-of instance) cache) > + allowable-initargs))) > + (unless (eq t allowable-initargs) > + (do* ((tail initargs (cddr tail)) > + (initarg (car tail) (car tail))) > + ((null tail)) > + (unless (memq initarg allowable-initargs) > + (error 'program-error > + :format-control "Invalid initarg ~S." > + :format-arguments (list initarg)))))))) > > (defun merge-initargs-sets (list1 list2) > (cond > @@ -2648,7 +2692,8 @@ > (let ((instance (std-allocate-instance class))) > (check-initargs (list #'allocate-instance #'initialize-instance) > (list* instance initargs) > - instance t initargs) > + instance t initargs > + *make-instance-initargs-cache*) > (apply #'initialize-instance instance initargs) > instance)) > > @@ -2670,7 +2715,8 @@ > ;; it received." > (defmethod reinitialize-instance ((instance standard-object) &rest initargs) > (check-initargs (list #'reinitialize-instance) (list* instance initargs) > - instance () initargs) > + instance () initargs > + nil) > (apply #'shared-initialize instance () initargs)) > > (defun std-shared-initialize (instance slot-names all-keys) > @@ -2761,7 +2807,8 @@ > (class-slots (class-of new)))))) > (check-initargs (list #'update-instance-for-different-class) > (list old new initargs) > - new added-slots initargs) > + new added-slots initargs > + nil) > (apply #'shared-initialize new added-slots initargs))) > > ;;; make-instances-obsolete > @@ -2793,7 +2840,8 @@ > (check-initargs (list #'update-instance-for-redefined-class) > (list* instance added-slots discarded-slots > property-list initargs) > - instance added-slots initargs) > + instance added-slots initargs > + nil) > (apply #'shared-initialize instance added-slots initargs)) > > ;;; Methods having to do with class metaobjects. > @@ -3101,6 +3149,11 @@ > ;; FIXME > (defgeneric function-keywords (method)) > > + > +(setf *gf-initialize-instance* (symbol-function 'initialize-instance)) > +(setf *gf-allocate-instance* (symbol-function 'allocate-instance)) > +(setf *gf-shared-initialize* (symbol-function 'shared-initialize)) > +(setf *gf-reinitialize-instance* (symbol-function 'reinitialize-instance)) > (setf *clos-booting* nil) > > (defgeneric class-prototype (class)) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] couple of difficult to debug clos situations
by Alan Ruttenberg 13 Feb '11

13 Feb '11

(defclass a (b)) (make-instance 'a) ; Evaluation aborted on NIL. ;; no backtrace in slime The problem is that b is not defined, but the error makes this difficult to discern. --- Trying to fix the problem in some ways leads to more: (defclass a1 (b1)) (defclass b2 ()) CL-USER> (make-instance 'a1) ; Evaluation aborted on NIL. ;; no backtrace in slime CL-USER> (defclass a1 (b2)) ; Evaluation aborted on NIL. ;; no backtrace in slime --- (defclass a3 (b3)) (mop::class-prototype (find-class 'a3)) ;; here we get a backtrace: #<STANDARD-CLASS A3 {1E8E471}> is not finalized. However it is hard to figure out what the problem is. Now try to fix it: (defclass b3 ()) (mop::class-prototype (find-class 'a3)) ;; still get "is not finalized" error (make-instance 'a3) ;; succeeds (mop::class-prototype (find-class 'a3)) ;; now it succeeds -Alan

2 1

[armedbear-devel] Clarification proposal for CLHS 22.3
by Didier Verna 11 Feb '11

11 Feb '11

Hello, I'm planning to submit a CDR for clarifying some aspects of the syntax and semantics of format directives. As this could involve modifying ABCL's behavior, I'd like to have some comments before I submit a first document. I'm attaching a plain text version below (the source is in Texinfo format). -- 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] Maven & ABCL
by Alessio Stalla 11 Feb '11

11 Feb '11

Hello folks, I'm in the process of integrating Dynaspring [1] in a yet-to-be-released open source utilities project developed together with some (ex-)colleagues. The utilities project is built with Maven, so in order to use Dynaspring (and transitively ABCL) I had to write a simple pom.xml (Maven project descriptor) for ABCL to make it known to Maven (i.e. usable as a dependency in Maven projects). For the other developers' convenience, it would be nice if the poms were available from a publicly accessible Maven repository (Sonatype provides a free one, [2]). I'm going to create one there for Dynaspring, but if you're ok with it, I can create a separate one for ABCL, and from now on, publish ABCL releases there as well. What do you think? Bye, Alessio [1] http://code.google.com/p/dynaspring/ [2] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+…

4 14

[armedbear-devel] Release signing (was Maven & ABCL)
by Erik Huelsmann 10 Feb '11

10 Feb '11

>> Morale: this is not terribly complicated, and it would make ABCL >> available through another distribution channel. OTOH, I can't hide the >> fact that - besides my own personal convenience for my shared project >> - probably no-one is using ABCL in Maven projects right now, and >> having ABCL released through Maven would complicate its release >> process, not much for technical reasons but for organizational ones >> (e.g. who keeps ABCL's GPG key? How is it managed?). > > Currently Erik maintains the GPG key we currently use for signing. Does > anyone have a model by which we could somehow share it? It might be > nice to start "rotating" the responsibility for the releases among the > four core committers to help take some work off of Erik's plate. Yes. The key I use for signing as really my own though: I use it to sign all packages I put up for distribution: usocket (when I last did), cl-irc, ABCL, Subversion, py-configparser and maybe others. Within the Subversion project we had a discussion about having a project key or not. We considered that a project key would have to be passed from one to another person, increasing chances of the key getting compromised. Also, the process with a single key means single point of failure. What we considered back then - and are still doing today - is that as many committers as possible sign the release. Each committer signs the variants of the release he/she verified and tested to work well. (There is a tgz and a zip release, exactly like ours, one meant for *nix, the other for Windows). Having many committers sign each release reduces the dependency on every single one of them, but also allows others to join in and maybe have some of the older contributors flow out. Due to the fact that the core stays the same from one release to another, the signatures are still very well recognizable as "the official Subversion release with its regular signatures". I'm interested in your opinions (and how this might work with Maven). Do you think this approach would help to lift work off my shoulders? Do you think it's a good idea to make the signatures "mean" anything? Do you think our group of contributors is large enough to start collecting multiple signatures at all? By the way, I think it's really great that we're actually having this discussion. To me it says something about the maturity of the ABCL project and the attitude of the committers in its community: we're a group dedicated to setting steps in the direction of delivering mature software with solid processes to ensure that our users are getting the quality they deserve. Bye, Erik.'

2 1

Re: [armedbear-devel] [armedbear-cvs] r13209 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 08 Feb '11

08 Feb '11

This fixes the regression I introduced a few days ago. Bye, Erik. On Tue, Feb 8, 2011 at 10:46 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Tue Feb 8 16:46:47 2011 > New Revision: 13209 > > Log: > Add documentation to STD-SHARED-INITIALIZE and > add initarg checking to REINITIALIZE-INSTANCE. > > Modified: > trunk/abcl/src/org/armedbear/lisp/clos.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/clos.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/clos.lisp Tue Feb 8 16:46:47 2011 > @@ -2650,18 +2650,23 @@ > ;; slots should be initialized according to their initforms), and the initargs > ;; it received." > (defmethod reinitialize-instance ((instance standard-object) &rest initargs) > + (check-initargs (list #'reinitialize-instance) (list* instance initargs) > + instance () initargs) > (apply #'shared-initialize instance () initargs)) > > (defun std-shared-initialize (instance slot-names all-keys) > (when (oddp (length all-keys)) > (error 'program-error :format-control "Odd number of keyword arguments.")) > + ;; do a quick scan of the arguments list to see if it's a real > + ;; 'initialization argument list' (which is not the same as > + ;; checking initarg validity > (do* ((tail all-keys (cddr tail)) > - (initarg (car tail) (car tail))) > + (initarg (car tail) (car tail))) > ((null tail)) > (when (and initarg (not (symbolp initarg))) > (error 'program-error > - :format-control "Invalid initarg ~S." > - :format-arguments (list initarg)))) > + :format-control "Invalid initarg ~S." > + :format-arguments (list initarg)))) > (dolist (slot (class-slots (class-of instance))) > (let ((slot-name (slot-definition-name slot))) > (multiple-value-bind (init-key init-value foundp) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Cannot RENAME-FILE to a file without extensions
by Theam Yong Chew 07 Feb '11

07 Feb '11

Dear developers of ABCL, I found a problem recently in both ABCL 0.21.0 and 0.24.0, where I could not rename a file to any file without an extension. For example, with an existing file /tmp/a.txt, CL-USER> (rename-file "/tmp/a.txt" "/tmp/a") #P"/tmp/a.txt" #P"/tmp/a.txt" #P"/tmp/a.txt" The file does not change at all. With any extension, everything works as expected. Thanks in advance. Yong.

2 1

[armedbear-devel] compiler-pass2, dump-form and the dreaded 64k constant string size limit
by Alessio Stalla 06 Feb '11

06 Feb '11

I found another limitation caused by the class file format: constant strings are limited to a size of 64k bytes. The compiler uses dump-form to externalize objects to FASLs, and this means that not only literal strings are limited to 64k, but every object that is dumped is limited by its printed representation. I found that out while trying to compile closure-html [1], which creates a big vector to hold generated parser states and stores it as a constant in the code [2]. So we need to split big dumped forms over multiple strings. I'll attempt a solution in the following days. Bye, Alessio [1] http://common-lisp.net/project/closure/closure-html [2] Incidentally, I also found out that dump-vector causes a stack overflow error for such a vector (probably because it contains other vectors that form circular references). What's the reason for dump-vector not to use the normal vector printing code?

1 0

[armedbear-devel] (quit) in slime doesn't
by Alan Ruttenberg 03 Feb '11

03 Feb '11

CL-USER> (quit) ; Evaluation aborted on NIL.

2 1

[armedbear-devel] (defstruct (teststruct (:type list) :named) testslot)))
by Alan Ruttenberg 02 Feb '11

02 Feb '11

(defstruct (teststruct (:type list) :named) testslot))) causes the following defun to be compiled: (DEFUN NIL (SYSTEM::INSTANCE) (ELT SYSTEM::INSTANCE 0)) That shouldn't be. Particularly if (fdefinition nil) gives an error. -Alan

2 2

[armedbear-devel] [RFC] How to better support disposal of class objects
by Erik Huelsmann 31 Jan '11

31 Jan '11

To prevent any confusion beforehand: The mail below talks about class objects, objects which store class definitions, not the actual instances of those classes, which use those class definitions and store class-allocated or instance values. We have fixed a few bugs where memory would be allocated during (package creation or) FASL loading, but would not be freed upon package deletion. That was an issue because it's an explicit use-case for Blake. Last weekend I came up with another "leak" in ABCL. The word "leak" is between quotes, because depending on how you look at it, not all of it may technically be leaky. My point: it's easy to create a class; simply use a DEFCLASS form. However, unlike package creation, which can be "undone" through DELETE-PACKAGE, there's no DELETE-CLASS function to undo the result of a DEFCLASS. I started to think about supporting the use-case of deleting a class. Digging around in our implementation, I found there are several reasons why a class won't be automatically cleaned up when the package containing its naming symbol is deleted: 1. Every parent maintains a list of subclasses The list contains class objects, meaning that the actual class-object is referenced in this list and for that reason can't be GC-ed 2. Every generic function maintains a list of specializing methods The methods in the list refer to the dispatch types, meaning that the class-objects are strongly referenced from there too 3. Our FIND-CLASS implementation contains strong references to both the naming symbols as well as the class-objects. 4. Our implementation uses a cache to speed up the calls to generic functions. This cache uses strong references too. The issue in item (3) can be solved (relatively) easy by developing a weak hash table which contains both weak keys and values. This hash table could even be made available as regular Lisp objects. Item (4) currently uses an explicitly specialized hash table implemented on the Java side. The hash table could be adapted to use weak references as well - the effort wouldn't be as generally usable, but that's just tough luck. Items (1) and (2) are something to think about though: Is it wise to implement a function which removes the methods and the class from its parent? What if the class itself has direct subclasses? Do we signal an error? Do we provide a parameter forcing the deletion of a whole tree? Or maybe we should just document how potential users of our CLOS should proceed if they have the intention to do this, since it won't be portable anyway? Myself, I'm currently contemplating "just document" on one hand and "do whatever we can, even if they're whole trees" on the other... What do other people think? Bye, Erik.

2 2

[armedbear-devel] Start up message suggestion
by Blake McBride 31 Jan '11

31 Jan '11

Greetings, I've got a suggestion regarding the startup message on development versions of abcl. Rather that just saying "-dev" why don't we say "-dev (XXX)" where XXX is the subversion revision number? This would make it much more clear about what you are running, and I'm pretty sure subversion can automatically provide and update this (I am doing it elsewhere). Thanks. Blake McBride

6 12

[armedbear-devel] ext:run-shell-program
by Alex Mizrahi 30 Jan '11

30 Jan '11

hi I'd like to recieve output of external program as a stream, i.e. without getting it all in one (potentially) huge string but processing it in small portions as it comes. But it looks like this is not possible to do this with ext:run-shell-program -- it accepts output stream as parameter, but I can't read from output stream, and there is no way to translate output stream into input string in CL. (make-echo-stream does the opposite.) So ... am I missing something? If not, what is the best way to implement this?

1 0

[armedbear-devel] Thanks for the error message fix
by Blake McBride 26 Jan '11

26 Jan '11

Greetings, Thanks a lot for fixed the error messages. I can't tell you how much easier debugging has been. Thanks! Blake McBride

1 0

[armedbear-devel] Filename errors in Windows
by Arie van Wingerden 26 Jan '11

26 Jan '11

Hi, I just started with ABCL using the J editor on WinXP SP3. I replaced the ABCL jar in the J lib with the latest 0.23.1, but also in the old version ABCL 0.19 I had the same errors. I am able to create and save a very simple lisp file. However, when I use the menu function: Mode | Compile and load file I get this: [1] CL-USER(3): ;;; Compiling and loading D:\src\lisp\plus.lisp ... #<THREAD "JLisp interpreter" {FD5428}>: Debugger invoked on condition of type FILE-ERROR The file "D:/src/lisp/srclispplus.lisp" does not exist. It seems that somewhere under the hood the filename gets corrupted. Trying to change the name using double backslashes in the text box above the source file does have no effect. Can I change this behaviour? Thx, Arie

3 8

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 26 Jan '11

26 Jan '11

Sent, Erik. Thank you. Please confirm that you have it in hand. At 10:11 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 10:01 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I have a self-contained directory that has only the QI files needed to > > reproduce the problem. Â In it there is a subdirectory called JAR where you > > should place the ABCL jar file of your choice. Â _COMPILE.bat compiles > files > > and then loads them; it hangs trying to load the fourth file. _BUILD.bat > > uses the same files but just loads the lisp sources; it works. > >That looks like a manageable size reproduction. Interesting. > >Could you send directly to me on my sender address? I'll check it out. > >Bye, > >Erik. > > > > I have all this in a 16KB zip file ready to go. Â Where do you want it? > > > > <G> > > > > At 09:23 PM 1/25/2011, Erik Huelsmann wrote: > >> > >> Hi Greg, > >> > >> On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> > >> wrote: > >> > I recently became interested in the language QI. Ã Since it did not run > >> > on > >> > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > >> > what it would take to move it there. Ã From the QI mailing list, I > found > >> > several others had tried on earlier versions of ABCL with inconclusive > >> > results. Ã I decided to give it a try on 0.23.1. > >> > > >> > When I tried the standard script with compiles and then loads the > >> > compiled > >> > files, ABCL hangs it what appears to be an infinite loop try to load one > >> > of > >> > the compiled files. Ã When I switch to just loading them in as Lisp > >> > sources, > >> > things seem to work (though some of the QI tests later fail). > >> > > >> > I tried the compile/load script under 0.24.0 today and the same hang > >> > happens. > >> > > >> > I have a small test case consisting only of the needed sources and a > >> > couple > >> > of .bat files for Windows that demonstrates the problem, but before I > >> > proceed further, has anyone seem anything like this. Ã The file in > >> > question > >> > DEFUNs about 85 functions. Ã Is that too many to provoke the "large > >> > file" > >> > problem I see mentioned here? > >> > >> Could you provide us with a transcript for downloading/installing Qi > >> so we/I can test? > >> > >> If this is the same old bug, the ball is really in Qi's park, but if > >> it's not, we're really happy to fix what we can! > >> > >> Thanks! > >> > >> > >> Bye, > >> > >> > >> Erik. > > > >

1 0

[armedbear-devel] initialization of shared slots
by Didier Verna 26 Jan '11

26 Jan '11

Hello, it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I have a self-contained directory that has only the QI files needed to reproduce the problem. In it there is a subdirectory called JAR where you should place the ABCL jar file of your choice. _COMPILE.bat compiles files and then loads them; it hangs trying to load the fourth file. _BUILD.bat uses the same files but just loads the lisp sources; it works. I have all this in a 16KB zip file ready to go. Where do you want it? <G> At 09:23 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I recently became interested in the language QI. Â Since it did not run on > > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > > what it would take to move it there. Â From the QI mailing list, I found > > several others had tried on earlier versions of ABCL with inconclusive > > results. Â I decided to give it a try on 0.23.1. > > > > When I tried the standard script with compiles and then loads the compiled > > files, ABCL hangs it what appears to be an infinite loop try to load one of > > the compiled files. Â When I switch to just loading them in as Lisp > sources, > > things seem to work (though some of the QI tests later fail). > > > > I tried the compile/load script under 0.24.0 today and the same hang > happens. > > > > I have a small test case consisting only of the needed sources and a couple > > of .bat files for Windows that demonstrates the problem, but before I > > proceed further, has anyone seem anything like this. Â The file in question > > DEFUNs about 85 functions. Â Is that too many to provoke the "large file" > > problem I see mentioned here? > >Could you provide us with a transcript for downloading/installing Qi >so we/I can test? > >If this is the same old bug, the ball is really in Qi's park, but if >it's not, we're really happy to fix what we can! > >Thanks! > > >Bye, > > >Erik.

2 1

[armedbear-devel] Problem with error reporting
by Blake McBride 25 Jan '11

25 Jan '11

I've noticed a problem with error reporting in certain cases. For example, if you type (cons) you get: "Wrong number of arguments for CONS." However, if you type (time) you get: "Wrong number of arguments for ~S." It should be: "Wrong number of arguments for TIME." Of course this is a problem because it doesn't give any pointers when a function fails. I've seen this issue in several instances. Thanks. Blake McBride

3 11

[armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I recently became interested in the language QI. Since it did not run on ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see what it would take to move it there. From the QI mailing list, I found several others had tried on earlier versions of ABCL with inconclusive results. I decided to give it a try on 0.23.1. When I tried the standard script with compiles and then loads the compiled files, ABCL hangs it what appears to be an infinite loop try to load one of the compiled files. When I switch to just loading them in as Lisp sources, things seem to work (though some of the QI tests later fail). I tried the compile/load script under 0.24.0 today and the same hang happens. I have a small test case consisting only of the needed sources and a couple of .bat files for Windows that demonstrates the problem, but before I proceed further, has anyone seem anything like this. The file in question DEFUNs about 85 functions. Is that too many to provoke the "large file" problem I see mentioned here? Thanks.

4 3

[armedbear-devel] Dynamic classpath settings (ticket #18)
by Erik Huelsmann 24 Jan '11

24 Jan '11

Hi Alessio, There's a ticket (#18, http://trac.common-lisp.net/armedbear/ticket/18) to add dynamic classpath capabilities to ABCL, just as used by invoke.lisp. Browsing through our sources, I think you may have added this capability already. Can the issue be closed? Bye, Erik.

3 3

[armedbear-devel] [ANNOUNCE] ABCL 0.24.0 released
by Erik Huelsmann 22 Jan '11

22 Jan '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.24.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among lots of other things - improved embedding support through elimination of System.exit() calls and fixes a regression causing FASLs to be limited in the number of functions they can contain. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.24.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.zip.asc

1 0

[armedbear-devel] Design issue regarding condition printing (was: Error reporting problems)
by Erik Huelsmann 22 Jan '11

22 Jan '11

In order to start addressing our issue with error reporting, I thought I'd start poking around at the source of all Java based exception classes (of which both PROGRAM-ERROR and SIMLE-ERROR are part). This source is the Condition java class. In the class 3 methods have been defined, all related to printing of (java based) errors: * getMessage() [overridden 13 times, 8 call sites] * getConditionReport() [not overridden, 1 call site] * writeToString() While the role of "writeToString()" is clear (it's called by PRINT to print all Java-based objects) and hence should function differently under different circumstances, the role separation between getMessage() and getConditionReport() isn't quite so well defined. This conclusion comes both from the extreme lack of documentation as well as the following: getConditionReport() calls getMessage() to find an "alternative message" to be reported. getMessage() finds out if there's a formatControl string; if there is, it calls writeToString() to generate a message, returning that to getConditionReport(). If getConditionReport() doesn't get an alternative from getMessage() to return back to the caller, it calls Lisp.format() to generate a formatted string to be presented to the user. However, this second path will never get called, except when there's no format string.... Lisp.format() explicitly checks for a null format control string and returns an empty string - which explains why we haven't seen crashes from the above code paths. So, how does that tie into the grand scheme of error reporting? We have two places where errors are being reported: 1. the lisp debugger, which prints errors using the real (lisp based) FORMAT function if it's autoloaded (but falls back to Lisp.format() if FORMAT isn't autoloaded yet) which is invoked by INVOKE-DEBUGGER-REPORT-CONDITION 2. the ERROR place holder Primitives.ERROR() which calls Condition.getConditionReport() The Lisp based FORMAT uses PRINT-OBJECT to print conditions. PRINT-OBJECT.lisp defines specialized instances for several classes in the condition class hieranchy. I know I added some in order to try to address the exact issue we're talking about here. The Java based Lisp.format() function uses <condition>.writeToString() to produce its output. With all these facts on the table, I think we need to do a few things to clean up the mess: - Any condition overriding getMessage() in order to call FORMAT should be removed - getMessage() should be documented *not* to use writeToString() on its own instance - getConditionReport() should be documented not to be overridden, but to override getMessage() instead (maybe declare 'final'?) - Remove all the special methods for classes derived from CONDITION in the print-object.lisp file: they should all fall back to the general method for printing conditions. - Both INVOKE-DEBUGGER-REPORT-CONDITION and Lisp.ERROR should bind the following variables to these listed values, in order to make sure conditions are printed for humans: *print-readably* nil --> all other *print-** variables bound like the values specified for WITH-STANDARD-IO-SYNTAX (except maybe *PRINT-ESCAPE*) The above looks like it should solve our issues. I'd greatly welcome any comments: it's a rather big change, judging by the description above. Ville, you were going to look at it, maybe you can verify if I'm half way right? Bye, Erik.

4 7

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- 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] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- 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] Another error message enhancement request
by Blake McBride 14 Jan '11

14 Jan '11

I just got the following error: #<THREAD "http-8084-1" {41ABA945}>: Unhandled condition of type SIMPLE-ERROR: The method has the wrong number of required arguments for the generic function. Which method? I have a macro that creates many, many methods. If it gave me the method name I'd be able to track the problem easily. I am embedding ABCL in a very large web application. Starting and stopping the server takes a significant amount of time, and I have no command line access to the code. Giving me the name of the method in question could save me 30 minutes easily. Thanks. Blake McBride

1 0

[armedbear-devel] Error condition is too strong
by Blake McBride 14 Jan '11

14 Jan '11

Greetings, I am in the process of embedding ABCL into a web server application I have. While it is okay for an error to either be caught and handled, or not handled and having the thread terminate, it definitely is not okay for an error condition to kill the entire server. I am executing a (load "file") command (where "file" doesn't exist) from Java and it kills the entire server. I tried enclosing it in a try/catch block (I tried Exception & Throwable) and it still killed the server. I then replaced the load with (without a try/catch): File file = null; file.canRead(); And the error didn't kill the server. I just got a backtrace and the thread ended. (I think the error was caught higher up.) Is ABCL calling System.exit() or doing something similar? Thanks. Blake McBride

3 5

[armedbear-devel] Alex Muscar wants to stay in touch on LinkedIn
by Alex Muscar 14 Jan '11

14 Jan '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alex Muscar Alex Muscar Student at Universitatea din Craiova Romania Confirm that you know Alex Muscar https://www.linkedin.com/e/-if48af-giwrckr2-4k/isd/2142627460/1VpMmRDn/ -- (c) 2010, LinkedIn Corporation

1 0

[armedbear-devel] Proposed solution to the "too many functions in FASL" problem
by Alessio Stalla 13 Jan '11

13 Jan '11

Hello all, since my merge of the less-reflection branch with trunk[1], several of you have been bitten by the new limitation in the number of functions that can be contained in a FASL. The reflection-less scheme requires creating a loader class because it needs to spell out in the bytecode all the class names corresponding to compiled Lisp functions in the FASL. Functions are numbered from 1 onwards and a method is created that is a huge switch (actually a chain of if's) that returns the right function given its index: if(index >= 1 && index < 1024) { if(index == 1) return new function_1(); if(index == 2) return new function_2(); ... } else if(index >= 1024 ... In the presence of many functions, this method grows very large, eventually surpassing the JVM's 64k method size limit. A couple of days ago Erik and I discussed a bit about the issue and how to solve it. One option is to implement method splitting for the big FASL loader method. Method splitting in general is hard (you'd need some form of CPS conversion) but in this case it's quite easy. The current scheme, though, has drawbacks: it's more complicated than it used to be, and it's not that beneficial performance-wise - from a profiling I did a while ago, its performance gains amounted to ~1% of our loading time, which is completely dominated by I/O and UTF-8 decoding. So, there's another option: go back to reflection-based loading. Using reflection has the benefit of being simpler. On certain platforms (e.g. mobile JVMs or similar, like Dalvik), reflection has a higher cost, but we currently don't run satisfactorily on those platforms anyway and we'd require multiple changes to do so. After my discussion with Erik, a further refinement of this second option came to my mind. As part of the no-reflection effort, the compiler was changed to stop emitting calls to loadCompiledFunction(className) in favor of generating `new className()` bytecode for local functions, in accordance with the goal of avoiding reflection as much as possible. A special classloader is used to both resolve those local function references, and to load the FASL loader class (and thus transitively all top-level functions). I propose keeping the compilation of local function references as it is, and thus the special classloader; and use it directly (via reflection) to load top-level functions, instead of generating one big loader method. This would result in slightly less reflection, but more importantly in a clearer function loading scheme, and less development effort compared to returning completely to the reflection-based scheme also for local functions. What do you think? If it's not clear, both Erik and I sponsor the solution of returning to a reflection-based approach, but we'd like to hear everyone's opinions. Bye, Alessio

2 4

[armedbear-devel] Recovering "special slots" after package deletion
by Erik Huelsmann 11 Jan '11

11 Jan '11

The other day, Ville and I were discussing the issue with recovery of "special slots" after package deletion on IRC. Let me start by describing the problem for you first. After that I'll describe the solution I see, however, your feedback on the solution is very much appreciated. Special symbol slots? ABCL - like SBCL and CCL - uses a thread-local array containing the 'current' values of its special variables. All symbols which have been declared or declaimed special at one point or another have been assigned an index in this array. This method allows very quick access to the special value (and hence the symbol value) with only a single level of added indirection: the symbols hold the number of their index in the array, meaning that having a reference to the symbol and the current thread is enough to find its value. When I implemented it, it was a huge difference with respect to the method we were using before. Do those need release? Since packages can be deleted, symbols be garbage collected. In the current implementation, GC-ing a special symbol will leave the slot it was assigned unused. There's no way the slot gets reassigned, because nothing keeps track of these 'dead' slots. To make matters worse: there may be huge lisp structures referenced in the dead slot, because it's also not cleared out. In the very long run, this will cause issues in scenarios as Blake describes where one creates, deletes and re-creates packages. The symbols in the packages are new symbols on every re-creation. Yet there are only 4096 spots in the special-symbols table. The solution? Well, the solution I see is to use the Object.finalize() method to release the index back to a freelist. There's a downside here though: the 4096 slots may run out before a multi-gb system sees its first GC run. There are two ways out here: grow the table once we run out of free slots (even though many potentially free slots may be pending GC). Or force a gc/runFinalization() run when running out of indices. Surely a combination of both would also be an option. Ville partially objects to the above because he's used to the pattern "you can't depend on finalize() to be invoked". Reading its documentation and googling the topic a bit, I see that finalize() can't be depended upon especially on JVM termination. However, that particular case isn't interesting here: we're looking at releasing "memory" related resources, which seems to be the exact purpose of finalize() as described in all the web docs I found. Can you comment? Is my approach as sane as I think it is? Bye, Erik.

3 3

[armedbear-devel] Memory leak
by Blake McBride 10 Jan '11

10 Jan '11

Greetings, I think there is a memory leak. I constructed the enclosed lisp files and compiled memtest2.lisp. On a clean abcl evocation I load "try.lisp" and run the various tryN functions. I've mainly been using N=10. You can see that there is a leak when running memtest2. This leak would kill my app after ongoing usage. On another note, memtest2.lisp creates 1000 functions. If you change the number to 10,000 it can't be compiled. This speaks to the error that was reported recently. Thanks. Blake McBride

3 2

[armedbear-devel] [CfP] European Lisp Symposium deadline extension
by Didier Verna 10 Jan '11

10 Jan '11

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

1 0

[armedbear-devel] Broken link in documentation
by Didier Verna 06 Jan '11

06 Jan '11

The page http://common-lisp.net/project/armedbear/doc/abcl-user.html contains two pointers to files under this directory: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples/abcl/java… both are broken links. In fact, it seems that every example pointer to trac is broken. Once in the trac "not found" page, I have a 50% chance to get an Internal Server Error when clinking on Search, but last time, I got to a working page showing this last change: (delete) @12718 [12719] 8 months mevenson Example reorganzation: delete 'abcl' directory. It seems to indicate that the abcl directory under examples/ should be removed in the links, which indeed seems to be the case: I can reach this one instead: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

2 2

[armedbear-devel] JSR-223: path names with spaces and output capturing
by Martin Hepperle 05 Jan '11

05 Jan '11

Hello all, hope you had good start into 2011. ABCL via JSR-223 is almost perfect now, but I have two things which do not work perfectly: A) How to handle path names with spaces? When my Java application is installed in a path with spaces (which should be no problem nowadays in 2011), I receive the following error when the ABCL engine is created: ERROR placeholder called with arguments: #<ERROR {590510}> "Failed to find loadable system file in boot classpath 'jar:file:/D:/Programme/MH%20AeroTools/PROPPY/bin/languages/abcl.jar!/org/armedbear/lisp/boot.lisp'" The spaces have been encoded by "%20", but obviously ABCL does not understand this boot path. B) How to redirect I/O of the script engine? If I want to use a scripting engine in my application, the user may make mistakes. OK. For this purpose I have to 1) catch errors in Java, which works by placing the following two lines into "abcl-script-config.lisp" (in-package :abcl-script) (setq *use-throwing-debugger* nil) 2) catch standard error and standatd output. While JSR provides an interface for this vi "setWriter" and "setErrorWriter", I discovered that most JSR-223 engines do not implement this correctly. So I resorted to redirect the system streams via "System.setOut" and "System.setErr", which worked for all JSR-223 implementations so far ... except ABCL. I always reveive error mesages, as well as the initialization message (...ABCL: configured ) on standard output, possibly bypassing the system streams? So how can I capture errors? Is t possible to rediredt errro and output (e.g.of print) to the standard output and standard error streams of the Java system? Maybe there is some extra initialization needed in ABCL to do this in case of the JSR-223 engine. Thanks for listening, Martin

2 2

[armedbear-devel] Several ABCL/Java questions
by Didier Verna 04 Jan '11

04 Jan '11

Hello, I'm trying to port Clon[1] to ABCL, or at least figure out whether it makes sense at all. My Java programming experience boils down to a Hello World program 10 years ago or so, so some questions belong to the Java side of ABCL for sure :-). I would be grateful if somebody can help me answer these. 1/ Is it possible to create standalone ABCL executables and how ? 2/ ABCL doesn't seem to provide a [set|put]env function. From what I can gather from the internet, that would be because there's no such thing in Java. I've seen some nasty tricks around consisting in modifying the (application-local) initial memory mapping of the environment, but that's all. Is this correct ? 3/ It seems that ABCL does not have a complete MOP. In particular, I couldn't find a validate-superclass function. Is this correct ? Does this mean that classes/superclasses are implicitely "validated" ? 4/ There is a place where I need to access low-level information about a stream in order to figure out whether it's connected to a tty, and in that case, what's the tty line-width. In other implementations, I have native support (or cffi support in the case of CLISP) for calling ioctl with the TIOCGWINSZ argument. It either gets me the tty line width or throws me an ENOTTY error in the face which is fine. How can I do something similar in ABCL ? Thank you very much ! Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/clon.php -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

4 8

Re: [armedbear-devel] Several ABCL/Java questions
by Luís Oliveira 04 Jan '11

04 Jan '11

On 04-01-2011 11:08, Ville Voutilainen wrote: > On 4 January 2011 13:05, Mark Evenson<evenson(a)panix.com> wrote: >> Low level stuff for which you know the local system analogs via ANSI C >> linkage would be well served by using CFFI to wrap calls to >> [abcl-cffi-jna][]. We have a [putative patch to run JNA with the >> callbacks made possible via constructing the necessary Java interfaces >> on-the-fly made possible on abcl-0.24-dev][1] that we welcome feedback >> on esp. wrt. improving the ABCL system interfaces. > > It would surely be neat to have an example of cffi/jna. What kind of example? Once you get it running, it should work as every other CFFI platform and you can following the CFFI User Manual. Cheers, -- Luís Oliveira http://r42.eu/~luis

3 4

[armedbear-devel] [rfc] Preventing stack inconsistencies - structurally
by Erik Huelsmann 01 Jan '11

01 Jan '11

Every now and then (see ticket 117 for a current example), an issue pops up where we fail class file verification with a stack inconsistency error. The problem is that in some specific cases, it's impossible to accumulate function call argument values on the stack: the JVM clears out the stack in these cases. Next to storing values on the stack, the JVM offers local variables. These don't get cleared out. Historically, we have solved the problem by 'rewriting' the code being compiled in a way that made it store its values in local variables. This rewriting happens in pass1 of the compiler, based on the outcome of a the 'safety scanning function' UNSAFE-P. However, this function is overeager (will classify too many cases as unsafe) and it needs to be manually added to all cases which may end up being problematic in pass2. My proposal is now to add infrastructure to pass2 to handle the situation: Some blocks of code need to be marked as "collecting function call arguments". Then, upon the compilation of each argument, the new infrastructure would analyse the form being compiled. If that form will contain 'unsafe' bits, the compiler will automatically switch collection of function call arguments to local variables instead of on the stack. My idea would be to add a macro called WITH-STACK-PARAMETER-COLLECTION and an accompanying COMPILE-STACK-PARAMETER. The macro would set up some special variables for the COMPILE-STACK-PARAMETER to inspect and set. At the end of the macro, code will be emitted to make sure all the values are correctly loaded on the stack, just as if they had always been there. The pass1 form rewriting could be eliminated and our decision rules about what's 'unsafe' and what's not would be completely correct, instead of "overeager, but at least not missing any cases" [the latter it obviously does, since pass1 needs to estimate what pass2 will be compiling]. Any comments? Regards, Erik.

4 12

[armedbear-devel] Release time?
by Erik Huelsmann 31 Dec '10

31 Dec '10

If our Trac milestones are still correct, it's time to start preparing a release again! Does anybody have local changes which urgently require a release? If so, please commit, so we can start the release process. In the mean time, it'd be great if a volunteer would step up to update CHANGES and the 0.24 release notes page. Thanks in advance! Bye, Erik.

3 3

[armedbear-devel] Pathname.java, or: trying to understand the Java URL/URI/File universe
by Erik Huelsmann 27 Dec '10

27 Dec '10

As a result of the failure I just fixed in r13105, I tried to understand more broadly about our interaction with the URL/URI/File Java universe. What I found: * We're constantly converting URL->URI->file-based pathname * When converting an absolute URI to a file object using the File(URI uri) constructor for file: URIs, the process strips the leading slash that preceeds the windows drive letter * We can't "just" convert paths to URIs by doing ["file:" + path], because that's not a valid URI. However, it seems that we should be able to do [new URI("file", null, path, null, null);] as it seems that the URI does its own encoding, *if* we use the multi-argument constructors. Any single-string should be pre-encoded. * We seem to be required to support relative URIs in a non-standard way (like "jar:file:baz.jar"); the standards do allow relative path URIs, but those are requred to be without a schema. All of the above has me thinking: 1. Should we separate the different types of supported pathnames into separate Java classes, with a single entry point (factory?) 2. Would it make sense to separate internal representation from external presentation? Hopefully, this way we can circumvent the fact that the URI<->File conversion really wants absolute paths, while the external presentation is relative. 3. It seems that any URL/URI->path conversion should go through the normalization routines defined by the File(URI uri) constructor, because it seems to do the right thing with URI's - even on Windows. Comments? Regards, Erik.

1 0

[armedbear-devel] Failed to install cl-unicode via quicklisp
by Tomohiro Matsuyama 18 Dec '10

18 Dec '10

Hi all, Today, I have investigated ABCL about is it possible to install libraries via quicklisp and how many libraries can be installed via quicklisp. Installation quicklisp itself has been successful and (surprisingly) it seems to be almost perfect. However, I have finally confront the following errors during installing (compiling?) cl-unicode library after installed some other libraries. ================================================== ; Loading "cl-unicode" ... ;;; Parsing Unicode file UnicodeData.txt ;;; Parsing Unicode file Scripts.txt ;;; Parsing Unicode file Blocks.txt ;;; Parsing Unicode file PropList.txt ;;; Parsing Unicode file DerivedAge.txt ;;; Parsing Unicode file BidiMirroring.txt ;;; Parsing Unicode file Jamo.txt ;;; Building hash tables ;;; Writing source file methods.lisp ;;; Writing source file hash-tables.lisp ;;; Writing source file lists.lisp ;;; Writing source file derived-properties ;;; Parsing Unicode file DerivedCoreProperties.txtjava.lang.ClassFormatError: Unknown constant tag 41 in class file org/armedbear/lisp/ASDF_TMP_hash_tables_2 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at java.lang.ClassLoader.defineClass(ClassLoader.java:480) at org.armedbear.lisp.FaslClassLoader.findClass(FaslClassLoader.java:95) at org.armedbear.lisp.FaslClassLoader.loadClass(FaslClassLoader.java:77) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) ... ================================================== Reproduce: 1. Install Quicklisp 2. (ql:quickload :cl-unicode) Is there any solution? Regards, Tomohiro Matsuyama

1 0

[armedbear-devel] Speculative use of #\unnnn reader forms
by Mark Evenson 16 Dec '10

16 Dec '10

The attached patch attempts to add the ability for ABCL to interpret the form #\unnnn as referring to the unicode character at the hexadecimal codepoint nnnn. I'd commit it to trunk for wider experimentation but ran into an erroneous interaction with Babel's own version of a sharp backslash reader in trying to run the CFFI tests, indicating that I probably missed something rather fundamental here. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] [CfP] 4th European Lisp Symposium, March 31 - April 1, 2010, Hamburg
by Didier Verna 14 Dec '10

14 Dec '10

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

1 0

[armedbear-devel] Using ABCL's JSR-223 support for Ant integration
by Erik Huelsmann 12 Dec '10

12 Dec '10

Together with Alex Mizrahi, I'm working on resurrecting (and improving) ABCL-web, the Java<->ABCL servlet bridge. Because the ABCL-web project consists of both Java and lisp files which need to be distributed in compiled form in a JAR, I'm looking at ways to extend the (NetBeans generated) Ant based build for the ABCL-web project. So far, I've come up with 2 solutions (the third approach turns out to be no solution): 1. Create a custom Ant task - which isn't exactly a lot of work, but still... 2. Integrate with Ant using our JSR-223 implementation based on the Ant SCRIPT tag The latter turned out to be two minutes work for a trivial project file (run from the ABCL project directory root): ================= <project name="squares" default="main" basedir="."> <target name="main"> <script language="ABCL" classpath="dist/abcl.jar"> <![CDATA[ (print "ok") ]]> </script> </target> </project> ================= However, the output is a bit peculiar [note the 4 characters each being on their own line!]: C:\Users\Erik\Documents\abcl-j>ant -f b.xml Buildfile: b.xml main: [script] #<PACKAGE "ABCL-SCRIPT"> [script] #<PACKAGE "ABCL-SCRIPT-USER"> [script] #<PACKAGE "ABCL-SCRIPT"> [script] +GLOBAL-SCOPE+ [script] +ENGINE-SCOPE+ [script] +PUT-BINDING+ [script] +GET-BINDINGS+ [script] GENERATE-BINDINGS [script] GENERATE-SPECIAL-DECLARATIONS [script] GENERATE-JAVA-BINDINGS [script] EVAL-IN-SCRIPT-CONTEXT [script] EVAL-FUNCTION [script] EVAL-SCRIPT [script] EVAL-COMPILED-SCRIPT [script] COMPILE-SCRIPT [script] *INTERFACE-IMPLEMENTATION-MAP* [script] FIND-JAVA-INTERFACE-IMPLEMENTATION [script] REGISTER-JAVA-INTERFACE-IMPLEMENTATION [script] REMOVE-JAVA-INTERFACE-IMPLEMENTATION [script] ("CLOS" "PRINT-OBJECT" "FORMAT" "PPRINT" "ASDF") [script] #<PACKAGE "ABCL-SCRIPT"> [script] *LAUNCH-SWANK-AT-STARTUP* [script] *SWANK-DIR* [script] *SWANK-PORT* [script] *USE-THROWING-DEBUGGER* [script] CONFIGURE-ABCL [script] ABCL: configured [script] [script] [script] " [script] o [script] k [script] " [script] BUILD SUCCESSFUL Total time: 5 seconds So, now I have two questions: 1. Can we silence the ABCL+Script boot up? 2. What's happening with the 1-character-per-line output of my script???? Any help would be appreciated! Bye, Erik.

2 2

Re: [armedbear-devel] [armedbear-cvs] r13094 - in trunk/abcl/src/org/armedbear/lisp/scripting: . util
by Erik Huelsmann 12 Dec '10

12 Dec '10

Hi Alessio, Could you review my commit below? I've removed the ReaderInput/WriterOutput streams, because I think their functionality is available in our general Stream class. Thanks in advance! Bye, Erik. On Sun, Dec 12, 2010 at 11:04 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Dec 12 05:04:45 2010 > New Revision: 13094 > > Log: > Eliminate flushes after every character in javax.scripting support. > > This fixes Ant output for embedded scriptlets in Ant files. > > Removed: > trunk/abcl/src/org/armedbear/lisp/scripting/util/ > Modified: > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > > Modified: trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java Sun Dec 12 05:04:45 2010 > @@ -25,15 +25,11 @@ > import java.io.InputStream; > import java.io.Reader; > import java.io.StringWriter; > -import java.math.BigInteger; > import java.util.Map; > -import java.util.Properties; > > import javax.script.*; > > import org.armedbear.lisp.*; > -import org.armedbear.lisp.scripting.util.ReaderInputStream; > -import org.armedbear.lisp.scripting.util.WriterOutputStream; > > > public class AbclScriptEngine extends AbstractScriptEngine implements Invocable, Compilable { > @@ -230,22 +226,14 @@ > } > > Object eval(Function evaluator, LispObject code, ScriptContext ctx) throws ScriptException { > - ReaderInputStream in = null; > - WriterOutputStream out = null; > LispObject retVal = null; > - try { > - in = new ReaderInputStream(ctx.getReader()); > - out = new WriterOutputStream(ctx.getWriter()); > - Stream outStream = new Stream(Symbol.SYSTEM_STREAM, out, Symbol.CHARACTER); > - Stream inStream = new Stream(Symbol.SYSTEM_STREAM, in, Symbol.CHARACTER); > + Stream outStream = new Stream(Symbol.SYSTEM_STREAM, ctx.getWriter()); > + Stream inStream = new Stream(Symbol.SYSTEM_STREAM, ctx.getReader()); > retVal = evaluator.execute(makeBindings(ctx.getBindings(ScriptContext.GLOBAL_SCOPE)), > makeBindings(ctx.getBindings(ScriptContext.ENGINE_SCOPE)), > inStream, outStream, > code, new JavaObject(ctx)); > return retVal.javaInstance(); > - } catch (IOException e) { > - throw new ScriptException(e); > - } > } > > @Override > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] r12092 breaks build
by Mark Evenson 12 Dec '10

12 Dec '10

With [r12092][1] we apparently need to change the private to protected as in the attached patch. abcl.compile.java: Compiling 270 source files to /Users/evenson/work/abcl/build/classes /Users/evenson/work/abcl/src/org/armedbear/lisp/Interpreter.java:530: JAVA_EXCEPTION_CAUSE has private access in org.armedbear.lisp.JavaException .JAVA_EXCEPTION_CAUSE.execute(condition).javaInstance()); [1]: http://trac.common-lisp.net/armedbear/changeset/13092 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Environment not found
by Gabriel Dos Reis 10 Dec '10

10 Dec '10

Hi, I was looking for documentation of the standard options that the `abcl' driver accepts -- but could not find one. The FAQ page http://common-lisp.net/project/armedbear/faq.shtml suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference... That being reported, where is the documentation of the options accepted by the `abcl' driver? Thanks, -- Gaby

3 8

[armedbear-devel] -Xbootclasspath/a: in abcl.bat wrapper
by Erik Huelsmann 08 Dec '10

08 Dec '10

Some months ago, V-ille mentioned that Clojure got a 50% boot speedup by adding their jar(s) using the bootclasspath. Today, I decided to look into what that means. As it turns out, there's an option to the (Sun) java executable called "-Xbootclasspath/a" which can be used to add jars to the bootclasspath. These timings I got from doing the same in our situation: without the bootclasspath option: C:\Users\Erik\Documents\abcl-j>abcl Armed Bear Common Lisp 0.24.0-dev Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.91 seconds. Startup completed in 5.019 seconds. Type ":help" for a list of available commands. CL-USER(1): :exit with the bootclasspath option: C:\Users\Erik\Documents\abcl-j>abcl Armed Bear Common Lisp 0.24.0-dev Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.341 seconds. Startup completed in 4.159 seconds. Type ":help" for a list of available commands. CL-USER(1): :exit As you see, we can achieve a lot of performance gain (66%) by loading our classes off the bootclasspath. The general performance increase (from 5.0 to 4.9 seconds on my machine in powersavings mode) can -presumably- be much higher, if we compile into .class files instead of "manually" loading .cls files. Just noting to share my findings. Bye, Erik.

1 0

[armedbear-devel] An example of using the ability to dynamically create Java interfaces
by Mark Evenson 05 Dec '10

05 Dec '10

This can probably be cleaned up a lot. Among other things, it shows a nearly constant need to protect the "raw" Java values from ABCL's interpretation to do anything useful. For example (let ((c (jclass "java.io.File"))) (jnew-array-from-array "java.lang.Class" #(c c c))) fails to construct an array as the java.lang.Class members are promoted to JAVA-OBJECT. Does this mean we need JNEW-ARRAY-FROM-ARRAY-RAW? Or do we need to try both interpretations? Onwards through callbacks in CFFI… [1]: http://trac.common-lisp.net/armedbear/changeset/13089 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Idiomatic conversion of file: URLs to file-paths
by Erik Huelsmann 05 Dec '10

05 Dec '10

Hi Mark, To get back to our earlier (irc) discussion of converting URL.getPath() / URI.getPath() to (Windows) pathnames: I found this page: http://weblogs.java.net/blog/2007/04/25/how-convert-javaneturl-javaiofile which contains code on how to do the conversion. I just checked on Windows it even strips the leading '/' which you get from URL.getPath(). My reaction to these findings is to propose a new static function to be added to the Utilities class, which should be used to convert file:/ urls to paths. Our code should then be searched for invocations of URL/URI.getPath() on file urls, changing it to the utility function. Regards, Erik.

1 0

[armedbear-devel] bug in RandomAccessCharacterFile.java
by David Kirkman 05 Dec '10

05 Dec '10

The problem is that in the while loop (line 549), if only part of the byte array is written to the buffer, the position is updated but the length is not. I'm attaching a patch. Here is some code that fails in r13087, and works with the patch. I ran into this while serializing mixed lisp/java objects, which is pretty well reflected in this snippet. Cheers, -david k. (let* ((len 5000) (big-object (jnew-array "double" len))) (dotimes (i len) (setf (jarray-ref big-object i) (+ i 0.1))) (with-open-file (stream "foo.dat" :direction :output :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectOutputStream" "java.io.OutputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedOutputStream") stream)))) (jcall (jmethod "java.io.ObjectOutputStream" "writeObject" "java.lang.Object") p big-object) (jcall (jmethod "java.io.ObjectOutputStream" "flush") p))) (let ((big-object2 (with-open-file (stream "foo.dat" :direction :input :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectInputStream" "java.io.InputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedInputStream") stream)))) (jcall (jmethod "java.io.ObjectInputStream" "readObject") p))))) (dotimes (i len) (format t "~A ~A~%" (jarray-ref big-object i) (jarray-ref big-object2 i)))))

2 1

Re: [armedbear-devel] Patch for ABCL against BORDEAUX-THREADS-0.8.0
by Mark Evenson 04 Dec '10

04 Dec '10

On 12/3/10 4:56 PM, Martin Simmons wrote: >>>>>> On Fri, 03 Dec 2010 14:37:52 +0100, Mark Evenson said: >> >> Implement CONDITION-WAIT and CONDITION-NOTIFY for ABCL. > > That version of CONDITION-WAIT won't work properly: Indeed it won't: thanks for the comments, and the kick in the butt. After studying the needed abstractions in more detail I've [reimplemented most of the BORDEAUX-THREADS interfaces for ABCL based on the java.util.concurrent.ReentrantLock][1]. This code should now correctly implement the POSIX-style condition variables, the recursively held locks, and the form of lock acquisition that returns immediately. Please consider the referenced patch for inclusion in BORDEAUX-THREADS. [1]: http://slack.net/~evenson/abcl/hunchentoot/bordeaux-threads-abcl-20101204a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] ASDF 2.011
by Faré 03 Dec '10

03 Dec '10

Dear Lispers, I'm pleased to announce the release of ASDF 2.011. As compared to ASDF 2.010, it only sports a series of minor changes, which I think is sign of ASDF 2 becoming mature: * minor portability tweaks, to make GCL (2.010.1) and Allegro (2.010.5) happy * minor fixes, to an error in error (2.010.8) * minor API cleanups, exporting symbol operation-description (2.010.6) and accepting keywords as component class names (2.010.3) * minor internal refactoring (2.010.4, 2.010.7 + 2.010.9) * minor improvement in dealing with incompatibility, refusing to run if asdf-binary-locations was loaded as it only works with asdf 1, with useful error message (2.010.7) * minor improvements in compatibility with cl-launch (2.010.2) and xcvb (2.010.4) If you missed it, 2.010 had a notable speedup in addition to minor fixes. It would be very nice of vendors to update the version of ASDF they ship with their respective implementations, or to start shipping it when they don't do it yet (LispWorks, SCL; Corman, GCL - if they are still being developed). PS: I think we should create an asdf-announce mailing-list so that vendors may subscribe to it and only get traffic relevant to releases. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Every technique is first developed, then used, important, obsolete, normalized, and finally understood.

2 1

Re: [armedbear-devel] [armedbear-cvs] r13078 - in trunk/abcl: nbproject src/org/armedbear/lisp
by Erik Huelsmann 03 Dec '10

03 Dec '10

Hi Mark, On Wed, Dec 1, 2010 at 11:44 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Wed Dec 1 17:44:34 2010 > New Revision: 13078 > > Log: > The classfile writer now handles the creation of interfaces. > Modified: > trunk/abcl/nbproject/build-impl.xml > trunk/abcl/nbproject/genfiles.properties ^^^^ Did you intend to commit the NB project file changes? > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp Bye, Erik.

2 1

[armedbear-devel] [ANNOUNCE] ABCL 0.23.1: Fix for loading ABCL from a path with spaces
by Erik Huelsmann 02 Dec '10

02 Dec '10

1 0

[armedbear-devel] CFFI support for the previous example
by Cyrus Harmon 01 Dec '10

01 Dec '10

I neglected to mention that the previous example requires some changes to CFFI to get things to compile in the first place. The attached patch is my attempt at bringing the ABCL CFFI code forward to support the :calling-convention -> :convention that must have been made a while back. Cyrus

2 3

[armedbear-devel] is there a good method to read/write java byte arrays?
by David Kirkman 01 Dec '10

01 Dec '10

Does anybody know of a good way to serialize lisp objects into java byte arrays? I've got a method that almost works, but if anybody has a better/canonical way of doing this I'd love to know! I've been trying to use cl-store, outputting to a stream I create with sys::%make-byte-array-output-stream, and then getting the byte array with sys::%get-output-stream-bytes. I've only been using abcl for a few days, and I found those functions by grepping through the sources, so I apologize if I'm inviting trouble by messing around with functions you never meant users to play with. Anyway, the output works fine. But I can't find the equivalent of sys::%make-byte-array-output-stream to create an input stream, so I attempted to make my own (defun make-byte-array-input-stream (bytes) (let ((bis (jnew (jconstructor "java.io.ByteArrayInputStream" "[B") bytes))) (jnew (jconstructor "org.armedbear.lisp.Stream" "java.io.InputStream") bis))) This almost seems to work, but if I try to use it I get a java exception and a (very long) java stack trace. I put a copy of the stack trace at the end of this message. Here is an expression which will produce the problem in abcl-18.1 (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) ;; now open the byte array as an input stream (with-open-stream (stream (make-byte-array-input-stream outbytes)) ;; all works fine until here (read-byte stream))) I don't need to read the stream, asking for the element type of the input stream is enough to cause trouble ... (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) (with-open-stream (stream (make-byte-array-input-stream outbytes)) (stream-element-type stream))) I can fix the problem and make my code work, but I have to change Stream.java to make it work. I added elementType = UNSIGNED_BYTE_8; to the initAsBinaryInputStream(InputStream in) method. I did this because the stack trace suggested that the problem was stream_element_type.execute() was returning null. Anyway, that fixes the problem, and I'm happily serializing/deserializing lisp objects to a Berkeley DB ... so I guess I'm happy! But I don't know how rational that fix is, because I don't really know how Stream is supposed to work. I suspect that my 'fix' probably breaks something else that I'm just not using yet. Any ideas? Thanks, -david k. Here's the first few lines of the stack trace ... CL-USER(2): Debugger invoked on condition of type SIMPLE-TYPE-ERROR: java.lang.NullPointerException at org.armedbear.lisp.Primitives$49.execute(Primitives.java:795) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_14.execute(print.lisp:279) ... (and it ends with) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:760) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) READ-BYTE: unsupported element type Debugger invoked on condition of type ERROR: Caught java.lang.NullPointerException. Restarts: 0: TOP-LEVEL Return to top level.

3 14

[armedbear-devel] creating a socket with :element-type 'octet fails on ABCL
by Cyrus Harmon 30 Nov '10

30 Nov '10

I've been trying to get drakma (and cl+ssl and CFFI, etc...) working on ABCL. Now I manage to get most of the way there, but I run into an error down in usocket:socket-connect (well, get-socket-stream really): :ELEMENT-TYPE must be CHARACTER or (UNSIGNED-BYTE 8). [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {181CA265}> #<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>) 1: (APPLY #<FUNCTION {181CA265}> (#<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>) 3: (INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {644BFFE5}>) 4: (ERROR SIMPLE-TYPE-ERROR :FORMAT-CONTROL ":ELEMENT-TYPE must be CHARACTER or (UNSIGNED-BYTE 8).") 5: (GET-SOCKET-STREAM #<sun.nio.ch.SocketAdaptor Socket[addr=github.com/207.97.22... {2CD5B121}> :ELEMENT-TYPE FLEXI-STREAMS:OCTET) 6: (USOCKET:SOCKET-CONNECT "github.com" 443 :ELEMENT-TYPE FLEXI-STREAMS:OCTET :NODELAY ...) 7: (DRAKMA:HTTP-REQUEST "https://github.com/slyrus") 8: (SYSTEM::%EVAL (DRAKMA:HTTP-REQUEST "https://github.com/slyrus")) 9: (EVAL (DRAKMA:HTTP-REQUEST "https://github.com/slyrus")) --more-- Any ideas if get-socket-stream needs some octet support or what the best way to address this is? thanks, Cyrus

2 1

[armedbear-devel] ANSI regression testing for abcl-0.23.1
by Mark Evenson 30 Nov '10

30 Nov '10

Results for the ANSI tests on abcl-0.22.0, abcl-0.23.0, and the proposed abcl-0.23.1 are attached. The results ANSI> (report 'doit '0.22.0 '0.23.1) NIL ANSI> (report 'compileit '0.22.0 '0.23.1) 0.23.1[SATURN] --> 0.22.0[SATURN] additional failures: (FLET.45) NIL indicate that we still have one regression in the compiled case for flet.45 (this was also present in abcl-0.23.0. FLET.45 fails in compiling (flet ((nil () 'a)) (nil)) getting lost in PRECOMPILE-FUNCTION-CALL: […] 4: (ERROR PROGRAM-ERROR :FORMAT-CONTROL "Wrong number of arguments for ~S." :FORMAT-ARGUMENTS (NIL)) 5: (SYSTEM::ARG-COUNT-ERROR DEFMACRO NIL NIL (SYSTEM::INSTANCE) 1 ...) 6: (#<FUNCTION (LAMBDA (#:G44218)) {5298DB1F}> (NIL)) 7: (SYSTEM::EXPAND-SOURCE-TRANSFORM-1 (NIL)) 8: (SYSTEM:EXPAND-SOURCE-TRANSFORM (NIL)) 9: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (NIL)) 10: (PRECOMPILER::PRECOMPILE1 (NIL)) 11: (PRECOMPILER::PRECOMPILE-FLET/LABELS (FLET ((NIL NIL 'A)) (NIL))) 12: (PRECOMPILER::PRECOMPILE1 (FLET ((NIL NIL 'A)) (NIL))) 13: (PRECOMPILER::PRECOMPILE-BLOCK (BLOCK FOO (FLET (#) (NIL)))) 14: (PRECOMPILER::PRECOMPILE1 (BLOCK FOO (FLET (#) (NIL)))) 15: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL (BLOCK FOO (FLET # #)))) 16: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (BLOCK FOO (FLET # #)))) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Bug with spaces in directory for abcl-0.23.0
by Mark Evenson 29 Nov '10

29 Nov '10

I noticed that splittist reported on #abcl that abcl-0.23.0 has fails to start if it is in a directory that contains #\Space characters. The problem is related to my "fix" for loading Pathnames that contain #\+ characters which reveals that we are too undecided with our encoding of a JAR Pathname. The problem arises by not rigorously treating Pathnames with "jar:" and "file:" prefixes as having URLEncoded DIRECTORY, NAME, and TYPE components, which seems to be how the java.net.URL classes treat them. Although this seems innocent, when ABCL loads its FASLs it always using this code so this deeply effects the system operation, although normally no one actually constructs such URLs. My proposed fix would be to treat all inputs to Pathname which construct with "jar:" and "file:" schema as being URLEncoded. Likewise, we would fix the namestring routines to provide such encoding on the "way out" to string representations. There would therefore be a difference between (pathname-directory "file:/containing%20a%20space/") ==> (:ABSOLUTE "containing a space") and (pathname-directory #p"/containing%20a%20space/") ==> (:ABSOLUTE "containing%20a%20space") There would be a bit of a surprise that (pathname-directory "file:/cl+ssl!/foo.lisp") ==> (:absolute "cl ssl") It will take some time to chase down all the code paths here, so please comment if this solution is still ambiguous in some way that I haven't anticipated, or if someone has different proposal. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 6

[armedbear-devel] SLOW enumeration of scripting engines via JSR 223 interface...
by Martin Hepperle 27 Nov '10

27 Nov '10

Hi, embedding ABCL using JSR 223 scripting interface I see an nnoyingly long startup time for instances of the ScriptEngineFactory. This is annoying, as e.g. just enumerating all available scrip engines takes rather long because ABCL peforms its complete initailization when I only want to see what its name and script file extensions are. In the class AbclScriptEngineFactory there is a static field which holds a singleeton instance of the script engine: private static final AbclScriptEngine THE_ONLY_ONE_ENGINE = new AbclScriptEngine(); This field is unneccesarily instantiated as soon as the class AbclScriptEngineFactory is instantiated. It would be preferred to intantiate the cript engine only when actually needed, i.e. in getScriptEngine() and instead set it to null so that THE_ONLY_ONE_ENGINE can be tested agianst null inside getScriptEngine(). Thank You, Martin

2 2

[armedbear-devel] [ANNOUNCE] ABCL 0.23.0
by Erik Huelsmann 25 Nov '10

25 Nov '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.23.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - CLOS thread safety fixes and concurrency improvements, support for Oracle's JRockit JVM, and a new (generic) class file writer. In addition, this is the first release to complete the Maxima test suite without failures, thanks to close cooperation between our projects. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.23.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.zip.asc

1 1

[armedbear-devel] ANSI regressions in proposed 0.23.x
by Mark Evenson 25 Nov '10

25 Nov '10

Unfortunately, I'm seeing the following regressions in the ANSI test suite from 0.22.0 to the 0.23.x branch. I think that we can ignore the PRINT.SYMBOL.RANDOM.3 failure, as that has been present intermittently for a while. ANSI> (REPORT 'compileit '0.22.0 '0.23.0) 0.23.0[SATURN] --> 0.22.0[SATURN] additional failures: (STANDARD-METHOD-CPL ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPES.9A TYPES.3 FLET.45) NIL ANSI> (REPORT 'doit '0.22.0 '0.23.0) 0.23.0[SATURN] --> 0.22.0[SATURN] additional failures: (PRINT.SYMBOL.RANDOM.3 STANDARD-METHOD-CPL ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPES.9A TYPES.3) NIL (compileit 0.22.0 :id saturn :uname "x64-solaris-2.11.snv_111b" :jvm "jdk-1.6.0_22" (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPE-OF.1 TYPE-OF.4 MAKE-PATHNAME.9 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16 TRACE.8)) (doit 0.22.0 :id saturn (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPE-OF.1 TYPE-OF.4 MAKE-PATHNAME.9 PRINT.SYMBOL.RANDOM.2 PRINT.STRING.RANDOM.1 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16)) (compileit 0.23.0 :id saturn (FLET.45 REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPES.3 TYPES.9A ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPE-OF.1 TYPE-OF.4 STANDARD-METHOD-CPL MAKE-PATHNAME.9 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16 TRACE.8)) (doit 0.23.0 :id saturn (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPES.3 TYPES.9A ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPE-OF.1 TYPE-OF.4 STANDARD-METHOD-CPL MAKE-PATHNAME.9 PRINT.SYMBOL.RANDOM.2 PRINT.SYMBOL.RANDOM.3 PRINT.STRING.RANDOM.1 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16)) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 3

[armedbear-devel] defun return value is not conforming.
by pjb＠informatimago.com 23 Nov '10

23 Nov '10

CLHS says: Macro DEFUN Syntax: defun function-name lambda-list [[declaration* | documentation]] form* => function-name Arguments and Values: function-name---a function name. and the glossary: function name n. 1. (in an environment) A symbol or a list (setf symbol) that is the name of a function in that environment. 2. A symbol or a list (setf symbol). Therefore (defun f () ...) should return the symbol F, not the function F. Unfortunately, after having loaded quicklisp, it looks like abcl switches to another definition, which returns a function instead of a name: (macroexpand '(defun (x) (1+ x))) Before: (SYSTEM:%DEFUN (QUOTE F) (LAMBDA (X) (BLOCK F (1+ X)))) (correct) After: (PROGN (SYSTEM:%DEFUN (QUOTE F) (SYSTEM:NAMED-LAMBDA F (X) (BLOCK F (1+ X))))) WRONG. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 7

[armedbear-devel] New classwriter no longer preserves Lisp source line numbers
by Mark Evenson 22 Nov '10

22 Nov '10

I just noticed that I no longer see Lisp source line numbers in our backtraces. I'm assuming this is a property of the new classwriter. For debugging, this seems like a serious regression as we already had a paucity of debug information (no way to inspect the frames, no stepped, etc.) Having the line number of the form associated with the stack frame at least gave a bit of a clue as to where to look for the source of a condition. Is my presumption if the lossage stemming from the new classwriter correct? Would it be easy to restore? We seem to be including the ordinal of the top level form in the class name (i.e. "org.armedbear.lisp.ASDF_TMP_installer_51.execute(installer.lisp)" contains the result of compiling the 51st top-level form in 'installer.lisp'), so it should be fairly easy to include a single entry in the LineNumberTable attribute linking the start of the class code with the Lisp source. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] patch to compile with ecl
by pjb＠informatimago.com 22 Nov '10

22 Nov '10

Here is a patch to allow ecl compile abcl (it fails however). I also had problems with ZEROP stumbling on NIL, so I rather brutishly replaced most of its occurences with EQUAL 0. run-shell-command will need some work... [pjb@kuiper :0.0 abcl-svn]$ svn diff Index: build-abcl.lisp =================================================================== --- build-abcl.lisp (revision 13040) +++ build-abcl.lisp (working copy) @@ -69,9 +69,9 @@ #+clisp (cond ((member :win32 *features*) :windows) - ((zerop (ext:run-shell-command "uname | grep -i darwin" :output nil)) + ((equal 0 (ext:run-shell-command "uname | grep -i darwin" :output nil)) :darwin) - ((zerop (ext:run-shell-command "uname | grep -i linux" :output nil)) + ((equal 0 (ext:run-shell-command "uname | grep -i linux" :output nil)) :linux) (t :unknown))) @@ -94,7 +94,7 @@ "\" && " command))) (sb-ext:process-exit-code - (sb-ext:run-program + (sb-ext:run-program "/bin/sh" (list "-c" command) :input nil :output output))) @@ -168,7 +168,24 @@ (declare (ignore status)) exitcode)) -#+(or sbcl cmu lispworks openmcl) +#+ecl +(defun run-shell-command (command &key directory (output *standard-output*)) + (when directory + (setf command (concatenate 'string + "\\cd \"" + (namestring (pathname directory)) + "\" && " + command))) + (let ((result (si:run-program + "/bin/sh" + (list "-c" command) + :input nil :output output))) + (if (null result) + -1 + result))) + + +#+(or sbcl cmu lispworks openmcl ecl) (defun probe-directory (pathspec) (let* ((truename (probe-file pathspec)) ; TRUENAME is a pathname. (namestring (and truename (namestring truename)))) ; NAMESTRING is a string. @@ -285,7 +302,7 @@ (defun java-compile-file (source-file) (let ((cmdline (build-javac-command-line source-file))) - (zerop (run-shell-command cmdline :directory *abcl-dir*)))) + (equal 0 (run-shell-command cmdline :directory *abcl-dir*)))) (defun make-classes (force batch) (let* ((source-files @@ -330,7 +347,7 @@ s) (princ #\space s)))) (status (run-shell-command cmdline :directory *abcl-dir*))) - (zerop status))) + (equal 0 status))) (t (ensure-directories-exist *build-root*) (dolist (source-file source-files t) @@ -350,7 +367,7 @@ (copy-with-substitutions source-file target-file substitutions-alist) (ensure-directories-exist *dist-root*) (let ((status (run-shell-command command :directory *tree-root*))) - (unless (zerop status) + (unless (equal 0 status) (format t "~A returned ~S~%" command status)) status)))) @@ -489,13 +506,13 @@ (when (or full compile-system) (let* ((zip (if (or full jar) nil t)) (status (do-compile-system :zip zip))) - (unless (zerop status) + (unless (equal 0 status) (format t "Build failed.~%") (return-from build-abcl nil)))) ;; abcl.jar (when (or full jar) (let ((status (make-jar))) - (unless (zerop status) + (unless (equal 0 status) (format t "Build failed.~%") (return-from build-abcl nil)))) ;; abcl/abcl.bat @@ -518,7 +535,7 @@ (princ #\space s))) (princ "--main=org.armedbear.lisp.Main -o lisp" s))) (result (run-shell-command cmdline :directory *abcl-dir*))) - (zerop result))) + (equal 0 result))) (defvar *copy-verbose* nil) @@ -591,11 +608,11 @@ (namestring parent-dir) version-string version-string)) (status (run-shell-command command :directory parent-dir))) - (unless (zerop status) + (unless (equal 0 status) (format t "~A returned ~S~%" command status))) (let* ((command (format nil "zip -q -r ~A~A.zip ~A" (namestring parent-dir) version-string version-string)) (status (run-shell-command command :directory parent-dir))) - (unless (zerop status) + (unless (equal 0 status) (format t "~A returned ~S~%" command status))))) Index: build-from-lisp.sh =================================================================== --- build-from-lisp.sh (revision 13040) +++ build-from-lisp.sh (working copy) @@ -72,6 +72,11 @@ exec "$1" --load "$2" --eval "(progn $3 (ext:quit))" } +ecl() +{ + exec "$1" -norc -load "$2" -eval "(progn $3 (ext:quit))" +} + clisp() { exec "$1" -ansi -q -norc -i "$2" -x "(progn $3 (ext:quit))" @@ -120,7 +125,7 @@ gcl*) notimplemented "$IMPL" "$FILE" "$FORM" ;; ecl*) - notimplemented "$IMPL" "$FILE" "$FORM" ;; + ecl "$IMPL" "$FILE" "$FORM" ;; alisp*) notimplemented "$IMPL" "$FILE" "$FORM" ;; *) -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 7

[armedbear-devel] There is no way to compile abcl-src-0.22.0
by pjb＠informatimago.com 21 Nov '10

21 Nov '10

There is no way to compile abcl-src-0.22.0, whatever the lisp implementation used: Armed Bear Common Lisp --> "0.20.0" Clozure Common Lisp --> "Version 1.6-RC1-r14432M (LinuxX8664)" CLISP --> "2.49 (2010-07-07) (built 3499053122) (memory 3499054130)" CMU Common Lisp --> "19c (19C)" ECL --> "10.7.1" SBCL --> "1.0.19-gentoo" [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.272 seconds. Startup completed in 0.71 seconds. Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.232 seconds. Startup completed in 2.678 seconds. #<THREAD "interpreter" {664310D0}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. C-c C-c [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh ccl ;Compiler warnings for "/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp" : ; In SAFE-NAMESTRING: Unused lexical variable LEN Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.227 seconds. Startup completed in 2.638 seconds. #<THREAD "interpreter" {548997D1}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): Build completed successfully in 7.132986 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh clisp ;; Loading file build-abcl.lisp ... ;; Loaded file build-abcl.lisp ;; Loading file /data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp ... ;; Loaded file /data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp Platform: gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -lreadline -lncurses -ldl -lavcall -lcallback -lsigsegv libgnu_cl.a SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.8 libreadline 6.0 JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.233 seconds. Startup completed in 2.651 seconds. #<THREAD "interpreter" {1137D4A4}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): (quit) Build completed successfully in 11.080321 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh lisp ; Loading #P"/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp". ; In: LAMBDA (PATHNAME) ; (LET* (# #) ; (WHEN # ; #) ; STRING) ; Note: Variable BUILD-ABCL::LEN defined but never used. Platform: Linux ; [GC threshold exceeded with 12,010,408 bytes in use. Commencing GC.] ; [GC completed with 1,294,232 bytes retained and 10,716,176 bytes freed.] ; [GC will next occur when at least 13,294,232 bytes are in use.] JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x0. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC554)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0] (unix:unix-exit) Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x0. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFC554)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0] (unix:unix-exit 1) Build completed successfully in 33.49 seconds. ; [pjb@kuiper :0.0 abcl-src-0.22.0]$ [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh ecl ;;; Loading "/data/src/languages/abcl/abcl-src-0.22.0/build-abcl.lisp" ;;; Loading "/data/src/languages/abcl/abcl-src-0.22.0/customizations.lisp" Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Build failed. [pjb@kuiper :0.0 abcl-src-0.22.0]$ sh build-from-lisp.sh sbcl This is SBCL 1.0.19-gentoo, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; loading system definition from ; /usr/share/common-lisp/systems/asdf-binary-locations.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM ASDF-BINARY-LOCATIONS {1002BFE1B1}> as ; ASDF-BINARY-LOCATIONS ; in: LAMBDA NIL ; (LET* ((STRING (NAMESTRING PATHNAME)) (BUILD-ABCL::LEN (LENGTH STRING))) ; (WHEN (POSITION #\ STRING) ; (SETF STRING ; (CONCATENATE 'STRING "\"" (BUILD-ABCL::COMP STRING #\\) "\""))) ; STRING) ; ; caught STYLE-WARNING: ; The variable LEN is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.231 seconds. Startup completed in 2.547 seconds. #<THREAD "interpreter" {73EB904D}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): Build completed successfully in 7.044 seconds. [pjb@kuiper :0.0 abcl-src-0.22.0]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

5 5

[armedbear-devel] Conformity and convenience problems with pathnames
by pjb＠informatimago.com 20 Nov '10

20 Nov '10

Hello, It is well known that implementations of CL pathnames have been greatly implementation dependant. However, the standard still specifies clear behavior for logical pathnames, for one thing, and for the other, since there are several implementations working on the same POSIX systems (unix including linux and MacOSX; and MS-Windows), it is desirable that all implementations converge in their handling of pathnames on these plateforms. Personnaly, I resolved to use logical pathnames and logical-pathname translations as much as possible, and to use make-pathname to build portably physical pathnames. However, most implementations have problems dealing with these two aspects. To improve the situation, I wrote a little script to check the behavior of implementations in these two aspects. The script can be found at: ftp://ftp.informatimago.com/users/pjb/lisp/check-pathnames.lisp Since I'm sending a similar message to most implementation lists, it might be better, if there is any need for 'language lawyer' discussions, to direct them to news:comp.lang.lisp. Here are the results for the latest abcl (from svn): ------------------------------------------------------------------------ [pjb@kuiper :0.0 lisp]$ abcl --noinit --load check-pathnames.lisp Armed Bear Common Lisp 0.24.0-dev Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.244 seconds. Startup completed in 0.766 seconds. check-pathnames of Armed Bear Common Lisp (0.24.0-dev) ================================================================================ Test and probe conforming logical pathnames, and their translation to unix physical pathnames. We want to check the good working of logical pathnames, and the translation of logical pathnames to physical pathnames, in a semi-standard way on unix systems. Namely, given the logical host and its translations: (setf (logical-pathname-translations "LOGICAL") nil) (setf (logical-pathname-translations "LOGICAL") '((#P"LOGICAL:**;*.*" #P"/tmp/**/*.*") (#P"LOGICAL:**;*" #P"/tmp/**/*"))) #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST" must be the same as (make-pathname :host "LOGICAL" :directory '(:absolute "DIR" "SUBDIR") :name "NAME" :type "TYPE" :version :newest :case :common) and must translate to: #P"/tmp/dir/subdir/name.type" on unix. Merging physical pathnames specified with :case :common is also tested: (merge-pathnames (make-pathname :directory '(:relative "DIR" "SUBDIR") :name "NAME" :type "TYPE" :version :newest :case :common :default #1=#P"/tmp/") #1# nil) must give #P"/tmp/dir/subdir/name.type" on unix. ================================================================================ -------------------------------------------------------------------------------- Failed assertion: (IMPLY (EQL CUSTOMARY-CASE-1 :UPPER) (EQL CUSTOMARY-CASE-2 :UPPER)) with: (EQL CUSTOMARY-CASE-1 :UPPER) = T and: (EQL CUSTOMARY-CASE-2 :UPPER) = NIL CUSTOMARY-CASE-1 = :UPPER CUSTOMARY-CASE-2 = :LOWER The customary case for the file system of Armed Bear Common Lisp (0.24.0-dev) seems to be lower case. *FEATURES* = (:X86-64 :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :LINUX :CDR6) ================================================================================ (MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY (:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE :COMMON) LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST" -------------------- :case :local (default) Host : "LOGICAL" Device : :UNSPECIFIC Directory : (:ABSOLUTE "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : :NEWEST -------------------- :case :common Host : "LOGICAL" Device : :UNSPECIFIC Directory : (:ABSOLUTE "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : :NEWEST -------------------- -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL" and: (POP EXPECTED-VALUES) = "logical" 19.2.2.1.2 makes no exception for pathname-host of logical pathnames. -------------------------------------------------------------------------------- Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-DIRECTORY PATH :CASE :LOCAL) = (:ABSOLUTE "DIR" "SUBDIR") and: (POP EXPECTED-VALUES) = (:ABSOLUTE "dir" "subdir") -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-NAME PATH :CASE :LOCAL) = "NAME" and: (POP EXPECTED-VALUES) = "name" -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-TYPE PATH :CASE :LOCAL) = "TYPE" and: (POP EXPECTED-VALUES) = "type" ================================================================================ (MAKE-PATHNAME :HOST "logical" :DEVICE :UNSPECIFIC :DIRECTORY (:ABSOLUTE "dir" "subdir") :NAME "name" :TYPE "type" :VERSION :NEWEST :CASE :LOCAL) LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST" -------------------- :case :local (default) Host : "LOGICAL" Device : :UNSPECIFIC Directory : (:ABSOLUTE "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : :NEWEST -------------------- :case :common Host : "LOGICAL" Device : :UNSPECIFIC Directory : (:ABSOLUTE "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : :NEWEST -------------------- -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL" and: (POP EXPECTED-VALUES) = "logical" 19.2.2.1.2 makes no exception for pathname-host of logical pathnames. -------------------------------------------------------------------------------- Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-DIRECTORY PATH :CASE :LOCAL) = (:ABSOLUTE "DIR" "SUBDIR") and: (POP EXPECTED-VALUES) = (:ABSOLUTE "dir" "subdir") -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-NAME PATH :CASE :LOCAL) = "NAME" and: (POP EXPECTED-VALUES) = "name" -------------------------------------------------------------------------------- Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :LOCAL) (POP EXPECTED-VALUES)) with: (PATHNAME-TYPE PATH :CASE :LOCAL) = "TYPE" and: (POP EXPECTED-VALUES) = "type" -------------------------------------------------------------------------------- Failed assertion: ((LAMBDA (DIRLIST PATH) (EQUAL DIRLIST (PATHNAME-DIRECTORY PATH :CASE :LOCAL))) '(:ABSOLUTE "tmp" "dir" "subdir") (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL)) with: '(:ABSOLUTE "tmp" "dir" "subdir") = (:ABSOLUTE "tmp" "dir" "subdir") and: (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL) = #P"/tmp/DIR/SUBDIR/NAME.TYPE" PATHNAME #P"/tmp/DIR/SUBDIR/NAME.TYPE" -------------------- :case :local (default) Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- :case :common Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- -------------------------------------------------------------------------------- Failed assertion: ((LAMBDA (NAME PATH) (EQUAL NAME (PATHNAME-NAME PATH :CASE :LOCAL))) "name" (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL)) with: "name" = "name" and: (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL) = #P"/tmp/DIR/SUBDIR/NAME.TYPE" PATHNAME #P"/tmp/DIR/SUBDIR/NAME.TYPE" -------------------- :case :local (default) Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- :case :common Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- -------------------------------------------------------------------------------- Failed assertion: ((LAMBDA (TYPE PATH) (EQUAL TYPE (PATHNAME-TYPE PATH :CASE :LOCAL))) "type" (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL)) with: "type" = "type" and: (MERGE-PATHNAMES (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :CASE :COMMON :DEFAULTS #P"/tmp/") #P"/tmp/" NIL) = #P"/tmp/DIR/SUBDIR/NAME.TYPE" PATHNAME #P"/tmp/DIR/SUBDIR/NAME.TYPE" -------------------- :case :local (default) Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- :case :common Host : NIL Device : NIL Directory : (:ABSOLUTE "tmp" "DIR" "SUBDIR") Name : "NAME" Type : "TYPE" Version : NIL -------------------- Type ":help" for a list of available commands. CL-USER(1): (quit) [pjb@kuiper :0.0 lisp]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 0