- ecl-devel - mailman3.common-lisp.net

About the source of The ECL Manual
by NOEU 22 Feb '20

22 Feb '20

Hello. I want to translate "The ECL Manual(https://common-lisp.net/project/ecl/static/manual/)" into my native language (Japanese). Because I couldn't find the translated version. Is "The ECL Manual" generated by DocBook? Please let me know if I have a way to get the XML source for The ECL Manual. Thanks

2 2

Combining ~T and ~<~:;~>
by Eric Timmons 03 Feb '20

03 Feb '20

I've been using ECL to compile SBCL on aarch64, but I can't do it without patching the sources. There is a warning triggered during the build (only on aarch64) with a format string that contains: ~<~%~9T~:;~/sb-impl:print-type/:~> ECL chokes on this due to the ~T in the ~:; clause. Why is that not allowed? It seems like a reasonable thing to do at first glance. -Eric

2 1

[CfP] Reminder: 13rd European Lisp Symposium, April 27-28, Zürich
by Didier Verna 22 Jan '20

22 Jan '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 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. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. 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 http://www.easychair.org/conferences/?conf=els2020 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. Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Raspberry Pi test results
by Dave Richards 06 Jan '20

06 Jan '20

These are the results of testing ECL on a Raspberry Pi 3B+ running Raspbian Buster. Because the Raspberry Pi 3B+ has only 1G of RAM and the default swap size for Raspbian Buster is 100M it is highly recommended that you extend the swap size to something larger. I use 1G. Instructions for doing this are located at: https://wpitchoune.net/tricks/raspberry_pi3_increase_swap_size.html (I was unable to build Ironclad successfully without doing this.) My build configuration is: ./configure \ --enable-shared \ --enable-threads \ --enable-boehm=system \ --enable-libatomic=system \ --enable-gmp=system \ --enable-c99complex \ --enable-unicode=32 \ --enable-smallcons \ --with-tcp \ --with-serve-event \ --with-clos-streams \ --with-cmuformat \ --with-asdf \ --without-defsystem \ --with-cmp \ --with-bytecmp \ --with-dffi=included \ --with-fpe \ --with-signed-zero \ --with-ieee-fp \ --prefix=${HOME}/ecl The FPU on the Raspberry Pi does not generate CPUexceptions, which prevents Linux from generating SIGFPE signals, which prevents ECL from detecting floating-point errors and delivering appropriate error conditions. The patch below causes ECL to poll for floating-point errors (rather than relying on SIGFPEs). This situation is properly detected by 'make check'. diff --git a/src/aclocal.m4 b/src/aclocal.m4 index d1e626a7..ffcd1ad3 100644 --- a/src/aclocal.m4 +++ b/src/aclocal.m4 @@ -865,6 +865,10 @@ case "${host_cpu}" in ECL_FPE_CODE="arch/fpe_x86.c" AC_MSG_RESULT([x86_64]) ;; + arm* ) + ECL_FPE_CODE="arch/fpe_fenv.c" + AC_MSG_RESULT([arm]) + ;; *) ECL_FPE_CODE="arch/fpe_none.c" AC_MSG_RESULT([not available]) (src/configure needs to be re-generated.) Add the file src/c/arch/fpe_fenv.c: /* -*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*- */ /* vim: set filetype=c tabstop=8 shiftwidth=4 expandtab: */ /* fpe_fenv.c -- ISO C99 version of the floating point code */ /* Copyright (c) 2005, Juan Jose Garcia Ripoll. ECL is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See file '../Copyright' for full details. */ /* * See fpe_none.c for a description */ #define ecl_detect_fpe() do { \ int bits = fetestexcept(FE_ALL_EXCEPT); \ unlikely_if (bits) ecl_deliver_fpe(bits); } while(0) The results of 'make check' are as follows: Did 215 tests (0 crashed), 17647 checks. Pass: 17645 (100%) Fail: 2 ( 0%) Failure details: -------------------------------- MIX.0016.FIFO-TESTS: FAIL: (EQUAL "foobar" (READ-LINE STREAM NIL :FOO)) -------------------------------- CMP.0044.INLINE-COS: FAIL: (NULL #:OO-1328) Expected NIL, but got (SHORT-FLOAT SINGLE-FLOAT) -------------------------------- I did not run ansi-test. It takes too long to run on a Raspberry Pi. I did not run the maxima tests. I gave up after being unable to get them to build and run. I was curious to see how the C99 complex data type would perform. The cl-bench results are: ;; -*- lisp -*- ECL 16.1.3 ;; #| Implementation *features*: (:QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :WALKER :CDR-1 :CDR-5 :LINUX :FORMATTER :CDR-7 :ECL-WEAK-HASH :LITTLE-ENDIAN :ECL-READ-WRITE-LOCK :LONG-LONG :UINT64-T :UINT32-T :UINT16-T :COMPLEX-FLOAT :LONG-FLOAT :UNICODE :DFFI :CLOS-STREAMS :CMU-FORMAT :UNIX :ECL-PDE :DLOPEN :CLOS :THREADS :BOEHM-GC :ANSI-CL :COMMON-LISP :IEEE-FLOATING-POINT :PACKAGE-LOCAL-NICKNAMES :CDR-14 :PREFIXED-API :FFI :ARMV7L :COMMON :ECL) |# ;; ;; Function real user sys consed ;; ---------------------------------------------------------------- ;; COMPILER 42.38 6.79 NIL NIL ;; LOAD-FASL 0.85 0.73 NIL NIL ;; SUM-PERMUTATIONS 4.23 4.31 NIL NIL ;; WALK-LIST/SEQ 0.02 0.02 NIL NIL ;; WALK-LIST/MESS 0.21 0.21 NIL NIL ;; BOYER 4.66 4.66 NIL NIL ;; BROWSE 1.81 1.81 NIL NIL ;; DDERIV 4.19 4.23 NIL NIL ;; DERIV 4.44 4.48 NIL NIL ;; DESTRUCTIVE 2.16 2.16 NIL NIL ;; DIV2-TEST-1 5.33 5.42 NIL NIL ;; DIV2-TEST-2 6.77 6.87 NIL NIL ;; FFT 3.10 3.09 NIL NIL ;; FRPOLY/FIXNUM 4.64 4.64 NIL NIL ;; FRPOLY/BIGNUM 1.93 1.93 NIL NIL ;; FRPOLY/FLOAT 5.36 5.36 NIL NIL ;; PUZZLE 15.64 15.64 NIL NIL ;; TAK 5.69 5.69 NIL NIL ;; CTAK 7.32 7.32 NIL NIL ;; TRTAK 5.72 5.72 NIL NIL ;; TAKL 3.30 3.30 NIL NIL ;; STAK 7.51 7.51 NIL NIL ;; FPRINT/UGLY 5.31 5.19 NIL NIL ;; FPRINT/PRETTY 55.37 54.43 NIL NIL ;; TRAVERSE 18.21 18.21 NIL NIL ;; TRIANGLE 13.39 13.39 NIL NIL ;; RICHARDS 37.24 37.24 NIL NIL ;; FACTORIAL 0.68 0.74 NIL NIL ;; FIB 2.66 2.66 NIL NIL ;; FIB-RATIO 0.28 0.28 NIL NIL ;; ACKERMANN 25.50 25.49 NIL NIL ;; MANDELBROT/COMPLEX 0.80 0.80 NIL NIL ;; MANDELBROT/DFLOAT 3.88 3.99 NIL NIL ;; MRG32K3A 11.40 11.56 NIL NIL ;; CRC40 473.48 481.94 NIL NIL ;; BIGNUM/ELEM-100-1000 0.14 0.14 NIL NIL ;; BIGNUM/ELEM-1000-100 0.18 0.18 NIL NIL ;; BIGNUM/ELEM-10000-1 0.24 0.24 NIL NIL ;; BIGNUM/PARI-100-10 0.02 0.02 NIL NIL ;; BIGNUM/PARI-200-5 0.06 0.06 NIL NIL ;; PI-DECIMAL/SMALL 5.43 5.43 NIL NIL ;; PI-DECIMAL/BIG 5.99 5.98 NIL NIL ;; PI-ATAN 1.26 1.36 NIL NIL ;; PI-RATIOS 1.66 1.66 NIL NIL ;; HASH-STRINGS 2.03 2.03 NIL NIL ;; HASH-INTEGERS 2.23 2.23 NIL NIL ;; SLURP-LINES 0.00 0.00 NIL NIL ;; BOEHM-GC 20.03 21.11 NIL NIL ;; DEFLATE-FILE 7.48 7.47 NIL NIL ;; 1D-ARRAYS 0.72 0.72 NIL NIL ;; 2D-ARRAYS 9.32 9.34 NIL NIL ;; 3D-ARRAYS 19.78 19.81 NIL NIL ;; BITVECTORS 8.37 8.42 NIL NIL ;; BENCH-STRINGS 19.93 19.93 NIL NIL ;; fill-strings/adjustable 9.83 20.80 NIL NIL ;; STRING-CONCAT 169.24 175.45 NIL NIL ;; SEARCH-SEQUENCE 11.97 11.97 NIL NIL ;; CLOS/defclass 7.03 1.19 NIL NIL ;; CLOS/defmethod 7.45 0.85 NIL NIL ;; CLOS/instantiate 29.34 29.33 NIL NIL ;; CLOS/simple-instantiate 94.13 94.17 NIL NIL ;; CLOS/methodcalls 8.39 8.53 NIL NIL ;; CLOS/method+after 12.48 6.62 NIL NIL ;; CLOS/complex-methods 4.43 4.43 NIL NIL ;; EQL-SPECIALIZED-FIB 9.37 9.37 NIL NIL ("ECL 16.1.3" ("EQL-SPECIALIZED-FIB" 9.37 9.366 NIL NIL) ("CLOS/complex-methods" 4.431 4.431 NIL NIL) ("CLOS/method+after" 12.478 6.618 NIL NIL) ("CLOS/methodcalls" 8.389 8.531 NIL NIL) ("CLOS/simple-instantiate" 94.132 94.17 NIL NIL) ("CLOS/instantiate" 29.339 29.329 NIL NIL) ("CLOS/defmethod" 7.449 0.85 NIL NIL) ("CLOS/defclass" 7.025 1.194 NIL NIL) ("SEARCH-SEQUENCE" 11.974 11.973 NIL NIL) ("STRING-CONCAT" 169.244 175.447 NIL NIL) ("fill-strings/adjustable" 9.834 20.797 NIL NIL) ("BENCH-STRINGS" 19.926 19.927 NIL NIL) ("BITVECTORS" 8.366 8.422 NIL NIL) ("3D-ARRAYS" 19.779 19.811 NIL NIL) ("2D-ARRAYS" 9.317 9.337 NIL NIL) ("1D-ARRAYS" 0.724 0.724 NIL NIL) ("DEFLATE-FILE" 7.476 7.468 NIL NIL) ("BOEHM-GC" 20.031 21.107 NIL NIL) ("SLURP-LINES" 0.004 0.003 NIL NIL) ("HASH-INTEGERS" 2.23 2.227 NIL NIL) ("HASH-STRINGS" 2.027 2.025 NIL NIL) ("PI-RATIOS" 1.663 1.662 NIL NIL) ("PI-ATAN" 1.257 1.36 NIL NIL) ("PI-DECIMAL/BIG" 5.989 5.983 NIL NIL) ("PI-DECIMAL/SMALL" 5.429 5.427 NIL NIL) ("BIGNUM/PARI-200-5" 0.065 0.064 NIL NIL) ("BIGNUM/PARI-100-10" 0.019 0.019 NIL NIL) ("BIGNUM/ELEM-10000-1" 0.239 0.238 NIL NIL) ("BIGNUM/ELEM-1000-100" 0.179 0.177 NIL NIL) ("BIGNUM/ELEM-100-1000" 0.138 0.139 NIL NIL) ("CRC40" 473.485 481.938 NIL NIL) ("MRG32K3A" 11.4 11.564 NIL NIL) ("MANDELBROT/DFLOAT" 3.879 3.987 NIL NIL) ("MANDELBROT/COMPLEX" 0.798 0.798 NIL NIL) ("ACKERMANN" 25.495 25.494 NIL NIL) ("FIB-RATIO" 0.275 0.275 NIL NIL) ("FIB" 2.665 2.665 NIL NIL) ("FACTORIAL" 0.683 0.736 NIL NIL) ("RICHARDS" 37.243 37.244 NIL NIL) ("TRIANGLE" 13.387 13.386 NIL NIL) ("TRAVERSE" 18.207 18.206 NIL NIL) ("FPRINT/PRETTY" 55.373 54.429 NIL NIL) ("FPRINT/UGLY" 5.308 5.191 NIL NIL) ("STAK" 7.511 7.511 NIL NIL) ("TAKL" 3.303 3.302 NIL NIL) ("TRTAK" 5.718 5.718 NIL NIL) ("CTAK" 7.325 7.324 NIL NIL) ("TAK" 5.692 5.692 NIL NIL) ("PUZZLE" 15.643 15.642 NIL NIL) ("FRPOLY/FLOAT" 5.357 5.357 NIL NIL) ("FRPOLY/BIGNUM" 1.932 1.933 NIL NIL) ("FRPOLY/FIXNUM" 4.643 4.643 NIL NIL) ("FFT" 3.095 3.094 NIL NIL) ("DIV2-TEST-2" 6.772 6.869 NIL NIL) ("DIV2-TEST-1" 5.331 5.424 NIL NIL) ("DESTRUCTIVE" 2.16 2.16 NIL NIL) ("DERIV" 4.437 4.476 NIL NIL) ("DDERIV" 4.188 4.234 NIL NIL) ("BROWSE" 1.809 1.807 NIL NIL) ("BOYER" 4.662 4.662 NIL NIL) ("WALK-LIST/MESS" 0.207 0.207 NIL NIL) ("WALK-LIST/SEQ" 0.017 0.017 NIL NIL) ("SUM-PERMUTATIONS" 4.23 4.312 NIL NIL) ("LOAD-FASL" 0.85 0.732 NIL NIL) ("COMPILER" 42.378 6.788 NIL NIL))

