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

[armedbear-devel] Using print and read together.
by Ted Kosan 13 Jun '11

13 Jun '11

Hello, I am currently working through the "Land of Lisp" book by Conrad Barski and I am using ABCL to run all of the code in the book. In the following code, the prompt that is printed by 'print' is not seen until after 'read' returns: (defun add-five() (print "Pleaser enter a number:") (let ((num (read))) (print "When I add five I get") (print (+ num 5)))) Is it possible to configure ABCL to have the output from 'print' be visible immediately so that it can be used to prompt the user to input some information? Thanks in advance, Ted

3 2

[armedbear-devel] ASDF 2.016 released
by Faré 09 Jun '11

09 Jun '11

Dear Lisp implementors, below is the announcement for ASDF 2.016, as posted on the asdf-announce mailing-list, also accessible via its gmane mirror gmane.lisp.asdf.announce. Please have me take your list off my forwarding aliases if unappropriate. Can you upgrade your implementation to ship with the latest ASDF? Thanks! If you're still using 2.015 (or something even older), there have been many bug fixes, robustness, portability and upgradability enhancements and a few features implemented since. We recommend that you keep (require :asdf) working as well as (require "asdf"). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Consider this: the first hole ever dug on the moon by a man-made machine is now done. It is the most expensive hole in the history of the human race. Now, what does that mean? How do we know whether this is one of man's noblest achievements or if it is a game being played by a small group of lunatics for their own amusement — at our expense?" — Neil Postman, "Teaching as a Subversive Activity" ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: 7 June 2011 20:30 Subject: ASDF 2.016 released To: asdf-announce(a)common-lisp.net Cc: ASDF-devel <asdf-devel(a)common-lisp.net> Dear CL users, I released ASDF 2.015.12 as 2.016. Please test, and upon success update your implementations and lisp distributions. Since 2.015, we have the following improvements: * Portability: Fixes for ECL, RMCL. Tweaks for CLISP. Improvements to Windows configuration, notably for LispWorks. * Fix to load-source-op (broken in 2.014.13 - oops). * Avoid infinite loops in defsystem in cases of bad interference between quicklisp and your source-registry. * Small fixes regarding upgrade, compile-file* :output-file. * Make defsystem-depends-on actually useful by allowing a system thus depended on to define the class of the system depending on it. The XCVB bridge notably relies on this feature. * Some documentation updates. Notably, for the sake of CLISP, (require "asdf") is the new canonical way to load ASDF, instead of (require :asdf). Sigh. * Better tests, notably wrt hot upgrade. Happy hacking! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American diplomat to the Russian: "My country too is free: in the USA too anyone may freely publish the dirty little secrets of president Medvedev!"

2 3

[armedbear-devel] Patch to get ABCL working with TRIVIAL-GARBAGE
by Mark Evenson 07 Jun '11

07 Jun '11

Thanks to Erik's recent work to support both object finalizers and weak reference, and my own recent implementation of weak hash tables, ABCL as of [r13310][] now supports [trivial-garbage][] with the [attached patch][trivial-garbage-20101006-darcs-abcl-20110607a.diff]. [r13310]: http://trac.common-lisp.net/armedbear/changeset/13310 [trivial-garbage]: http://www.cliki.net/trivial-garbage [trivial-garbage-20101006-darcs-abcl-20110607a.diff]: http://detroit.slack.net/~evenson/abcl/trivial-garbage-20101006-darcs-abcl-… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #150: MAKE-PATHNAME ignores version in :DEFAULTS
by Erik Huelsmann 04 Jun '11

04 Jun '11

Same commit-simulation, please ignore. On Sat, Jun 4, 2011 at 11:25 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #150: MAKE-PATHNAME ignores version in :DEFAULTS > -----------------------+---------------------------------------------------- > Reporter: mevenson | Owner: mevenson > Type: defect | Status: closed > Priority: minor | Milestone: 0.26 > Component: java | Version: 0.24 > Resolution: fixed | Keywords: pathname asdf > -----------------------+---------------------------------------------------- > > Comment(by mevenson): > > (In [13294]) Fix #150: MAKE-PATHNAME ignores version in :DEFAULTS. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/150#comment:8> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[armedbear-devel] ABCL and multithreading
by Matus Kmit 01 Jun '11

01 Jun '11

Hi Does ABCL supports multithreading? Greetings, Matus

2 1

[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