From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: More over-engineering Date: Fri, 27 Nov 2015 18:37:20 +0100 Message-ID: <878u5jz6lr.fsf@fencepost.gnu.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448645850 18201 80.91.229.3 (27 Nov 2015 17:37:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 17:37:30 +0000 (UTC) Cc: Stefan Monnier , Emacs development discussions To: =?iso-8859-1?Q?Aur=E9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 27 18:37:27 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a2MxX-00057V-RU for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 18:37:23 +0100 Original-Received: from localhost ([::1]:57890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Mxa-0002Tq-Et for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 12:37:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2MxX-0002SG-Ss for emacs-devel@gnu.org; Fri, 27 Nov 2015 12:37:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2MxX-0003jC-0d for emacs-devel@gnu.org; Fri, 27 Nov 2015 12:37:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43214) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2MxV-0003in-E4; Fri, 27 Nov 2015 12:37:21 -0500 Original-Received: from localhost ([127.0.0.1]:57033 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1a2MxU-0003VH-Va; Fri, 27 Nov 2015 12:37:21 -0500 Original-Received: by lola (Postfix, from userid 1000) id 9538CDF8B5; Fri, 27 Nov 2015 18:37:20 +0100 (CET) In-Reply-To: (=?iso-8859-1?Q?=22Aur=E9lien?= Aptel"'s message of "Fri, 27 Nov 2015 18:12:30 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195394 Archived-At: Aur=E9lien Aptel writes: > On Fri, Nov 27, 2015 at 6:00 PM, Stefan Monnier > wrote: >> Are we really allocating a structure for every Lisp_Object value we pass >> through the modules API? Why do that? > > Look at the old thread for Philip's arguments. As far as I'm > concerned, we need an indirect pointer to support wide-int > Lisp_Objects on 32bit platforms. Global reference can still be made > with the current code. We have a reference counting hash-table to keep > track of them. Non-global refs are marked explicitely in case the GC > misses them. If the same modules cannot be used at the same time for wide-int and normal int Emacs compilations (can they?), then it would seem that module code could become significantly simpler when declaring wide-int and module support mutually exclusive. --=20 David Kastrup