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". 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! Thanks, Dennis [1] https://www.spectrumcollaborationchallenge.com/ [2] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/100 Daniel Kochmański <dan...@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
