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

(ARRAY DOUBLE-FLOAT (*)) is not a valid type specifier.
by Gunter Königsmann 13 Nov '18

13 Nov '18

Dear all, Just for interest/since you provided me with excellent help the last time even if I only had a vague problem description: Maxima, an open-source computer Algebra system comes with an optional lapack package that was generated from the original fortran source using a fortran-2-lisp utility. The Lapack package runs fine on gcl, clisp, ccl, allegro cl and - if sbcl is given enough memory to be able to compile it - on sbcl, too. On ECL it compiles just fine. But trying to actually use it results in (ARRAY DOUBLE-FLOAT (*)) is not a valid type specifier. Do you again have a magic idea on what we are doing wrong? The sourcecode of our lapack implementation would be here: https://sourceforge.net/p/maxima/code/ci/master/tree/share/lapack/ ...but it is quite a beast and - as it doesn't count as a "minimal example" I wouldn't expect you to look into it if the problem isn't clear from the error message. My hope is that we somehow need to make an alias for some variable type and everything starts working. Thanks in advance, and kind regards, Gunter.

2 2

[CfP] 12th European Lisp Symposium, April 1-2 2019, Genova, Italy
by Didier Verna 31 Oct '18

31 Oct '18

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/2019/ 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 and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: tba Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

defsystem+ecl question
by Gunter Königsmann 29 Oct '18

29 Oct '18