3 5

Re: Error while running a simple GTK program with ECL
by Marius Gerbershagen 06 Jan '20

06 Jan '20

Hi, > Hi list, > I am sorry I didn't find an ECL-User mailing list, so I post this question here. If here is not the right place to ask this kind of question, please let me know. > I wrote a simple GTK program using cl-gtk2-gtk, please see it here:http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp > > After I installed the dependent packages using quicklisp, I ran it with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It compiled for about 5 hours, and emitted an error, here is the log:http://depot.kdr2.com/scrappy/202001/ecl-gtk.log The important parts of the log are the errors such as (Error: "/tmp/ecl3258uX7y8Y.fas: failed to map segment from shared object") I can't tell you exactly how to fix this, but it is clear that the cl-gtk2-gtk system is compiling A HUGE NUMBER of files and also single functions. This number might be simply too big for ECL to handle and the above error a result of some limit on the number of shared libraries that one can load imposed by the glibc or the kernel, I don't know. > Then I run it again, it gave a different error: > ```$ ecl --load ecl-gtk.lisp;;; Loading "/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;; Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.3/asdf.fas"An error occurred during initialization:The slot ASDF/PLAN::STAMP in the object #<action-status > Condition of type: STACK-OVERFLOWBINDING-STACK overflow at size 10240. Stack can probably be resized.Proceed with caution.Available restarts: > 1. (CONTINUE) Extend stack size2. (RETRY) Retry ASDF operation.3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">.5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful.6. (RETRY) Retry ASDF operation.7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.8. (CONTINUE) Ignore initialization errors and continue.9. (ABORT) Quit ECL unsafely, ignoring all existing threads. > Top level in: #<process TOP-LEVEL>.> > ``` I have seen errors like this before when asdf was trying (and failing) to replace itself with a newer version. You can check whether you have a copy of a newer asdf in a place where asdf will search for its systems and remove that copy. If you really need the new asdf, you need to generate the asdf.lisp file containing all of asdf from the sources (see the asdf documentation for how to do that), drop that in place of the "contrib/asdf/asdf.lisp" file in the ECL sources and recompile ECL. Best regards, Marius Gerbershagen

