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

[ecl 23.9.9][release]
by Daniel Kochmański 09 Sep '23

09 Sep '23

Dear All, we are happy to announce the new release: ECL 23.9.9. You may find details here: https://ecl.common-lisp.dev/posts/ECL-2399-release.html Cheers! 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

1 0

ecl-devel@common-lisp.net
by Gerard ROBIN 18 Aug '23

18 Aug '23

Hello, I am using ecl on my smartphone (android) it works fine but the -q option does not work. How can we make it not verbose? Thanks -- Gerard ____________________________ **************************** Created with Mutt 2.2.9 under Debian Linux BOOKWORM ****************************

1 0

Re: speeding ECL up
by Daniel Kochmański 14 Jul '23

14 Jul '23

Hello Dima, some bottlenecks are known and I'm working on these. The worst offenders: - the generic function dispatch is slow I have implemented the computation part of the fast generic function dispatch as proposed by Robert Strandh, but it needs to be integrated with the C compiler - there is no type inference (only the type propagation) ECL can go really fast when it knows about its types. I have plans for that, but some extra work needs to be done first Both things hang on refactoring the compiler (that task is pending, you may see cmpc-separation branch), so it will be easier to work with the intermediate representation and experiment with backends. There are also other motivations for this refactor. There is also the fact that ECL /compilation/ time is very slow. Currently there is not much we can do about this, because most of the time is spend in GCC (so nothing to optimize for us). Another problem is FASL loading - when ECL loads a fasl then it replays necessary side-effects and that is time consuming (you may notice this for example when you REQUIRE ASDF). This is not much of the problem in itself, but said side-effects need to be replayed even when we build an executable, so the startup suffers. Other implementations hide that startup time by dumping images, where all side effects are already present. Also, if you are not using the C compiler (i.e only the bytecode), then the result is not optimized at all - the bytecodes compiler performs only the minimal compilation. All that said, when both fast gf and type inference are implemented, I will try to identify further bottlenecks if things still doesn't look good. None of these possible improvements will be part of the upcoming release. We are currently in the testing phase (not thanks to me, I'm disappointingly not very active on this front at the moment - sorry Marius!). Here are a few hints that will help you to produce better optimized code: - avoid generic functions - declare types wherever feasible - lower safety to 1, raise speed to 3 (don't use safety 0, there are known bugs) There are also more mundane ways to improve the performance: - inline partial dispatch tables for arithmetic operators - work harder on IR to optimize it (using SSA and adding more passes is pending™) Best regards, Daniel p.s we should also introduce more immediate types on 64bit platforms - we are currently using only two available bits for tagging while we could use three, but I'm not working on that at the moment - single-float could be unboxed in that case -- 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 ------- Original Message ------- On Friday, July 14th, 2023 at 2:19 PM, Dima Pasechnik <dimpase+ecl(a)gmail.com> wrote: > It's well-known that ECL-compiled CL projects are considerably slower > than ones where SBCL is used. Examples are e.g. Maxima, FriCAS - there > speed might be few times (sic!) slower. > > Is there an effort to find out bottlenecks, or is it known where these > bottlenecks are? > > Best, > Dima

3 3

Example in ECL repository for static link
by Thomas Teixeira 20 Jun '23

20 Jun '23

Hi ! Thanks for ECL, I've been learning CL for the past weeks and it's my favorite implementation so far ! Would love to contribute one I've the required skills :)) I'm trying to create a small script that'll allow users to recreate a mail thread inside a virtual maildir box. I would like to use ECL for that script but the project which this script will belong to ([fruitslegumes][1]) is focused on using no dependencies. Because of this constraint, I only ever used POSIX-shell/C99 to build those scripts I would love to use ECL as programs can be compiled down to machine code, which can be `upx`-ed, but users would have to install their ecl package. I managed to statically link libecl with a simple script, but it gets harder for me when trying with the example-with-dep program. I saw in a previous thread of this mailing list that statically linking ECL makes asdf unusable. Is that still the case ? Would it be possible to either provide an example (if what i'm asking is even possible) or talk in more depth about ecl being statically linked ? Regards, Thomas.

2 1

Building ECL as a static library
by J E 19 Jun '23

19 Jun '23

