Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Pip Cet <pipcet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

On Fri, Nov 24, 2017 at 8:07 AM, Paul Eggert <eggert@cs.ucla.edu> 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.

[-- Attachment #2: 0001-Use-NULL-for-NULL-rather-than-false.patch --]
[-- Type: text/x-patch, Size: 878 bytes --]

From eac5f78117b07c76eb725a4653b5d8f70382c165 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Fri, 24 Nov 2017 08:33:22 +0000
Subject: [PATCH] Use NULL for NULL rather than false.

---
 src/xdisp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xdisp.c b/src/xdisp.c
index 016e7044caf..7e47c06c2d7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31872,7 +31872,7 @@ x_draw_bottom_divider (struct window *w)
       int x1 = WINDOW_RIGHT_EDGE_X (w);
       int y0 = WINDOW_BOTTOM_EDGE_Y (w) - WINDOW_BOTTOM_DIVIDER_WIDTH (w);
       int y1 = WINDOW_BOTTOM_EDGE_Y (w);
-      struct window *p = !NILP (w->parent) ? XWINDOW (w->parent) : false;
+      struct window *p = !NILP (w->parent) ? XWINDOW (w->parent) : NULL;
 
       /* If W is vertically combined and has a sibling below, don't draw
 	 over any right divider.  */
-- 
2.15.0.rc2