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

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

24 Mar '13

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

6 14

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

12 Aug '12

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

3 3

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

08 Aug '12

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

5 5

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

01 Feb '12

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

2 2

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

01 Feb '12

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

2 3

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

27 Jan '12

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

2 1

[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