armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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

[armedbear-devel] [PATCH] Access command line arguments
by Dennis Lambe Jr. 12 Feb '10

12 Feb '10

I've written a small patch to ABCL that copies unrecognized command line arguments into ext:*command-line-argument-list*. This is analogous to SBCL's sb-ext:*posix-argv* or CLISP's ext:*argv* (but without the executable name that heads up those variables, since that's not passed in to the Java main() function). I hope you find it useful enough to merge in. --Dennis Lambe Jr. malsyned(a)malsyned.net

2 1

[armedbear-devel] Building with Netbeans
by Paul Griffioen 12 Feb '10

12 Feb '10

Hi everybody I'm having trouble building the latest version of ABCL from Netbeans. Can you help me out? I work with Netbeans 6.8 (just upgraded for ANT) and run the build from the menu. Running the generated jar with 'java -jar abcl.jar geeft' gives the following message: Failed to load Main-Class manifest attribute from abcl.jar I noticed that the manifest.mf just contains the following: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 1.6.0_0-b11 (Sun Microsystems Inc.) Class-Path: Is the Netbeans build supposed to work? Does anybody have any idea why the Main is not in the generated manifest? A second question is what the best way is to include the jna library. I'm trying to compile CFFI with ABCL but that required jna as the following quote from CFFI's code shows: ;;; This implementation requires the Java Native Access (JNA) library. ;;; <http://jna.dev.java.net/> I downloaded the required jna.jar and figured that I could include it somehow in abcl.jar after building that. Unfortunately that build failed but I would like to be able to use it from Netbeans anyway. Does anybody know how to do that? My knowledge of the Java ecosystem is limited so figuring this out for ABCL specifically is not easy. Finally I would appreciate feedback on the following patch for TRIVIAL-FEATURES I needed to write to get CFFI to compile. It turned out that the endianess feature wasn't set. diff -rN old-trivial-features/src/tf-abcl.lisp new-trivial-features/src/tf-abcl.lisp 31c31,38 < ;;; TODO --- > (pushnew (let ((order (jcall "toString" > (jstatic "nativeOrder" "java.nio.ByteOrder")))) > (cond ((string-equal order "LITTLE_ENDIAN") > :little-endian) > ((string-equal order "BIG_ENDIAN") > :big-endian) > (t (error "Byte order ~A unknown" order)))) > *features*) Like I said, I'm no Java expert and feedback would be helpful. Any comment, help or pointers would be appreciated. Paul

2 3

[armedbear-devel] Passing lisp objects from java to lisp
by Blake McBride 11 Feb '10

11 Feb '10

Greetings, If I have a lisp function as follows: (defun myfun (a b) (+ a b)) I want to be able to call it from lisp or java. In other words I don't want the lisp side to have to use jobject-lisp-value. Therefore, from the java side, how do I take a java object and translate into a lisp object so that when I call the execute method the lisp function doesn't need jobject-lisp-value? Thanks. Blake McBride

2 1

[armedbear-devel] [PATCH] Access command line arguments
by Dennis Lambe Jr. 11 Feb '10

11 Feb '10

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel