On Tue, 04 Jun 2019 20:22:48 -0400 Dennis Ogbe do@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@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