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

Watson IoT MQTT with ABCL (dW recipe)
by Frederico Munoz 23 Apr '17

23 Apr '17

Hello all, Following my previous experiences with using Eclipe Paho with ABCL I wrote a more step-by-step tutorial that uses MQTT to send data to IBM's Watson IoT Platform. https://developer.ibm.com/recipes/tutorials/watson-iot-with-common-lisp/ It uses Quicklisp and tries to show to those who do not know ABCL the basics of what is possible. I'm sure there are some incorrections here and there but still, thought it would be interesting. The audience is the general community much more than those already acquainted with ABCL. Best regards -- fsmunoz(a)sdf.org SDF Public Access UNIX System - http://sdf.org

1 0

patch for bug 443 (ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument)
by Robert Dodier 17 Apr '17

17 Apr '17

Hi, here is a patch to fix bug 443. With this change, Maxima + ABCL passes its tests (in tests/rtest11.mac for the record) for parse_timedate which calls ENCODE-UNIVERSAL-TIME. Incidentally this patch also fixes an unreported bug in DECODE-UNIVERSAL-TIME: the daylight saving flag is reported incorrectly because EXT:GET-TIME-ZONE expects its argument in milliseconds, not seconds. I can't sign in to the bug tracker as the OpenID button doesn't work and I don't remember my common-lisp.net username/password and I don't see a way to get a password reminder on common-lisp.net. A comment on the bug tracker mentions Java 8. If I remember correctly, I tried the previous version of the code with both Java 7 and Java 8 and in both cases it fails. In any event the error seems to be pretty clearly a mistake in ENCODE-UNIVERSAL-TIME so I would be surprised if different Java versions yielded different results. Hope this helps, and all the best. Robert Dodier PS. This patch was taken against r14981 on armedbear-svn/trunk.

3 4

Help me get a Java object's name
by Mirko Vukovic 15 Apr '17

15 Apr '17

Hello, I am using the Apache POI library to read Excel files. The following is from within Slime. I am struggling to extract cell types as returned by getCellTypeEnum ( https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html#getCel… ()) My code returns a Java Object like so: #<org.apache.poi.ss.usermodel.CellType FORMULA {5C25A9}> It is of class #<java class org.apache.poi.ss.usermodel.CellType> I would like to grab the "FORMULA" in the above object description. Slime can see it, it's inspector can see it, even DESCRIBE can see it: READER> (describe *) #<org.apache.poi.ss.usermodel.CellType FORMULA {11CC24A}> is an object of type JAVA-OBJECT. The wrapped Java object is an instance of org.apache.poi.ss.usermodel.CellType: "FORMULA" But, I could not figure out a way to get to "FORMULA". I tried to accessing the slot `name' but that does not work. I looked at the FFI page, but found no clues. I tried to get slot names via AMOP: (mop:class-direct-slots (class-of java-cell-type)) returns NIL It must be something simple that I am overlooking. Help is appreciated. Thanks! Mirko

2 2

Easy Maven publishing for GitHub projects
by Alessio Stalla 29 Mar '17

29 Mar '17

FYI, if you're interested, I've just stepped on this: https://jitpack.io/

1 0

bug report: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument
by Robert Dodier 23 Mar '17

23 Mar '17

A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0. CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508 Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations. TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). Tried to submit a bug report via Trac but when I clicked on the OpenID button I get a connection reset error. Thanks for all your efforts, I appreciate it. Robert Dodier

2 1

integration with java's threading
by Devon Miller 13 Mar '17

13 Mar '17

I saw that Bordeaux threads uses a very thin layer of java threads in their abcl implementation file. I wanted to use some libraries from java that use threading fairly heavily (web apis) and was wondering if there had been good testing with exchanging data from the lisp layer to the java layer when threading is heavily used in the java layer. For example, passing xml and json s-expr into java for processing and sending out through a multi-threaded environment i.e. akka actors.

2 1

[CfPart] 10th European Lisp Symposium, Apr 3-4 2017, Brussels
by Didier Verna 03 Mar '17

03 Mar '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsors: Brunner Software GmbH, Franz Inc., LispWorks Ltd. and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 13 deadline for the full <Programming> conference early bird discount! 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: - Hans Hübner -- Identity in a World of Values - Bohdan B. Khomtchouk -- How the Strengths of Lisp Facilitate Building Complex and Flexible Bioinformatics Applications Important dates: - 13 Mar 2017 Early registration deadline - 03-04 Apr 2017 Symposium - 05-06 Apr 2017 <Programming> main tack Programme chair: Alberto Riva, University of Florida, USA Programme committee: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Erick Gallesio, Université de Nice Sophia-Antipolis, France Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy Chris Stacy, CS Consulting Search Keywords: #els2017, ELS 2017, ELS '17, European Lisp Symposium 2017, European Lisp Symposium '17, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2017, European Lisp Conference '17 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

