Re: [PATCH21.5] Asynchronous finalization revised and merge of MC_ALLOC and NEW_GC

Marcus> I see no need to have MC_ALLOC and NEW_GC separated any Marcus> longer. And the merge makes my life easier: Especially Marcus> for this patch, I would have needed another ton of #ifdefs Marcus> to get things right for all possible configurations. I guess this is OK with me. The only thing is that USE_KKCC by itself doesn't seem to enforce Lisp-ification of structs containing Lisp_Objects. But that seems pretty desirable to me, especially after my adventure into the syntax cache last week. It would be nice if we had a tag that (somewhat) corresponded to that. Will NEW_GC play the same role? BTW, are there any real downsides to Lisp-ification of such structs? Marcus> By the way, I do not touch USE_KKCC. It will remain a Marcus> separate flag and will remain enabled as default. OK. Marcus> Since this patch only touches NEW_GC stuff, I'll commit it Marcus> tomorrow. I'd like to release a checkpoint beta before you commit this. I'll start on that later tonight my time. Once you see the r21-5-25 tag on version.sh in CVS, it's OK to commit. (I thought abouut just tagging and making a branch if necessary, but that doesn't quite work the release heralds won't get into the ChangeLogs in the right places.) Once the beta is out, maybe we can consider enabling NEW_GC by default for a couple of weeks. I really don't see why people who are explicitly selecting the bleeding edge shouldn't bleed a little. :-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.