armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] patch to stop NPE in PATHNAME.WINDOWS.6
by Matthew L Daniel 27 May '11

27 May '11

Hello, When running `abcl.test' against r13286, I am experiencing a NullPointerException caused by the Pathname's URI having a null Path property. The patch below fixes this by reporting an error instead of just blindly passing it into java.io.File. Hope this helps, -- /v\atthew ---8<---patch-----8<-- --- a/src/org/armedbear/lisp/Pathname.java +++ b/src/org/armedbear/lisp/Pathname.java @@ -356,8 +356,12 @@ public class Pathname extends LispObject { + "'" + url.toString() + "'" + ": " + ex.toString())); } - File file = new File(uri.getPath()); - Pathname p = new Pathname(file.getPath()); + final String uriPath = uri.getPath(); + if (null == uriPath) { + error(new FileError("The URI has no path: "+uri)); + } + final File file = new File(uriPath); + final Pathname p = new Pathname(file.getPath()); this.host = p.host; this.device = p.device; this.directory = p.directory; --->8--end-patch-->8-- ---8<--exception-----8<-- ; (DEFTEST WINDOWS.4 ...) ; (DEFTEST WINDOWS.5 ...) ; (DEFTEST PATHNAME.WINDOWS.6 ...) Exception in thread "interpreter" java.lang.NullPointerException at java.io.File.<init>(File.java:222) at org.armedbear.lisp.Pathname.init(Pathname.java:359) at org.armedbear.lisp.Pathname.<init>(Pathname.java:174) at org.armedbear.lisp.Pathname.parseNamestring(Pathname.java:1021) at org.armedbear.lisp.Stream.readPathname(Stream.java:538) at org.armedbear.lisp.LispReader$15.execute(LispReader.java:247) --->8--end-exception-->8--

2 1

[armedbear-devel] ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)
by Mark Evenson 17 May '11

17 May '11

On 5/17/11 3:28 PM, Faré wrote: […] > Hope this helps. I'm gonna need a bit more time to chew over the ASDF code, but thanks for the general direction. I must confess that in spite of the reasonable looking documentation and having contributed the function translation code to ASDF, its whole output translation API has never really gelled in my understanding as a totality. Maybe I can contribute some examples to the texinfo file when the fuzz in my understanding resolves a bit. > BTW, for cl-launch and XCVB, I indeed am looking for a way to create > bundles from compiled stuff. How do I create a jar from ABCL and a set > of lisp files, precompiled or not? A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of ASDF system definitions that works well in a Java ecosystem is precisely the itch I'm in the process of scratching for ABCL right now. The base unit of packaging in Java is the jar file, which is nothing more than a ZIP archive with (possibly) some Java-the-language specific metadata. Currently, one can package an ASDF definition in a jar file, push the location of the asd file into ASDF:*CENTRAL-REGISTRY* using the [ABCL JAR-PATHNAME conventions][1] for which a subsequent ASDF:LOAD-SYSTEM will do the right thing. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… For instance, if you were to package up cl-ppcre installed via [quicklisp][10^9monkey-wants-this] in a jar file via unix$ cd ~/quicklisp/dists/quicklisp/software && jar cfv /tmp/cl-ppcre-2.0.3.jar cl-ppcre-2.0.3 [10^9monkey-wants-this]: http://www.quicklisp.org one could subsequently enable an ASDF controlled load of this system via CL-USER> (push "jar:file:/tmp/cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" asdf:*central-registry) When loaded, ASDF will compile the system to the user cache. Some problems here that I'm working through: 1) You can't immediately load FASL out of the jar. In my current hackish way—i.e. without comprehending your advice yet—one has first ASDF compile the system with output translations disabled, and then (defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file))) (setf (asdf::output-translations) '((t t)))) in the target JVM to load the ABCL FASLS from the jar. 2) One has to specify the absolute path on the local filesystem (or potentially via a URI) for the jar, which makes things a bit fragile in the typical Java ecosystem usage which shuffles jars around like win32 DLLs (or, to be fair, Unix dynamic libraries) relying merely on the filename to keep things straight. My current insight into a way around would be to define another PATHNAME extension in ABCL for CLASSPATH entries, i.e. "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar in the JVM CLASSPATH if it exists. 3) ABCL [has a bug][#149] that currently prevents ASDF systems located in the top-level entry of a JAR from being accessed. [#149]: http://trac.common-lisp.net/armedbear/ticket/149 4) The extremely nice use of [JSS][jss] and [ABCLD's slight modification][abcld] of ASDF to also refer to jar files to dynamically load into the JVM probably needs to be rewritten, otherwise we run into the situation whereby we have jars (i.e. the packaged Java code) within the ASDF packaged jar which A) needs changes within ABCL to completely work and B) would be rather inefficient in that the naive implementation each request for a new entry in the JAR within a JAR would require a complete "reseek" through the enclosed ZIP file. [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld 5) A fear of mine: if I enable all this, I presume that people would start going around creating 'abcl.jar' files with different inclusions of different ASDF packagings. Without a real smart dynamic introspection system that essentially solves the problems in JVM's classpath we would end up with, at the minimum, a rather hostile situation for the end user. "Put 'abcl.jar' in your classpath." "I did, and it still didn't load Maxima." "Well, what's the checksum of your abcl.jar?" "c48d359a23ee" "Oh, you need 846f78c279cb". Ideally, I would like to come up with a mechanism that would require that 'abcl.jar' come from "official" ABCL packaging, but would somehow be able to introspect the JVM classpath to include ASDF definitions. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 5

[armedbear-devel] ABCL-0.25.0
by Paul Bowyer 17 May '11

17 May '11

Hello: I'm very new to lisp and decided to try ABCL to see how it works. I have some experience (not much though) with SBCL and CMUCL using Slime. I've also tried ClozureCL, but it is a little more problematic. I built ABCL with: Netbeans-6.9 (ant-1.8.2) and with: Netbeans-7.0 (ant-1.11.1) as Java Free-Form Projects In both cases, ABCL built without noticeable problems. I'm running PCLinuxOS, so I used the install instructions for Linux from: "http://common-lisp.net/project/armedbear/doc/abcl-install-with-java.html" by copy/paste of "test.lisp" and running : "java -jar <mypath>/abcl.jar --load test.lisp" which also went without problems. I then created a shell script (named "abcl") in my home directory by copy/paste of your "/usr/bin/lisp" with the corrected "ABCL_JAR=" set for the location of my newly built "abcl.jar" but when I run that script from a Konsole shell, the "CL-USER(1):" prompt copies itself plus the character I typed for each character I type at the prompt. As I type, the screen fills with "CL-USER(1):" until I press the enter key and then the lisp form is evaluated and the CL-USER(2): is now at the normal expected location at the lower- left corner of the shell. I have "rlwrap 0.30" installed for use with ABCL. Startup of ABCL: ---------------------------------------------------------------------- Armed Bear Common Lisp 0.25.0 Java 1.6.0_24 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.746 seconds. Startup completed in 2.318 seconds. Type ":help" for a list of available commands. ---------------------------------------------------------------------- I tried using ABCL with Slime and it starts up OK, but it would not compile and load some lisp files that work properly with SBCL and CMUCL. From a Konsole shell using: 'java -jar "<mypath>/abcl.jar"' to run ABCL so as to avoid the prompt problem, I tried: :cload <mypath-to-files>/util.lisp and it went through the compile, but choked at loading with the following: ---------------------------------------------------------------------------------------------------------------------------------------- ; Compiling <mypath-to-files>/util.lisp ... ; (IF (NOT #) ...) ; (IN-PACKAGE "UTIL") ; (DEFUN ELEMENTP ...) ; (DEFTYPE ELEMENT ...) ; (DEFUN LIST-DUP-EL-SRCH ...) ; (DEFUN BAGP ...) ; (DEFTYPE BAG ...) ; Wrote <mypath-to-files>/util.abcl (0.644 seconds) Error loading <mypath-to-files>/util.abcl at line 6 (offset 274) #<THREAD "interpreter" {993730}>: Debugger invoked on condition of type PACKAGE-ERROR The symbol COMMON-LISP-USER::ELEMENTP is not accessible in package UTIL. Restarts: 0: TOP-LEVEL Return to top level. ---------------------------------------------------------------------------------------------------------------------------------------- This was one of the files that compiles and loads without problems with SBCL or CMUCL. ClozureCL will compile and load this file from Slime if I coax it through the process, but it takes more effort than SBCL or CMUCL. I have attached the source for this file if it is needed. It is just some code built by following (kind of) some common lisp tutorial instructions. pbowyer

2 2

[armedbear-devel] Fwd: ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)
by Mark Evenson 17 May '11

17 May '11

-------- Original Message -------- Subject: ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation) Date: Tue, 17 May 2011 21:47:07 +0200 From: Mark Evenson <evenson-VmQCmMdMyN0AvxtiuMwx3w(a)public.gmane.org> To: asdf-devel-F1HGIaG5STRyXAeb93iumQ(a)public.gmane.org CC: Armed Bear <armedbear-devel-F1HGIaG5STRyXAeb93iumQ(a)public.gmane.org> Newsgroups: gmane.lisp.asdf.devel References: <iqtmt0$7ec$1(a)dough.gmane.org> <BANLkTin8YBewU_=NnwOB53sxsn=rkqsOxA(a)mail.gmail.com> On 5/17/11 3:28 PM, Faré wrote: […] > Hope this helps. I'm gonna need a bit more time to chew over the ASDF code, but thanks for the general direction. I must confess that in spite of the reasonable looking documentation and having contributed the function translation code to ASDF, its whole output translation API has never really gelled in my understanding as a totality. Maybe I can contribute some examples to the texinfo file when the fuzz in my understanding resolves a bit. > BTW, for cl-launch and XCVB, I indeed am looking for a way to create > bundles from compiled stuff. How do I create a jar from ABCL and a set > of lisp files, precompiled or not? A reasonable packaging mechanism for ABCL plus "compiled stuff" composed of ASDF system definitions that works well in a Java ecosystem is precisely the itch I'm in the process of scratching for ABCL right now. The base unit of packaging in Java is the jar file, which is nothing more than a ZIP archive with (possibly) some Java-the-language specific metadata. Currently, one can package an ASDF definition in a jar file, push the location of the asd file into ASDF:*CENTRAL-REGISTRY* using the [ABCL JAR-PATHNAME conventions][1] for which a subsequent ASDF:LOAD-SYSTEM will do the right thing. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… For instance, if you were to package up cl-ppcre installed via [quicklisp][10^9monkey-wants-this] in a jar file via unix$ cd ~/quicklisp/dists/quicklisp/software && jar cfv /tmp/cl-ppcre-2.0.3.jar cl-ppcre-2.0.3 [10^9monkey-wants-this]: http://www.quicklisp.org one could subsequently enable an ASDF controlled load of this system via CL-USER> (push "jar:file:/tmp/cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" asdf:*central-registry) When loaded, ASDF will compile the system to the user cache. Some problems here that I'm working through: 1) You can't immediately load FASL out of the jar. In my current hackish way—i.e. without comprehending your advice yet—one has first ASDF compile the system with output translations disabled, and then (defmethod asdf:perform ((o asdf:compile-op) (c asdf:cl-source-file))) (setf (asdf::output-translations) '((t t)))) in the target JVM to load the ABCL FASLS from the jar. 2) One has to specify the absolute path on the local filesystem (or potentially via a URI) for the jar, which makes things a bit fragile in the typical Java ecosystem usage which shuffles jars around like win32 DLLs (or, to be fair, Unix dynamic libraries) relying merely on the filename to keep things straight. My current insight into a way around would be to define another PATHNAME extension in ABCL for CLASSPATH entries, i.e. "classpath:cl-ppcre-2.0.3.jar!/cl-ppcre-2.0.3/" would refer to the named jar in the JVM CLASSPATH if it exists. 3) ABCL [has a bug][#149] that currently prevents ASDF systems located in the top-level entry of a JAR from being accessed. [#149]: http://trac.common-lisp.net/armedbear/ticket/149 4) The extremely nice use of [JSS][jss] and [ABCLD's slight modification][abcld] of ASDF to also refer to jar files to dynamically load into the JVM probably needs to be rewritten, otherwise we run into the situation whereby we have jars (i.e. the packaged Java code) within the ASDF packaged jar which A) needs changes within ABCL to completely work and B) would be rather inefficient in that the naive implementation each request for a new entry in the JAR within a JAR would require a complete "reseek" through the enclosed ZIP file. [jss]: http://code.google.com/p/lsw2/source/browse/#svn%2Ftrunk%2Fjss [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse?repo=abcld 5) A fear of mine: if I enable all this, I presume that people would start going around creating 'abcl.jar' files with different inclusions of different ASDF packagings. Without a real smart dynamic introspection system that essentially solves the problems in JVM's classpath we would end up with, at the minimum, a rather hostile situation for the end user. "Put 'abcl.jar' in your classpath." "I did, and it still didn't load Maxima." "Well, what's the checksum of your abcl.jar?" "c48d359a23ee" "Oh, you need 846f78c279cb". Ideally, I would like to come up with a mechanism that would require that 'abcl.jar' come from "official" ABCL packaging, but would somehow be able to introspect the JVM classpath to include ASDF definitions. Comments solicited. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." _______________________________________________ asdf-devel mailing list asdf-devel(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

1 0

[armedbear-devel] JAVA:*JAVA-OBJECT-TO-STRING-LENGTH* controls pretty print length
by Mark Evenson 17 May '11

17 May '11

[r13277][1] now places the control of the elision of PRINT-OBJECT representation of otherwise an unspecialized JAVA-OBJECT by the value of JAVA:*JAVA-OBJECT-TO-STRING-LENGTH*. [1]: http://trac.common-lisp.net/armedbear/changeset/13277 The addresses the problem Blake McBride reported as follows (in an email that mysteriously didn't make it to the armedbear-devel list) On 5/14/11 03:19 , Blake McBride wrote: > I am trying to pretty-print an object. I'm getting: > > #(#<java.lang.reflect.Field private static final long com.ar... {6666F55B}> > #<java.lang.reflect.Field public static final java.lang.St... {43D027D5}> > #<java.lang.reflect.Field public static final java.lang.St... {7CDF3533}> > #<java.lang.reflect.Field public static final java.lang.St... {221DE751}> > #<java.lang.reflect.Field public static final java.lang.St... {593D8856}>) > > I need to be able to see the "..." parts in order to debug a problem I > am having. I tried virtually every combination of printer control > variables I could think of with no changes at all. I have also changed the elision character sequence from "..." to "...." to avoid confusing users that this has anything to do with the standard pretty printer variables (*PRINT-LENGTH* uses "..." to indicate its elision). -- "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 use ABCL's debugger
by David C Wang 16 May '11

16 May '11

I recently started using ABCL, and until now I've been able to use it fine through the Emacs/Slime interface. I'm now trying to use ABCL directly from the command line, but I have no idea what the debugger commands are. Once a runtime error occurs and I am offered the list of possible restarts, how do I check the current frame and step through the backtrace? Is there documentation on this somewhere? Or, can someone tell me what some of the basic commands are? I'm running the latest ABCL on Fedora 14 x64. - Thank you! - David W.

2 2

[armedbear-devel] test, please ignore
by Alessio Stalla 14 May '11

14 May '11

This is a test message. Blake McBride reported that one mail of his got rejected.

1 0

Re: [armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Erik Huelsmann 04 May '11

04 May '11

Dan, On Mon, May 2, 2011 at 10:08 AM, Dan Corkill <corkill(a)gbbopen.org> wrote: > >> It'll take more than the 20 minutes I had to analyze the best >> solution. I'll come back hopefully later this week. > > Thanks Erik. I'm using the short-term workaround of allowing > ABCL to shout back at me (by not setting *print-case* to my > usual :downcase personal preference...). Just committed the fix to trunk. Enjoy! Bye, Erik.

2 1

[armedbear-devel] *print-case* :downcase breaks DEFSTRUCT compilation
by Dan Corkill 02 May '11

02 May '11

Compiling the following file in the latest ABCL (r13272) illustrates the error: --------------------------- (in-package :cl-user) (eval-when (:compile-toplevel :load-toplevel :execute) (setf *print-case* ':downcase)) (defstruct rec a b) --------------------------- Alternatively, remove the EVAL-WHEN and set *PRINT-CASE* as :downcase before compiling the file containing only the DEFSTRUCT.

3 2

[armedbear-devel] Patch: call reinitialize-instance on metaclass on class redefinition
by Alessio Stalla 02 May '11

02 May '11

Hello, I found out that ABCL, when redefining a class, modifies the old class metaobject in-place, slot by slot. This has the implication that the redefinition of an instance of a custom metaclass does not update custom slots. Now, I didn't check on the AMOP, but I'm pretty sure the proper class redefinition protocol is more articulate than the one implemented in ABCL; still, applying the patch that you find attached fixes the problem of custom slots not being updated by calling reinitialize-instance where the old code manually updated the class metaobject, so it is, I think, a valid temporary solution until we have a full MOP. However, before committing the patch, I'd like to hear your opinion about it. The patch also includes some tabs converted to spaces, sorry for the noise. Bye, Alessio

1 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel