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

defgeneric, defmethod, and incongruent lambda list... bug?
by Paul Nathan 09 Aug '16

09 Aug '16

Hi, I have a generic function (defgeneric equals (a b &rest keys &key recursive key &allow-other-keys) ... ) This method works correctly: (defmethod equals ((a t) (b t) &rest keys) (declare (ignore keys)) (equalp a b)) ... ) But, this method throws an error: (defmethod equals ((a float) (b float) &rest keys &key floating-compare (max-relative-diff 1.19e-7)) ... ) My understanding from http://www.lispworks.com/documentation/HyperSpec/Body/07_fd.htm is that since &allow-other-keys has been set, this should work. As a point of reference, SBCL allows this, but of course that is not the determinant of correctness. :-) Best regards, Paul

1 0

errors in threads corrupt terminal IO
by Vibhu Mohindra 04 Aug '16

04 Aug '16

Hi, Is anyone aware of any reasons not to use threads in a production ABCL program? I'm preparing to deliver a program mostly written in Lisp, with a layer of Java on top so Java programmers can interact with it. The Lisp code runs a handful of daemon threads, some of which are lparallel worker threads. I'm specifically wondering whether errors raised inside threads will corrupt any of ABCL's internal state. e.g. in an ABCL REPL, this corrupts the terminal: (ql:quickload "bordeaux-threads") (use-package "BORDEAUX-THREADS") (make-thread #'(lambda () (error "testing"))) ;now press "enter" a couple of times. It's as though multiple threads are trying to read from the terminal, not just write. My program doesn't have a REPL, so if this is only a REPL problem, that's okay. I'm wondering if it's something bigger. If anyone on this list has used threads, and found any sort of instability because of them, I'd love to know. I'll then rewrite my program to not use threads. Thanks in advance, Vibhu ---- abcl-1.3.2 on OSX bordeaux-threads-0.8.3 ----

1 0

#'directory likely bug
by Vibhu Mohindra 01 Jul '16

01 Jul '16

In a directory containing files and directories, (directory (make-pathname :directory '(:relative :wild))) lists only the directories, in CCL, SBCL, CLISP, ECL, but in ABCL (1.3.2) produces this error: #<THREAD "interpreter" {71225B71}>: Debugger invoked on condition of type TYPE-ERROR The value NIL is not of type (OR PATHNAME STRING FILE-STREAM SYSTEM:JAR-STREAM SYSTEM:URL-STREAM). This is triggered by the existence of a file in OSX named ./.android/adbkey , or in general by the existence of: $ mkdir .d1 $ touch .d1/f1 [CMUCL seems wrong. It lists contents of subdirectories of current directory (but not their subdirectories).] Vibhu

1 0

ABCL and Truffle
by Alessio Stalla 24 Jun '16

24 Jun '16

Hi list, is anyone aware of Truffle/Graal from Oracle? Here some insightful slides: https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf Since there's been talk about rewriting the ABCL compiler which is old, messy and not very optimizing, I wonder if Truffle can be a useful technology to base a new compiler on. Not as the default because it requires Java 9 (or perhaps 8), but at least as a future-proof solution. It seems to me that getting started is not hard - just map the Lisp S-expression based AST to a Truffle AST; optimizations can follow incrementally. What do you think? I don't have the resources to work on it anytime soon, I'm letting my own projects slip sadly - it would be great to work on it. Still, maybe someone else is interested. I can contribute some design and code reviews, if need be, but little actual coding. Peace Alessio

2 1

#'asdf-jar:add-to-asdf use-jar-fasls is ineffective
by Vibhu Mohindra 24 Jun '16

24 Jun '16

Hi, I've got #'asdf-jar:package to create a jar file containing lisp sources and fasls. With abcl-1.0.1, (asdf:operate 'asdf:load-op ...) uses the fasls from the jar, whereas with abcl-1.1.0 onwards those fasls are ignored and the jarred sources are compiled into ~/.cache/... again. Is this a bug, or is it a feature (as easyE seems to think it is, in the last two sentences at: http://stackoverflow.com/questions/4763910/abcl-compilation-and-primitives )? If it's a bug, here is how far I've got in my diagnosis. (asdf-jar:add-to-asdf "wispym.jar") shows this in abcl-1.0.1 ((#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*" T) (#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*" #P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*") (#P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {2B63F8AD}>) (T #P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*")) but this in abcl-1.3.2, ((#P"/**/*.*" T) (#P"/**/*.*" #P"/**/*.*") (#P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {4F340027}>) (T #P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*")) I think these are asdf output-translations, each specifying a source directory and a corresponding destination directory. The first two entries are significantly different between abcl-1.0.1 and abcl-1.3.2. ---- The reason I'd like to use the jarred fasls is that I'm distributing my program to customers. I don't want to spew fasls around their hard disks. I also don't want to get into having to explain to them to clear caches. (I do have to do this locally on occasion, e.g. when timestamps on files confuse the cache). But most importantly, I've got a large cl-yacc grammar that takes ages to macroexpand and compile. I don't want them to wait so long even though it's just on the first load. ---- Any tips for where I should look next will be much appreciated. ASDF, ABCL, ABCL contrib? Thanks for reading. Vibhu

2 2

merge-pathnames bug with :back component
by Vibhu Mohindra 15 Jun '16

15 Jun '16

CLHS for merge-pathnames specifies that, "This removal of redundant :back keywords is repeated as many times as possible." abcl-1.3.2 The first expression below evaluates correctly, but the second produces an error. FCFS(34): (merge-pathnames (make-pathname :directory '(:relative "a" "b" :back)) (make-pathname :directory '(:absolute "root"))) #P"/root/a/" FCFS(35): (merge-pathnames (make-pathname :directory '(:relative "a" "b" :back :back)) (make-pathname :directory '(:absolute "root"))) #<THREAD "interpreter" {43B4AF3C}>: Debugger invoked on condition of type FILE-ERROR Unsupported directory component BACK. Restarts: 0: TOP-LEVEL Return to top level. For what it's worth, CCL also produces an error. CLISP, ECL, SBCL correctly produce: #P"/root/" (That said, I'm far from a pathname expert and could be completely wrong.) Vibhu

2 1

publish system::expand-deftype ?
by Massimiliano Ghilardi 13 Jun '16

13 Jun '16

Hello, for my library https://github.com/cosmos72/cl-parametric-types I need the function introspect-environment:typexpand, which expands DEFTYPE'd types, similarly to what CL:MACROEXPAND does for macros. Even though introspect-environment does not support ABCL, I found that system::expand-deftype does exactly what I need, yet I am wary of using a non-exported symbol from ABCL. Is system::expand-deftype stable enough to be published as an ABCL extension to ANSI CL and to be used to implement introspect-environment:typexpand ? Regards, Massimiliano

2 1

function documentation patch
by Alan Ruttenberg 01 Jun '16

01 Jun '16

When a function object is given to describe function documentation is not shown (it's shown on the symbol). Because of this, the slime function documentation doesn't show it either. Index: src/org/armedbear/lisp/describe.lisp =================================================================== --- src/org/armedbear/lisp/describe.lisp (revision 14850) +++ src/org/armedbear/lisp/describe.lisp (working copy) @@ -89,7 +89,13 @@ (setf plist (cddr plist)))))) (FUNCTION (%describe-object object stream) - (describe-arglist object stream)) + (describe-arglist object stream) + (let ((function-symbol (nth-value 2 (function-lambda-expression object)))) + (when function-symbol + (let ((doc (documentation function-symbol 'function))) + (when doc + (format stream "Function documentation:~% ~A~%" doc))) + ))) (INTEGER (%describe-object object stream) (format stream "~D.~%~

2 2

Format ~$ buglet
by Scott L. Burson 28 Apr '16

28 Apr '16

In 1.3.2, > (format nil "~$" -32.17) --32.17 Negative values are getting a double minus sign. The right fix seems to be, in 'format-dollars', to pass '(abs number)' rather than 'number' to 'sys::flonum-to-string'. -- Scott

2 1

[CFPart] ELS'16, 9th European Lisp Symposium, May 9-10, Kraków, Poland
by Didier Verna 06 Apr '16

06 Apr '16

ELS'16 - 9th European Lisp Symposium Department of Computer Science AGH University of Science and Technology Kraków, Poland May 9-10, 2016 In cooperation with: ACM SIGPLAN Sponsored by EPITA, Franz Inc., LispWorks Ltd., IdEx and Dept. of Computer Science AGH UST http://www.european-lisp-symposium.org/ Recent news: - Full programme now available online - Registration now open (early registration deadline: April 25) The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. Keynote speakers: - Pierre Castéran -- Program Proving with Coq - Stephan Karpinski -- Julia: to Lisp or Not to Lisp? - Francis Sergeraert -- Lexical Closures and Complexity Important dates: - 25 Apr 2016 Early registration deadline - 9-10 May 2016 Symposium Programme chair: Irène Durand, LaBRI, University of Bordeaux, France Local chair: Michał Psota, Emergent Network Defense, Kraków, Poland Programme committee: Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade de Lisboa, Portugal Charlotte Heerzel — IMEC, Leuven, Belgium Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Christophe Rhodes — Goldsmiths, University of London, United Kingdom Didier Verna — EPITA Research and Development Laboratory, France Erick Gallesio — University of Nice-Sophia Antipolis, France François-René Rideau, Google, USA Giuseppe Attardi — University of Pisa, Italy Kent Pitman, HyperMeta Inc., USA Leonie Dreschler-Fischer — University of Hamburg, Germany Pascal Costanza — Intel Corporation, Belgium Robert Strandh — University of Bordeaux, France Search Keywords: #els2016, ELS 2016, ELS '16, European Lisp Symposium 2016, European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium, European Lisp Conference 2016, European Lisp Conference '16 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Synonym streams and column position
by Stas Boukarev 04 Apr '16

04 Apr '16

(let ((stream (make-synonym-stream '*standard-output*))) (write-char #\c stream) (system::stream-charpos stream)) prints abcabc (let ((stream (make-synonym-stream '*standard-output*))) (write-char #\c stream) (system::stream-charpos stream)) => 0 -- With best regards, Stas.

2 5

ASDF 3.1.7 has been released
by Robert P. Goldman 23 Mar '16

23 Mar '16

ASDF 3.1.7 is a bugfix release, enhancing the 3.1.x ASDF series. To the best of our knowledge, it only fixes bugs, and should thus be a low-risk upgrade for inclusion in implementations. Thanks, as ever, to Faré for many fixes, and to other bug reporters and patch-suppliers. See the Changelog (below) for a summary of changes. Bug fix and portability release: * Fix compilation on Genera. * Fix UIOP:FILE-EXISTS-P for dotfiles on CCL. * Fix infinite loop in source registry configuration that can occur when there are cycles in the filesystem (typically caused by symlinks) on some CL implementations. * Miscellaneous bug fixes. * Documentation improvements. * Restore original Makefile. -- Robert P. Goldman <rpgoldman(a)sift.net> Wed, 23 Mar 2016 09:34:14 -0500

1 0

Syntactic sugar to call Java from ABCL?
by EGarrulo 06 Mar '16

06 Mar '16

Hello ABCL developers, has anybody written some macros to make calling Java from ABCL more straightforward? I mean something that, instead of this code from the ABCL documentation: (defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result))) would let you write something like this, for example: (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" ;; Let's imagine that we have defined a -> macro. (-> |Main.addTwoNumbers| 2 4) Thank you.

2 3

[CfP] ELS 2016 Deadline extension: Sat Feb 27
by Didier Verna 20 Feb '16

20 Feb '16

ELS'16 - 9th European Lisp Symposium Department of Computer Science AGH University of Science and Technology Kraków, Poland May 9-10, 2016 In cooperation with: ACM SIGPLAN Sponsored by EPITA, Franz Inc., LispWorks Ltd., IdEx and Dept. of Computer Science AGH UST http://www.european-lisp-symposium.org/ Recent news: - *** Submission deadline extended to Saturday Feb 27 *** The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 9th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. The conference proceedings will be published in the ACM Digital Library. Important dates: - *** EXTENDED *** 27 Feb 2016 Submission deadline *** EXTENDED *** - 25 Mar 2016 Notification of acceptance - 15 Apr 2016 Early registration deadline - 22 Apr 2016 Final papers due - 9-10 May 2016 Symposium Programme chair: Irène Durand, LaBRI, University of Bordeaux, France Local chair: Michał Psota, Emergent Network Defense, Kraków, Poland Programme committee: Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade de Lisboa, Portugal Charlotte Heerzel — IMEC, Leuven, Belgium Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Christophe Rhodes — Goldsmiths, University of London, United Kingdom Didier Verna — EPITA Research and Development Laboratory, France Erick Gallesio — University of Nice-Sophia Antipolis, France François-René Rideau, Google, USA Giuseppe Attardi — University of Pisa, Italy Henry Lieberman — MIT, USA Kent Pitman, HyperMeta Inc., USA Leonie Dreschler-Fischer — University of Hamburg, Germany Pascal Costanza — Intel Corporation, Belgium Robert Strandh — University of Bordeaux, France Search Keywords: #els2016, ELS 2016, ELS '16, European Lisp Symposium 2016, European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium, European Lisp Conference 2016, European Lisp Conference '16 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Debugging ANSI tests
by Alessio Stalla 07 Feb '16

07 Feb '16

Hi list, in my local copy of ABCL I broke some ANSI tests related to packages and that's not good. I'm lazy so I'm asking here: does someone have a ready recipe to debug the ANSI tests, in particular to place breakpoints inside ABCL's Java code while it is executing the tests? In the minute or so I spent thinking about it before getting lazy, I couldn't figure out how to pass the jdwp incantation to the JVM launched by Ant when testing. Thanks is advance! Alessio

2 2

Load abcl
by Hernan Ezequiel Di Giorgi 31 Jan '16

31 Jan '16

The result of cl:compile, how can be loaded via java using .getResourceAsStream()? I'm compiling all the dependencies of a proyect and generating a super abcl.jar with my project inside, in the root directory of the abcl.jar i have a "system.abcl", that can be loaded with cl:load only with it outside the jar. If i try to load if from the jar with the full path "jar:file:/path/abcl.jar!/system.abcl" the repl simply freezes, and do nothing (via java or repl). The org.armedbear.lisp.load.load() throws an exception because don't load the .abcl. The abcl is generated with (asdf:operate 'asdf:monolithic-compile-boundle-op system-name). I just can't use the .abcl when is inside the jar. Any ideas??

1 1

[CfP] 9th European Lisp Symposium, May 9-10, Krakow, Poland
by Didier Verna 21 Jan '16

21 Jan '16

ELS'16 - 9th European Lisp Symposium Department of Computer Science AGH University of Science and Technology Kraków, Poland May 9-10, 2016 In cooperation with: ACM SIGPLAN Sponsored by EPITA, Franz Inc., LispWorks Ltd. and Dept. of Computer Science AGH UST http://www.european-lisp-symposium.org/ Recent news: - Submission deadline in less than a month! - 3nd invited speaker announced: Stephan Karpinski on Julia: to Lisp or Not to Lisp? The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 9th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. The conference proceedings will be published in the ACM Digital Library. Important dates: - 19 Feb 2016 Submission deadline - 25 Mar 2016 Notification of acceptance - 15 Apr 2016 Early registration deadline - 22 Apr 2016 Final papers due - 9-10 May 2016 Symposium Programme chair: Irène Durand, LaBRI, University of Bordeaux, France Local chair: Michał Psota, Emergent Network Defense, Kraków, Poland Programme committee: Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade de Lisboa, Portugal Charlotte Heerzel — IMEC, Leuven, Belgium Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Christophe Rhodes — Goldsmiths, University of London, United Kingdom Didier Verna — EPITA Research and Development Laboratory, France Erick Gallesio — University of Nice-Sophia Antipolis, France François-René Rideau, Google, USA Giuseppe Attardi — University of Pisa, Italy Henry Lieberman — MIT, USA Kent Pitman, HyperMeta Inc., USA Leonie Dreschler-Fischer — University of Hamburg, Germany Pascal Costanza — Intel Corporation, Belgium Robert Strandh — University of Bordeaux, France Search Keywords: #els2016, ELS 2016, ELS '16, European Lisp Symposium 2016, European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium, European Lisp Conference 2016, European Lisp Conference '16 -- @-quartet live: Sunset/Sunside, Paris, Jan 26 2016 ! Book now: http://www.sunset-sunside.com/2016/1/artiste/2101/3453/ Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Loops and interruptibility
by Scott L. Burson 31 Dec '15

31 Dec '15

Hi all, The other day I had an inadvertent infinite loop in my code, running in ABCL, and found I was unable to interrupt it with double C-c in SLIME. In fact, even when I killed the process, restarted it, and started the code with the infinite loop in a new thread, I couldn't kill the thread! Is this a known problem, or is something wrong with my setup? -- Scott

2 1

Problems with static methods (and interface implementation?), java.lang.NoClassDefFoundError.
by fsmunoz＠gmail.com 28 Dec '15

28 Dec '15

Hello, I have been struggling with this for some hours now and would welcome some pointers. I'm writing a small how-to on how to deploy Common Lisp web applications (i.e. "something that replies to an HTTP request") in IBM's Bluemix using ABCL. That part is taken care of and I have it up and running (more on that in a separate post). I was going for a more advanced version and I am having a problem with interface implementation. To showcase java interop I am not using CL web frameworks, but decided to give Spark a try (http://sparkjava.com/documentation.html) just to get a minimal example up and running (I already have Jetty working and serving up an "(Hello World)" page): #+BEGIN_SRC java import static spark.Spark.*; public class HelloWorld { public static void main(String[] args) { get("/hello", (req, res) -> "Hello World"); } } #+END_SRC I'm going to start with the Clojure example since that one I got working; the API reference (http://spark.screenisland.com/spark/Spark.html) helped me and this works #+BEGIN_SRC clojure => (Spark/get "/hello" (reify spark.Route (handle [this req res] ("Hello World")))) [Thread-34] INFO spark.webserver.JettySparkServer - == Spark has ignited ... [Thread-34] INFO spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:4567 nil[Thread-34] INFO org.eclipse.jetty.server.Server - jetty-9.3.2.v20150730 #+END_SRC I have learned (thanks to bpalmer in #emacs, cheers!) that the Single Abstract Method can be constructed using Java 8 lambda expressions, which is why I couldn't find a reference to the "handle" method, which I got from the API. Now, back to ABCL; I'm unable to reproduce the above and I'm unsure if it is because I'm not getting something right (likely) or because some of the plumbing in ABCL isn't quite there yet. I tried this using jss::jinterface-implementation (which I had used previously with my MQTT code and worked perfectly): #+BEGIN_SRC lisp (#"get" 'spark.Spark "/hello" (jss::jinterface-implementation "spark.Route" "handle" (lambda (request response) ("Hello World")))) #+END_SRC The (jinterface-implementation ...) returns #<com.sun.proxy.$Proxy5 com.sun.proxy.$Proxy5@4f0bbf2a {41CC48BB}>, but the (#"get"...) fails: Java exception 'java.lang.NoClassDefFoundError: Could not initialize class spark.Spark$SingletonHolder'. I have also tried with jmake-proxy to see if there was something different going on. #+BEGIN_SRC lisp (java::jstatic "get" "spark.Spark" "/hello" (java::jmake-proxy "spark.Route" #'(lambda (lisp-this method request response) ("Hello World")))) #+END_SRC The result is the same, both in what jmake-proxy returns and the final error. Note that I have added the jar to the classpath, otherwise I would get "ClassNotFound". Even more simply this also doesn't work: #+BEGIN_SRC clojure => (Spark/stop) [nREPL-worker-11] INFO spark.webserver.JettySparkServer - >>> Spark shutting down ... #+END_SRC ... (#"stop" 'spark.Spark) returns the same "NoClassDefFoundError", which makes me thing the issue is not with the jproxy bit but something more fundamental... With this in mind: 1) Is there anything obviously wrong about the way I'm going about it - not limited to implementation errors on my part but including trying to use parts of ABCL's Java interop which aren't done? 2) The java::jmake-proxy call... I wasn't able to find a single example of it used (the only code I find when searching is the implementation itself) so I'm not sure I'm understanding the documentation correctly: are the arguments I'm using above correct? I'm using the method that uses a function and if I understood it correctly the first argument is "lisp-this" (which defaults to nil), the second the method name (which would be "handle" in this example, and the rest are the method arguments (request and response here). I am of course available for any further clarification, and if this is something that isn't obvious I can upload a minimal example using quickproject and quicklisp. Best regards, -- Frederico Muñoz fsmunoz(a)gmail.com

1 0

destructuring-bind not signaling error with &rest
by 2l8qyo+d734u52o8x7j0＠guerrillamail.com 22 Dec '15

22 Dec '15

(destructuring-bind (a b &rest c) '(1) b) => nil with no error. sbcl, clisp, and ecl signal an error. http://clhs.lisp.se/Body/m_destru.htm seems to suggest it should be an error. version is abcl 1.3.3 on jdk 1.8.0_66 ---- Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=QFN5AAkCRrUHxQqx5nsTUhfIQMef3JpczrdS…

1 0

ASDF configuration for "JAR-only" system
by John Pallister 16 Dec '15

16 Dec '15

Hello list, I'm trying to configure ASDF to load my application while running within the Google App Engine development server (Jetty 6.1). My Ant build script uses ASDF-JAR:PACKAGE to produce a single JAR file containing my application and all dependencies, and copies this to the war/WEB-INF/lib/ directory so that it's in the classpath. At runtime (in a separate bootstrap.lisp file), following the example of ASDF-JAR:ADD-TO-ASDF[1], I search the application JAR file (obtained by grovelling JAVA:DUMP-CLASSPATH) for the .ASD files and push them all onto ASDF:*CENTRAL-REGISTRY*. So far so good. (Having read the ASDF manual I now know I should either build a .cl-source-registry.cache file into the JAR or compute an ASDF source registry configuration and include that.) When ASDF starts up it tries to read various configuration files from the filesystem, for both the source registry and for its output translations. This isn't allowed by App Engine. On #lisp, Attila Lendvai suggested that giving ASDF a source registry configuration of '(:SOURCE-REGISTRY :IGNORE-INHERITED-CONFIGURATION) should suppress this behaviour, and it does seem to work. Now I'm struggling to get the output translations to work. Based on ADD-TO-ASDF again I'm using an output translations configuration of: `(:output-translations (,(merge-pathnames "/**/*.*" *application-jar-path*)) ; => #P"/**/*.*" :ignore-inherited-configuration :disable-cache) My *APPLICATION-JAR-PATH* is #P"jar:file:/Volumes/SoftRAID/Users/john/src/synchromesh/forumfeedme/war/WEB-INF/lib/forumfeedme-lisp-0.1.0.jar!/", i.e. a pathname with the JAR path as the PATHNAME-DEVICE. With this I get the error "access denied ("java.io.FilePermission" "/___jar___file___root___" "read")". This matches the default translations seen in asdf.lisp:WRAPPING-OUTPUT-TRANSLATIONS: (defun wrapping-output-translations () `(:output-translations ;; Some implementations have precompiled ASDF systems, ;; so we must disable translations for implementation paths. #+(or #|clozure|# ecl mkcl sbcl) ,@(let ((h (resolve-symlinks* (lisp-implementation-directory)))) (when h `(((,h ,*wild-path*) ())))) #+mkcl (,(translate-logical-pathname "CONTRIB:") ()) ;; All-import, here is where we want user stuff to be: :inherit-configuration ;; These are for convenience, and can be overridden by the user: #+abcl (#p"/___jar___file___root___/**/*.*" (:user-cache #p"**/*.*")) #+abcl (#p"jar:file:/**/*.jar!/**/*.*" (:function translate-jar-pathname)) ;; We enable the user cache by default, and here is the place we do: :enable-user-cache)) Although I don't understand exactly how the "JAR file as device" (JFAD) translations are supposed to work, one thing that struck me as odd while investigating things was this: CL-USER> (make-pathname :device (list #P"/foo.jar")) #P"jar:file:/foo.jar!/" CL-USER> (merge-pathnames "**/*.*" *) #P"jar:file:/foo.jar!/**/*.*" CL-USER> (merge-pathnames "/**/*.*" **) #P"/**/*.*" CL-USER> (pathname-directory **) (:RELATIVE :WILD-INFERIORS) CL-USER> (pathname-directory **) (:ABSOLUTE :WILD-INFERIORS) That is, merging a relative path with the (absolute) JFAD path retained the default JAR file "device" (and remains a relative path, which ASDF won't accept), but merging an absolute path reset the device component. I've read through the documentation for MERGE-PATHNAMES in the HyperSpec[2] and AFAICT the device component should be copied across. I'm reasonably confident that if it were, things would work better. But I could be (doubly) wrong. I am trying to figure this out for myself, but I'm stuck for now, so I'm hoping someone (i.e. Mark) can, on reading this, offer some guidance as to where I should go from here. I haven't (yet) tried posting to the ASDF mailing list as this seems like a fairly ABCL-specific issue. I guess the fallback is to unpack the application JAR and just load the FASLs directly, but (based again on ADD-TO-ASDF) I'm pretty sure that this should work, and it does seem to be the Right Thing. Any or all comments and/or advice appreciated, Cheers, John :^P [1] http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/asdf-jar.lisp [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_merge_.htm#merge-pa… -- John Pallister john(a)johnp.net john(a)synchromesh.com

2 3

Package-local nicknames
by Alessio Stalla 09 Dec '15

09 Dec '15

Hello list, long time no see :) I'm once again experimenting on ABCL with a sort of a pet peeve of mine: hierarchical symbols (aka symbols as packages aka symbol/package conflation). If I get good results I'll submit an article to the next ELS. Btw, is anyone going? I've seen that, since the time when I was actively contributing to it, ABCL has gained package-local nicknames (or, they were already there and I never noticed or I forgot about them). Since my experiment is, I suppose, a superset of what said nicknames have to offer, I'm curious: is anybody using them? How? Are they a novel idea of ABCL's, or were they inspired by other implementations? Do they implement some specification (e.g., a CDR)? Thanks for any input! Cheers Alessio

5 7

ABCL-JAR issues & patch
by John Pallister 24 Nov '15

24 Nov '15

Hello list, I've been trying to use ABCL-JAR to package up my app for deployment to Google App Engine. I've come across a few issues; any comments would be appreciated. I've attached a patch to the ABCL-JAR:PACKAGE function that Works For Me(TM). For the original code, see http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/asdf-jar.lisp?rev=… First, there was an issue where if the ROOT parameter is NIL the function would fail at line 90. Second, The SYSTEM:ZIP function didn't want to nest JARs within the new JAR, so systems that depended on e.g. JSS via abcl-contrib.jar would fail. I filter out files in JARs on the assumption that one will just distribute those JARs along with the new one. Third, my ASDF file includes a system that looks like: (asdf:defsystem #:gabacle-clack-java :defsystem-depends-on (#:abcl-asdf) :version "0.1" :description "Java interface classes for Gabacle/Clack." :depends-on () :components ((:module java-src :pathname "src/" :components ((:class-file-directory "java"))))) This may or may not be good style, but it seems to be legal. When traversing the ASDF files, the class file directory component comes back with a PATHNAME-TYPE of :UNSPECIFIC, so I filter such entries out so that SYSTEM:ZIP doesn't object. On a minor note, at http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/zip.java?rev… "incorporation" is spelled "incoporation". I hope this is useful. If people could point out where I've just got the wrong end of the stick, that would be great... Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

1 1

Creating a Lisp stream from a java.io.Reader
by John Pallister 24 Nov '15

24 Nov '15

Hello list, I'm trying to get Clack (http://clacklisp.org/) running on Google App Engine which means doing a Java Servlets back-end. Clack expects a :RAW-BODY request header that is an input stream, and the HTTPServletRequest object I receive from the Jetty web server inherits a getReader() method (for a character stream) and a getInputStream() method (for a binary stream). Looking at the "reference implementation" (i.e. Hunchentoot), it creates a FLEXI-STREAM so that any HTTP "Content-Length" header can be used to set the bound on the stream. So based on that, and an IRC chat with Mark E., and some scratch code, I've come up with this to create a FLEXI-STREAM from the HTTPServletRequest: (defconstant +latin-1+ (make-external-format :latin1 :eol-style :lf) "A FLEXI-STREAMS external format used for `faithful' input and output of binary data (via hunchentoot/specials.lisp).") (defun make-stream-for-request (req content-length) "Construct a Lisp input flexi-stream from the binary stream provided by the HTTPServletRequest. Set the bound of the stream to the value of the Content-Length header, if any." (let* ((java-stream (#"getInputStream" req)) (lisp-stream (jss:new :|lisp.Stream| (jss:get-java-field :|lisp.Symbol| "SYSTEM_STREAM") ; structureClass java-stream '(unsigned-byte 8)))) ; elementType (make-flexi-stream lisp-stream :external-format +latin-1+ :bound content-length))) We agreed that there's not much documentation around this, hence this email. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

4 6

Reports of problems in binding/connecting to localhost for testing http servers (clack, hunchentoot)
by Mark Evenson 21 Nov '15

21 Nov '15

[Something in the USOCKET code seems to have problems interpreting ip6 addresses with ABCL…][40]. [40]: http://abcl.org/trac/ticket/40 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

Encode/decode-universal-time and DST
by Scott L. Burson 09 Nov '15

09 Nov '15

Hi, As daylight-saving time ended in the US today, I discovered that ABCL's interpretation of the CL spec concerning the behavior of 'encode/decode-universal-time' around DST is not the usual one. The usual interpretation is that when an explicit timezone is not supplied to these calls, DST is selected automatically based on whether it would have been in force (under certain assumptions, e.g., you're not in Arizona) at the time being converted. ABCL's behavior is to convert the time based on whether DST is in force at the time of the call. I think it's pretty clear that the former interpretation was the intended one, even if the language of the spec is admittedly not as clear as it should have been. SBCL does it that way, CCL does it that way, and I even dug out the Genera 7.2 sources, which I still have lying around, to confirm that it did it that way too. It looks like the ABCL interpretation was more-or-less intentional since a comment in the code says "adapted from SBCL". Do the ABCL developers feel strongly that this is the correct behavior? -- Scott

3 11

JEP 276: Dynamic Linking of Language-Defined Object Models
by Mark Evenson 24 Oct '15

24 Oct '15

Not sure exactly how this maps to Common Lisp, but it looks like JDK 9 will have a lot of interesting new APIs for compiling efficient code for langauges other than Lisp. The latest I have found out about is [JEP 276: Dynamic Linking of Language-Defined Object Models][1]. [1]: http://openjdk.java.net/jeps/276 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Maven plugin for compiling to bytecode?
by Andrew Pennebaker 21 Oct '15

21 Oct '15

Could there be a Maven plugin that compiles src/main/lisp/**/*.lisp to .class files for integration in Java projects? -- Cheers, Andrew

2 1

ASDF 3.1.6 is released
by Robert Goldman 18 Oct '15

18 Oct '15

We would like to announce the release of ASDF 3.1.6, the latest bug fix release for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups, explanations, etc. Thanks are also owed to Dave Cooper, for testing on the Windows platform, enabling the maintainers to test on Windows, and identifying uncaught bugs. Thanks to Anton Vodonosov for testing the release candidate against Quicklisp on cl-test-grid. Finally, thanks to all who found bugs, provided patches, and used prerelease candidates. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.1.6. 3.1.6 does not introduce any API incompatibilities that we know of, and contains significant bug fixes on multiple platforms and implementations. See the Changelog (below) for a list of the major bug fixes. Details on minor bugfixes can be found at launchpad.net/asdf We had hoped that 3.1.5 would be the last 3.1.x bug fix release, paving the way for us to move to developing ASDF 3.2, which we expect will add new features. Maybe this time! Here is the changelog entry for 3.1.6: Bug fix and portability release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. -- Robert P. Goldman <rpgoldman(a)sift.net> Sat, 17 Oct 2015 15:01:34 -0500

1 0

[CfP] European Lisp Symposium 2016, May 9-10, Kraków, Poland
by Didier Verna 07 Oct '15

07 Oct '15

ELS'16 - 9th European Lisp Symposium AGH University of Science and Technology Kraków, Poland May 9-10, 2016 http://www.european-lisp-symposium.org/ Sponsored by EPITA and AGH University The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 9th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 19 Feb 2016 Submission deadline - 25 Mar 2016 Notification of acceptance - 15 Apr 2016 Early registration deadline - 22 Apr 2016 Final papers due - 9-10 May 2016 Symposium Programme chair: Irène Durand, University of Bordeaux, France Local chair: Michał Psota, Emergent Network Defense, Kraków, Poland Programme committee: Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade de Lisboa, Portugal Charlotte Heerzel — IMEC, Leuven, Belgium Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Christophe Rhodes — Goldsmiths, University of London, United Kingdom Didier Verna — EPITA Research and Development Laboratory, France Erick Gallesio — University of Nice-Sophia Antipolis, France Francois-René Rideau, Google, USA Giuseppe Attardi — University of Pisa, Italy Henry Lieberman — MIT, USA Kent Pitman, HyperMeta Inc., U.S.A. Leonie Dreschler-Fischer — University of Hamburg, Germany Pascal Costanza — Intel Corporation, Belgium Robert Strandh — University of Bordeaux, France Search Keywords: #els2016, ELS 2016, ELS '16, European Lisp Symposium 2016, European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium, European Lisp Conference 2016, European Lisp Conference '16 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Unable to quickload Drakma + CL+SSL on ABCL 1.3.2 - (Failed to read artifact descriptor for net.java.dev.jna:jna)
by Paul Nathan 27 Sep '15

27 Sep '15

Hello, I just downloaded ABCL 1.3.2 for OSX (curl -L -O http://abcl.org/releases/1.3.2/abcl-bin-1.3.2.tar.gz) and tried to load a few things in. Drakma & CL+SSL failed to load for me. I have copied the tracebacks to the end of the email. Please advise: is this my own error or something with ABCL? Is there more information you would like? Regards, Paul CL-USER(3): (ql:quickload :cl+ssl) To load "cl+ssl": Load 1 ASDF system: cl+ssl ; Loading "cl+ssl" .......... Using probed value of abcl-contrib: '/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar'. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/abcl-asdf/ to ASDF. ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {10EDE4B7}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "cl+ssl" 7: TOP-LEVEL Return to top level. CL-USER(4): (ql:quickload :drakma) To load "drakma": Load 1 ASDF system: drakma ; Loading "drakma" ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {A19A2B4}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "drakma" 7: TOP-LEVEL Return to top level. [1] CL-USER(5): 6

3 6

Pointing out ABCL "extensions" to ANSI-TEST
by Mark Evenson 15 Sep '15

15 Sep '15

Congratulations on getting the divergent ANSI-TEST suite codebases back together in one place, as well as establishing this mailing list. As a Common Lisp implementer who only really started studying the language a decade ago, I have profited immeasurably from figuring out why ABCL fails a given ANSI-TEST while other implementations don't. I would like to point out a few "extensions" to the ANSI-TEST suite that ABCL has added over the years so that other implementations might profit from them and/or that some of the ideas might be included in the ANSI-TEST suite itself. Upon reviewing the implementation of these ideas, parts of me cringe at how my younger self implemented things so I wouldn't necessarily recommend adoption of our code wholesale. 1) ASDF By the nature of how ANSI-TEST loads and runs itself, encapsulation as a "true" ASDF system (i.e. one where all the source is declared) seems a little farfetched. And maybe it is useful to be able to run the suite in places where ASDF is not available, such as when bootstrapping a new implementation. Nevertheless, we put some work into encapsulating the ANSI-SUITE into ASDF to the point that it can be loaded and the tests run that might be of interest. [ABCL defines three ASDF systems][1], namely ANSI-RT, ANSI-COMPILED, and ANSI-INTERPRETED. ANSI-RT encapsulates the regression test framework, while ANSI-COMPILED and ANSI-INTERPETED provide definitions to the point that ASDF:TEST-SYSTEM can run the compiled or interpreted tests respectively. This helps with automation of the tests in ABCL's build mechanism. The one caveat is that one cannot run tests in "parallel" on, say, different versions of your implementation that you are regression testing due to the way that ANSI-TEST uses the filesystem of the ANSI-TEST itself to keep fasls and record state for tests in the course of running the suite. [1]: http://abcl.org/trac/browser/trunk/abcl/abcl.asd#L76 2) ABCL.TEST.ANSI In order to support the necessary shenanigans to make the ANSI-COMPILED and ANSI-INTERPRETED definitions work, we [created a small set of utility routines][2]. CLEAN-TESTS performs the removal of intermediate files that the old Makefile used to do. DO-TESTS-MATCHING will run only those tests whose symbols match a regular expression, which is useful for repeatedly running a subset of tests. [2] http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/abcl-ansi.lisp 3) ANSI-TEST error "database" We [created a simple s-expr "database"][4] for recording test failures and then [reporting on the results][3]. ABCL is a unique CL implementation because it is hosted on a JVM for which there are multiple implementations and whose behavior often varies by operating system so running the ANSI-TEST suite has proven to be fairly sensitive to hosting JVM implementation version and operating system. Thus, such a database of regressions has proven to be of special importance to ABCL. That being said, my implementation of this idea is pretty amateurish in hindsight, so I think what is important here is the idea rather than the implementation. [3]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/parse-ansi-errors.li… [4]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/ansi-test-failures -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

Typo in last commit on svn
by Stefan Husmann 10 Sep '15

10 Sep '15

Hello, I think there is a typo, or, say, copy-and-paste error in the last commit on svn. abcl does not build the way it is. This is my correction. +++ a/trunk/abcl/build.xml +++ b/trunk/abcl/build.xml @@ -877,5 +877,5 @@ ${basedir}/../ansi-tests. -[1]: <git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git> +[1]: git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git The CL-BENCH tests require that [cl-bench][2] be manually installed in Best Regards Stefan Husmann PS: I am new on this list, so I apologize if thi has been brought up before.

2 1

Can't muffle COMPILE
by James M. Lawrence 08 Sep '15

08 Sep '15

(handler-bind ((warning #'muffle-warning)) (compile nil '(lambda () x))) => ; Caught STYLE-WARNING: ; Undefined variable X assumed special ; Compilation unit finished ; Caught 1 STYLE-WARNING condition Also, you might want that to be more than a style-warning; it's a full warning in other implementations. Best, lmj

2 1

Compiler can generate code it cannot load....
by Patrick Stein 02 Sep '15

02 Sep '15

This is a short program for which the compiler creates a file it cannot load. Save this program to a file, then try: (load (compile-file “this-file.lisp”)) ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) As noted in the comment, it is very finicky. There are at least four ways this code could be slightly less-specific and then not trigger the bug. I tried it both with ABCL-1.3.1 and ABCL-1.3.2. The logs of the output are below. I’d love to be able to say that I’m looking at the compiler now to try to figure out where it’s going wrong, but realistically, I’m not going to have time to delve into it myself, I’ve never really looked at the ABCL compiler before, and I suspect the problem is in the compiling but doesn’t show up until the loading… so it won’t be as easy as exploring the stack when the error shows up. Thanks, Patrick Script started on Tue Sep 1 16:33:56 2015 bash-3.2$ cat compile-problem.lisp ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-1.3.2 abcl Armed Bear Common Lisp 1.3.2 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.524 seconds. Startup completed in 2.65 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.208 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {33E81276}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@2acec9eb Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-bin-1.3.1 abcl Armed Bear Common Lisp 1.3.1 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.471 seconds. Startup completed in 2.651 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.199 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {3F8D7E88}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@28015d1d Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ccl --no-init Welcome to Clozure Common Lisp Version 1.11-dev-r16393-trunk (DarwinX8664)! CCL is developed and maintained by Clozure Associates. For more information about CCL visit http://ccl.clozure.com. To enquire about Clozure's Common Lisp consulting services e-mail info(a)clozure.com or visit http://www.clozure.com. ? (load (compile-file "compile-problem.lisp")) #P"/Users/pat/compile-problem.dx64fsl" ? (quit) bash-3.2$ sbcl --no-init This is SBCL 1.2.3.13-3446e1a-dirty, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load (compile-file "compile-problem.lisp")) ; compiling file "/Users/pat/compile-problem.lisp" (written 01 SEP 2015 04:33:38 PM): ; compiling (DEFTYPE BUFSIZE ...) ; compiling (DECLAIM (INLINE BUFFER-LENGTH) ...) ; compiling (DEFUN BUFFER-LENGTH ...) ; compiling (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; /Users/pat/compile-problem.fasl written ; compilation finished in 0:00:00.007 T * (quit) bash-3.2$ exit Script done on Tue Sep 1 16:36:21 2015

2 2

Better integration between ABCL & Java
by Blake McBride 30 Aug '15

30 Aug '15

Greetings, I worked hard on a project to link ABCL with a very large Java application. Although the addition of ABCL to that project failed, the work I did could be of use, and with some effort could be made to solve the problem I had. I believe the original problem I had would be a very common problem in similar circumstances. My pre-existing Java application has almost 10,000 classes! I wasn't about to create lisp cover functions for each java method. I also wasn't going to use a convoluted syntax to get to java each time. What I did was create some Java and Lisp code that, through reflection, caused the system to auto-generate a complete set of CLOS classes to mirror my primary java application classes - including the class hierarchy. The methods in these CLOS classes would call the Java methods. With this, when in Lisp, I could just use all of my Java classes and methods as regular CLOS classes and methods. It's use of Java classes and methods internally was transparent to lisp. All of this worked fine. The problem I ran into was the fact that Java can have several methods with the same name but different arguments. So, the Java method being called depended on the types and number of arguments too (not just the class of the instance and the method name). I never solved this, although I think it could be. I just ran out of time and steam, as well as other non-technical reasons. The reason I bring this all up now is because I am unclear about what problems Ralph is trying to solve. I thought what I have done may be of use. Thanks. Blake McBride

5 5

All conformance ansi-test's passed
by Ralph Ritoch 27 Aug '15

27 Aug '15

Hello, I have been able to get ABCL to pass all of the ansi conformance tests. While this is not an official ABCL release, all of the modifications I made are released under the MIT license and may be freely integrated into ABCL at the discretion of the maintainers. To embed this conforming version into your java applications add the following dependencies which have been released at maven central. <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-impl</artifactId> <version>0.0.2</version> </dependency> <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-contrib</artifactId> <version>0.0.2</version> </dependency> The source code for this release can be found at https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a… . While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases. Moving forward it is likely that any future development on these branches will further deviate from ABCL. I am not claiming that this solves EVERY compliance issue but I have found solutions for each of the ansi conformance test failures. Any remaining compliance issues can be considered a bug. My primary intention of passing every test is to lock the build process so that builds will fail if any of the ansi tests fail. It is unlikely that future modifications to these forks will have any relevance to ABCL. I will likely continue developing features that are needed for modern application development and therefore are of little interest to some, if not all, of the ABCL maintainers. That being said, v0.0.2 is the best release to source conformance solutions from for ABCL as it passes every conformance test. Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development. Best Regards, Ralph Ritoch

5 7

loading lisp files from inside the java jar
by Hamda Binte Ajmal 18 Aug '15

18 Aug '15

Hi, I am sending this message again, as the last thread went a little too far. I have developed a Java Application that runs lisp code at the back end, and I use ABCL for that. Before using the lisp commands, I load a few .lisp files so that I can call the functions defined in those files. Everything works fine as long as I run the application from Netbeans. When I run the application from the jar file, it throws 'File not found error'. as the lisp files are not a part of file system inside the project jar. I tried to follow the suggestions given by Mark (load “jar:file:/absolute/path/to/file.jar!/path/within/jar/setup.lisp”) It shows the same File not found error. Am i missing something here? As suggested by Ralph to use (load-system-file "path/to/resource.lisp"), I tried to use that, but I was unable to access sys package, please let me know how to do this. I find the help documentation and tutorials very confusing, and difficult to understand. Any hints will be appreciated. Thanking in anticipation. Regards, Hamda NUIG, Ireland.

5 13

Re: Lisp filepath issues when running application directly from jar file
by Ralph Ritoch 17 Aug '15

17 Aug '15

This "idiot" refactored a very small portion of your code making it MUCH faster, and also passed more than 90% of the tests ABCL is currently failing, leaving only 3 ansi-tests that are still failing. If I'm an idiot it doesn't say much about you since you've been working on this for years and I've only been working on it for weeks. Best Regards, Ralph Ritoch On Mon, Aug 17, 2015 at 8:00 PM, <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/armedbear-devel > or, via email, send a message with subject or body 'help' to > armedbear-devel-request(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of armedbear-devel digest..." > > > Today's Topics: > > 1. Re: Lisp filepath issues when running application directly > from jar file (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Aug 2015 14:38:44 +0200 > From: Mark Evenson <evenson(a)panix.com> > To: Armed Bear <armedbear-devel(a)common-lisp.net> > Subject: Re: Lisp filepath issues when running application directly > from jar file > Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051(a)panix.com> > Content-Type: text/plain; charset="utf-8" > > > > On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch(a)gmail.com> wrote: > > > > I have used this function in my code without ANY problems. [?] > > The SYSTEM package is not intended to be used by users unless there is no > alternative. The manual states clearly that functionality provided by > SYSTEM > is subject to be changed between major releases without warning. > Therefore, > the argument in this case isn?t that one would have problems using > SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface > as > implemented CL:LOAD which should be able to load Lisp and/or fasls in all > cases > needed by the user. My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was > motivated by precisely the need for CL:LOAD to work in all conceivable > cases in > the JVM ecology. And the best contemporary mechanism for expression for > resolution of and dependency order for CL:LOAD lies in ASDF, hence my > emphasis on using its abstraction where extending CL:LOAD is not desirable. > > As a side note, over time, we wish to move functions in SYSTEM which > useful to > the user into the EXTENSION package, but this work is incomplete at best. > Currently, there are indeed cases in which using a function from SYSTEM is > unavoidable. The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them. > > > Your attitude regarding "progress" is archaic. If you don't want to > support maven or other java technologies why do you even bother controlling > abcl? > > > Your attitude towards discussion is not only archaic (i.e. immature) but > counterproductive towards reaching the sort of consensus needed for > progress. > > However misguided such an endeavor may be, a couple points follow towards a > defense from your sleazy ad hominem ?argumentation?. > > As for supporting Maven, I have developed the machinery to use Maven > artifacts > in ABCL-ASDF, and continued to maintain them (with help from users) even > as the > lurching horror that comprises Maven release engineering continues to > change > API semantics between patch level releases. I have offered to collaborate > with you on incorporating your initial work on building from Maven, > pointing > out the problems that I see with your approach to which I have received no > reply. > > As for supporting ?other technologies?, I suppose you are referring to your > attempt to merge abcl-contrib.jar and abcl.jar. In this effort, I pointed > out > you could do this cleanly with the current code by adding site-specific > code to > the ?system.lisp? file whose contents are controlled by the Ant build > process. > Since your Maven build doesn?t use the Ant target to package (one of my > explicit criticisms), you presumedly weren?t interested in using this > mechanism. I responded twice to your proposal to probe jar files on the > classpath for code to pontential load with suggestions which you found too > burdensome to discuss so you developed what you needed. Your email > announcing > this implementation implied you had implemented to a ?specification?, but > no > such entity existed external to the source code. If you wish to provide > such a > specification for your current implementation, please do so that others may > consider its usefulness. > > As to whether I control ABCL, I was going to reply that I am but one > maintainer > out of five; that you are welcome to convince a majority of the maintainers > through useful and accepted contributions that that you should be in > ?control? > too; and that since the code is GPL?d so you are welcome to get the fork > out of > here. But at this point, I would reply that if I do somehow ?control? > ABCL, I > am glad to protect it from idiots like you. > > -- > "A screaming comes across the sky. It has happened before but there is > nothing > to compare to it now." > > > > > >

5 7

Lisp filepath issues when running application directly from jar file
by Hamda Binte Ajmal 17 Aug '15

17 Aug '15

Hi, I was working on an application, that loads a few lisp files using lisp command (load "fullfilepath.lisp") from java using ABCL. This file in turn loads the other lisp files located in same folder hierarchy, and then i call lisp functions (defined in these files) from java and everything works perfect as long as I run the application from Netbeans. Close to deployment, I tested the application by running it from jar file, I found that there are issues with filepaths, as the files are not a part of file-system, and hence not accessible using a file-path. Does anyone has any idea how to fix this issue ? I tried many things, like URL url = LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String path = url.getFile();File f = new File(path); path = f.getAbsolutePath(); path = path.replace("\\", "/"); which returns [image: enter image description here] But which is wrong as this is not a valid file path and does not exists so lisp : (load "filepath") fails here. When I use the code String path = url.toURI();File = new File(path); path = path.getAbsolutePath(); Again it works fine while running from netbeans, but shows error "URI is not hierarchical" error while running the jar file. Has anyone encountered this issue, please help. -- Hamda Binte Ajmal NUIG, Ireland

2 2

Re: Lisp filepath issues when running application directly from jar file
by Ralph Ritoch 16 Aug '15

16 Aug '15

Hello, Since you are loading resources and not from the filesystem you probably want to utilize the load-system-file function which I believe is provided by the :sys package. I'm not sure how portable this is so you may want to add some additional control logic if you want portability. (load-system-file "path/to/resource.lisp") Best Regards, Ralph Ritoch On Fri, Aug 14, 2015 at 8:00 PM, <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/armedbear-devel > or, via email, send a message with subject or body 'help' to > armedbear-devel-request(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of armedbear-devel digest..." > > > Today's Topics: > > 1. Lisp filepath issues when running application directly from > jar file (Hamda Binte Ajmal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Aug 2015 11:20:18 +0100 > From: Hamda Binte Ajmal <hamda.binte.ajmal(a)gmail.com> > To: armedbear-devel(a)common-lisp.net > Subject: Lisp filepath issues when running application directly from > jar file > Message-ID: > <CAJEb= > LPJuCP6FJoTxuCGaapbo4FHdjnWdEf_QumgMJF-9BhHXQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > I was working on an application, that loads a few lisp files using lisp > command > (load "fullfilepath.lisp") from java using ABCL. > This file in turn loads the other lisp files located in same folder > hierarchy, and then i call lisp functions (defined in these files) from > java and everything works perfect as long as I run the application from > Netbeans. > Close to deployment, I tested the application by running it from jar file, > I found that there are issues with filepaths, as the files are not a part > of file-system, and hence not accessible using a file-path. > Does anyone has any idea how to fix this issue ? > I tried many things, like > > URL url = > LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String > path = url.getFile();File f = new File(path); > path = f.getAbsolutePath(); > path = path.replace("\\", "/"); > > which returns [image: enter image description here] > > But which is wrong as this is not a valid file path and does not exists so > lisp : (load "filepath") fails here. > > When I use the code > > String path = url.toURI();File = new File(path); > path = path.getAbsolutePath(); > > Again it works fine while running from netbeans, but shows error "URI is > not hierarchical" error while running the jar file. > > Has anyone encountered this issue, please help. > > > -- > Hamda Binte Ajmal > NUIG, Ireland >

2 3

ABCL on jailbroken iPhone
by Vibhu Mohindra 12 Aug '15

12 Aug '15

My jailbroken iPhone has GNU classpath[0] and jamvm[1] installed. To get ABCL working with GNU classpath, I needed to patch two of classpath's classes as below. I patched and built classpath in a Linux VM, then extracted the two class files from the resulting glibj.zip and inserted them into the iPhone's /usr/share/classpath/glibj.zip . I've reported these modifications to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67188 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67189 the latter of which may be an ABCL problem, not a GNU classpath one. (Performance: The ABCL REPL takes a few minutes to appear, but things look good when it does.) ref: [0] http://www.gnu.org/software/classpath/ [1] http://jamvm.sourceforge.net/ Vibhu diff -Naur classpath-0.99/java/math/BigInteger.java classpath-0.99.abcl/java/math/BigInteger.java --- classpath-0.99/java/math/BigInteger.java 2010-09-02 17:47:07.000000000 +0100 +++ classpath-0.99.abcl/java/math/BigInteger.java 2015-08-11 02:01:18.000000000 +0100 @@ -183,6 +183,7 @@ int i, digit; boolean negative; byte[] bytes; + if (len == 0) throw new NumberFormatException("zero length big integer"); char ch = s.charAt(0); if (ch == '-') { diff -Naur classpath-0.99/java/nio/charset/CharsetEncoder.java classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java --- classpath-0.99/java/nio/charset/CharsetEncoder.java 2010-06-03 20:13:04.000000000 +0100 +++ classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java 2015-08-12 12:16:13.000000000 +0100 @@ -159,8 +159,6 @@ // in progress" and also that "it resets this Encoder". // Should we check to see that the state is reset, or should we // call reset()? - if (state != STATE_RESET) - throw new IllegalStateException (); // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? @@ -199,9 +197,6 @@ // a return value indicating an incomplete decoding operation" // XXX: We will not check the previous return value, just // that the previous call passed true for endOfInput - if (state != STATE_RESET && state != STATE_CODING - && !(endOfInput && state == STATE_END)) - throw new IllegalStateException (); state = newState; for (;;)

1 0

Proposal to improve the loading of the abcl-contrib dependency.
by Ralph Ritoch 03 Aug '15

03 Aug '15

Hi, I have run into an issue with making executable abcl jars when the jar depends on, and provides, abcl-contrib. As far as I can tell abcl looks for abcl-contrib in the following locations. 1. Looks for a jar named abcl-contrib.jar in the classpath determined by probing the classloader for the jars it provides. 2. Looks in the directory of the jars in the classpath for a file named abcl-contrib.jar Neither of these solutions work if the currently executing jar includes abcl-contrib and isn't named abcl-contrib.jar. The following code proves that it is relatively easy to add this capability. (in-package 'sys) (sys:add-contrib (make-pathname :defaults (java:jcall "toString" (svref (java:jcall "getURLs" (sys:boot-classloader)) 0)))) This code properly loads abcl-contrib when the executing jar provides abcl-contrib, while (require 'abcl-contrib) does not. My proposal is to add a file named abcl-contrib/version.lisp to the abcl-contrib.jar, possibly in the /META-INF directory to avoid any potential conflicts with java, and to have sys:find-contrib look for this file in the resources provided by the classpath. The contents of this file is not important. This change makes it possible to include the abcl-contrib "dependency" directly inside the jar application that is currently running, regardless of the name of the jar file. Therefore, applications which make use of abcl-contrib can be distributed as a single jar. For maven users, this means that their uberjars will work by just including abcl and abcl-contrib as dependencies. For ant users they would probably need to extract abcl-contrib and include the extracted files in their generated jar which I believe can be fully automated. It would be relatively easy for me to produce a patch to provide this feature as part of ABCL. It may be possible to provide this feature as an add-on, but the functions needed within the system package are private (not exported) so it would be difficult, if not impossible, to implement this feature as an add-on. I would like your feedback on this issue. If this is a feature you want, or if you have any specific objections to including this feature in ABCL, please let me know. Best Regards, Ralph Ritoch

2 11

Build ABCL with Maven using these updated POM files.
by Ralph Ritoch 03 Aug '15

03 Aug '15

Hi, I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the past few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle. Included are the following pom.xml => abcl\pom.xml (abcl-parent) main-pom.xml => abcl\main\pom.xml (abcl) contrib-pom.xml => abcl\contrib\pom.xml (abcl-contrib) Note: Filenames are relative to the trunk so they include the abcl prefix. These have been posted as a gist on github at https://gist.github.com/rritoch/70f9f211c523499b794a I have tested by deploying to my localrepo and the abcl artifact is functional. Additional work may be needed on the abcl-contrib artifact POM because I'm unsure how to test it. The file size is similar to the one generated by ant so it may be correct. Best Regards, Ralph Ritoch

2 4

Are you looking for an idea for an ABCL project?
by Ralph Ritoch 01 Aug '15

01 Aug '15

Hi, I was invited by someone in the virt.x community to add ABCL to the virt.x project http://vertx.io/ . I don't foresee having the time to do the integration this year but if anyone is interested it looks like there are many in the Java development community who are interested in using common-lisp in their JVM applications. The virt.x system supports maven and integration with vert.x will most likely require that the maven integration issues, including integration of abcl-contrib from the classpath (maven) be resolved before integration will be possible. I don't currently use virt.x but it looks like a good system for large teams with diverse programming backgrounds. Best Regards, Ralph Ritoch

1 0

bug?
by Alejandro Zamora Fonseca 27 Jul '15

27 Jul '15

Hi! Just now playing a little with ABCL(1.3.2), I saw some strange behaviour: CL-USER> '(2 . 5) (2 . 5) CL-USER> '(2 . 5 . 5) (2 . 5) CL-USER> (equal '(2 . 5) '(2 . 5 . 5)) T while other implementations give me an error when i type '(2 . 5 . 5) it's a bug or ANSI CL allows this? greetings, Alejandro -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/

3 2

Bordeaux-threads issues
by Stelian Ionescu 22 Jul '15

22 Jul '15

Hi, can somebody take a look at the Bordeaux-threads support for ABCL? The test suite hangs on Travis-CI.org during automatic tests so I guess there's something wrong there. TraviCI runs Ubuntu 12.04 LTS on x86_64. Thanks. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

3 7

ASDF 3.1.5 released
by Robert Goldman 21 Jul '15

21 Jul '15

1 0

Getting Java Class objects, and JSS
by John Pallister 08 Jul '15

08 Jul '15

Hello list, I'm working on getting ABCL + the Jetty <http://www.eclipse.org/jetty> web server + SLIME working together as a development environment for Google App Engine web apps[1]. This seems to be what the Clojure people have done <http://www.hackers-with-attitude.com/2009/08/intertactive-programming-with-…>: run your own Jetty server & SWANK server, then load the GAE JARs to provide the same emulated services as the GAE SDK's development server. I've been working through the "Embedding Jetty" tutorials[2] and making reasonable progress (with help from Mark Evenson and others on #abcl - thanks Mark!). I've been doing it all in Lisp (so far), making my own servlet classes using JNEW-RUNTIME-CLASS. Ideally I'd like to make an ABCL library equivalent to (a subset of) Compojure <https://github.com/weavejester/compojure> (and appengine-magic <https://github.com/gcv/appengine-magic>). Some of the tutorials have code like: context.addServlet(HelloServlet.class, "/"); Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)? I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS <http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown> and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE <http://emacswiki.org/emacs/JavaDevelopmentEnvironment> and/or CEDET <http://cedet.sourceforge.net/>) - has anyone else thought about this? Cheers, John :^P (hoping HTML email to the list isn't a social faux pas) [1] I have a page of initial notes and links at https://johnp.net/jpkb/wiki/AbclOnGae [2] https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty, http://www.eclipse.org/jetty/documentation/current/embedding-jetty.html -- John Pallister john(a)johnp.net john(a)synchromesh.com

3 3

Licensing Issues
by Hamda Binte Ajmal 04 Jul '15

04 Jul '15

Hello, I am using ABCL to run lisp files in my Java code. ABCL is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application. So, I conclude the GNU GPL is not going to effect the license of my Java Code, BUT, what about the lisp code I load using ABCL? Would it have to be released under GNU GPL ? Regards, Hamda

7 23

Create Instance throws exception when Java Project located on network drive
by Hamda binte Ajmal 03 Jul '15

03 Jul '15

If the java project that is using ABCL is located on a network drive, Method Create isntance throws this exception: Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: org.armedbear.lisp.Nil cannot be cast to org.armedbear.lisp.Pathname at org.armedbear.lisp.Load.loadSystemFile(Load.java:329) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) ....... I believe this has something to do with the the path. (path \\fs2\14233205\NetBeansProjects\HamdaBinteAjmal-interface- 1ed1d2022f90 ) Please note that both the abcl.jar and the java project are located on a network drive. Anyway to resolve this? Regards, Hamda

2 2

addRepository call
by Cyrus Harmon 01 Jul '15

01 Jul '15

A recent commit: 62a21ec Fix ABCL-ASDF usage with maven-3.3.x contained the following change: - (when repository - (#"addRepository" collect-request - (if repository-p - (ensure-remote-repository :repository repository) - (ensure-remote-repository)))) + (#"addRepository" collect-request + (if repository-p + (ensure-remote-repository :repository repository) + (ensure-remote-repository))) The upshot of this change is that it broke my code that uses :repository nil. This may be a non-standard thing, but I use it for jars in my local maven library. I propose the following: --- i/contrib/abcl-asdf/maven-embedder.lisp +++ w/contrib/abcl-asdf/maven-embedder.lisp @@ -469,10 +469,13 @@ (defun resolve-dependencies (group-id artifact-id artifact (java:jfield (jss:find-java-class "JavaScopes") "COMPILE"))) (collect-request (java:jnew (jss:find-java-class "CollectRequest")))) (#"setRoot" collect-request dependency) - (#"addRepository" collect-request - (if repository-p - (ensure-remote-repository :repository repository) - (ensure-remote-repository))) + + ;; Don't call addRepository if we explicitly specify a NIL repository + (unless (and repository-p (not repository)) + (#"addRepository" collect-request + (if repository-p + (ensure-remote-repository :repository repository) + (ensure-remote-repository)))) (let* ((node (#"getRoot" (#"collectDependencies" (ensure-repository-system) (ensure-session) collect-request))) (dependency-request which will call ensure-remote-repository only if :repository NIL is not explicitly specified. Any objections? thanks, Cyrus

2 1

(require 'jna) failing in 1.3.2
by Scott L. Burson 30 Jun '15

30 Jun '15

Hi armed bears, I'm getting a DependencyCollectionException from org.eclipse.aether.internal.impl.DefaultRepositorySystem: "failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0". This is ABCL 1.3.2, JDK 1.8.0_40, on Linux. ... I just tried JDK 1.7.0_71 and 1.6.0_25, and they both fail the same way. Any ideas? -- Scott

2 3

[Patch] Add name to "no breaking space" character
by Javier Olaechea 12 Jun '15

12 Jun '15

Hi, when trying to load spinneret <https://github.com/ruricolist/spinneret> on ABCL it would fail as ABCL does not recognize the character #\No-break_space <https://github.com/ruricolist/spinneret/blob/master/syntax.lisp#L37>. The character in question is named #\_. This patch adds a human readable name, #\No-break_space, which is used in sbcl, ccl and clisp, and permits spinneret to load. Hope it is adequately formatted as I'm not familiar with svn, Javier Olaechea -- "I object to doing things that computers can do." — Olin Shivers

2 1

Running embedded ABCL in J on Windows
by Jeff Shrager 07 May '15

07 May '15

I'm sure that this is a common question, so please feel free to tell me to RTFM as long as you point me to the right place in the M. I have downloaded and can separately run ABCL and J on my Win7 box, but I don't know how to tell J where ABCL is in order to run either the embedded or along-the-side ABCL from J. Can someone tell me how to do this in a Win7 env? Thanks, 'Jeff

2 1

Bug in path handling on 1.3.2
by timo.myyra＠wickedbsd.net 03 May '15

03 May '15

Hi, Just tried to update ABCL to 1.3.2 but got error when I tried to load hunchentoot. The actual error case can reduced to this: (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar") I tried above with sbcl, ecl and clisp. All those return nil as result. With ABCL I get: Bad place for a wild pathname. [Condition of type FILE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {4A273227}> #<FILE-ERROR {534DC479}> #<FUNCTION {4A273227}>) 1: (APPLY #<FUNCTION {4A273227}> (#<FILE-ERROR {534DC479}> #<FUNCTION {4A273227}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<FILE-ERROR {534DC479}> #<FUNCTION {4A273227}>) 3: (INVOKE-DEBUGGER #<FILE-ERROR {534DC479}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.probe_file$pf_file_directory_p.execute(probe_file.java:110) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 8: org.armedbear.lisp.directory_6.execute(directory.lisp:98) 9: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 11: org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) 12: org.armedbear.lisp.Lisp.eval(Lisp.java:540) 13: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 14: (FILE-DIRECTORY-P #P"/usr/local/lib/libstdc++*-gdb.py") 15: (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar") 16: (SYSTEM::%EVAL (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar")) 17: (EVAL (DIRECTORY #P"/usr/local/bin/../lib/maven-core-*.jar")) --more-- I also run the abcl test suite if that will yield any additional info: Armed Bear Common Lisp 1.3.2 Java 1.7.0_71 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.581 seconds. Startup completed in 3.332 seconds. Caught FILE-ERROR while processing --eval option "(asdf:test-system :ansi-compiled)": The file "/usr/ports/pobj/abcl-1.3.2/ansi-tests/rt-package.lsp" does not exist. Java Result: 2 Armed Bear Common Lisp 1.3.2 Java 1.7.0_71 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.545 seconds. Startup completed in 3.315 seconds. ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/rt-package.lisp ... ; (LET* (# #) ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/rt-package-TMP.abcl (0.155 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/rt.lisp ... ; (IN-PACKAGE :ABCL-REGRESSION-TEST) ; (DECLAIM (FTYPE # ...)) ; (DECLAIM (TYPE LIST ...)) ; (DECLAIM (FTYPE # ...)) ; (DECLAIM (FTYPE # ...)) ; (DEFVAR *TEST* ...) ; (DEFVAR *DO-TESTS-WHEN-DEFINED* ...) ; (DEFVAR *ENTRIES* ...) ; (DEFVAR *ENTRIES-TAIL* ...) ; (DEFVAR *ENTRIES-TABLE* ...) ; (DEFVAR *IN-TEST* ...) ; (DEFVAR *DEBUG* ...) ; (DEFVAR *CATCH-ERRORS* ...) ; (DEFVAR *PRINT-CIRCLE-ON-FAILURE* ...) ; (DEFVAR *COMPILE-TESTS* ...) ; (DEFVAR *EXPANDED-EVAL* ...) ; (DEFVAR *OPTIMIZATION-SETTINGS* ...) ; (DEFVAR *FAILED-TESTS* ...) ; (DEFVAR *PASSED-TESTS* ...) ; (DEFVAR *EXPECTED-FAILURES* ...) ; (DEFVAR *NOTES* ...) ; (DEFSTRUCT (ENTRY #) ...) ; (DEFSTRUCT NOTE ...) ; (DEFMACRO DEFN ...) ; (DEFUN ENTRY-NOTES ...) ; (DEFUN HAS-DISABLED-NOTE ...) ; (DEFUN HAS-NOTE ...) ; (DEFUN PENDING-TESTS ...) ; (DEFUN REM-ALL-TESTS ...) ; (DEFUN REM-TEST ...) ; (DEFUN GET-TEST ...) ; (DEFUN GET-ENTRY ...) ; (DEFMACRO DEFTEST ...) ; (DEFUN ADD-ENTRY ...) ; (DEFUN REPORT-ERROR ...) ; (DEFUN DO-TEST ...) ; (DEFUN MY-AREF ...) ; (DEFUN MY-ROW-MAJOR-AREF ...) ; (DEFUN EQUALP-WITH-CASE ...) ; (DEFUN DO-ENTRY ...) ; (DEFUN EXPANDED-EVAL ...) ; (DEFUN CONTINUE-TESTING ...) ; (DEFUN DO-TESTS ...) ; (DEFUN DO-ENTRIES ...) ; (DEFMACRO DEFNOTE ...) ; (DEFUN DISABLE-NOTE ...) ; (DEFUN ENABLE-NOTE ...) ; (DEFUN DO-EXTENDED-TESTS ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/rt-TMP.abcl (1.914 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/test-utilities.lisp ... ; (IN-PACKAGE #:ABCL-REGRESSION-TEST) ; (DEFMACRO SIGNALS-ERROR ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/test-utilities-TMP.abcl (0.02 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/package.lisp ... ; (DEFPACKAGE #:ABCL.TEST.LISP ...) ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFPARAMETER *ABCL-TEST-DIRECTORY* ...) ; (DEFUN RUN ...) ; (DEFVAR *LAST-RUN-MATCHING* ...) ; (DEFUN DO-TESTS-MATCHING ...) ; (SETF (SYMBOL-FUNCTION #) ...) ; (SETF (SYMBOL-FUNCTION #) ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/package-TMP.abcl (0.103 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/utilities.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFVAR *STREAM-BUFFER-SIZE* ...) ; (DEFUN CL-FAD-COPY-STREAM ...) ; (DEFUN CL-FAD-COPY-FILE ...) ; (DEFVAR *FOO.LISP* ...) ; (DEFMACRO WITH-TEMP-DIRECTORY ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/utilities-TMP.abcl (0.082 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/compiler-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFCONSTANT MOST-POSITIVE-JAVA-LONG ...) ; (DEFCONSTANT MOST-NEGATIVE-JAVA-LONG ...) ; (ASSERT (EQL MOST-POSITIVE-JAVA-LONG ...)) ; (ASSERT (EQL MOST-NEGATIVE-JAVA-LONG ...)) ; (DEFMACRO DEFINE-COMPILER-TEST ...) ; (DEFTEST UNUSED.1 ...) ; (DEFTEST UNUSED.2 ...) ; (DEFTEST PLUS.1 ...) ; (DEFTEST PLUS.2 ...) ; (DEFTEST PLUS.3 ...) ; (DEFINE-COMPILER-TEST PLUS.4 ...) ; (DEFINE-COMPILER-TEST MINUS.1 ...) ; (DEFINE-COMPILER-TEST MINUS.2 ...) ; (DEFINE-COMPILER-TEST MINUS.3 ...) ; (DEFINE-COMPILER-TEST LOGXOR-MINUS.1 ...) ; (DEFTEST TIMES.1 ...) ; (DEFTEST TIMES.2 ...) ; (DEFTEST TIMES.3 ...) ; (DEFTEST DOTIMES.1 ...) ; (DEFTEST DOTIMES.2 ...) ; (DEFTEST DERIVE-TYPE-LOGXOR.1 ...) ; (DEFTEST DERIVE-TYPE-LOGXOR.2 ...) ; (DEFTEST DERIVE-TYPE-LOGXOR.3 ...) ; (DEFTEST ASH.1 ...) ; (DEFTEST BIGNUM-CONSTANT.1 ...) ; (DEFTEST BIGNUM-CONSTANT.2 ...) ; (DEFTEST BIGNUM-CONSTANT.3 ...) ; (DEFTEST BIGNUM-CONSTANT.4 ...) ; (DEFTEST SHIFTF.1 ...) ; (DEFTEST LOGAND-VALUES.1 ...) ; (DEFTEST LOGAND-LOGNOT.1 ...) ; (DEFTEST LOGIOR-LOGAND-SETF.1 ...) ; (DEFTEST LOGXOR.1 ...) ; (DEFINE-COMPILER-TEST MIN.1 ...) ; (DEFINE-COMPILER-TEST MIN.2 ...) ; (DEFINE-COMPILER-TEST MIN.3 ...) ; (DEFINE-COMPILER-TEST MIN.4 ...) ; (DEFINE-COMPILER-TEST MAX.1 ...) ; (DEFINE-COMPILER-TEST MAX.2 ...) ; (DEFINE-COMPILER-TEST MAX.3 ...) ; (DEFINE-COMPILER-TEST MAX.4 ...) ; (DEFTEST COMPILER.1 ...) ; (DEFTEST COMPILER.2 ...) ; (DEFTEST COMPILER.3 ...) ; (DEFTEST COMPILER.4A ...) ; (DEFTEST COMPILER.4B ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/compiler-tests-TMP.abcl (0.617 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/condition-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFUN FILTER ...) ; (DEFTEST CONDITION.1 ...) ; (DEFTEST CONDITION.2 ...) ; (DEFTEST CONDITION.3 ...) ; (DEFTEST PRINT-NOT-READABLE-OBJECT.1 ...) ; (DEFTEST PRINT-NOT-READABLE-OBJECT.2 ...) ; (DEFTEST TYPE-ERROR.1 ...) ; (DEFTEST TYPE-ERROR.2 ...) ; (DEFTEST TYPE-ERROR.3 ...) ; (DEFTEST TYPE-ERROR.4 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.1 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.2 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.3 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.4 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.5 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.6 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.7 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.8 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.9 ...) ; (DEFTEST SIMPLE-TYPE-ERROR.10 ...) ; (DEFTEST DEFINE-CONDITION.1 ...) ; (DEFTEST DEFINE-CONDITION.2 ...) ; (DEFTEST DEFINE-CONDITION.3 ...) ; (DEFTEST DEFINE-CONDITION.4 ...) ; (DEFTEST DEFINE-CONDITION.5 ...) ; (DEFTEST DEFINE-CONDITION.6 ...) ; (DEFTEST DEFINE-CONDITION.7 ...) ; (DEFTEST DEFINE-CONDITION.8 ...) ; (DEFTEST DEFINE-CONDITION.9 ...) ; (DEFTEST DEFINE-CONDITION.10 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/condition-tests-TMP.abcl (0.274 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/class-file.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST FIELDTYPE.1A ...) ; (DEFTEST FIELDTYPE.1B ...) ; (DEFTEST FIELDTYPE.1C ...) ; (DEFTEST FIELDTYPE.1D ...) ; (DEFTEST FIELDTYPE.1E ...) ; (DEFTEST FIELDTYPE.1F ...) ; (DEFTEST FIELDTYPE.1G ...) ; (DEFTEST FIELDTYPE.1H ...) ; (DEFTEST FIELDTYPE.1I ...) ; (DEFTEST FIELDTYPE.1J ...) ; (DEFTEST FIELDTYPE.2 ...) ; (DEFTEST FIELDREF.1A ...) ; (DEFTEST FIELDREF.1B ...) ; (DEFTEST FIELDREF.1C ...) ; (DEFTEST FIELDREF.1D ...) ; (DEFTEST FIELDREF.1E ...) ; (DEFTEST FIELDREF.1F ...) ; (DEFTEST FIELDREF.1G ...) ; (DEFTEST FIELDREF.1H ...) ; (DEFTEST FIELDREF.1I ...) ; (DEFTEST FIELDREF.1J ...) ; (DEFTEST FIELDREF.2 ...) ; (DEFTEST DESCRIPTOR.1 ...) ; (DEFTEST DESCRIPTOR.2 ...) ; (DEFTEST MAP-FLAGS.1 ...) ; (DEFTEST POOL.1 ...) ; (DEFTEST MAKE-CLASS-FILE.1 ...) ; (DEFTEST FINALIZE-CLASS-FILE.1 ...) ; (DEFTEST GENERATE-METHOD.1 ...) ; (DEFTEST GENERATE-METHOD.2 ...) ; (DEFTEST GENERATE-METHOD.3 ...) ; (DEFTEST GENERATE-METHOD.4 ...) ; (DEFTEST GENERATE-METHOD.5 ...) ; (DEFTEST WITH-CODE-TO-METHOD.1 ...) ; (DEFTEST WITH-CODE-TO-METHOD.2 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/class-file-TMP.abcl (0.417 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/metaclass.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFCLASS TESTCLASS1 ...) ; (DEFCLASS TESTCLASS2 ...) ; (DEFCLASS METACLASS1 ...) ; (DEFCLASS METACLASS2 ...) ; (DEFCLASS TESTCLASS3 ...) ; (DEFTEST TESTCLASS1.INSTANTIATE ...) ; (DEFTEST TESTCLASS2.INSTANTIATE ...) ; (DEFTEST TESTCLASS3.INSTANTIATE ...) ; (DEFTEST TESTCLASS1.CLASS-OF ...) ; (DEFTEST TESTCLASS1.METACLASS-OF ...) ; (DEFTEST TESTCLASS3.METACLASS-OF ...) ; (DEFTEST STANDARD-CLASS.TYPEP.CLASS ...) ; (DEFTEST STANDARD-CLASS.TYPEP.STANDARD-CLASS ...) ; (DEFTEST METACLASS1.TYPEP.CLASS ...) ; (DEFTEST METACLASS1.TYPEP.STANDARD-CLASS ...) ; (DEFTEST TESTCLASS3.CLASS-OF.TYPEP ...) ; (DEFTEST TESTCLASS3.METACLASS-OF.TYPEP ...) ; (DEFCLASS TESTCLASS4 ...) ; (DEFTEST TESTCLASS4.INIT-NOARGS ...) ; (DEFTEST TESTCLASS4.INITARGS ...) ; (DEFCLASS TESTCLASS5 ...) ; (DEFTEST TESTCLASS5.INIT-NOARGS ...) ; (DEFTEST TESTCLASS5.INITARGS ...) ; (DEFCLASS TESTCLASS6 ...) ; (DEFTEST TESTCLASS6.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/metaclass-TMP.abcl (0.249 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/mop-tests-setup.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFUN FIND-CLASSES ...) ; (DEFGENERIC MOP-TEST.FOO ...) ; (DEFUN FIND-FOO ...) ; (DEFGENERIC MOP-TEST.BAR ...) ; (DEFUN FIND-BAR ...) ; (DEFGENERIC MOP-TEST.BAZ ...) ; (DEFUN FIND-BAZ ...) ; (DEFGENERIC MOP-TEST.QUUX ...) ; (DEFUN FIND-QUUX ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/mop-tests-setup-TMP.abcl (0.451 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/mop-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.1 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.2 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.3 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.4 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.5 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.6 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.7 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.FOO.8 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.1 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.1A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.1B ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.1C ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.2 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.2A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.3 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.3A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.4 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.4A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.5 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAR.5A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.1 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.1A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.1B ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.1C ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.2 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.3 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.4 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.BAZ.5 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.1 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.1A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.2 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.2A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.3 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.3A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.4 ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.4A ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.4B ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.4C ...) ; (DEFTEST COMPUTE-APPLICABLE-METHODS.QUUX.5 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/mop-tests-TMP.abcl (0.27 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/clos-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST DMC-RETURN.1 ...) ; (DEFTEST DMC-RETURN.2 ...) ; (DEFTEST DMC-RETURN.3 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-MC.1 ...) ; (DEFGENERIC DMC-TEST-MC.1 ...) ; (DEFMETHOD DMC-TEST-MC.1 ...) ; (DEFTEST DMC-TEST-MC.1 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-MC.2 ...) ; (DEFGENERIC DMC-TEST-MC.2A ...) ; (DEFMETHOD DMC-TEST-MC.2A ...) ; (DEFTEST DMC-TEST-MC.2A ...) ; (DEFGENERIC DMC-TEST-MC.2B ...) ; (DEFMETHOD DMC-TEST-MC.2B ...) ; (DEFMETHOD DMC-TEST-MC.2B ...) ; (DEFTEST DMC-TEST-MC.2B ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-MC.3A ...) ; (DEFGENERIC DMC-TEST-MC.3A ...) ; (DEFMETHOD DMC-TEST-MC.3A ...) ; (DEFMETHOD DMC-TEST-MC.3A ...) ; (DEFMETHOD DMC-TEST-MC.3A ...) ; (DEFTEST DMC-TEST-MC.3A ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-MC.3B ...) ; (DEFGENERIC DMC-TEST-MC.3B ...) ; (DEFMETHOD DMC-TEST-MC.3B ...) ; (DEFMETHOD DMC-TEST-MC.3B ...) ; (DEFTEST DMC-TEST-MC.3B ...) ; (DEFPARAMETER *DMC-TEST-4* ...) ; (DEFUN OBJECT-LOCK ...) ; (DEFUN UNLOCK ...) ; (DEFUN LOCK ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-MC.4 ...) ; (DEFGENERIC DMC-TEST.4 ...) ; (DEFMETHOD DMC-TEST.4 ...) ; (DEFMETHOD DMC-TEST.4 ...) ; (DEFTEST DMC-TEST.4A ...) ; (DEFTEST DMC-TEST.4B ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST.5 ...) ; (DEFGENERIC DMC-TEST-MC.5 ...) ; (DEFTEST DMC-TEST.5A ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST.6 ...) ; (DEFGENERIC DMC-TEST-MC.6 ...) ; (DEFTEST DMC-TEST-MC.6A ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST.7 ...) ; (DEFGENERIC DMC-TEST-MC.7 ...) ; (DEFMETHOD DMC-TEST-MC.7 ...) ; (DEFTEST DMC-TEST-MC.7A ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.1 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.1 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.1 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.2 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.2 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.2 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.3A ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.3A ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.3A ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.3B ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.3B ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.3B ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.3C ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.3C ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.3C ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.3D ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.3D ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.3D ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.4 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.4 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.4 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-WHOLE.5 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-WHOLE.5 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-WHOLE.5 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-OPTIONAL.1 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-OPTIONAL.1 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.1A ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.1B ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-OPTIONAL.2 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-OPTIONAL.2 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.2A ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.2B ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-OPTIONAL.3 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-OPTIONAL.3 ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.3 ...) ; (DEFINE-METHOD-COMBINATION DMC-TEST-ARGS-WITH-OPTIONAL.4 ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-OPTIONAL.4A ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.4A ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.4B ...) ; (DEFGENERIC DMC-TEST-ARGS-WITH-OPTIONAL.4C ...) ; (DEFTEST DMC-TEST-ARGS-WITH-OPTIONAL.4C ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/clos-tests-TMP.abcl (0.982 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/file-system-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFPARAMETER *THIS-FILE* ...) ; (DEFPARAMETER *THIS-DIRECTORY* ...) ; (DEFUN PATHNAMES-EQUAL-P ...) ; (DEFUN RUN-SHELL-COMMAND ...) ; (DEFUN COPY-FILE ...) ; (DEFUN MAKE-SYMBOLIC-LINK ...) ; (DEFUN PROBE-DIRECTORY ...) ; (DEFUN FILE-DIRECTORY-P ...) ; (DEFUN MAKE-DIRECTORY ...) ; (DEFUN DELETE-DIRECTORY ...) ; (DEFUN MAKE-TEMPORARY-FILENAME ...) ; (DEFUN TOUCH ...) ; (DEFUN MAKE-TEMPORARY-DIRECTORY ...) ; (DEFUN DELETE-DIRECTORY-AND-FILES ...) ; (DEFTEST RUN-SHELL-COMMAND.1 ...) ; (DEFTEST RUN-SHELL-COMMAND.2 ...) ; (DEFTEST PROBE-FILE.1 ...) ; (DEFTEST PROBE-FILE.2 ...) ; (DEFTEST PROBE-FILE.3 ...) ; (DEFTEST PROBE-FILE.4 ...) ; (DEFTEST PROBE-FILE.5 ...) ; (DEFTEST TRUENAME.1 ...) ; (DEFTEST TRUENAME.2 ...) ; (DEFTEST DIRECTORY.1 ...) ; (DEFTEST DIRECTORY.2 ...) ; (DEFTEST DIRECTORY.3 ...) ; (DEFTEST DIRECTORY.4 ...) ; (DEFTEST SYMLINK.1 ...) ; (DEFTEST SYMLINK.2 ...) ; (DEFTEST USER-HOMEDIR-PATHNAME.1 ...) ; (DEFTEST FILE-SYSTEM.DIRECTORY-NAMESTRING.1 ...) ; (DEFTEST FILE.SYSTEM.DIRECTORY-NAMESTRING.2 ...) ; (DEFTEST ENSURE-DIRECTORIES-EXIST.1 ...) ; (DEFTEST ENSURE-DIRECTORIES-EXIST.2 ...) ; (DEFTEST ENSURE-DIRECTORIES-EXIST.3 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/file-system-tests-TMP.abcl (0.338 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/pathname-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFUN CHECK-PHYSICAL-PATHNAME ...) ; (DEFUN CHECK-WINDOWS-PATHNAME ...) ; (DEFUN CHECK-LOGICAL-PATHNAME ...) ; (DEFUN CHECK-MERGE-PATHNAMES ...) ; (DEFUN CHECK-TRANSLATE-PATHNAME ...) ; (DEFMACRO CHECK-READABLE ...) ; (DEFUN CHECK-READABLE-OR-SIGNALS-ERROR ...) ; (DEFMACRO CHECK-NAMESTRING ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "effluvia") ...) ; (DEFTEST EQUAL.1 ...) ; (DEFTEST EQUAL.2 ...) ; (DEFTEST SXHASH.1 ...) ; (DEFTEST SXHASH.2 ...) ; (DEFTEST SXHASH.3 ...) ; (DEFTEST PHYSICAL.1 ...) ; (DEFTEST PHYSICAL.2 ...) ; (DEFTEST PHYSICAL.3 ...) ; (DEFTEST PHYSICAL.4 ...) ; (DEFTEST PHYSICAL.5 ...) ; (DEFTEST PHYSICAL.6 ...) ; (DEFTEST PHYSICAL.7 ...) ; (DEFTEST PHYSICAL.8 ...) ; (DEFTEST PHYSICAL.9 ...) ; (DEFTEST PHYSICAL.10 ...) ; (DEFTEST PHYSICAL.11 ...) ; (DEFTEST PHYSICAL.12 ...) ; (DEFTEST PHYSICAL.13 ...) ; (DEFTEST PHYSICAL.14 ...) ; (DEFTEST PHYSICAL.15 ...) ; (DEFTEST PHYSICAL.18 ...) ; (DEFTEST PHYSICAL.19 ...) ; (DEFTEST PHYSICAL.20 ...) ; (DEFTEST PHYSICAL.21 ...) ; (DEFTEST PHYSICAL.22 ...) ; (DEFTEST NAMESTRING.1 ...) ; (DEFTEST PHYSICAL.23 ...) ; (DEFTEST PHYSICAL.24 ...) ; (DEFTEST NAMESTRING.2 ...) ; (DEFTEST DIRECTORY-NAMESTRING.1 ...) ; (DEFTEST PHYSICAL.25 ...) ; (DEFTEST PHYSICAL.26 ...) ; (DEFTEST PHYSICAL.27 ...) ; (DEFTEST PHYSICAL.28 ...) ; (DEFTEST NAMESTRING.3 ...) ; (DEFTEST PHYSICAL.29 ...) ; (DEFTEST NAMESTRING.4 ...) ; (DEFTEST DIRECTORY-NAMESTRING.2 ...) ; (DEFTEST PHYSICAL.30 ...) ; (DEFTEST PHYSICAL.31 ...) ; (DEFTEST WILD.1 ...) ; (DEFTEST WILD.2 ...) ; (DEFTEST WILD.3 ...) ; (DEFTEST WILD.4 ...) ; (DEFTEST WILD.5 ...) ; (DEFTEST LOTS-OF-DOTS.1 ...) ; (DEFTEST LOTS-OF-DOTS.2 ...) ; (DEFTEST SILLY.1 ...) ; (DEFTEST SILLY.2 ...) ; (DEFTEST SILLY.3 ...) ; (DEFTEST SILLY.4 ...) ; (DEFTEST SILLY.5 ...) ; (DEFTEST SILLY.6 ...) ; (DEFTEST LOGICAL-PATHNAME-TRANSLATIONS.1 ...) ; (DEFTEST LOGICAL-PATHNAME.1 ...) ; (DEFTEST LOGICAL-PATHNAME.2 ...) ; (DEFTEST LOGICAL.1 ...) ; (DEFTEST LOGICAL.3 ...) ; (DEFTEST LOGICAL.4 ...) ; (DEFTEST LOGICAL.5 ...) ; (DEFTEST LOGICAL.8 ...) ; (DEFTEST LOGICAL.9 ...) ; (DEFTEST LOGICAL.10 ...) ; (DEFTEST LOGICAL.11 ...) ; (DEFTEST LOGICAL.12 ...) ; (DEFTEST LOGICAL.13 ...) ; (DEFTEST LOGICAL.14 ...) ; (DEFTEST LOGICAL.15 ...) ; (DEFTEST LOGICAL.16 ...) ; (DEFTEST LOGICAL.17 ...) ; (DEFTEST LOGICAL.18 ...) ; (DEFTEST LOGICAL.19 ...) ; (DEFTEST LOGICAL.20 ...) ; (DEFTEST LOGICAL.21 ...) ; (DEFTEST LOGICAL.22 ...) ; (DEFTEST LOGICAL.23 ...) ; (DEFTEST PARSE-NAMESTRING.1 ...) ; (DEFTEST PARSE-NAMESTRING.2 ...) ; (DEFTEST PARSE-NAMESTRING.3 ...) ; (DEFTEST PARSE-NAMESTRING.4 ...) ; (DEFTEST PARSE-NAMESTRING.5 ...) ; (DEFTEST PARSE-NAMESTRING.6 ...) ; (DEFTEST PARSE-NAMESTRING.7 ...) ; (DEFTEST PARSE-NAMESTRING.8 ...) ; (DEFTEST WILD-PATHNAME-P.1 ...) ; (DEFTEST PATHNAME-MATCH-P.1 ...) ; (DEFTEST PATHNAME-MATCH-P.2 ...) ; (DEFTEST PATHNAME-MATCH-P.3 ...) ; (DEFTEST PATHNAME-MATCH-P.4 ...) ; (DEFTEST PATHNAME-MATCH-P.5 ...) ; (DEFTEST PATHNAME-MATCH-P.6 ...) ; (DEFTEST PATHNAME-MATCH-P.7 ...) ; (DEFTEST PATHNAME-MATCH-P.8 ...) ; (DEFTEST PATHNAME-MATCH-P.9 ...) ; (DEFTEST PATHNAME-MATCH-P.10 ...) ; (DEFTEST TRANSLATE-PATHNAME.1 ...) ; (DEFTEST TRANSLATE-PATHNAME.2 ...) ; (DEFTEST TRANSLATE-PATHNAME.3 ...) ; (DEFTEST TRANSLATE-PATHNAME.4 ...) ; (DEFTEST TRANSLATE-PATHNAME.5 ...) ; (DEFTEST TRANSLATE-PATHNAME.6 ...) ; (DEFTEST TRANSLATE-PATHNAME.7 ...) ; (DEFTEST TRANSLATE-PATHNAME.8 ...) ; (DEFTEST TRANSLATE-PATHNAME.9 ...) ; (DEFTEST TRANSLATE-PATHNAME.10 ...) ; (DEFTEST TRANSLATE-PATHNAME.11 ...) ; (DEFTEST TRANSLATE-PATHNAME.12 ...) ; (DEFTEST TRANSLATE-PATHNAME.13 ...) ; (DEFTEST TRANSLATE-PATHNAME.14 ...) ; (DEFTEST TRANSLATE-PATHNAME.15 ...) ; (DEFTEST TRANSLATE-PATHNAME.16 ...) ; (DEFTEST TRANSLATE-PATHNAME.17 ...) ; (DEFTEST PATHNAME-MATCH-P.11 ...) ; (DEFTEST TRANSLATE-PATHNAME.18 ...) ; (DEFTEST PATHNAME-MATCH-P.12 ...) ; (DEFTEST TRANSLATE-PATHNAME.19 ...) ; (DEFTEST TRANSLATE-PATHNAME.20 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.1 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.2 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.4 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.5 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.6 ...) ; (DEFTEST TRANSLATE-LOGICAL-PATHNAME.7 ...) ; (DEFTEST MERGE-PATHNAMES.1 ...) ; (DEFTEST MERGE-PATHNAMES.2 ...) ; (DEFTEST COMPILE-FILE-PATHNAME.1 ...) ; (DEFTEST FILE-NAMESTRING.1 ...) ; (DEFTEST FILE-NAMESTRING.2 ...) ; (DEFTEST FILE-NAMESTRING.3 ...) ; (DEFTEST FILE-NAMESTRING.4 ...) ; (DEFTEST ENOUGH-NAMESTRING.1 ...) ; (DEFTEST ENOUGH-NAMESTRING.2 ...) ; (DEFTEST ENOUGH-NAMESTRING.3 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "demo0") ...) ; (DEFTEST SBCL.1 ...) ; (DEFTEST SBCL.2 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "demo1") ...) ; (DEFTEST SBCL.3 ...) ; (DEFTEST SBCL.4 ...) ; (DEFTEST SBCL.5 ...) ; (DEFTEST SBCL.8 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "demo2") ...) ; (DEFTEST SBCL.9 ...) ; (DEFTEST SBCL.10 ...) ; (DEFTEST SBCL.11 ...) ; (DEFTEST SBCL.12 ...) ; (DEFTEST SBCL.13 ...) ; (DEFTEST SBCL.14 ...) ; (DEFTEST SBCL.15 ...) ; (DEFTEST SBCL.16 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "bazooka") ...) ; (DEFTEST SBCL.17 ...) ; (DEFTEST SBCL.18 ...) ; (DEFTEST SBCL.19 ...) ; (DEFTEST SBCL.20 ...) ; (DEFTEST SBCL.21 ...) ; (DEFTEST SBCL.22 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "test0") ...) ; (DEFTEST SBCL.23 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "prog") ...) ; (DEFTEST SBCL.24 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "prog1") ...) ; (DEFTEST SBCL.25 ...) ; (DEFTEST SBCL.26 ...) ; (SETF (LOGICAL-PATHNAME-TRANSLATIONS "scratch") ...) ; (DEFTEST SBCL.27 ...) ; (DEFTEST SBCL.28 ...) ; (DEFTEST SBCL.29 ...) ; (DEFTEST SBCL.30 ...) ; (DEFTEST SBCL.31 ...) ; (DEFTEST SBCL.32 ...) ; (DEFTEST SBCL.33 ...) ; (DEFTEST SBCL.34 ...) ; (DEFTEST SBCL.35 ...) ; (DEFTEST SBCL.36 ...) ; (DEFTEST SBCL.37 ...) ; (DEFTEST SBCL.38 ...) ; (DEFTEST SBCL.39 ...) ; (DEFTEST SBCL.40 ...) ; (DEFTEST SBCL.41 ...) ; (DEFTEST SBCL.42 ...) ; (DEFTEST SBCL.43 ...) ; (DEFTEST SBCL.44 ...) ; (DEFTEST SBCL.45 ...) ; (DEFTEST SBCL.46 ...) ; (DEFTEST SBCL.47 ...) ; (DEFTEST SBCL.48 ...) ; (DEFTEST SBCL.49 ...) ; (DEFTEST SBCL.50 ...) ; (DEFTEST SBCL.51 ...) ; (DEFTEST SBCL.52 ...) ; (DEFTEST SBCL.53 ...) ; (DEFTEST SBCL.54 ...) ; (DEFTEST SBCL.55 ...) ; (DEFTEST SBCL.56 ...) ; (DEFTEST SBCL.57 ...) ; (DEFTEST SBCL.58 ...) ; (DEFTEST SBCL.59 ...) ; (DEFTEST SBCL.60 ...) ; (DEFTEST SBCL.61 ...) ; (DEFTEST SBCL.62 ...) ; (DEFTEST MAKE-PATHNAME.1 ...) ; (DEFTEST PATHNAME.URI-ENCODING.1 ...) ; (DEFTEST PATHNAME.URI-ENCODING.2 ...) ; (DEFTEST PATHNAME.LOAD.1 ...) ; (DEFTEST PATHNAME.LOAD.2 ...) ; (DEFTEST PATHNAME.MAKE-PATHNAME.1 ...) ; (DEFTEST PATHNAME.MAKE-PATHNAME.2 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/pathname-tests-TMP.abcl (1.819 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/jar-pathname.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFPARAMETER *TMP-DIRECTORY* ...) ; (DEFPARAMETER *TMP-DIRECTORY-WHITESPACE* ...) ; (DEFPARAMETER *TMP-JAR-PATH* ...) ; (DEFPARAMETER *TMP-JAR-PATH-WHITESPACE* ...) ; (DEFVAR *FOO.LISP* ...) ; (DEFVAR *BAR.LISP* ...) ; (DEFVAR *EEK.LISP* ...) ; (DEFUN WRITE-FORMS ...) ; (DEFUN JAR-FILE-INIT ...) ; (DEFUN CLEAN-JAR-TESTS ...) ; (DEFMACRO WITH-JAR-FILE-INIT ...) ; (DEFUN JAR-PATHNAME-ESCAPED ...) ; (DEFMACRO LOAD-FROM-JAR ...) ; (PUSH (QUOTE JAR-PATHNAME.LOAD.INIT) ...) ; (DEFTEST JAR-PATHNAME.LOAD.INIT ...) ; (DEFTEST JAR-PATHNAME.LOAD.1 ...) ; (DEFTEST JAR-PATHNAME.LOAD.2 ...) ; (DEFTEST JAR-PATHNAME.LOAD.3 ...) ; (DEFTEST JAR-PATHNAME.LOAD.4 ...) ; (DEFTEST JAR-PATHNAME.LOAD.5 ...) ; (DEFTEST JAR-PATHNAME.LOAD.6 ...) ; (DEFTEST JAR-PATHNAME.LOAD.7 ...) ; (DEFTEST JAR-PATHNAME.LOAD.8 ...) ; (DEFTEST JAR-PATHNAME.LOAD.9 ...) ; (DEFTEST JAR-PATHNAME.LOAD.10 ...) ; (DEFTEST JAR-PATHNAME.LOAD.11 ...) ; (DEFTEST JAR-PATHNAME.LOAD.12 ...) ; (DEFTEST JAR-PATHNAME.LOAD.13 ...) ; (DEFTEST JAR-PATHNAME.LOAD.14 ...) ; (DEFTEST JAR-PATHNAME.LOAD.15 ...) ; (DEFTEST JAR-PATHNAME.LOAD.16 ...) ; (DEFPARAMETER *URL-JAR-PATHNAME-BASE* ...) ; (DEFMACRO LOAD-URL-RELATIVE ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.1 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.2 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.3 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.4 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.5 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.6 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.7 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.8 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.9 ...) ; (DEFTEST JAR-PATHNAME.LOAD.HTTP.10 ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.1 ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.2 ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.3 ...) ; (PUSH (QUOTE JAR-PATHNAME.PROBE-FILE.4) ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.4 ...) ; (PUSH (QUOTE JAR-PATHNAME.PROBE-FILE.5) ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.5 ...) ; (DEFTEST JAR-PATHNAME.PROBE-FILE.6 ...) ; (DEFTEST JAR-PATHNAME.MERGE-PATHNAMES.1 ...) ; (DEFTEST JAR-PATHNAME.MERGE-PATHNAMES.2 ...) ; (DEFTEST JAR-PATHNAME.MERGE-PATHNAMES.3 ...) ; (DEFTEST JAR-PATHNAME.MERGE-PATHNAMES.4 ...) ; (DEFTEST JAR-PATHNAME.MERGE-PATHNAMES.5 ...) ; (DEFTEST JAR-PATHNAME.TRUENAME.1 ...) ; (DEFTEST JAR-PATHNAME.1 ...) ; (DEFTEST JAR-PATHNAME.2 ...) ; (DEFTEST JAR-PATHNAME.3 ...) ; (DEFTEST JAR-PATHNAME.4 ...) ; (DEFTEST JAR-PATHNAME.5 ...) ; (DEFTEST JAR-PATHNAME.6 ...) ; (DEFTEST JAR-PATHNAME.7 ...) ; (DEFTEST JAR-PATHNAME.8 ...) ; (DEFTEST JAR-PATHNAME.9 ...) ; (DEFTEST JAR-PATHNAME.10 ...) ; (DEFTEST JAR-PATHNAME.11 ...) ; (DEFTEST JAR-PATHNAME.12 ...) ; (DEFTEST JAR-PATHNAME.MATCH-P.1 ...) ; (DEFTEST JAR-PATHNAME.MATCH-P.2 ...) ; (DEFTEST JAR-PATHNAME.MATCH-P.3 ...) ; (DEFTEST JAR-PATHNAME.TRANSLATE.1 ...) ; (DEFTEST JAR-PATHNAME.TRUENAME.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/jar-pathname-TMP.abcl (0.498 seconds) ; Caught SIMPLE-WARNING: ; Redefining test JAR-PATHNAME.TRUENAME.1 ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/url-pathname.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST URL-PATHNAME.1 ...) ; (DEFTEST URL-PATHNAME.2 ...) ; (DEFTEST URL-PATHNAME.3 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/url-pathname-TMP.abcl (0.035 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/math-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFMACRO SET-FLOATING-POINT-MODES ...) ; (DEFMACRO GET-FLOATING-POINT-MODES ...) ; (DEFMACRO RESTORE-DEFAULT-FLOATING-POINT-MODES ...) ; (RESTORE-DEFAULT-FLOATING-POINT-MODES) ; (DEFTEST MOST-NEGATIVE-FIXNUM.1 ...) ; (DEFTEST MOST-NEGATIVE-FIXNUM.2 ...) ; (DEFTEST FLOATING-POINT-MODES.1 ...) ; (DEFTEST FLOATING-POINT-MODES.2 ...) ; (DEFTEST FLOATING-POINT-MODES.3 ...) ; (DEFTEST FLOATING-POINT-MODES.4 ...) ; (DEFTEST SINGLE-FLOAT-EPSILON.1 ...) ; (DEFTEST SINGLE-FLOAT-NEGATIVE-EPSILON.1 ...) ; (DEFTEST MOST-POSITIVE-SINGLE-FLOAT.1 ...) ; (DEFTEST MOST-POSITIVE-SINGLE-FLOAT.2 ...) ; (DEFTEST LEAST-POSITIVE-SINGLE-FLOAT.1 ...) ; (DEFTEST LEAST-POSITIVE-SINGLE-FLOAT.2 ...) ; (DEFTEST SQRT.1 ...) ; (DEFTEST SQRT.2 ...) ; (DEFTEST SQRT.3 ...) ; (DEFTEST SQRT.4 ...) ; (DEFTEST SQRT.5 ...) ; (DEFTEST SQRT.6 ...) ; (DEFTEST SQRT.7 ...) ; (DEFTEST SQRT.8 ...) ; (DEFTEST SQRT.9 ...) ; (DEFTEST SQRT.10 ...) ; (DEFTEST SQRT.11 ...) ; (DEFTEST SQRT.12 ...) ; (DEFTEST SQRT.13 ...) ; (DEFTEST SQRT.14 ...) ; (DEFTEST EXP.1 ...) ; (DEFTEST EXP.2 ...) ; (DEFTEST EXP.3 ...) ; (DEFTEST EXP.4 ...) ; (DEFTEST EXP.5 ...) ; (DEFTEST EXP.6 ...) ; (DEFTEST EXP.7 ...) ; (DEFTEST EXP.8 ...) ; (DEFTEST EXP.9 ...) ; (DEFTEST EXPT.1 ...) ; (DEFTEST EXPT.2 ...) ; (DEFTEST EXPT.3 ...) ; (DEFTEST EXPT.4 ...) ; (DEFTEST EXPT.5 ...) ; (DEFTEST EXPT.6 ...) ; (DEFTEST EXPT.7 ...) ; (DEFTEST EXPT.8 ...) ; (DEFTEST EXPT.9 ...) ; (DEFTEST EXPT.10 ...) ; (DEFTEST EXPT.11 ...) ; (DEFTEST EXPT.12 ...) ; (DEFTEST EXPT.13 ...) ; (DEFTEST EXPT.14 ...) ; (DEFTEST EXPT.15 ...) ; (DEFTEST EXPT.16 ...) ; (DEFTEST EXPT.17 ...) ; (DEFTEST EXPT.18 ...) ; (DEFTEST EXPT.19 ...) ; (DEFTEST EXPT.20 ...) ; (DEFTEST EXPT.21 ...) ; (DEFTEST EXPT.22 ...) ; (DEFTEST EXPT.23 ...) ; (DEFTEST EXPT.24 ...) ; (DEFTEST EXPT.25 ...) ; (DEFTEST EXPT.26 ...) ; (DEFTEST LOG.1 ...) ; (DEFTEST LOG.2 ...) ; (DEFTEST LOG.3 ...) ; (DEFTEST LOG.4 ...) ; (DEFTEST LOG.5 ...) ; (DEFTEST LOG.6 ...) ; (DEFTEST LOG.7 ...) ; (DEFTEST PI.1 ...) ; (DEFTEST TAN.1 ...) ; (DEFTEST TAN.2 ...) ; (DEFTEST TAN.3 ...) ; (DEFTEST TAN.4 ...) ; (DEFTEST ATANH.1 ...) ; (DEFTEST ATANH.2 ...) ; (DEFTEST TRUNCATE.1 ...) ; (DEFTEST TRUNCATE.2 ...) ; (DEFTEST TRUNCATE.3 ...) ; (DEFTEST TRUNCATE.4 ...) ; (DEFTEST MATH.READ-FROM-STRING.1 ...) ; (DEFINE-COMPILER-TEST MATH.LOGAND.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/math-tests-TMP.abcl (0.657 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/misc-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST MISC.DOTIMES.1 ...) ; (DEFTEST DOTIMES.1.COMPILED ...) ; (DEFTEST MISC.DOTIMES.2 ...) ; (DEFTEST DOTIMES.2.COMPILED ...) ; (DEFTEST FUNCALL.1 ...) ; (DEFTEST FUNCALL.2 ...) ; (DEFTEST FUNCALL.3 ...) ; (DEFTEST FUNCALL.4 ...) ; (DEFTEST FUNCALL.5 ...) ; (DEFTEST COPY-LIST.1 ...) ; (DEFTEST READ-FROM-STRING.1 ...) ; (DEFTEST READ-FROM-STRING.2 ...) ; (DEFSTRUCT MYSTRUCT ...) ; (DEFTEST TICKET.107 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/misc-tests-TMP.abcl (0.138 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/latin1-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST NORMAL-UTF8.1 ...) ; (DEFTEST LATIN1.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/latin1-tests-TMP.abcl (0.018 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/bugs.lisp ... ; (IN-PACKAGE :ABCL.TEST.LISP) ; (DEFTEST BUGS.LOGICAL-PATHNAME.1 ...) ; (DEFTEST BUGS.LOGICAL-PATHNAME.2 ...) ; (DEFTEST BUGS.PATHNAME.1 ...) ; (DEFTEST BUGS.PATHNAME.2 ...) ; (DEFTEST BUGS.PATHNAME.3 ...) ; (DEFTEST BUGS.JAVA.1 ...) ; (DEFTEST BUGS.READTABLE-CASE.1 ...) ; (DEFTEST BUGS.PPRINT.1 ...) ; (DEFTEST BUGS.DEFGENERIC.1 ...) ; (DEFTEST BUGS.CLOS.AUX.1 ...) ; (DEFTEST BUGS.PATHNAME.MAKE-PATHNAME.1 ...) ; (PUSH (QUOTE BUGS.PATHNAME.MAKE-PATHNAME.1) ...) ; (DEFTEST BUGS.PATHNAME.MAKE-PATHNAME.2 ...) ; (DEFTEST BUGS.LOOP.1 ...) ; (DEFTEST BUGS.READER.1 ...) ; (DEFTEST BUGS.EXPORT.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/bugs-TMP.abcl (0.1 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/wild-pathnames.lisp ... ; (IN-PACKAGE :ABCL.TEST.LISP) ; (DEFVAR *TEST-FILES* ...) ; (DEFVAR *TEMP-DIRECTORY-ROOT* ...) ; (DEFUN CREATE-WILD-TEST-HIERARCHY ...) ; (DEFUN REMOVE-WILD-TEST-HIERARCHY ...) ; (DEFMACRO WITH-TEST-DIRECTORIES ...) ; (DEFUN SET-EQUAL ...) ; (DEFTEST WILD-PATHNAMES.1 ...) ; (DEFTEST WILD-PATHNAMES.2 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/wild-pathnames-TMP.abcl (0.071 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/weak-hash-tables.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFUN RANDOM-OBJECT ...) ; (DEFTEST WEAK-HASH-TABLE.1 ...) ; (DEFTEST WEAK-HASH-TABLE.2 ...) ; (DEFTEST WEAK-HASH-TABLE.3 ...) ; (DEFTEST WEAK-HASH-TABLE.4 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/weak-hash-tables-TMP.abcl (0.147 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/zip.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST ZIP.1 ...) ; (IF (NOT #) ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/zip-TMP.abcl (0.075 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/java.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFTEST JAVA.TRUTH.1 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/java-TMP.abcl (0.037 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/runtime-class.lisp ... ; (IN-PACKAGE :ABCL.TEST.LISP) ; (DEFTEST RUNTIME-CLASS.1 ...) ; (DEFTEST RUNTIME-CLASS.2 ...) ; (DEFTEST RUNTIME-CLASS.3 ...) ; (DEFTEST RUNTIME-CLASS.4 ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/runtime-class-TMP.abcl (0.112 seconds) ; Compiling /usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/package-local-nicknames-tests.lisp ... ; (IN-PACKAGE #:ABCL.TEST.LISP) ; (DEFMACRO WITH-TMP-PACKAGES ...) ; (DEFPACKAGE :PACKAGE-LOCAL-NICKNAMES-TEST-1 ...) ; (DEFPACKAGE :PACKAGE-LOCAL-NICKNAMES-TEST-2 ...) ; (DEFTEST PLN-INTROSPECT ...) ; (DEFTEST PLN-USAGE ...) ; (DEFTEST PLN-ADD-NICKNAME-TWICE ...) ; (DEFTEST PLN-ADD-SAME-NICKNAME ...) ; (DEFTEST PLN-REMOVE-LOCAL-NICKNAME ...) ; (DEFTEST PLN-DELETE-LOCALLY-NICKNAMING-PACKAGE ...) ; (DEFTEST PLN-DELETE-LOCALLY-NICKNAMED-PACKAGE ...) ; (DEFTEST PLN-OWN-NAME-AS-LOCAL-NICKNAME ...) ; (DEFTEST PLN-OWN-NICKNAME-AS-LOCAL-NICKNAME ...) ; Wrote /home/zmyrgel/.cache/common-lisp/abcl-1.3.2-fasl42-bsd-x64/usr/ports/pobj/abcl-1.3.2/abcl-src-1.3.2/test/lisp/abcl/package-local-nicknames-tests-TMP.abcl (0.24 seconds) Doing 601 pending tests of 601 tests total. Test ABCL.TEST.LISP::UNUSED.1 failed Form: (LET ((ABCL.TEST.LISP::OUTPUT (WITH-OUTPUT-TO-STRING (*ERROR-OUTPUT*) (COMPILE NIL (QUOTE (LAMBDA NIL (LET ((ABCL.TEST.LISP::X 42)) 17))))))) (INTEGERP (SEARCH "The variable X is defined but never used." ABCL.TEST.LISP::OUTPUT))) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::UNUSED.2 failed Form: (PROGN (FMAKUNBOUND (QUOTE ABCL.TEST.LISP::UNUSED.2)) (DEFUN ABCL.TEST.LISP::UNUSED.2 NIL (LET ((ABCL.TEST.LISP::X 42)) 17)) (VALUES (MULTIPLE-VALUE-LIST (COMPILE (QUOTE ABCL.TEST.LISP::UNUSED.2))) (ABCL.TEST.LISP::UNUSED.2))) Expected values: (ABCL.TEST.LISP::UNUSED.2 NIL NIL) 17 Actual values: (ABCL.TEST.LISP::UNUSED.2 T T) 17. ABCL.TEST.LISP::PLUS.1 ABCL.TEST.LISP::PLUS.2 ABCL.TEST.LISP::PLUS.3 ABCL.TEST.LISP::PLUS.4 ABCL.TEST.LISP::MINUS.1 ABCL.TEST.LISP::MINUS.2 ABCL.TEST.LISP::MINUS.3 ABCL.TEST.LISP::LOGXOR-MINUS.1 ABCL.TEST.LISP::TIMES.1 ABCL.TEST.LISP::TIMES.2 ABCL.TEST.LISP::TIMES.3 ABCL.TEST.LISP::DOTIMES.1 ABCL.TEST.LISP::DOTIMES.2 ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.1 Test ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.2 failed Form: (LET ((TYPE (JVM:DERIVE-COMPILER-TYPE (QUOTE (LOGXOR 441516657 (THE (INTEGER 0 8589934588) ABCL.TEST.LISP::X)))))) (AND (SYSTEM:INTEGER-TYPE-P TYPE) (VALUES (SYSTEM:INTEGER-TYPE-LOW TYPE) (SYSTEM:INTEGER-TYPE-HIGH TYPE)))) Expected values: 0 8589934588 Actual values: 0 8589934591. Test ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.3 failed Form: (LET ((TYPE (JVM:DERIVE-COMPILER-TYPE (QUOTE (LOGXOR 441516657 (THE (INTEGER 0 8589934588) ABCL.TEST.LISP::X) (ASH (THE (INTEGER 0 8589934588) ABCL.TEST.LISP::X) -5)))))) (AND (SYSTEM:INTEGER-TYPE-P TYPE) (VALUES (SYSTEM:INTEGER-TYPE-LOW TYPE) (SYSTEM:INTEGER-TYPE-HIGH TYPE)))) Expected values: 0 8589934588 Actual values: 0 8589934591. ABCL.TEST.LISP::ASH.1 ABCL.TEST.LISP::BIGNUM-CONSTANT.1 ABCL.TEST.LISP::BIGNUM-CONSTANT.2 ABCL.TEST.LISP::BIGNUM-CONSTANT.3 ABCL.TEST.LISP::BIGNUM-CONSTANT.4 ABCL.TEST.LISP::SHIFTF.1 ABCL.TEST.LISP::LOGAND-VALUES.1 ABCL.TEST.LISP::LOGAND-LOGNOT.1 ABCL.TEST.LISP::LOGIOR-LOGAND-SETF.1 ABCL.TEST.LISP::LOGXOR.1 ABCL.TEST.LISP::MIN.1 ABCL.TEST.LISP::MIN.2 ABCL.TEST.LISP::MIN.3 ABCL.TEST.LISP::MIN.4 ABCL.TEST.LISP::MAX.1 ABCL.TEST.LISP::MAX.2 ABCL.TEST.LISP::MAX.3 ABCL.TEST.LISP::MAX.4; Compiling /tmp/abcl6890959790817241702.tmp ... ; (IN-PACKAGE :CL-USER) ; (SETF *PRINT-CASE* ...) ; (defstruct abcl.test.lisp::rec ...) ; Wrote /tmp/abcl6890959790817241702.abcl (0.224 seconds) ABCL.TEST.LISP::COMPILER.1; Compiling /tmp/abcl4461440705850230568.tmp ... ; (DEFCONSTANT A ...) ; Wrote /tmp/abcl4461440705850230568.abcl (0.016 seconds) ABCL.TEST.LISP::COMPILER.2 ABCL.TEST.LISP::COMPILER.3 ABCL.TEST.LISP::COMPILER.4A ABCL.TEST.LISP::COMPILER.4B ABCL.TEST.LISP::CONDITION.1 ABCL.TEST.LISP::CONDITION.2 ABCL.TEST.LISP::CONDITION.3 ABCL.TEST.LISP::PRINT-NOT-READABLE-OBJECT.1 ABCL.TEST.LISP::PRINT-NOT-READABLE-OBJECT.2 ABCL.TEST.LISP::TYPE-ERROR.1 ABCL.TEST.LISP::TYPE-ERROR.2 ABCL.TEST.LISP::TYPE-ERROR.3 ABCL.TEST.LISP::TYPE-ERROR.4 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.1 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.2 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.3 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.4 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.5 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.6 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.7 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.8 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.9 ABCL.TEST.LISP::SIMPLE-TYPE-ERROR.10 ABCL.TEST.LISP::DEFINE-CONDITION.1 ABCL.TEST.LISP::DEFINE-CONDITION.2 ABCL.TEST.LISP::DEFINE-CONDITION.3 ABCL.TEST.LISP::DEFINE-CONDITION.4 ABCL.TEST.LISP::DEFINE-CONDITION.5 ABCL.TEST.LISP::DEFINE-CONDITION.6 ABCL.TEST.LISP::DEFINE-CONDITION.7 ABCL.TEST.LISP::DEFINE-CONDITION.8 ABCL.TEST.LISP::DEFINE-CONDITION.9 ABCL.TEST.LISP::DEFINE-CONDITION.10 ABCL.TEST.LISP::FIELDTYPE.1A ABCL.TEST.LISP::FIELDTYPE.1B ABCL.TEST.LISP::FIELDTYPE.1C ABCL.TEST.LISP::FIELDTYPE.1D ABCL.TEST.LISP::FIELDTYPE.1E ABCL.TEST.LISP::FIELDTYPE.1F ABCL.TEST.LISP::FIELDTYPE.1G ABCL.TEST.LISP::FIELDTYPE.1H ABCL.TEST.LISP::FIELDTYPE.1I ABCL.TEST.LISP::FIELDTYPE.1J ABCL.TEST.LISP::FIELDTYPE.2 ABCL.TEST.LISP::FIELDREF.1A ABCL.TEST.LISP::FIELDREF.1B ABCL.TEST.LISP::FIELDREF.1C ABCL.TEST.LISP::FIELDREF.1D ABCL.TEST.LISP::FIELDREF.1E ABCL.TEST.LISP::FIELDREF.1F ABCL.TEST.LISP::FIELDREF.1G ABCL.TEST.LISP::FIELDREF.1H ABCL.TEST.LISP::FIELDREF.1I ABCL.TEST.LISP::FIELDREF.1J ABCL.TEST.LISP::FIELDREF.2 ABCL.TEST.LISP::DESCRIPTOR.1 ABCL.TEST.LISP::DESCRIPTOR.2 ABCL.TEST.LISP::MAP-FLAGS.1 ABCL.TEST.LISP::POOL.1 ABCL.TEST.LISP::MAKE-CLASS-FILE.1 ABCL.TEST.LISP::FINALIZE-CLASS-FILE.1 ABCL.TEST.LISP::GENERATE-METHOD.1 ABCL.TEST.LISP::GENERATE-METHOD.2 ABCL.TEST.LISP::GENERATE-METHOD.3 ABCL.TEST.LISP::GENERATE-METHOD.4 ABCL.TEST.LISP::GENERATE-METHOD.5 ABCL.TEST.LISP::WITH-CODE-TO-METHOD.1 Test ABCL.TEST.LISP::WITH-CODE-TO-METHOD.2 failed Form: (LET* ((CLASS (JVM::MAKE-JVM-CLASS-NAME "org/armedbear/lisp/gm_7")) (ABCL.TEST.LISP::FILE (JVM::MAKE-CLASS-FILE CLASS JVM::+LISP-OBJECT+ (QUOTE (:PUBLIC)))) (ABCL.TEST.LISP::METHOD1 (JVM::MAKE-JVM-METHOD :STATIC-INITIALIZER :VOID NIL :FLAGS (QUOTE (:STATIC)))) (ABCL.TEST.LISP::METHOD2 (JVM::MAKE-JVM-METHOD "method2" :VOID NIL)) (ABCL.TEST.LISP::REGISTERS NIL)) (JVM::CLASS-ADD-METHOD ABCL.TEST.LISP::FILE ABCL.TEST.LISP::METHOD1) (JVM::CLASS-ADD-METHOD ABCL.TEST.LISP::FILE ABCL.TEST.LISP::METHOD2) (JVM::WITH-CODE-TO-METHOD (ABCL.TEST.LISP::FILE ABCL.TEST.LISP::METHOD1) (JVM::ALLOCATE-REGISTER :INT) (PUSH JVM::*REGISTER* ABCL.TEST.LISP::REGISTERS) (JVM::WITH-CODE-TO-METHOD (ABCL.TEST.LISP::FILE ABCL.TEST.LISP::METHOD2) (JVM::ALLOCATE-REGISTER :INT) (PUSH JVM::*REGISTER* ABCL.TEST.LISP::REGISTERS) (JVM::WITH-CODE-TO-METHOD (ABCL.TEST.LISP::FILE ABCL.TEST.LISP::METHOD1) (JVM::ALLOCATE-REGISTER :INT) (PUSH JVM::*REGISTER* ABCL.TEST.LISP::REGISTERS)) (JVM::ALLOCATE-REGISTER :INT) (PUSH JVM::*REGISTER* ABCL.TEST.LISP::REGISTERS)) (JVM::ALLOCATE-REGISTER :INT) (PUSH JVM::*REGISTER* ABCL.TEST.LISP::REGISTERS) (JVM::EMIT (QUOTE RETURN))) (JVM::FINALIZE-CLASS-FILE ABCL.TEST.LISP::FILE) (NREVERSE ABCL.TEST.LISP::REGISTERS)) Expected value: (1 1 2 2 3) Actual value: #<SIMPLE-ERROR {12241DE8}>. ABCL.TEST.LISP::TESTCLASS1.INSTANTIATE ABCL.TEST.LISP::TESTCLASS2.INSTANTIATE ABCL.TEST.LISP::TESTCLASS3.INSTANTIATE ABCL.TEST.LISP::TESTCLASS1.CLASS-OF ABCL.TEST.LISP::TESTCLASS1.METACLASS-OF ABCL.TEST.LISP::TESTCLASS3.METACLASS-OF ABCL.TEST.LISP::STANDARD-CLASS.TYPEP.CLASS ABCL.TEST.LISP::STANDARD-CLASS.TYPEP.STANDARD-CLASS ABCL.TEST.LISP::METACLASS1.TYPEP.CLASS ABCL.TEST.LISP::METACLASS1.TYPEP.STANDARD-CLASS ABCL.TEST.LISP::TESTCLASS3.CLASS-OF.TYPEP ABCL.TEST.LISP::TESTCLASS3.METACLASS-OF.TYPEP ABCL.TEST.LISP::TESTCLASS4.INIT-NOARGS ABCL.TEST.LISP::TESTCLASS4.INITARGS ABCL.TEST.LISP::TESTCLASS5.INIT-NOARGS ABCL.TEST.LISP::TESTCLASS5.INITARGS ABCL.TEST.LISP::TESTCLASS6.1 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.1 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.2 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.3 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.4 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.5 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.6 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.7 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.FOO.8 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.1 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.1A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.1B ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.1C ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.2 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.2A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.3 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.3A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.4 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.4A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.5 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAR.5A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.1 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.1A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.1B ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.1C ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.2 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.3 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.4 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.BAZ.5 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.1 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.1A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.2 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.2A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.3 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.3A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.4 ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.4A ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.4B ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.4C ABCL.TEST.LISP::COMPUTE-APPLICABLE-METHODS.QUUX.5 ABCL.TEST.LISP::DMC-RETURN.1 ABCL.TEST.LISP::DMC-RETURN.2 ABCL.TEST.LISP::DMC-RETURN.3 ABCL.TEST.LISP::DMC-TEST-MC.1 ABCL.TEST.LISP::DMC-TEST-MC.2A ABCL.TEST.LISP::DMC-TEST-MC.2B ABCL.TEST.LISP::DMC-TEST-MC.3A ABCL.TEST.LISP::DMC-TEST-MC.3B ABCL.TEST.LISP::DMC-TEST.4A ABCL.TEST.LISP::DMC-TEST.4B ABCL.TEST.LISP::DMC-TEST.5A ABCL.TEST.LISP::DMC-TEST-MC.6A ABCL.TEST.LISP::DMC-TEST-MC.7A ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.1 ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.2 ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.3A ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.3B ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.3C ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.3D ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.4 ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-WHOLE.5 ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.1A ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.1B (PROGN (CALL-METHOD #<STANDARD-METHOD ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.2 (T) {4F4E6E53}>) #:G9382) ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.2A ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.2B (PROGN (CALL-METHOD #<STANDARD-METHOD ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.3 (T) {262D33D2}>) NIL) ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.3 ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.4A ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.4B ABCL.TEST.LISP::DMC-TEST-ARGS-WITH-OPTIONAL.4C ABCL.TEST.LISP::RUN-SHELL-COMMAND.1 ABCL.TEST.LISP::RUN-SHELL-COMMAND.2 ABCL.TEST.LISP::PROBE-FILE.1 ABCL.TEST.LISP::PROBE-FILE.2 ABCL.TEST.LISP::PROBE-FILE.3 ABCL.TEST.LISP::PROBE-FILE.4 ABCL.TEST.LISP::PROBE-FILE.5 ABCL.TEST.LISP::TRUENAME.1 ABCL.TEST.LISP::TRUENAME.2 ABCL.TEST.LISP::DIRECTORY.1 ABCL.TEST.LISP::DIRECTORY.2 Test ABCL.TEST.LISP::DIRECTORY.3 failed Form: (LET ((ABCL.TEST.LISP::DIRECTORY-PATHNAME (ABCL.TEST.LISP:MAKE-TEMPORARY-DIRECTORY ABCL.TEST.LISP::*THIS-DIRECTORY*))) (UNWIND-PROTECT (LET ((ABCL.TEST.LISP::FILE-PATHNAME (MAKE-PATHNAME :NAME "foo" :DEFAULTS ABCL.TEST.LISP::DIRECTORY-PATHNAME))) (ABCL.TEST.LISP:TOUCH ABCL.TEST.LISP::FILE-PATHNAME) (LET ((DIRECTORY (DIRECTORY (MAKE-PATHNAME :NAME :WILD :DEFAULTS ABCL.TEST.LISP::DIRECTORY-PATHNAME)))) (AND (LISTP DIRECTORY) (= (LENGTH DIRECTORY) 1) (ABCL.TEST.LISP:PATHNAMES-EQUAL-P (CAR DIRECTORY) ABCL.TEST.LISP::FILE-PATHNAME)))) (ABCL.TEST.LISP:DELETE-DIRECTORY-AND-FILES ABCL.TEST.LISP::DIRECTORY-PATHNAME))) Expected value: T Actual value: NIL. ABCL.TEST.LISP::DIRECTORY.4 ABCL.TEST.LISP::SYMLINK.1 ABCL.TEST.LISP::SYMLINK.2 ABCL.TEST.LISP::USER-HOMEDIR-PATHNAME.1 ABCL.TEST.LISP::FILE-SYSTEM.DIRECTORY-NAMESTRING.1 ABCL.TEST.LISP::FILE.SYSTEM.DIRECTORY-NAMESTRING.2 ABCL.TEST.LISP::ENSURE-DIRECTORIES-EXIST.1 ABCL.TEST.LISP::ENSURE-DIRECTORIES-EXIST.2 ABCL.TEST.LISP::ENSURE-DIRECTORIES-EXIST.3 ABCL.TEST.LISP::EQUAL.1 ABCL.TEST.LISP::EQUAL.2 ABCL.TEST.LISP::SXHASH.1 ABCL.TEST.LISP::SXHASH.2 ABCL.TEST.LISP::SXHASH.3 ABCL.TEST.LISP::PHYSICAL.1 ABCL.TEST.LISP::PHYSICAL.2 ABCL.TEST.LISP::PHYSICAL.3 ABCL.TEST.LISP::PHYSICAL.4 ABCL.TEST.LISP::PHYSICAL.5 ABCL.TEST.LISP::PHYSICAL.6 ABCL.TEST.LISP::PHYSICAL.7 ABCL.TEST.LISP::PHYSICAL.8 ABCL.TEST.LISP::PHYSICAL.9 ABCL.TEST.LISP::PHYSICAL.10 ABCL.TEST.LISP::PHYSICAL.11 ABCL.TEST.LISP::PHYSICAL.12 ABCL.TEST.LISP::PHYSICAL.13 ABCL.TEST.LISP::PHYSICAL.14 ABCL.TEST.LISP::PHYSICAL.15 ABCL.TEST.LISP::PHYSICAL.18 ABCL.TEST.LISP::PHYSICAL.19 ABCL.TEST.LISP::PHYSICAL.20 Test ABCL.TEST.LISP::PHYSICAL.21 failed Form: (ABCL.TEST.LISP::CHECK-READABLE (MAKE-PATHNAME :NAME ".")) Expected value: T Actual value: #<PRINT-NOT-READABLE {169EA92F}>. ABCL.TEST.LISP::PHYSICAL.22 ABCL.TEST.LISP::NAMESTRING.1 ABCL.TEST.LISP::PHYSICAL.23 ABCL.TEST.LISP::PHYSICAL.24 ABCL.TEST.LISP::NAMESTRING.2 ABCL.TEST.LISP::DIRECTORY-NAMESTRING.1 ABCL.TEST.LISP::PHYSICAL.25 ABCL.TEST.LISP::PHYSICAL.26 Test ABCL.TEST.LISP::PHYSICAL.27 failed Form: (ABCL.TEST.LISP::CHECK-READABLE (MAKE-PATHNAME :NAME "..")) Expected value: T Actual value: #<PRINT-NOT-READABLE {A755843}>. ABCL.TEST.LISP::PHYSICAL.28 ABCL.TEST.LISP::NAMESTRING.3 ABCL.TEST.LISP::PHYSICAL.29 ABCL.TEST.LISP::NAMESTRING.4 ABCL.TEST.LISP::DIRECTORY-NAMESTRING.2 ABCL.TEST.LISP::PHYSICAL.30 ABCL.TEST.LISP::PHYSICAL.31 ABCL.TEST.LISP::WILD.1 ABCL.TEST.LISP::WILD.2 ABCL.TEST.LISP::WILD.3 ABCL.TEST.LISP::WILD.4 ABCL.TEST.LISP::WILD.5 ABCL.TEST.LISP::LOTS-OF-DOTS.1 ABCL.TEST.LISP::LOTS-OF-DOTS.2 ABCL.TEST.LISP::SILLY.1 ABCL.TEST.LISP::SILLY.2 ABCL.TEST.LISP::SILLY.3 ABCL.TEST.LISP::SILLY.4 Test ABCL.TEST.LISP::SILLY.5 failed Form: (ABCL.TEST.LISP::CHECK-READABLE-OR-SIGNALS-ERROR (MAKE-PATHNAME :NAME "abc.def")) Expected value: T Actual value: NIL. ABCL.TEST.LISP::SILLY.6 ABCL.TEST.LISP::LOGICAL-PATHNAME-TRANSLATIONS.1 ABCL.TEST.LISP::LOGICAL-PATHNAME.1 ABCL.TEST.LISP::LOGICAL-PATHNAME.2 ABCL.TEST.LISP::LOGICAL.1 ABCL.TEST.LISP::LOGICAL.3 ABCL.TEST.LISP::LOGICAL.4 ABCL.TEST.LISP::LOGICAL.5 ABCL.TEST.LISP::LOGICAL.8 ABCL.TEST.LISP::LOGICAL.9 ABCL.TEST.LISP::LOGICAL.10 ABCL.TEST.LISP::LOGICAL.11 ABCL.TEST.LISP::LOGICAL.12 ABCL.TEST.LISP::LOGICAL.13 ABCL.TEST.LISP::LOGICAL.14 ABCL.TEST.LISP::LOGICAL.15 ABCL.TEST.LISP::LOGICAL.16 ABCL.TEST.LISP::LOGICAL.17 ABCL.TEST.LISP::LOGICAL.18 ABCL.TEST.LISP::LOGICAL.19 ABCL.TEST.LISP::LOGICAL.20 ABCL.TEST.LISP::LOGICAL.21 ABCL.TEST.LISP::LOGICAL.22 ABCL.TEST.LISP::LOGICAL.23 ABCL.TEST.LISP::PARSE-NAMESTRING.1 ABCL.TEST.LISP::PARSE-NAMESTRING.2 ABCL.TEST.LISP::PARSE-NAMESTRING.3 ABCL.TEST.LISP::PARSE-NAMESTRING.4 ABCL.TEST.LISP::PARSE-NAMESTRING.5 ABCL.TEST.LISP::PARSE-NAMESTRING.6 ABCL.TEST.LISP::PARSE-NAMESTRING.7 ABCL.TEST.LISP::PARSE-NAMESTRING.8 ABCL.TEST.LISP::WILD-PATHNAME-P.1 ABCL.TEST.LISP::PATHNAME-MATCH-P.1 ABCL.TEST.LISP::PATHNAME-MATCH-P.2 ABCL.TEST.LISP::PATHNAME-MATCH-P.3 ABCL.TEST.LISP::PATHNAME-MATCH-P.4 ABCL.TEST.LISP::PATHNAME-MATCH-P.5 ABCL.TEST.LISP::PATHNAME-MATCH-P.6 ABCL.TEST.LISP::PATHNAME-MATCH-P.7 ABCL.TEST.LISP::PATHNAME-MATCH-P.8 ABCL.TEST.LISP::PATHNAME-MATCH-P.9 ABCL.TEST.LISP::PATHNAME-MATCH-P.10 ABCL.TEST.LISP::TRANSLATE-PATHNAME.1 ABCL.TEST.LISP::TRANSLATE-PATHNAME.2 ABCL.TEST.LISP::TRANSLATE-PATHNAME.3 ABCL.TEST.LISP::TRANSLATE-PATHNAME.4 ABCL.TEST.LISP::TRANSLATE-PATHNAME.5 ABCL.TEST.LISP::TRANSLATE-PATHNAME.6 ABCL.TEST.LISP::TRANSLATE-PATHNAME.7 ABCL.TEST.LISP::TRANSLATE-PATHNAME.8 ABCL.TEST.LISP::TRANSLATE-PATHNAME.9 ABCL.TEST.LISP::TRANSLATE-PATHNAME.10 ABCL.TEST.LISP::TRANSLATE-PATHNAME.11 ABCL.TEST.LISP::TRANSLATE-PATHNAME.12 ABCL.TEST.LISP::TRANSLATE-PATHNAME.13 ABCL.TEST.LISP::TRANSLATE-PATHNAME.14 ABCL.TEST.LISP::TRANSLATE-PATHNAME.15 ABCL.TEST.LISP::TRANSLATE-PATHNAME.16 ABCL.TEST.LISP::TRANSLATE-PATHNAME.17 ABCL.TEST.LISP::PATHNAME-MATCH-P.11 ABCL.TEST.LISP::TRANSLATE-PATHNAME.18 ABCL.TEST.LISP::PATHNAME-MATCH-P.12 ABCL.TEST.LISP::TRANSLATE-PATHNAME.19 ABCL.TEST.LISP::TRANSLATE-PATHNAME.20 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.1 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.2 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.4 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.5 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.6 ABCL.TEST.LISP::TRANSLATE-LOGICAL-PATHNAME.7 ABCL.TEST.LISP::MERGE-PATHNAMES.1 ABCL.TEST.LISP::MERGE-PATHNAMES.2 ABCL.TEST.LISP::COMPILE-FILE-PATHNAME.1 ABCL.TEST.LISP::FILE-NAMESTRING.1 ABCL.TEST.LISP::FILE-NAMESTRING.2 ABCL.TEST.LISP::FILE-NAMESTRING.3 ABCL.TEST.LISP::FILE-NAMESTRING.4 ABCL.TEST.LISP::ENOUGH-NAMESTRING.1 ABCL.TEST.LISP::ENOUGH-NAMESTRING.2 ABCL.TEST.LISP::ENOUGH-NAMESTRING.3 ABCL.TEST.LISP::SBCL.1 ABCL.TEST.LISP::SBCL.2 ABCL.TEST.LISP::SBCL.3 ABCL.TEST.LISP::SBCL.4 ABCL.TEST.LISP::SBCL.5 ABCL.TEST.LISP::SBCL.8 ABCL.TEST.LISP::SBCL.9 ABCL.TEST.LISP::SBCL.10 ABCL.TEST.LISP::SBCL.11 ABCL.TEST.LISP::SBCL.12 ABCL.TEST.LISP::SBCL.13 ABCL.TEST.LISP::SBCL.14 ABCL.TEST.LISP::SBCL.15 ABCL.TEST.LISP::SBCL.16 ABCL.TEST.LISP::SBCL.17 ABCL.TEST.LISP::SBCL.18 ABCL.TEST.LISP::SBCL.19 ABCL.TEST.LISP::SBCL.20 ABCL.TEST.LISP::SBCL.21 ABCL.TEST.LISP::SBCL.22 ABCL.TEST.LISP::SBCL.23 ABCL.TEST.LISP::SBCL.24 ABCL.TEST.LISP::SBCL.25 ABCL.TEST.LISP::SBCL.26 ABCL.TEST.LISP::SBCL.27 ABCL.TEST.LISP::SBCL.28 ABCL.TEST.LISP::SBCL.29 ABCL.TEST.LISP::SBCL.30 ABCL.TEST.LISP::SBCL.31 ABCL.TEST.LISP::SBCL.32 ABCL.TEST.LISP::SBCL.33 Test ABCL.TEST.LISP::SBCL.34 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES #P"scratch:;name2" #P"scratch:foo;" #P"SCRATCH:FOO;NAME2") Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.35 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES #P"scratch:;foo" #P"/usr/local/doc/" #P"SCRATCH:USR;LOCAL;DOC;FOO") Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.36 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES #P"scratch:supplied-dir;" #P"/dir/name.type" #P"SCRATCH:SUPPLIED-DIR;NAME.TYPE") Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.37 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES #P"scratch:;supplied-name" #P"/dir/name.type" #P"SCRATCH:DIR;SUPPLIED-NAME.TYPE") Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.38 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES (MAKE-PATHNAME :HOST "scratch" :TYPE "supplied-type") #P"/dir/name.type" #P"SCRATCH:DIR;NAME.SUPPLIED-TYPE") Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.39 failed Form: (LET ((PATHNAME (MAKE-PATHNAME :HOST "scratch" :DIRECTORY (QUOTE (:RELATIVE "foo")) :NAME "bar")) (ABCL.TEST.LISP::DEFAULT-PATHNAME #P"/aaa/bbb/ccc/ddd/eee")) (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES PATHNAME ABCL.TEST.LISP::DEFAULT-PATHNAME #P"SCRATCH:AAA;BBB;CCC;DDD;FOO;BAR")) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.40 failed Form: (LET ((PATHNAME (MAKE-PATHNAME :HOST "scratch" :DIRECTORY (QUOTE (:RELATIVE :BACK "foo")) :NAME "bar")) (ABCL.TEST.LISP::DEFAULT-PATHNAME #P"/aaa/bbb/ccc/ddd/eee")) (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES PATHNAME ABCL.TEST.LISP::DEFAULT-PATHNAME #P"SCRATCH:AAA;BBB;CCC;FOO;BAR")) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::SBCL.41 failed Form: (ABCL.TEST.LISP::CHECK-MERGE-PATHNAMES #P"scratch:absolute;path;name" #P"/dir/default-name.type" #P"SCRATCH:ABSOLUTE;PATH;NAME.TYPE") Expected value: T Actual value: NIL. ABCL.TEST.LISP::SBCL.42 Test ABCL.TEST.LISP::SBCL.43 failed Form: (STRING= (NAMESTRING (PARSE-NAMESTRING "FOO" (HOST-NAMESTRING #P"SCRATCH:BAR"))) "SCRATCH:FOO") Expected value: T Actual value: NIL. ABCL.TEST.LISP::SBCL.44 ABCL.TEST.LISP::SBCL.45 ABCL.TEST.LISP::SBCL.46 ABCL.TEST.LISP::SBCL.47 ABCL.TEST.LISP::SBCL.48 ABCL.TEST.LISP::SBCL.49 ABCL.TEST.LISP::SBCL.50 ABCL.TEST.LISP::SBCL.51 ABCL.TEST.LISP::SBCL.52 ABCL.TEST.LISP::SBCL.53 ABCL.TEST.LISP::SBCL.54 ABCL.TEST.LISP::SBCL.55 ABCL.TEST.LISP::SBCL.56 ABCL.TEST.LISP::SBCL.57 ABCL.TEST.LISP::SBCL.58 ABCL.TEST.LISP::SBCL.59 ABCL.TEST.LISP::SBCL.60 ABCL.TEST.LISP::SBCL.61 ABCL.TEST.LISP::SBCL.62 ABCL.TEST.LISP::MAKE-PATHNAME.1 ABCL.TEST.LISP::PATHNAME.URI-ENCODING.1 ABCL.TEST.LISP::PATHNAME.URI-ENCODING.2 ABCL.TEST.LISP::PATHNAME.LOAD.1 ABCL.TEST.LISP::PATHNAME.LOAD.2 ABCL.TEST.LISP::PATHNAME.MAKE-PATHNAME.1 ABCL.TEST.LISP::PATHNAME.MAKE-PATHNAME.2 Using /tmp/jar-pathname-tests/ to create files for testing jar-pathnames. ; Compiling /tmp/jar-pathname-tests/foo.lisp ... ; (LABELS (#) ...) ; Wrote /tmp/jar-pathname-tests/foo.abcl (0.081 seconds) ; Compiling /tmp/jar-pathname-tests/foo bar.lisp ... ; (LABELS (#) ...) ; Wrote /tmp/jar-pathname-tests/foo bar.abcl (0.101 seconds) ; Compiling /tmp/jar-pathname-tests/bar.lisp ... ; (DEFVAR ABCL.TEST.LISP::*PATHNAME* ...) ; (DEFVAR ABCL.TEST.LISP::*TRUENAME* ...) ; (DEFUN ABCL.TEST.LISP::BAR ...) ; (DEFVAR ABCL.TEST.LISP::*BAR* ...) ; (DEFUN ABCL.TEST.LISP::BAZ ...) ; Wrote /tmp/jar-pathname-tests/bar.abcl (0.161 seconds) ; Compiling /tmp/jar-pathname-tests/eek.lisp ... ; (DEFUN ABCL.TEST.LISP::EEK ...) ; (DEFUN ABCL.TEST.LISP::OOK ...) ; (DEFUN ABCL.TEST.LISP::AAK ...) ; Wrote /tmp/jar-pathname-tests/eek.abcl (0.157 seconds) Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.INIT failed Form: (ABCL.TEST.LISP::WITH-JAR-FILE-INIT NIL) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.1 failed Form: (ABCL.TEST.LISP::LOAD-FROM-JAR ABCL.TEST.LISP::*TMP-JAR-PATH* "foo") Expected value: T Actual value: #<FILE-ERROR {110CD084}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.2 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.3 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.4 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.5 Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.6 failed Form: (ABCL.TEST.LISP::LOAD-FROM-JAR ABCL.TEST.LISP::*TMP-JAR-PATH* "foo") Expected value: T Actual value: #<FILE-ERROR {74924258}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.7 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.8 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.9 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.10 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.11FOO here. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.12 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.13 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.14 ABCL.TEST.LISP::JAR-PATHNAME.LOAD.15FOO here. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.16 Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.1 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "foo") Expected value: T Actual value: #<TYPE-ERROR {4E90DC4}>. Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.2 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "bar") Expected value: T Actual value: #<TYPE-ERROR {5C07BBAC}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.3 Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.4 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "eek") Expected value: T Actual value: #<TYPE-ERROR {113B7AF6}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.5 Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.6 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "a/b/foo") Expected value: T Actual value: #<TYPE-ERROR {7339953F}>. Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.7 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "a/b/bar") Expected value: T Actual value: #<TYPE-ERROR {49759632}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.8 Test ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.9 failed Form: (ABCL.TEST.LISP::LOAD-URL-RELATIVE "a/b/eek") Expected value: T Actual value: #<TYPE-ERROR {22966555}>. ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.10 ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.1 ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.2 Test ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.3 failed Form: (LET ((ABCL.TEST.LISP::RESULT (ABCL.TEST.LISP::WITH-JAR-FILE-INIT (PROBE-FILE "jar:jar:file:baz.jar!/a/b/bar.abcl!/bar._")))) (STRING= (IF ABCL.TEST.LISP::RESULT (NAMESTRING ABCL.TEST.LISP::RESULT) "") (FORMAT NIL "jar:jar:file:~Abaz.jar!/a/b/bar.abcl!/bar._" (NAMESTRING ABCL.TEST.LISP::*TMP-DIRECTORY*)))) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.4 failed Form: (LET ((ABCL.TEST.LISP::RESULT (ABCL.TEST.LISP::WITH-JAR-FILE-INIT (PROBE-FILE "jar:file:baz.jar!/a/b")))) (STRING= (IF ABCL.TEST.LISP::RESULT (NAMESTRING ABCL.TEST.LISP::RESULT) "") (FORMAT NIL "jar:file:~Abaz.jar!/a/b/" (NAMESTRING ABCL.TEST.LISP::*TMP-DIRECTORY*)))) Expected value: T Actual value: NIL. Test ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.5 failed Form: (LET ((ABCL.TEST.LISP::RESULT (ABCL.TEST.LISP::WITH-JAR-FILE-INIT (PROBE-FILE "jar:file:baz.jar!/a/b/")))) (STRING= (IF ABCL.TEST.LISP::RESULT (NAMESTRING ABCL.TEST.LISP::RESULT) "") (FORMAT NIL "jar:file:~Abaz.jar!/a/b/" (NAMESTRING ABCL.TEST.LISP::*TMP-DIRECTORY*)))) Expected value: T Actual value: NIL. ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.6 Test ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.1 failed Form: (MERGE-PATHNAMES "/bar.abcl" #P"jar:file:baz.jar!/foo") Expected value: #P"jar:file:baz.jar!/bar.abcl" Actual value: #P"/bar.abcl". ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.2 ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.3 ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.4 Test ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.5 failed Form: (MERGE-PATHNAMES "jar:file:/a/b/c/foo.jar!/bar/baz.lisp") Expected value: #P"jar:file:/a/b/c/foo.jar!/bar/baz.lisp" Actual value: #P"jar:file:/a/b/c/foo.jar!/bar/baz.lisp". ABCL.TEST.LISP::JAR-PATHNAME.TRUENAME.1 ABCL.TEST.LISP::JAR-PATHNAME.1 ABCL.TEST.LISP::JAR-PATHNAME.2 ABCL.TEST.LISP::JAR-PATHNAME.3 ABCL.TEST.LISP::JAR-PATHNAME.4 ABCL.TEST.LISP::JAR-PATHNAME.5 ABCL.TEST.LISP::JAR-PATHNAME.6 ABCL.TEST.LISP::JAR-PATHNAME.7 ABCL.TEST.LISP::JAR-PATHNAME.8 ABCL.TEST.LISP::JAR-PATHNAME.9 ABCL.TEST.LISP::JAR-PATHNAME.10 ABCL.TEST.LISP::JAR-PATHNAME.11 ABCL.TEST.LISP::JAR-PATHNAME.12 ABCL.TEST.LISP::JAR-PATHNAME.MATCH-P.1 ABCL.TEST.LISP::JAR-PATHNAME.MATCH-P.2 ABCL.TEST.LISP::JAR-PATHNAME.MATCH-P.3 ABCL.TEST.LISP::JAR-PATHNAME.TRANSLATE.1 ABCL.TEST.LISP::URL-PATHNAME.1 ABCL.TEST.LISP::URL-PATHNAME.2 ABCL.TEST.LISP::URL-PATHNAME.3 ABCL.TEST.LISP::MOST-NEGATIVE-FIXNUM.1 ABCL.TEST.LISP::MOST-NEGATIVE-FIXNUM.2 ABCL.TEST.LISP::FLOATING-POINT-MODES.1 ABCL.TEST.LISP::FLOATING-POINT-MODES.2 ABCL.TEST.LISP::FLOATING-POINT-MODES.3 ABCL.TEST.LISP::FLOATING-POINT-MODES.4 ABCL.TEST.LISP::SINGLE-FLOAT-EPSILON.1 ABCL.TEST.LISP::SINGLE-FLOAT-NEGATIVE-EPSILON.1 ABCL.TEST.LISP::MOST-POSITIVE-SINGLE-FLOAT.1 ABCL.TEST.LISP::MOST-POSITIVE-SINGLE-FLOAT.2 ABCL.TEST.LISP::LEAST-POSITIVE-SINGLE-FLOAT.1 ABCL.TEST.LISP::LEAST-POSITIVE-SINGLE-FLOAT.2 ABCL.TEST.LISP::SQRT.1 ABCL.TEST.LISP::SQRT.2 ABCL.TEST.LISP::SQRT.3 ABCL.TEST.LISP::SQRT.4 ABCL.TEST.LISP::SQRT.5 ABCL.TEST.LISP::SQRT.6 ABCL.TEST.LISP::SQRT.7 ABCL.TEST.LISP::SQRT.8 ABCL.TEST.LISP::SQRT.9 ABCL.TEST.LISP::SQRT.10 ABCL.TEST.LISP::SQRT.11 ABCL.TEST.LISP::SQRT.12 ABCL.TEST.LISP::SQRT.13 ABCL.TEST.LISP::SQRT.14 ABCL.TEST.LISP::EXP.1 ABCL.TEST.LISP::EXP.2 ABCL.TEST.LISP::EXP.3 ABCL.TEST.LISP::EXP.4 ABCL.TEST.LISP::EXP.5 ABCL.TEST.LISP::EXP.6 ABCL.TEST.LISP::EXP.7 ABCL.TEST.LISP::EXP.8 ABCL.TEST.LISP::EXP.9 ABCL.TEST.LISP::EXPT.1 ABCL.TEST.LISP::EXPT.2 ABCL.TEST.LISP::EXPT.3 ABCL.TEST.LISP::EXPT.4 Test ABCL.TEST.LISP::EXPT.5 failed Form: (EXPT -5.0d0 1.9d0) Expected value: #C(20.24180952239008d0 -6.576962601219341d0) Actual value: #C(20.241809522390078d0 -6.576962601219339d0). ABCL.TEST.LISP::EXPT.6 ABCL.TEST.LISP::EXPT.7 ABCL.TEST.LISP::EXPT.8 ABCL.TEST.LISP::EXPT.9 ABCL.TEST.LISP::EXPT.10 ABCL.TEST.LISP::EXPT.11 ABCL.TEST.LISP::EXPT.12 ABCL.TEST.LISP::EXPT.13 ABCL.TEST.LISP::EXPT.14 ABCL.TEST.LISP::EXPT.15 ABCL.TEST.LISP::EXPT.16 ABCL.TEST.LISP::EXPT.17 ABCL.TEST.LISP::EXPT.18 ABCL.TEST.LISP::EXPT.19 ABCL.TEST.LISP::EXPT.20 ABCL.TEST.LISP::EXPT.21 ABCL.TEST.LISP::EXPT.22 ABCL.TEST.LISP::EXPT.23 ABCL.TEST.LISP::EXPT.24 ABCL.TEST.LISP::EXPT.25 ABCL.TEST.LISP::EXPT.26 ABCL.TEST.LISP::LOG.1 ABCL.TEST.LISP::LOG.2 Test ABCL.TEST.LISP::LOG.3 failed Form: (LOG 17 10) Expected values: Actual value: 1.230449. Test ABCL.TEST.LISP::LOG.4 failed Form: (LOG 17.0 10.0) Expected values: Actual value: 1.230449. Test ABCL.TEST.LISP::LOG.5 failed Form: (LOG 17.0d0 10) Expected values: Actual value: 1.2304489213782739d0. Test ABCL.TEST.LISP::LOG.6 failed Form: (LOG 17 10.0d0) Expected values: Actual value: 1.2304489213782739d0. ABCL.TEST.LISP::LOG.7 ABCL.TEST.LISP::PI.1 ABCL.TEST.LISP::TAN.1 ABCL.TEST.LISP::TAN.2 ABCL.TEST.LISP::TAN.3 ABCL.TEST.LISP::TAN.4 ABCL.TEST.LISP::ATANH.1 ABCL.TEST.LISP::ATANH.2 ABCL.TEST.LISP::TRUNCATE.1 ABCL.TEST.LISP::TRUNCATE.2 ABCL.TEST.LISP::TRUNCATE.3 ABCL.TEST.LISP::TRUNCATE.4 Test ABCL.TEST.LISP::MATH.READ-FROM-STRING.1 failed Form: (ABCL-REGRESSION-TEST:SIGNALS-ERROR (READ-FROM-STRING "1.0f-1000") (QUOTE READER-ERROR)) Expected value: T Actual value: NIL. ABCL.TEST.LISP::MATH.LOGAND.1 ABCL.TEST.LISP::MISC.DOTIMES.1 ABCL.TEST.LISP::DOTIMES.1.COMPILED ABCL.TEST.LISP::MISC.DOTIMES.2 ABCL.TEST.LISP::DOTIMES.2.COMPILED ABCL.TEST.LISP::FUNCALL.1 ABCL.TEST.LISP::FUNCALL.2 ABCL.TEST.LISP::FUNCALL.3 ABCL.TEST.LISP::FUNCALL.4 ABCL.TEST.LISP::FUNCALL.5 ABCL.TEST.LISP::COPY-LIST.1 ABCL.TEST.LISP::READ-FROM-STRING.1 ABCL.TEST.LISP::READ-FROM-STRING.2 ABCL.TEST.LISP::TICKET.107 ABCL.TEST.LISP::NORMAL-UTF8.1 ABCL.TEST.LISP::LATIN1.1 ABCL.TEST.LISP::BUGS.LOGICAL-PATHNAME.1 ABCL.TEST.LISP::BUGS.LOGICAL-PATHNAME.2 ABCL.TEST.LISP::BUGS.PATHNAME.1 ABCL.TEST.LISP::BUGS.PATHNAME.2 ABCL.TEST.LISP::BUGS.PATHNAME.3 ABCL.TEST.LISP::BUGS.JAVA.1 ABCL.TEST.LISP::BUGS.READTABLE-CASE.1 Test ABCL.TEST.LISP::BUGS.PPRINT.1 failed Form: (LET ((ABCL.TEST.LISP::RESULT (MAKE-ARRAY (QUOTE (0)) :ELEMENT-TYPE (QUOTE BASE-CHAR) :FILL-POINTER T))) (WITH-OUTPUT-TO-STRING (ABCL.TEST.LISP::S ABCL.TEST.LISP::RESULT) (PPRINT-LOGICAL-BLOCK (ABCL.TEST.LISP::S NIL :PER-LINE-PREFIX "---") (FORMAT ABCL.TEST.LISP::S "~(~A~)" (QUOTE (1 2 3 4))))) ABCL.TEST.LISP::RESULT) Expected value: "---(1 2 3 4)" Actual value: "(1 2 3 4)---". ABCL.TEST.LISP::BUGS.DEFGENERIC.1 ABCL.TEST.LISP::BUGS.CLOS.AUX.1 Test ABCL.TEST.LISP::BUGS.PATHNAME.MAKE-PATHNAME.1 failed Form: (ABCL-REGRESSION-TEST:SIGNALS-ERROR (MAKE-PATHNAME :DEVICE (LIST "foo")) (QUOTE ERROR)) Expected value: T Actual value: NIL. ABCL.TEST.LISP::BUGS.PATHNAME.MAKE-PATHNAME.2 ABCL.TEST.LISP::BUGS.LOOP.1 Test ABCL.TEST.LISP::BUGS.READER.1 failed Form: (LET ((*READTABLE* *READTABLE*)) (SET-MACRO-CHARACTER #\? (LAMBDA (STREAM CHAR) (CODE-CHAR (READ STREAM NIL NIL T)))) (QUOTE (ABCL.TEST.LISP::A ABCL.TEST.LISP::.?0))) Expected value: (ABCL.TEST.LISP::A . #\Null) Actual value: (ABCL.TEST.LISP::A ABCL.TEST.LISP::.?0). ABCL.TEST.LISP::BUGS.EXPORT.1 ABCL.TEST.LISP::WILD-PATHNAMES.1 Test ABCL.TEST.LISP::WILD-PATHNAMES.2 failed Form: (EQUAL (FIRST (ABCL.TEST.LISP::WITH-TEST-DIRECTORIES (DIRECTORY (MAKE-PATHNAME :DIRECTORY (PATHNAME-DIRECTORY ABCL.TEST.LISP::*TEMP-DIRECTORY-ROOT*) :NAME :WILD :TYPE "ext" :VERSION :NEWEST)))) (MERGE-PATHNAMES ABCL.TEST.LISP::*TEMP-DIRECTORY-ROOT* "foo.ext")) Expected value: T Actual value: NIL. Previously 47049 entries, now 2038. ABCL.TEST.LISP::WEAK-HASH-TABLE.1 Previously 49425 entries, now 9277. ABCL.TEST.LISP::WEAK-HASH-TABLE.2 ABCL.TEST.LISP::WEAK-HASH-TABLE.3 ABCL.TEST.LISP::WEAK-HASH-TABLE.4 ABCL.TEST.LISP::ZIP.1 ABCL.TEST.LISP::JAVA.TRUTH.1 Test ABCL.TEST.LISP::RUNTIME-CLASS.1 failed Form: (JNEW-RUNTIME-CLASS "Actor" :FIELDS (QUOTE (("name" "java.lang.String"))) :METHODS (QUOTE (("getName" "java.lang.String" NIL (LAMBDA (ABCL.TEST.LISP::THIS) (JFIELD ABCL.TEST.LISP::THIS "name")))))) Expected value: T Actual value: #<JAVA-EXCEPTION java.lang.ClassNotFoundException: Function class not found: Actor {3B21E66C}>. Test ABCL.TEST.LISP::RUNTIME-CLASS.2 failed Form: (JNEW-RUNTIME-CLASS "Actor" :FIELDS (QUOTE (("name" "java.lang.String"))) :METHODS (QUOTE (("getName" "java.lang.String" (:INT) (LAMBDA (ABCL.TEST.LISP::THIS) (JFIELD ABCL.TEST.LISP::THIS "name")))))) Expected value: T Actual value: #<SIMPLE-ERROR {2E9EDAC8}>. java.lang.ClassFormatError: Duplicate method name&signature in class file Actor at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at org.armedbear.lisp.JavaClassLoader.defineLispClass(JavaClassLoader.java:186) at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:107) at org.armedbear.lisp.MemoryClassLoader.loadClass(MemoryClassLoader.java:77) at org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.armedbear.lisp.Java.jcall(Java.java:902) at org.armedbear.lisp.Java$pf_jcall.execute(Java.java:758) at org.armedbear.lisp.Primitive.execute(Primitive.java:135) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.runtime_class_1.execute(runtime-class.lisp:9) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:603) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_63.execute(rt.lisp:228) at org.armedbear.lisp.rt_TMP_62.execute(rt.lisp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.rt_TMP_74.execute(rt.lisp:368) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_73.execute(rt.lisp:355) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.package_TMP_1.execute(package.lisp:23) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Primitives$pf_funcall.execute(Primitives.java:2689) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:154) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1006.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_303.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1008.execute(asdf.lisp:8225) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1010.execute(asdf.lisp:8225) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1007.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1217.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1216.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.asdf_1215.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1214.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.asdf_1265.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1264.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1253.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1252.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1283.execute(asdf.lisp:9071) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:614) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:303) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:745) java.lang.StringIndexOutOfBoundsException: String index out of range: -10 at java.lang.String.substring(String.java:1875) at org.armedbear.lisp.JavaClassLoader.getFunctionClassBytes(JavaClassLoader.java:88) at org.armedbear.lisp.MemoryClassLoader.getFunctionClassBytes(MemoryClassLoader.java:119) at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:106) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at org.armedbear.lisp.MemoryClassLoader.loadClass(MemoryClassLoader.java:95) at org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at org.armedbear.lisp.JavaClassLoader.defineLispClass(JavaClassLoader.java:186) at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:107) at org.armedbear.lisp.MemoryClassLoader.loadClass(MemoryClassLoader.java:77) at org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.armedbear.lisp.Java.jcall(Java.java:902) at org.armedbear.lisp.Java$pf_jcall.execute(Java.java:758) at org.armedbear.lisp.Primitive.execute(Primitive.java:135) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.runtime_class_1.execute(runtime-class.lisp:9) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:603) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_63.execute(rt.lisp:228) at org.armedbear.lisp.rt_TMP_62.execute(rt.lisp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.rt_TMP_74.execute(rt.lisp:368) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_73.execute(rt.lisp:355) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.package_TMP_1.execute(package.lisp:23) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Primitives$pf_funcall.execute(Primitives.java:2689) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:154) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1006.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_303.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1008.execute(asdf.lisp:8225) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1010.execute(asdf.lisp:8225) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1007.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1217.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1216.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.asdf_1215.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1214.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.asdf_1265.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1264.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1253.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1252.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1283.execute(asdf.lisp:9071) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:614) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:303) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:745) java.lang.NoClassDefFoundError: foo/Actor at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at org.armedbear.lisp.JavaClassLoader.defineLispClass(JavaClassLoader.java:186) at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:107) at org.armedbear.lisp.MemoryClassLoader.loadClass(MemoryClassLoader.java:77) at org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.armedbear.lisp.Java.jcall(Java.java:902) at org.armedbear.lisp.Java$pf_jcall.execute(Java.java:758) at org.armedbear.lisp.Primitive.execute(Primitive.java:135) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.runtime_class_1.execute(runtime-class.lisp:9) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:603) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_63.execute(rt.lisp:228) at org.armedbear.lisp.rt_TMP_62.execute(rt.lisp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.rt_TMP_74.execute(rt.lisp:368) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.rt_TMP_73.execute(rt.lisp:355) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.package_TMP_1.execute(package.lisp:23) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Primitives$pf_funcall.execute(Primitives.java:2689) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:154) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1006.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_303.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1008.execute(asdf.lisp:8225) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1010.execute(asdf.lisp:8225) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) Test ABCL.TEST.LISP::RUNTIME-CLASS.3 failed at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) Form: (PROGN (JNEW-RUNTIME-CLASS "foo.Actor" :FIELDS (QUOTE (("name" "java.lang.String")))) (JNEW-RUNTIME-CLASS "foo.StageActor" :SUPERCLASS "foo.Actor" :FIELDS (LIST (QUOTE ("givenName" "java.lang.String"))))) at org.armedbear.lisp.asdf_1007.execute(asdf.lisp:8225) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) Expected value: T at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.clos_277.execute(clos.lisp:2301) Actual value: #<JAVA-EXCEPTION java.lang.ClassNotFoundException: Function class not found: foo.StageActor {3690923C}>. at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) Test ABCL.TEST.LISP::RUNTIME-CLASS.4 failed at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1217.execute(asdf.lisp:8880) Form: (JNEW-RUNTIME-CLASS "Actor" :CONSTRUCTORS (QUOTE (("java.lang.String") (LAMBDA (ABCL.TEST.LISP::NAME) (SETF (ABCL.TEST.LISP::JFIELD ABCL.TEST.LISP::THIS "name") ABCL.TEST.LISP::NAME)))) :METHODS (QUOTE (("getName" "java.lang.String" ("java.lang.String") (LAMBDA (ABCL.TEST.LISP::THIS ABCL.TEST.LISP::DUMMY) (DECLARE (IGNORE ABCL.TEST.LISP::DUMMY)) (JFIELD ABCL.TEST.LISP::THIS "name"))))) :FIELDS (QUOTE (("name" "java.lang.String")))) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) Expected value: T at org.armedbear.lisp.LispThread.execute(LispThread.java:814) Actual value: #<SIMPLE-ERROR {50057DB9}>. ABCL.TEST.LISP::PLN-INTROSPECT ABCL.TEST.LISP::PLN-USAGE at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ABCL.TEST.LISP::PLN-ADD-NICKNAME-TWICE at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1216.execute(asdf.lisp:8880) ABCL.TEST.LISP::PLN-ADD-SAME-NICKNAME ABCL.TEST.LISP::PLN-REMOVE-LOCAL-NICKNAME at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::PLN-DELETE-LOCALLY-NICKNAMING-PACKAGE at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) ABCL.TEST.LISP::PLN-DELETE-LOCALLY-NICKNAMED-PACKAGE ABCL.TEST.LISP::PLN-OWN-NAME-AS-LOCAL-NICKNAME at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) ABCL.TEST.LISP::PLN-OWN-NICKNAME-AS-LOCAL-NICKNAME at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 46 out of 601 total tests failed: ABCL.TEST.LISP::UNUSED.1, at org.armedbear.lisp.Symbol.execute(Symbol.java:803) ABCL.TEST.LISP::UNUSED.2, ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.2, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.3, at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) ABCL.TEST.LISP::WITH-CODE-TO-METHOD.2, ABCL.TEST.LISP::DIRECTORY.3, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::PHYSICAL.21, ABCL.TEST.LISP::PHYSICAL.27, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ABCL.TEST.LISP::SILLY.5, ABCL.TEST.LISP::SBCL.34, at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) ABCL.TEST.LISP::SBCL.35, ABCL.TEST.LISP::SBCL.36, at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) ABCL.TEST.LISP::SBCL.37, ABCL.TEST.LISP::SBCL.38, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) ABCL.TEST.LISP::SBCL.39, ABCL.TEST.LISP::SBCL.40, at org.armedbear.lisp.Symbol.execute(Symbol.java:803) ABCL.TEST.LISP::SBCL.41, ABCL.TEST.LISP::SBCL.43, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.INIT, at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.1, ABCL.TEST.LISP::JAR-PATHNAME.LOAD.6, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.1, at org.armedbear.lisp.Symbol.execute(Symbol.java:826) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.2, ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.4, at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.asdf_1215.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.6, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.7, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.9, at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1214.execute(asdf.lisp:8880) ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.3, at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.4, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.5, at org.armedbear.lisp.asdf_1210.execute(asdf.lisp:8880) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.1, ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.5, at org.armedbear.lisp.asdf_1213.execute(asdf.lisp:8880) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) ABCL.TEST.LISP::EXPT.5, ABCL.TEST.LISP::LOG.3, ABCL.TEST.LISP::LOG.4, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) ABCL.TEST.LISP::LOG.5, ABCL.TEST.LISP::LOG.6, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1212.execute(asdf.lisp:8880) ABCL.TEST.LISP::MATH.READ-FROM-STRING.1, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::BUGS.PPRINT.1, ABCL.TEST.LISP::BUGS.PATHNAME.MAKE-PATHNAME.1, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ABCL.TEST.LISP::BUGS.READER.1, ABCL.TEST.LISP::WILD-PATHNAMES.2, at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ABCL.TEST.LISP::RUNTIME-CLASS.1, ABCL.TEST.LISP::RUNTIME-CLASS.2, at org.armedbear.lisp.asdf_1209.execute(asdf.lisp:8880) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) ABCL.TEST.LISP::RUNTIME-CLASS.3, ABCL.TEST.LISP::RUNTIME-CLASS.4. at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 42 unexpected failures: ABCL.TEST.LISP::UNUSED.1, at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:102) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) ABCL.TEST.LISP::UNUSED.2, ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.2, at org.armedbear.lisp.Lisp.funcall(Lisp.java:172) ABCL.TEST.LISP::DERIVE-TYPE-LOGXOR.3, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) ABCL.TEST.LISP::WITH-CODE-TO-METHOD.2, ABCL.TEST.LISP::DIRECTORY.3, at org.armedbear.lisp.asdf_1265.execute(asdf.lisp:8988) ABCL.TEST.LISP::PHYSICAL.21, ABCL.TEST.LISP::PHYSICAL.27, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) ABCL.TEST.LISP::SILLY.5, ABCL.TEST.LISP::SBCL.34, at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ABCL.TEST.LISP::SBCL.35, ABCL.TEST.LISP::SBCL.36, at org.armedbear.lisp.asdf_1264.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) ABCL.TEST.LISP::SBCL.37, ABCL.TEST.LISP::SBCL.38, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) ABCL.TEST.LISP::SBCL.39, ABCL.TEST.LISP::SBCL.40, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) ABCL.TEST.LISP::SBCL.41, ABCL.TEST.LISP::SBCL.43, at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.1, at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.6, ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.1, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.2, at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.4, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.6, at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.7, ABCL.TEST.LISP::JAR-PATHNAME.LOAD.HTTP.9, at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ABCL.TEST.LISP::JAR-PATHNAME.PROBE-FILE.3, at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.1, ABCL.TEST.LISP::JAR-PATHNAME.MERGE-PATHNAMES.5, at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) ABCL.TEST.LISP::EXPT.5, ABCL.TEST.LISP::LOG.3, ABCL.TEST.LISP::LOG.4, ABCL.TEST.LISP::LOG.5, ABCL.TEST.LISP::LOG.6, at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.clos_292.execute(clos.lisp:2527) ABCL.TEST.LISP::MATH.READ-FROM-STRING.1, at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ABCL.TEST.LISP::BUGS.PPRINT.1, ABCL.TEST.LISP::BUGS.READER.1, at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) ABCL.TEST.LISP::WILD-PATHNAMES.2, ABCL.TEST.LISP::RUNTIME-CLASS.1, at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) ABCL.TEST.LISP::RUNTIME-CLASS.2, ABCL.TEST.LISP::RUNTIME-CLASS.3, ABCL.TEST.LISP::RUNTIME-CLASS.4. at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) ; Compilation unit finished ; Caught 1 WARNING condition at org.armedbear.lisp.Symbol.execute(Symbol.java:814) ; The following functions were used but not defined: at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ; ABCL-REGRESSION-TEST::COPY-ENTRY at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1253.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1252.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_304.execute(clos.lisp:2620) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_1257.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.asdf_1261.execute(asdf.lisp:8988) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.asdf_717.execute(asdf.lisp:7182) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1259.execute(asdf.lisp:8988) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_1256.execute(asdf.lisp:8988) at org.armedbear.lisp.clos_306.execute(clos.lisp:2719) at org.armedbear.lisp.clos_280.execute(clos.lisp:2301) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.funcall(Lisp.java:174) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:838) at org.armedbear.lisp.LispThread.execute(LispThread.java:872) at org.armedbear.lisp.asdf_1283.execute(asdf.lisp:9071) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:614) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:303) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.ClassNotFoundException: Function class not found: foo.Actor at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:111) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at org.armedbear.lisp.MemoryClassLoader.loadClass(MemoryClassLoader.java:95) at org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) ... 259 more Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -10 at java.lang.String.substring(String.java:1875) at org.armedbear.lisp.JavaClassLoader.getFunctionClassBytes(JavaClassLoader.java:88) at org.armedbear.lisp.MemoryClassLoader.getFunctionClassBytes(MemoryClassLoader.java:119) at org.armedbear.lisp.MemoryClassLoader.findClass(MemoryClassLoader.java:106) ... 262 more Armed Bear Common Lisp 1.3.2 Java 1.7.0_71 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.622 seconds. Startup completed in 3.625 seconds. Caught FILE-ERROR while processing --eval option "(asdf:test-system :cl-bench)": The file "/usr/ports/pobj/abcl-1.3.2/cl-bench/defpackage.lisp" does not exist. Java Result: 2 Timo

3 5

Java version 1.5?
by Blake McBride 03 May '15

03 May '15

Looking over the ant build (build.xml), it seems like the target and source are set to Java 1.5. Isn't it time we changed it to at least 1.7?

2 1

abcl-1.3.2 released
by Mark Evenson 29 Apr '15

29 Apr '15

To little fanfare, we released abcl-1.3.2 last week. >From <http://abcl.org/svn/tags/1.3.2/CHANGES>: Enhancements ------------ * Make result of DEFINE-MODIFY-MACRO available at compilation time [r14727] Fixes ----- * Fix failed AVER [#289] [r14763] * Fix incorrect dead code elimination Additionally, don't recurse into flet/labels upon elimination of a single labels function; simply continue by changing the applicable set. Reported by Vibhu Mohindra. [r14754][r14756] * Numeric tower repairs on promoting floats across representation boundaries [r14749-50] (Massimiliano Ghilardi). * Return SIMPLE-ERROR for invalid external-format arguments.[r14735] * Lisp stack frame representation now formatted as unreadable. [r14738-9] Contrib ------- * JSS ** Fix GET-JAVA-FIELD and SET-JAVA-FIELD [r14718] ** no longer error on NO-SUCH-JAVA-FIELD, by setting fields as accessible where necessary [r14715] [r14725] * ABCL-ASDF ** Update to current Maven support (keep up with changing APIs through the Maven 3.2.3-3.2.5 hysteresis) [r14742-7] (Cyrus Hamon). ** Special-case JNA artifacts with alternate network location [r14733] ** Further work on ABCL-ASDF:RESOLVE [r14732] (Cyrus Hamon) ** Find Maven under FreeBSD ports [r14723], under OS X Homebrew [r14776] * ABCL-JAR ** Fix ASDF-JAR:PACKAGE [#376] [r14717][r14720][r14736] (Eduardo Bellani) * ASDF ** Updated to version 3.1.4. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 3

armedbear.org
by Erik Huelsmann 24 Apr '15

24 Apr '15

Hi all, armedbear.org used to be in my possession (ever since Peter Graves transferred it to me). Today, I transferred it to the CLF ( http://cl-foundation.org/) so it's in neutral hands. The offer I made the CLF is that I keep paying for the domain for the forseeable future. I guess that if the project has great plans for the domain, you're free to implement them :-) [always were, just mentioning it once more]. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

maven binary location under mac homebrew
by Cyrus Harmon 24 Apr '15

24 Apr '15

For the maven ASDF contrib stuff to find the mvn executable when using the homebrew packaged maven, I need the following patch: diff --git i/contrib/abcl-asdf/maven-embedder.lisp w/contrib/abcl-asdf/maven-embedder.lisp index c0b67ad..a64f8fa 100644 --- i/contrib/abcl-asdf/maven-embedder.lisp +++ w/contrib/abcl-asdf/maven-embedder.lisp @@ -115,6 +115,9 @@ (defun find-mvn-libs () (truename d))) (list (make-pathname :defaults (merge-pathnames "../lib/" (find-mvn)) :name nil :type nil) + ;; library location for homebrew maven package on MacOS + (make-pathname :defaults (merge-pathnames "../libexec/lib/" (find-mvn)) + :name nil :type nil) #p"/usr/local/share/java/maven3/lib/" ;; FreeBSD ports #p"/usr/local/maven/lib/"))) ;; OpenBSD location suggested by Timo Myyrä is there a better way to do this? thanks, Cyrus

2 1

cl-test-grid results for svn revision 14755
by Anton Vodonosov 11 Apr '15

11 Apr '15

Hello, Diff between ABCL 1.3.1 and the current dev version (svn revision 14755): https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff25.html Unfortunately there are only regressions. (The green results for cffi-libffi are due to installed libffi-dev on the testing machine, not because of ABCL improvement) Best regards, - Anton

4 15

Upcoming abcl-1.3.2
by Mark Evenson 11 Apr '15

11 Apr '15

I hearby officially announce my attention to release abcl-1.3.2 before ELS 2015. If people have time to fix outstanding bugs over the weekend, please submit your patches or concerns as soon as you can either to the mailing list on on IRC at [#abcl][]. [#abcl]: http://webchat.freenode.net/?randomnick=1&channels=abcl&prompt=1&uio=d4 One can view the more-or-less complete list of [CHANGES][1] in trunk. [1]: http://abcl.org/trac/browser/trunk/abcl/CHANGES There are six (6) [ANSI regressions][2] that occur on JRE 7/8 that don't appear on previous versions of the JRE, namely READ-BYTE.ERROR.5 WRITE-BYTE.ERROR.4 CLEAR-INPUT.ERROR.5 FINISH-OUTPUT.ERROR.3 FORCE-OUTPUT.ERROR.3 CLEAR-OUTPUT.ERROR.3, which have something to do with generic function dispatch that I haven't quite figured out, but will probably not address in this release. [2]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/ansi-test-failures#L… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Losing on multiprocessing
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Howdy, I wonder if those of you have worked with threads might have a quick look to see if I am doing something stupid. https://lsw2.googlecode.com/svn/branches/bona/util/jargrep.lisp The situation is that I want to do stuff (like look for matches to a regular expression) in 240k files which comprise 52G of data. I am running on a VM allocated 5 CPUs each with three cores. Because at the moment the disk subsystem isn't very fast, I decided to approach this by breaking up the 240k files into 15 parts and put each part in a jar file. The code mentioned above looks for a regular expression (two methods for two different regex handlers: java and dk.brics.automaton It is invoked something like: (jar-map-threads-automaton-find regex (generate-filename-sequence "/data/jars/15/file#.jar" 2 0 14)) This spawns off 15 threads that go at it for something around a minute. As they find hits they save them in a lisp hash table keyed by the entry name in the jar file, which is unique across all the jar files. The result of running this is about (and their's the rub) 20 key value pairs in the hash table (I had read that ABCL hash tables are thread safe). The problem is that different runs of this code on the same data get different numbers of key value pairs, between 13 and 24! I'm not sure whether I'm just not doing this the right way, in which case it would be very helpful to get an explanation of why not, or there's a problem somewhere in the implementation. Any ideas would be greatly appreciated. Best, Alan (LISP-IMPLEMENTATION-VERSION) "1.2.0-dev-svn-14436M" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_21-b11" "amd64-Linux-3.8.0-30-generic"

2 7

[armedbear-devel] abcl.org down
by Mark Evenson 08 Apr '15

08 Apr '15

abcl.org is currently unreachable: we expect to have it up around 2300 GMT. A [relatively up-to-date mercurial repostiory][1] exists if you absolutely have to diff trunk *right now*. [1]: https://code.google.com/p/abcl-dynamic-install/ Sorry about this, Bear fans, -- The Mgmt. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] SBCL->ABCL migration questions
by Rich Morin 08 Apr '15

08 Apr '15

I'm involved with a project that uses Steel Bank Common Lisp (SBCL). I'm interested in the possibility of moving it to ABCL, in order to take advantage of interoperability with some other JVM languages (eg, Clojure, JRuby, Jython). FYI, the project software currently uses several requires: (require :bordeaux-threads) (require :mcclim) ; CLIM public implementation (require :MT19937) ; Mersenne Twister random number generator Does anyone have any caveats or suggestions to offer? I'd also be interested in learning about ABCL (or, more generally, Common Lisp) consultants who are willing to take on small assignments. -r

4 5

[armedbear-devel] Futile attempt at using Akka
by ubikation _ 08 Apr '15

08 Apr '15

Hello, I have been playing around with Common Lisp for a while and I really want to get this idea working. I have been reading a lot about Akka, but I'm not really a Java/Scala/distributed guy. To my understanding, Akka is an agnostic way to create Actors that can send messages at varying speeds, speeding up with the available memory and cores and easily extending itself for distributed communication via remote Actors. I'm not an expert by any means, so feel free to correct me on the description. I would like to create bindings to this example http://doc.akka.io/docs/akka/2.1.2/java/untyped-actors.html and it was suggested to me that I might use "java:jnew-runtime-class" by the very nice ehu on #abcl. My repository is at https://github.com/ubikation/chemicalambda if anyone is interested in my progress or wants a better idea of where I am (not really beyond starting the project at the moment). At the minimum I would like to create bindings, but I would like to do something more interesting after I get some stuff working. I do not know what I am doing at all, but I am hoping that creating these bindings will help solidify my understanding of Common Lisp and of ABCL in particular. Thanks again!

3 3

[armedbear-devel] undesirable behavior in #'directory ?
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Emacs creates files like this: lrwxr-xr-x 1 alanr staff 30 Jan 6 01:40 .#foo.sql@ -> alanr(a)conjunctive-2.local.6427 as lock files, IIRC. In such cases, the target of link names a file that doesn't exist. #'directory calls #'truename on the filenames that are listed, and truename does a probe file. Incidentally It looks like that is done in the java as well as the lisp function making the latter redundant. It seems wrong that there is a situation in which one can't call directory at all without getting an error. The crux of the matter is how to interpret the documentation of truename in the presence of symbolic links. The doc for truename says: If filespec is a pathname it represents the name used to open the file. This may be, but is not required to be, the actual name of the file." "actual name of the file" suggests that there is a file, but also suggests that it is the name that is important. Also whereas directory allows implementation-dependent keywords, truename is not so defined. I'll take the position that truename should *not* depend on the file existing, but rather focus on what names are present in directory structures. So resolve-truenames nil should should return the names in the directory and for resolve-truenames t it should follow symbolic links as long as they can be followed without hitting a name that doesn't designate an existing file. -Alan

5 13

[armedbear-devel] installing java dependencies with :mvn ASDF component
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. I need to import data from Excel, and following Hans Hübner's article for how to do this with ABCL: http://netzhansa.blogspot.com/2013/03/dealing-with-excel-files-from-common.… The Hans' code depends on Apache POI library. I saw that ABCL comes from abcl-asdf contrib, which extends ASDF by adding a :mnv component, so that we can specify :mvn artifact as a dependency of our ASDF system. I would like to use this facility to automatically install the POI .jar files. I created an .asdf file with this content: (defsystem :excel-s :defsystem-depends-on (:abcl-asdf) :version "0.1.0" :encoding :utf-8 :components ((:mvn "org.apache.poi/poi-ooxml/3.9"))) Then I invoke ABCL: C:\Users\anton\projects\abcl\abcl.bat --batch --eval "(require :abcl-contrib") --eval "(pushnew \"./\" asdf:*central-registry* :test #'equal)" --eval "(ql:quickload :excel-s)" It fails with exception: java.lang.ClassNotFoundException: aether.util.artifact.DefaultArtifact This exception is throw by abcl-asdf::resolve-dependencies function, defined in the contrib/abcl-asdf/maven-embedder.lisp. Maven is installed on my machine, including the /lib/ directory containing the Aether API jars. I performed some investigation and tried to ensure the Aether .jars are added to classpath: (abcl-asdf::init) (let ((*default-pathname-defaults* abcl-asdf::*mvn-libs-directory*)) (dolist (jar-pathname (or (directory "**/*.jar") (error "no jars found in ~S - expected Apache Maven /libs/ directory ~ installation there" (merge-pathnames abcl-asdf::*mvn-libs-directory*)))) (java:add-to-classpath (namestring jar-pathname)))) Still I have the same error - class aether.util.artifact.DefaultArtifact not found. Is the way I am trying to install java libs expected to work, and how to find the problem? Best regards, - Anton

2 8

Re: [armedbear-devel] Pdfdoclet - Javadoc for ABCL in PDF format
by Mark Evenson 08 Apr '15

08 Apr '15

On 7/23/13 11:34 PM, Sean Champ wrote: […] > Personally and primarily, I've been interested in the possibility of > developing an ABCL interface onto Apache Jena, and possibly an interface > onto some JARs distributed by the GeoTools project - would like to > develop a process of transforming an ESRI Shapefile into an OWL > ontology, and it seemed that ABCL would be a good Common Lisp > implementation to use for such a purpose. See [jeannie][] for an initial wrapping of Jena with ABCL. It doesn't do much more than read RDF from a PATHNAME, but adding the rest is a matter of rolling up the proverbial sleeves. [jeannie]: http://bitbucket.org/easye/jeannie […] > In looking at that idea, I'd been interested about how the CLOS support > is implemented in ABCL, and whether and how MOP might be implemented, > there. As much of CLOS/MOP as possible has been implemented in Lisp: see clos.lisp. CLOS is mostly historical, evolving in fits and starts over the lifetime of ABCL. The MOP has been added mostly of the last year by Rudi Schlatte. Following his commits chronologically would give somewhat of an impression of how it is implemented. […] > (On a personal note: > Between moving and returning to college, it's been a busy summer, > frankly, but there are some bluesky ideas that one can focus on, I suppose) No sweat: we should still be here when you get some time. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 2

Are we back?
by Erik Huelsmann 08 Apr '15

08 Apr '15

Test. sent from my phone

7 6

[armedbear-devel] 7th European Lisp Symposium, May 5-6 2014, Paris, France
by Didier Verna 08 Apr '15

08 Apr '15

ELS'14 - 7th European Lisp Symposium IRCAM, Paris, France May 5-6, 2014 http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 7th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Please note that IRCAM, the conference venue, is a French institute for research on music and acoustics. Submissions relating Lisp to music or other acoustical matters will hence be particularly welcome, although given no heightened favor during the review process. We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - TODAY: Mark your calendar. Start planning now! - 09 Mar 2014: Submission deadline - 31 Mar 2014: Notification of acceptance - 21 Apr 2014: Final Papers due - 05 May 2014: Symposium. Join us there! Program Committee: Chair: Kent Pitman, Hypermeta Inc., U.S.A. Local Organizers: Didier Verna, EPITA Research Lab, France Gérard Assayag, IRCAM, France Members: To be announced later Search Keywords: #els2014, ELS 2014, ELS '14, European Lisp Symposium 2014, European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium, European Lisp Conference 2014, European Lisp Conference '14 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[armedbear-devel] Fwd: Wild pathnames
by Faré 08 Apr '15

08 Apr '15

Bug report: abcl doesn't correctly process filenames with a "*" in them. Here is the command I ran, where cl is the latest cl-launch 4: mkdir -p /tmp/x ; touch "/tmp/x/*" ; for i in sbcl ccl clisp cmucl ecl abcl \ scl allegro lispworks gcl xcl ; do echo $i ; cl -l $i -iw \ '(let ((x (directory "/tmp/x/*"))) (list "'$i'" x (pathname-name (first x))))' ; done And the summarized results are: Escape properly: ("sbcl" (#P"/tmp/x/\\*") "*") ("ccl" (#P"/tmp/x/\\*") "\\*") ("cmucl" (#P"/tmp/x/\\*") "*") ("lispworks" (#P"/tmp/x/\\*") "\\*") ("scl" (#P"file://localhost/tmp/x/*") "*") Read badly: ("clisp" (#P"/tmp/x/*") :WILD) ("ecl" (#P"/tmp/x/*") :WILD) ("allegro" (#P"/tmp/x/*") :WILD) ("xcl" (#P"/tmp/x/*") :WILD) Error out: abcl Fatal condition: Bad place for a wild pathname. gcl: Fatal condition: Condition in LET [or a callee]: INTERNAL-SIMPLE-FILE-ERROR: File error on "/tmp/x/*": File "/tmp/x/*" is wild —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No man would listen to you talk if he didn't know it was his turn next. — Edgar Watson Howe

2 1

[armedbear-devel] multidimensional java arrays?
by Cyrus Harmon 08 Apr '15

08 Apr '15

I am trying to connect ABCL up with some java code that uses multidimensional arrays of the form: int[][] theArray = new int[4][4]; The problem is that when I call this code I get something like this in return: #(#<jarray [I@2d983837 {6492BA43}> #<jarray [I@5d02b84a {5D9131FA}> #<jarray [I@67684413 {6E4D706E}> #<jarray [I@1e107e55 {4CD60DDE}>) that is a lisp array that contains 4 java arrays. I can’t pass this off to a method like this: static public int[][] arrayTest2(int[][] oldArray) { … } I can work around this by creating a new java array myself (and populating it appropriately), but this is no fun. Is this the intended behavior? thanks, Cyrus

3 5

[armedbear-devel] Trouble calling a static function
by ubikation _ 08 Apr '15

08 Apr '15

I have been trying to create a static function that allows me to create an Akka Actor so I can try to play with it from within slime, but I am running into a very odd issue. ----- Issue: The static function for Java works perfectly, but the equivalent static function for slime does not. ----- The files for reproducing this issue are attached, and the repository that I am using is: https://github.com/ubikation/chemicalambda Testing requires having the correct jars, which are installable via the pom.xml: mvn install mvn dependency:copy-dependencies The second command should create a target/dependency folder that you have to add to the classpath, along with the dir containing all of the files I've attached to this email. ----- Here is my calling session: CL-USER> (load "/home/ubikation/src/lisp/chemicalambda/AkkaTest.lisp") T CL-USER> (my-test) This is the error when trying to call the static function: Java exception 'java.lang.NoClassDefFoundError: akka/actor/ActorSystem'. [Condition of type JAVA-EXCEPTION] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {1E9ABE91}> #<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>) 1: (APPLY #<FUNCTION {1E9ABE91}> (#<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>) 3: (INVOKE-DEBUGGER #<JAVA-EXCEPTION {15883401}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.jstatic(Java.java:487) 6: org.armedbear.lisp.Java$pf_jstatic.execute(Java.java:513) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 8: (JSTATIC "test" "AkkaApiSimple") 9: (VOID-FUNCTION) 10: (MY-TEST) 11: (SYSTEM::%EVAL (MY-TEST)) 12: (EVAL (MY-TEST)) 13: (SWANK::EVAL-REGION "(my-test) ") 14: (#<FUNCTION {210E38B2}>) 15: (SWANK::TRACK-PACKAGE #<FUNCTION {210E38B2}>) 16: (#<FUNCTION {2CAC3F12}>) 17: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION {2CAC3F12}>) 18: (#<FUNCTION {6060CDA7}>) 19: (FUNCALL #<FUNCTION {6060CDA7}>) 20: (#<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {735DC05F}> #<FUNCTION {6060CDA7}>) 21: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {735DC05F}> #<FUNCTION {6060CDA7}> NIL) 22: (SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #<FUNCTION {6060CDA7}>) 23: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<FUNCTION {6060CDA7}>) 24: (SWANK::REPL-EVAL "(my-test) ") 25: (SWANK:LISTENER-EVAL "(my-test) ") 26: (SYSTEM::%EVAL (SWANK:LISTENER-EVAL "(my-test) ")) 27: (EVAL (SWANK:LISTENER-EVAL "(my-test) ")) 28: (#<FUNCTION {1000D825}>) 29: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1000D825}>) 30: (SWANK:EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(my-test) ") "COMMON-LISP-USER" 12) 31: (APPLY #<EVAL-FOR-EMACS {4FAC1D53}> ((SWANK:LISTENER-EVAL "(my-test) ") "COMMON-LISP-USER" 12)) 32: (SWANK::PROCESS-REQUESTS NIL) 33: (#<FUNCTION {276E6D58}>) 34: (EVAL (SWANK:LISTENER-EVAL "(test) ")) 35: (#<FUNCTION {42CCC0A1}>) 36: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {42CCC0A1}>) 37: (SWANK:EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(test) ") "COMMON-LISP-USER" 9) 38: (APPLY #<EVAL-FOR-EMACS {4FAC1D53}> ((SWANK:LISTENER-EVAL "(test) ") "COMMON-LISP-USER" 9)) 39: (SWANK::PROCESS-REQUESTS NIL) 40: (#<FUNCTION {107AAC4A}>) 41: (#<FUNCTION {65C536B9}>) 42: (FUNCALL #<FUNCTION {65C536B9}>) 43: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}>) 44: (APPLY #<(FLET CALL-WITH-DEBUGGER-HOOK) {768BDFE1}> #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}> NIL) 45: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}>) 46: (#<FUNCTION {59176994}>) 47: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*STANDARD-INPUT* . #S(SLIME-INPUT-STREAM)) (*TRACE-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*ERROR-OUTPUT* . #S(SLIME-OUTPUT-STREA.. 48: (#<FUNCTION {3A65F5B1}>) 49: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {3A65F5B1}>) 50: (#<FUNCTION {7BE5556A}>) 51: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {7BE5556A}>) 52: (SWANK::HANDLE-REQUESTS #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {6BC6FEA9}> :SOCKET-IO #<TWO-WAY-STREAM {55794086}> :DEDICATED-OUTPUT NI.. 53: (SWANK::REPL-LOOP #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {6BC6FEA9}> :SOCKET-IO #<TWO-WAY-STREAM {55794086}> :DEDICATED-OUTPUT NIL :USE.. 54: (#<FUNCTION {B7B4941}>) 55: (SWANK::CALL-WITH-BINDINGS NIL #<FUNCTION {B7B4941}>) 56: (#<FUNCTION {4B06504A}>) 57: (FUNCALL #<FUNCTION {4B06504A}>) 58: (#<FUNCTION (LAMBDA ()) {B8150C1}>) 59: (THREADS::THREAD-FUNCTION-WRAPPER #<FUNCTION (LAMBDA ()) {B8150C1}>) I've tried to be very clear but I'm sure I've missed something. I don't know what's causing this error, and I can't tell if I'm going about this in some stupid manner or if this is a symptom of a more complex issue. If you need any help reproducing this issue please email me, I'm desperate for any input. Thank you very much for your time!

2 4

[armedbear-devel] hang with threads:object-wait
by James M. Lawrence 08 Apr '15

08 Apr '15

(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001)))) For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001. The context is the new timeout option for bordeaux-threads:condition-wait, https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp… 1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae Best, lmj

4 22

Re: [armedbear-devel] Pure threads and hashtables test
by Mark Evenson 08 Apr '15

08 Apr '15

Eh. Upon reflection, not entirely sure that the increments are happening CV correctly. I will try to move the test to counting the total entries in the hash table, rather than only accessing one key. This should be closer to Alan's original problem.

3 6

[armedbear-devel] Building with gcj
by David Creelman 08 Apr '15

08 Apr '15

Hi All, First of, a big congrats on ABCL. It seems to be getting better and better all the time. I'm able to run ABCL under Java on Debian (testing) with no troubles (using ant or build-abcl.lisp with a few changes). However, I'm stumped about how to use gcj to make an exe. I'm wanting to use the exe on a site that doesn't have java, but will allow server exes. For a normal Java build, on Debian I needed to change the script a little so that the java and javac exe were found at /usr/bin/java, rather than /bin/java. Perhaps this could be made into a defconstant/defparameter? If someone has built ABCL with gcj and could point me to some docs I may have missed or some information that may be missing, but is in someones head or a custom build script, please let me know. Once I find out how to do it, I'll be more than happy to write up how it works for the ABCL docs and build scripts. Cheers David

2 1

[armedbear-devel] Backquote bug
by Faré 08 Apr '15

08 Apr '15

Subtle bug in ABCL. What should this form read as? `#5(1 ,@`(2 3)) ECL, LispWorks and fare-quasiquote agree on #(1 2 3 2 3) allegro, ccl, clisp, sbcl return the arguably conformant #(1 2 3 2 3 2 3 2 3) abcl, cmucl, gcl, xcl all return the arguably completely buggy #(1 2 3) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty.

4 6

[armedbear-devel] abcl-1.3.0 released
by Mark Evenson 08 Apr '15

08 Apr '15

http://abcl.org/releases/1.3.0 abcl-1.3.0 is a feature release. 15-MAR-2014 ## Features * Make LispStackFrame.UNAVAILABLE_ARG a singleton object, and lazily create the little used portions of the Lisp stack. Aggressively cache and control the use of memory by the underlying Lisp stack frame representation by introducing the private LispThread.StackFrame and LispThread.StackSegments classes. Contributed by Dmitry Nadezhin. LispStackFrame object are allocated on every LispThread.execute(...) . However, they are seldom [accessed] ([... verify via] inspect[tion of the] stack trace). This patch delays allocation of LispStackFrame? objects until they are requested. Raw information about stack frames is stored in stack. Stack is an Object[] array (more precisely a list of [...]4 [Mib] Object[] arrays). ME: We are going to need a way to try to less agressively grab 4Mib chunks in low memory situations. Memory profiling of ABCL shows that the classes with largest allocation count are org.armedbear.lisp.LispStackFrame and org.armedbear.lisp.LispStackFrame.UnavailableArgument. Contributed by Dmitry Nadezhin. [r14572]: http://abcl.org/trac/changeset/14572 [r14579]: http://abcl.org/trac/changeset/14579 * ASDF 3.0.1.94 shipped with the implementation * per function call stack and memory exception handler in CL:COMPILE Inline calls to jrun-exception-protected (used by handler-bind to catch out of memory conditions). This commit saves generation roughly 50 cls files. [r14552]: http://abcl.org/trac/changeset/14552 * SYS:SHA256 audited The functionality if the SYS:SHA256 algorithim has been audited for use on inputs of single for files with recently shipping ORCL Java 7 implementations (through jdk-1.7.0_51). [r14582]: http://abcl.org/trac/changeset/14582 * Connect to NetBeans controlled JDWP via SLIME The Netbeans IDE configuration now includes a way to connect to the running-under-jdb ABCL via SLIME. One needs a version of SLIME able to be loaded from its 'swank.asd' definition. * Install 'abcl.jar' and 'abcl-contrib.jar' locally as Maven artifacts The Ant `abcl.mvn.install` target now installs build artifacts into the local Maven repository (Olof-Joachim Frahm) [r14579]: http://abcl.org/trac/changeset/14606 ## Compatibility * CL:DIRECTORY The implementation specific :RESOLVE-SYMLINKS argument to the ANSI DIRECTORY function has been changed to nil. This implements behavior closer to SBCL and guarantees that a DIRECTORY operation will not signal a file error. [r14619]: http://abcl.org/trac/changeset/14619 [ticket-340]: http://abcl.org/trac/ticket/340 ## Fixes * Fix CL:SLEEP for intervals less than a millisecond. For intervals less than or equal to a nanosecond, including an interval of zero, the current thread merely yields execution to other threads. [r14632]: http://abcl.org/trac/changeset/14632 ## Tested ### "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_51-b13" "x86_64-Mac_OS_X-10.9.1" ### "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.8.0-b129" "x86_64-Mac_OS_X-10.9.2" ## Contrib #### abcl-asdf * Now working with both Maven 3.0.x and 3.1.x. Thanks to Anton for the help! [ticket-328]: http://abcl.org/trac/ticket/328 * cache Maven dependency resolution to avoid repeated lookups. Instead of calling ABCL-ASDF:RESOLVE in both the ASDF COMPILE-OP and LOAD-OP, we now cache the result of invocation in COMPILE-OP and add this value in the LOAD-OP phase. Contributed by Cyrus Harmon. [r14631]: http://abcl.org/trac/changeset/14631 #### jna Now references jna-4.0.0. Some incompatibility with CFFI ([in progress with fixing upstream][cffi-easye]). [cffi-easye]: http://github.com/easye/cffi/

5 16

[armedbear-devel] Setup changes for cl-test-grid.cloud.efficito.com
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Anton, Looking at some of the test grid failures for ABCL, I noticed some of the OpenGL packages failing due to being unable to locate LibGL.so. To resolve that, I ran: $ aptitude install libgl1-mesa-swx11 Then I noticed something wanted to require JSS, but didn't know how to, so I've added "(require :abcl-contrib)" to /home/testgrid/.abclrc. With these in place cl-glfw-opengl-core seems to load just fine. Any other libraries or measures I should take in order to be able to load (currently failing) systems? Bye, Erik.

3 3

[armedbear-devel] abcl-1.2.0 RC 0
by Mark Evenson 08 Apr '15

08 Apr '15

Live from the floor of ECLM 2013, [Binaries for the first release candidate for abcl-1.2.0][abcl-1.2.0-rc-0] have been uploaded and signed by <evenson.not.org(a)gmail.com>. For reasons that aren't entirely clear, the size of the archive has increased to 10 Mib. I'm not sure if this has been just a slow creep, or is related to the recent conversion of CLOS infrastructure from Java to Lisp. Please test if you can, letting us know if you have problems. [branch for 1.2.0]: http://abcl.org/svn/branches/1.2.0 [abcl-1.2.0-rc-0]: http://abcl.org/releases/1.2.0/rc-0

1 1

[armedbear-devel] Can't build rev14574 with ant 1.8.2
by Dmitry Nadezhin 08 Apr '15

08 Apr '15

1) I check out a fresh working copy from SVN trunk (rev14574). 2) Then I try to build. It fails. <<<<<<<<<<<<<< $ ant Buildfile: MYWORKDIR/build.xml abcl.clean.maybe: [echo] Cleaning all intermediate compilation artifacts. [echo] Setting 'abcl.build.incremental' enables incremental compilation. abcl.clean: abcl.copy.lisp: BUILD FAILED MYWORKDIR/build.xml:200: file attribute is null! Total time: 0 seconds >>>>>>>>>>>>>>>>> 3) Then I comment line 200 in build xml. This line was: <file name="${basedir}/abcl.rdf"/> 4) and run again $ ant Now the build passes ok. Ant version is: $ ant -version Apache Ant(TM) version 1.8.2 compiled on December 20 2010 The documentation says that ant-1.7.1 is enough. I have the workaround. Nevertheless, how to build properly ?

2 1

[armedbear-devel] Community & educational development
by AMPU 08 Apr '15

08 Apr '15

PRESS RELEASE The Federal Grants and Loans Directory is now available. Our new and revised 2014 edition contains more than 2800 financial programs, subsidies, scholarships, grants and loans offered by the US federal government. In addition you will also have access to over 2400 programs funded by private corporations and foundations. That is over 5200 programs available through various sources of financial providing organizations. NEW: You will also have access to our live Database that is updated on a daily basis. This product also provides daily email alerts as programs are announced. The Database is also available with IP recognition. This allows you to login without a username or password (Great for libraries or educational institutions who want their users to access the database). Businesses, students, researchers, scientists, teachers, doctors, private individuals, municipalities, government departments, educational institutions, law enforcement agencies, nonprofits, foundations and associations will find a wealth of information that will help them with their new ventures or existing projects. The document is a fully searchable PDF file for easy access to your particular needs and interests. Simply enter your keywords to search through the publication. It is the perfect tool for libraries and educational institutions to use as a reference guide for students who require funds to pursue their education. Contents of the Directory: -Web link to program announcement page -Web link to Federal agency or foundation administering the program -Authorization upon which a program is based -Objectives and goals of the program -Types of financial assistance offered under a program -Uses and restrictions placed upon a program -Eligibility requirements -Application and award process -Regulations, guidelines and literature relevant to a program -Information contacts at the headquarters, regional, and local offices -Programs that are related based upon program objectives and uses Programs in the Catalog provide a wide range of benefits and services for categories such as: Agriculture Business and Commerce Community Development Consumer Protection Cultural Affairs Disaster Prevention and Relief Education Employment, Labor and Training Energy Environmental Quality Food and Nutrition Health Housing Income Security and Social Services Information and Statistics Law, Justice, and Legal Services Natural Resources Regional Development Science and Technology Transportation CD version: $69.95 Printed version: $149.95 To order please call: 1 (866) 645-1051 Please do not reply to the sender's email address as this address is only for outgoing mail. If you do not wish to receive information from us in the future please reply here: rem(a)rembcst.com This is a CANSPAM ACT compliant advertising broadcast sent by: AMPU, 4044 W. Lake Mary Blvd., Unit # 104-221, Lake Mary, FL, 32746-2012

1 0

[armedbear-devel] how do I unsubscribe?
by Durward McDonell 08 Apr '15

08 Apr '15

I apologize for bothering everyone with this, but I haven't been able to figure out how to unsubscribe from armedbear-devel. The common-lisp.net mail lists seem to be in a state of (eternal?) flux. One day I saw something there that said to send a message to armedbear-devel+unsubscribe(a)common-lisp.net, which I did, and it seemed to work for a while, but now I'm getting messages again. Any suggestions? -- Durward McDonell durward.mcdonell(a)jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)

2 1

[armedbear-devel] Site is down
by Victor 08 Apr '15

08 Apr '15

Hi, I noticed that http://armedbear.org/abcl.html points to the Common-Lisp.net project page that redirects to www.abcl.org that is currently down. Is it possible either to restore the site or turn the redirect off? Thanks, Victor

1 0

[armedbear-devel] Catching exceptions from toString() methods
by Olof-Joachim Frahm 08 Apr '15

08 Apr '15

Hi, I've mentioned this on IRC, just so it isn't forgotten: I was getting some objects from Hibernate in the REPL, which worked fine until the toString() method of an object was called and threw an exception, terminating ABCL completely. Attached is a patch which catches all exceptions during the printObject() method of JavaObject. Best regards, Olof

2 1

[armedbear-devel] threads:interrupt-thread
by Carlos Ungil 08 Apr '15

08 Apr '15

Hello, is there a reason why interrupt-thread doesn't seem to run the requested function in some cases? The following code tries to run a function in each existing thread (the variable *output* logs the calls that we try to run and the ones that are actually run). (defvar *output*) (defun test-run () (setf *output* nil) (threads:mapcar-threads (lambda (thread) (push (format nil "~A : calling" thread) *output*) (threads:interrupt-thread thread (lambda () (push (format nil "~A : running" thread) *output*)))))) (defun test-report () (format t "~{~A~%~}" (reverse *output*))) Running in the command line: CL-USER(5): (threads:make-thread #'test-run :name "TEST-RUN") #<THREAD "TEST-RUN" {49BBE826}> CL-USER(6): (test-report) #<THREAD "TEST-RUN" {49BBE826}> : calling #<THREAD "interpreter" {409CB8AF}> : calling I can understand that the thread "TEST-RUN" that I create to run the function might disappear before it gets to run the function as requested, or maybe the reason is that a thread can't interrupt itself by design... But why doesn't the thread "interpreter" run the function? Running in slime there are many threads present, and most of them will respond as expected. But "TEST-RUN", "interpreter" and "reader-thread" won't. #<THREAD "control-thread" {3C036436}> : calling #<THREAD "reader-thread" {10A08BAA}> : calling #<THREAD "swank-indentation-cache-thread" {2A83402}> : calling #<THREAD "Swank Sentinel" {66E71110}> : calling #<THREAD "repl-thread" {699D8335}> : calling #<THREAD "Swank Sentinel" {66E71110}> : running #<THREAD "TEST-RUN" {4E0267BA}> : calling #<THREAD "repl-thread" {699D8335}> : running #<THREAD "auto-flush-thread" {6913E490}> : calling #<THREAD "interpreter" {1902DFD5}> : calling #<THREAD "auto-flush-thread" {6913E490}> : running #<THREAD "swank-indentation-cache-thread" {2A83402}> : running #<THREAD "control-thread" {3C036436}> : running Cheers, Carlos

1 0

[armedbear-devel] Disable debugger completely
by Jonathan Fischer Friberg 08 Apr '15

08 Apr '15

Hi, This is related to my previous question on catching cl errors in java. This time, I would like to know if it's possible to completely disable the debugger. The error catching that I'm currently using (from the previous thread) works fine, but some things can still escape. Whenever the debugger is started, my whole program locks up for some reason and I'm unable to resume. Jonathan

1 0

[armedbear-devel] Bugs
by Faré 08 Apr '15

08 Apr '15

Testing ASDF found several bugs in ABCL. cd ~/cl/asdf/ abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).' Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'. abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))" So your backquote parser is broken somehow. Also, upgrading from ASDF 2.25 or 2.26 used to work, but not anymore. Now 2.27 is needed (as configured in header.lisp, and tested with make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25). Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Not all Law is created equal before Man. Some Law causes least conflict and least perverse incentives. By definition we call it Natural Law.

2 8

[armedbear-devel] Bug report: non-standard metaclass causes aberrant behaviour
by William Hounslow 08 Apr '15

08 Apr '15

Dear maintainers #1 a user-defined allocate-instance method is not called at all #2 slot-missing is called with a slot-name of nil #3 update-dependent is not being applied to its keyword arguments Best regards William "1.2.1" "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_17-b02" "x86-Windows_7-6.1" ;;;#1 CL-USER(2): (defclass quux-class (standard-class) ()) #<STANDARD-CLASS QUUX-CLASS {D2A36B}> CL-USER(3): (defmethod allocate-instance :after ((class quux-class) &rest initargs) (format t "allocated ~S~%" class)) #<STANDARD-METHOD ALLOCATE-INSTANCE :AFTER (QUUX-CLASS) {14A0B92}> CL-USER(4): (defclass quux nil (bar) (:metaclass quux-class)) #<QUUX-CLASS QUUX {50039B}> CL-USER(5): (make-instance *) #<QUUX {B2D899}> CL-USER(6): (inspect (fdefinition 'allocate-instance)) 0 LAYOUT -----------> #<LAYOUT {BEF803}> 1 NAME -------------> ALLOCATE-INSTANCE 2 LAMBDA-LIST ------> (CLASS &REST ...) 3 REQUIRED-ARGS ----> (CLASS) 4 OPTIONAL-ARGS ----> NIL 5 INITIAL-METHODS --> NIL 6 METHODS ----------> (#<STANDARD-METHOD ALLOCATE-INSTANCE :AFTER (QUUX-CLASS) {14A0B92}> #<STANDARD-METHOD ALLOCATE-INSTANCE :BEFORE (CLASS) {18C9692}> ...) 7 METHOD-CLASS -----> #<STANDARD-CLASS STANDARD-METHOD {A801B0}> 8 %METHOD-COMBINATION -> #<METHOD-COMBINATION STANDARD {F167BB}> 9 ARGUMENT-PRECEDENCE-ORDER -> (CLASS) 10 DECLARATIONS -----> NIL 11 CLASSES-TO-EMF-TABLE -> #<EQUAL HASH-TABLE 0 entries, 11 buckets {D15EE4}> 12 %DOCUMENTATION ---> NIL ;;;#2 CL-USER(11): (make-instance 'quux) #<QUUX {F2AE7E}> CL-USER(12): (slot-value * 'baz) #<THREAD "interpreter" {1A2FE4D}>: Debugger invoked on condition of type SIMPLE-ERROR The slot NIL is missing from the class #<QUUX-CLASS QUUX {50039B}>. Restarts: 0: TOP-LEVEL Return to top level. ;;;#3 CL-USER(2): (defclass foo-class (standard-class) ()) #<STANDARD-CLASS FOO-CLASS {14A123F}> CL-USER(3): (defclass foo-dep () ()) #<STANDARD-CLASS FOO-DEP {145B486}> CL-USER(4): (defmethod mop:update-dependent ((class foo-class) (dep foo-dep) &key direct-slots &allow-other-keys)) #<STANDARD-METHOD MOP:UPDATE-DEPENDENT (FOO-CLASS FOO-DEP) {155388B}> CL-USER(5): (defclass foo () (bar) (:metaclass foo-class)) #<FOO-CLASS FOO {25D10A}> CL-USER(6): (mop:add-dependent * (make-instance 'foo-dep)) (#<FOO-DEP {F167BB}>) CL-USER(7): (trace mop:update-dependent) (MOP:UPDATE-DEPENDENT) CL-USER(8): (defclass foo () (bar baz) (:metaclass foo-class)) 0: (MOP:UPDATE-DEPENDENT #<FOO-CLASS {25D10A}> #<FOO-DEP {F167BB}> (:DIRECT-SUPERCLASSES NIL :DIRECT-SUPERCLASSES NIL DIRECT-SLOTS ((:NAME BAR) (:NAME BAZ)))) #<THREAD "interpreter" {886140}>: Debugger invoked on condition of type PROGRAM-ERROR Odd number of keyword arguments. Restarts: 0: TOP-LEVEL Return to top level.

2 1

[armedbear-devel] CLOS for ABCL based on interpreted Closette?
by ubikation _ 08 Apr '15

08 Apr '15

I've been trying to read AMOP and looking at the Closette code. It seems to me that ABCL uses Closette for CLOS... but the original Xerox code seems to explicitly warn against using it for compiled CLOS. I was just wondering if this is perhaps the reason for the performance issues of CLOS in ABCL. Do other CL implementations use Closette? The text is "Load this source file directly, rather than trying to compile it." from here: http://homepage.stat.uiowa.edu/~luke/xls/xlispstat/other/closette/closette.… Thanks!

1 0

[armedbear-devel] Compiler loses lexical macro in (eval-when (:compile-toplevel ...))
by Douglas Katzman 08 Apr '15

08 Apr '15

Hi. This code fragment works with (LOAD "/tmp/foo.lisp") but not (COMPILE-FILE "/tmp/foo.lisp") (eval-when (:compile-toplevel :load-toplevel :execute) (defvar *count* 0) (macrolet ((something (sym) `(setf (get ,sym 'uniqueid) (incf *count*)))) (defun register-it (x) (something x)))) (eval-when (:compile-toplevel :execute) (format t "~&OK so far~%") (register-it :foo)) (eval-when (:compile-toplevel :execute) (format t "~&Got ~D~%" (symbol-plist :foo))) Armed Bear Common Lisp 1.3.0 Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.258 seconds. Startup completed in 1.231 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/tmp/foo.lisp") ; Compiling /private/tmp/foo.lisp ... ; (DEFVAR *COUNT* ...) ; (DEFUN REGISTER-IT ...) OK so far #<THREAD "interpreter" {3A284BEE}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SOMETHING is undefined. Restarts: ...

2 1

[armedbear-devel] Problem in CLOS MOP in abcl 1.2.0
by Pascal Costanza 08 Apr '15

08 Apr '15

Hi, There is a problem in the MOP implementation in abcl 1.2.0: It seems that the parameter list for std-find-method-combination has changed, but the corresponding :initform for :method-combination for standard-generic-function has not been updated to reflect this. I now get an error that std-find-method-combination gets the wrong number of arguments in my test suites. I don't have a good idea how to work around this problem in Closer to MOP, so I believe I cannot officially declare support for abcl 1.2.0. Another recommendation: The *features* list currently doesn't provide a way to detect the version of abcl. Most Common Lisp implementation have one convention or the other to encode this information. If I had a workaround for the above problem, detecting the version via *features* would allow me to provide a version of Closer to MOP that works with several versions of abcl. (This may, however, not be as crucial as for the commercial implementations.) Best, Pascal -- Pascal Costanza

2 1

Re: [armedbear-devel] Site is down
by Victor 08 Apr '15

08 Apr '15

On Wed, 09 Oct 2013 16:19:45 +0300, Victor <bobbie(a)ua.fm> wrote: > On Wed, 09 Oct 2013 16:11:34 +0300, Erik Huelsmann <ehuels(a)gmail.com> wrote: > >> Thanks for the heads-up. The site should be up again. > > Hi Erik, > > the server/host is now up on the internet again but instead of a nice Welcome page it shows a directory listing that reminds me of common-lisp.net before its upgrade. The site is back again. Thanks! > > Thanks, > Victor > > >> >> >> >> On Wed, Oct 9, 2013 at 2:17 PM, Victor <bobbie(a)ua.fm> wrote: >> >>> Hi, >>> >>> I noticed that http://armedbear.org/abcl.html points to the >>> Common-Lisp.net project page that redirects to www.abcl.org that is >>> currently down. >>> >>> Is it possible either to restore the site or turn the redirect off? >>> >>> Thanks, >>> Victor >>> >>>

1 0

[armedbear-devel] Trouble trying to get example to work
by ubikation _ 08 Apr '15

08 Apr '15

I've been finding it difficult to try and understand the Java/ABCL interop. Right now I'm trying to get the official ABCL pure lisp calling java example to work to no avail: http://abcl.org/svn/tags/1.2.1/abcl/examples/pure-lisp-to-java/ Even though I have the Main.class in the local directory, and I see it when I 'echo $CLASSPATH' ABCL says "Class not found: Main". I'm using bash, I've run through the ABCL setup twice (although I'm not sure if it's right) but I am absolutely clueless. Is there a way to view/modify the classpath within ABCL?

2 1

[armedbear-devel] ASDF 3.0.3 released
by Robert Goldman 08 Apr '15

08 Apr '15

Dear Lisp hackers, I am pleased to announce the release of ASDF 2.26. Since previous release 2.25, the changes are as follows: * Run-program much improved, with a slight backward incompatibility. See the new documentation about it. * Portability enhanced, with more robust Windows support, plus patches for CCL, CLISP, LispWorks, XCL. * UIOP improved, with a README, more docstrings, a few new functions (println, writeln, stripln, ensure-gethash, vomit-output-stream), and bugfixes (to ensure-function, with-temporary-file, split-string). * Debian installations that don't export XDG_DATA_DIRS will benefit from the fix to split-string, as the bug was basically disabling the default source-registry entry for /usr/share/common-lisp/source// Closes: #723977 * Minor tweaks to the defsystem, mostly to print more information in some situations, less in other situations, but also to better handle systems with secondary names like foo/bar, a fix for user functions in output-translation, and to :version (:read-file-...) * Documentation somewhat updated. This is a very substantial bug fix release, notably on Windows, but has a stable API wrt the previous version. For this reason, CL implementations are strongly encouraged to replace previous bundled versions with 3.0.3. As always, thanks to Faré for what seems like a countless number of fixes. Thanks to Dave Cooper for many hours of testing on Windows, without whom the improvements on that platform would have been impossible. Work will soon begin on the 3.1.0 series, with some additional API features, so please make sure to pull a copy of 3.0.3 instead of the bleeding edge when you are bundling. Best, Robert

1 0

[armedbear-devel] Something is wrong with abcl.org
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Could someone who is familiar with how it should work check?

4 4

[armedbear-devel] Trying to learn abcl-asdf
by ubikation _ 08 Apr '15

08 Apr '15

I am trying to figure out how to use abcl-asdf to automate the classpath issues I've been dealing with manually in slime via (add-to-classpath "/foo/bar/..."). Are there any good examples of projects using it? I have a few jars in target/dependency that I would like to load. Thank you!

2 1

[armedbear-devel] unsubscribe
by Reinhard Oldenburg 08 Apr '15

08 Apr '15

-- Prof. Dr. Reinhard Oldenburg Goethe-Universität Frankfurt Institut für Didaktik der Mathematik und Informatik Robert-Mayer-Str. 6-8 (Sekretariat) Robert-Mayer-Str. 10, Raum 301 (Dienstzimmer) D-60325 Frankfurt/Main Telefon +49 (0)69 798 23770 Telefax +49 (0)69 798 22553 E-Mail oldenbur(a)math.uni-frankfurt.de WWW www.math.uni-frankfurt.de/~oldenbur

1 0

[armedbear-devel] ant target for maven-install-plugin
by Olof-Joachim Frahm 08 Apr '15

08 Apr '15

Hi, here is a patch attached for an ant target "abcl.mvn.install" which installs abcl- and abcl-contrib-x.y.z.jar into the local maven repository. It makes it a bit easier to get ABCL into a maven-based project if one is not particularly familiar with maven. There are more options for the plugin[1], but considering the necessary dependencies and the hassle of ant syntax I doubt it's feasible to make more available (except maybe the one to specify a different installation folder). Best regards, Olof [1]: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html

2 1

[armedbear-devel] What are you working on?
by ubikation _ 08 Apr '15

08 Apr '15

What projects are people working on using ABCL? If they are open-source, would you mind sharing a link to the repository?

1 0

[armedbear-devel] help on using cl-dot with java-objects
by Kilian Sprotte 08 Apr '15

08 Apr '15

Hi, I had a very happy start on using cl-dot with java-objects, utilizing methods such as cl-dot:graph-object-points-to directly specialized on java classes: (defmethod cl-dot:graph-object-points-to ((graph (eql 'graph)) (object (java:jclass "SomeClass"))) ...) This all went very well until I realized that java objects are boxed and a second call to the same java method returning the same java object will result in a different wrapper each time, so that in lisp they aren't eql, which is what cl-dot would expect. Now I realize that at least they are equal. But is this == or Object.equals? As an aside: Is it possible to call == from lisp? I know there has been a thread "eql for java objects" some time ago. I am looking here for a practical solution about how to use cl-dot with java objects. If anybody would like to comment on how to go about it, please go ahead. Best, Kilian

1 0

[armedbear-devel] how to load local file?
by Joe Corneli 08 Apr '15

08 Apr '15

Hello: I'm working with a Java developer and she tells me that this works: interpreter.eval("(load \"/http://people.kmi.open.ac.uk/ning/atms/decipher-atms-single-file.lisp\")"); but this doesn't: interpreter.eval("(load \"/Decipher/codes/decipher-atms-single-file.lisp\")"); Any idea about why this would be, and how we can load local code from a WAR web service?

3 2

[armedbear-devel] Bad slot value in PACKAGE-ERROR
by James M. Lawrence 08 Apr '15

08 Apr '15

(package-error-package (nth-value 1 (ignore-errors (intern "FOO" :bar)))) ;; => #<UNBOUND> (This is in anticipation of using cl-store, which when deserializing foreign code may call INTERN with an unknown package. An lfarm server handles the resulting package error. BTW lfarm runs fine on ABCL using PRINT/READ for serialization. With SBCL as a client it's a kind of FFI to java :)

2 1

[armedbear-devel] Some wrong answers from SUBTYPEP
by James M. Lawrence 08 Apr '15

08 Apr '15

;; these return NIL,NIL (subtypep 'fixnum nil) (subtypep 'string nil) (subtypep 'array nil) (subtypep 'vector nil) (subtypep 'simple-vector nil) (subtypep '(simple-array float (*)) nil) ;; OK (subtypep 'integer nil) (subtypep 'float nil) (subtypep 'bignum nil) (subtypep 'pathname nil) (subtypep t nil) (subtypep nil nil)

1 0

[armedbear-devel] Compiled type declaration and type checks (http://abcl.org/trac/ticket/323)
by Theam Yong Chew 08 Apr '15

08 Apr '15

Just an FYI (is trac open to edits for the public? I guess not), I managed to narrow down the problem here to this: http://abcl.org/trac/ticket/323 (defun test (stream) (declare ;; (type stream stream) (stream stream) ;; (optimize speed (safety 1) (debug 0)) ) (write-byte 1 stream)) (flex:with-output-to-sequence (s) (test s)) If you evaluate test (C-x C-e), the second form works. If test is compiled, (C-c C-c), then the second form fails. Some sort of type check error? The flexi-streams *is* a stream: (block a (flex:with-output-to-sequence (s) (return-from a (list (type-of s) (typep s 'stream))))) => (FLEXI-STREAMS::VECTOR-OUTPUT-STREAM T) Yong

2 1

[armedbear-devel] Email version of list?
by Steve Nunez 08 Apr '15

08 Apr '15

Hope this makes it through. It's not easy trying to find out where to sign up for the ABCL list. Does anyone know where this is done? This silly gmane web interface is complaining about lines longer than 80 characters.

3 3

[armedbear-devel] Looking for someone(s) for a project
by Alan Ruttenberg 08 Apr '15

08 Apr '15

STOP Reading here if you absolutely no interest in or bandwidth for doing work for hire. --- The project will probably *not* be implemented in lisp, but many of you can, I know, program in any language. We do intend that the server side be based on the JVM so that there is flexibility in choice of language used. Whether or not lisp can be used, and to what extent, will depend on how persuasive I am in convincing the group that owns the existing system that allowing development in a number of different languages is a Good Thing. One project is to help start moving a legacy windows(PowerBuilder, .net, SQL server)-based app, typically accessed through Citrix, towards a standards-based web platform (e.g. firefox on the client). The strategy is to start adding new functionality using web standards and have them interoperate with the existing system. As time permits they will move old functionality over. The system is an electronic dental record and so issues that will have to be dealt with are having secure connections, coordinated timeouts of screens (after any activity in either the app window or web app the timer is reset, after the last activity windows need be locked). This means there has to be a system by which windows on both sides of the application are coordinated, with failsafes in the case of losing network connectivity. Other issues to address are: - Coordination with Citrix - ideally the VPN enabling the web app is carried by the single Citrix connection. - Storage backend. There is interest in having new storage being triple-store-based. - Possibility of using AWS Perhaps by the same person, or by another, we will want to start building functionality on the web side. In this case I would want someone with solid experience using a modern javascript toolkit and either direct design experience or who works with a designer. I would expect to see a portfolio of previous work. Telecommuting will be an option, though there may be need for a visit to Buffalo at some point in the project. Schedule: It would be beneficial to aim for a quick proof of concept, then move into development. The next milestone will be deployment in a new clinic in a matter of months (legacy plus whatever new functionality we can add during that time). How much effort is spent in the legacy system versus in the new standards-based system depends on how quickly we can show that the strategy works and can be a reasonable basis for development. A likely project is to extend the current system with the ability to record medical history, with this interaction taking place on the web side. The project, all told, could exercise quite a spectrum of skills. Depending on the people working on the project, and the needs of the future clinic denizens we will obviously need to be strategic in setting prioritizes and crafting a plan. The ideal candidate would have experience and previous success in planning implementation so they can be a useful participant in our project strategizing. If you are perhaps interested in this work, please contact me offline at alanruttenberg(a)gmail.com with the understanding that while I am tasked getting some leads on skilled programmers I am not the person responsible for hiring. But I'll have influence and will have some level of ongoing relation to the project. Regards, Alan ps. I think the project will be fun. YMMV.

1 0

[armedbear-devel] Building from trunk broken?
by Alan Ruttenberg 08 Apr '15

08 Apr '15

I'm getting boatloads of messages of the sort: [java] Failed to require CLOS because 'The function (SETF VALUES) is undefined.' [java] ; SYSTEM:%MAKE-CONDITION triggers autoloading of org.armedbear.lisp.make_condition ... [java] ; Autoloaded org.armedbear.lisp.make_condition (0.0030 seconds) [java] Failed to require PRINT-OBJECT because 'Don't know how to REQUIRE CLOS.' [java] ; COMMON-LISP:INVOKE-DEBUGGER triggers autoloading of debug ... [java] ; Autoloaded debug (0.013 seconds) [java] ; COMMON-LISP:FRESH-LINE triggers autoloading of pprint ... [java] ; Loading /Users/alanr/repos/abcl/src/org/armedbear/lisp/print.lisp ... [java] ; Loaded /Users/alanr/repos/abcl/src/org/armedbear/lisp/print.lisp (0.053 seconds) [java] ; Loading /Users/alanr/repos/abcl/src/org/armedbear/lisp/print-object.lisp ... [java] ; Loading /Users/alanr/repos/abcl/src/org/armedbear/lisp/clos.lisp ... [java] Failed to require CLOS because 'The function (SETF VALUES) is undefined.' [java] Failed to require PRINT-OBJECT because 'Don't know how to REQUIRE CLOS.'

1 1

[armedbear-devel] Why field LispStatckFrame.UNAVAILABLE_ARG is not static ?
by Dmitry Nadezhin 08 Apr '15

08 Apr '15

Memory profiling of ABCL shows that the classes with largest allocation count are LispStackFrame and LispStackFrame.UnavailableArgument . It seems to me that LispStatckFrame.UNAVAILABLE_ARG can be a singleton object, can't it ? =================================================================== --- LispStackFrame.java (revision 14571) +++ LispStackFrame.java (working copy) @@ -44,7 +44,7 @@ private final LispObject third; private final LispObject[] args; - private final class UnavailableArgument extends LispObject + private static final class UnavailableArgument extends LispObject { public UnavailableArgument () { } @Override @@ -53,7 +53,7 @@ } } - private final LispObject UNAVAILABLE_ARG = new UnavailableArgument(); + private static final LispObject UNAVAILABLE_ARG = new UnavailableArgument(); public LispStackFrame(LispObject operator) { ====================================================================

2 1

[armedbear-devel] Fwd: One-jar
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Howdy, I was wondering whether anyone had tried to use this with ABCL. Looks like a nice packaging solution but I'm not sure how it would interact with ABCL's classloader (yes I can try :) ) -Alan ---------- Forwarded message ---------- From: Blaisure, Jonathan <jcblaisu(a)buffalo.edu> Date: Wed, Nov 13, 2013 at 9:12 AM Subject: One-jar To: Alan Ruttenberg <alanruttenberg(a)gmail.com> http://one-jar.sourceforge.net/ Might be useful. -- Regards, Jonathan Blaisure, MS ---------------------- *Database Administrator* *Institute for Health care Informatics* 716.878.2996

3 3

[armedbear-devel] Lazy allocation of LispStackFrames
by Dmitry Nadezhin 08 Apr '15

08 Apr '15

LispStackFrame object are allocated on every LispThread.execute(...) . However, they are seldom (to inspect stack trace). This patch delays allocation of LispStackFrame objects until they are requested. Raw information about stack frames is stored in stack. Stack is an Object[] array ( more precisely a list of 8 MB Object[] arrays ).

3 3

[armedbear-devel] Pdfdoclet - Javadoc for ABCL in PDF format
by Sean Champ 08 Apr '15

08 Apr '15

Hello! In brief: Attached is a shell script for running pdfdoclet[6], a Javadoc doclet component that generates PDF format documentation, instead of HTML, when used with the javadoc tool. For sake of convenience, I was going to send the PDF format ABCL javadoc generated by pdfdoclet, but the resulting PDF file is 13.3 megs in size. Maybe the little utility shell script, as attached, could be enough. The PDF javadoc could be useful, i think, in the interest of studying ABCL's Java API - perhaps more intermediately, for modeling ABCL's Java API in UML - for instance, using Modelio[1], Argo[2], or Papyrus[3], on the laptop, and Cubetto Mobile[4] on the tablet. As an additional plug: As far as the PDF format itself, and PDF's annotation support, typically on mobile, i tend to prefer Goodreader[5]. It offers good support for PDF annotations and so on. PDFDoclet can also be used from Ant. I'm not very well familiar with Ant, offhand. Of course, I notice that Ant is used in ABCL - will take a look... Cheers! [1] http://www.modeliosoft.com/ [2] http://argouml.tigris.org/ [3] http://www.eclipse.org/papyrus/ [4] http://www.semture.de/en/cubetto-mobile-en/overview [5] http://www.goodiware.com/goodreader.html [6] http://pdfdoclet.sourceforge.net/ <http://pdfdoclet.sourceforge.net/><http://www.semture.de/en/cubetto-mobile-en/overview><http://www.eclipse.org/papyrus/>

2 1

[armedbear-devel] mvn snapshots
by Cyrus Harmon 08 Apr '15

08 Apr '15

The attached patch adds support for maven snapshot versions with the following defsystem component syntax: (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6" :snapshot t) I’m open to other suggestions to solving this, but this works for my immediate needs. thanks, Cyrus

3 8

[armedbear-devel] Re: What are you working on?
by Rolando Pereira 08 Apr '15

08 Apr '15

ubikation _ <ubikation-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> writes: > What projects are people working on using ABCL? If they are > open-source, would you mind sharing a link to the repository? Since the lack of answers is slightly disappointing I guess I can post something regarding an experiment I did an afternoon a couple months ago which tried to link Jython to ABCL. Since it was an experiment I didn't put the source code online. Also currently the source is basically just a "*slime-scratch*" buffer saved to a file which means that the code is a hairy mess. But here's an example to show how to use it: > (add-to-classpath "/home/rolando/src/jython/jython-standalone-2.5.3.jar") > (defvar *interpreter* (jss:new 'org.python.util.PythonInterpreter)) > > (#"exec" *interpreter* "import feedparser") > > (defvar *rss-parse* (gethash "parse" > (py-unwrap (#"getDict" > (gethash "feedparser" > (py-unwrap (#"getLocals" *interpreter*))))))) > > ;; Get the ABCL mailing list RSS > (defvar *rss* (pycall *rss-parse* "http://rss.gmane.org/gmane.lisp.armedbear.devel")) Having defined the "*rss*" variable you can then do this: > CL-USER> (gethash "title" (nth 1 (gethash "entries" (py-unwrap *rss*)))) > "Web frameworks with ABCL (was Re: SBCL->ABCL migration questions)" > T Something I wanted to make was importing the Python modules as Lisp functions so instead of defining the "*rss-parse*" as > (defvar *rss-parse* (gethash "parse" > (py-unwrap (#"getDict" > (gethash "feedparser" > (py-unwrap (#"getLocals" *interpreter*))))))) you could do: > (feedparser:parse "http://rss.gmane.org/gmane.lisp.armedbear.devel") and that would also allow you slime's autocomplete to complete the python code. I've thought about doing the above using a macro around the "inspect" Python module, but never got around to it. Best Regards, Rolando Pereira

1 0

[armedbear-devel] MQTT example using ABCL and Eclipse Paho
by Frederico Munoz 08 Apr '15

08 Apr '15

Hi all, I have written a simple example of using the Eclipse Paho libraries, via ABCL, to send messages in Common Lisp using MQTT. I will not write much more here since it's in the article which contains the code and some other considerations: http://finisterra.motd.org/?p=237 As I note I initially did this in Clojure so - and just like my experiments with Swing before which I sent to the list as well - this is in a way a comparison on how the interop facilities work. My code is not exactly stellar (either the Clojure or the CL one) but it is, I hope, easy enough to understand and follow, especially since I couldn't found any other example out there, which is why I thought the list could have some use for it (even if only for future reference). I stumbled a bit on getting the command-line arguments but that was due to my custom-made abcl script end with $@ instead of "@" - something to watch for :) I had one problem that I found weird and which I would welcome any help, I'm not sure why the following works: CL-USER(3): (#"currentThread" 'Thread) #<java.lang.Thread Thread[interpreter,5,main] {BD30B16}> ... but the following doesn't: CL-USER(4): (#"sleep" 'Thread 100) #<THREAD "interpreter" {19AA4D78}>: Debugger invoked on condition of type ERROR no such method Restarts: 0: TOP-LEVEL Return to top level. For another short demo I have I will need to subclass, something used in Swing programming a lot from what I could understand. If I'm not mistaken this isn't currently supported in ABCL, but I will read on it. Best regards, Frederico

3 3

[armedbear-devel] Java 6+ Type-checking bytecode verifier compatible output: requirements analysis
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi all, At ECLM the other week, Alessio and I agreed to start working on a requirements analysis regarding the output required for the type-checking bytecode verifier. We know Mark wants to create an intermediate level code representation to address any issues that may arise. However, we want to assess requirements first and come up with a solution after that. That solution may or may not depend on such an intermediate representation. For now, we'd like to leave that undecided. So, what I learned that the type-checking bytecode verifier wants is that it can verify the state of the stack and of the locals for all bytecode instructions. In order to do so, it needs: 1. The "initial state" of stack and locals at the external entry points of a function (ie notably the start and any exception handlers) 2. Optional "state modifications" when locals start being used or when the flow from one instruction to another is broken (such as in case of (conditional) jumps) Apart from a different class file version number and an attribute to store this information in, that's it. More doesn't the verifier want to know. Is it your understanding as well that this is all that is required? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[armedbear-devel] c++ library FreeLing from ABCL
by Alexandre Rademaker 08 Apr '15

08 Apr '15

I am trying to use a C++ library called FreeLing from ABCL (using the library JAVA API). I have just posted a question in http://stackoverflow.com/questions/17556912/calling-freeling-java-api-from- abcl. Does anyone know of any limitation of ABCL to deal with the System.load of Java? Best, Alexandre

3 7

[armedbear-devel] Bug: COND clauses must have a test
by Pascal J. Bourguignon 08 Apr '15

08 Apr '15

The syntax for COND is: cond {clause}* => result* clause::= (test-form form*) therefore (cond ()) should be a program-error, but abcl 1.0.1 returns NIL. -- __Pascal Bourguignon__ http://www.informatimago.com/

2 1

[armedbear-devel] Next steps on our way to usability
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi all, With support for CloserMOP now almost released (great job! Thanks Rudi, Pascal and everybody who helped out!), I'm looking forward to see how we can run more quicklisp packages. If you look at http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.h… and the load failures recently published for 1.2.0, you'll see that the root blockers now (apart from cl-glfw-opengl-core<http://cl-test-grid.appspot.com/blob?key=1fgcximsyj> which fails due to a missing dynamic library) portability libraries: uffi, iolib.base, kmrcl, acl-compat and metatilities. Seems we're looking for people who want to submit portability code to these projects! Bye, Erik.

2 2

[armedbear-devel] Some convenience functions
by Theam Yong Chew 08 Apr '15

08 Apr '15

Hi all, I've got a bunch of useful functions for general hacking with abcl. Hope they could be useful. Any suggestions on the best place for sending patches (if indeed they are useful enough). abcl contribs, slime contribs, or core abcl? Yong ;; javap seems to be bundled/more widely available compared to the defaults (defun disassemble-class-cmd (path) (with-accessors ((d pathname-directory) (n pathname-name)) (merge-pathnames path) (format nil "cd ~{/~a~}; javap -c ~a" (cdr d) n))) (defun disassemble-class (path) (ext:run-shell-command (disassemble-class-cmd path))) (setf system::*disassembler* #'disassemble-class-cmd) (in-package :swank) (defmethod menu-choices-for-presentation ((throwable java:java-exception)) "Java exception stack traces (different from Lisp stack traces) are also available." (list (list "printStackTrace" (lambda (choice object id) (declare (ignore choice id)) ;; TODO, print to an Emacs buffer instead (java:jcall "printStackTrace" *standard-output* (java:java-exception-cause object)))))) (in-package :swank-backend) ;; Not real frame local variables, but it at least exposes function ;; arguments for possible inspection (defimplementation frame-locals (index) (loop for id upfrom 0 for item in (java:jcall "toLispList" (nth-frame index)) collect (let () ;; ((id id) (item item)) (list :name "??" :id id :value item)))) (defimplementation frame-var-value (index id) (elt (java:jcall "toLispList" (nth-frame index)) id))

2 1

[armedbear-devel] ABCL 1.2.1 Release
by Mark Evenson 08 Apr '15

08 Apr '15

We think that [abcl-1.2.1][] represents the final release engineering work for the version available at ECLM 2013. A description of the [CHANGES] is included with the source. Upcoming in abcl-1.3.0: o per function call stack and memory exception handler in CL:COMPILE o further fixes in Quicklisp, q.v. [abcl-1.2.1]: http://abcl.org/releases/1.2.1 [CHANGES]: http://abcl.org/svn/tags/1.2.1/abcl/CHANGES

1 0

Re: [armedbear-devel] 20130823a Diffs for chemicalamba (Akka bridge in ABCL)
by Mark Evenson 08 Apr '15

08 Apr '15

On Aug 22, 2013, at 9:37 PM, ubikation _ <ubikation(a)gmail.com> wrote: > Hey Mark, > > I really appreciate your help but I am having trouble understand the diffs that you are sending me. I understand that HG is generating them but I am having trouble recreating your state. What tools do you recommend? I understand that creating a huge class isn't a good Java practice and I'm happy to break it up but it was hard for me to figure out exactly what goes where according to your diffs. […] For any software development, open or not, coming to terms with "diffs" is a basic skill that has no "right answer" for the tools one uses. A "diff" is a standardized format, used by a variety of tools including most IDEs these days. But in the beginning there was the command line, so the first tools you should come to terms with are diff(1) and patch(1): cmd$ [[[clone repo into "./chemicalambda"]]] cmd$ cd chemicalambda cmd$ patch -p 1 < file-that-contains-the-diff.diff The "-p 1" strips the top-level of the hierarchy, and then patch reads the contents of stdin for changes to make. One will see either success or error messages in applying the diff. Re-do until you get the results you want, then deal with the changes in your own version control ecology. What I like about hg is that one can just directly import a diff into the repo: cmd$ hg import file-that-contains-the-diff.diff but git certainly has similar functionality, somewhere. I avoided a comprehensive understanding diffs for many years, much to my own detriment.

1 0

[armedbear-devel] Unsubscribe
by Wayne Rogers 08 Apr '15

08 Apr '15

1 0

[armedbear-devel] bug: example java-to-lisp1 does not compile (ABCL 1.2.1)
by David Catteeuw 08 Apr '15

08 Apr '15

Hello, While experimenting with ABCL, i noticed that the example "java-to-lisp1" cannot be compiled using ABCL 1.2.1. It does compile using ABCL 1.1.1. The method "findPackage(String)" seems to have disappeared from "Packages" in the new release. java-to-lisp1$ javac -cp /Applications/Dev/abcl-1.1.1/abcl.jar:. *.java java-to-lisp1$ javac -cp /Applications/Dev/abcl-1.2.1/abcl.jar:. *.java MainAlternative.java:39: cannot find symbol symbol : method findPackage(java.lang.String) location: class org.armedbear.lisp.Packages Packages.findPackage("CL-USER"); ^ 1 error java-to-lisp1$ java version "1.6.0_51" Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-10M4509) Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode) java-to-lisp1$ javac -version javac 1.6.0_51 java-to-lisp1$ Kind regards, david.

2 2

Re: [armedbear-devel] threads:interrupt-thread
by Carlos Ungil 08 Apr '15

08 Apr '15

Hello Erik, I don't know how to debug java processes but I have an intuition about why those threads are not interrupted: they're never waiting. See the example below: an interruption scheduled for the interpreter thread is only executed when I put the thread to sleep (and if the garbage collector runs in the meantime it's lost). The reason why I cared about being able to interrupt the main thread was to run finalizers from there, to avoid concurrency issues in a foreign library. In the end I implemented an alternative solution using locks so I'm not really concerned about this problem anymore. Regards, Carlos CL-USER(1): (let ((main (threads:current-thread))) (threads:make-thread (lambda () (threads:interrupt-thread main (lambda () (print "Hi there!")))))) #<THREAD {3AF6EA95}> CL-USER(2): (* 2 2) 4 CL-USER(3): (sleep 1) "Hi there!" NIL CL-USER(4): (let ((main (threads:current-thread))) (threads:make-thread (lambda () (threads:interrupt-thread main (lambda () (print "Hi there!")))))) #<THREAD {CE5A31A}> CL-USER(5): (gc) 462843184 CL-USER(6): (sleep 1) NIL On 06/09/2013, at 21:49, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi Carlos, > > > is there a reason why interrupt-thread doesn't seem to run the requested function in some cases? The following code tries to run a function in each existing thread (the variable *output* logs the calls that we try to run and the ones that are actually run). > > Looking at your code, there may be multiple causes for the strings not showing up in the output. Frst of all, there's a problem with concurrency in your code: pushing into the *output* variable across threads isn't thread safe. The other reason for the code not being executed could be a bug: the code "checks manually" whether the thread interrupt has been invoked and executes the function(s) handed over. Maybe these threads land in loops that do not check this condition. > > (defvar *output*) > > > > (defun test-run () > > (setf *output* nil) > > (threads:mapcar-threads > > (lambda (thread) > > (push (format nil "~A : calling" thread) *output*) > > (threads:interrupt-thread thread > > (lambda () > > (push (format nil "~A : running" thread) *output*)))))) > > > > (defun test-report () > > (format t "~{~A~%~}" (reverse *output*))) > > > > Running in the command line: > > [snip] > > > > > I can understand that the thread "TEST-RUN" that I create to run the function might disappear before it gets to run the function as requested, or maybe the reason is that a thread can't interrupt itself by design... But why doesn't the thread "interpreter" run the function? > > > > Running in slime there are many threads present, and most of them will respond as expected. But "TEST-RUN", "interpreter" and "reader-thread" won't. > > Can you interrupt the reader-thread and interpreter thread in a java debugging environment and tell me what the stack trace is when you send the signal that isn't being processed? Maybe the answer turns out to be really obvious. > Thanks! > > Bye, > > > Erik. >

1 0

[armedbear-devel] [CfP] International Lisp Conference, Aug. 14-17 2014, Montréal, Canada
by Didier Verna 08 Apr '15

08 Apr '15

ILC 2014 - International Lisp Conference "Lisp on the Move" August 14-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. We invite high quality submissions in all areas involving Lisp dialects and any other languages in the Lisp family, including, but not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. This year's focus will be directed towards integrated solutions, including mobile computing. We especially invite submissions in the following areas: * Pervasive computing * Interoperability * Portability * Implementation challenges/tradeoffs for embedded/mobile platforms * Language support for mobile toolkits and frameworks * Language support for distribution * Language support for reliability, availability, and serviceability * Mobile IDEs * Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation * Language integration, inter-operation and deployment * Applications (especially commercial) * Reflection, meta-object protocols, meta-programming * Domain-specific languages * Programming paradigms and environments * Efficient parallel and concurrent computation * Language support for managing both manual and automatic GC * Theorem proving * Scientific computing * Data mining * Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May 18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: to be announced Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org For more information, see http://www.international-lisp-conference.org -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[armedbear-devel] EXT:URL-PATHNAME vs http: as a logical pathname
by Karsten Poeck 08 Apr '15

08 Apr '15

Hello all, I am trying to compile cl-http on abcl. Mostly got it loading, but have some problems with abcls url-pathnames. Example: CL-USER> (lisp-implementation-version) "1.2.1" "Java_HotSpot(TM)_64-Bit_Server_VM-Apple_Inc.-1.6.0_51-b11-456-11M4508" "x86_64-Mac_OS_X-10.8.4" CL-USER> (lisp-implementation-type) "Armed Bear Common Lisp" CL-USER> (setf (logical-pathname-translations "http") '( ("port;**;*.*" "/Users/karstenpoeck/Documents/workspace/trunk/contrib/kpoeck/port-templa te/**/*.*") ("**;*.*" "/Users/karstenpoeck/Documents/workspace/trunk/**/*.*") ) ) ((#P"HTTP:PORT;**;*.*" #P"/Users/karstenpoeck/Documents/workspace/trunk/contrib/kpoeck/port-temp late/**/*.*") (#P"HTTP:**;*.*" #P"/Users/karstenpoeck/Documents/workspace/trunk/**/*.*")) ;;;; the problem is here CL-USER> (translate-logical-pathname "http:declaration.lisp") #P"http:" If I do the same with httpx: instead of http:, the code loads fine. The reason is probably the following. CL-USER> (type-of (pathname "http:declaration.lisp")) URL-PATHNAME Later starting up cl-hhtp i get: http:www;foo.html has a null authority. http:www;foo.html has a null authority. http:proxy-cache; has a null authority. http:pw;random-seed.lisp has a null authority. java.lang.NullPointerException at sun.net.www.ParseUtil.toURI(ParseUtil.java:261) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnectio n.java:905) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.jav a:836) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnect ion.java:1172) at java.net.URL.openStream(URL.java:1010) at org.armedbear.lisp.Pathname.getInputStream(Pathname.java:2369) .... I completely understand that it is desirable to have (load "http://beta.quicklisp.org/quicklisp.lisp") working, but can't you check for "http://" or "https://" before converting a pathname to an url-pathname? Karsten

2 2

[armedbear-devel] Unsubscribe
by Wayne Rogers 08 Apr '15

08 Apr '15

2 1

[armedbear-devel] Status of 1.2.0
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Mark, all, My own testing didn't reveal any notable problems, nor did the ANSI test suite. There are a few regressions in cl-test-grid which indicate our changes to symbol interning. My proposal is to go forward with the 1.2 release and release a bugfix as soon as we identify and fix the problem which the cl-colors tests indicate. What's your position? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 12

[armedbear-devel] Desperate for a chance to hack with ABCL all day
by ubikation _ 08 Apr '15

08 Apr '15

Greetings! As you may know from my ramblings I'm new to Common Lisp and ABCL in particular. I'm not an experienced coder but I'm really enjoying the time I'm spending becoming more familiar with ABCL/Slime/Emacs. Would anybody be interested in me working for them for a low ($15) hourly contract? I really am desperate for work and and a chance to prove myself. Thank you very much for your time and consideration. I am happy to give more personal information for anybody who is interested.

1 0

[armedbear-devel] Hadoop Anyone?
by Steven Núñez 08 Apr '15

08 Apr '15

Greetings All, I’ve got another ‘big data’ project on the go, and rather than program in Java, I thought I’d give LISP a go. There are ways to program Hadoop with Clojure<http://alexott.net/en/clojure/ClojureHadoop.html>, but I’d rather not learn a non-standard lisp if I can avoid it. Has anyone got ABCL working as a Hadoop map/reduce program? I’d prefer native, but streaming will do if need be. Regards, - SteveN

1 0

[armedbear-devel] ensure-parsed-mvn not yet exported in abcl-asdf.lisp
by Cyrus Harmon 08 Apr '15

08 Apr '15

The recent addition of the asdf:ensure-parsed-mvn call in the RESOLVE defmethod form has the problem that the ensure-parsed-mvn symbol isn’t exported at the time the defmethod is compiled. Assuming that the intended behavior of export is not to change things at compile time, we need to wrap the export call in an appropriate eval-when form. The following seems to fix things for me: diff --git i/contrib/abcl-asdf/abcl-asdf.lisp w/contrib/abcl-asdf/abcl-asdf.lisp index 401487b..b96457e 100644 --- i/contrib/abcl-asdf/abcl-asdf.lisp +++ w/contrib/abcl-asdf/abcl-asdf.lisp @@ -85,8 +85,9 @@ (defun ensure-parsed-mvn (component) (setf path (format nil "~A/~A/~A" group-id artifact-id version)))) component)) -(export `(mvn iri ensure-parsed-mvn group-id artifact-id version) - 'asdf) +(eval-when (:compile-toplevel :load-toplevel :execute) + (export `(mvn iri ensure-parsed-mvn group-id artifact-id version) + 'asdf)) (defmethod source-file-type ((component iri) (system system)) nil)

2 2

[armedbear-devel] abcl 1.2.1 ignores :resolve-symlinks parameter of directory
by Gabor Balazs 08 Apr '15

08 Apr '15

hY, Armed Bear Common Lisp 1.2.1 Java 1.6.0_27 Sun Microsystems Inc. OpenJDK 64-Bit Server VM ls -l -rw-r--r-- 1 user group 0 Dec 15 11:00 file lrwxrwxrwx 1 user group 4 Dec 15 11:00 link -> file CL-USER(3): (directory "./*" :resolve-symlinks nil) (#P"/home/user/test/file" #P"/home/user/test/file") The result should be (#P"/home/user/test/file" #P"/home/user/test/link"). Or do I miss something? Thanks, `bg`

1 0

[armedbear-devel] Link from Twitter
by Mark Evenson 08 Apr '15

08 Apr '15

www.oracle.com/technetwork/java/javase/7u25-relnotes-1955741.html Download the official Twitter app here Sent from my iPad

1 0

[armedbear-devel] bogus (t ...) function call
by Cyrus Harmon 08 Apr '15

08 Apr '15

I finally realized where the warning about calling the undefined function T was coming from: diff --git a/contrib/abcl-asdf/abcl-asdf.lisp b/contrib/abcl-asdf/abcl-asdf.lisp index b96457e..2ded8b5 100644 --- a/contrib/abcl-asdf/abcl-asdf.lisp +++ b/contrib/abcl-asdf/abcl-asdf.lisp @@ -130,8 +130,7 @@ (defmethod resolve ((mvn-component asdf::mvn)) (resolve-dependencies group-id artifact-id version) (if alternate-uri (values (namestring alternate-uri) alternate-uri) - (t - (error "Failed to resolve MVN component name ~A." name)))))) + (error "Failed to resolve MVN component name ~A." name))))) (defmethod resolve ((uri pathname)) (warn "Unimplemented.")) Looks like this was copy/pasted from a cond form elsewhere. Cyrus

1 1

[armedbear-devel] Re: cl-test-grid: Testing ABCL-1.2.0-RC
by Mark Evenson 08 Apr '15

08 Apr '15

Agreed: fixing STD-FIND-METHOD-COMBINATION seems to be necessary. @anton: thanks for the tests @rudi: dunno if this is you, but could you take a look to see if this is easy? If you fix on trunk, I will take care of the release. At this point, I would release abcl-1.2.1 and announce, as abcl-1.2.0 has already been "softly launched" without announcement. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email? On Jun 9, 2013, at 1:15, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > 08.06.2013, 02:35, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >> 08.06.2013, 02:13, "Erik Huelsmann" <ehuels(a)gmail.com>: >> >>> Hi Anton, >>> Could you test ABCL-1.2.0-RC with the latest Quicklisp snapshot and publish reports? I'd love to see how we're doing in the CL ecosystem before we release! >>> >>> Thanks! >>> >>> Bye, >>> >>> Erik. >> >> Hello, Erik. >> >> Just today I started the tests, on the 1.2.0 source tarball from abcl.org and on the current svn head. >> They are running on your VM. The results will be a day or two later. >> >> Best regards, >> - Anton > > Hello again. > > The results for ABCL 1.2.0 RC (the soruce tarball form abcl.org) are ready. > Comparision with ABCL 1.1.1: > http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff10.html > > As you see there are some regressions - results that were green and have become red. > Most of the seem to be caused by the same error: Wrong number of arguments for #<STD-FIND-METHOD-COMBINATION {17D2F0E}>. > > Best regards, > - Anton

5 7

[armedbear-devel] Fix MAKE-FUNCTION-POINTER for abcl-1.2.1 with jna-4.0.0.
by Mark Evenson 08 Apr '15

08 Apr '15

A [fix for CFFI with function pointers when using jna-4.0.0][1] and [the corresponding naked diff][2]. Can’t quite seem to figure out how to make a “pull request” out of this. *sigh* [1]: https://github.com/easye/cffi/commit/0f63798ab20e274d3062964a3286e34855747d… [2]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-encoding-20131124a.diff -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[armedbear-devel] FIND-SYSTEM-JAR ignores versioned jars
by Olof-Joachim Frahm 08 Apr '15

08 Apr '15

Hi, I've noticed (while building with Maven), that the versioned system and contrib jars aren't found properly because of how the loader constructs the pathnames. Attached are three patches to clean up abcl-contrib.lisp a bit and then fix this by accepting every matching pathname directly. This still doesn't check for the correct version string, but maybe that's not a problem. Best regards, Olof

2 3

[armedbear-devel] COMPILE-FILE fails with stack overflow when INLINE meets recursion
by Xiaofeng Yang 08 Apr '15

08 Apr '15

Hi, all. It seems that cl-prime-maker compiles failed with ABCL because of the following bug. This bug can also be found in ABCL 1.1.1 (I don't know whether this bug can be found in 1.1.0 or earlier), not only 1.2.x and 1.3.x. $ cat bug-for-abcl.lisp (in-package :cl-user) (declaim (inline foo)) (defun foo () (foo)) (defun bar () (foo)) $ ~/abcl/abcl Armed Bear Common Lisp 1.3.0 Java 1.8.0 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.364 seconds. Startup completed in 1.739 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "bug-for-abcl.lisp") ; Compiling /tmp/bug-for-abcl.lisp ... ; (IN-PACKAGE :CL-USER) ; (DECLAIM (INLINE FOO)) ; (DEFUN FOO ...) ; (DEFUN BAR ...) #<THREAD "interpreter" {776DDE2A}>: Debugger invoked on condition of type STORAGE-CONDITION Stack overflow. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): After the stack overflow, if I returned to the top level, remove the line "(declaim (inline foo))" and COMPILE-FILE again, it also failed. Unless I restart ABCL and perform COMPILE-FILE with the file without the line "(declaim (inline foo))", it can be compiled now. Best regards, Xiaofeng Yang

2 1

[armedbear-devel] :back not supported?
by Faré 08 Apr '15

08 Apr '15

See https://bugs.launchpad.net/asdf/+bug/1260011 http://www.lispworks.com/documentation/HyperSpec/Body/19_bbdc.htm [2] CL-USER(5): (make-pathname :directory '(:relative :back)) #<THREAD "interpreter" {2B3B7C28}>: Debugger invoked on condition of type FILE-ERROR Unsupported directory component BACK. Restarts: 0: ABORT Return to debug level 2. 1: ABORT Return to debug level 1. 2: TOP-LEVEL Return to top level. [3] CL-USER(6): (lisp-implementation-version) "1.2.1" "OpenJDK_64-Bit_Server_VM-Sun_Microsystems_Inc.-1.6.0_27-b27" "amd64-Linux-3.8.0-34-generic" [3] CL-USER(7): I suppose I can try to paper over it in ASDF. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey

2 1

[armedbear-devel] latest cl-test-grid testing
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. I have recently preformed cl-test-grid tests runs for several ABCL versions, and reviewed the results now. Two things I want to report. 1. Some degradation of error handling is introduced somewhere between abcl-1.2.0-fasl42 and abcl-1.3.0-dev-svn-14580-fasl42. It may be noticed when loading ASDF systems :cells and :test-gtk (the latter is from the cells-gtk3 project). ASDF:load-op fails for these systems with stack overflow. Old ABCL allows me to catch the stack overflow error and record asdf:load failure, while new ABCL sometimes crashes - the java process terminates: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff16.html To reproduce the situations on the cl-test-grid.cloud.efficito.com machine, lets ql:quickload the :cells system and save the ABCL process output: Old ABCL: java -jar ~/lisps/abcl-1.2.0/dist/abcl.jar --noinit --nosystem --batch --load ~/cl-test-grid/work-dir/agent/quicklisp/setup.lisp --eval '(handler-case (ql:quickload :cells) (serious-condition (e) (format t "!!! Serious condition occurred: ~A !!!~%" (type-of e))))' > log 2>&1 && less log Old ABCL always behave the same: prints the stacktrace, and then prints the message from our handler-case - "!!! Serious condition occurred .." New ABCL: java -jar ~/lisps/abcl/dist/abcl.jar --noinit --nosystem --batch --load ~/cl-test-grid/work-dir/agent/quicklisp/setup.lisp --eval '(handler-case (ql:quickload :cells) (serious-condition (e) (format t "!!! Serious condition occured: ~A !!!~%" (type-of e))))' > log 2>&1 && less log New ABCL sometimes only prints the "!!! Serious condition occurred ..." message from our handler-case, without the stack trace. But sometimes it doesn't invoke our handler-case at all, and instead prints a stack trace as shown below, and then java process exits: Exception in thread "interpreter" java.lang.ClassCastException: org.armedbear.lisp.Symbol cannot be cast to org.armedbear.lis p.LispThread$StackMarker at org.armedbear.lisp.LispThread.getStackTop(LispThread.java:721) at org.armedbear.lisp.LispThread.pushStackFrame(LispThread.java:736) at org.armedbear.lisp.Lisp.pushJavaStackFrames(Lisp.java:374) at org.armedbear.lisp.Lisp.stackError(Lisp.java:388) at org.armedbear.lisp.asdf_134.execute(asdf.lisp:1436) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.asdf_402.execute(asdf.lisp:4458) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.asdf_675.execute(asdf.lisp:6127) The full stacktrace is in the file attached. As you can see, the problem is caused by ClassCastException when handling the first (stack overflow) error. Why the ClassCastException doesn't happen always - I don't know. Maybe it depends on the internal state of the ABCL process. 2. Erik asked whether cl-test-grid testing becomes faster after the patch for "Lazy allocation of LispStackFrames". There is no noticeable speedup, full test run on both new and old ABCL takes around 18 hours. For your information: in cl-test-grid every ASDF system and every testsuite is peformed in a separate process, in total around 1500 processes are started. It might be the case that in some other use case, lisp code execution has speedup, but in cl-test-grid it is not noticeable. Best regards, - Anton

1 0

[armedbear-devel] "Hardcoding" methods that funcall a symbol
by Theam Yong Chew 08 Apr '15

08 Apr '15

Hi all, This is old history, but I remember seeing some really old email threads about hardcoding of Lisp function (as symbols) calls into Java methods. Attached please find a patch for trying this out. I refactored the original method body generation code slightly, then added java::runtime-class-add-symbol-method-body which involves low level bytecode generation, so I'd appreciate additional checks/reviews (I believe the repetitive load/store sequences won't have any effects with the JIT & optimisers, but may be fractionally easier to decompile...). I also updated java:jnew-runtime-class's docstring, but I'm not sure if the wording "function designator" is accurate enough, since (funcall '(lambda () 1)) => 1 Would '(lambda () 1) be considered a FUNCTION DESIGNATOR? In any case, java::runtime-class-add-methods already works with it just the same. This code has not been rigorously tested as it doesn't work in abcl-1.2.1 (tested/works for older versions) due to a regression, since fixed in r14570 (Restore Packages.findPackage() API...Fixes #324). See appendix, where I include a start for some tests. And in case it isn't obvious, the hardcoding of symbol funcalls (test3) into a class method is the only new functionality here. Yong (defun test3 (this) "test3") (defun test4 (this x y z) (+ x y z)) (defparameter *test-class* (java:jnew-runtime-class "runtime_class" :methods `(("test1" "java.lang.String" () ,(lambda (this) "test1")) ("test2" "java.lang.String" () (lambda (this) "test2")) ("test3" "java.lang.String" () test3) ("test4" "java.lang.Object" ;; (:int :int :int) ;; unsupported for now ("java.lang.Object" "java.lang.Object" "java.lang.Object") ,(function test4)) ("test5" "java.lang.String" ("java.lang.String") (lambda (this x) (declare (ignore x)) "test5")) ("undefined" :void () undefined)))) (let ((obj (java:jnew *test-class*))) (list (java:jcall "test1" obj) (java:jcall "test2" obj) (java:jcall "test3" obj) (java:jcall "test4" obj 1 2 3) (java:jcall "test5" obj "foo"))) ==> ("test1" "test2" "test3" 6 "test5") ;; This should thrown an error... (java:jcall "undefined" (java:jnew *test-class*)) ;; As should this, but java.lang.NoSuchMethodException: No applicable method is not very obvious... (java:jcall "test5" (java:jnew *test-class*)) ;; This shouldn't, but does, see stack trace below, (quite relatedly, at least for me using Slime, (java:jcall "undefined" (java:jnew *test-class*)) above actually seemed to throw 2 errors) (ignore-errors (java:jcall "undefined" (java:jnew *test-class*))) ==> ;;error Java exception 'org.armedbear.lisp.Go'. [Condition of type JAVA:JAVA-EXCEPTION] Restarts: 0: [RETRY] Retry SLIME interactive evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {106FAF1E}> #<JAVA-EXCEPTION {658A7B6C}> #<FUNCTION {106FAF1E}>) Locals: "??" = #<FUNCTION {106FAF1E}> "??"#1 = #<JAVA:JAVA-EXCEPTION org.armedbear.lisp.Go {658A7B6C}> "??"#2 = #<FUNCTION {106FAF1E}> 1: (APPLY #<FUNCTION {106FAF1E}> (#<JAVA-EXCEPTION {658A7B6C}> #<FUNCTION {106FAF1E}>)) Locals: "??" = APPLY "??"#1 = #<FUNCTION {106FAF1E}> "??"#2 = (#<JAVA:JAVA-EXCEPTION org.armedbear.lisp.Go {658A7B6C}> ..) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<JAVA-EXCEPTION {658A7B6C}> #<FUNCTION {106FAF1E}>) Locals: "??" = SYSTEM::RUN-HOOK "??"#1 = SYSTEM::*INVOKE-DEBUGGER-HOOK* "??"#2 = #<JAVA:JAVA-EXCEPTION org.armedbear.lisp.Go {658A7B6C}> "??"#3 = #<FUNCTION {106FAF1E}> 3: (INVOKE-DEBUGGER #<JAVA-EXCEPTION {658A7B6C}>) Locals: "??" = INVOKE-DEBUGGER "??"#1 = #<JAVA:JAVA-EXCEPTION org.armedbear.lisp.Go {658A7B6C}> 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) Locals: "??" = "??" 5: org.armedbear.lisp.Java.jcall(Java.java:909) Locals: "??" = "??" 6: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:756) Locals: "??" = :CLASS "??"#1 = "org.armedbear.lisp.Java$pf_jcall" "??"#2 = :METHOD "??"#3 = "execute" "??"#4 = :FILE "??"#5 = "Java.java" "??"#6 = :LINE "??"#7 = 756 7: org.armedbear.lisp.Primitive.execute(Primitive.java:123) Locals: "??" = :CLASS "??"#1 = "org.armedbear.lisp.Primitive" "??"#2 = :METHOD "??"#3 = "execute" "??"#4 = :FILE "??"#5 = "Primitive.java" "??"#6 = :LINE "??"#7 = 123 8: (JAVA:JCALL "undefined" #<runtime_class runtime_class@1451e300 {C0E1F6C}>) Locals: "??" = JAVA:JCALL "??"#1 = "undefined" "??"#2 = #<runtime_class runtime_class@1451e300 {C0E1F6C}> 9: (#<FUNCTION (LAMBDA ()) {7330F1A2}>) Locals: "??" = #<FUNCTION (LAMBDA ()) {7330F1A2}> 10: (JAVA:JRUN-EXCEPTION-PROTECTED #<FUNCTION (LAMBDA ()) {7330F1A2}>) 11: (SYSTEM::%EVAL (IGNORE-ERRORS (JAVA:JCALL "undefined" (JAVA:JNEW *TEST-CLASS*)))) 12: (EVAL (IGNORE-ERRORS (JAVA:JCALL "undefined" (JAVA:JNEW *TEST-CLASS*)))) 13: (#<FUNCTION {1247FDC3}>)

2 3

[armedbear-devel] Gray streams bugs
by Theam Yong Chew 08 Apr '15

08 Apr '15

Hi all, I inadvertently discovered some bugs in the gray-streams implementation due to a stale flexi-streams that did not get upgraded properly. There were quite a few things that needed tidying - the type checking using EQ is wrong. Also, after trying to hunt around CLHS, I think BYTE is not a CL type (though I may be mistaken). This could be a reflection of some Corman Lisp specific feature in the past (Yes! These bugs seem to have been around ABCL for that long!) Some test examples (avoiding flexi-streams or other dependencies) ;; ----- setup (require 'gray-streams) (defclass test-gray-binary-input-stream (gray-streams:fundamental-binary-input-stream) ()) (defclass test-gray-character-input-stream (gray-streams:fundamental-character-input-stream) ()) (let ((bytes (list 65 66 67 68 69)) (pos -1)) (defmethod gray-streams::stream-read-byte ((stream test-gray-binary-input-stream)) (elt bytes (mod (incf pos) 5)))) (let ((chars (list #\A #\B #\C #\D #\E)) (pos -1)) (defmethod gray-streams::stream-read-char ((stream test-gray-character-input-stream)) (elt chars (mod (incf pos) 5)))) ;; ----- (let ((s (make-instance 'test-gray-binary-input-stream))) (loop repeat 10 collect (read-byte s))) => (65 66 67 68 69 65 66 67 68 69) (let ((arr (make-array 10 :initial-element nil))) (list (read-sequence arr (make-instance 'test-gray-binary-input-stream) :start 2 :end 7) arr)) Expected (7 #(NIL NIL 65 66 67 68 69 NIL NIL NIL)), but got an error instead, ... no applicable method... I guess implementors of gray streams would normally define both read-byte & read-sequence. But ABCL's default/fallback method does try to support binary streams, it just isn't being dispatched on the right class. Also, read-sequence should return the "final" array index, not the number of bytes/characters read. Similarly, write-sequence needs to do its work, then return the sequence itself. Attached is a patch with what I hope are the required fixes, please review. Two additional notes, 1. Even after loading my proposed fixes, I'd would still get this, which is ok, but the error message is not obvious enough. This is actually a method not found error, not a type error. There appears to be some type guessing going on, so perhaps the message should indicate failure to dispatch on STREAM or similar. (gray-streams::stream-element-type (make-instance 'test-gray-binary-input-stream)) The value #<TEST-GRAY-BINARY-INPUT-STREAM {500BBBF9}> is not of type STREAM. [Condition of type TYPE-ERROR] So we just need something like this, (defmethod gray-streams::stream-element-type ((stream test-gray-binary-input-stream)) '(unsigned-byte 8)) 2. I also don't understand this snippet in the original code, converting unsigned-bytes/integers (basically the wrong type) to a character? (#+nil ccl:int-char code-char (elt sequence n)) Of course, after patching the above, I discovered that re-compiling flexi-streams got rid of my particular set of problems :-) Yong

3 6

[armedbear-devel] CLtL2 Environment functions
by Marco Antoniotti 08 Apr '15

08 Apr '15

Hello it looks like ABCL does not implement CLtL2 environment functions. (CLtL chapter 8.5). Would you guys consider putting them in (if not in yet?) Thanks -- Marco Antoniotti

2 2

[armedbear-devel] Performance of eq hash tables
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Hi, Has anyone looked at this? I'm traversing a large structure and using an eq (tried eql too) hash table to record where I've been so that I don't get caught in circularities. There are about 1.5M nodes, but what I see is that adding entries to the hash table slows down (a lot) over time, even when I give an initial size of 4,000,000. That would be max occupancy of 30%, lower than anyone would typically rehash. What I see is that it rapidly starts to fill. At 300k entries I'm getting about 2.5K new entries per second. By the time I get to 600k entries it is down to 750 new entries/sec. At 900k (where it stands now) it's about 500 entries/sec. That makes me suspect that the hash isn't distributing well over the size of the underlying vector and that the slowdown is due to buckets getting long. I'm not sure how to probe this - any ideas? Or to fix it. I suppose I could look for an alternative hash implementation, but I thought I would check first with the list to see if anyone else can shed some light. Thanks, Alan

2 1

[armedbear-devel] Source repository has moved?
by Eric Marsden 08 Apr '15

08 Apr '15

Hi, I have long been tracking the source code repository at svn://common-lisp.net/project/armedbear/svn/trunk/abcl/ (as indicated at http://common-lisp.net/project/armedbear/faq.shtml) but the last update is r14462 from 2013-04-05. What is the new location of the repository? Thanks, -- Eric Marsden

2 1

[armedbear-devel] ELS 2014 Registration now open / 2nd Call for papers
by Didier Verna 08 Apr '15

08 Apr '15

ELS'14 - 7th European Lisp Symposium IRCAM, Paris, France May 5-6, 2014 http://www.european-lisp-symposium.org/ Latest News: * Registration is now open. Early registration fee until April 13. See http://www.european-lisp-symposium.org/content-registration-full.html * Submission deadline is approaching. Still one month to submit a paper! * Thanks to our new sponsors, Lispworks and Franz Inc.! http://www.lispworks.com/ http://franz.com/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 7th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Please note that IRCAM, the conference venue, is a French institute for research on music and acoustics. Submissions relating Lisp to music or other acoustical matters will hence be particularly welcome, although given no heightened favor during the review process. We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - TODAY: Mark your calendar. Start planning now! - 09 Mar 2014: Submission deadline - 31 Mar 2014: Notification of acceptance - 13 Apr 2014: Early registration deadline - 21 Apr 2014: Final Papers due - 05 May 2014: Symposium. Join us there! Programme chair: Kent Pitman, Hypermeta Inc., U.S.A. Local chairs: Didier Verna, EPITA Research Lab, France Gérard Assayag, IRCAM, Paris, France Programme committee: To be announced later Local organizers: Daniela Becker, EPITA Research Lab, France Sylvie Benoit, IRCAM, Paris, France Search Keywords: #els2014, ELS 2014, ELS '14, European Lisp Symposium 2014, European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium, European Lisp Conference 2014, European Lisp Conference '14 Ircam STMS Lab, IRCAM / CNRS / UPMC -- Please help crowdfund my next Jazz quartet album !! http://www.kisskissbankbank.com/quartet-the-second-album Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[armedbear-devel] Ticket 240: Support 3-arg FIND-CLASS and (SETF FIND-CLASS)
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Rudi, Some time ago, I promissed I'd look at implementing the three argument version of FIND-CLASS. I can't really test it, but I've finally managed to hack up my proposed solution. Find the patch included below and attached to the ticket. Also, I'm not sure the compiler sets up a global compilation environment. I think that if it doesn't, you want to bind a new environment somewhere in the COMPILE-FROM-STREAM to *compile-file-environment*. HTH, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. The patch: Index: Environment.java =================================================================== --- Environment.java (revision 14552) +++ Environment.java (working copy) @@ -42,6 +42,7 @@ private Binding blocks; private Binding tags; public boolean inactive; //default value: false == active + private static final ConcurrentHashMap<Symbol, LispObject> classMap; public Environment() {} @@ -53,7 +54,11 @@ lastFunctionBinding = parent.lastFunctionBinding; blocks = parent.blocks; tags = parent.tags; + classMap = parent.classMap; } + else + classMap = new ConcurrentHashMap<Symbol, LispObject>(); + } // Construct a new Environment extending parent with the specified symbol- @@ -217,6 +222,36 @@ return null; } + final public LispObject addClass(LispObject name, LispObject c) + { + classMap.put(checkSymbol(name), c); + return c; + } + + final public LispObject findClass(LispObject name, boolean errorp) + { + final Symbol symbol = checkSymbol(name); + final LispObject c = classMap.get(symbol); + + if (c != null) + return c; + + if (errorp) + { + StringBuilder sb = + new StringBuilder("There is no class named "); + sb.append(name.princToString()); + sb.append('.'); + return error(new LispError(sb.toString())); + } + return NIL; + } + + final public void removeClass(LispObject name) + { + classMap.remove(checkSymbol(name)); + } + // Returns body with declarations removed. public LispObject processDeclarations(LispObject body) Index: LispClass.java =================================================================== --- LispClass.java (revision 14552) +++ LispClass.java (working copy) @@ -328,8 +328,7 @@ LispObject third) { - // FIXME Use environment! - return findClass(first, second != NIL); + return checkEnvironment(third).findClass(first, second != NIL); } }; @@ -339,7 +338,6 @@ { @Override public LispObject execute(LispObject first, LispObject second) - { final Symbol name = checkSymbol(first); if (second == NIL) @@ -350,6 +348,18 @@ addClass(name, second); return second; } + + @Override + public LispObject execute(LispObject first, LispObject second, + LispObject third, LispObject fourth) + { + if (second == NIL) + { + checkEnvironment.removeClass(first); + return second; + } + + return checkEnvironment(fourth).addCleass(first, second); }; // ### subclassp

1 0

[armedbear-devel] ASDF 3.0.0
by Faré 08 Apr '15

08 Apr '15

Dear ABCL hackers, I'm proud to announce the release of release ASDF 3.0.0. Please test it and include it in ABCL. I'll have to produce some document explaining the innovations since ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes since 2.33. As you can see, it's very minor stuff, and ASDF has been mostly stable these last two months, which is a good sign and the reason why I'm making an official 3.0.0 release. I'm also inserting a new digit in the version, so releases will have three digits: 3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be the next "major" milestone in a series that preserves backward compatibility, and 4.0 (if ever) will be the next major release that doesn't. But I probably won't be there to see it, because I'm moving away from my Common Lisp job in Cambridge MA to some new as yet undetermined opportunities in NYC that are unlikely to see me do Common Lisp for a living, and I plan to try out different Lisps for a hobby (Racket, Maru, etc.). * Portability: have *uninteresting-conditions* be empty by default. Move stuff to *usual-uninteresting-conditions*, unused by default. Will make the SBCL team happy. Also, fix tests on ABCL. Fix regression of program-op on ECL, by implicitly linking in UIOP or ASDF. * UIOP: improvements to slurp-input-stream and thus run-program, notably accepting T as alias for *standard-output*, for better backward-compatibility of the deprecated run-shell-command. New macro with-output-file. * POIU support enhanced with various tweaks. * Build cleanup so make and concatenate-source-op create the same asdf.lisp —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reason isn't about not having prejudices, it's about having (appropriate) postjudices. — Faré

1 0

[armedbear-devel] Re: [quicklisp] ABCL vs SBCL quicklisp load time in .rc files
by Mark Evenson 08 Apr '15

08 Apr '15

On 05/11/13 1428 , Zach Beane wrote: > Dave Tenny <dave.tenny(a)gmail.com> writes: > >> This may be more of an ABCL question than a Quicklisp question I guess, >> but I haven't yet found a good place to ask ABCL questions of this type. >> I'll post this in the common-lisp group too. >> >> I have the following code in my SBCL and ABCL rc files for quicklisp: >> >> #-quicklisp >> (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" >> (user-homedir-pathname)))) >> (when (probe-file quicklisp-init) >> (load quicklisp-init))) >> >> >> It executes in negligible time in SBCL, but takes about 12-13 seconds every >> time in ABCL (beyond the prior 2 seconds for normal jvm/abcl startup time). >> >> In both cases there's no obvious compilation or other stuff going on (as >> in, no output to console of things being compiled). >> >> Any idea why it takes so long in ABCL? >> >> Thanks, and ABCL discussion forum pointers welcome. > > I'm not sure why it takes so long, sorry. I don't think that's typical, > but I could be mistaken. I don't use ABCL very much. > > armedbear-devel(a)common-lisp.net is a good place for ABCL questions. I'm > not sure how you subscribe, but there are a lot of helpful ABCL hackers > answering questions there. Unfortunately, I believe that the long startup time for Quicklisp in ABCL is typical In order to save on raw startup time, the ABCL implementation has an autoload mechanism by which the compilation unit ("file") containing a given function is not loaded until first one is executed. Among other things, this means that we don't have to load CLOS to get to the bare "CL-USER>" REPL prompt. Since Quicklisp is intimately connected to ASDF which in turn is wedded at the hip to CLOS, loading Quicklisp in `~/.abclrc` effectively means that there are no time savings incurred by the autoload mechanism. Note that I "believe" this to be the case, not having actually verified by appropriate profiling, which would probably be easy to do by some combination of setting the [`abcl.autoload.verbose`][1]: Java property to collect various profiles of with/without Quicklisp/ASDF. [1]: http://abcl.org/trac/wiki/AbclJavaProperties We would welcome any suggestions for strategies to decrease our this time. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] [CfP] DEADLINE EXTENSION - 7th European Lisp Symposium
by Didier Verna 08 Apr '15

08 Apr '15

ELS'14 - 7th European Lisp Symposium IRCAM, Paris, France May 5-6, 2014 http://www.european-lisp-symposium.org/ Sponsored by IRCAM, CNRS, UPMC, EPITA, LispWorks, Franz Inc. Latest News: * SUBMISSION DEADLINE EXTENDED. You have two more week to submit! * Registration is now open. Early registration fee until April 13. See http://www.european-lisp-symposium.org/content-registration-full.html The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 7th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies Please note that IRCAM, the conference venue, is a French institute for research on music and acoustics. Submissions relating Lisp to music or other acoustical matters will hence be particularly welcome, although given no heightened favor during the review process. We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - TODAY: Mark your calendar. Start planning now! - 23 Mar 2014: Submission deadline **** EXTENDED **** - 31 Mar 2014: Notification of acceptance - 13 Apr 2014: Early registration deadline - 21 Apr 2014: Final Papers due - 05 May 2014: Symposium. Join us there! Programme chair: Kent Pitman, Hypermeta Inc., U.S.A. Local chairs: Didier Verna, EPITA Research Lab, France Gérard Assayag, IRCAM, Paris, France Programme committee: Marie Beurton-Aimar — LaBRI, University of Bordeaux, France Pierre Parquier — IBM France Lab, Paris, France Rainer Joswig — Hamburg, Germany Guiseppe Attardi — Università di Pisa, Italy Taiichi Yuasa — Kyoto University, Japan António Leitão — IST/Universidade de Lisboa, Portugal Christophe Rhodes — Goldsmiths, University of London, UK Olin Shivers — Northeastern University, USA Charlotte Herzeel — IMEC, ExaScience Life Lab, Leuven, Belgium Local organizers: Daniela Becker, EPITA Research Lab, France Sylvie Benoit, IRCAM, Paris, France Search Keywords: #els2014, ELS 2014, ELS '14, European Lisp Symposium 2014, European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium, European Lisp Conference 2014, European Lisp Conference '14 Ircam STMS Lab, IRCAM / CNRS / UPMC -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[armedbear-devel] loading maven snapshot repositories?
by Cyrus Harmon 08 Apr '15

08 Apr '15

It seems that there’s a maven convention where repositories get version “numbers” like 1.5.6-SNAPSHOT. This doesn’t seem to be supported by the current acbl-asdf contrib. Before I try to track this down, has anyone else run into this and, if so, any suggestions for working around this? thanks, Cyrus

1 0

Fwd: possible abcl bug: incorrectly deletes "unused" local function
by Erik Huelsmann 05 Apr '15

05 Apr '15

Hi Erik, ABCL appears to remove a function definition that it incorrectly thinks is unused. I've attached abcl-bug.lisp. Here is a transcript: ---- ABCL (fails) VibhuMondrasMBP:Desktop vibhu$ abcl.sh Armed Bear Common Lisp 1.3.1 Java 1.8.0_11 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.394 seconds. Startup completed in 1.8 seconds. Loading /Users/vibhu/.abclrc completed in 11.668 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "abcl-bug") ; Note: deleting unused local function LABELS =G T CL-USER(2): (sample2 1) #<THREAD "interpreter" {4F4C3489}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SAMPLE2 is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SAMPLE2. 3: TOP-LEVEL Return to top level. [1] CL-USER(3): ---- CLISP (works) VibhuMondrasMBP:Desktop vibhu$ clisp ;; Loading file /Users/vibhu/.clisprc ... ;; Loading file /Users/vibhu/quicklisp/setup.lisp ... ;; Loading file /Users/vibhu/quicklisp/ASDF.lisp ... ;; Loaded file /Users/vibhu/quicklisp/ASDF.lisp ;; Loaded file /Users/vibhu/quicklisp/setup.lisp ;; Loaded file /Users/vibhu/.clisprc [1]> (load "abcl-bug") ;; Loading file /Users/vibhu/Desktop/abcl-bug.lisp ... ;; Loaded file /Users/vibhu/Desktop/abcl-bug.lisp T [2]> (bug) 1 [3]> (load "tco2") ;; Loading file /Users/vibhu/Desktop/tco2.lisp ... ;; Loaded file /Users/vibhu/Desktop/tco2.lisp T [4]> (sample2 1) 1 -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 6

[CfPart] ELS 2015, April 20-21 2015, London
by Didier Verna 01 Apr '15

01 Apr '15

ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK April 20-21, 2015 http://www.european-lisp-symposium.org/ Sponsored by EPITA, Goldsmiths University of London, Franz Inc., Lispworks Ltd., Clozure Associates and Google Recent news: - A few seats left, still time to register! - Programme now online (schedule may still change a little) - Invited speakers announced: Zach Beane, Bodil Stokke, Martin Cracauer The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 8th European Lisp Symposium features 3 invited talks, one tutorial, 4 technical sessions and 2 lightning talks slots. The full programme is now available on the website: http://www.european-lisp-symposium.org/. Programme chair: Julian Padget, University of Bath, UK Local chair: Christophe Rhodes, Goldsmiths, University of London, UK Programme committee: Sacha Chua — Toronto, Canada Edmund Weitz — University of Applied Scicences, Hamburg, Germany Rainer Joswig — Hamburg, Germany Henry Lieberman — MIT, USA Matthew Flatt — University of Utah, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Giuseppe Attardi — University of Pisa, Italy Marc Feeley — University of Montreal, Canada Stephen Eglen — University of Cambridge, UK Robert Strandh — University of Bordeaux, France Nick Levine — RavenPack, Spain Search Keywords: #els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[Armedbear-devel] (require 'jna) broken by 0030b89b2
by Cyrus Harmon 06 Mar '15

06 Mar '15

Commit 0030b89b2eb24b0b63b5f1ca4d4c9a7644eea02d breaks the maven JNA resolution: (sly@cyruss-mbp):~/src/abcl$ ./abcl Armed Bear Common Lisp 1.4.0-dev Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.351 seconds. Startup completed in 1.786 seconds. Loading /Users/sly/.abclrc completed in 9.51 seconds. Type ":help" for a list of available commands. CL-USER(1): (require 'abcl-contrib) Using probed value of abcl-contrib: '/Users/sly/src/abcl/dist/abcl-contrib.jar'. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/sly/src/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. ("ABCL-CONTRIB") CL-USER(2): (require 'jna) ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 (/Users/sly/.m2/repository/net/java/dev/jna/jna/4.1.0/jna-4.1.0.pom) @ central (http://repo1.maven.org/maven2/, releases+snapshots) jnaASDF could not load because Java exception 'java.lang.NullPointerException'.. #<THREAD "interpreter" {4323B3D5}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.NullPointerException'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: TOP-LEVEL Return to top level. [1] CL-USER(3): [1] CL-USER(4): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<JAVA-EXCEPTION java.lang.NullPointerException {1DA02950}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Java$pf_jnew.execute(Java.java:581) 4: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 5: (JNEW #<java class org.eclipse.aether.resolution.DependencyRequest> #<org.eclipse.aether.graph.DefaultDependencyNode net.java.dev.jna:jna:jar:4.1.0 (.... {60206C1}> #<null {6F096BFB}>) 6: (ABCL-ASDF:RESOLVE-DEPENDENCIES "net.java.dev.jna" "jna" "4.1.0") 7: (#<FUNCTION {28D8442C}> (#<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">)) Any clues? thanks, Cyrus _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 5

[Armedbear-devel] Advancements in preparing ASDF system in ABCL for WAR
by Mark Evenson 06 Mar '15

06 Mar '15

A notice for those interested in my recent work in deploying ABCL as a WAR binary artifact of [an update to abcl-servlet][1], which is where I am collecting my ideas on implementation in an open source form. After locating the ASDF ABCL-SERVLET/BUILD definition, one may CL-USER> (abcl-servlet/prepare :hunchentoot) to create necessary packaging of Hunchentoot and its transitive ASDF dependences to [<file:hunchentoot/build/web/asdf/>][2] for merging into Java Servlet WAR archives. I’ve got a 100 Mib deployment WAR out of this system that has been running in production for six months now, but comments on how to generalise are welcome. [1]: https://bitbucket.org/easye/abcl-servlet/commits/e3bf36e015f2b5168d3e1d3d54… [2]: https://bitbucket.org/easye/abcl-servlet/src/b0e7e5353d6c92a1990ed1bb5500be… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] How to load compiled Lisp stuff from a jar
by Robert Dodier 06 Mar '15

06 Mar '15

Hi, I think maybe this topic has been covered before but I wonder what's the state of the art. I want to have a Java program load a compiled Lisp program contained in a jar so that I can then call functions in the Lisp code. For the record, the program in question is Maxima. Calling Lisp functions worked fine when the compiled code was unpacked (i.e. just in a directory) but I seem to recall it is not simply a matter of packing it into a jar. Or is it? Thanks for any advice. best, Robert Dodier PS. I apologize in advance for any gross misunderstanding on my part. _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

7 19

[Armedbear-devel] Access to private methods from ABCL?
by Robert Goldman 06 Mar '15

06 Mar '15

Is there some way to find a private method and make it accessible, somewhat like the way JSS can make a private field accessible? Thanks! _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 2

Re: [armedbear] #362: GET-JAVA-FIELD doesn't behave orthogonally when TRY-HARDER is T
by armedbear 06 Mar '15

06 Mar '15

#362: GET-JAVA-FIELD doesn't behave orthogonally when TRY-HARDER is T -----------------------------+----------------------- Reporter: robert goldman | Owner: mevenson Type: defect | Status: accepted Priority: major | Milestone: 1.4.0 Component: JSS | Version: 1.4.0-dev Resolution: | Keywords: -----------------------------+----------------------- Changes (by mevenson): * owner: => mevenson * status: new => accepted * version: => 1.4.0-dev * milestone: => 1.4.0 Comment: I'll have a look: thanks for the patch! -- Ticket URL: <http://abcl.org/trac/ticket/362#comment:1> armedbear <http://abcl.org> armedbear

1 0

[Armedbear-devel] Tail recursion
by Ralf Moeller 06 Mar '15

06 Mar '15

Hi all, ABCL does not seem to support tail call optimization right now. Are there any plans to provide this? Best regards, Ralf Moeller _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 5

[Armedbear-devel] Having trouble with ASDF-JAR
by Robert Dodier 06 Mar '15

06 Mar '15

Hi, I'm trying ASDF-JAR again. I'm working with the svn trunk (current revision 14736). Here's what I get: CL-USER(1): (require 'asdf) ("uiop" "UIOP" "asdf" "ASDF") CL-USER(2): (require 'abcl-contrib) Using probed value of abcl-contrib: 'NIL'. ("ABCL-CONTRIB") CL-USER(3): (require 'asdf-jar) #<THREAD "interpreter" {13AD88B}>: Debugger invoked on condition of type SIMPLE-ERROR Don't know how to REQUIRE ASDF-JAR. I guess I'm doing something wrong? Thanks for your help, Robert Dodier _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 4

[Armedbear-devel] Installing ABCL?
by Robert P. Goldman 06 Mar '15

06 Mar '15

Sorry if this is a stupid question, but is there a way to install ABCL in the standard sort of location (e.g., /usr/local/bin and /usr/local/lib, etc.)? I see that there's a copy of install-sh in the ABCL source, but I don't see a way to invoke it. I looked with find . $ -name '.git' -prune $ -o -type f -exec fgrep -q install-sh {} \; -print but didn't find anything. I have lots of bleeding edge lisp implementations because of needing to test ASDF, so was looking to figure out how to install using GNU stow for easy rebuilding and testing. [sorry if this is all handled by some Java thing like ant that I don't understand.] thanks, r _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 2

[Armedbear-devel] ABCL and RMI
by Robert Goldman 06 Mar '15

06 Mar '15

I am trying to profile (using jvirtualvm) a program that I have compiled ABCL into. I'm using ABCL to script the application, and rapidly prototype extensions. The program is the PRISM model checker (http://www.prismmodelchecker.org/) for anyone who is interested. Oddly, I find that the profiler's call graph shows not just my top level main() program as a root, but also multiple jobs running RMI TCP connection. These are all in the idle state, but seem to be chewing up a lot of CPU. There are 16 of these processes and an RMI thread scheduler. Is there any way that ABCL could be causing this to happen? I don't see any use of RMI in the host PRISM program, but then I don't see it in ABCL, either. _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 10

[Armedbear-devel] Strange behaviour of unexporting and defpackage
by Eitaro Fukamachi 06 Mar '15

06 Mar '15

Hi ABCL developers, I found a strange behaviour of cl-colors happening only on ABCL. [Issue] Symbols won't be exported on ABCL https://github.com/tpapp/cl-colors/issues/6 Though cl-colors unexports all symbols before defpackage when reloading the system, the :export clause in defpackage seems to be ignored. https://github.com/tpapp/cl-colors/blob/master/package.lisp#L5-L19 Any ideas? Regards, Eitaro _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 3

[Armedbear-devel] How to get a fresh session or instance
by Robert Dodier 06 Mar '15

06 Mar '15

Hi, is there a way to get a fresh session or instance of ABCL, short of reloading all the classes? Ideally I'd like to be able to have two or more instances which exist at the same time and are independent of each other. I believe the answer to this question is "no", but I just want to make sure I am not overlooking something. If indeed it's not possible now, what would it take to make it happen? I see there is a certain amount of static data -- would it be necessary to replace that with (just for the sake of discussion) a hash table which takes a session or instance id as a key? Any thoughts on this topic will be appreciated. best, Robert Dodier _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 9

[Armedbear-devel] GUI toolkits for the Bear
by Paul Nathan 06 Mar '15

06 Mar '15

Hi, Are there any GUI toolkits for the Bear? I am thinking in particular of something like Seesaw for Clojure. Regards, Paul _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 4

[Armedbear-devel] [CfP] ELS 2015, 8th European Lisp Symposium, Apr. 20-21, London
by Didier Verna 06 Mar '15

06 Mar '15

ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK April 20-21, 2015 http://www.european-lisp-symposium.org/ Sponsored by EPITA, Franz Inc. and Lispworks Ltd. The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 8th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 22 Feb 2015: Submission deadline - 15 Mar 2015: Notification of acceptance - 29 Mar 2015: Early registration deadline - 05 Apr 2015: Final papers - 20-21 Apr 2015: Symposium Programme chair: Julian Padget, University of Bath, UK Local chair: Christophe Rhodes, Goldsmiths, University of London, UK Programme committee: To be announced Search Keywords: #els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] [2nd CfP] European Lisp Symposium 2015, April 20-21, London
by Didier Verna 06 Mar '15

06 Mar '15

ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK April 20-21, 2015 http://www.european-lisp-symposium.org/ Sponsored by EPITA, Franz Inc. and Lispworks Ltd. Recent news: - Submission deadline in less than a month now! - Programme committee has been announced (see below) - Venue information now available on the web site The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 8th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 22 Feb 2015: Submission deadline - 15 Mar 2015: Notification of acceptance - 29 Mar 2015: Early registration deadline - 05 Apr 2015: Final papers - 20-21 Apr 2015: Symposium Programme chair: Julian Padget, University of Bath, UK Local chair: Christophe Rhodes, Goldsmiths, University of London, UK Programme committee: Sacha Chua — Toronto, Canada Edmund Weitz — University of Applied Scicences, Hamburg, Germany Rainer Joswig — Hamburg, Germany Henry Lieberman — MIT, USA Matthew Flatt — University of Utah, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Giuseppe Attardi — University of Pisa, Italy Marc Feeley — University of Montreal, Canada Stephen Eglen — University of Cambridge, UK Robert Strandh — University of Bordeaux, France Nick Levine — RavenPack, Spain Search Keywords: #els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] EQUALP raises type-error comparing large bignums to floats (patch attached)
by Massimiliano Ghilardi 06 Mar '15

06 Mar '15

If a bignum exceeds the largest representable single-float, EQUALP will raise a type-error when comparing it to a single-float. The same problem happens with double-floats. I am reporting this because my understanding of CLHS http://www.lispworks.com/documentation/lw51/CLHS/Body/f_equalp.htm#equalp tells that EQUALP is not supposed to raise errors at all: "Exceptional Situations: None." How to reproduce: ;; =========== double-floats =========== (= (ash 1 1024) most-positive-double-float) NIL (equalp (ash 1 1024) most-positive-double-float) ; Evaluation aborted on #<TYPE-ERROR {215F90FE}>. ;; =========== single-floats =========== (= 340282360000000000000000000000000000000 0.0f0) NIL (equalp 340282360000000000000000000000000000000 0.0f0) ; Evaluation aborted on #<TYPE-ERROR {1CFFC364}>. In attachment the detailed stacktrace and a proposed patch to fix this problem. Regards, Massimiliano Ghilardi _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

4 6

[Armedbear-devel] problem compiling a defstruct
by Pascal J. Bourguignon 06 Mar '15

06 Mar '15

While compiling the package com.informatimago.common-lisp.unix.option, abcl 1.3.1 fails with the following error, apparently on: (defstruct option "An option structure." keys arguments documentation function) It fails similarly to compile com.informatimago.tools.script, which contains this other (unrelated) structure: (defstruct option keys arguments documentation function) It can also be reproduced with: abcl --noinit (load "quicklisp/setup.lisp") (ql:quickload :com.informatimago.common-lisp.cesarum) ; dependency (ql:quickload :com.informatimago.common-lisp.unix :verbose t) but not with: (compile-file #P"~/quicklisp/dists/quicklisp/software/com.informatimago-20141217-git/common-lisp/unix/option.lisp" :verbose t :print t) [package com.informatimago.common-lisp.unix.option]. Error loading /home/pjb/.cache/common-lisp/abcl-1.3.1-fasl42-linux-x64/home/pjb/src/git/public/lisp/common-lisp/unix/option.abcl at line 203 (offset 10713) #<THREAD "interpreter" {66473FF8}>: Debugger invoked on condition of type TYPE-ERROR The value #(#:WHOLE-226549 #:ENVIRONMENT-226550 #:OPTION- #:G226587 #:G226588 #:G226589 #:G226590 #:G226627 #:G226672 #:G226724 #:G226768 #:G226820 #:G226865 #:G226916 #:G226961 #:WHOLE-227535 #:ENVIRONMENT-227536 #:G228248 #:G228255 #:G228256 #:G228257 #:G228258 #:G228259) is not of type LIST. Restarts: 0: TRY-RECOMPILING Recompile option and try loading it again 1: RETRY Retry loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "com.informatimago.common-lisp.unix" "option">. 2: ACCEPT Continue, treating loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "com.informatimago.common-lisp.unix" "option"> as having been successful. 3: ABORT Give up on "com.informatimago.common-lisp" [1] COM.INFORMATIMAGO.COMMON-LISP.UNIX.OPTION(2): (pprint (macroexpand-1 '(defstruct option "An option structure." keys arguments documentation function))) (PROGN (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (SYSTEM:COMPILER-DEFSTRUCT 'OPTION :CONC-NAME '#:OPTION- :DEFAULT-CONSTRUCTOR 'MAKE-OPTION :COPIER 'COPY-OPTION :PREDICATE '"OPTION-P" :DIRECT-SLOTS '(#(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION KEYS 0 OPTION-KEYS NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION ARGUMENTS 1 OPTION-ARGUMENTS NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION DOCUMENTATION 2 OPTION-DOCUMENTATION NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION FUNCTION 3 OPTION-FUNCTION NIL T NIL)) :SLOTS '(#(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION KEYS 0 OPTION-KEYS NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION ARGUMENTS 1 OPTION-ARGUMENTS NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION DOCUMENTATION 2 OPTION-DOCUMENTATION NIL T NIL) #(SYSTEM::DEFSTRUCT-SLOT-DESCRIPTION FUNCTION 3 OPTION-FUNCTION NIL T NIL)) :INHERITED-ACCESSORS 'NIL :DOCUMENTATION '"An option structure.")) (DEFUN MAKE-OPTION (&KEY ((:KEYS #:G228606) NIL) ((:ARGUMENTS #:G228607) NIL) ((:DOCUMENTATION #:G228608) NIL) ((:FUNCTION #:G228609) NIL)) (SYSTEM:MAKE-STRUCTURE (EXTENSIONS:TRULY-THE SYMBOL 'OPTION) #:G228606 #:G228607 #:G228608 #:G228609)) (DEFUN OPTION-P (SYSTEM::OBJECT) (SYSTEM:SIMPLE-TYPEP SYSTEM::OBJECT 'OPTION)) (DECLAIM (FTYPE (FUNCTION * T) OPTION-KEYS)) (SETF (SYMBOL-FUNCTION 'OPTION-KEYS) (SYSTEM::MAKE-STRUCTURE-READER 0 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM OPTION-KEYS (SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-REF (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 0)) (SETF (GET 'OPTION-KEYS 'SYSTEM:SETF-FUNCTION) (SYSTEM::MAKE-STRUCTURE-WRITER 0 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM (SETF OPTION-KEYS) (SYSTEM::VALUE SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-SET (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 0 SYSTEM::VALUE)) (DECLAIM (FTYPE (FUNCTION * T) OPTION-ARGUMENTS)) (SETF (SYMBOL-FUNCTION 'OPTION-ARGUMENTS) (SYSTEM::MAKE-STRUCTURE-READER 1 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM OPTION-ARGUMENTS (SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-REF (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 1)) (SETF (GET 'OPTION-ARGUMENTS 'SYSTEM:SETF-FUNCTION) (SYSTEM::MAKE-STRUCTURE-WRITER 1 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM (SETF OPTION-ARGUMENTS) (SYSTEM::VALUE SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-SET (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 1 SYSTEM::VALUE)) (DECLAIM (FTYPE (FUNCTION * T) OPTION-DOCUMENTATION)) (SETF (SYMBOL-FUNCTION 'OPTION-DOCUMENTATION) (SYSTEM::MAKE-STRUCTURE-READER 2 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM OPTION-DOCUMENTATION (SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-REF (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 2)) (SETF (GET 'OPTION-DOCUMENTATION 'SYSTEM:SETF-FUNCTION) (SYSTEM::MAKE-STRUCTURE-WRITER 2 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM (SETF OPTION-DOCUMENTATION) (SYSTEM::VALUE SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-SET (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 2 SYSTEM::VALUE)) (DECLAIM (FTYPE (FUNCTION * T) OPTION-FUNCTION)) (SETF (SYMBOL-FUNCTION 'OPTION-FUNCTION) (SYSTEM::MAKE-STRUCTURE-READER 3 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM OPTION-FUNCTION (SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-REF (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 3)) (SETF (GET 'OPTION-FUNCTION 'SYSTEM:SETF-FUNCTION) (SYSTEM::MAKE-STRUCTURE-WRITER 3 'OPTION)) (SYSTEM:DEFINE-SOURCE-TRANSFORM (SETF OPTION-FUNCTION) (SYSTEM::VALUE SYSTEM::INSTANCE) (SYSTEM::BACKQ-LIST 'SYSTEM:STRUCTURE-SET (SYSTEM::BACKQ-LIST 'THE 'OPTION SYSTEM::INSTANCE) 3 SYSTEM::VALUE)) (SETF (FDEFINITION 'COPY-OPTION) #'COPY-STRUCTURE) 'OPTION) [1] COM.INFORMATIMAGO.COMMON-LISP.UNIX.OPTION(3): CL-USER(4): (COM.INFORMATIMAGO.TOOLS.MANIFEST:PRINT-BUG-REPORT-INFO) LISP-IMPLEMENTATION-TYPE "Armed Bear Common Lisp" LISP-IMPLEMENTATION-VERSION "1.3.1" SOFTWARE-TYPE "Linux" SOFTWARE-VERSION "3.2.0-4-amd64" MACHINE-INSTANCE "kuiper" MACHINE-TYPE "X86-64" MACHINE-VERSION "Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz" distribution (:LINUX :DEBIAN "7.7") *FEATURES* (:COM.INFORMATIMAGO.PJB :SPLIT-SEQUENCE :CLOSER-MOP :COM.INFORMATIMAGO.COMMON-LISP.LISP.CL-STEPPER :NEWLINE-IS-LINEFEED :HAS-ASCII-CODE :HAS-VT :HAS-BELL :HAS-ESCAPE :HAS-LINEFEED :HAS-RETURN :HAS-BACKSPACE :HAS-TAB :HAS-PAGE :HAS-RUBOUT :QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX :ASDF-UNICODE :ABCL-BUNDLE-OP-SUPPORTED :X86-64 :JAVA-1.7 :UNIX :LINUX :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES) /proc/cpuinfo ------------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3073.461 cache size : 8192 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6146.92 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: CL-USER(5): -- __Pascal J. Bourguignon__ _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 2

[Armedbear-devel] test
by Erik Huelsmann 06 Mar '15

06 Mar '15

HI, Testing delivery. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] hi
by Erik Huelsmann 06 Mar '15

06 Mar '15

testing delivery -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] abcl-asdf: merged changes from Cyrus
by Mark Evenson 06 Mar '15

06 Mar '15

Spam detection software, running on the system "mailcrunch1.panix.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see support(a)panix.com for details. Content preview: [Cyrusâs recent patches for ABCL-ASDF to use alternate Maven repositories and other fixes][1] have been merged [into the ABCL trunk][2,3,4,5]. [I made the following deviation from the patches][6]: The codes seems to intend to record, buts fails to actually set, the repository an artifact is download from as part of the path. I changed the ineffective code as a comment, mainly as the MVN path is intended to follow the [MVN URI scheme][7] for which the repository definitely doesnât belong at the end but rather at the beginning. [...] Content analysis details: (5.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?109.126.64.2>] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [109.126.64.2 listed in pgwm4qf5v2mbif3ei5nmvnmsve.zen.dq.spamhaus.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

1 0

[Armedbear-devel] asdf doesn't load dependencies in abcl
by Pascal J. Bourguignon 04 Mar '15

04 Mar '15

When using abcl, asdf doesn't load some dependent packages. In this case, I have asd file com.informatimago.tools.asd -------------------------------------------------------------------------------- (asdf:defsystem :com.informatimago.tools ;; system attributes: :description "This system gathers Informatimago Common Lisp tools." :author "Pascal J. Bourguignon <pjb(a)informatimago.com>" :maintainer "Pascal J. Bourguignon <pjb(a)informatimago.com>" :licence "AGPL3" ;; component attributes: :name "Informatimago Common Lisp Tools Agregate" :version "1.0.2" :properties ((#:author-email . "pjb(a)informatimago.com") (#:date . "Spring 2014") ((#:albert #:output-dir) . "/tmp/documentation/com.informatimago.tools/") ((#:albert #:formats) . ("docbook")) ((#:albert #:docbook #:template) . "book") ((#:albert #:docbook #:bgcolor) . "white") ((#:albert #:docbook #:textcolor) . "black")) #+asdf-unicode :encoding #+asdf-unicode :utf-8 :depends-on ("com.informatimago.tools.check-asdf" "com.informatimago.tools.make-depends" "com.informatimago.tools.manifest" "com.informatimago.tools.pathname" "com.informatimago.tools.source" "com.informatimago.tools.symbol" "com.informatimago.tools.quicklisp") :components ((:file "tools"))) -------------------------------------------------------------------------------- which should load com.informatimago.tools.pathname.asd -------------------------------------------------------------------------------- (asdf:defsystem :com.informatimago.tools.pathname :name "com.informatimago.tools.pathname" :description "Pathname tools." :author "Pascal J. Bourguignon" :version "1.0.0" :license "GPL3" :depends-on () :components ((:file "pathname"))) -------------------------------------------------------------------------------- and pathname.lisp defines a package named "COM.INFORMATIMAGO.TOOLS.PATHNAME": -------------------------------------------------------------------------------- (defpackage "COM.INFORMATIMAGO.TOOLS.PATHNAME" (:use "COMMON-LISP") (:shadow "MAKE-PATHNAME" "USER-HOMEDIR-PATHNAME" "TRANSLATE-LOGICAL-PATHNAME") (:export "MAKE-PATHNAME" "USER-HOMEDIR-PATHNAME" "TRANSLATE-LOGICAL-PATHNAME") (:documentation "Pathname tools.")) ;; etc -------------------------------------------------------------------------------- Unfortunately, it seems that asdf (version "3.1.0.103") fails to load this dependencies: [pjb@kuiper :10.0 lisp]$ abcl Armed Bear Common Lisp 1.3.1 Java 1.7.0_75 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 1.136 seconds. Startup completed in 6.589 seconds. ;; -*- mode:lisp -*- (:OUTPUT-TRANSLATIONS :IGNORE-INVALID-ENTRIES (T (:HOME ".cache" "common-lisp" :HOSTNAME :IMPLEMENTATION)) (T (:HOME ".cache" "common-lisp" :IMPLEMENTATION)) :INHERIT-CONFIGURATION) To load "com.informatimago.common-lisp": Load 1 ASDF system: com.informatimago.common-lisp ; Loading "com.informatimago.common-lisp" [package com.informatimago.common-lisp.lisp-sexp.source-form]. .................................................. [package com.informatimago.common-lisp.lisp-reader.reader]. .................................................. [package com.informatimago.common-lisp.lisp-reader.package]. .................................................. [package com.informatimago.common-lisp.lisp-text.source-text]. [package com.informatimago.common-lisp.cesarum.simple-test]. [package com.informatimago.common-lisp.cesarum.array] [package com.informatimago.common-lisp.cesarum.sequence]. [package com.informatimago.common-lisp.cesarum.list]. .................................................. [package com.informatimago.common-lisp.cesarum.utility]. .................................................. [package com.informatimago.common-lisp.cesarum.ecma048]. [package com.informatimago.common-lisp.cesarum.string]. .................................................. [package com.informatimago.common-lisp.cesarum.package]. [package com.informatimago.common-lisp.cesarum.set]. [package com.informatimago.common-lisp.cesarum.index-set]. .................................................. [package com.informatimago.common-lisp.cesarum.bset]. .................................................. [package com.informatimago.common-lisp.cesarum.brelation]. .................................................. [package com.informatimago.common-lisp.cesarum.dictionary]. [package com.informatimago.common-lisp.cesarum.dll] [package com.informatimago.common-lisp.cesarum.graph]. .................................................. [package com.informatimago.common-lisp.cesarum.llrbtree]. .................................................. [package com.informatimago.common-lisp.cesarum.queue] [package com.informatimago.common-lisp.cesarum.message-queue] [package com.informatimago.common-lisp.cesarum.ascii]. .................................................. [package com.informatimago.common-lisp.cesarum.character]. [package com.informatimago.common-lisp.cesarum.character-sets] [package com.informatimago.common-lisp.cesarum.iso3166] [package com.informatimago.common-lisp.cesarum.iso4217]. [package com.informatimago.common-lisp.cesarum.iso639a] [package com.informatimago.common-lisp.cesarum.pmatch] [package com.informatimago.common-lisp.cesarum.combination]. [package com.informatimago.common-lisp.cesarum.constraints]. [package com.informatimago.common-lisp.cesarum.raiden] [package com.informatimago.common-lisp.cesarum.dfa]. [package com.informatimago.common-lisp.cesarum.tea] [package com.informatimago.common-lisp.cesarum.circular] [package com.informatimago.common-lisp.cesarum.histogram]. [package com.informatimago.common-lisp.cesarum.a-star] [package com.informatimago.common-lisp.cesarum.activity]. .................................................. [package com.informatimago.common-lisp.cesarum.date.utility] [package com.informatimago.common-lisp.julian-calendar] [package com.informatimago.common-lisp.gregorian-calendar] [package com.informatimago.common-lisp.cesarum.date]. .................................................. [package com.informatimago.common-lisp.cesarum.version]. [package com.informatimago.common-lisp.cesarum.stream] [package com.informatimago.common-lisp.cesarum.file]. [package com.informatimago.common-lisp.cesarum.peek-stream]. [package com.informatimago.common-lisp.cesarum.cache]. .................................................. [package com.informatimago.common-lisp.cesarum.float-binio] [package com.informatimago.common-lisp.picture.picture]. .................................................. [package com.informatimago.common-lisp.picture.cons-to-ascii] [package com.informatimago.common-lisp.picture.tree-to-ascii]. [package com.informatimago.common-lisp.arithmetic.primes] [package com.informatimago.common-lisp.arithmetic.p127n2]. [package com.informatimago.common-lisp.data-encoding.data-encoding]. .................................................. [package com.informatimago.common-lisp.data-encoding.bencode]. [package com.informatimago.common-lisp.data-encoding.hexadecimal]. [package com.informatimago.common-lisp.data-encoding.ecp]. [package com.informatimago.common-lisp.heap.memory]. [package com.informatimago.common-lisp.heap.heap]. .................................................. [package com.informatimago.common-lisp.html-generator.html-entities]. .................................................. [package com.informatimago.common-lisp.html-generator.html]. .................................................. [package com.informatimago.common-lisp.html-parser.parse-html]. .................................................. [package com.informatimago.common-lisp.http.hquery] [package com.informatimago.common-lisp.http.htrans]. .................................................. [package com.informatimago.common-lisp.bank.iban]. [package com.informatimago.common-lisp.bank.rib].. [package com.informatimago.common-lisp.csv.csv]... [package com.informatimago.common-lisp.diagram.tree-to-diagram] [package com.informatimago.common-lisp.regexp.regexp-emacs]. .................................................. [package com.informatimago.common-lisp.regexp.regexp-posix] [package com.informatimago.common-lisp.regexp.regexp-posix.keyword]. .. ; in (DEFUN RMATCH-B-ANCHOR ...) ; Caught STYLE-WARNING: ; The variable #:G193370 is defined but never used. ; in (DEFUN RMATCH-E-ANCHOR ...) ; Caught STYLE-WARNING: ; The variable #:G193396 is defined but never used. ; in (DEFUN RMATCH-L-ANCHOR ...) ; Caught STYLE-WARNING: ; The variable #:G193423 is defined but never used. ; in (DEFUN RMATCH-R-ANCHOR ...) ; Caught STYLE-WARNING: ; The variable #:G193457 is defined but never used. ; in (DEFUN RMATCH-ANY ...) ; Caught STYLE-WARNING: ; The variable #:G193492 is defined but never used. .. ; Caught COMPILE-WARNED-WARNING: ; Lisp compilation had style-warnings while compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "com.informatimago.common-lisp.regexp" "regexp-posix"> .............................................. [package com.informatimago.common-lisp.ed.ed]..... [package com.informatimago.common-lisp.graphviz.graph-dot] [package com.informatimago.common-lisp.invoice.invoice]. .................................................. [package com.informatimago.common-lisp.interactive.browser]. [package com.informatimago.common-lisp.interactive.interactive]. .................................................. [package com.informatimago.common-lisp.parser.scanner]. [package com.informatimago.common-lisp.parser.parser]. [package com.informatimago.common-lisp.rfc2822.rfc2822] [package com.informatimago.common-lisp.rfc3548.rfc3548]. [package com.informatimago.common-lisp.unix.aliases]. [package com.informatimago.common-lisp.unix.group] [package com.informatimago.common-lisp.unix.passwd]. [package com.informatimago.common-lisp.unix.option]. ; Compilation unit finished ; Caught 1 WARNING condition ; Caught 5 STYLE-WARNING conditions To load "com.informatimago.common-lisp.lisp.stepper": Load 1 ASDF system: com.informatimago.common-lisp.lisp.stepper ; Loading "com.informatimago.common-lisp.lisp.stepper" [package com.informatimago.common-lisp.lisp.stepper.internal]. .................................................. [package com.informatimago.common-lisp.lisp.stepper]. . To load "com.informatimago.clmisc": Load 1 ASDF system: com.informatimago.clmisc ; Loading "com.informatimago.clmisc" [package com.informatimago.clmisc.resource-utilization] To load "com.informatimago.tools": Load 1 ASDF system: com.informatimago.tools ; Loading "com.informatimago.tools" To load "com.informatimago.clext": Load 1 ASDF system: com.informatimago.clext ; Loading "com.informatimago.clext" [package closer-mop].............................. [package closer-common-lisp]...................... [package closer-common-lisp-user]................. [package com.informatimago.clext.association]..... [package com.informatimago.clext.character-sets]. To load "alexandria": Load 1 ASDF system: alexandria ; Loading "alexandria" [package alexandria.0.dev].... Error loading /home/pjb/rc/common.lisp at line 262 (offset 9763) #<THREAD "interpreter" {7C9CC8FE}>: Debugger invoked on condition of type READER-ERROR The package "COM.INFORMATIMAGO.TOOLS.PATHNAME" can't be found. [1] PJB(1): (asdf/upgrade:asdf-version) "3.1.0.103" [1] PJB(2): For reference, the same script run by ccl (with asdf version "3.1.3"): [pjb@kuiper :10.0 lisp]$ ccl ;; -*- mode:lisp -*- (:OUTPUT-TRANSLATIONS :IGNORE-INVALID-ENTRIES (T (:HOME ".cache" "common-lisp" :HOSTNAME :IMPLEMENTATION)) (T (:HOME ".cache" "common-lisp" :IMPLEMENTATION)) :INHERIT-CONFIGURATION) To load "com.informatimago.common-lisp": Load 1 ASDF system: com.informatimago.common-lisp ; Loading "com.informatimago.common-lisp" [package com.informatimago.common-lisp.lisp-sexp.source-form]. .................................................. [package com.informatimago.common-lisp.lisp-reader.reader]. .................................................. [package com.informatimago.common-lisp.lisp-reader.package]. .................................................. [package com.informatimago.common-lisp.lisp-text.source-text]. [package com.informatimago.common-lisp.cesarum.simple-test]. [package com.informatimago.common-lisp.cesarum.array] [package com.informatimago.common-lisp.cesarum.sequence]. [package com.informatimago.common-lisp.cesarum.list]. .................................................. [package com.informatimago.common-lisp.cesarum.utility]. .................................................. [package com.informatimago.common-lisp.cesarum.ecma048] [package com.informatimago.common-lisp.cesarum.string]. .................................................. [package com.informatimago.common-lisp.cesarum.package]. [package com.informatimago.common-lisp.cesarum.set]. [package com.informatimago.common-lisp.cesarum.index-set]. [package com.informatimago.common-lisp.cesarum.bset]. .................................................. [package com.informatimago.common-lisp.cesarum.brelation]. .................................................. [package com.informatimago.common-lisp.cesarum.dictionary]. [package com.informatimago.common-lisp.cesarum.dll]. [package com.informatimago.common-lisp.cesarum.graph]. [package com.informatimago.common-lisp.cesarum.llrbtree]. .................................................. [package com.informatimago.common-lisp.cesarum.queue] [package com.informatimago.common-lisp.cesarum.message-queue]. [package com.informatimago.common-lisp.cesarum.ascii]. [package com.informatimago.common-lisp.cesarum.character] [package com.informatimago.common-lisp.cesarum.character-sets]. [package com.informatimago.common-lisp.cesarum.iso3166] [package com.informatimago.common-lisp.cesarum.iso4217] [package com.informatimago.common-lisp.cesarum.iso639a]. [package com.informatimago.common-lisp.cesarum.pmatch] [package com.informatimago.common-lisp.cesarum.combination]. [package com.informatimago.common-lisp.cesarum.constraints]. [package com.informatimago.common-lisp.cesarum.raiden] [package com.informatimago.common-lisp.cesarum.dfa]. .................................................. [package com.informatimago.common-lisp.cesarum.tea] [package com.informatimago.common-lisp.cesarum.circular] [package com.informatimago.common-lisp.cesarum.histogram]. [package com.informatimago.common-lisp.cesarum.a-star] [package com.informatimago.common-lisp.cesarum.activity]. .................................................. [package com.informatimago.common-lisp.cesarum.date.utility] [package com.informatimago.common-lisp.julian-calendar] [package com.informatimago.common-lisp.gregorian-calendar] [package com.informatimago.common-lisp.cesarum.date]. .................................................. [package com.informatimago.common-lisp.cesarum.version] [package com.informatimago.common-lisp.cesarum.stream] [package com.informatimago.common-lisp.cesarum.file]. [package com.informatimago.common-lisp.cesarum.peek-stream]. [package com.informatimago.common-lisp.cesarum.cache]. [package com.informatimago.common-lisp.cesarum.float-binio]. [package com.informatimago.common-lisp.picture.picture]. [package com.informatimago.common-lisp.picture.cons-to-ascii] [package com.informatimago.common-lisp.picture.tree-to-ascii]. [package com.informatimago.common-lisp.arithmetic.primes] [package com.informatimago.common-lisp.arithmetic.p127n2]. [package com.informatimago.common-lisp.data-encoding.data-encoding]. .................................................. [package com.informatimago.common-lisp.data-encoding.bencode] [package com.informatimago.common-lisp.data-encoding.hexadecimal]. [package com.informatimago.common-lisp.data-encoding.ecp]. .................................................. [package com.informatimago.common-lisp.heap.memory] [package com.informatimago.common-lisp.heap.heap]. .................................................. [package com.informatimago.common-lisp.html-generator.html-entities]. .................................................. [package com.informatimago.common-lisp.html-generator.html]. .................................................. [package com.informatimago.common-lisp.html-parser.parse-html]. .................................................. [package com.informatimago.common-lisp.http.hquery] [package com.informatimago.common-lisp.http.htrans]. [package com.informatimago.common-lisp.bank.iban]. [package com.informatimago.common-lisp.bank.rib].. [package com.informatimago.common-lisp.csv.csv]... [package com.informatimago.common-lisp.diagram.tree-to-diagram] [package com.informatimago.common-lisp.regexp.regexp-emacs]. .................................................. [package com.informatimago.common-lisp.regexp.regexp-posix] [package com.informatimago.common-lisp.regexp.regexp-posix.keyword]. .................................................. [package com.informatimago.common-lisp.ed.ed]..... [package com.informatimago.common-lisp.graphviz.graph-dot] [package com.informatimago.common-lisp.invoice.invoice]. .................................................. [package com.informatimago.common-lisp.interactive.browser]. [package com.informatimago.common-lisp.interactive.interactive]. [package com.informatimago.common-lisp.parser.scanner] [package com.informatimago.common-lisp.parser.parser] [package com.informatimago.common-lisp.rfc2822.rfc2822]. [package com.informatimago.common-lisp.rfc3548.rfc3548]. .................................................. [package com.informatimago.common-lisp.unix.aliases]. [package com.informatimago.common-lisp.unix.group] [package com.informatimago.common-lisp.unix.passwd] [package com.informatimago.common-lisp.unix.option]. . To load "com.informatimago.common-lisp.lisp.stepper": Load 1 ASDF system: com.informatimago.common-lisp.lisp.stepper ; Loading "com.informatimago.common-lisp.lisp.stepper" [package com.informatimago.common-lisp.lisp.stepper.internal] [package com.informatimago.common-lisp.lisp.stepper]. . To load "com.informatimago.clmisc": Load 1 ASDF system: com.informatimago.clmisc ; Loading "com.informatimago.clmisc" [package com.informatimago.clmisc.resource-utilization] To load "com.informatimago.tools": Load 1 ASDF system: com.informatimago.tools ; Loading "com.informatimago.tools" [package closer-mop].............................. [package closer-common-lisp]...................... [package closer-common-lisp-user]................. [package com.informatimago.clext.association]..... [package com.informatimago.clext.character-sets].. [package com.informatimago.clext.closer-weak]..... [package com.informatimago.clext.closer-weak-user]. .................................................. [package com.informatimago.tools.dependency-cycles]. [package com.informatimago.common-lisp.script].... [package com.informatimago.tools.asdf-file]....... [package com.informatimago.tools.check-asdf]...... [package com.informatimago.common-lisp.tools.make-depends]. .................................................. [package asdf].................................... [package split-sequence].......................... [package com.informatimago.tools.manifest]........ [package com.informatimago.tools.pathname]........ [package com.informatimago.read-sources].......... [package com.informatimago.tools.symbol].......... [package com.informatimago.tools.quicklisp]....... [package com.informatimago.tools.asdf] To load "alexandria": Load 1 ASDF system: alexandria ; Loading "alexandria" [package alexandria.0.dev]........ (OPTIMIZE (SAFETY 3) (DEBUG 3) (SPEED 0) (SPACE 0) (COMPILATION-SPEED 1)) Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! CCL is developed and maintained by Clozure Associates. For more information about CCL visit http://ccl.clozure.com. To enquire about Clozure's Common Lisp consulting services e-mail info(a)clozure.com or visit http://www.clozure.com. ? (asdf/upgrade:asdf-version) "3.1.3" ? (quit) -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] [Final CfP] ELS 2015 submission deadline extended to March 1st
by Didier Verna 22 Feb '15

22 Feb '15

ELS'15 - 8th European Lisp Symposium Goldsmiths College, London, UK April 20-21, 2015 http://www.european-lisp-symposium.org/ Sponsored by EPITA, Franz Inc. and Lispworks Ltd. Recent news: - *** Submission deadline extended to March 1st *** - Invited speakers announced: Zach Beane, Bodil Stokke, Martin Cracauer - Registration to open early March The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 8th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 01 Mar 2015: Submission deadline *** EXTENDED *** - 15 Mar 2015: Notification of acceptance - 29 Mar 2015: Early registration deadline - 05 Apr 2015: Final papers - 20-21 Apr 2015: Symposium Programme chair: Julian Padget, University of Bath, UK Local chair: Christophe Rhodes, Goldsmiths, University of London, UK Programme committee: Sacha Chua — Toronto, Canada Edmund Weitz — University of Applied Scicences, Hamburg, Germany Rainer Joswig — Hamburg, Germany Henry Lieberman — MIT, USA Matthew Flatt — University of Utah, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Giuseppe Attardi — University of Pisa, Italy Marc Feeley — University of Montreal, Canada Stephen Eglen — University of Cambridge, UK Robert Strandh — University of Bordeaux, France Nick Levine — RavenPack, Spain Search Keywords: #els2015, ELS 2015, ELS '15, European Lisp Symposium 2015, European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium, European Lisp Conference 2015, European Lisp Conference '15 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] flet+inline warns and generate bad code.
by Pascal J. Bourguignon 21 Feb '15

21 Feb '15

An inline flet makes the compiler report an error (warning?): (defun f (x) (flet ((hello (x) (logand x #xffffffff))) (declare (inline hello)) (hello (+ (hello 1) (hello x))))) CL-USER(6): (compile-file #P"~/abcl-flet-bug.lisp") ; Compiling /home/pjb/abcl-flet-bug.lisp ... ; (DEFUN F ...) ; (DEFUN G ...) ; Compilation unit finished ; The following functions were used but not defined: ; HELLO ; Wrote /home/pjb/abcl-flet-bug.abcl (0.04 seconds) #P"/home/pjb/abcl-flet-bug.abcl" NIL NIL And the code generated is wrong: CL-USER(12): (load(compile-file #P"~/abcl-flet-bug.lisp")) ; Compiling /home/pjb/abcl-flet-bug.lisp ... ; (DEFUN F ...) ; Compilation unit finished ; The following functions were used but not defined: ; HELLO ; Wrote /home/pjb/abcl-flet-bug.abcl (0.012 seconds) T CL-USER(13): (f 4) #<THREAD "interpreter" {6A4E43EA}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function HELLO is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to HELLO. 3: TOP-LEVEL Return to top level. [1] CL-USER(14): 3 CL-USER(15): Without inline, it works well. CL-USER(15): (load(compile-file #P"~/abcl-flet-bug.lisp")) ; Compiling /home/pjb/abcl-flet-bug.lisp ... ; (DEFUN F ...) ; Wrote /home/pjb/abcl-flet-bug.abcl (0.02 seconds) T CL-USER(16): (f 4) 5 CL-USER(17): CL-USER(11): (COM.INFORMATIMAGO.TOOLS.MANIFEST:PRINT-BUG-REPORT-INFO) LISP-IMPLEMENTATION-TYPE "Armed Bear Common Lisp" LISP-IMPLEMENTATION-VERSION "1.3.1" SOFTWARE-TYPE "Linux" SOFTWARE-VERSION "3.2.0-4-amd64" MACHINE-INSTANCE "kuiper" MACHINE-TYPE "X86-64" MACHINE-VERSION "Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz" distribution (:LINUX :DEBIAN "7.8") uname -a NIL *FEATURES* (:COM.INFORMATIMAGO.PJB :SPLIT-SEQUENCE :CLOSER-MOP :COM.INFORMATIMAGO.COMMON-LISP.LISP.CL-STEPPER :NEWLINE-IS-LINEFEED :HAS-ASCII-CODE :HAS-VT :HAS-BELL :HAS-ESCAPE :HAS-LINEFEED :HAS-RETURN :HAS-BACKSPACE :HAS-TAB :HAS-PAGE :HAS-RUBOUT :QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX :ASDF-UNICODE :ABCL-BUNDLE-OP-SUPPORTED :X86-64 :JAVA-1.7 :UNIX :LINUX :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES) /proc/cpuinfo ------------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3073.461 cache size : 8192 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6146.92 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: CL-USER(12): -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] Question about pipes
by Sistemas 27 Sep '14

27 Sep '14

Hi: I'm trying to start some processes and connect them using pipes with ABCL (like Unix shell pipes). I've reviewed the documentation but I haven't found anything. Are I missing something? If not, are there any plans of adding input, output and error parameters for run-program (like SBCL, CCL, etc.)? Greets and thanks in advance. Rafael J. Alcántara Pérez. -- +---------- | Departamento de Sistemas <sistemas(a)dedaloingenieros.com> | Teléfono fijo: 952 602 959 | Fax: 952 602 959 | Dirección: C/ Afligidos 2, 3º Derecha, 29015 Málaga | Dédalo Ingenieros, S.L.: http://www.dedaloingenieros.com/ | PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0x1899F325 +--------------------- _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

5 7

[Armedbear-devel] Comments on Cyrus's proposal for JSS static calls
by Mark Evenson 27 Sep '14

27 Sep '14

Erik asked me to comment on [Cyrus’s proposed patch][1] to extend JSS’s SHARPSIGN-DOUBLE-QUOTE use in static method calls to accept a string as well as a symbol to designate the object. Unfortunately, changing JSS in the manner means that one can no longer use SHARPSIGN-DOUBE-QUOTE on object descended from java.lang.String, for the reasons described in the [JSS README][2]: […] Static calls are possible as well with the #" macro, but the first argument MUST BE A SYMBOL to distinguish (#"getProperties" "java.lang.System") from (#"getProperties" 'java.lang.System) The first attempts to call a method on the java.lang.String object with the contents "java.lang.System", which results in an error, while the second invokes the static java.lang.System.getProperties() method. […] Other than perhaps for aesthetic reasons, is there some functionality that using strings enables here? To argue about preserving character case in strings as opposed to the case folding implicit in symbols doesn’t seem to be applicable, because JSS currently ignores case when searching for matching JVM symbols. In 2006, when I first understood the ignoring case bit of JSS, I was a bit worried that there would be cases where this resulted in ambiguity and errors, but in the ensuing years I have yet to run into a single problem with this design decision. Therefore, I am not currently persuaded that introducing an asymmetry to SHARPSIGN-DOUBLE-QUOTE (“It works on any java Object except those which descend from java.lang.String; for those instances you have to use the JFI”) to use strings as well as symbols to specify static methods is worth it. But please argue back if you disagree… [1]: https://github.com/slyrus/abcl/commit/9ec0fb26c7b7e9470349b1c4bd9be6fa4b053… [2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown#L55 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 2

[Armedbear-devel] Bug: compile function doesn't work
by Mariano Montone 27 Sep '14

27 Sep '14

Hello, This function is not working in the latest ABCL version: http://clhs.lisp.se/Body/f_cmp.htm This is what I get when I try to evaluate the example in CLHS: (defun foo () "bar") => FOO (compile 'foo) Wrong number of arguments for #<FUNCTION {5236A94B}>. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {752CC03}> #<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>) 1: (APPLY #<FUNCTION {752CC03}> (#<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {600776A0}> #<FUNCTION {752CC03}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {600776A0}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.CompiledClosure.notImplemented(CompiledClosure.java:81) 6: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:212) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 8: org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:117) 9: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 10: org.armedbear.lisp.compiler_pass2_387.execute(compiler-pass2.lisp:7495) 11: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) 12: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 13: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 14: org.armedbear.lisp.compiler_pass2_386.execute(compiler-pass2.lisp:7495) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:838) 16: org.armedbear.lisp.compiler_pass2_388.execute(compiler-pass2.lisp:7519) 17: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 19: org.armedbear.lisp.compiler_pass2_392.execute(compiler-pass2.lisp:7589) 20: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 22: org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) 23: org.armedbear.lisp.Lisp.eval(Lisp.java:540) 24: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 25: (COMPILE FOO) I'm not using this directly, but some libraries like closer-mop, need compile to work. Fails here: CL-USER> (lisp-implementation-type) "Armed Bear Common Lisp" CL-USER> (lisp-implementation-version) "1.4.0-dev-svn-14713" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_55-b14" "amd64-Linux-3.5.0-17-generic" It seems to work in some cases on ABCL 1.3.1, though. CL-USER> (compile 'foo) FOO NIL NIL But something like this signals an error: CL-USER> (compile nil '(lambda (x) x)) ; Evaluation aborted on #<PROGRAM-ERROR {4C62C417}>. With the same error above. CL-USER> (lisp-implementation-version) "1.3.1" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_55-b14" "amd64-Linux-3.5.0-17-generic" I couldn't put this on the bugs tracker because I don't have permissions. Cheers, Mariano _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 3

Re: [Cffi-devel] Patches to CFFI for ABCL which passes all tests
by Cyrus Harmon 27 Sep '14

27 Sep '14

On Aug 20, 2014, at 2:24 AM, Mark Evenson <evenson(a)panix.com> wrote: > > Even though we are passing all the CFFI tests, > > CL-USER> (drakma:http-request “https://google.com”) > > still times out with an error. Always something further to fix… Yes, I’ve run across this too. The first https call hangs, even if one adds :connection-timeout 120. Could we be improperly initializing something somewhere along the run? After recovering from this error, subsequent calls work. This is probably more of a cl+ssl issue than a cffi (or ABCL) issue, but it definitely seems to be ABCL-specific. Thanks for your work to clean up the CFFI patch set! I look forward to the day when I can run stock CFFI, cl+ss, and ABCL and have all my code working :) Cyrus

3 3

[Armedbear-devel] [CfPart] International Lisp Conference 2014, August 15-17, Montreal
by Didier Verna 19 Aug '14

19 Aug '14

ILC 2014 - International Lisp Conference "Lisp on the Move" August 15-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users In cooperation with: ACM SIGPLAN http://ilc2014.iro.umontreal.ca/ Latest News: * Registration is now open. See http://ilc2014.iro.umontreal.ca/registration.php * Invited speakers announced. Christian Queinnec, Ambrose Bonnaire-Sergeant, Stefan Monnier, Marc Battyani. Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. This year's focus is directed towards integrated solutions, including mobile computing. The conference also provides slots for lightning talks, to be registered on-site every day. The full programme is available here: http://ilc2014.iro.umontreal.ca/program.php Important Dates: - July 14, 2014: Early registration deadline - August 15, 2014: Conference starts Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USA Irène Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Möller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA Contact: ilc14-organizing-committee at alu.org For more information, see http://ilc2014.iro.umontreal.ca/ -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] Motion to delete asdf-install from ABCL's contrib
by Erik Huelsmann 19 Aug '14

19 Aug '14

Hi all, Relaying a motion by slyrus (Cyrus Harmon) from IRC: can we delete asdf-install from ABCL's contrib package? I think we can and should, given that we now have Quicklisp well supported, so hereby I'm relaying. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] ASDF-announce email list is live again
by Robert P. Goldman 19 Aug '14

19 Aug '14

Dear CL implementers and maintainers, I apologize for the mass spam, but I am sending this out in order to limit all further ASDF release spam. Hans Huebner has kindly raised the ASDF-announce(a)common-lisp.net mailing list from the dead. See http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-announce for more details. Please either sign your list up for ASDF-announce, or appoint someone in your maintenance community to subscribe. In return, I undertake to keep traffic to this mailing list to an absolute minimum. Indeed, for the moment, I will be turning on "emergency" moderation of all traffic, to enforce this. I plan to cease sending these mass emails upon ASDF releases, effective immediately, so please do monitor the announcement list. Best, Robert _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] ASDF errors in latest ABCL
by Cyrus Harmon 19 Aug '14

19 Aug '14

So, it’s quite possible I’m doing something wrong here, but I’m having a problem loading an ASDF file: Error (UNBOUND-SLOT) during printing: #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {342BCE09}> [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] Restarts: 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system abcl-cdk after reinitializing the source-registry. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {776A693B}> #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {342BCE09}> #<FUNCTION {776A693B}>) 1: (APPLY #<FUNCTION {776A693B}> (#<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {342BCE09}> #<FUNCTION {776A693B}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {342BCE09}> #<FUNCTION {776A693B}>) 3: (INVOKE-DEBUGGER #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {342BCE09}>) 4: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "abcl-cdk" :PATHNAME #P"/Users/sly/projects/abcl-cdk/abcl-cdk.asd" ...) 5: (#<FUNCTION {6B22DDBC}> #<PROGRAM-ERROR {27E3CBA1}>) 6: (SIGNAL #<PROGRAM-ERROR {27E3CBA1}>) 7: (ERROR PROGRAM-ERROR :FORMAT-CONTROL "Invalid initarg ~S in call to ~S with arglist ~S." :FORMAT-ARGUMENTS (:REPOSITORY MAKE-INSTANCE (#<ASDF/INTERFACE:MVN {5C4DCB7C}> :NAME "org.openscience.cdk/cdk-b.. 8: (MOP::CHECK-INITARGS (#<STANDARD-GENERIC-FUNCTION {22978F81}> #<STANDARD-GENERIC-FUNCTION {513D2D11}>) (#<ASDF/INTERFACE:MVN {5C4DCB7C}> :NAME "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :PATHNAME.. 9: (#<FUNCTION {6B4F0153}> #<STANDARD-CLASS ASDF/INTERFACE:MVN {2A4AE9E8}> :NAME "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :PATHNAME NIL ...) 10: (APPLY #<FUNCTION {6B4F0153}> (#<STANDARD-CLASS ASDF/INTERFACE:MVN {2A4AE9E8}> :NAME "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :PATHNAME NIL :PARENT ...)) 11: (MAKE-INSTANCE #<STANDARD-CLASS ASDF/INTERFACE:MVN {2A4AE9E8}> :NAME "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :PATHNAME NIL ...) 12: (APPLY MAKE-INSTANCE #<STANDARD-CLASS ASDF/INTERFACE:MVN {2A4AE9E8}> (:NAME "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :PATHNAME NIL :PARENT #<ASDF/SYSTEM:SYSTEM {3E0B9897}> ...)) 13: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM #<ASDF/SYSTEM:SYSTEM {3E0B9897}> (:MVN "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT" :REPOSITORY NIL) :PREVIOUS-SERIAL-COMPONENT "org.freehep/freehep-graph.. 14: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "abcl-cdk" :PATHNAME NIL :NAME "abcl-cdk" ...)) 15: (#<FUNCTION {FE0272F}>) 16: (ASDF/CACHE:CALL-WITH-ASDF-CACHE #<FUNCTION {FE0272F}> :OVERRIDE NIL :KEY NIL) 17: (ASDF/PARSE-DEFSYSTEM:REGISTER-SYSTEM-DEFINITION :ABCL-CDK :NAME "abcl-cdk" :AUTHOR "Cyrus Harmon" ...) 18: (APPLY ASDF/PARSE-DEFSYSTEM:REGISTER-SYSTEM-DEFINITION :ABCL-CDK (:NAME "abcl-cdk" :AUTHOR "Cyrus Harmon" :SERIAL T ...)) 19: (SYSTEM::%LOAD #P"/Users/sly/projects/abcl-cdk/abcl-cdk.asd" NIL NIL T :UTF-8) --more-- So while it’s possible there may be an error in my ASDF file, it seems like we’re erroring out with a bogus error message. I’m having a hard time figuring out what the invalid initarg it’s complaining about in lines 7 and 8 are. Cyrus _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] [CfPart] International Lisp Conference 2014, August 15-17, Montreal
by Didier Verna 19 Aug '14

19 Aug '14

ILC 2014 - International Lisp Conference "Lisp on the Move" August 15-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users In cooperation with: ACM SIGPLAN http://ilc2014.iro.umontreal.ca/ Latest News: * Only 4 days left before the early registration deadline! * Registration is now open. See http://ilc2014.iro.umontreal.ca/registration.php * Invited speakers announced. Christian Queinnec, Ambrose Bonnaire-Sergeant, Stefan Monnier, Marc Battyani. Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. This year's focus is directed towards integrated solutions, including mobile computing. The conference also provides slots for lightning talks, to be registered on-site every day. The full programme is available here: http://ilc2014.iro.umontreal.ca/program.php Important Dates: - July 14, 2014: Early registration deadline - August 15, 2014: Conference starts Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USA Irène Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Möller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA Contact: ilc14-organizing-committee at alu.org For more information, see http://ilc2014.iro.umontreal.ca/ -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

[Armedbear-devel] handling dependencies
by Eduardo Bellani 18 Aug '14

18 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello guys. This is my first post on the list, and beg your forgiveness if this question was already answered, but alas, my search-fu was incapable of finding anything that could have helped me. Here is my situation: I am trying to build a servlet using ABCL. The servlet is a middleware that will expose an API, consume JSON, and return JSON. I will also store some data into a postgres RDBMS. I've used the google-app-engine example as a basis to build a skeleton of my app, with a Java class providing a proxy for the servlet. If I don't use any dependencies on my project, everything runs ok. My problem is that I have the following system descriptor: (asdf:defsystem #:abcl-servlet :serial t :description "An example of a servlet using the ABCL stack." :author "Eduardo Bellani <ebellani(a)gmail.com>" :license "Beerware v. 42" :depends-on (:jsown :postmodern) :components ((:module :src :components ((:file "package") (:file "servlet-interface"))))) As you can see, I have some dependencies on my code. Dependencies which I must load before my packages can run. I'm wondering how I can load this dependencies without explicitly coding the load calls. FWIWI, the java proxy class is here: public class ServletProxy extends HttpServlet { static private Symbol doGet = null; static private Symbol doPost = null; static private Symbol doDestroy = null; static private Object lock = new Object(); static private boolean initialized = false; private static void doWithStreamsBound(Symbol whatToDo, HttpServletRequest req, HttpServletResponse resp) throws IOException { LispThread currentThread = LispThread.currentThread(); SpecialBindingsMark mark = currentThread.markSpecialBindings(); currentThread.bindSpecial(Symbol.STANDARD_OUTPUT, new Stream(Symbol.SYSTEM_STREAM, resp.getOutputStream(), Symbol.CHARACTER, false)); currentThread.bindSpecial(Symbol.STANDARD_INPUT, new Stream(Symbol.SYSTEM_STREAM, resp.getInputStream(), Symbol.CHARACTER, false)); try { currentThread.execute(whatToDo); } finally { currentThread.resetSpecialBindings(mark); } } /** * Initialize the lisp interpreter that the symbols that will be * called on the lisp servlet interface. Not surprisingly, these * symbols mirror the HttpServlet interface. This is a result of * this class being only a proxy for the internal lisp system. */ public void init(ServletConfig config) throws ServletException { // No need for any external usage of theInit Symbol theInit = null; Interpreter.initializeLisp(); Load.load(config.getServletContext().getRealPath("fasls/first-servlet.abcl")); LispThread.currentThread(); doGet = Lisp.internInPackage("DO-GET", "SERVLET-INTERFACE"); doPost = Lisp.internInPackage("DO-POST", "SERVLET-INTERFACE"); theInit = Lisp.internInPackage("INIT", "SERVLET-INTERFACE"); theDestroy = Lisp.internInPackage("DESTROY", "SERVLET-INTERFACE"); } public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { ServletProxy.doWithStreamsBound(doGet, req, resp); } } I'm planning to write down a tutorial that covers building a web app in ABCL from scratch up to a running servlet that touches a DB and returns JSON, so I want to know the best way to do those things. Thanks for the attention, and please let me know if you guys have any questions or pointers. See you. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPxEoQACgkQSbLl0kCTjGnAFACfWLAzM2qO0juJ1NYF0foTNHB5 Ei8An0Kodo4+LVtrIyOydrbhr3MqM+n+ =bIT2 -----END PGP SIGNATURE----- _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[Armedbear-devel] ASDF-3.1.3 on abcl trunk
by Mark Evenson 06 Aug '14

06 Aug '14

[r14716][] contains asdf-3.1.3, which should not be functionally different from the previous asdf-3.1.2.9 [r14716]: http://abcl.org/trac/changeset/14716 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." _______________________________________________ Armedbear-devel mailing list Armedbear-devel(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0