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

[CfP] 11th European Lisp Symposium, 16-17 Apr 2018, Marbella, Spain
by Didier Verna 18 Dec '17

18 Dec '17

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by EPITA 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 11th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 18 Feb 2018 Submission deadline - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson & Nick Levine, Ravenpack, Spain Programme committee: tba Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

FriCAS w. ABCL
by Kurt Pagani 05 Dec '17

05 Dec '17

I (almost) successfully compiled the fricas computer algebra system using ABCL (https://github.com/nilqed/fricas0) "Almost" because four of the over 1300 algebra files are refractory. I essentially got two errors: >> System error: The value :INT is not of type (COMMON-LISP:MEMBER COMMON-LISP:NIL :BOOLEAN). and >> System error: The assertion (COMMON-LISP:<= -32768 JVM::OFFSET 32767) failed. While the first one might be related to http://abcl.org/trac/ticket/316 (http://abcl.org/trac/changeset/15034) http://armedbear-devel.common-lisp.narkive.com/rm9OArfe/the-value-long-is-n… I have no idea what the second one could mean. Google, however, shows similar ones @: https://common-lisp.net/project/cl-test-grid/ql/qlalpha-2014-08-23-abcl-loa… (fishpack, lapack ...). Well, I'm stuck, so any ideas would be very welcome. Many thanks Kurt

2 2

Bug: format ~G of 1.0d0
by Willem Broekema 07 Nov '17

07 Nov '17

The following output seems to be wrong:(format nil "~G" 1.0d0) "1.0 " I expect it to be "1. " For the formula in CLHS "22.3.3.3 Tilde G: General Floating-Point" I arrive at q=0, n=1, d=1, dd=0 where dd stands for the number of decimals to print. Allegro, ECL, SBCL agree with this. Kind regards, Willem

1 0

Bug: defmacro environment variable declaration
by Willem Broekema 05 Nov '17

05 Nov '17

In the following form: (defmacro m (&environment e) (declare (ignore e)) 'm))) The declaration ends up in the wrong place after macro expansion: (LAMBDA (#:WHOLE-5584 #:ENVIRONMENT-5585) (LET* ((E #:ENVIRONMENT-5585)) ;; the (DECLARE (IGNORE E)) should go here (UNLESS (<= 0 (SYSTEM::DOT-LENGTH (CDR #:WHOLE-5584)) 0) (SYSTEM::ARG-COUNT-ERROR 'DEFMACRO 'M (CDR #:WHOLE-5584) '(&ENVIRONMENT E) 0 0)) (LET* () (DECLARE (IGNORE E)) ;; but it ends up here (BLOCK M 'M)))) Using Armed Bear Common Lisp 1.5.0 - Willem

1 0

abcl-web
by Alexandre Rademaker 16 Oct '17

16 Oct '17

What is the current status of http://abcl-web.sourceforge.net? What is the best alternative for web developing in ABCL? I am particularly interested in ABCL for using the Java starter kits in IBM Bluemix https://console.bluemix.net/developer/appservice/starter-kits Best, -- Alexandre Rademaker http://arademaker.github.io <http://arademaker.github.io/>

2 1

difficulties building abcl 1.5 from source distribution
by Guenther Thomsen 11 Oct '17

11 Oct '17

So far I wasn't able to build abcl release 1.5 under Linux (Ubuntu 16.04.3 which comes at this time with ant 1.9.6 and openjdk 1.8.0_131) from the distributed source [1]. The (ant) build completes (reportedly) successful even though there are errors: --8<-- [java] ; (DEFMACRO DIAG ...) [java] ; (DECLAIM (FTYPE # ...)) [java] ; (DEFUN VERIFY-LOAD ...) [java] ;SYSTEM:%MAKE-CONDITION triggers autoloading of org.armedbear.lisp.make_condition ... [java] ; Autoloaded org.armedbear.lisp.make_condition (0.001 seconds) [java] 2.081 seconds real time [java] 6753524 cons cells [java] FORMAT-ERROR: error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] Maximum error depth exceeded (11 nested errors) with '#<FORMAT-ERROR {67090C23}>'. [java] CL-USER(2): abcl.compile: [echo] Compiled ABCL with Java version: 1.8.0_131 abcl.version.src.0: abcl.version.src.1: abcl.version.src.2: abcl.version.src.3: abcl.version.src: abcl.stamp.version.uptodate: abcl.stamp.version.generate: abcl.stamp.version.0: abcl.stamp.version.1: abcl.stamp.version.2: abcl.stamp.version: [echo] ABCL implementation version: 1.5.0 abcl.stamp.hostname: [echo] abcl.hostname: slab abcl.stamp: abcl.jar.uptodate: abcl.contrib: abcl-contrib.jar: abcl.jar: [jar] Building jar: /home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar abcl.wrapper.unix: abcl.wrapper.windows: abcl.wrapper: [copy] Copying 1 file to /home/tho/Downloads/src/abcl-src-1.5.0 [echo] Created executable ABCL wrapper in 'abcl' [echo] N.B. This wrapper requires '/home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar' not be moved. BUILD SUCCESSFUL -->8-- Then the executable cannot be run: --8<-- $ ./abcl Armed Bear Common Lisp 1.5.0 Java 1.8.0_131 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.173 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) 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.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads-gen' in boot classpath. Failed to find loadable system file 'autoloads-gen' in boot classpath. Exception in thread "interpreter" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) 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.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) -->8-- Meanwhile I cloned the git repository and the HEAD as well as a branch off of commit 3e92245341ef07dd0915d1f7f59fa335626330db (release 1.5 [a tag would be nice, imho]) build and run successful, as far as I can tell. I noticed that the files in the zip archive are DOS formatted, which _shouldn't_ cause any such issue (making comparison with the files in the git repository a bit more cumbersome though). I haven't investigated further, as I got now a working abcl, but wanted to have mentioned it, as I couldn't find any hint regarding above error online. hth ~ Guenther [1] abcl-src-1.5.0.zip from https://common-lisp.net/project/armedbear/releases/1.5.0/abcl-src-1.5.0.zip

1 1

ASDF 3.3 is released
by Robert Goldman 07 Oct '17

07 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500

1 0

Compiler error during compile of TAGBODY and CATCH
by Paul Dietz 06 Oct '17

06 Oct '17

(compile nil '(lambda () (tagbody (catch 'c 17)))) ==> COMPILE-TAGBODY: tag not found: 17 [Condition of type SIMPLE-ERROR]