Dear all, I am currently trying to make maxima, a computer algebra system written in lisp, support out-of-tree builds: - The contents of the source tarball is kept in a directory and left completely unmodified and - all files generated during the build are kept in a potentially different directory. Since 2 of the lisp files containing (defparameter) commands are generated by the build scripts - the build process is started in the directory the output will end up in - an (mk:add-registry-location "$(top_srcdir)/src/") informs defsystem where to find the source tree and - in maxima.system all files that are in the build tree instead are marked as private-file: (:module final :source-pathname "" ;; These are not compiled, for whatever reason #-ecl :load-only #-ecl t :components ((:file "autol") (:file "max_ext") :private-file "share-subdirs") (:file "init-cl"))))) This seems to work fine in sbcl, clisp, ecl, openmcl, gcl and cmucl. And with ECL maxima seems to build fine, as well. But when I start a maxima that was compiled with ECL it generates a runtime error that the variables share-subdirs defines are not bound. I am no defsystem expert, neither a lisp expert so I expect to have done something obviously wrong. But as it works in all other lisps I've tried I hope ecl-devel is the right place to ask at. Thanks a lot, and kind regards, Gunter.

2 4

Build ecl on windows with open-source toolchain
by Hans-Peter Wickern 12 Oct '18

12 Oct '18

Hello, I am new to ecl and this list. I want to build ecl to run on Windows XP up to 10. I want to use a gcc-toolchain. Can I use http://tdm-gcc.tdragon.net/ ? Has someone used gcc on Windows to build ecl? A step by step Todo doku would be nice. Regards Hans-Peter

1 0

Oddities in ECL tests on Linux
by Robert Goldman 12 Sep '18

12 Sep '18

My Jenkins job is failing to test ECL successfully. What's interesting is that it looks like the tests are successful, but the checker is failing. Here's what I see in the transcript: These two expressions fail comparison with EQUAL: (UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ") '("hello, world") evaluates to ("hello, world") Oddly, when I try to run this at the command line, ECL throws to the interactive debugger on various signals and I have to restart it, before make test l=ecl will terminate successfully. I think I have seen this before, and it may be that ECL implicitly assumes that there will be some kind of C compilation tool chain present that I don't have, but I'm not sure about that. Suggestions for debugging would be welcom.

3 11

Loading "lparallel" hangs
by Robert Larice 06 Sep '18

06 Sep '18

Hello, can you provide me some hints for the following problem ? I've compiled ecl from git on a debian stretch machine. Then I've tried to compile the "qt" example, which did hang when loading "lparallel" So I started "ecl" from a shell, and did execute (ql:quickload :lparallel) which presents me: > To load "lparallel": > Load 1 ASDF system: > lparallel > ; Loading "lparallel" then the process fell silent. "top" doesn't show "ecl" to consume cpu cycles. Its waiting for something and doesn't proceed. Regards, Robert Larice

2 8

Re: Oddities in ECL tests on Linux
by Robert Goldman 02 Sep '18

02 Sep '18

On 31 Aug 2018, at 10:35, Marius Gerbershagen wrote: > This is most likely a bug in ECL. I recommend trying out a newer > version > of ecl (16.1.3 or the current develop branch from the git repository). I see your point, but have two comments: 1. If this really *is* an ECL bug, then shouldn't the Ubuntu package be updated and fixed? ASDF is supposed to work on the ECL that users will have, not only on the one that developers have. 2. I don't see a way to get a new ECL except by pulling from Gitlab and building. I do not have the time to run around building all available lisp implementations from source (and, again, ASDF should work on the versions of the implementations that users actually have, which means the ones provided by the packaging systems on the platforms). I build only SBCL, because that's an implementation I build anyway, for my work needs. Faré had the energy to play with all the different implementations in a substantial way, but I do not. So if the released version of an implementation is broken, I will simply regard that implementation as broken. If the *released version* of an implementation is broken for long enough (I'm looking at you, clisp), it will become unsupported by ASDF. Unsupported means "patches will be accepted, but I will no longer run the tests, and test failure on an unsupported implementation will not be a reason to hold up an ASDF release." Note that at the moment *all* implementations are essentially unsupported on Windows, since I have lost my Windows VM, and even if I got it back, I would have no way to develop on Windows. If you are a Windows user and this bothers you, I would be happy to support you in setting up a test environment, and even more happy to help you learn to patch ASDF. But even someone who doesn't want to patch ASDF, but who would be willing to run the test suite (or help figure out how it could be run through, e.g., Travis), would be a great help. > > Am 30.08.2018 um 21:51 schrieb Robert Goldman: >> I'm experimenting with your changes now but, for some reason that I >> don't understand, when I run the tests as |make l=ecl| interactively >> on >> Ubuntu (using the Ubuntu ECL package |16.1.2-3|), signals are >> throwing >> me into the interactive debugger, instead of being caught. I have no >> idea why this started happening, because I used to be able to run ECL >> successfully, and I don't believe I have changed the package >> (although >> Ubuntu might have upgraded it). >> >> Actually /usr/bin/ecl is crashing with SIGABRT when running programs, >> apparently, on my Ubuntu box. (|SIGABRT in si_run_program()|). I'll >> try >> uninstalling and reinstalling ECL in the hopes that fixes this, but >> unless I get some help, I will not be able to continue testing ASDF >> on >> ECL on Linux. >> >> On 30 Aug 2018, at 13:22, Marius Gerbershagen wrote: >> >> No, I don't think so. The sockets module has been part of ECL >> since >> version 0.9f from 2005. Please note, that this test can fail >> anyway if >> ECL is built without support for the respective module (be it :rt >> or >> :sockets). The change only prevents it from failing on a default >> build >> configuration. >> >> Am 30.08.2018 um 19:53 schrieb Robert Goldman: >> >> Thank you very much for these, Marius. I will look into >> fixing them >> directly. One question - do I need to check for ECL version >> number when >> requiring sockets in the test? I.e., to I need to test with >> |:rt| in >> older versions and |:sockets| in newer? Or will |:sockets| >> work >> in older >> versions of ECL, as well? >> >> Best, >> R >> >> On 30 Aug 2018, at 12:46, Marius Gerbershagen wrote: >> >> Harmless in the sense that ECL doesn't crash or throw me in >> the >> interactive debugger. Besides, the test failures seem to be >> easily >> fixed. The test-require.script test fails because it tries to >> require >> the :rt module which is deprecated on the develop branch and >> no >> longer >> build by default. A simple fix is to use the :sockets module >> instead: >> >> diff --git a/test/test-require.script >> b/test/test-require.script >> index e5f70857..1ef84e8c 100644 >> --- a/test/test-require.script >> +++ b/test/test-require.script >> @@ -178,7 +178,7 @@ >> #+allegro :sax >> #+clisp (first (remove "asdf" *dynmod-list* :test 'equal)) >> #+(or clozure cmucl) :defsystem >> - #+ecl :rt ;; loads faster than :ecl-quicklisp >> + #+ecl :sockets >> #+lispworks "comm" >> #+mkcl :walker >> #+sbcl :sb-md5 >> >> The test-program.script test seems to fail to include uiop >> because of an >> error in the linkable-system function. Tracing it shows that >> the >> function returns nil for the uiop system object, >> 1> (ASDF/BUNDLE::LINKABLE-SYSTEM #<system "uiop">) >> <1 (ASDF/BUNDLE::LINKABLE-SYSTEM NIL) >> which seems to be caused by a missing call to coerce-name: >> >> diff --git a/bundle.lisp b/bundle.lisp >> index 2ff56f93..42034c9f 100644 >> --- a/bundle.lisp >> +++ b/bundle.lisp >> @@ -529,7 +529,7 @@ which is probably not what you want; you >> probably >> need to tweak your output tran >> ;; If an ASDF upgrade is available from source, but not a >> UIOP >> upgrade to that, >> ;; then use the asdf/driver system instead of >> ;; the UIOP that was disabled by check-not-old-asdf-system. >> - (if-let (s (and (equal x "uiop") (output-files 'lib-op >> "asdf") >> (find-system "asdf/driver"))) >> + (if-let (s (and (equal (coerce-name x) "uiop") >> (output-files >> 'lib-op "asdf") (find-system "asdf/driver"))) >> (and (output-files 'lib-op s) s)) >> ;; If there was no source upgrade, look for modules provided >> by >> the implementation. >> (if-let (p (system-module-pathname (coerce-name x))) >> >> >> Am 29.08.2018 um 01:22 schrieb Faré: >> >> I can't reproduce this, for me the tests run fine without >> being thrown >> in the debugger. I only get two harmlessly looking test >> failures >> (test-program.script and test-require.script). >> >> No test failure is harmless. The test-program.script failure >> is what >> Robert saw, that I can reproduce. I didn't reproduce a >> failure with >> test-require. I had more problems with ECL from the develop >> branch, >> but maybe it was a bad idea to use the develop branch. >> >> —♯ƒ • François-René ÐVB Rideau >> •Reflection&Cybernethics• >> http://fare.tunes.org >> There are two kinds of people, those who do the work >> and those who take the credit. Try to be in the first group; >> there is less competition there >> — Indira Gandhi. >>