3 5

Error while running a simple GTK program with ECL
by ZHUO Qingliang (KDr2) 04 Jan '20

04 Jan '20

Hi list, I am sorry I didn't find an ECL-User mailing list, so I post this question here. If here is not the right place to ask this kind of question, please let me know. I wrote a simple GTK program using cl-gtk2-gtk, please see it here:http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp After I installed the dependent packages using quicklisp, I ran it with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It compiled for about 5 hours, and emitted an error, here is the log:http://depot.kdr2.com/scrappy/202001/ecl-gtk.log Then I run it again, it gave a different error: ```$ ecl --load ecl-gtk.lisp;;; Loading "/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;; Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading #P"/usr/lib/x86_64-linux-gnu/ecl-16.1.3/asdf.fas"An error occurred during initialization:The slot ASDF/PLAN::STAMP in the object #<action-status Condition of type: STACK-OVERFLOWBINDING-STACK overflow at size 10240. Stack can probably be resized.Proceed with caution.Available restarts: 1. (CONTINUE) Extend stack size2. (RETRY) Retry ASDF operation.3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">.5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful.6. (RETRY) Retry ASDF operation.7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration.8. (CONTINUE) Ignore initialization errors and continue.9. (ABORT) Quit ECL unsafely, ignoring all existing threads. Top level in: #<process TOP-LEVEL>.> ``` Here is the information of my system: # System Summary Report ############################## Date | 2020-01-04 12:57:44 UTC (local TZ: CST +0800) Hostname | Debian-X230 Uptime | 45 days, 4:37, 12 users, load average: 0.16, 0.04, 0.01 Release | Debian GNU/Linux bullseye/sid (sid) Kernel | 4.18.0-1-amd64Architecture | CPU = 64-bit, OS = 64-bit Threading | NPTL 2.29 SELinux | No SELinux detected# Processor ################################################## Processors | physical = 1, cores = 2, virtual = 4, hyperthreading = yes Speeds | 1x1546.829, 1x1599.499, 1x1608.905, 1x1643.428 Models | 4xIntel(R) Core(TM) i7-3520M CPU @ 2.90GHz Caches | 4x4096 KB# Memory ##################################################### Total | 15.40G Free | 6.30G Used | physical = 3.32G, swap = 902.84M, virtual = 4.20G Buffers | 5.78G Caches | 11.51G Used | 1.59G Swappiness | vm.swappiness = 60 DirtyPolicy | vm.dirty_ratio = 40, vm.dirty_background_ratio = 10 DirtyStatus | vm.dirty_bytes = 0, vm.dirty_background_bytes = 0 $ ecl --versionECL 16.1.3$ gcc --versiongcc (Debian 9.2.1-17) 9.2.1 20191102Copyright (C) 2019 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Anyone knows why and how to fix this? Thanks! Greetings. ZHUO Qingliang (KDr2, http://kdr2.com)

