armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] ASDF 2.000 released!
by Faré 31 May '10

31 May '10

Dear ABCL hackers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] When a pamphlet was published entitled "100 Authors Against Einstein", Einstein retorted "If I were wrong, one would be enough."

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.20.0 release includes its first funded feature
by Erik Huelsmann 27 May '10

27 May '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.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 is the first to include a funded feature: funds were provided to implement the CLOS METACLASS feature and tests. Next to that, this release contains a large number of fixes and improvements, such as the ability to use JARs and URLs as pathnames and the a new ASDF version (ASDF2). You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.20.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.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip.asc

1 0

[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 20 May '10

20 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel