From: Pip Cet <pipcet@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Fri, 24 Nov 2017 16:23:02 +0000 [thread overview]
Message-ID: <CAOqdjBcXC+QH722jDi8u=c55_J3F9BA+VrbG=vXc5nFYqkDb+A@mail.gmail.com> (raw)
In-Reply-To: <6f96617b-2c9a-2a2c-d39e-779f275c9bb8@cs.ucla.edu>
[-- 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
next prev parent reply other threads:[~2017-11-24 16:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 19:01 [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Pip Cet
2017-11-24 8:07 ` Paul Eggert
2017-11-24 16:23 ` Pip Cet [this message]
2017-11-24 18:20 ` Paul Eggert
2017-11-24 23:27 ` Pip Cet
2017-11-25 0:21 ` Paul Eggert
2017-11-25 23:50 ` Pip Cet
2017-11-24 22:13 ` Stefan Monnier
2017-11-24 23:05 ` Pip Cet
2017-11-25 4:15 ` Stefan Monnier
2017-11-25 23:50 ` Pip Cet
2017-11-26 1:20 ` Stefan Monnier
2017-11-26 4:20 ` Paul Eggert
2017-11-26 5:11 ` Stefan Monnier
2017-11-26 10:27 ` martin rudalics
[not found] ` <jwva7z9rgqh.fsf-monnier+Inbox@gnu.org>
[not found] ` <9d7be625-85ae-54d5-3897-6f701c8ea124@cs.ucla.edu>
[not found] ` <jwvo9npprfw.fsf-monnier+emacs@gnu.org>
2017-12-01 1:03 ` Steve Fink
[not found] <CAOqdjBe98BpWE- Ey8fPY1DmfCiLYnB06d30Xqf_KMm_muvKbDg@mail.gmail.com>
2017-12-01 17:57 ` Steve Fink
2017-12-03 0:37 ` Pip Cet
2017-12-03 5:24 ` Steve Fink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOqdjBcXC+QH722jDi8u=c55_J3F9BA+VrbG=vXc5nFYqkDb+A@mail.gmail.com' \
--to=pipcet@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).