From: Paul Eggert <eggert@cs.ucla.edu>
To: Pip Cet <pipcet@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Fri, 24 Nov 2017 10:20:45 -0800 [thread overview]
Message-ID: <e3706b2d-7289-dba5-382a-8ce276ace94b@cs.ucla.edu> (raw)
In-Reply-To: <CAOqdjBcXC+QH722jDi8u=c55_J3F9BA+VrbG=vXc5nFYqkDb+A@mail.gmail.com>
Pip Cet wrote:
> 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).
Yes, that's right.
> 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.
It should be OK to fix these, on style grounds. I assume the changes are
relatively minor.
> 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.
Emacs has a special way of using Gnulib, unfortunately. I wrote the Gnulib
interface (sorry! :-) and so can perhaps be of help here. What sort of
modifications are needed after autogen.sh? Perhaps we can lessen and/or
eliminate the need for them.
> The other issues are minor (a union and a typedef sharing a name, C++
> keywords, enums treated as ints),
If you would submit patches to fix these, that might help you in future merges.
Of the three, enums treated as ints seems like it'd be the most hassle, as enums
are the only way that C has to name small ints that can be used where an integer
constant expression can be used. I'd hate to have to cast these names to int
every time I used them, just to pacify C++. Perhaps the enum-to-int business
could be handled by the C-to-C++ translator instead.
> 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.
I tend to agree that pure space is no longer worth the hassle.
>>> [1] - there's one place that uses "false" for "NULL"
> Patch attached.
Thanks, I installed that in your name in the master branch.
next prev parent reply other threads:[~2017-11-24 18:20 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
2017-11-24 18:20 ` Paul Eggert [this message]
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=e3706b2d-7289-dba5-382a-8ce276ace94b@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=pipcet@gmail.com \
/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).