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

ecl + Windows + GUI
by dave＠synergy.org 07 Oct '20

07 Oct '20

Is there a GUI package for ecl on Windows? Dave

3 2

Windows annoyance building ECL in Windows 10 with (free) MSVC compiler
by PR 29 Sep '20

29 Sep '20

Hi, since I needed to build latest ECL for current Windows 10 (free! did you know? I didn't!) with the command line tools included in (free as in "register first") Visual Studio Express 2015, I encountered an annoyance while building the garbage collector library: The build in 'ecl/msvc' (using nmake.exe) failed early complaining about not being able to find both 'libcmt.lib' and 'libvcruntime.lib'. Since I struggled a while before finding the (simple) solution, I wanted to put it here, just for reference. The following fixed it for me: Copy both files (see above) from / to: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\onecore\amd64\ C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\ Paul P.S. about Windows 10 being "free": search the web for yourself, but it's true: you can download an official ISO image of Windows 10 form the MS website, and you're not required to purchase a license, if you agree to not being able to customize its look and feel...; so, you basically get both their OS and compiler suite for nothing more than the patience of downloading some GB, and providing 'some' email address for registering an account...

1 0

Is this thing on? Cross-compiling for ARM
by Erik Winkels 26 Sep '20

26 Sep '20

Hi all, Not sure if this is still the place to be for ECL questions but here it goes: I'm having issues cross-compiling ECL for ARM and since this is actually the first time I'm cross-compiling stuff ever I'm kinda stuck. I want to cross-compile for ARM, *but* it is not for Android it is for Sailfish OS. There's an (unofficial) ECL package available for it but I cannot find a way to contact the author and also don't want to depend on it. On my Void Linux machine I've installed `cross-arm-linux-gnueabi` and can do a `./configure --host=arm-linux-gnueabi` but when I do `make` I get the following errors: ``` dpp: /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d -> list.o.c Unknown symbol: mp::compare-and-swap-car Unknown symbol: mp::atomic-incf-car Unknown symbol: mp::compare-and-swap-cdr Unknown symbol: mp::atomic-incf-cdr /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d: In function 'mp_compare_and_swap_car': /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d:670:26: error: 'unknown' undeclared (first use in this function) return ecl_compare_and_swap(&ECL_CONS_CAR(x), old, new); ^~~~~~~ /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d:670:26: note: each undeclared identifier is reported only once for each function it appears in /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d: In function 'mp_atomic_incf_car': /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d:678:26: error: 'unknown' undeclared (first use in this function) return ecl_atomic_incf(&ECL_CONS_CAR(x), increment); ^~~~~~~ /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d: In function 'mp_compare_and_swap_cdr': /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d:686:26: error: 'unknown' undeclared (first use in this function) return ecl_compare_and_swap(&ECL_CONS_CDR(x), old, new); ^~~~~~~ /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d: In function 'mp_atomic_incf_cdr': /home/brainrot/projects/eclrepl/3rd-party/ecl-git/src/c/list.d:694:26: error: 'unknown' undeclared (first use in this function) return ecl_atomic_incf(&ECL_CONS_CDR(x), increment); ^~~~~~~ make[2]: *** [Makefile:88: list.o] Error 1 make[2]: Leaving directory '/home/brainrot/projects/eclrepl/3rd-party/ecl-git/build/c' make[1]: *** [Makefile:144: libeclmin.a] Error 2 make[1]: Leaving directory '/home/brainrot/projects/eclrepl/3rd-party/ecl-git/build' make: *** [Makefile:72: all] Error 2 ``` I get the feeling I'm forgetting some necessary steps. Thanks, Erik

4 19

How can i create a window on Linux. Can we call main function in C from CL using CFFI?
by oleg harput 03 Jul '20

03 Jul '20

I tried to create a window on Linux(as i undestand you need to use additional libraries in Linux) so i tried to reach the this code using CFFI command (cffi:foreign-funcall "main" :void :void :int) The C CODE: #include <GLFW/glfw3.h> #include <stdlib.h> #include <stdio.h> static void error_callback(int error, const char* description) { fputs(description, stderr); } static void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods) { if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS) glfwSetWindowShouldClose(window, GL_TRUE); } int main(void) { GLFWwindow* window; ... } Which works in C. But SBCL gives me error message: Execution of a form compiled with errors. Form: (EXTERN-ALIEN "main" (FUNCTION INT VOID)) Compile-time error: during macroexpansion of (EXTERN-ALIEN "main" (FUNCTION INT VOID)). Use *BREAK-ON-SIGNALS* to intercept. cannot use values types here [Condition of type SB-INT:COMPILED-PROGRAM-ERROR] What does this error mean? Can we call main function in C using CFFI? Is there a solution?

1 0

ECL crashes on iOS loading ASDF libs with several dependencies
by PR 02 Jun '20

02 Jun '20

Hi, ECL on iOS seems to run fine so far, but there is an issue when trying to load ASDF systems which depend on several other ones. The full description of the issue can be found here (including a backtrace): https://gitlab.com/eql/eql5-ios/-/issues/3 It would be great if somebody with experience of the ECL internals could look at this, since it's kind of a show stopper for the (free) CL REPL app. Thanks for any hints, Paul

1 2

[PATCH] Fix Unicode handling in :INVERT readtable and :CASE :COMMON pathnames
by Vladimir Sedach 11 May '20

11 May '20

Hello, Attached are fixes for ecl_string_case, which does not handle Unicode correctly. This shows up in two places in the CL run-time. Currently the READTABLE-CASE :INVERT issue is preventing Parenscript 2.8 from compiling. -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la

2 6

[release][ecl 20.4.24]
by Daniel Kochmański 25 Apr '20

25 Apr '20

Dear All, we've released today a new version of ECL. For details please see the announcement on our blog: https://common-lisp.net/project/ecl/posts/ECL-20424-release.html Best regards, Daniel P.S. I've modified a blog a little so the index shows only headers (instead of whole bodies). It is easier to navigate old entries that way. -- 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

3 2

[CfPart] 13th European Lisp Symposium, happening online, free of charge!
by Didier Verna 14 Apr '20

14 Apr '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for participation April 27 - April 28, 2020 Sponsored by EPITA, Igalia S.L., and RavenPack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #COVID19 important information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the context of the current pandemic, the symposium has been turned into an online event, and will be open to anyone, free of charge! Connection instructions will be posted on the website when available. Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Scope ~~~~~ The purpose of the European Lisp Symposium is to provide a 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, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. This year's focus is directed towards "Compilers". Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Metin Evrim Ulu - Middle East Technical University, Turkey Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

ASDF problem on second load of ECL
by querent 27 Feb '20

27 Feb '20

Hi there, I am just trying to use ECL for a little project of mine, but I have a problem. Immediately after installation, things seem to work fine. I can run things, produce executables, etc. However, the second time I load ECL I get the error listed below. Deleting .cache/common-lisp/ecl-16.1.3 removes the error, but of course the world gets recompiled every time I load something. And then again the next time I load ECL after that I get the error again. I am using Ubuntu 19.10. I have tried compiling the development branch from gitlab (wouldn't be the first time Ubuntu ships with a buggy package when upstream is fine) but I get the same behaviour. I did try using restart 1. to increase the stack size, but I just keep getting the error until I get an error about being unable to increase the stack size anymore. The error is the same that Zhou Qianliang reported in January, but I'm not doing anything odd, just trying to start ecl for a second time. https://mailman.common-lisp.net/pipermail/ecl-devel/2020-January/011473.html I have searched for the error message but not come up with anything much more than the above mailing list message. Error message: ;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas" An error occurred during initialization: The slot ASDF/PLAN::STAMP in the object #<action-status Condition of type: STACK-OVERFLOW BINDING-STACK overflow at size 10240. Stack can probably be resized. Proceed with caution. Available restarts: 1. (CONTINUE) Extend stack size 2. (RETRY) Retry ASDF operation. 3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">. 5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful. 6. (RETRY) Retry ASDF operation. 7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 8. (CONTINUE) Ignore initialization errors and continue. 9. (ABORT) Quit ECL unsafely, ignoring all existing threads. Top level in: #<process TOP-LEVEL 0x55b73cdd2f80>. > Thanks for any help you can give me. I'm looking forward to using ECL, seems like a nice platform! --querent.

3 3

AW: ASDF problem on second load of ECL
by marius.gerbershagen＠gmail.com 27 Feb '20

27 Feb '20

Hi, I have seen this problem occurring previously when asdf was trying to update itself. Unfortunately, the update process is so complicated that I wasn't able to determine whether the error is due to a bug in asdf or in ECL. Therefore, I can only offer you two possible workarounds: a) make sure that no copy of asdf is located somewhere where asdf is searching for its systems or b) create a monolithic asdf.lisp file from the asdf sources, drop it in place of contrib/asdf/asdf.lisp in the ECL sources and recompile ECL. Best, Marius Gerbershagen ----- Reply message ----- Von: "querent" <querent(a)yandex.com> An: <ecl-devel(a)common-lisp.net> Betreff: ASDF problem on second load of ECL Datum: Do., Feb. 27, 2020 10:57 Hi there, I am just trying to use ECL for a little project of mine, but I have a problem. Immediately after installation, things seem to work fine. I can run things, produce executables, etc. However, the second time I load ECL I get the error listed below. Deleting .cache/common-lisp/ecl-16.1.3 removes the error, but of course the world gets recompiled every time I load something. And then again the next time I load ECL after that I get the error again. I am using Ubuntu 19.10. I have tried compiling the development branch from gitlab (wouldn't be the first time Ubuntu ships with a buggy package when upstream is fine) but I get the same behaviour. I did try using restart 1. to increase the stack size, but I just keep getting the error until I get an error about being unable to increase the stack size anymore. The error is the same that Zhou Qianliang reported in January, but I'm not doing anything odd, just trying to start ecl for a second time. https://mailman.common-lisp.net/pipermail/ecl-devel/2020-January/011473.html I have searched for the error message but not come up with anything much more than the above mailing list message. Error message: ;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas" An error occurred during initialization: The slot ASDF/PLAN::STAMP in the object #<action-status Condition of type: STACK-OVERFLOW BINDING-STACK overflow at size 10240. Stack can probably be resized. Proceed with caution. Available restarts: 1. (CONTINUE) Extend stack size 2. (RETRY) Retry ASDF operation. 3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">. 5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful. 6. (RETRY) Retry ASDF operation. 7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 8. (CONTINUE) Ignore initialization errors and continue. 9. (ABORT) Quit ECL unsafely, ignoring all existing threads. Top level in: #<process TOP-LEVEL 0x55b73cdd2f80>. > Thanks for any help you can give me. I'm looking forward to using ECL, seems like a nice platform! --querent.

1 0