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

[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