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

[armedbear-devel] Changes to CHANGES
by Mark Evenson 28 Feb '10

28 Feb '10

I've updated the [CHANGES][1] file on trunk in preparation for the upcoming release. Erik asked me to write up my changes, but I took at stab at recapitulating everything as best I could interpret it. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=8a0bf88cca6dd… Deliberately missing from this summary: 1) Alessio's recent work on lambda inlining. In my opinion we have to address the bug Alan Ruttenberg has found or backout these changes before release. 2) Ville's work on string functions, as it's incomplete. And it was hard to understand from the commit messages if it is purely optimization or if it involves bug fixing as well. Anything else is something I missed. I've adopted a little more verbose format than previously, including references to svn changesets and tickets where possible. There are now three sections: "Features" which tries to summarize the features that would be interesting to end users "Fixes/Optimizations" summarizing all the fixes or optimizations that might prompt an end user to retry something that previously didn't work or was too slow, and "Other" which mostly summarizes changes to implementation details of interest to ABCL development. Comments (or direct changes in SVN) are welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 14

[armedbear-devel] some questions about r12503
by Ville Voutilainen 22 Feb '10

22 Feb '10

The separate pathname matcher for jars looks odd to me. I'd expect the listing to give whatever it gives, and the matching condition in directory.lisp to filter it. Is jar filtering so different that it requires a different matcher? Same question applies to the wildcard matching, jar listing seems to do the wildcard matching in java, rather than in lisp? That's also different from the way directory listings are handled. The list-directory primitive sorely needs to be split into two functions (listJar and listDirectory), it's getting long-winded. That's not a high-priority issue, but we need to mind function length, it's a huge readability issue.

2 2

[armedbear-devel] commit r12491
by Ville Voutilainen 21 Feb '10

21 Feb '10

I object to this patch. We have previously rejected code that sprinkles jnews and jcalls all over directory.java. I believe the proper way to introduce jar support for DIRECTORY would be to do it in the list-directory primitive in Pathname.java. At any rate, if we don't want that and want to do the jar logic in directory.lisp, then fine, add whatever primitives you need for the bare minimum, but _don't_ implement it as lisp code that only calls java code. That makes no sense (*). (*) Yes, it may make sense for user code that has to call java. I don't, however, think it makes sense for abcl internals, or namely directory.lisp. It looks ugly as sin, and it prevents using the code in non-java environments, if such ever arrive. We have a design where lisp code calls primitives that provide the bare minimum support from the java side, I think we should stick to that design.

2 4

[armedbear-devel] TypeError woes
by Ville Voutilainen 21 Feb '10

21 Feb '10

The String constructor for TypeError doesn't result in the message string to be printed. That's because the message is never set anywhere. Condition will give the message in getMessage(), and TypeError.getMessage() will use that if non-null, but nothing sets it. I'll attach a patch that corrects this, but I don't want to commit it yet - it looks woefully incorrect to me. Is this really what we have to do in all Condition-extending classes? Set a protected member? We already set the formatControl, why does that not work?

1 0

[armedbear-devel] ASDF-INSTALL committed to trunk
by Mark Evenson 20 Feb '10

20 Feb '10

A port of ASDF-INSTALL has been [committed to trunk][1]. [1]: http://trac.common-lisp.net/armedbear/changeset/12487 I have a lot of issues with the shape of this package. This is a commit to both get feedback and to leave a "stake in the ground" so I can move to the more pressing issue of the long form of DEFINE-METHOD-COMBINATION. I really don't expect ASDF-INSTALL to work well under Windows, but you at least need [cgywin installed][2] for the 'tar' and 'gpg' binaries to have a fighting chance. [2]: http://www.cygwin.com/ To use this package, one must invoke Ant with the target "abcl.contrib" whereupon a jar named "dist/abcl-contrib.jar" is created. Use the following in your ~/.abclrc (replacing ${dist.dir} with the absolute path of 'abcl-contrib.jar'): (require 'asdf) (pushnew "jar:file:${dist.dir}/abcl-contrib.jar!/asdf-install/" asdf:*central-registry*) Then issuing CL-USER> (require 'asdf-install) will load ASDF-INSTALL. After you have loaded ASDF-INSTALL, you use it by issuing commands of the form: CL-USER> (asdf-install:install :PACKAGE) where PACKAGE is [an asdf installable system identifier][3]. This will attempt to install that system and all of its dependencies under ~/.asdf-install-dir. [3]: http://www.cliki.net/ASDF-Install To use the system, you need to inform ADSF of the location to load systems by having (pushnew '(merge-pathnames ".asdf-install-dir/systems/" (user-homedir-pathname)) asdf:*central-registry*) in your '~/.abclrc'. What are my "issues"? 1. A large part of the value proposition of ASDF-INSTALL is that it is supposed to be help people newish to Lisp manage the installation of a lot of libraries to "get something running fast" but we don't have it as a standard part of ABCL. Why? Because ABCL should simply mean "you need Java x.x to run Common Lisp" leaving the platform distinctions behind. But since under Microsoft Windows ASDF-INSTALL relies on a) cygwin and b) symbolic links, it requires even *more* steps to get working for the hypothetical newcomer (who is likely coming from Windows in the first place). So we currently have no choice (or so I have argued myself into the position of) other than making ASDF-INSTALL an optional part of ABCL, if we wish to preserve the worthwhile semantics of platform independence. 2. The determination of the location of 'tar' and 'gpg' binaries should be better handled. 3. A lot of ASDF packages don't work well with ABCL, at least without patches. It would be nice to have something sort of like [Lispy][4] that could "intervene" for patching and recommendations for versions to install. In fact, a much more distributed manner of naming ADSF installable systems would be welcome. [4]: http://common-lisp.net/project/lispy/ 4. The #+windows conditionals make the asdf-contrib.jar non-platform independent. They should be replaced with (find :windows *features*) type forms. 5. The location of the 'abcl-contrib.jar' should at least be inferred from the location of 'abcl.jar' if they are in the same directory, but there isn't currently a reasonable proposal for how this would work to specify the ASDF location. 6. SBCL's version of asdf-install, although listed as "0.2" compared to the "0.6.10" that I ported seems to have more sophisticated conditionals for Microsoft Windows conditionals that should be examined for inclusion. Patches and comments welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] how to debug?
by Alan Ruttenberg 20 Feb '10

