From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 29 Mar 2018 13:35:05 +0000 Message-ID: References: <1775923222.898447.1518559575706@mail.libero.it> <277032065.898859.1518560883271@mail.libero.it> <1901861254.379742.1519646632018@mail.libero.it> <546679939.469612.1522307541367@mail.libero.it> <3b0dd2cd-fd15-c017-7249-7ae2fa567556@dancol.org> <87zi2rqkzi.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522330473 19509 195.159.176.226 (29 Mar 2018 13:34:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 13:34:33 +0000 (UTC) Cc: Daniel Colascione , Angelo Graziosi To: emacs-devel@gnu.org, rpluim@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 29 15:34:28 2018 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 1f1XhE-0004ym-Gl for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 15:34:28 +0200 Original-Received: from localhost ([::1]:53308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1XjH-0003KS-Pv for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 09:36:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1XiX-0003KF-Ak for emacs-devel@gnu.org; Thu, 29 Mar 2018 09:35:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1XiW-00086P-4w for emacs-devel@gnu.org; Thu, 29 Mar 2018 09:35:49 -0400 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:54762) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1XiV-000820-T7 for emacs-devel@gnu.org; Thu, 29 Mar 2018 09:35:48 -0400 Original-Received: by mail-wm0-x231.google.com with SMTP id h76so10887341wme.4 for ; Thu, 29 Mar 2018 06:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9YqtUnkHeJaO5tqmcyxmujpcIwlqrMDGViqa1ADGLQA=; b=DaZgmD2MiXtCfqoucn5jmmR0ozuPFNTu9lbojuaNKZU70xrxgUv9sFhdgMq8A/O4zQ RSQIjs003FYXJjc8g6b1OqBbcFGQSr7/PHFg0dXDQ+0zBXf3bzYU5lTitwDSzsaVvNTe +X4JD+y1ykgtRaDmIaoCx8XCM9ApjDLyPC+hj5M/2/MUKSo0Thvnx83xkQ8wDhGcJd50 Ozr3mJoUXvFoZjQuRyUC47plLZoVwSal+0xxHUGrVhbclBqBGmnBWGeFQQOglE4/10XX u/XzIEsPpM51RC8JjW34TM8hxonX7eLQsOwp/8M4ihryjgzXQYGHK8T+ylnKwJ8knC0D iECQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9YqtUnkHeJaO5tqmcyxmujpcIwlqrMDGViqa1ADGLQA=; b=flS0lszXXqrUoTeLtWKu9dkViy1t1/TTK2hTKfk6WgzzcDQFvIJ27dBupworpqaQ1o Z8Lhc91UXJ23cgPU3ggOPsj+AmMi516wajN25/2PONzbPSY87iVIS/xcA+qkDGUXlyas XTkxnSJwIv9G75ArTKQ55FEt7k94Fcu/utR/cT1dvRsUx/aZC0HUPbjYm48PReQ0nviI LuNU6eQf1iia65yzeFj1vMtcWwRnxTBwSQVQ/boXR4rtR7GdvZQg3VHVKyz9/EsATWPr q6gwqGNNONKzdxj+dLQt5hpuY2wAEuO4inGiSWA1lP7DQxXSEuRq/DTaTBVDMb7pVe1W RZpg== X-Gm-Message-State: AElRT7FW9SyNAmoPP1OEGGeeiwMqIMZZpzaNq0NBACoF5jf6Wne12IEi AmIJ8PR2skF2sHx7INjaUkrAGTyLm/nZxiXzIj13fA== X-Google-Smtp-Source: AIpwx4/2SpY67H7MvaKtlPamqWifeBEKRhUYeOMzwMhUXO0x1DMdjzWdIDeTv31rVmV0AM0zJNs1Wo4FwlSIlCJimcA= X-Received: by 10.80.151.151 with SMTP id e23mr7286361edb.51.1522330546429; Thu, 29 Mar 2018 06:35:46 -0700 (PDT) Original-Received: by 10.80.129.230 with HTTP; Thu, 29 Mar 2018 06:35:05 -0700 (PDT) In-Reply-To: <87zi2rqkzi.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::231 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:224155 Archived-At: I've just skimmed the diff, and I think the change is a significant improvement, and will help with my GC experiments even though I'm probably never going to be able to use the portable dumper. Some minor comments: it is not clear to me why some staticpro's are moved to happen after the initialisation of the variable and some aren't. Maybe we should change staticpro to have a void staticpro(Lisp_Object *ptr, Lisp_Object initial_value); signature and save some lines of code? I don't understand this hunk in sysdep.c: @@ -2138,7 +2149,7 @@ init_signals (bool dumping) #ifdef SIGUSR2 add_user_signal (SIGUSR2, "sigusr2"); #endif - sigaction (SIGABRT, &thread_fatal_action, 0); + //sigaction (SIGABRT, &thread_fatal_action, 0); #ifdef SIGPRE sigaction (SIGPRE, &thread_fatal_action, 0); #endif Similarly, this hunk in pcase.el: @@ -63,6 +63,7 @@ ;; FIXME: Now that macroexpansion is also performed when loading an interp= reted ;; file, this is not a real problem any more. (defconst pcase--memoize (make-hash-table :weakness 'key :test 'eq)) +;; (defconst pcase--memoize (make-hash-table :test 'eq)) ;; (defconst pcase--memoize-1 (make-hash-table :test 'eq)) ;; (defconst pcase--memoize-2 (make-hash-table :weakness 'key :test 'equal= )) Are those two intentional? I would vaguely prefer if "pdumper" names were limited to the actual pdumper implementation, and "dumper" names were used instead in code that does not depend on the implementation of the dumper. So we'd have dumper_object_p(), defined to false if there's no dumper, and pdumper_object_p otherwise. This would make things slightly easier for (a) competing implementations (b) abusing the DUMPER_* machinery for GC experiments (c) possibly extending pdumper to combine several images rather than use a single one. It would also help avoid _impl names. I think it's worth mentioning that staticpro is now required for variables that used to be safe: this change comes at the price of a tiny performance hit because of the additional GC roots, but it's worth it, IMHO. Apart from that, there appear to be no disadvantages for people who prefer to continue using unexec. Is that correct? On Thu, Mar 29, 2018 at 9:39 AM, Robert Pluim wrote: > Daniel Colascione writes: > >> On 03/29/2018 12:12 AM, Angelo Graziosi wrote: >>> >>> They are 4 weeks that pdumper branch is not synchronized, should we con= tinue to test it? >>> >>> During this time, builds of that branch have been tested on Windows, GN= U/Linux and macOS without showing any specific issue... >> >> I'm not sure what's left to test. It works. What's stopping a merge? > > I just test-merged it to master, with only two issues: > > 1. a merge conflict in src/nsfont.m as a result of 7ff62ed221c > 2. The Lisp_Buffer_Local_Value hash has changed, although it=CA=BCs not > clear to me why, since I only see comment changes in its definition. I > updated dmpstruct.h, and the build works fine (it runs gnus, as proven > by this message). > > Robert >