2 1

Compiler fail: Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.
by Paul Dietz 06 Oct '17

06 Oct '17

(defparameter *abcl1* '(lambda (a) (declare (optimize (debug 0) (compilation-speed 1) (speed 2) (space 3) (safety 1))) (ash 0 (bit #*0100 (catch 'ct7 a))))) (defun test1 () (let ((fn (compile nil *abcl1*))) (mapcar fn '(0 1 2 3)))) (test1) ==> ; Caught ERROR: ; Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.

2 1

It appears that ABCL is not ready for Java 9
by Gregory Baryza 27 Sep '17

27 Sep '17

I tried compiling it and was presented with the following error: .... [java] ; Loading C:/Downloads/Armed_Bear_Lisp/abcl-src-1.5.0/build/classes/org/armedbear/lisp/abcl-contrib.abcl ... [java] [java] ; Compilation unit finished [java] ; The following functions were used but not defined: [java] ; SYSTEM::SOURCE [java] [java] 311.988 seconds real time [java] 249904041 cons cells [java] JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No applicable method named getURLs found in java.lang.ClassLoader or jdk.internal.loader.ClassLoaders$AppClassLoader'. BUILD FAILED C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:280: The following error occurred while executing this line: C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:299: Java returned: -1 Total time: 6 minutes 11 seconds It compiled successfully under JDK_1_8_0_144. Has anyone else seen this?

4 6