From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Thu, 23 Jun 2022 21:37:32 +0300 Message-ID: <83y1xncjkj.fsf@gnu.org> References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> <83k098kg6c.fsf@gnu.org> <8335fvg8kz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11318"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 23 20:38:28 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o4Ril-0002gN-Si for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 20:38:28 +0200 Original-Received: from localhost ([::1]:40330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4Rik-0006vu-Ag for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 14:38:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Ri4-0006DG-9M for emacs-devel@gnu.org; Thu, 23 Jun 2022 14:37:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47206) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Ri2-0004qR-Bv; Thu, 23 Jun 2022 14:37:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Pl997JoNj1vKtihL2X4aUIedpLpPQxqFbjSX8nSq3bg=; b=Up99SDCCxZDfFR0N6ETJ Sy48LIScFTMMVOaz8OWhF4CljqiIWgSDIGIJ7e3l2o61wfLEjenqARt4ebUHlLl+jqqcQ7WdFM3uE DGhBxs2Uc8+Gee/dZ1qj4RzzdXzsdw3xjiaES9Sp5dHpExuvrpb+pKrxZOKCU0I8AfrVn9Cnjs61e 3+IfmB1k/ciPrfgvuF6vfC9rO/WQ0xPKwBYyNF+Y/dPWBKK7R1F5ET1YnBR4DEu5j8kzS0dxeKLjq b4fa6Dwv8Ip+8jNnZiBrU3A0Vbd07NED+1IYnTJ2whjOGaNRz4huJ9WyUSbdimc3S14ZJKiwnCfga gLBbi983LS8j9g==; Original-Received: from [87.69.77.57] (port=1384 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Ri1-0002L0-Gn; Thu, 23 Jun 2022 14:37:41 -0400 In-Reply-To: (message from Lynn Winebarger on Thu, 23 Jun 2022 13:07:44 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291541 Archived-At: > From: Lynn Winebarger > Date: Thu, 23 Jun 2022 13:07:44 -0400 > Cc: Lars Ingebrigtsen , Stefan Monnier , > Ihor Radchenko , Mattias Engdegård , > Tim Cross , rms@gnu.org, Alan Mackenzie , > emacs-devel > > > We lack someone in the role of the "project historian", who would then > > summarize and publish the design discussions in the form of such > > notes. Volunteers are most welcome. > > > > It's not the discussion (or history) per se, but the factors that decided > the current > design choices. An example would be the #ifdef DOUG_LEA_MALLOC blocks in > lisp_align_malloc > of alloc.c that prevent allocating via mmap. So far what I've read > indicates > that step is there to enable dumping by unexec (assuming I've understood > correctly). > Ideally there would be a design note (possibly generated from comments, > possibly free standing) > that would explain what the purpose of the restriction is, so you could > tell if it's still > relevant, and any negative impacts it has. Also, if there are plans to > remove it at > some point, what (if any) the requirements/test for removing it would be, > etc. By "it", > I mean any hypothetical design point, not just this particular one. > Alternative designs could also be discussed along with the factors that led > to their rejection, if it was significant enough. > Now, those could be derived from mailing list discussions, but I wouldn't > consider them > "history". Per subsequent mails in this thread, if a developer or code > reviewer made > a practice of citing particular mail messages (or even other sources), some > extraction > process might even be automated, but then there would be the question of > copyright > assignment. What you describe is a full-time job, more or less. I'd love to have someone who'd volunteer to record all those points, but we don't have him/her yet. The only places where design is document are the large comments in some source files. > It would help if there were some taxonomy of features/design > points for > reference. Is the bug database being used for that? I don't think so (IIUC what you mean by that), and I don't really see how bugs could serve in that role. Most of the design changes and redesigns in Emacs were developed without any bug report, simply because those who did the job knew that a particular group of problems needs to be taken care of. > Actually, a good example (even though it's more post facto description than > prospective > design & cost-benefit tradeoff analysis) would be > https://github.com/rocky/elisp-bytecode > That is really useful documentation that would ideally be in the emacs docs > or etc directory. That's not design description, though. > I put in a request to assign@gnu.org a few days ago, but I have not > received any response yet. Please ping them and CC me and Lars.