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

[armedbear-devel] Fixes to LispShell.java for 0.23.0
by Frank Pursel 25 May '10

25 May '10

All, I downloaded the latest version of J a couple of days ago (J version 0.23.0) and had some difficulties getting it to compile using java-6-sun's compiler version 1.6 update 20. Here are the modifications I made to LispShell.java to get it to compile cleanly against a fresh build of the newest abcl (ver 0.19.1, though I don't think it matters): diff -c /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java *** /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-04-03 15:04:08.000000000 -0400 --- /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-05-22 18:42:29.963613502 -0400 *************** *** 110,120 **** } else { ! File lispHome = File.getInstance(Site.getLispHome()); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance(lispHome, ! "swank-loader.lisp"); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 --- 110,121 ---- } else { ! Pathname lispHome = (Pathname)Site.getLispHome(); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance( ! Pathname.mergePathnames(lispHome, ! new Pathname("swank-loader.lisp"))); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 *************** *** 902,908 **** sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); --- 903,909 ---- sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = (Pathname)org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); Diff finished. Sun May 23 19:30:24 2010 I hope it's helpful. I was unable to get abcl to compile cleanly using the lisp build method. It failed with messages telling me that it, variously, could not autoload load or that it could not load 'system'. When I used ant I had no problems. Best wishes on an excellent project. Sincerely, Frank Pursel

3 2

[armedbear-devel] HEADS-UP Swing/AWT code moved to examples; ConsoleREPL added to base
by Mark Evenson 25 May '10

25 May '10

As discussed on #abcl some days ago with Alessio (and Erik?), I have moved the unused code from org.armedbear.lisp.java.* to 'examples/gui' as it is a better fit there. Under the examples I created a simple Ant build.xml with the base outline of a README. The domain of using ABCL to take the tedium out of Swing development and/or the combination with [JSS][1] to produce an interactively built GUI is potentially very interesting to a wider audience, but the examples are currently very thin. But maybe we should just direct people to [Snow][2], as that is where a lot of energy has seemingly been spent. [1]: http://code.google.com/p/lsw2/source/browse/#svn/trunk/jss [2]: http://common-lisp.net/project/snow/ I've [placed the code that Alessio wrote for a minimal Swing REPL console in org.armedbear.lisp.java.swing.REPLConsole][3], which has a suitable Main method so that java -cp abcl.jar org.armedbear.lisp.java.swing.REPLConsole will bring it "up" in the local display. [3]: http://trac.common-lisp.net/armedbear/changeset/12734 This console code is [the current basis][4] for the embedding of ABCL in the Protege ontology editor, although that currently uses its own version. I don't like the creation of Threads in the constructor, but haven't had time to figure out if there is a better way to go. The intention is to provide a standard way for people to embed ABCL with a minimal REPL for their domain-specific Java application, so I when I get the time I will revisit the Protege plugin to use this code. [4]: http://svn.neurocommons.org/svn/trunk/protege/org.sciencecommons.protege.li… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[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