ecl-devel

ecl-devel@common-lisp.net

1 participants
232 discussions

What is the best version of ECL to use right now?
by Dennis Ogbe 10 Jun '19

10 Jun '19

Hello, I am working on embedding ECL in a reasonably-sized C++ program and I have been using v16.1.3 until now, since it seems like this is the latest official release. However, it seems like there is a lot of activity and bug fixes in the develop branch and I already ran into a few bugs (for example [1]) that are fixed in develop, but are not in any release. The documentation also seems to overlap more with the develop branch than the latest release. In your opinion, what is the best and most stable ECL version to use as of June 2019? I have some reservations about simply picking a random commit from a dev branch, so I wanted to reach out and ask y'all directly. Thanks for all the hard work, this project is great! [1] https://gitlab.com/embeddable-common-lisp/ecl/issues/418

2 6

debug setup
by Andrea Corallo 17 Mar '19

17 Mar '19

Hi all, I'm using ECL with a classic setup Emacs + Slime. Unfortunately when I get a type-error somewhere in my program I have some problem debugging it. Inside the sldb I cannot inspect the frame (no locals) and seams It has no informations on which is function responsible for this error inside the codebase. My program is loaded by quicklisp and I have no idea if is compiled by ecl or interpreted. Do you have any suggestion on what is the recommended setup? I've attached my .eclrc but is quite standard I would say. Thanks for the help Best regards Andrea

1 0

Static library for windows
by Jón Hallur Haraldsson 16 Mar '19

16 Mar '19

Hi, I was wonder if I could easily build a static version of ECL on windows to link into other C++ projects without having to ship the ECL.dll with it. There is a "ecl-static.lib" recipe in the Makefile in the ./msvc folder which I can build after having built "all", but when linking that into an application that does nothing but call cl_boot() the linker (VS2015) complains with LNK2019 unresolved external symbol __imp__cl_boot referenced in function _main When looking into the symbols of the ecl-static.lib (created by MS dumpbin /symbols) the cl_boot function is defined but is UNDEF-ed so that the linker tries to find __imp__cl_boot which is not in the ecl-static.lib Looking through the mail list I came upon the mention of using --disable-shared when configuring, which works for me on Linux, but I don't know how to add that flag to the nmake environment on Windows (or if it is there at all) Regards, Jón Hallur

2 1

The mailbox API is incomplete
by Не Скажу 15 Mar '19

15 Mar '19

Hello! The mailbox API is incomplete, lacking timeout option. I don't know whether there is a common standard for it, but according to this - http://cl-cookbook.sourceforge.net/process.html at least LispWorks has such feature. Having timeout would be a really useful, consider this scenario: 1) Main thread continuously passes some data to ECL thread, waiting for ECL thread to process it. 2) ECL thread processes this data and returns it back to main thread; 3) Main thread continues execution, gathers new data, etc. Main thread --> ECL thread --> Main thread User is given full control over ECL thread, being able to change anything within it, mainly how data should be processed. What if user makes a mistake and something goes wrong, like: 1) Debugger is entered; 2) User input is requested; 3) An infinite loop is created. That would mean that execution of ECL thread is halted, halting execution of main thread in return. Program is stuck. A timeout would save from such situation: after x number of milliseconds passed execution would go back to the main thread and program wold not freeze. Main thread would know that something went wrong within ECL thread and could skip it next time until it receives notification that whatever problems had arisen in ECL thread were fixed. Sure, ignore-errors could be used to prevent debugger from breaking execution, but it would be much better to still being able to use it. Besides, ignore-errors will not save from problems 2 and 3 mentioned above.

2 1

Erros cross-compiling for MIPS
by Jeronimo Pellegrini 15 Mar '19

15 Mar '19

