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

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

23 May '10

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

3 25

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

21 May '10

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

5 8

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

19 May '10

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

2 1

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

18 May '10

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

2 3

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

16 May '10

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

1 0

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

16 May '10

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

3 4

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

15 May '10

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

2 2

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

14 May '10

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

2 7

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

12 May '10

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

2 1

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

11 May '10

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

4 5