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: Mon, 27 Jun 2022 16:20:29 +0300 Message-ID: <838rpi8cpu.fsf@gnu.org> References: <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> <87pmizrgoi.fsf@localhost> <83zgi3espf.fsf@gnu.org> <87pmizajtv.fsf@localhost> <83y1xneqif.fsf@gnu.org> <87mte3ah08.fsf@localhost> <83r13felor.fsf@gnu.org> <878rplwcp0.fsf@localhost> <83tu89b7pr.fsf@gnu.org> <877d52pi3u.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15820"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 27 15:21:59 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 1o5ogf-0003qD-Op for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 15:21:57 +0200 Original-Received: from localhost ([::1]:35334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5oge-0003xh-AO for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Jun 2022 09:21:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5ofK-000330-AR for emacs-devel@gnu.org; Mon, 27 Jun 2022 09:20:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5ofI-00071O-Jn; Mon, 27 Jun 2022 09:20:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AqigFpfe8Mro7PxnCmblkFSXYGs10xmMEKunX1+GQPE=; b=LKn8TgEYsPdB klmJ+gQvVD4bGLgoDfgekZ2RuuICf5w7clX8fDHmxnqWqXjwO6o4CzXxagfpJ9IGI7BvsoRk6PqPX MF9PlxiXNnx3F72zYRcMemM5HzMLbkIcCV2hpkOEMhkQwsFF8lo6CZV328LvhESjuWV3XqTtBg9+K /2JkD7vpyby1wtXnJ+7KmWvpox2WpDvs08UpAeFZ4QNT/0xKSEZfEWuK0B1000yI04r0zKSGf71tj r8L+yE0QchQI57kL9K93gDOkmo7KgNB4N862jRWZ3/e7jiyKA2rf/rV/5SQTo4+xtuGonemx/qGog N0p6uwKhBzI1H+bjvwS13w==; Original-Received: from [87.69.77.57] (port=2820 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 1o5ofE-00026z-HL; Mon, 27 Jun 2022 09:20:30 -0400 In-Reply-To: <877d52pi3u.fsf@localhost> (message from Ihor Radchenko on Mon, 27 Jun 2022 17:32:05 +0800) 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:291659 Archived-At: > From: Ihor Radchenko > Cc: owinebar@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca, > mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, > emacs-devel@gnu.org > Date: Mon, 27 Jun 2022 17:32:05 +0800 > > Eli Zaretskii writes: > > >> Then it raises a bigger question. Do we have anything better than email > >> archives to archive emacs-devel? > > > > I don't know of any. > > What about Mailman 3 frontends like Hyperkitty? > https://wiki.archlinux.org/title/Hyperkitty#Xapian_search_backend Not sure what that means in practice. Do you mean I should install that locally? Or what else? You asked, above, do we have a better way of archiving a mailing list, and the solution you propose seems to be yet another way of keeping email archives? I must be missing something. > >> Note that I can also ask "what if we change debbugs?". Would it mean > >> that we should not link to bug#? > > > > The bug number gives you a quick way of reaching the bug discussion in > > the email archives of bug-gnu-emacs, and in debbugs itself. These > > will remain available even if we switch away from debbugs as our issue > > tracker. So the bug number is definitely a good thing to have in the > > logs. > > Will the commit hash not be available e.g. on savannah? Do you intend to > remove the git history alltogether during the switch? No, but I don't want to look in more than one repository, either. > >> > And in any case, the trigger for this discussion was the situation > >> > where you want to answer questions like "why did Emacs stop using sbrk > >> > on GNU/Linux", in which case there's no commit ID to search for. > >> > >> I implied using git log search to identify the relevant commits. > > > > That doesn't work well IME. Would you mind walking me though using > > that when trying to answer the above question about sbrk? > > 1. I listed all the commits that mentioned sbrk in the messages using > git log, displaying the statistics. (actually, I used Magit) > 2. I noticed that some of the commits changed large number of lines and > removed sbrk-related staff. In particular, d12e5d003d Add portable > dumper > 3. I searched https://yhetil.org/emacs-devel/?q=linux+sbrk and noticed > two candidate threads: Re: When should ralloc.c be used?; and Re: > Dumper issue, revisited; invalid realloc/free; How did you decide that these threads are relevant? > 4. Looking through the threads; it appears that the pdumper thread had a > lot of occurrences of sbrk word: > https://yhetil.org/emacs-devel/?q=%22sbrk%22 > 5. I skimmed through the thread and possibly found relevant message > root: > https://yhetil.org/emacs-devel/20140625212421.GD179@brightrain.aerifal.cx/ How much time did this take you? > It would have been even easier if I had an idea what sbrk does and where > its Linux support is supposed to be in the code. sbrk is a system call, so I guess by "its Linux support" you mean where we used to use it Emacs? The answer to that is not always easy to find in practice, unless you happen to know. > > As a matter of fact, I have hard time making sure each commit that has > > a bug number mentions that number in the commit log message. > > On Org side, I do not find tracking such things too difficult. Probably > due to lesser volume of commits. What do you mean by "tracking"? By "making sure" I meant the job of having people who have write access mention the bug number. Detecting they missed after the commit is pushed is too late. > Note that things like double space, or even bug number checks could be > automated. For example, one can write a make target that checks recent > commit messages to follow specific rules. Commit log messages in Git are immutable, so looking up such problems post-factum is not really useful. But that is a tangent; the main point here is that we have quite a few good practices and conventions in place, but have problems living up to them. So any procedure that relies too heavily on these conventions and practices will not be too successful, unless what it relies on is completely automated.