5 ms·

Hey, I'm one of ECL maintainers. If you have some questions I'll be glad to answer.

mark_l_watson 3y ago
Thanks for your work! Question: are there any projects you know of where people use ECL compiled to Apple’s M1/M2 and used as a library with Swift and SwiftUI? I experimented with LispWorks for macOS and it was fairly nice for building Mac apps, but I had issues getting an app accepted by the Apple Store (probably my fault). EDIT: other people and companies had LispWorks apps accepted by the Apple Store
- jackdaniel 3y ago
  I know that ECL works on Apple M1 and otherwise, as of Swift - no idea. LQML / EQL5 created by Paul Ruetz is a very cool project that works on iphone, android and such with appealing graphical inteface. It is basically ECL embedded in QT. If I recall correctly Paul has a few applications in the Apple Store, but you'd need to ask him directly to confirm that.
schemescape 3y ago
Is it possible to compile to native in a fully static binary? By default, ECL seems to link with a libecl (or something like that) shared object. If I compile with “--disable-shared”, it seems to also remove the “compile to native” part. Or at least that’s how it appeared to me. It’s possible I’m misunderstanding, but it I didn’t see why those two aspects (static binary and native/non-byte code) are coupled. Again, apologies if I’m just misinterpreting! Edit: my motivation is I have some small utilities that I’d like to be able to just copy to any Linux box (even musl libc-based Alpine) and have them work, regardless of glibc/ECL being present.
- jackdaniel 3y ago
  The short answer is no - ECL links against the libc present on the system. It is not that it could not be improved in this regard. Even when you compile with "--disable-shared" you'll link against libc (but everything else will be statically linked). The function "--disable-shared" does not remove the compiler to native, it removes compilation of fasls to native. The reason for that is this: - "native" fasls are shared objects under disguise linked against libecl (dlopen) - they can't not link against libecl unless you want to statically link whole ecl with the fasl Imagine that you call a PRINT function from the FASL. The symbol you will probably reference is ecl_print that is defined in ECL core runtime (usually in libecl.so, libecl.a/static-ecl). The native compiler still can produce statically linked native binaries. Now I'll get into current ECL developments - mind that this is not granted that this pan out as expected - perhaps I'll scrap whole work at some point: I'm refactoring ECL compiler to have multiple frontends and backends (something like LLVM) - currently passes are far more coupled. With that I hope to have a better control over a generated code and we could use static analysis about which parts of CL are used, and in an opt-in manner we could allow minimal static builds that do not depend on full CL. Such static binaries could be really small.
  - schemescape 3y ago
    As far as libc, I should have clarified that I meant linking with musl libc, which can in fact be linked in statically, unlike glibc. So that part is not a problem for me. As for the FASL compilation part, it sounds like I did indeed misunderstand the documentation, but I’ll need to digest your comment a bit more :) Thanks!
    - jackdaniel 3y ago
      I think that you'd need to tinker a little with ECL makefile to adjust flags in order to enable static linking. That said ECL does work with musl libc, so at least from the porting perspective there should not be any problem. If you manage to link musl libc statically then I'd greatly appreciate if you share your experience on our issue tracker or on irc (#ecl @ libera.chat), and if you have problems with it, you may ask in either for advice.
nonenobody 3y ago
> If you have some questions I'll be glad to answer. What is the main difference between ECL and GCL?
- jackdaniel 3y ago
  Both ECL and GCL are descendants of Kyoto Common Lisp. That said ECL (generally speaking) is a complete as ANSI Common Lisp implementation[1], has more "man years" under its belt, has active community, better support across platform, is recognized by Common Lisp developers and has more "man years" under its belt. [1] One of current GCL goals is to reach it

Thanks for your work! Question: are there any projects you know of where people use ECL compiled to Apple’s M1/M2 and used as a library with Swift and SwiftUI? I experimented with LispWorks for macOS and it was fairly nice for building Mac apps, but I had issues getting an app accepted by the Apple Store (probably my fault). EDIT: other people and companies had LispWorks apps accepted by the Apple Store

jackdaniel 3y ago
I know that ECL works on Apple M1 and otherwise, as of Swift - no idea. LQML / EQL5 created by Paul Ruetz is a very cool project that works on iphone, android and such with appealing graphical inteface. It is basically ECL embedded in QT. If I recall correctly Paul has a few applications in the Apple Store, but you'd need to ask him directly to confirm that.

schemescape 3y ago

Is it possible to compile to native in a fully static binary? By default, ECL seems to link with a libecl (or something like that) shared object. If I compile with “--disable-shared”, it seems to also remove the “compile to native” part. Or at least that’s how it appeared to me. It’s possible I’m misunderstanding, but it I didn’t see why those two aspects (static binary and native/non-byte code) are coupled. Again, apologies if I’m just misinterpreting! Edit: my motivation is I have some small utilities that I’d like to be able to just copy to any Linux box (even musl libc-based Alpine) and have them work, regardless of glibc/ECL being present.

jackdaniel 3y ago
The short answer is no - ECL links against the libc present on the system. It is not that it could not be improved in this regard. Even when you compile with "--disable-shared" you'll link against libc (but everything else will be statically linked). The function "--disable-shared" does not remove the compiler to native, it removes compilation of fasls to native. The reason for that is this: - "native" fasls are shared objects under disguise linked against libecl (dlopen) - they can't not link against libecl unless you want to statically link whole ecl with the fasl Imagine that you call a PRINT function from the FASL. The symbol you will probably reference is ecl_print that is defined in ECL core runtime (usually in libecl.so, libecl.a/static-ecl). The native compiler still can produce statically linked native binaries. Now I'll get into current ECL developments - mind that this is not granted that this pan out as expected - perhaps I'll scrap whole work at some point: I'm refactoring ECL compiler to have multiple frontends and backends (something like LLVM) - currently passes are far more coupled. With that I hope to have a better control over a generated code and we could use static analysis about which parts of CL are used, and in an opt-in manner we could allow minimal static builds that do not depend on full CL. Such static binaries could be really small.
- schemescape 3y ago
  As far as libc, I should have clarified that I meant linking with musl libc, which can in fact be linked in statically, unlike glibc. So that part is not a problem for me. As for the FASL compilation part, it sounds like I did indeed misunderstand the documentation, but I’ll need to digest your comment a bit more :) Thanks!
  - jackdaniel 3y ago
    I think that you'd need to tinker a little with ECL makefile to adjust flags in order to enable static linking. That said ECL does work with musl libc, so at least from the porting perspective there should not be any problem. If you manage to link musl libc statically then I'd greatly appreciate if you share your experience on our issue tracker or on irc (#ecl @ libera.chat), and if you have problems with it, you may ask in either for advice.

nonenobody 3y ago

> If you have some questions I'll be glad to answer. What is the main difference between ECL and GCL?

jackdaniel 3y ago
Both ECL and GCL are descendants of Kyoto Common Lisp. That said ECL (generally speaking) is a complete as ANSI Common Lisp implementation[1], has more "man years" under its belt, has active community, better support across platform, is recognized by Common Lisp developers and has more "man years" under its belt. [1] One of current GCL goals is to reach it