Embeddable Common-Lisp https://common-lisp.net/project/ecl en-us Tue, 05 May 2026 09:34:02 +0000 ECL 26.5.5 release https://common-lisp.net/project/ecl/posts/ECL-2655-release.html 2026-05-05 12:00 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-2655-release.html We are announcing a bugfix ECL release that addresses a few issues that has slipped through testing of the recent one.

Addressed issues:

  • bugfix: MAKE-PACKAGE destructively modified defining form's cons cells of the package local nicknames, breaking package literals in bytecmp (#839)

  • bugfix: the first environment is now always page-aligned by using the same allocation mechanism as all subsequent envs (#828)

  • bugfix: allow loading concatenated fasc files (#842)

  • bugfix: defclass does not redefine existing classes at compile time with forward-referenced classes in the bytecodes compiler (#843)

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Happy Hacking,
The ECL Developers

]]> ECL 26.3.27 release https://common-lisp.net/project/ecl/posts/ECL-26327-release.html 2026-03-27 10:00 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-26327-release.html We are announcing a new stable ECL release. This release highlights:

  • bytecodes closures are now faster and avoid capturing unused parts of the lexical environment
  • improvements to the native compiler, including better separation between compiler frontend and backend, reduced function call overhead, more aggressive dead code elimination and many internal improvements and bug fixes
  • hash table implementation improvements and bug fixes for collisions
  • streams: extensions EXT:PEEK-BYTE, EXT:UNREAD-BYTE, GRAY:STREAM-PEEK-BYTE and GRAY:STREAM-UNREAD-BYTE, bugfixes and implementation refactor
  • the codebase has been updated to conform to the C23 standard
  • simplified procedure for cross-compiling ECL itself
  • support for cross-compilation of Common Lisp code to different targets using a new :TARGET option for COMPILE-FILE
  • some fixes for the emscripten target

The release also incorporates many other bug fixes and performance improvements as well as an updated manual. We'd like to thank all people who contributed to ECL with code, testing, issue reports and otherwise.

People listed here contributed code in this iteration: Daniel Kochmański, Marius Gerbershagen, Tarn W. Burton, Kirill A. Korinsky, Dmitry Solomennikov, Kevin Zheng, Mark Shroyer and Sebastien Marie.

People listed here did extensive release candidate testing on various platforms: Marius Gerbershagen, Daniel Kochmański, Dima Pasechnik, Matthias Köppe, Jeremy List, Mark Damon Hughes and Paul Ruetz.

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Finally, a note on the release schedule: ECL releases often take some time to come out, partially because we do extensive testing against supported platforms and existing libraries to find regressions. In the meantime all improvements are incrementally incorporated in the branch develop. It is considered stable and it is tested and reviewed with necessary dilligence. If release cycle is too slow for your needs, then we suggest following the branch develop for the most recent changes.

Happy Hacking,
The ECL Developers

]]> Web ECL Grant Announcement https://common-lisp.net/project/ecl/posts/Web-ECL-Grant-Announcement.html 2025-07-29 13:30 Daniel Kochmański https://common-lisp.net/project/ecl/posts/Web-ECL-Grant-Announcement.html Dear Community,

I'm happy to share that I've received a grant from NLnet to work on improving the WebAssembly integration and ECL.

The project has four milestones that are expected to be finished within a year:

  1. Implement a protocol for interoperation with the web environment (DOM)
  2. Integrate a set of tools to develop Common Lisp code directly in a browser
  3. Port ECL to the Web Assembly System Interface (WASI)
  4. Implement a virtual filesystem extension for ECL

As you might have noticed, the first two milestones focus on using ECL in the browser setting. Progress of this part of the project may be tracked in a separate repository. I've already begun work on this, and the repository will now see much more activity.

After the first milestone it should be possible (and hopefully convenient) to directly incorporate Common Lisp scripts on websites that allow controlling DOM elements and implementing the application logic. I plan to design the protocol after CLIM II to make it easier to port McCLIM to this platform in the future.

The second milestone is related to developing a set of reusable components like a listener, a debugger and a code editor, and integrate them into a sample development environment for Common Lisp.