I'm trying to explore building ECL as a static library with the eventual goal of cross compiling the library to run it on a homebrew Nintendo Switch. For starters, I wanted to see if it's possible to run example `embed` by linking ECL built as a static library rather than the system installation. I tried to do this by uninstalling ECL from my system, and then running the following from the git repo: ./configure --disable-shared --prefix=`pwd`/mystaticlib Then built ECL, I copied the headers and lib/libecl.a from the `mystaticlib` folder to the `embed` example directory, and tried modifying the Makefile to link the static library: hello.exe: hello.c hello-lisp.a $(CC) -Iinclude -o $@ hello.c hello-lisp.a \ -Llib -lecl Running the resulting executable gives a lot of undefined references, so I'm not sure if not everything gets built into libecl.a or if it's even possible to do what I'm trying to do. I'm not very proficient with C so sorry if this a dumb question, but any pointers would be greatly appreciated.

2 1

[release candidate][23.x.x]
by Daniel Kochmański 18 Jun '23

18 Jun '23

Dear All, we've decided that it is a good time to go for the new release. The current release candidate is in the develop branch, testing is tracked in this issue: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/706 All help with testing is greatly appreciated. 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

Final Call for Participation - ELS 2023, 16th European Lisp Symoisium
by Didier Verna 06 Apr '23

06 Apr '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium In-Cooperation-With: ACM SIGLAN Call for Participation April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recent News ~~~~~~~~~~~ Registrer now. Early bird discount closing soon! Keynote details now available. Important Dates ~~~~~~~~~~~~~~~ - Final papers due: April 9, 2023 - Early registration deadline: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier 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, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Keynotes ~~~~~~~~ ##### Artificial Intelligence: a Problem of Plumbing? -- Gerald J. Sussman, MIT CSAIL, USA We have made amazing progress in the construction and deployment of systems that do work originally thought to require human-like intelligence. On the symbolic side we have world-champion Chess-playing and Go-playing systems. We have deductive systems and algebraic manipulation systems that exceed the capabilities of human mathematicians. We are now observing the rise of connectionist mechanisms that appear to see and hear pretty well, and chatbots that appear to have some impressive linguistic ability. But there is a serious problem. The mechanisms that can distinguish pictures of cats from pictures of dogs have no idea what a cat or a dog is. The chatbots have no idea what they are talking about. The algebraic systems do not understand anything about the real physical world. And no deontic logic system has any idea about feelings and morality. So what is the problem? We generally do not know how to combine systems so that a system that knows how to solve problems of class A and another system that knows how to solve problems of class B can be combined to solve not just problems of class A or class B but can solve problems that require both skills that are needed for problems of class A and skills that are needed for problems of class B. Perhaps this is partly a problem of plumbing. We do not have linguistic structures that facilitate discovering and building combinations. This is a fundamental challenge for the programming-language community. We need appropriate ideas for abstract plumbing fittings that enable this kind of cooperation among disparate mechanisms. For example, why is the amazingly powerful tree exploration mechanism that is used for games not also available, in the same system, to a deductive engine that is being applied to a social interaction problem? I will attempt to elucidate this problem and perhaps point at avenues of attack that we may work on together. ##### Hedy: Gradual, Multi-Lingual, and Teacher-Centric Programming Education -- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands When kids learn to program they often use either a visual language like Scratch, or a textual language like Python. While visual languages are great for the first steps, children and educators often want to move on to textual languages. However, early on, a textual language and its error messages can be scary. Hedy aims to bridge this gap with a programming language that is gradual, using different language levels. In level 1, there is hardly any syntax at all; printing is done with: print hello! At every level, new syntax and concepts are added, so learners do not have to master everything at once. Hedy builds up to a subset of Python including conditions, loops, variables, and lists. To make learning as accessible as possible, Hedy also allows for the use of localized keywords, f.e in Spanish: imprimir Hello! Hedy (www.hedy.org) was launched in early 2020 and over 5 million Hedy progams have been created to date, and has been translated into 46 languages. ##### A Language-Based Approach to Programming with Serialized Data -- Michael Vollmer, School of Computing, University of Kent, UK It is common for software running today to use object representations fixed by the language runtime system; both the Java and Haskell runtimes dictate an object layout, and the compiler must stick to it for all programs. And yet when humans optimize a program, one of their primary levers on performance is changing data representation. For example, an HPC programmer knows how to pack a regular tree into a byte array for more efficient access. Unfortunately, this is error-prone, making it an undesirable way to achieve performance optimization at the expense of safety and readability. Furthermore, whenever a program receives data from the network or disk, rigid insistence on a particular heap layout causes an impedance mismatch we know as deserialization. Data represented in memory has pointers and arbitrary, sparse layout, while data on disk is packed contiguously, so data must be transformed from one form to another and back. Programming with serialized data is a technique for unifying the in-memory and on-disk representations of data, where the serialized form is used both on-disk and in-memory. This technique allows data processing programs to skip the deserialization/reserialization steps by operating directly on the data in its serialized form. It also represents a principled approach to optimizing programs by compacting data representations, which increases locality and minimizes indirection. In this talk, I will present a programming language, LoCal, for programming with serialized data. I will also describe Gibbon, an experimental compiler that automatically transforms functional programs to operate on serialized data. ##### Run-Time Verification of Communication Protocols in Clojure -- Sung-Shik Jongmans, Open Universiteit, Nederlands To simplify shared-memory concurrent programming, languages have started to offer core support for high-level communications primitives, in the form of message passing though channels, in addition to lower-level synchronization primitives. Yet, a growing body of evidence suggests that channel-based programming abstractions also have their issues. The Discourje project aims to help programmers cope with channels and concurrency bugs in Clojure programs, based on dynamic analysis. The idea is that programmers write not only implementations of communication protocols in their Clojure programs, but also specifications. Discourje then offers a run-time verification library to ensure that channel actions in implementations are safe relative to specifications. Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Mark Evenson, not.org, Austria Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Germany Robert Smith, HRL Laboratories Mattias Engdegård Marc Feeley, Université de Montréal, Canada Marc Battyani, FractalConcept Alan Ruttenberg, National Center for Ontological Research, USA Nick Levine, RavenPack, Spain Ludovic Courtès, Inria, France Matthew Flatt, University of Utah, USA Irène Durand, Université Bordeaux 1, France Jay McCarthy, Brigham Young University, USA Ambrose Bonnaire-Sergeant, Cisco Christopher League, Long Island University, NY, USA Pascal Costanza, Intel, Belgium Christian Queinnec Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

