From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken. Date: Wed, 10 Apr 2019 13:11:05 -0700 Message-ID: <52731970482b0b4d53b89d8f187bcc2a.squirrel@dancol.org> References: <20190228202146.GC4686@ACM> <20190228205955.GD4686@ACM> <20190410162203.GA4009@ACM> <20190410194525.GB4009@ACM> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="235146"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Paul Eggert , Daniel Colascione , emacs-devel@gnu.org To: "Alan Mackenzie" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 10 22:11:49 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 1hEJZS-000yzC-Qb for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 22:11:47 +0200 Original-Received: from localhost ([127.0.0.1]:37220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEJZR-0004K9-MC for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 16:11:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEJYs-0004Ix-15 for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:11:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEJYr-0007D4-0K for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:11:10 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39070) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEJYq-0007AK-6i for emacs-devel@gnu.org; Wed, 10 Apr 2019 16:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=jwx1wFEjS2s6L7MDJ9wGQEwlsnf6PMvR+b/lmQtuMW4=; b=jowLF7qtAb+XfvS1kqxbYRt4r7UzSQzDVJHcFDUYLsdOIs5xN4/g97U7Y9NVGeF24u04nD+5YN/UtiapZoT+g/nMC39FYKEXY+Dt+xzwR1GK6lbtfspawjOK26zTV+VXveY+wQqW+MomepuR7PExWfLGGTQ8IV6HAcCp25uoQF6Awc0sr3jVqQnTdvQct0xjhQ0SPY5VRJT/Zru+gvIltm0rhJr+mf9A8SAKjq40s8Xwq5jEvUosG13Aim6nqQ3pBf1vm9Jn6UWu+ttVzhO2IJy09zlLALx6ZqKwuE0ClXzBQKk+/a9RpUenwYg82RH9+mc0yPXHZX4C1xiCLUVFAw==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEJYn-0006JT-F1; Wed, 10 Apr 2019 13:11:05 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Wed, 10 Apr 2019 13:11:05 -0700 In-Reply-To: <20190410194525.GB4009@ACM> X-Priority: 3 (Normal) Importance: Normal 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:235253 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. What would make the hashes easier to deal with? Some make target for updating them automatically? An easier way to disable the check at configure time? Transformation into a prominent runtime warning instead of a build break?