The next two steps will be far more involved with ECL internals and will benefit all platforms. Porting to WASI will improve ECL's portability and reduce its dependency on libc. I also hope to include my recent work on green threads in this step. A virtual filesystem will enable us to store entire systems in memory and work on files even when the host lacks a filesystem.

Some goals may change during development, but this is a general outline of the direction. If you have some questions (or suggestions), please write to our mailing list, or contact me directly.

Best regards,
Daniel

Funding

This project is funded through NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.

NLnet foundation logo NGI Zero Logo

]]> ECL 24.5.10 release https://common-lisp.net/project/ecl/posts/ECL-24510-release.html 2024-05-10 13:30 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-24510-release.html Dear Community,

We are announcing a new stable ECL release. The release mainly includes a number of bug fixes, including changes that prevent rare crashes in the garbage collector on Mac OS X, some bug fixes for gray streams and for pathname related functionality. Moreover, the release features new extensions for gray streams (gray:stream-line-length, gray:stream-file-length, gray:stream-file-string-length and generic versions of cl:pathname and cl:truename) as well as improved emscripten support (allowing shared library builds) and small improvements to the manual.

We'd like to thank all people who contributed to ECL with code, testing, issue reports and otherwise.

People listed here contributed code in this iteration: Daniel Kochmański, Kirill A. Korinsky, Marius Gerbershagen, Tarn W. Burton, Mark Shroyer, Dmitry Solomennikov, Kevin Zheng.

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Happy Hacking,
The ECL Developers

]]> ECL 23.9.9 release https://common-lisp.net/project/ecl/posts/ECL-2399-release.html 2023-09-09 08:00 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-2399-release.html Dear Community,

We are happy to announce a new stable ECL release tagged 23.9.9. The new release includes many bug fixes, some new features, improvements to the compiler and more. Changes include but are not limited to:

  • Complete overhaul of thread synchronization primitives (mutexes, condition variables, etc.). Users of bordeaux-threads will have to update as this breaks workarounds for missing timeouts on condition variable wait operations in version 0.9.1 and earlier of this library.
  • Better unicode support: add new functions to convert between Lisp strings and byte arrays in different encodings, allow non-ascii characters in pathnames and as arguments to ext:run-program.
  • Preliminary support for the Emscripten target (bytecodes compiler only).
  • Various bug fixes and internal improvements to the compiler.
  • Better conformance to the ANSI standard.

We'd like to thank all people who contributed to ECL with code, testing, issue reports and otherwise.

People listed here contributed code in this iteration: Caleb Xu, Catherine Tower, Daniel Kochmański, Dima Pasechnik, Dmitry Solomennikov, Eric Timmons, Florian Margaine, Jeronimo Pellegrini, Kevin Zheng, Kirill A. Korinsky, Marius Gerbershagen, Nick Faro, Tarn W. Burton, Ulrich Müller, Yuguo Zhang, Yuri D. Lensky.

People listed here tested ECL extensively before the release: Kirill A. Korinsky, Marius Gerbershagen and Paul Ruetz.

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Happy Hacking,
The ECL Developers

]]> ECL 21.2.1 release https://common-lisp.net/project/ecl/posts/ECL-2121-release.html 2021-02-01 14:21 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-2121-release.html Dear Community,

We are announcing a new stable ECL release which fixes a number of bugs from the previous release. Changes made include amongst others

  • working generational and precise garbage collector modes
  • support for using precompiled headers to improve compilation speed
  • the bytecompiler correctly implements the ANSI specification for load time forms of literal objects in compiled files
  • fixes for encoding issues when reading in the output of the MSVC compiler
  • issues preventing ECL from compiling on Xcode 12 and running on ARM64 versions of Mac OS have been rectified

More detailed information can be obtained from the CHANGELOG file and git commit logs. We'd like to thank all people who contributed to this release. Some of them are listed here (without any particular order): Paul Ruetz, Karsten Poeck, Eric Timmons, Vladimir Sedach, Dima Pasechnik, Matthias Köppe, Yuri Lensky, Tobias Hansen, Pritam Baral, Marius Gerbershagen and Daniel Kochmański.

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Happy Hacking,
The ECL Developers

]]> ECL 20.4.24 release https://common-lisp.net/project/ecl/posts/ECL-20424-release.html 2020-04-24 12:00 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-20424-release.html Dear Community,