asdf:defsystem complains about path, sometimes
by Mirko Vukovic 01 Mar '17

01 Mar '17

Hello, This is with asdf 3.1.7.27, Armed Bear Common Lisp 1.4.0 Java 1.6.0_41 Sun Microsystems Inc. OpenJDK 64-Bit Server VM, Emacs & Slime The following example code from the ASDF manual (asdf:defsystem "hello-lisp" :description "hello-lisp: a sample Lisp system." :version "0.0.1" :author "Joe User <joe(a)example.com>" :licence "Public Domain" :depends-on ("optima.ppcre" "command-line-arguments") :components ((:file "packages") (:file "macros" :depends-on ("packages")) (:file "hello" :depends-on ("macros")))) when executed via the ABCL command line gives a relative path error Invalid relative pathname #P"packages.lisp" for component ("hello-lisp" "packages") Restarts: 0: RETRY Retry ASDF operation. 1: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 2: TOP-LEVEL Return to top level. If that code is in a file, then the file compiles cleanly: CL-USER(6): (load (compile-file "test.asd")) ; Compiling /home/mv/projects/poi+excel/test.asd ... ; (IN-PACKAGE :CL-USER) ; (ASDF/PARSE-DEFSYSTEM:DEFSYSTEM "hello-lisp" ...) ; Wrote /home/mv/projects/poi+excel/test.abcl (0.021 seconds) T CL-USER(7): I am looking for confirmation of this and second opinions before taking up at the ASDF mailing list. Thanks, Mirko

3 4

sys:run-program errs (both Windows & Linux)
by Mirko Vukovic 15 Jan '17

15 Jan '17

While narrowing down the problems I was having with maven and cffi, I came across the maven-embedded.lisp file ( https://common-lisp.net/svn/armedbear/branches/1.4.0/contrib/abcl-asdf/mave… ) where I saw the sys:run-program. I now have ABCL installed on both Linux and Windows, and have problems on both when issuing #+windows(sys:run-program "where.exe" nil) #+linux(sys:run-program "which" nil) On Windows, the first call fails, while the second succeeds. On Linux, the call fails, and repeated calls also fail. Is this just me or can anyone else reproduce this? Thanks. Transcript of the Windows 10 session (Linux follows) P:\>java -jar c:\mv-program-files\abcl-bin-1.4.0\abcl.jar --noinit Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.274 seconds. Startup completed in 4.28 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "which.exe" nil) ;;; *First invocation results in error* Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess ;;; *ERROR* Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError ... Java stack elided Caused by: org.armedbear.lisp.Go Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_49 from org.armedbear.lisp.Pathname@60a4bd75 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (sys:run-program "which.exe" nil) ;;; *Second invocation succeeds* #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl java.lang.ProcessImpl@6aaa6218 {2F20252D}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(5): On Linux I work through Slime. Here is the startup message on a RedHat EL6. I hope my Java patch is recent enough. Armed Bear Common Lisp 1.4.0 Java 1.6.0_40 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.491 seconds. Startup completed in 2.488 seconds. Using probed value of abcl-contrib: '/usr/local/share/java/abcl-contrib.jar'. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/abcl-asdf/ to ASDF. Loading /home/mv/.abclrc completed in 9.644 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading /home/sm/software/slime/swank-loader.lisp ... Doing (sys:run-program "which" nil) the error backtrace is: Class not found: java.lang.ProcessBuilder$Redirect [Condition of type ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {5A18A372}> #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 1: (APPLY #<FUNCTION {5A18A372}> (#<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 3: (INVOKE-DEBUGGER #<ERROR {47BE45A7}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.classForName(Java.java:1299) 6: org.armedbear.lisp.Java.javaClass(Java.java:1332) 7: org.armedbear.lisp.Java.javaClass(Java.java:1306) 8: org.armedbear.lisp.Java.jfield(Java.java:177) 9: org.armedbear.lisp.Java$pf_jfield.execute(Java.java:272) 10: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 11: (JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT") 12: (SYSTEM:INIT-FASL :VERSION 42) 13: (SYSTEM::%MAKE-PROCESS-BUILDER "which" NIL) 14: (SYSTEM:RUN-PROGRAM "which" NIL) 15: (SYSTEM::%EVAL (SYSTEM:RUN-PROGRAM "which" NIL)) 16: (EVAL (SYSTEM:RUN-PROGRAM "which" NIL))

2 2

Strange, magical, thing :)
by Marco Antoniotti 13 Jan '17

13 Jan '17

Hi just to point out what happens hitting (or just writing) the following address in you Browser :) (I noticed it because of my CL Ook compiler) ook.common-lisp.net Cheers -- Marco Antoniotti

2 1