2 4

I don't seem to receive emails to the list by François-René Rideau
by Spiros Bousbouras 30 Aug '18

30 Aug '18

When I look at https://mailman.common-lisp.net/pipermail/ecl-devel/2018-August/thread.html I see 3 posts by him all in the thread "Oddities in ECL tests on Linux" .I haven't received any of them (they're not in spam either). Before this month last time he posted on the list was on 2016-12-27 with Message-ID: <CAN7nBXcjskn=J3oRJTBJVt1mJBY+DKVs-hFjOtTHtB0aoenp6w(a)mail.gmail.com> and I received that one (and previous emails by him). So the question is whether anyone else has the same problem. Spiros Bousbouras

1 0

Re: Using a cl_object in Lisp
by Stewart M. 30 Jul '18

30 Jul '18

Hello Marius, This was very helpful, thank you! > Hi Stewart, > > cl_object's are declared as :object type in ECL's ffi, so > > (ffi:def-function "getObject" ((lo :pointer-void)) :returning :object) > (ffi:def-function "setObject" ((lo :pointer-void) (clo :object))) > > should work. CFFI does not support this as far as i know. > Hope that helps, > Marius Gerbershagen -- Stewart Milberger Kavalogic, Inc.

1 0

Using a cl_object in Lisp
by Stewart M. 29 Jul '18

29 Jul '18

I am using CFFI with ECL to interface to a C++ library, which has a C++ class with a data member of type 'cl_object'. Simplified, my C++ code is: class LispObject { public: cl_object object; }; extern "C" cl_object getObject(LispObject* lo) { return lo->object; } extern "C" void setObject(LispObject* lo, cl_object clo) { lo->object = clo; } The full code is: https://common-lisp.net/viewvc/clive/trunk/src/extensions/corral/CliveCorra… Can I somehow declare the 'cl_object' type for the 'getValue()' and 'setValue()' functions using CFFI 'defcfun' to get and set ECL objects? Is there a technique using the lower-level FFI? I am looking for a way to do this without compiling C code embedded in Lisp, which I am aware ECL can do. Thank you for any ideas! -- Stewart Milberger Kavalogic, Inc.

2 3