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

Re: [Ecls-list] threading failures
by Daniel Kochmański 22 Jan '16

22 Jan '16

Hello, that's probably my fault, sorry. I've migrated bugs manually and probably missed this one (I remember this bug! but can't find anywhere). I'm adding it to regression tests in repository, thanks! Yes, old reports are unfortunately lost. As a sienote, please use ecl-devel(a)common-lisp.net mailing list – I'm closing the old one today. You can subscribe here https://mailman.common-lisp.net/listinfo/ecl-devel . All archives before 2015-08-10 are imported to the new one and gmane stream is redirected (if you use it). Regards, Daniel James M. Lawrence writes: > Hello, the threading bugs I reported a while ago appear to have not > survived the migration from sourceforge, and the old pages are now > 404'd. There were a number of test cases, including > > (defun test (message-count worker-count) > (let ((to-workers (mp:make-semaphore)) > (from-workers (mp:make-semaphore))) > (loop repeat worker-count > do (mp:process-run-function > "test" > (lambda () > (loop > (mp:wait-on-semaphore to-workers) > (mp:signal-semaphore from-workers))))) > (loop > (loop repeat message-count > do (mp:signal-semaphore to-workers)) > (loop repeat message-count > do (mp:wait-on-semaphore from-workers)) > (assert (zerop (mp:semaphore-count to-workers))) > (assert (zerop (mp:semaphore-count from-workers))) > (format t ".") > (finish-output)))) > > (defun run () > (test 10000 64)) > > RUN will eventually hang on all versions of ECL I've tried, including > the latest. Another test case was a variant of the above using a > homemade semaphore. I can rewrite that and other test cases, but > before doing so I'd like to know whether the old reports are really > lost or have survived in some form. > > Best, > lmj > > ------------------------------------------------------------------------------ > _______________________________________________ > Ecls-list mailing list > Ecls-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

3 11

More detailed embedding example
by Morgan Howe 28 Sep '15

28 Sep '15

Hey guys, I'm playing around with embedding ECL into a C program. I've followed the blog post which was very useful, but as far as calling lisp functions, didn't really get beyond the cl_safe_eval type operations. I'd like to be able to get a handle to a specific lisp function, and call that function passing some arguments. What I've tried is basically this series of steps (omitting boot, shutdown, etc for brevity): * cl_safe_eval some code doing (load "foo.lisp") // From the blog example, works fine * ecl_make_symbol("BAR", "CL-USER") // Quite sure this is where I'm going wrong * cl_funcall the symbol from step 2, which gives me this a few times before dropping to debugger: Condition of type: SIMPLE-ERROR 0 is an illegal frs index. No restarts available. I'm sure step 2 is where I'm going wrong and the symbol I try to retrieve is not valid, thus the issue in step 3. Sorry if this is too basic a question, but could someone give me a working example of doing something like this? Thanks, Morgan

2 2

cross compiling howto for mips-openwrt-linux
by Attila Lendvai 24 Sep '15

24 Sep '15

hi! with the invaluable help of jackdaniel on #ecl, i've managed to cross compile ecl for mips-openwrt-linux. unfortunately i cannot edit the wiki at, so i'll write it up here. (if anyone reads it an can give me rights, my user is attila.lendvai) FTR, https://gitlab.com/embeddable-common-lisp/ecl/wikis/home the bird's eye view: - first you need to compile ecl on the host, but making sure that some important variables are the same as on the target (e.g. 32/64 bit; long long support; what else?). - then make clean, and configure the source tree for the target - ./configure will fail when run for the first time. you'll then need to edit 'build/cross_config' to set some variables regarding the target that cannot be detected automatically from the host. - then build it once again using a cross-compiling gcc - if you are not planning to have a gcc on the target, then configure the target with --with-bytecmp=builtin --with-cmp=no compile for the host: - you may need 32 bit support: sudo apt-get install gcc-multilib - CFLAGS=-m32 LDFLAGS=-m32 ABI=32 ./configure --prefix=/opt/ecl-host --enable-longdouble=no - make -j2 - make install compile for the target: make clean export STAGING_DIR=/home/alendvai/workspace/OpenWrt-SDK-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64/staging_dir export TOOLCHAIN=${STAGING_DIR}/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/ export TARGETROOT=${STAGING_DIR}/target-mips_34kc_uClibc-0.9.33.2/ PATH=/opt/ecl-host/bin/:${TOOLCHAIN}/bin:${PATH} \ CFLAGS="-I${TOOLCHAIN}/include -I${TARGETROOT}/usr/include" \ LDFLAGS="--sysroot=${TARGETROOT}" ./configure \ --prefix=/opt/ecl-mips --disable-longdouble \ --with-libffi-prefix=${TARGETROOT} \ --host=mips-openwrt-linux --with-system-gmp optionally add: --with-bytecmp=builtin --with-cmp=no edit 'build/cross_config' and restart the above once again. (in this specific case i had to ECL_BIGENDIAN=yes) PATH=/opt/ecl-host/bin/:${TOOLCHAIN}/bin:${PATH} make -j2 copy /opt/ecl-mips to your openwrt and don't forget to: opkg install libgmp opkg install libffi i will try to put together an openwrt package, too. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “People get used to anything. The less you think about your oppression, the more your tolerance for it grows. After a while, people just think oppression is the normal state of things. But to become free, you have to be acutely aware of being a slave.” — Assata Shakur (1947–), 'Assata: An Autobiography'

1 0

[C99][Question]
by Daniel Kochmański 22 Sep '15

22 Sep '15

Dear all, I've got a question - does anyone really depend on a non-C99 compliant compiler? MSVC supports C99 from 2013 [1], GCC has complete support from 4.5 [2] (with various bits earlier), TCC also has everything except complex numbers [3] (what is on their TODO) and Clang has complete support [4]. I'm asking this question because we're considering making C99-supporting compiler as a dependency for ECL C backend. This will relieve us from writing backward-compatible workarounds for the older standard and will simplify the code. That also means, that various improvements will be possible and code will be easier to maintain. Best regards, Daniel [1] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-vi… [2] https://gcc.gnu.org/c99status.html [3] http://repo.or.cz/w/tinycc.git/blob/HEAD:/TODO [4] http://clang.llvm.org/docs/UsersManual.html#id43 -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

3 2

Safely calling lisp lambda function from C?
by bruce li 08 Sep '15

08 Sep '15

Hi, I'm writing a wrapper for a game engine that involves a few callbacks. I wrap the callback in a C function so that I can pass in lambdas as callbacks. Here is how the code looks like: cl_object callback_wrapper(cl_object lambda, cl_object ...) { cl_funcall(2, lambda, some_params); } It works OK if the passed in lambda function is syntactically correct. But it fails disastrously if the function contains errors, either syntactically or logically and it crashes the program. I wonder if it's possible to call the lambda function in a safer manner and when anything is wrong, it just drops to the top-level? A second question is... can I traverse lisp lists in C? I would like to collect everything into a C++ vector and pass that on to the engine's API. Thanks, Bruce

2 1

email list subject line
by Daniel Herring 05 Sep '15

05 Sep '15

Hi all, The old mailing list had a "[Ecls-list]" prefix in the subject line. This was helpful for visually scanning a mailbox and could also be used for filter rules. The new list has no such prefix. Could someone add it? I don't care the exact format -- [Ecls-list], [ECL], whatever. I would just appreciate the addition. Thanks, Daniel

3 2

[floats][infinity][C99]
by Daniel Kochmański 04 Sep '15

04 Sep '15

Hello, I'm little in doubt. Problem is related to ieee-floating-point extensions, which provide infinities and nan. Everything works fine until we generate C code, which simply breaks, because it isn't taken into account. There are two possible solutions: - for these cases use constant expressions, which trigger an error on some compilers, that is (0.0 / 0.0) for nan, (1.0 / 0.0) for infinity - use defined by C99 macros: INFINITY and NAN, which will work on any compiler supporting C99. Using the latter is clean and elegant, but raises requirements of ECL for C backend. Regarding compilers, C99 is considered complete since GCC 4.5 (and partly complete in previous versions), while MSVC implemented them with VS2013 (however ECL runs with bytecmp, so if no additional package using infinities is added during buildtime, there should be no problem with using previous versions). I'm writing to ML to ask your opionions - should we use these macros? Best regards, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

2 6

Swank server dies with any error in REPL
by bruce li 04 Sep '15

04 Sep '15

Hi, there, I'm pretty new to ECL. I'm currently considering embedding ECL in a game engine. When I interactively interrupt the program and drop into the repl, I load up swank with quicklisp and create swank server with (swank:create-server :port 4005). I can connect to it from SLIME. But any error in the statement, either by deliberately typing sth wrong, will cause swank server to close instead of dropping into the debugging environment. I have no idea why this happens. It turns out that if I start swank on a different thread with mp:process-run-function, it goes well. But since the game engine is based on OpenGL, multithreading rendering isn't an option. I wonder if there is any way to get around the swank server and enable its debugger when it encounters error. Thanks, Bruce

4 5