From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken. Date: Wed, 10 Apr 2019 19:45:25 +0000 Message-ID: <20190410194525.GB4009@ACM> References: <20190228202146.GC4686@ACM> <20190228205955.GD4686@ACM> <20190410162203.GA4009@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="126228"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Daniel Colascione , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 10 21:46:16 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEJAl-000WiL-J5 for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 21:46:15 +0200 Original-Received: from localhost ([127.0.0.1]:36984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEJAk-0005Um-3E for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 15:46:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEJA7-0005Uf-TE for emacs-devel@gnu.org; Wed, 10 Apr 2019 15:45:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEJA5-0005gX-Te for emacs-devel@gnu.org; Wed, 10 Apr 2019 15:45:35 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:50684 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hEJA5-0005g1-HJ for emacs-devel@gnu.org; Wed, 10 Apr 2019 15:45:33 -0400 Original-Received: (qmail 69619 invoked by uid 3782); 10 Apr 2019 19:45:28 -0000 Original-Received: from acm.muc.de (p4FE15EEB.dip0.t-ipconnect.de [79.225.94.235]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 10 Apr 2019 21:45:26 +0200 Original-Received: (qmail 31153 invoked by uid 1000); 10 Apr 2019 19:45:25 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:235251 Archived-At: Hello, Paul. On Wed, Apr 10, 2019 at 11:05:02 -0700, Paul Eggert wrote: > On 4/10/19 9:22 AM, Alan Mackenzie wrote: > > All that was needed to disable it was a single line change to set > > CHECK_STRUCTS to zero. > That would also have sufficed, but the code clutter (and slowdown in the > build due to the computation of hashes which forces that part of the > build to be sequential) was also annoying. If you really want it we can > bring back the mechanism (with CHECK_STRUCTS off by default please!), > though I'd rather not - see below. According to Daniel (and my experience backs it up), the problems CHECK_STRUCTS detects happen when merging master into a branch. I'm not sure you do such merges much. But if you are making frequent changes to the structures guarded by the mechanism, having deleted that mechanism, you are saving effort for yourself, but imposing extra effort on other people. > > it was of use to me recently when it reminded me to > > amend dump_subr after extending struct subr. > I didn't observe that in master - presumably this was in some > experimental branch? In master, dump_subr is currently the same as it > was when the pdumper was installed. Naturally. I don't change basic structures in master without (usually extensive) discussion on emacs-devel. The changes were in branch scratch/accurate-warning-pos. The hashes were helpful in making these changes. > Before making the recent change, I reviewed all the changes made to > pdumper.c in master, and observed none where the hashes helped and > several where they hurt. Since the portable dumper was added I have made > four commits that involved the hashes, and the hashes only got into my > way and slowed me down. The hashes do slow us down, yes. But not really by very much, IMAO. For example I timed make dmpstruct.h, and it only took 0.16s. The extra time taken in a build can't be more than a very small number of seconds. Having a build aborted by CHECK_STRUCTS, and having manually to change the hashes in pdumper.c is what takes the time. But really, how often are we changing those structures of an evening? > You made one commit (9c0fa1172fd987a8f23b115145270383a11c12fc) that > involved the buffer.h hash, and portions of that commit were > mistakenly pushed in pdumper.c's previous commit so the hashes didn't > seem to have helped there. That was actually Eli's commit. > The only other persons to make hash-related commits to pdumper.c were > Alan and Stefan, and the hashes didn't help there either. I think the hashes are a hindrance when developing on master, but a help on branches (when merging from master). > As the hashes get in the way of ordinary development (mostly affecting > me) and don't seem to help in practice, I really want them to go. I think I would prefer the hashes to stay, but I can see the other side of the argument, too. -- Alan Mackenzie (Nuremberg, Germany).