1 0

[ecl 20.1.x][rc testing]
by Daniel Kochmański 03 Jan '20

03 Jan '20

Dear All, After three years of development we are closing to a new release. During this time many important features and fixes has been made. We also have a new co-maintainer of the project – Marius Gerbershagen, what is a fantastic news (especially from a bus-factor perspective :-). If you have spare machines (especially on uncommon architectures/ operating systems), it would be very helpful if you could help with testing. I'm tracking testing progress here: https://gitlab.com/embeddable-common-lisp/ecl/issues/333 there is no need to limit yourself to the mentioned platforms and it is possible that we will omit some listed there, so please treat it more like a wishlist than an actual roadmap. We are especially interested in regressions (that is issues which are not present in 16.1.3 but occur in the current develop branch) - of course if you encounter other problems please report them too, but they will be most likely addressed after the release. Thank you for your help; I hope that we will be able to release the new version on January 2020. As a side note, I've been invited to give a talk at the European Lisp Symposium this year about ECL. Currently I'm working on the compiler documentation and refactoring as well as the IR visualizer, but these changes will be proposed after there release. Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

2 1

FP exceptions on Raspberry Pi
by Dave Richards 31 Dec '19

31 Dec '19

It appears that the VFP unit on the Raspberry Pi does not generate FPU exceptions. Therefore, no SIGFPE is generated and cannot be handled by ECL. This causes numerous 'make check' test failures. I am working on a patch. I am not very familiar with the ECL C environment so I am sure the patch will need some help. The approach is as follows: 1. There is no value in registering a SIGFPE handler. For the ARM I will just not register the handler at all. 2. I will created an arch/fpe_arm.c file. I will re-define the macro to read the FPSCR register and check for exception bits being set. If any are I will call a C function that will disambiguate which exception to map to a condition and signal the condition. 3. I was planning on creating a static inline function for this purpose right inside fpe_arm.c but if it should go somewhere else I'd be happy to put it there. The inline thing is just an excuse for sticking in the fpe_arm.c file. In reality it's probably better to make a C function call to do the heavy lifting rather than making each FPE check pay for it. Dave

