From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Date: Fri, 24 Nov 2017 10:20:45 -0800 Organization: UCLA Computer Science Department Message-ID: References: <6f96617b-2c9a-2a2c-d39e-779f275c9bb8@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511547697 4876 195.159.176.226 (24 Nov 2017 18:21:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Nov 2017 18:21:37 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 24 19:21:33 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIIbU-0000sM-2m for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 19:21:32 +0100 Original-Received: from localhost ([::1]:50639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIIbb-0000rF-1h for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 13:21:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIIav-0000rA-QA for emacs-devel@gnu.org; Fri, 24 Nov 2017 13:20:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIIar-0005To-Js for emacs-devel@gnu.org; Fri, 24 Nov 2017 13:20:57 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41912) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eIIar-0005SM-Ds for emacs-devel@gnu.org; Fri, 24 Nov 2017 13:20:53 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BA4D116118F; Fri, 24 Nov 2017 10:20:50 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id imb0Px_Mdz1s; Fri, 24 Nov 2017 10:20:50 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F14A916119D; Fri, 24 Nov 2017 10:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8_zagKKeU4Lt; Fri, 24 Nov 2017 10:20:49 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D15D61610BA; Fri, 24 Nov 2017 10:20:49 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220436 Archived-At: Pip Cet wrote: > If my understanding is correct, signals can occur after every instructi= on, > 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=20 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 Gnuli= b=20 interface (sorry! :-) and so can perhaps be of help here. What sort of=20 modifications are needed after autogen.sh? Perhaps we can lessen and/or=20 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 m= erges.=20 Of the three, enums treated as ints seems like it'd be the most hassle, a= s enums=20 are the only way that C has to name small ints that can be used where an = integer=20 constant expression can be used. I'd hate to have to cast these names to = int=20 every time I used them, just to pacify C++. Perhaps the enum-to-int busin= ess=20 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.