Hello, I am trying to get ECL to run on a MIPS-based wireless router that runs OpenWRT. This one: system type : Qualcomm Atheros QCA956X ver 1 rev 0 machine : TP-Link Archer C7 v4 processor : 0 cpu model : MIPS 74Kc V5.0 BogoMIPS : 385.84 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented : mips16 dsp dsp2 Options implemented : tlb 4kex 4k_cache prefetch mcheck ejtag llsc dc_aliases perf_cntr_intr_bit cdmm nan_legacy nan_2008 contextconfig perf shadow register sets : 1 OpenWRT has a framework for building packages; almost everything is in one Makefile and possibly patches, but the system takes care of whatever is needed to cross compile, usually. So, I have tried creating an ECL package, and, well, it complained I was cross-compiling :-) and told me that I should fill in a cross_config file. So I did (the only change was to choose ECL_BIGENDIAN=yes): ECL_STACK_DIR=down CL_FIXNUM_TYPE=int CL_FIXNUM_BITS=32 CL_FIXNUM_MAX=536870911L CL_FIXNUM_MIN=-536870912L CL_INT_BITS=32 CL_LONG_BITS=32 ECL_BIGENDIAN=yes ECL_NEWLINE=LF ECL_FILE_CNT=0 ECL_STDINT_HEADER="#include <stdint.h>" ECL_UINT8_T=uint8_t ECL_UINT16_T=uint16_t ECL_UINT32_T=uint32_t ECL_UINT64_T=no ECL_INT8_T=int8_t ECL_INT16_T=int16_t ECL_INT32_T=int32_t ECL_INT64_T=no ECL_LONG_LONG_BITS=no ECL_WORKING_ENVIRON=yes ECL_TO_RUN=/usr/local/bin/ecl Then, when compiling, I got the error below. It seems that I probably got something wrong in the cross_config file (is that correct?) Does it look like something easy/obvious to fix? Is the output of the configure script necessary? Thank you! Jeronimo . . . Making all in src make[6]: Entering directory '/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3/build/atomic/src' make[7]: Entering directory '/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3/build/atomic/src' libtool: compile: mips-openwrt-linux-musl-gcc -DHAVE_CONFIG_H -I../src -I/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3/src/bdwgc/libatomic_ops/src -I/home/jeronimo/pkg/openwrt/staging_dir/target-mips_24kc_musl/usr/include -I/home/jeronimo/pkg/openwrt/staging_dir/target-mips_24kc_musl/include -I/home/jeronimo/pkg/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.4.0_musl/usr/include -I/home/jeronimo/pkg/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.4.0_musl/include/fortify -I/home/jeronimo/pkg/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.4.0_musl/include -fPIC -Wall -Wextra -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 -iremap/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3:ecl-16.1.3 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/jeronimo/pkg/openwrt/staging_dir/target-mips_24kc_musl/usr/include/ -fPIC -D_THREAD_SAFE -MT atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c /home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3/src/bdwgc/libatomic_ops/src/atomic_ops.c -fPIC -DPIC -o atomic_ops.o {standard input}: Assembler messages: {standard input}:24: Error: opcode not supported on this processor: mips2 (mips2) `sync ' {standard input}:47: Error: opcode not supported on this processor: mips2 (mips2) `ll $2,0($4)' {standard input}:49: Error: opcode not supported on this processor: mips2 (mips2) `sc $5,0($4)' make[7]: *** [Makefile:597: atomic_ops.lo] Error 1 make[7]: Leaving directory '/home/jeronimo/pkg/openwrt/build_dir/target-mips_24kc_musl/ecl-16.1.3/build/atomic/src' make[6]: *** [Makefile:460: all] Error 2

2 1

ECL cross-compiled for 'aarch64' considered stable?
by PR 12 Mar '19

12 Mar '19

