ECL Quarterly Volume I
Tagged as quarterly
Written by Daniel Kochmański on 2015-05-01
From time to time there are misleading signals, that ECL is "floating dead". This FUD is mostly spread by IRC newcomers with little orientation, but it's good! This is a signal, that this particular implementation of Common Lisp needs to make little more noise, instead of silently fixing ** stuffstuff* (however it obviously needs a bit of work on *as well ;-)) .
Some projects make new release each month to prevent such disinformation. It solves this particular problem, but introduces a new one - it's a bit fuzzy, if a new release introduces any significant improvements, or if it's just a release number bump. Yet, updating it requires recompilation of personal projects, which depending on machine might take a while and is surely a bit annoying.
This is where ECL Quarterly idea has born. To show a bit activity from time to time - post will be published every three months. I want to make it an e-zine containing info about development, tutorials, comparisons, benchmarks and anything, what is at least slightly related to ECL. Everyone is welcome to contribute - such materials will be also published on wiki, added to git tree, and if appropriate - incorporated in documentation. If you have such material, don't hesitate to contact me at dkochmanski[at]turtle-solutions[dot]eu.
This chapter highlights:
- Changes, development status etc.
- Contributing to ECL
If you have any suggestions regarding ECL Quarterly, you like it, or maybe hate it - please tell me either by commenting this post, or writing an e-mail. Thank you!
2 Changes and development status
After 15.3.7 release there are a few changes going on. We are now hosted at gitlab.com (however it would be nice to move to gitlab.common-lisp.net, just /not now/), a few wiki entries are added, official site is https://common-lisp.net/project/ecl/. Domain embeddable-common-lisp.net is already bought (not configured properly yet).
Until now we have updated libraries, which we depend on. Namely:
- libffi to version 3.2.1,
- asdf to version 3.1.4,
- bdwgc to version 7.4.2.
There was also update of GMP to more recent version, but we won't include it - yes, we are staying LGPLv2, to remain GPLv2 compatible. All changes were tested on Windows with MSVC2012.
For now we have also reworked
macros, to conform ANSI standard in regard to places (multiple
values weren't held properly).
Experimental branch contains Android (as name suggests - experimental) port, which is preview only for now (this branch is LGPLv3, because included GMP enforces it, and doesn't build on Windows).
Loads of things are to be done, and we're slowly making progress. After all we won't change release versioning scheme. No ETA for next release, but I assure you - if you contribute, it will be sooner ;-). What leads us to the next part.
3 Contributing to ECL
3.1 Documentation, tutorials, wiki, others
You can contribute in numerous ways. One way is to code and fix bugs - and it's very important part. But equally important is to find bugs and report them, so developers can improve codebase. Feature requests are also welcome (however we are focused now on fixing stuff rather than adding functionality, so even good proposition might wait in queue behind something maybe less exciting).
Testing on various platform and architectures is essential. Thanks
to Anton Vodonosov and
is as easy as setting environment, tweaking two configuration
files and invoking
./run-agent.sh. Run may take a while
(depending on computer) and is limited to operating systems and
architectures supported by Clozure Common Lisp.
If ECL doesn't build, crashes, or works non-conforming to specification, please do report at https://gitlab.com/embeddable-common-lisp/ecl/issues. It requires account on GitLab, but setting it up is free. I'm still struggling to produce some time and move all tickets from https://sourceforge.net/p/ecls/_list/tickets to above mentioned issue tracking site - volunteers are more then welcome to do it.
If you encounter problem, please write to mailing list. There are many kind souls there more then willing to help - and usually they do. On the other hand, if someone asks for help and you know the answer - act! :-)
Wiki is a place, where many resources are gathered. It is incomplete and barely usable, because I don't have time to improve it. If you successfully build ECL on Android - great! Please add page to wiki, so others may reproduce your work! Do you have some nifty idea, and you believe it is worth to keep it there - do it. See a typo? Bug? Outdated information? You know what to do! You spot some nice blog post about ECL? Please share with others - wiki is best place to do so. You did successful project using ECL? Share this information! All this, and so much more, may be done here: https://gitlab.com/embeddable-common-lisp/ecl/wikis/home.
You can also write something for ECL Quarterly (my e-mail is mentioned in preface).
3.2 Source code contributions
Development takes place on git repository located at email@example.com:embeddable-common-lisp/ecl.git.
If you want your code in Embeddable Common-Lisp project, please
send a patch to mailing list with additional tag [PATCH] in
subject. Generally we want to follow convention used by U-Boot
development team (http://www.denx.de/wiki/U-Boot/Patches),
which borrows a lot from Linux policy. Please read this guide,
it's really worthwhile reading. If you submit a significant
change, please report it in
CHANGELOG located in top directory.
Basically, if you want to contribute to code, you have at least
two choices. You may improve C code (which is probably less
interesting for lispers). Most of the sources are written in lisp
however, and require no knowledge about C. Problems vary from
fairly easy even for seasoned developer to hard conceptual
riddles, so everyone can find something interesting for
himself.. Please consult appropriate directories under
src/clos etc.) - it's pure lisp!
And it's fun to hack. Improving both C and Lisp sources might be a
great learning experience. To figure what's wrong requires often
getting your hands dirty, and then cleaning proposed
solution. This, connected with peer review, might be a next step
to become a better programmer.
There is also a third part, which is tiresome (for me at least) - improving build system - it is buggy and inconsistent. First person who will fix this has granted a free dinner when we meet in person. Remember however, that we support many operating systems, so it might be tricky to do it properly without introducing *new* problems.
If you are a library or application developer, _please_ test against as many implementations as possible - it's hard, it takes time, but in my humble opinion it is essential for CL ecosystem. Each implementation has it's weak and strong sides, and you never know, when you'll need one, or who and in what purpose is using your code :-).