ecl-devel

ecl-devel@common-lisp.net

1 participants
232 discussions

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

how do you build the embed example
by blackthirt33n 28 May '18

28 May '18

How do you build the embed example "ecl-16.1.3\examples\embed" with the visual studio 2017 tools? I have no problem compiling running the Makefile in the msvc directory but the files up level are problematic. James

1 0

defstruct :predicate failure
by Peter Keller 09 May '18

09 May '18

Hello, I ran into a situation where I think ECL 16.1.3 has a bug in it: Linux violet > ecl ;;; Loading "/home/psilord/quicklisp/setup.lisp" ;;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas" ECL (Embeddable Common-Lisp) 16.1.3 (git:UNKNOWN) Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2000 Juan J. Garcia-Ripoll Copyright (C) 2016 Daniel Kochmanski ECL is free software, and you are welcome to redistribute it under certain conditions; see file 'Copyright' for details. Type :h for Help. Top level in: #<process TOP-LEVEL>. > (defstruct (foo (:type vector) (:predicate nil)) qux bar) Condition of type: SIMPLE-ERROR NIL is an illegal structure predicate. Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (SI:TOP-LEVEL T)] In: #<process TOP-LEVEL>. >> The clhs spec says: http://www.lispworks.com/documentation/lw70/CLHS/Body/m_defstr.htm most notably: ":predicate This option takes one argument, which specifies the name of the type predicate. If the argument is not supplied or if the option itself is not supplied, the name of the predicate is made by concatenating the name of the structure to the string "-P", interning the name in whatever package is current at the time defstruct is expanded. If the argument is provided and is nil, no predicate is defined. A predicate can be defined only if the structure is named; if :type is supplied and :named is not supplied, then :predicate must either be unsupplied or have the value nil. " In this case, :type is supplied, :named is not supplied, and therefore :predicate must either be unsupplied or have the value NIL. In my case, it has the value NIL. It appears to me that I have written legal CL, but ECL doesn't think so. Thank you! -pete

3 4

ASDF 3.3.2 released
by Robert Goldman 04 May '18

04 May '18

Dear Lisp implementors and maintainers, Today we release ASDF 3.3.2, the second bugfix release for the 3.3 release series. Of primary interest in this release are 1. Multiple fixes in handling misnamed (or "legacy-named," if you prefer) secondary systems ("foo-test" instead of "foo/test"). Thanks to Eric Timmons, there is also a similar fix for package-inferred-systems. 2. Fix an annoying warning message for compute-action-stamp. 3. Add support for the Mezzano implementation (thanks to E. Housel, H. Harrington). 4. Miscellaneous minor fixes and documentation tweaks. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.2 at their earliest convenience. Immense thanks, as always, to Fare Rideau. Also thanks to the many bug reporters and patch submitters (see the Changelog), and to Anton Vodonosov and Dave Cooper for help with testing. Here is the changelog entry for 3.3.2: cl-asdf (2:3.3.2-1) unstable; urgency=low Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Add package location information to define-package on SBCL. * Upgrade: fix issue with asdf/bundle. * Portability: add support for Mezzano (thanks to E. Housel, H. Harrington) * Documentation: add discussion of best practices. * Package-inferred system: Improve source file handling. * Test and documentation improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Thu, 03 May 2018 22:46:19 -0400

1 0

[Final CfPart] ELS 2018, April 16-17, Marbella, Spain
by Didier Verna 08 Apr '18

08 Apr '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 In cooperation with: ACM SIGPLAN Sponsored by RavenPack, Brunner Software GmbH, Franz Inc., LispWorks Ltd., and EPITA http://www.european-lisp-symposium.org/ Recent news: - ELS 2018 is in cooperation with ACM SIGPLAN - Full program now available on the website - Still one week to register! 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. Keynote speakers: - Vsevolod Domkin -- Lisp in a Startup: the Good, the Bad, and the Ugly - R. Matthew Emerson -- This Old Lisp (a look at Clozure CL) Important dates: - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program USA Ernst van Waning, Infometrics.nl, Netherlands Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northeastern University USA Philipp Marek, Austria Robert Strandh, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[CfPart] European Lisp Symposium 2018, 16-17 April, Marbella, Spain
by Didier Verna 14 Mar '18

14 Mar '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH, Franz Inc., LispWorks Ltd., and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 25 deadline for the early bird discount! 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. Keynote speakers: - Vsevolod Domkin -- Lisp in a Startup: the Good, the Bad, and the Ugly - R. Matthew Emerson -- This Old Lisp (a look at Clozure CL) Important dates: - 25 Mar 2018 Early registration deadline - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northeastern University USA Philipp Marek, Austria Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

ecl-devel