Anand, I've been using guile, straight from git for maybe almost 2 years(??) in a semi-harsh environment (lots of threads, lots of C++ smob jiggery-pokery, entering and exiting guile, redirecting ports, using fluids at the scheme/c++ boundary, catching and throwing exceptions to/from C++, interleaving all this with python, too, -- and medium cpu burn over many days/week) and it seems to work fine. Try it -- fix a tag, run system test, I bet it will work for you. I think Ludo and Andy have done a good job. The only recent glitch is that the setvbuf API changed. An old quasi-issue is that garbage collection seems to not be aggressive enough. After several layers of C calling guile calling C and so on, mem usage seems to bloat (a lot -- many many GB's) unless I forcibly run GC every 50th time I re-enter guile. But I think it does that in guile-2.0 too. --linas On Wed, Jun 22, 2016 at 10:43 AM, Anand Mohanadoss wrote: > Hi Andy, > > Thanks a lot for looking into this and your response! Any idea when we > will have a stable 2.2 release that we can move to given that 2.1 has been > out for a few months. > > Thanks, > Anand > > On Wed, Jun 22, 2016 at 8:25 PM, Andy Wingo wrote: > >> Hi :) >> >> On Mon 15 Dec 2014 07:36, Anand Mohanadoss writes: >> >> > Here is what we changed in hashtab.c - >> > >> > 130a131 >> >> size_t orig_len = len; >> > 137,138c138,144 >> > < assert (removed <= len); >> > < len -= removed; >> > --- >> >> if (removed <= len) >> >> len -= removed; >> >> else >> >> { >> >> printf ("Vacuum weak hash table assert Table=%p len=%zi removed=%zi >> > orig_len=%zi n_items=%zi\n", table, len, removed, orig_len, >> > SCM_HASHTABLE_N_ITEMS (table)); >> >> len = 0; >> >> } >> > >> > With this change, we got lines similar to the following printed >> > periodically - >> > >> > Vacuum weak hash table assert Table=0x9bdb840 len=0 removed=1 >> > orig_len=2321 n_items=2321 >> >> I guess printing a warning is not worse than crashing. I was unable to >> make this table work in a reliable way in 2.0 without rewriting it, so >> in 2.2 there's a new implementation with hopefully no bug in this >> regard. >> >> Ludovic what do you thing, should we just be sloppy in 2.0 and remove >> the assertion? I don't think it's fixable. The other option I see is >> to close as WONTFIX. >> >> Andy >> > >