(log #c(0 1) #c(0 -1)) errors
by James Cloos 25 Mar '23

25 Mar '23

With 21.2.1 I get: >> (log #c(0 1) #c(0 -1)) Debugger received error of type: DIVISION-BY-ZERO #<a DIVISION-BY-ZERO 0x7f8925037640> Error flushed. gcl, sbcl and ccl all return #C(-1.0 0.0). other non-lisp software agrees. i haven't yet tried master. -JimC -- James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

4 6

Differences Between ECL Executable and Embedded ECL
by Binh Nguyen 24 Mar '23

24 Mar '23

Dear ECL Community, Could you let me know how to do the following, please? - How to load file "quicklisp.lisp" in an embedded instance of ECL - How to make the function REQUIRE available in an embedded instance of ECL - How to load ASDF 3 or newer in an embedded instance of ECL I am able to load file "quicklisp.lisp" when I run "/usr/local/ecl.exe". I saw that there is an "ecl-quicklisp.lisp" but I'd like to learn how to load non-ECL Quicklisp. I am running ECL 21.2.1. that I compiled with MSYS MinGW x86. The first error that comes up is that the function REQUIRE is not available. > (load "quicklisp.lisp") > ;;; Loading "C:/msys64/home/Admin/quicklisp.lisp" Debugger received error of type: SIMPLE-ERROR Module error: Don't know how to REQUIRE SOCKETS. Error flushed. So I manually loaded SOCKETS. > (load #P"C:/msys64/usr/local/sockets.fas") > ;;; Loading "C:/msys64/usr/local/sockets.fas" #P"C:/msys64/usr/local/sockets.fas" Then I tried again and I was able to progress further. > (load "quicklisp.lisp") > ;;; Loading "C:/msys64/home/Admin/quicklisp.lisp" > ==== quicklisp quickstart 2015-01-28 loaded ==== > To continue with installation, evaluate: (quicklisp-quickstart:install) > For installation options, evaluate: (quicklisp-quickstart:help) > #P"C:/msys64/home/Admin/quicklisp.lisp" > (quicklisp-quickstart:install) > Debugger received error of type: SIMPLE-ERROR Quicklisp has already been installed. Load > #P"C:/msys64/home/Admin/quicklisp/setup.lisp" instead. Error flushed. Bu the following error appeared that I don't know how to solve. > (load #P"C:/msys64/home/Admin/quicklisp/setup.lisp") > ;;; Loading "C:/msys64/home/Admin/quicklisp/setup.lisp" Debugger received error of type: SIMPLE-ERROR Could not load ASDF "3.0" or newer Error flushed. I tried loading the other ".fas" files in "/usr/local" such as "asdf.fas" but that did not help. I checked the *features* variable in both versions but they were the same. $ ./a.exe ... Condition of type: INTERACTIVE-INTERRUPT Console interrupt. Available restarts: > 1. (CONTINUE) CONTINUE ... > (print-list *features*) > (WALKER > ECL-BYTECMP CDR-1 CDR-5 FORMATTER CDR-7 WSOCK ECL-WEAK-HASH LITTLE-ENDIAN LONG-LONG UINT64-T UINT32-T UINT16-T COMPLEX-FLOAT LONG-FLOAT UNICODE DFFI CLOS-STREAMS CMU-FORMAT WINDOWS WIN32 MINGW32 ECL-PDE DLOPEN CLOS THREADS BOEHM-GC ANSI-CL COMMON-LISP IEEE-FLOATING-POINT PACKAGE-LOCAL-NICKNAMES CDR-14 PREFIXED-API FFI I686 COMMON ECL) > $ /usr/local/ecl.exe > ... > > (print-list *features*) > (WALKER ECL-BYTECMP CDR-1 CDR-5 FORMATTER CDR-7 WSOCK ECL-WEAK-HASH > LITTLE-ENDIAN LONG-LONG UINT64-T UINT32-T UINT16-T COMPLEX-FLOAT > LONG-FLOAT UNICODE DFFI CLOS-STREAMS CMU-FORMAT WINDOWS WIN32 MINGW32 > ECL-PDE DLOPEN CLOS THREADS BOEHM-GC ANSI-CL COMMON-LISP > IEEE-FLOATING-POINT PACKAGE-LOCAL-NICKNAMES CDR-14 PREFIXED-API FFI I686 > COMMON ECL) > Best regards, Binh Nguyen

2 4

[CfPart] 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 09 Mar '23

09 Mar '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium In-Cooperation-With: ACM SIGLAN Call for Participation April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recent News ~~~~~~~~~~~ Registrations are now open (early bird deadline: April 9) Keynote speakers announced (see below) Important Dates ~~~~~~~~~~~~~~~ - Author notification: March 26, 2023 - Final papers due: April 9, 2023 - Early registration deadline: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier 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, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Keynotes ~~~~~~~~ ##### Artificial Intelligence: a Problem of Plumbing? -- Gerald J. Sussman, MIT CSAIL, USA We have made amazing progress in the construction and deployment of systems that do work originally thought to require human-like intelligence. On the symbolic side we have world-champion Chess-playing and Go-playing systems. We have deductive systems and algebraic manipulation systems that exceed the capabilities of human mathematicians. We are now observing the rise of connectionist mechanisms that appear to see and hear pretty well, and chatbots that appear to have some impressive linguistic ability. But there is a serious problem. The mechanisms that can distinguish pictures of cats from pictures of dogs have no idea what a cat or a dog is. The chatbots have no idea what they are talking about. The algebraic systems do not understand anything about the real physical world. And no deontic logic system has any idea about feelings and morality. So what is the problem? We generally do not know how to combine systems so that a system that knows how to solve problems of class A and another system that knows how to solve problems of class B can be combined to solve not just problems of class A or class B but can solve problems that require both skills that are needed for problems of class A and skills that are needed for problems of class B. Perhaps this is partly a problem of plumbing. We do not have linguistic structures that facilitate discovering and building combinations. This is a fundamental challenge for the programming-language community. We need appropriate ideas for abstract plumbing fittings that enable this kind of cooperation among disparate mechanisms. For example, why is the amazingly powerful tree exploration mechanism that is used for games not also available, in the same system, to a deductive engine that is being applied to a social interaction problem? I will attempt to elucidate this problem and perhaps point at avenues of attack that we may work on together. ##### Gradual, Multi-Lingual, and Teacher-Centric Programming Education -- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands (tba) Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Mark Evenson, not.org, Austria Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Germany Robert Smith, HRL Laboratories Mattias Engdegård Marc Feeley, Université de Montréal, Canada Marc Battyani, FractalConcept Alan Ruttenberg, National Center for Ontological Research, USA Nick Levine, Ravenbrook Ltd, UK Ludovic Courtès, Inria, France Matthew Flatt, University of Utah, USA Irène Durand, Université Bordeaux 1, France Jay McCarthy, Brigham Young University, USA Ambrose Bonnaire-Sergeant, Cisco Christopher League, Long Island University, NY, USA Pascal Costanza, Intel, Belgium Christian Queinnec Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0