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

FEprogram_error vs FEprogram_error_noreturn
by Kris Katterjohn 01 Jul '17

01 Jul '17

Hey, I notice that there is a FEprogram_error and a FEprogram_error_noreturn in src/c/error.d; however, it looks like these functions are identical aside from their names. I copied these to different files and diff'd them: --- test 2017-06-28 15:39:32.199877688 -0500 +++ test2 2017-06-28 15:39:32.199877688 -0500 @@ -1,5 +1,5 @@ void -FEprogram_error(const char *s, int narg, ...) +FEprogram_error_noreturn(const char *s, int narg, ...) { cl_object real_args, text; ecl_va_list args; FEprogram_error_noreturn was added in commit 7d9fb8bb. I think it was added because FEprogram_error didn't have the noreturn attribute, so FEprogram_error_noreturn was introduced with this attribute. However, it looks like FEprogram_error (and others) got this attribute in commit 790d466c. (This all happened in Feb 2010.) Currently in src/h/external.h: extern ECL_API void FEprogram_error(const char *s, int narg, ...) ecl_attr_noreturn; extern ECL_API void FEprogram_error_noreturn(const char *s, int narg, ...) ecl_attr_noreturn; They are both used throughout src/c. It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn. If these changes are desired, then I can open up a new Merge Request with these changes after my currently open Merge Request is done (to avoid conflicts). Cheers, Kris Katterjohn

3 3

Android question (for porting EQL5 to that platform)
by PR 27 Jun '17

27 Jun '17

Hi all, I'm currently trying to port EQL5 to the android platform. There is a big show-stopper to this: - building ECL for android only works with NDK r9 (which is really old already) - building EQL5 for android only works with NDK r15 (for Qt 5.9; but Qt5 requires a recent NDK anyway) Since I need to link the both together, I have an incompatibility issue during the final linker step. Now, the only solution I see (so far) would be this: making ECL work with latest NDK r15. Did anybody already give it a try? Is it feasible at all? (We need to look at what we would be gaining: EQL5 on android, using QML and Lisp, just would be too nice to have!!) Thanks, Paul

2 5

ECL 16.1.3 on mingw-w64 64-bit
by Dave Richards 24 Jun '17

24 Jun '17

I am able to build ECL on mingw-w64 in 32-bit mode, but when I build in 64-bit mode it fails with a Lisp Initialization error. I notice that when building under MSVC there is an ECL_WIN64 make variable that must be set. Is there a similar variable for mingw-w64? If so, I have not found it. Thanks! Dave

2 1

Running examples from REPL
by Ivan Truskov 05 Jun '17

05 Jun '17

Hello I am trying to have a go with ECL. I have built ECL on windows 10 machine with 64-bit Visual Studio (community version) and i am trying to run example on build that comes with the source code. In open window of ecl.exe, i go to the folder, and call load on "readme.lisp". Then, on the first lines of it, i recieve the following error and the execution stops. Error as follows: > Condition of type: SIMPLE-ERROR > In COMPILE-FILE-PATHNAME, the type OBJECT is unsupported. > Available restarts: > > 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > Broken at SI:BYTECODES. [Evaluation of: (C::COMPILER-CC "hello_aux.c" > (COMPILE-FILE-PATHNAME "hello_aux.c" :TYPE :OBJECT))] In: #<process > TOP-LEVEL>. > File: > #P"C:/Users/Kurvivor/Development/ecl-16.1.3/examples/build/readme.lisp" > (Position #1054) How can i get past this error? Related question: how do i set up the compiler used and compiler environment? How do i check it (determine what current setings are)? Thanks in advance!

2 1