armedbear-devel May 2011

armedbear-devel@common-lisp.net

13 participants
15 discussions

[armedbear-devel] readtable-case :invert does not invert uninterned symbols
by Ole Arndt 16 Aug '11

16 Aug '11

This prevents loading a newer parenscript, which uses an inverted readtable case via named-readtables: Armed Bear Common Lisp 0.26.0-dev-svn-13273 Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.712 seconds. Startup completed in 3.154 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf (readtable-case *readtable*) :invert) :invert CL-USER(2): (string :cl) "CL" CL-USER(3): (string '#:cl) "cl" Cheers Ole -- Ole Arndt http://www.sugarshark.com

3 5

[armedbear-devel] Spaces in pathnames (jar:file:/x/y/z/a space/...)
by Theam Yong Chew 11 Jul '11

11 Jul '11

Dear ABCL developers, While ABCL can handle spaces (& others) in file pathnames just fine, a space in jar file pathnames still doesn't work. I have confirmed this on Linux, Mac and Windows. An example using Cygwin, $ java -jar abcl.jar Armed Bear Common Lisp 0.24.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.625 seconds. Startup completed in 4.438 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "jar:file:e:/My Dropbox/temp/a space/hello.jar!/hello.abcl") #<THREAD "interpreter" {9AC0F5}>: Debugger invoked on condition of type FILE-ERROR Failed to create URI from 'e:/My Dropbox/temp/a space/hello.jar': Illegal character in opaque part at index 10: file:e:/My Dropbox/temp/a space/hello.jar Restarts: 0: TOP-LEVEL Return to top level. (and yeah, this particular path already has a space character in "My Dropbox" along with my original intended "a space" folder) By the way, thanks for the :wildcard directory support (I've only just tested that, it works for me now!). Yong.

4 15

[armedbear-devel] The value :LONG is not of type (MEMBER NIL :BOOLEAN)
by Chun Tian (binghe) 30 May '11

30 May '11

Hi, ABCL developers I found my program have some CLOS code which could get the weakness of ABCL ... It's cl-net-snmp [1], which I just release a whole new version few days ago. My goal on ABCL is to make sure the server-side version (a pure Lisp SNMP Agent) run as a separated thread in JVM, so that people can use my program to remotely monitor any Java (or ABCL) servers. (I know some ABCL people are fixing bordeaux-threads, I'm watching this work and hope it could be done soon) Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6 and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN). I have no idea how to fix it. Regards, Chun Tian (binghe) [1] http://common-lisp.net/project/cl-net-snmp/snmp.html Below are the error outputs when compiling a lisp file from cl-net-snmp: #<THREAD "interpreter" {24CCF86}>: Debugger invoked on condition of type TYPE-ERROR The value :LONG is not of type (MEMBER NIL :BOOLEAN). Restarts: 0: TRY-RECOMPILING Try recompiling pdu 1: RETRY Retry compiling component ("snmp" "pdu"). 2: ACCEPT Continue, treating compiling component ("snmp" "pdu") as having been successful. 3: TOP-LEVEL Return to top level. [1] SNMP(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {6BA52C90}>) 2: (JVM::COMPILE-FORM #<JVM::LET/LET*-NODE {2910D926}> JVM::STACK :LONG) 3: (JVM:COMPILE-DEFUN NIL (LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) NIL "/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/packages/snmp/ASDF_TMP_pdu_6.cls" #<FILE-STREAM {6539DEFE}> NIL) 4: (#<FUNCTION {753896F2}>) 5: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {753896F2}>) 6: (SYSTEM::C-E-M-1 (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FUNCTION) 7: (SYSTEM::CONVERT-ENSURE-METHOD (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))))

3 13

[armedbear-devel] Tentative inclusion of JSS with ABCL contrib
by Mark Evenson 27 May '11

27 May '11

Sick of having Clojure eat ABCL's lunch, I've decided to [start trying to include JSS as an ABCL contrib][1] to bring forward a more public platform for Java interop experiments on ANSI CL. Or at least the example of one such platform. [1]: http://trac.common-lisp.net/armedbear/changeset/13281 I've gotten to the point of eliminating the use of bsh-2.0b4.jar, and most of INVOKE-RESTARGS without the jscheme.jar stuff. Essentially the ABCL Java routines have evolved to a point that none of the external JAR dependencies should be necessary. When jscheme.jar is eliminated, we will be able to load JSS quite comfortably from abcl-contrib.jar (even over the network). With the additional syntax for ASDF, we will be able to start formalizing a packaging mechanism that allows us to mix Lisp/Java libraries in a systematic manner. One question for Alan about the #1"something" form of the JSS macro: is relied on outside of JSS? It seems like it was introduced to get around a bug in abcl-0.18, but doesn't seem to be used anywhere inside the lsw2 code base. I've eliminated it in my port of JSS, but would like confirmation that nothing should be using it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[armedbear-devel] ABCL and ASDF
by Faré 27 May '11

27 May '11

Dear ABCL developers, another bug in ABCL: (defparameter *wild-file* (make-pathname :name :wild :type :wild :version :wild :directory nil)) (describe *wild-file*) (describe (make-pathname :defaults *wild-file*)) Apparently, make-pathname fails to copy the version from the defaults. ASDF currently works around this somehow. PS: in a future ABCL release, please include ASDF 2.015.5 or later. Maybe 2.016 will have been released by then. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The difference between a contemporary liberal and a socialist is that to a liberal the most beautiful word in the English language is 'forbidden', whereas to a socialist the most beautiful word is 'compulsory'. — John McCarthy

3 8

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel May 2011