From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: noverlay branch Date: Wed, 28 Sep 2022 19:09:20 -0400 Message-ID: References: <87bkr1e6yb.fsf@rfc20.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="17392"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Matt Armstrong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 29 01:10:17 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 1odgC1-0004K9-1y for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Sep 2022 01:10:17 +0200 Original-Received: from localhost ([::1]:33892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odgC0-0002xy-2Y for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 19:10:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odgBH-0002FR-Iu for emacs-devel@gnu.org; Wed, 28 Sep 2022 19:09:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21924) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odgBA-0007Ms-Ou for emacs-devel@gnu.org; Wed, 28 Sep 2022 19:09:30 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 10BA5100130; Wed, 28 Sep 2022 19:09:23 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 829711000F8; Wed, 28 Sep 2022 19:09:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1664406561; bh=cjUzNuWRy3fyNeif86y51vkqnlg9d0iboJo/MdCHS2I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WoJXrU6isqS4bqYpm4OucFr5o5/in7amYYwpj5FGGrXymSaYycurwZ7syGv0lsK2D vCSgfIL/1FFvAhEQe6p3u2SPoeHp8jU8ITp3wXwUMZ4valbywhfzWzTltTcyLZAe9v 4KzngT+WyIiTVnCG7UY1Rl2savvZIVlOhkQ/4fZQBeWP6JoisysFlpBZTJp/4Et5XN +pFo+O/hnDW5sSrup2UqzTEM8qxaPE+b2CiE/1jgg+J1iXKXdnQv8Z2Ivn2U0BNfzd NORlVojZs/Rj+VqmhSI9dkr7kH460xn6wn4A0xs0OAmJGkbwLhb5IM1TKpoLeV9ZoV J8CuN+J+EGFLw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6A8E4120909; Wed, 28 Sep 2022 19:09:21 -0400 (EDT) In-Reply-To: <87bkr1e6yb.fsf@rfc20.org> (Matt Armstrong's message of "Mon, 26 Sep 2022 22:12:44 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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:296427 Archived-At: > 3) Improve quality of comments in the new code. Personally, I find the > algorithms quite subtle and quite a bit more complex than what you > find on, say, https://en.wikipedia.org/wiki/Interval_tree or the > Cormen et al. Introduction to Algorithms Book. I think I pieced > most of it together but it took a lot of effort. At top of mind is > looking at the interval_node.visited flag and figure out how that > flag is used, then describe the algorithm in detail. It isn't clear > to me how that flag gets set/cleared. Best case: doing so proves me > wrong on point (1). I can explain the `visited` bit (and I added a comment about it in the code). What I'm less clear about is the use of the `null` sentinel node. It seems that this node is sometimes modified (e.g. its color changed from black to red or vice versa, and maybe also its `parent` field), even though it's pointed to from lots of different nodes, so any help documenting the way it works (or why the value in those fields doesn't matter) would be welcome. Stefan