2 1

Build error on Raspbian Buster
by Dave Richards 30 Dec '19

30 Dec '19

When I build --with-dffi=included everything builds fine. When I build --with-dffi=system I get the following build error: (sorry for those escape sequences, not sure why they are there, I bet there is some colorization going on somewhere, which is ironic since I am blind and it doesn't help me a bit). dpp: /home/pi/ecl.git/src/c/ffi.d -> ffi.o.c [K/home/pi/ecl.git/src/c/ffi.d:218:4:[m[K [01;31m[Kerror: [m[K'[01m[Kffi_type_complex_float[m[K' undeclared here (not in a function); did you mean '[01m[Ksi_complex_float[m[K'? &[01;31m[Kffi_type_complex_float[m[K, /*@':csfloat',*/ [01;31m[K^~~~~~~~~~~~~~~~~~~~~~[m[K [32m[Ksi_complex_float[m[K [01m[K/home/pi/ecl.git/src/c/ffi.d:219:4:[m[K [01;31m[Kerror: [m[K'[01m[Kffi_type_complex_double[m[K' undeclared here (not in a function); did you mean '[01m[Kffi_type_longdouble[m[K'? &[01;31m[Kffi_type_complex_double[m[K, /*@':cdfloat',*/ [01;31m[K^~~~~~~~~~~~~~~~~~~~~~~[m[K [32m[Kffi_type_longdouble[m[K [01m[K/home/pi/ecl.git/src/c/ffi.d:220:4:[m[K [01;31m[Kerror: [m[K'[01m[Kffi_type_complex_longdouble[m[K' undeclared here (not in a function); did you mean '[01m[Kffi_type_longdouble[m[K'? &[01;31m[Kffi_type_complex_longdouble[m[K, /*@':clfloat',*/ [01;31m[K^~~~~~~~~~~~~~~~~~~~~~~~~~~[m[K [32m[Kffi_type_longdouble[m[K make[2]: *** [Makefile:88: ffi.o] Error 1 make[2]: Leaving directory '/home/pi/ecl.git/build/c' make[1]: *** [Makefile:144: libeclmin.a] Error 2 make[1]: Leaving directory '/home/pi/ecl.git/build' make: *** [Makefile:65: all] Error 2

2 1

Error when building ironclad
by Dave Richards 28 Dec '19

28 Dec '19

This occurs on my Raspberry Pi 3B+ running Raspbian Buster on current ECL: Script started on 2019-12-28 05:53:34-08:00 [TERM="xterm" TTY="/dev/pts/0" COLUMNS="80" LINES="24"] ]0;pi@raspberrypi: ~ [01;32mpi@raspberrypi[00m:[01;34m~ $[00m ecl ;;; Loading "/home/pi/quicklisp/setup.lisp" ;;; Loading #P"/home/pi/ecl/lib/ecl-16.1.3/asdf.fas" ECL (Embeddable Common-Lisp) 16.1.3 (git:87a1c5faed97bd0b946a4fd82f33cb666879cd4f) Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2013 Juan J. Garcia-Ripoll Copyright (C) 2018 Daniel Kochmanski Copyright (C) 2019 Daniel Kochmanski and Marius Gerbershagen ECL is free software, and you are welcome to redistribute it under certain conditions; see file 'Copyright' for details. Type :h for Help. Top level in: #<process TOP-LEVEL 0x709fc0>. > (ql:quickload "ironclad") To load "ironclad": Load 1 ASDF system: ironclad ; Loading "ironclad" [package nibbles]................................. [package alexandria.1.0.0]........................ [package bordeaux-threads]........................ [package ironclad]................................ .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. ............ ;;; Internal error: ;;; ** Error code 1 when executing ;;; (SI:RUN-PROGRAM-INNER "gcc" ("-I." "-I/home/pi/ecl/include/" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-g" "-O2" "-fPIC" "-D_THREAD_SAFE" "-Dlinux" "-O2" "-c" ".cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists /quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c" "-o" ".cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists /quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.o") NIL): ;;; .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/ quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c: In function 'L49kalyna512_decrypt_block': ;;; .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/ quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c:231231:18: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without ;;; static cl_object L49kalyna512_decrypt_block(cl_object v1context, cl_object v2ciphertext, cl_object v3ciphertext_start, cl_object v4plaintext, cl_object v5plaintext_start) ;;; ^~~~~~~~~~~~~~~~~~~~~~~~~~ ;;; .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/ quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c: In function 'L48kalyna512_encrypt_block': ;;; .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/ quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c:185126:18: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without ;;; static cl_object L48kalyna512_encrypt_block(cl_object v1context, cl_object v2plaintext, cl_object v3plaintext_start, cl_object v4ciphertext, cl_object v5ciphertext_start) ;;; ^~~~~~~~~~~~~~~~~~~~~~~~~~ ;;; gcc: fatal error: Killed signal terminated program cc1 ;;; compilation terminated. Condition of type: COMPILE-FILE-ERROR COMPILE-FILE-ERROR while compiling #<ironclad-source-file "ironclad" "src" "ciphers" "kalyna"> Available restarts: 1. (RETRY) Retry compiling #<ironclad-source-file "ironclad" "src" "ciphers" "kalyna">. 2. (ACCEPT) Continue, treating compiling #<ironclad-source-file "ironclad" "src" "ciphers" "kalyna"> as having been successful. 3. (RETRY) Retry ASDF operation. 4. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 5. (ABORT) Give up on "ironclad" 6. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at ASDF/ACTION:PERFORM. In: #<pr

2 1