After more than three years of development, we are proud to announce a new ECL release having the version tag 20.4.24. During that time many important improvements have been made including bug fixes, stability enhancements and new features. Changes include but are not limited to:

  • package local nicknames support
  • atomic operations support
  • specialized representations of complex float types
  • a port to the iOS platform
  • fixes for weak hash tables and weak pointers
  • fixes for race conditions in the ECL internals
  • hash table extensions (synchronization and custom test functions)
  • better MOP conformance and improved meta-stability
  • improvements to the manual

For more information please read the file CHANGELOG which is located in the source code, and browse commits. We'd like to thank all people who made this release possible by contributions of code, documentation, issue reports, testing and others. Some of them are listed here (without any particular order): Paul Ruetz, Karsten Poeck, Vadim Penzin, Roger Sen, Stas Boukarev, Michael Fox, Erik Bray, Bo Yao, Jeremy Cooper, Florian Margaine, Fabrizio Fabbri, Tomek Kurcz, Kris Katterjohn, Marcin Kolenda, Zhang Yuguo, Sébastien Villemot, Moritz Petersen, Marius Gerbershagen and Daniel Kochmański. We'd also like to thank the company Rigetti Computing for sponsoring the work on specialized complex float representations.

We have another important announcement we'd like to make. Embeddable Common-Lisp project has now two maintainers: Daniel Kochmański and Marius Gerbershagen. After numerous contributions from Marius I've proposed him this responsibility and to my rejoice he has accepted it. That reflects our community growth.

This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):

Happy Hacking,
The ECL Developers

]]> ECL license https://common-lisp.net/project/ecl/posts/ECL-license.html 2017-12-15 13:30 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-license.html From time to time a little misconception emerges regarding the ECL license - namely some people seem to have the impression that it is GPL-2.0, while in fact it is LGPL-2.1+. In this post I want to talk a little about the history of ECL and to describe what the practical implications of such licensing are.

The heritage of Embeddable Common Lisp is rich, as you can read here. The software has had a few maintainers throughout its history who hold copyrights to various parts of the code. ECL was licensed under GPL-2.0, but that license was changed after ECLS (or ECL-Spain) and ECoLisp were once again one project and Prof. Juanjo García-Ripoll changed the license to LGPL-2.1+ with agreement of Prof. Giuseppe Attardi. That's the point from which I took over in 2015 with blessing from the previous maintainer. I do not own all copyrights to the software and I can't change its license to anything that is incompatible with working in LGPL-2.1+. Note that parts of the codebase are licensed more liberally (like programs in the examples directory which may be used for any purpose and are licensed under the terms of BSD-2-Clause).

That said, I feel very comfortable with current licensing. It preserves a reasonable balance between producent and consumer rights and fits project goals perfectly. The meaning of our current license is, in short, the following: you can use ECL for any purpose in any setting (including commercial applications), but if you commit changes to ECL itself you are obliged to share these changes (and only them).

The core library is a shared object libecl.so and it is dynamically linked with the software. The binary called ecl is just a program which is a client of this library. Moreover, ECL compilation artifacts are usually shared objects themself (usually disguised under the fas extension):

➜  ~ ldd `which ecl`
    linux-vdso.so.1 =>  (0x00007ffff80c3000)
    libecl.so.16.1 => /home/jack/Pulpit/lisps/ecl-16.1.3/lib/libecl.so.16.1 (0x00007fc7c4665000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7c427a000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc7c3ffa000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fc7c3df2000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7c3bd4000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc7c39ce000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc7c36c5000)
    /lib64/ld-linux-x86-64.so.2 (0x00005592f1735000)
➜  ~ cd .cache/common-lisp/ecl-16.1.3-21f0b92f-linux-x64/home/jack/Pulpit/repo/mcclim/Apps/Listener
➜  Listener ls listener*
listener.fas listener.o
➜  Listener ldd listener.fas 
    linux-vdso.so.1 =>  (0x00007fffb43f5000)
    libecl.so.16.1 => /home/jack/Pulpit/lisps/ecl-develop/lib/libecl.so.16.1 (0x00007fa2bbfc1000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2bbbd6000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fa2bb956000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fa2bb74e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa2bb530000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa2bb32a000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa2bb021000)
    /lib64/ld-linux-x86-64.so.2 (0x0000563db6716000)
