From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 12:36:54 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <721b8fb1-5672-778e-b68f-a68b53308f55@cs.ucla.edu> <83vav7xs1p.fsf@gnu.org> <83twarxq6f.fsf@gnu.org> <834m2qrux9.fsf@gnu.org> <83wpfmqcch.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480451874 12447 195.159.176.226 (29 Nov 2016 20:37:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 20:37:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 21:37:50 2016 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 1cBp9x-0002ZZ-UZ for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 21:37:50 +0100 Original-Received: from localhost ([::1]:39188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBpA1-0001Od-Oj for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 15:37:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBp9C-0001NF-AA for emacs-devel@gnu.org; Tue, 29 Nov 2016 15:37:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBp9B-0004P5-IQ for emacs-devel@gnu.org; Tue, 29 Nov 2016 15:37:02 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:55778) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBp9B-0004Ob-8d; Tue, 29 Nov 2016 15:37:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=qm5KubAkyxvDtRuNXZRz/Q3KzIGK207ANdgug6+DrnA=; b=AMVGkbPVWgc8i8ptLYY6iLWXNncT0LwOZL/Kmtrx9ngqNrBR9Z3yEmAxNmuy9jbCqmtUnXyxXCYpVu2sY5QEbCScFoIRsNoFq7lv1bHF5LSbCL+y19Ukb5rU5Z7zQ1wku1VxR6QCi6a8v1C66E7TQGyw9oEHzwLG41MerAt6KNcow8ctbXVEUYmGUS0KYRrQOTKpEQoMzucdi+lr6CZwrwK59end5Z5pOHRdSdezIZRqPw9XCpyxuPV4CvKzWGrbK3Iy7DfRGSkKxFwRWnVblMyuakKFF96LWenc/a6W+0DS0I19rZynTvsQEzDQxdtLtHrNuAkX4BalpGhoPIcPTA==; Original-Received: from [2620:0:1008:1101:a803:88c3:331:8b1] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cBp99-00048m-Pn; Tue, 29 Nov 2016 12:36:59 -0800 In-Reply-To: (John Wiegley's message of "Tue, 29 Nov 2016 12:29:57 -0800") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209764 Archived-At: On Tue, Nov 29 2016, John Wiegley wrote: >>>>>> Eli Zaretskii writes: > >>> Could we ask Daniel to include his code under an #ifdef, so until it's proven >>> we can always disable it, or back out the changes easily if need be? > >> What would that solve? Don't we still need to review the patches, compile >> the code once in a while, debug it as needed, etc.? > > It keeps the portable dumper fenced off. We'd compile it in by default, but it > helps future readers, for a while, by clearly demarcating when special > handling is needed for the sake of that dumper. FWIW, as a logistical matter, it's not really practical to literally #ifdef out the pdumper integration into the rest of Emacs. We can, however, make the pdumper constructs compile down to nothing if you opt not to enable pdumper in the build configuration. I specifically designed the pdumper.h API to make this arrangement easy and natural. As a matter of general taste, I _much_ prefer this style: #ifdef HAVE_FOO void foo_thing (void); #else # define foo_thing() ((void)0) #endif void function1() { ... foo_thing(); ... } void function2() { ... foo_thing(); ... } void function3() { ... foo_thing(); ... } to this style: void function1() { ... #ifdef HAVE_FOO foo_thing(); #endif ... } void function2() { ... #ifdef HAVE_FOO foo_thing(); #endif ... } void function3() { ... #ifdef HAVE_FOO foo_thing(); #endif ... } > >>> I'd like to entertain the experiment, if we can. > >> Fine, but why do you need me for that? What would be my role in that >> experiment? > > I guess just say OK at this point, and help with the review if you're > inclined? Daniel will handle the work of integration and documentation.