Hi, I have a question about 'aarch64' cross compiling: Using a recent ECL git snapshot (2019-03-06) I could successfully cross-compile ECL to aarch64 (applying a small patch, more on this later), using android NDK 18b (which uses llvm). Did anybody here run ECL on aarch64, and is it considered to be stable? I'm asking because of my EQL5-Android project: I successfully compiled the REPL example to aarch64, but I encountered a severe memory corruption at startup. I found a (stupid) workaround for this, and it definitely happens only with the combination of Qt 5.12.1 and ECL on android. (Qt 5.12.1 on aarch64 runs stable without ECL). Once the android REPL example is started up, the app seems to run fine. (The stupid workaround hack I use is calling the QApplication constructor twice, first on the stack, then on the heap; the used one is the one on the heap; without this the app would crash every time I call QCoreApplication::arguments(), which accesses 'argc' and 'argv' passed to 'main()': this means that the argc, argv data gets overwritten somehow on startup.) Regarding the above mentioned patch to cross-compile to aarch64: I needed to comment out one line in 'build/ecl/config-internal.h': //# define FILE_CNT(fp) ((fp)->_r) Here the patch: diff --git a/config-internal.h.orig b/config-internal.h index 2c0cd4c..a399192 100644 --- a/config-internal.h.orig +++ b/config-internal.h @@ -211,7 +211,7 @@ # define FILE_CNT(fp) ((fp)->_IO_read_end - (fp)->_IO_read_ptr) #endif #if 2 == 2 -# define FILE_CNT(fp) ((fp)->_r) +//# define FILE_CNT(fp) ((fp)->_r) // not available for 'aarch64' with recent android NDK #endif #if 2 == 3 # define FILE_CNT(fp) ((fp)->_cnt) This is because the 'struct __sFILE' in latest NDKs is only opaquely defined, and they say that we can't rely on its internals. In fact, the definition in "struct_file.h" is this (android NDK 18b, which is llvm only, gcc just links to clang): struct __sFILE { #if defined(__LP64__) char __private[152]; #else char __private[84]; #endif } __attribute__((aligned(sizeof(void*)))); You see, no internals revealed! Any comments on this appreciated, Paul

2 3

Re: Is this thing on? Cross-compiling for ARM
by Renaud Casenave-Péré 24 Feb '19

24 Feb '19

On Tue, Feb 19 2019, PR wrote: > 2019-02-19 2:06 GMT+01:00, Renaud Casenave-Péré <renaud(a)casenave-pere.fr>: >> I still need to find a way to efficiently use slime with this setup. > > Just thinking loud: couldn't the approach used in EQL5-Android be > ported to Sailfish (I mean for Slime), because on Android not only > Lisp but also the QML files can be reloaded live on the device, which > is very convenient (like in example "my" from EQL5-Android): > > https://gitlab.com/eql/EQL5-Android/tree/master/examples/my That is indeed a pretty nice solution, thanks! -- Renaud Casenave-Péré

1 0

Catching SIGPIPE
by Gunter Königsmann 15 Feb '19

15 Feb '19

Dear all, Maxima (which is written in lisp) connects to its front-end using a network socket. stdout and stderr of the lisp are redirected to this socket. If the front-end dies unexpectedly this seems to cause ECL to output an error message which (since it cannot be output) causes an error message which causes... On gcl maxima just catches the SIGPIPE signal and exits if the pipe breaks. ECL offers ECL_OPT_TRAP_SIGPIPE but I don't know what to do with it. Could anyone give me a hand? the function that sets up the server is: (defun setup-client (port &optional (host "localhost")) ;; The following command has to be executed on windows before ;; the connection is opened. If it isn't the first unicode ;; character maxima wants to send causes sbcl to wait indefinitely. #+sbcl (setf sb-impl::*default-external-format* :utf-8) (multiple-value-bind (sock condition) (ignore-errors (open-socket host port)) (unless sock ; It appears that we were unable to open a socket or connect to the ; specified port. (mtell (intl:gettext "~%Unable to connect Maxima to port ~:M.~%") port) (mtell (intl:gettext "Error: ~A~%") condition) ($quit)) #+gcl (setq si::*sigpipe-action* 'si::bye) (setq *socket-connection* sock) (setq $old_stderr *error-output* $old_stdout *standard-output*) #+ecl (setq *old-stdin* *standard-input* *old-stdout* *standard-output* *old-sterr* *error-output* *old-term-io* *terminal-io* *old-debug-io* *debug-io*) (setq *standard-input* sock) (setq *standard-output* sock) (setq *error-output* sock) (setq *terminal-io* sock) (setq *trace-output* sock) (format t "pid=~a~%" (getpid)) (force-output sock) (setq *debug-io* sock)) (values)) Kind regards, Gunter.

2 1

least-positive vs least-positive-normalized
by Raymond Toy 13 Feb '19

13 Feb '19

With ecl 16.1.3, I noticed that least-positive-double-float and least-positive-normalized-double-float are exactly equal. This is allowed, but ecl can work with denormals since (/ least-positive-normalized-double-float 10) is printed correctly. Maybe these two values should be different? Or maybe ecl really meant to turn on flush-to-zero so that no denormals can occur? -- Ray?

3 3

specifying custom location for ecl-quicklisp packages
by Dima Pasechnik 03 Feb '19

03 Feb '19

Dear all, we have trouble understanding how ecl-quicklisp can be configured to install packages at a custom location. Currently, either (require :asdf) (asdf:load-system :ecl-quicklisp) or (require :ecl-quicklisp) starts installing things into ~/quicklisp/ no matter what one tries. E.g. quicklisp FAQ tells about (quicklisp-quickstart:install :path ".quicklisp/") but this seems to need to be evaluated much earlier than (require :ecl-quicklisp)... Does this mean one needs to change the ECL installation procedure to take care of this? Thanks Dima

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

ecl-devel