➜  Listener file listener.fas 
listener.fas: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ed1cece88028eb3a388ab0a589a9ee12415532e9, not stripped

There are a few implications of this. First, I will explain (informally) what LLGPL clarification to LGPL is. Many Common Lisp implementations don't work with the notion of linking, so "static linking" and "dynamic linking" doesn't make much sense in them. Libraries are simply added to the image. That may raise questions whenever a binary with an LGPL library in it may be considered derivative work or not? My strong belief lies on the side that it is not derived work and if the author of the Lisp library gave it the LGPL license – they meant it. If we take another interpretation, then it is no different than licensing it with GPL, so it would be nonsense. I think that what is tested in court is intention and there is no rational interpretation of giving a Lisp library the LGPL license except the one that the software does not influence other image components. LLGPL additionally clarifies some wording to make it less ambiguous and clear up unnecessary doubts.

The point above is reinforced by the fact, that the Free Software Foundation itself made a clarification about dynamic linking in the context of Java programming language, but equally applicable to Common Lisp, and it addresses both the "linking" and the "inheritance" problem. But are macro expansions derivative work? The compiler output is not the subject of the compiler license and macros should not be much different with this regards.

All that said, ECL is safe from concerns like that and such clarification is not necessary because it works with the very same notion LGPL talks about (static and dynamic linking). There is no program image, only objects which a binary is composed of and linked with (exactly like in C programs).

Another interesting license (with which ECL is compatible with thanks to "or later version" clause) is LGPL-3.0. This license is for example used by ECL's fork named MKCL and GMP since version 6. In short, this license adds an important restriction to LGPL-2.1+ called the anti-tivoization provision. This privision adds a new freedom for software users – they must have the ability to update the library on a device with software under this license to their own version of it. This effectively means that the device can't be a complete black box.

