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

[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