On Fri, Nov 24, 2017 at 8:07 AM, Paul Eggert wrote: > Wow Thank you. > sounds like you've done some interesting things, and it's interesting > to see that you got it to work at all with a copying collector. "At all" being about the limit of it, at present. While I managed to write that email without a segfault, there are plenty of race conditions that I'm aware of. I think we're fine in theory, though, once we make sure that signal handlers cannot trigger GC. (If my understanding is correct, signals can occur after every instruction, including in the middle of a call sequence while the argument, or return value, is unprotected). >> I do advocate making the >> official Emacs compile with G++ with the -fpermissive option, to help >> further experiments. > > What changes would this entail? If you're already running Emacs through a > C-to-C++ converter, why can't the converter arrange for the changes itself? You're right, I should be clearer on this point: I want to help out others who decide not to use my converter, not myself. One thing that current stable versions of g++ are missing is structured initializers, and I decided to convert the few instances we have of those by hand rather than write code to do it. I think, but I'm not sure, that the current development version of g++ will correctly deal with those, though. Another thing is nested structs/enums/unions. I think those are bad style in addition to presenting a portability concern, even though they're easy to catch for the converter. The most vexing issue for me right now is that I haven't figured out how to get gnulib working with g++ without modifying files after every sh autogen.sh, though. I admit I don't understand the gnulib build process at all, so any hints would be appreciated. The other issues are minor (a union and a typedef sharing a name, C++ keywords, enums treated as ints), but overall it seems a potential deterrent to people who want to just try linking a C++ library to Emacs as an experiment, without using my converter. >> - dumping (I'm currently using CANNOT_DUMP=yes. Is that supposed to >> work? Because it doesn't without a few changes to the initial Lisp >> files.) > It is supposed to work. Admittedly it's not tested much. We really need to > move away from the current dumping model anyway, so CANNOT_DUMP mode will > grow in importance (in some sense). I'll open a bug for the CANNOT_DUMP issue. While I've got a fairly good overview regarding the C code, now, I don't understand the Lisp bootstrapping process, which appears to be the issue... What do you think about the future of pure space? That also seems to me to be an optimization that might no longer be worth it, and perhaps to add even more complexity to the code than dumping does. >> [1] - there's one place that uses "false" for "NULL" > > Please let us know where, and we'll fix it. Patch attached.