This leads us to another topic. ECL is licensed under LGPL-2.1+ license and it is linked with GMP. As we have noted in the paragraph above, the newest version of GMP is licensed under LGPL-3.0. In practice this means that if you use ECL and GMP in your application and any of them is LGPL-3.0 you can't put such a bundle on a camera device which doesn't allow changing its software. To prevent such situation ECL has bundled its own version of GMP, which is a slightly modified version of GMP version 4, which was licensed under the LGPL-2.1+ terms. By default, when building it tries to link against libgmp.so on your system, but given appropriate configure flags it may use the bundled GMP version and link it statically into libecl.so (ECL doesn't export symbols from libeclgmp.a to avoid symbol name conflicts with the original libgmp.so).

I think that summarises it. Now I will provide some made up FAQ to illustrate licensing implications in shorter form:

Q: Is ECL GPL-2.0?
A: No, ECL is LGPL-2.1+.

Q: Can you provide a commercial license for us?
A: No, I don't own all the copyrights.

Q: Can we use ECL in our commercial product with proprietary components?
A: Yes, but you have to keep ECL linked dynamically with them (as a shared object).

Q: Can you incorporate proprietary components in ECL?
A: God no (and I wouldn't do that even if I could).

Q: Can we use ECL in our LGPL/GPL/AGPL product?
A: Yes, you can even link ECL statically for that purpose. Your license will be intact.

Q: Can you incorporate LGPL/GPL/AGPL components in ECL?
A: If you incorporate LGPL-2.1+, then ECL remains in LGPL-2.1+ and it can be integrated in the upstream; but if you incorporate LGPL-3.0, GPL or AGPL, then your fork of ECL will become LGPL-3.0, GPL or AGPL and it won't be integrated upstream.

Q: Can we use ECL in our BSD/MIT/Apache-2.0 product?
A: Yes. If it is dynamically linked there are no further implications. If you link it statically, the overall license is LGPL-2.1+.

Q: Can you incorporate BSD/MIT/Apache-2.0 components in ECL?
A: Yes, sometimes I do that.

Q: If I compile my software with ECL is it LGPL-2.1+?
A: No, products of compilation are not influcenced by compiler license. You may compile any kind of free and proprietary software with ECL without any implications on the compilation artifacts or the code it compiles. I would appreciate not using it for something unethical though.

Q: Can I put ECL in an embedded device to which the consumer doesn't have access to?
A: Yes. You may need to build ECL with bundled GMP library to avoid LGPL-3.0 implications.

Q: If I use two libraries in my application - one being LGPL and the other MIT – what is my program license?
A: That depends. If you link them statically (monolithic programs), then resulting work will be covered at least with LGPL (you may add more restrictions if you want). If you link them dynamically (default), then you may use any license you want.

Q: If I use GPL libraries in my application – what is my program license?
A: Its license is at least GPL.

Q: Are you a lawyer?
A: Nope. You may want to consult one. But hey, you should also consult a lawyer regarding the terms of services you probably agree on surfing the web and EULAs bundled with your favourite software and hardware (i.e phone).

Q: Did you cover all LGPL-2.1+ implications?
A: No, I recommend reading the license. I have talked about things which I find relevant to this post.

Q: Can I buy something from you?
A: Yes, you may buy developer time to work on ECL or to help integrate ECL with your application. I'll probably do it anyway if you drop by on the IRC channel.

If you have more questions you may ask on the mailing list and IRC (channel #ecl on libera.chat).

Thank you for reading,
Daniel Kochmański

--

  • I want to thank Elias Mårtenson, Pascal Bourguignon and Tomek Kurcz for proofreading this text and for providing valuable remarks before publishing it on the blog.

  • In this post I've used SPDX-License-Identifier format where appropriate.

]]> Lisp (ECL) and QML (Qt5) on Android? https://common-lisp.net/project/ecl/posts/Lisp-ECL-and-QML-Qt5-on-Android.html 2017-07-15 12:00 Daniel Kochmański https://common-lisp.net/project/ecl/posts/Lisp-ECL-and-QML-Qt5-on-Android.html -->
(please note that I'm assuming a Linux/64 bit platform or VirtualBox image)

Preamble: about a month ago, I was completely void of any android experience.
This is to say: using both QML (which is easy to learn) and Common Lisp (which I assume you already know) to develop android apps is not a difficult task at all, as you'll see.

So, if you are like me just a month ago, there are no excuses not to write your own, first android app using this new "EQL5-Android" project!

We will build a small game (Sokoban), which uses Lisp for the program logic, and QML for the UI, and build an APK for the android platform.

Being the author of that very first attempt of integrating Lisp and Qt4 (see lisp-cffi-qt4), what I would like to accomplish is providing you with a ca. 3 MB download, which can be tried out instantly.

10 years ago, the lisp-cffi-qt4.zip (a runnable win32 binary version), was a 3 MB download, including both ECL and Qt4 (UPX compressed, but still).
10 years later, this time on android, what download size is to be expected?
We will see...

Since all the documentation needed for preparing the development environment is already covered in the "EQL5-Android" project itself, I will give only the link here:

README-PREPARE.txt

So, I'm assuming that you already have everything installed and set up (Qt 5.7.1, Android NDK 10e, Android SDK, Java JDK, and obviously the EQL5-Android sources from gitlab), in order to build android packages (APK files).

(EQL5 itself, the desktop version, is not strictly needed to follow this example; but for developing your own apps, you will obviously need it; even here it's very helpful for testing and debugging, if something doesn't work as expected.)

If you already know the process of building EQL5 apps for the desktop, you will find that building (cross-compiling) to android is very similar, with only a few more steps involved.

Since we use an example of EQL5-Android itself, everything has already been set up. But I want to remember the steps that are not obvious, if you are not familiar with Qt and EQL:

  • you need to add all your external resources, like QML files, PNG files etc. to a Qt resource file (ending .qrc); this will integrate them (compressed) directly into the executable
  • you need to add all your Lisp files, in exact order of loading, to make.lisp (in a future version of EQL5, I will try to integrate this step with ASDF)

And that's it, basically (except the app name, which needs to be adapted to the *.qrc file name, to your *.pro file name and contents (see TARGET and RESOURCES), and to the contents of the third script 3-build-apk.sh (see *.json file name).

Everything else will stay the same for every project.

Now I want to call your attention on the huge advantage of using Qt for your android apps: you can first build a desktop exe, with the exact same sources, and try/debug it. If the desktop version works, the android app will generally work too (the only things that may need adaption are e.g. font sizes and similar).

So, let's get practical! In the EQL5-Android sources, switch to 'examples/sokoban/'.

Building a desktop exe would be this 3 liner:


  $ eql5 make-desktop.lisp
  $ qmake sokoban_desktop.pro
  $ make

(To test if all resources have really been included in the sokoban_desktop executable, you need to move it to a different directory, and launch it from there.)

Here's a screenshot of our app running on the desktop:

But now let's do the cross-compile dance!

First let's copy the needed shared libraries to the 'android-build/' directory.
Just run script number 1:


  $ ./1-copy-libs.sh

This step needs only be done once for every new project. It will copy the cross-compiled ECL and EQL5 libs into our android build directory.

The next steps are very similar to a desktop build:


  $ ecl-android -shell make.lisp
  $ qmake-android sokoban.pro
  $ make

Since cross-compiling requires a special "host ECL", which needs to match the target platform (that is, 32 bit, no double floats), we would be in trouble with cross-compiling EQL5 code: we certainly don't want a seperate EQL5 32 bit version, only for cross-compiling...

But there is a solution to this (see 'utils/EQL5-symbols.lisp' in sources): for cross-compiling -- which is the job of our "host ECL" -- we pretend to be the eql5 executable, by defining all packages and symbols, defining all EQL5 macros (otherwise we can't compile), and simply defining dummy-functions for all EQL5 functions, so the compiler will not complain.

So, loading 'utils/EQL5-symbols.lisp' in our host ECL will be sufficient for cross-compiling EQL5 code.

If you are interested in how the cross-compile environment is set up, please see:

utils/cross-compile.lisp

(thanks to Sylvain Ageneau, who wrote the original version; this is a simplified version not depending on ASDF; the latter will be integrated in a future version)

So, the above 3 liner will build the shared library of our app, ready to be included in the android build. To copy it where the android build expects it, use script number 2:


  $ ./2-install-lib.sh

The last step, which will build our APK file, is a verbose one (for eventual debugging), and a little time consuming: it will create the whole package structure, and compile the whole thing into an APK file, ready to be installed on an android device.

There is this great tool (courtesy Qt) called androiddeployqt, which automates the whole and complex process of creating an APK file, with all the needed options already set in our 3rd script:


  $ ./3-build-apk.sh

Here the contents of the above script, where you can see all the selected options:


  $ ~/Qt5.7.1/5.7/android_armv7/bin/androiddeployqt \
        --input android-libsokoban.so-deployment-settings.json \
        --output android-build \
        --deployment ministro \
        --gradle \
        --verbose

If it will tell you BUILD SUCCESSFUL, then you'll find the APK file (ready for deployment) in 'android-build/build/outputs/apk/'.

The last step is copying over the APK file to your android device, and install / run it. Normally you're not allowed to do this, because it requires special developer settings (please search the web for instructions how to enable them, as they are different for every android version).

After connecting via USB and copying the APK file over to your device, just tap it from there. This will ask for installing, and then for opening the app.

Here's a screenshot of the sokoban app running on a tablet:

Above you see the splash screen, because startup will take a few seconds.

Below the game:

After seeing the result, I'd like to consider a few QML and Lisp snippets.

QML is easy to learn. You just need to declare what you want (and it will do the how behind the scenes).
Let's see this snippet for defining and placing our arrow buttons:


  // container for arrow buttons
  Item {
      id: arrows
      width: up.width * 3
      height: up.height * 3
      anchors.margins: 10
      anchors.right: parent.right
      anchors.verticalCenter: parent.verticalCenter

      Ext.Button {
          id: up
          objectName: "up"
          source: "img/up.png"
          anchors.horizontalCenter: parent.horizontalCenter
      }

      Ext.Button {
          objectName: "left"
          source: "img/left.png"
          anchors.verticalCenter: parent.verticalCenter
      }

      Ext.Button {
          objectName: "right"
          source: "img/right.png"
          anchors.verticalCenter: parent.verticalCenter
          anchors.right: parent.right
      }

      Ext.Button {
          objectName: "down"
          source: "img/down.png"
          anchors.horizontalCenter: parent.horizontalCenter
          anchors.bottom: parent.bottom
      }
  }

So, we define an Item as container for the buttons, giving it the width (up.width * 3) and height (up.height * 3), according to the button sizes: this may be any calculation or function call, and may refer to any item of the file, referred to by its id.

For placing the container itself, and the single arrow buttons, we just need to define anchors, which can be relative to other items (here: the parent item).

The Ext.Button is a user defined item class, which can be found in 'qml/ext/Button.qml. That is, the whole directory 'ext/' is imported as Ext:


  import "ext/" as Ext

This means that every file in 'ext/' is now a new QML class, which can be referred to via Ext (like a namespace).

The definition of our image button class (see 'qml/ext/Button.qml') is:


  import QtQuick 2.0

  Image {
      signal pressed()

      MouseArea {
          anchors.fill: parent
          onPressed: { parent.pressed() }
      }
  }

So, we don't need a real button, but only a clickable image: adding a mouse area will allow us to capture mouse events; this event is then passed to the parent (that is, the Image class), where a Qt signal will be emitted: this will allow us to connect to it from Lisp:


  (defun connect ()
    (macrolet ((pressed (item function)
                 `(qconnect (find-quick-item ,item) "pressed()"
                            (lambda () ,function))))
      (pressed "up"       (sokoban:move :north *maze*))
      (pressed "down"     (sokoban:move :south *maze*))
      (pressed "left"     (sokoban:move :west *maze*))
      (pressed "right"    (sokoban:move :east *maze*))
      (pressed "previous" (change-level :previous))
      (pressed "next"     (change-level :next))
      (pressed "undo"     (undo))
      (pressed "restart"  (reset-maze))
      (pressed "solve"    (solve))))

If you already played the game finishing a level, you will have noticed that there are 2 animations (rotation of the player, wiggling of all boxes) which run queued.
This is a little tricky to do, but with the help of a Lisp macro, we only need these lines in Lisp (being queued a macro):


  (defun final-animation ()
    (queued (qml-set "rotate_player" "running" t)
            (qml-set-all "wiggle_box" "running" t)))

Please see the sources for all the details. And this would not be possible without a Lisp function called from QML for notifying us whenever an animation state changes, see 'qml/ext/RotationAnimation.qml':


  import QtQuick 2.0
  import EQL5 1.0

  RotationAnimation {
      onRunningChanged: Lisp.call("qsoko:animation-change", running)
  }

What I left out to explain is the dynamic (at run time) creation of QML items (see 'qml/items/*' and 'lisp/sokoban.lisp'); let's just say that this is left as an exercise to the reader, as all sources will patiently stay there to be read...

Well. But I still didn't answer the initial question: how big of a download is to be expected, 10 years later?

Since our APK file uses the ministro service for automatically installing the needed Qt libraries at the first launch of the app, it will only need to include both the ECL and EQL5 libraries (you can therefore use different ECL and EQL5 versions for every app you deploy).

So, to finally answer the question: our download will be ca. 3.5 MB (instead of 3 MB, 10 years ago, although we obviously compare apples and oranges here).

Seems acceptable.

And since I promised you to test it instantly (if you own a device with ARM processor), here you are:

sokoban.apk

Enjoy!

 

 

 

]]> ECL 16.1.3 release https://common-lisp.net/project/ecl/posts/ECL-1613-release.html 2016-12-19 11:30 Daniel Kochmański https://common-lisp.net/project/ecl/posts/ECL-1613-release.html Announcement

Dear Community,

After almost a year of development we are proud to present a new release of ECL tagged with version 16.1.3. All changes are backward compatible fixing bugs and other issues, implementing new interfaces and cleaning up the code base.

ECL manual has been updated in a few places. Work on a new documentation is still pending. New documentation is still incomplete, but you may see it here: https://common-lisp.net/project/ecl/static/ecldoc/.

Before this release we have performed extensive tests on many platforms (Linux, FreeBSD, OpenBSD, NetBSD, OSX, Windows MSVC, Windows MinGW, Windows Cygwin, Android and Haiku). For details please consult https://gitlab.com/embeddable-common-lisp/ecl/issues/307. Extra attention has been paid to Windows testing to improve that platform support.

This release is available for download in form of a source archive:

Best regards,
ECL Development Team

API changes

  • Added better interface for package-locks.

    Introduced functions:

    ext:package-locked-p package
ext:lock-package package
ext:unlock-package package
ext:without-package-locks &body body
ext:with-unlocked-packages (&rest packages) &body body

    To use these functions user has to require the module

    (require '#:package-locks)

    defpackage accepts new option lock to allow locking package on creation:

    (defpackage foo (:lock t))

  • mp:holding-lock-p: introduce new function for multiprocessing. Function verifies if lock is hold by the thread which calls the function. Usage: (mp:holding-lock-p my-lock).

  • make-random-state: fix problem with simple-vectors. The correct initialization types for make-random-state are: (OR RANDOM-STATE FIXNUM (MEMBER T NIL)).

    Initializing a random state with an appropriate array (element type and arity dependent on platform) is also possible.

  • ext:random-state-array: new extension for random-states. Usage: (ext:random-state-array random-state).

  • ext:terminate-process: new extension for external processes. Usage: (ext:terminate-process process) with a second, optional boolean argument whenever termination should be forced or not.

Enhancements

  • Implemented CDR-7. https://common-lisp.net/project/cdr/document/7/index.html

  • implemented CDRs: CDR-1, CDR-5, CDR-14. Both CDR-1 and CDR-5 were already implemented, CDR-14 made us to list them in *features* (https://common-lisp.net/project/cdr/document/14/index.html).

  • if ECL is build with --with-cxx option, :CXX-CORE is present in *features*.

  • deprecated configure option --with-local-gmp has been removed - use --enable-gmp (defaults to auto).

  • configure options has been revised.

  • ASDF has been upgraded to version 3.1.7.26 (with a few patches scheduled for 3.2.0).

  • bundled CLX has been purged. Lately I've fixed ECL support on portable CLX maintained by sharplispers on https://github.com/sharplispers/clx (available via QuickLisp).

  • initial port for the Haiku platform. The port is done by Kacper Kasper's work, one of Haiku developers. Threads are not supported yet.

  • refactored ECL internal tests framework. Tests in src/tests are now asdf-loadable (with load-source-op) and divided into test suites. make check target runs all regression and feature tests which aren't supposed to fail.

  • removed 15000 lines of obsolete code. Files not included in the buildsystem but lingering in the codebase or options failing to build. All info is added in the new documentation in the section "Removed interfaces".

  • improved man page and help output. Man page now contains up-to-date list of flags, as well as explanation of flag's behavior.

  • deprecated long flags with one dash, added two-dash version. Flags that aren't one-character, but start with one dash (e.g. -eval) are now deprecated; long version --eval was added instead.

  • indented C/C++ code to follow emacs's gnu C style. This is a first step towards coding standards in the documentation. Additionally all in the src/c/ directory are listed in the appropraite documentation section (new-doc).

  • refactored list_current_directory in unixfsys.d. Function was obfuscated with ifdefs with non-even pairs of #\{ and #\}.

Issues fixed

  • ECL signals floating point exceptions in top-level console.

  • mp:rwlock is treated as built-in class (previously process crashed if class-of was called on such object).

  • ECL builds now succesfully with --with-ieee-fp=no option.

  • ext:file-stream-fd: doesn't cause an internal-error if called with something not being a file-stream (signals a SIMPLE-TYPE-ERROR condtition).

  • stable-sort: bugfix and improvement in speed. Adapted from SBCL by Diogo Franco.

  • typep: accept * type specifier as abbreviation of T as described in 2.4.3 Type Specifiers of the specification.

  • MOP: fix problemes when redefining non-standard and anonymous classes. Bugs identified and fixed by Pascal Costanza.

  • getcwd: fix issue with too long pathname. This fixes the regression, which crashed ECL at start when pathname exceeded 128 characters limit.

  • make-random-state: fix a problem with simple-vectors. Until now #$ reader macro accepted simple vectors as an argument, what lead to bugs if vector didn't match specific requirements like the element type or the arity. Now we sanitize this.

  • make-load-form: provide implementation for random-state objects.

  • thread fix on msvc: on windows importing thread was closing the thread handler so the thread wakeup wasn't working because the handler is not more valid.

  • import thread wasn't set upping a proper environment: on some case the thread was mistakenly thinking that the thread was already registered.

  • ECL_HANDLER_CASE and ECL_RESTART_CASE didn't work as expected. Bug identified and fixed by Vadim Penzin.

]]>