- 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