What is the best version of ECL to use right now?

Daniel Kochmański daniel at turtleware.eu
Wed Jun 5 06:02:58 UTC 2019


On Tue, 04 Jun 2019 20:22:48 -0400
Dennis Ogbe <do at ogbe.net> wrote:

> Hello Daniel,
> 
> thanks for your reply, that's about what I expected. It's not a secret at all---My team and I (a bunch of graduate students) are building an "intelligent" radio network using software-defined radios. The source is not opened--yet--since we are competing as part of a DARPA Grand Challenge [1].
> 
> While I have you here: I am currently fighting a strange bug that crashes my process. I am still in the phase where its occurrences seem random to me, so I can't tell you how to reproduce it, but the crashes seem localized to the if statement in fill_spec_vector in src/c/gfun.d--the call to cl_class_of() crashes with an unrecoverable error "not a lisp object".

what is the object you call cl_class_of on? are you sure it is initialized cl_object? you may try attaching gdb to the process (see src/utils/gdbinit for useful configuration).
> 
> Since I've seen merge requests like [2] I wanted to try to disable threading, since I won't be using it. But when I compile ecl with
> 
> ./configure --enable-shared --enable-threads=no --enable-boehm=included --with-dffi --enable-debug=yes
> 
> I now crash in cl_boot in a GC function (GC_push_all_eager)! Is building without threads supposed to work or am I trying the wrong thing here? My original problem (the crash in fill_spec_vector) only happens about 1/500 times I call the offending function (it's the store function from cl-store), and I am still investigating what the culprit could be. If you have any thoughts--I'd appreciate it!

I've used recently ECL with threads disabled and all seemed to work. I would try playing with flags (i.e first allow use autodetected boehm, then skip the with-dffi flag if it still doesn't work, then remove enable-shared and at last enabl-edebug). If ./configure --disable-threads without any additions still crashes then it is indeed problem with this exactly flag.
> 
> Thanks,
> Dennis

Regards,
Daniel
> 
> [1] https://www.spectrumcollaborationchallenge.com/
> [2] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/100
> 
> Daniel Kochmański <daniel at turtleware.eu> writes:
> 
> > Hello Dennis,
> >
> > On Mon, 2019-06-03 at 20:02 -0400, Dennis Ogbe wrote:
> >> 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.
> >
> > Yes, 16.1.3 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.
> >
> > That is also true, we work on the next release and we expect to make
> > the new one soon™ (only a few tasks has been left over to implement).
> >>
> >> 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.
> >
> > There is no good answer for that. While develop branch indeed has many
> > improvements in form of bug fixes and new (dare I say – exciting)
> > features it is only loosely tested. Before each release we work hard to
> > test the release candidate against a big variety of operating systems,
> > architectures and libraries (cl-test-grid is an invaluable help with
> > that) and try to fix regressions. If you feel adventurous just pick
> > develop branch, we do not commit there half-baked things (only stuff
> > which we are certain about or which was a subject of a peer review /
> > testing around the thing being changed) - it is fairly stable. But
> > there is no guarantee that you won't hit some ugly regression we are
> > not aware of yet. Otherwise you may try to live with 16.1.3 until we
> > release the new 16.2.0 version – hopefully withing a few months from
> > now.
> >>
> >> Thanks for all the hard work, this project is great!
> >
> > That's very kind of you to say that. If it is not a secret what are you
> > working on?
> >>
> >> [1] https://gitlab.com/embeddable-common-lisp/ecl/issues/418
> >>
> >
> > Best regards,
> > Daniel


-- 
Daniel Kochmański <daniel at turtleware.eu>



More information about the ecl-devel mailing list