20 Feb '10

Could this be the result of some corruption of my java environment? Error loading /Users/alanr/repos/lsw/trunk/util/armedbear-0.19.0-dev-darwin-unknown/obo.abcl at line 16 (offset 951) Debugger invoked on condition of type ERROR: Class verification failed: (class: org/armedbear/lisp/obo_10, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Accessing value from uninitialized register 10 Restarts: 0: RETRY Retry performing #<ASDF:LOAD-OP (:VERBOSE NIL) {A3513D}> on #<ASDF:CL-SOURCE-FILE "obo" {DD5547}>. 1: ACCEPT Continue, treating #<ASDF:LOAD-OP (:VERBOSE NIL) {A3513D}> on #<ASDF:CL-SOURCE-FILE "obo" {DD5547}> as having been successful. [1] CL-USER(1): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {59067}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<ERROR {690C8E}>) 4: org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:237) 5: org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) 6: org.armedbear.lisp.Load.faslLoadStream(Load.java:548) 7: org.armedbear.lisp.Load.access$100(Load.java:54) [1] CL-USER(2):

3 14

[armedbear-devel] no restart on stack overflow
by Alan Ruttenberg 18 Feb '10

18 Feb '10

Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: Backtrace: 0: org.armedbear.lisp.Java$23.execute(Java.java:1013) 1: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 2: org.armedbear.lisp.swank_145.execute(swank.lisp:423) ... How do we abort this and recover the stack? -Alan

1 0

[armedbear-devel] It it worth cacheing jmethod and jclass calls?
by Blake McBride 16 Feb '10

16 Feb '10

I do: (let ((meth (jmethod "java.lang...." "javaMethodName" "arg-type")) (cls (jclass "java.lang....."))) (defun lisp-fun (arg) (jcall meth cls arg))) Rather than: (defun lisp-fun (arg) (jcall (jmethod "java.lang...." "javaMethodName" "arg-type") (jclass "java.lang.....") arg)) In order to cache the jmethod and jclass calls. I read in another post that this had no value because (essentially) this is what the compiler is doing anyway. Is this true? Does it make any difference which way I do it in terms of speed? Thanks. Blake McBride

2 1

[armedbear-devel] Better error reporting for wrong number of arguments
by Blake McBride 16 Feb '10

16 Feb '10

Greetings, When I call ABCL from Java and the Lisp code has an error ABCL reports various levels of detail about the error depending on the type of error. Sometimes the level of detail is very helpful, sometimes it's too vague. One error that's clearly too vague is: "Wrong number of arguments." If it told me what function had the wrong number of arguments it would be very helpful. Thanks. Blake McBride

1 0

[armedbear-devel] ABCL r12444 java.lang.IllegalStateException: zip file closed
by dmiles＠users.sourceforge.net 12 Feb '10

12 Feb '10

Heads up in ANSI-TESTS (btw this is reverting clos.lisp to r12422 so the ansi tests can be ran) COMPILE-FILE.3 "/development/ABCL/ansi-tests/compile-file-test-file-3.abcl" "/development/ABCL/ansi-tests/compile-file-test-file-3.abcl" 253.82 seconds real time 171506133 cons cells java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:403) at java.util.zip.ZipFile.getEntry(ZipFile.java:148) at org.armedbear.lisp.Pathname.truename(Pathname.java:1671) at org.armedbear.lisp.Pathname.truename(Pathname.java:1575) at org.armedbear.lisp.Load.load(Load.java:164) at org.armedbear.lisp.Load.load(Load.java:623) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:573) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators$8.execute(SpecialOperators.java:270) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:496) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:96) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:493) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at abcl_094a9fb9_5102_45fb_b8d5_a5e9c9b58404.execute(Unknown Source) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.rt_72.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_71.execute(rt.lsp:228) at org.armedbear.lisp.rt_75.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_70.execute(rt.lsp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.rt_86.execute(rt.lsp:348) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_85.execute(rt.lsp:335) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:488) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.Time$1.execute(Time.java:56) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Load.loadStream(Load.java:514) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.load(Load.java:185) at org.armedbear.lisp.Load.load(Load.java:623) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:573) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:457) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators$8.execute(SpecialOperators.java:270) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:275) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:765) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:619) Debugger invoked on condition of type ERROR: Caught java.lang.IllegalStateException: zip file closed. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

2 3