From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Wed, 29 Jun 2022 17:35:28 +0800 Message-ID: <87zghvke1r.fsf@localhost> References: <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> <838rpi8cpu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2650"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 29 11:39:37 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 1o6UAa-0000RA-Nv for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 11:39:36 +0200 Original-Received: from localhost ([::1]:43258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6UAZ-00063l-KQ for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jun 2022 05:39:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6U5a-0006e6-81 for emacs-devel@gnu.org; Wed, 29 Jun 2022 05:34:26 -0400 Original-Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:36422) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o6U5Y-0000gB-50; Wed, 29 Jun 2022 05:34:25 -0400 Original-Received: by mail-pf1-x433.google.com with SMTP id x138so11883594pfc.3; Wed, 29 Jun 2022 02:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=kvuE70xPlp9ETapiI9iYZbnGVigYSqIKf9r7BeNITXQ=; b=APp/DooEtaZlTqkdCWfsH2CMBo8kNlyEtPQrca2noE7f2WILa7SfFQHBawsWaZrqr2 sHEdmyGrdTG0gYDk8RPL1KwAeE+0ScYTH4Kh3SHy5NWlvO6iLHPwsYWw8MoSih1n7umS uveUrvQole0qR1fsk+TpAO2arGGXvqkqrBEtYqmc6yIEL9K5w/JU3bpldNpEIdNM1qo8 hmp4G0/IxJNRZ1NmgHoMwLqkhuX6tJg/YUdrkdYHJXtnnn8XpTicNsZ+y5hqwk4c8JbG fD3+Ouduj84P+ZywKSZZPuWiczzEHUkkFhg6tjAWGmOQ3eqxY9yIMgqpG+M9XqFG9Ccu KtwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=kvuE70xPlp9ETapiI9iYZbnGVigYSqIKf9r7BeNITXQ=; b=iPlrNrBsUR7xRr3r7HkoM6C4kjaFGM/+5vbY9ynFlVhDm50w9oE527kEmgsXDpO9aX h/tqTe4ztI0L5bXIiiJ8gKOqUf4C7gNOiWw6EAkiP+5v4mITdBEjfuXksy2E0sKcTtyY aa97j6myH6+Chu2EGIXIaDf7Usu2ws4KgDa+c9/8WlhmL2xKJRgiGA+DmmBSgB94MoNH chg2kI8jKQUbT0RGFvUrxPJnH7tEhHaHEEcu9N2MBbLiiqFZB2uhexVWOGXhwjPu3s7b IWLTLE9bIjQhzZtc02wmqpva7BjPJmWtq6lfnSwxa3lKBMb0y1hbXbipO6u8S1HPV305 +S8Q== X-Gm-Message-State: AJIora9mFvR7EeKFZ4opRcRvRgHq8gYCVT8Vu0f/ljLdPjS8Ut5RRJj2 BPw3f72vOxKaM0I1JU3B/NjH08B0eyv8TeWc X-Google-Smtp-Source: AGRyM1veBvdph3zT3PbMkl1+/H1xRsPLsTgM66wpEs6S6D43zSExcAML4Rv4KjvWE7qQ1JkD7gyUDw== X-Received: by 2002:a63:35c4:0:b0:40c:99f6:8889 with SMTP id c187-20020a6335c4000000b0040c99f68889mr2152277pga.387.1656495261483; Wed, 29 Jun 2022 02:34:21 -0700 (PDT) Original-Received: from localhost ([155.94.207.39]) by smtp.gmail.com with ESMTPSA id d21-20020a17090abf9500b001ec9b7efec2sm1605352pjs.5.2022.06.29.02.34.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 02:34:20 -0700 (PDT) In-Reply-To: <838rpi8cpu.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::433; envelope-from=yantar92@gmail.com; helo=mail-pf1-x433.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:291710 Archived-At: 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. I am trying to challenge your statement that thread display is bad in mailing list web frontends. I fail to believe that the problem with year crossing is impossible to solve. So, I suggested that a newer Mailman frontend might not have the described problem. Can we use it in lists.gnu.org instead of the older web interface? >> 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. My initial suggestion was bi-directional linking between the commit messages and the relevant ML discussions. There is already a convention to link from commit messages to debbugs, but it would be useful to have the backlinks from debbugs/ML to the relevant commits. Via commit hash or possibly via direct savannah link (whatever is more permanent). I do not think that there is any way to have the commits directly in debbugs. (Or am I wrong?) >> > 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? ralloc.c and pdumper where the keywords used both in the commits and in the threads. And there were significant number of matching messages in the threads. >> 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? The total time I spent replying to your email was 42 minutes (recorded). Out of those 42 minutes I subjectively spent 10-15 minutes trying to answer "Would you mind walking me though using that when trying to answer the above question about sbrk?". Not more than 25 minutes max. >> > 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. You are right. I mostly had to deal with people who do not have write access. As for automatic checks for all the committers, what about git pre-push hooks (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)? If one can write make commit_check target, it can be configured to run before pushing to Emacs upstream. Best, Ihor