ddb7bb72e9
Otherwise it can happen that a user-defined finalizer for some object A storing a builtin object B registers another finalizer for A making B reachable again while B has already been finalized. We can't impose an ordering for user-defined finalizers in general since these may include cyclic references. Therefore it is the duty of the user to write the finalizers in a consistent way which is independent of the order in which the finalizers are called. This doesn't work for builtin objects since the user can't influence the finalizers in this case. We also fix a bug which lead to the removal of the standard finalizer if a user-defined finalizer was registered and then removed. Co-authored-by: Daniel Kochmański <daniel@turtleware.eu> |
||
|---|---|---|
| contrib | ||
| examples | ||
| msvc | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appveyor.yml | ||
| CHANGELOG | ||
| configure | ||
| COPYING | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| README.md | ||
ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an implementation of the Common-Lisp language which complies to the ANSI X3J13 definition of the language.
The term embeddable refers to the fact that ECL includes a Lisp to C compiler, which produces libraries (static or dynamic) that can be called from C programs. Furthermore, ECL can produce standalone executables from Lisp code and can itself be linked to your programs as a shared library. It also features an interpreter for situations when a C compiler isn't available.
ECL supports the operating systems Linux, FreeBSD, NetBSD, DragonFly BSD, OpenBSD, Solaris (at least v. 9), Microsoft Windows (MSVC, MinGW and Cygwin) and OSX, running on top of the Intel, Sparc, Alpha, ARM and PowerPC processors. Porting to other architectures should be rather easy.