From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in Date: Sun, 14 Apr 2019 00:08:34 -0400 Message-ID: References: <20190409224339.20116.87667@vcs0.savannah.gnu.org> <20190409224342.0DA1F20E54@vcs0.savannah.gnu.org> <86697de6baf024290a9d0b10743ba2b7.squirrel@dancol.org> <9093e1cb-7cad-14df-9428-6229313e8f51@cs.ucla.edu> <7bd7a4577abcebd089c7aecc253718f2.squirrel@dancol.org> <0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org> <064a6c19-760d-a2b6-8f9c-8f7972557b65@cs.ucla.edu> <597d5c5a-f8c1-3b69-006d-6e3da4b1124d@cs.ucla.edu> <838swel7lt.fsf@gnu.org> <6bbfa27e-390d-6680-7fe5-d7b97f29318a@dancol.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="40281"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 14 06:08:44 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 1hFWRf-000ANz-IE for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 06:08:43 +0200 Original-Received: from localhost ([127.0.0.1]:59136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFWRe-0005tO-F9 for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 00:08:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFWRY-0005tJ-I1 for emacs-devel@gnu.org; Sun, 14 Apr 2019 00:08:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hFWRX-0006ZO-Q2 for emacs-devel@gnu.org; Sun, 14 Apr 2019 00:08:36 -0400 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:55738) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1hFWRX-0006Yt-IY for emacs-devel@gnu.org; Sun, 14 Apr 2019 00:08:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2E7JADXsLJc//zyd0tmHgEGBwaBZYIRa?= =?us-ascii?q?FEhEiiHWGiESYotAYIMEyIBgXsBmBEQG4EWgzYEAgKFdiQ4EwEDAQEBCQEBAQE?= =?us-ascii?q?CAgJpHAyEL18+AQQBViMFCwsOJhIUGA0kgzaBeQ+sCoN1hjKBMothgX+EIz6KJ?= =?us-ascii?q?QOmMgmCB4YJjCiBeG2IbIkinDaDZwyBZiKBVjMaCDCDJwmCUIV2iBkmMJByAQE?= X-IPAS-Result: =?us-ascii?q?A2E7JADXsLJc//zyd0tmHgEGBwaBZYIRaFEhEiiHWGiESYo?= =?us-ascii?q?tAYIMEyIBgXsBmBEQG4EWgzYEAgKFdiQ4EwEDAQEBCQEBAQECAgJpHAyEL18+A?= =?us-ascii?q?QQBViMFCwsOJhIUGA0kgzaBeQ+sCoN1hjKBMothgX+EIz6KJQOmMgmCB4YJjCi?= =?us-ascii?q?BeG2IbIkinDaDZwyBZiKBVjMaCDCDJwmCUIV2iBkmMJByAQE?= X-IronPort-AV: E=Sophos;i="5.60,347,1549947600"; d="scan'208";a="90245631" Original-Received: from 75-119-242-252.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.242.252]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2019 00:08:34 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 2D7B9AE526; Sun, 14 Apr 2019 00:08:34 -0400 (EDT) In-Reply-To: <6bbfa27e-390d-6680-7fe5-d7b97f29318a@dancol.org> (Daniel Colascione's message of "Sat, 13 Apr 2019 20:43:00 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 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:235427 Archived-At: > Implementing the rewrite-in-place idea would make us both happy, > wouldn't it? Could be, yes. I was thinking that if we use an initial fingerprint value that's sufficiently unique, we could just look for this special value and replace it without knowing "anything" about the executable file format. Another approach might be to generate the fingerprint on-the-fly at run time (i.e. everytime a snapshot is dumped or loaded). Not sure if that can be made cheap enough easily enough, tho. Stefan