From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: noverlay branch Date: Sat, 08 Oct 2022 16:33:52 -0700 Message-ID: <875ygt6gbj.fsf@rfc20.org> References: <87sfjzefvv.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3574"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 09 01:35:16 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 1ohJLg-0000hs-Hi for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Oct 2022 01:35:16 +0200 Original-Received: from localhost ([::1]:55178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohJLe-0001ZI-Mu for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Oct 2022 19:35:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohJKY-0000rj-32 for emacs-devel@gnu.org; Sat, 08 Oct 2022 19:34:06 -0400 Original-Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]:48463) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohJKU-0005M9-8f for emacs-devel@gnu.org; Sat, 08 Oct 2022 19:34:05 -0400 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id BB2911BF206; Sat, 8 Oct 2022 23:33:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1665272038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fSFI0R2Ju2xf41q84XgGwZyXEiluvK0kCokQgkaXJuo=; b=K2s8OwGO+EVpMe43eIXxhyaqQ7ee5ehmd6d8X2mP4GHmbUNe5PeT1VmDkXnToHTRL68lpd l9w6OIbpfgSRZ96qyaeWlOuaOZAAVoTYtnDD4IjptJZNignhZd3sPSe0AxigxBvU3fwYzR wD5uEj4BJKGi6OjeGoBE0VkMr9Sg44bsPOdD7/S0wDKUYUdznzSCRZ48hlAfCCbnN+wSmj 8smBXJLe56gZ8eSllSrVWezBUHc84Dr26t49Z4Lyh1KR+E8YAH9Id4ENH8UVa4Jur4OFeI nJZsVlf848G9gmNEq6d72GX0N8y6O5uWnQZzaheuSA+Rxq3wgn1z4xYAxaMEiw== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1ohJKK-0058uw-21; Sat, 08 Oct 2022 16:33:52 -0700 In-Reply-To: Received-SPF: pass client-ip=2001:4b98:dc4:8::228; envelope-from=matt@rfc20.org; helo=relay8-d.mail.gandi.net X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:297229 Archived-At: --=-=-= Content-Type: text/plain Stefan Monnier writes: > Matt Armstrong [2022-10-07 09:51:32] wrote: >> Stefan Monnier writes: >>> I just updated the noverlay branch to the code in `master` (most of it >>> was mechanical except for the fact that since the last commit on that >>> branch we have gotten rid of Lisp_Misc and we moved to pdumper). >>> >>> I'm getting ready to install this in `master`, so I'd encourage people >>> to try this code as much as possible to try and weed out the most >>> glaring problems before it hits master. >> >> Stefan (and others), where are we at with this? Are there things that >> must happen before a merge? > > I'm mainly waiting to hear feedback (including my own) about "I use it > with no visible problem". I like that criteria. :) >> Is anybody able to use the noverlay branch for daily work? > > I do. > >> I'm running the noverlay branch now and was observing an eassume >> failure. > > Do you have the file&line number at least? Not the specific eassert because...reasons. Long story short: I can debug eassert failures now, but not then. In any case, I do have a new test for tests/src/buffer-tests.el that crashes feature/noverlay Emacs immediately, when ENABLE_CHECKING is on, in a spot in itree.c having to do with offset inheritance. Two patches, also on https://git.sr.ht/~matta/emacs/log/feature/noverlay as before. I'll work on fixing the crash next, but wanted to get the test in because it takes an...interesting approach...that may require discussion. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Comment-change-explain-inheriting-dirty-offsets.patch >From 87204feaa4f50744701481f3aa051483647cf9da Mon Sep 17 00:00:00 2001 From: Matt Armstrong Date: Sat, 8 Oct 2022 09:15:26 -0700 Subject: [PATCH 1/2] Comment change: explain inheriting "dirty" offsets ; * src/itree.c (interval_generator_next): explain why the code handles inheriting offsets from dirty nodes. --- src/itree.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/itree.c b/src/itree.c index de16af5b0c..1fc711b021 100644 --- a/src/itree.c +++ b/src/itree.c @@ -1086,9 +1086,17 @@ interval_tree_inherit_offset (uintmax_t otick, struct interval_node *node) node->right->offset += node->offset; node->offset = 0; } - /* FIXME: I wonder when/why this condition can be false, and more generally - why we'd want to propagate offsets that may not be fully up-to-date. */ - if (node->parent == ITREE_NULL || node->parent->otick == otick) + /* FIXME: I wonder when/why this condition can be false, and more + generally why we'd want to propagate offsets that may not be + fully up-to-date. --stef + + Offsets can be inherited from dirty nodes (with out of date + otick) during insert and remove. Offsets aren't inherited + downward from the root for these operations so rotations are + performed on potentially "dirty" nodes. We could fix this by + always inheriting offsets downward from the root for every insert + and remove. --matt + */ node->otick = otick; } -- 2.35.1 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-test-src-buffer-tests.el-test-overlay-randomly-new-t.patch >From 89ed5cbee03cce6c621af6570d2c4411e7586f9d Mon Sep 17 00:00:00 2001 From: Matt Armstrong Date: Sat, 8 Oct 2022 09:28:29 -0700 Subject: [PATCH 2/2] ; * test/src/buffer-tests.el (test-overlay-randomly): new test. --- test/src/buffer-tests.el | 92 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/test/src/buffer-tests.el b/test/src/buffer-tests.el index a12d15bc79..46e57289a1 100644 --- a/test/src/buffer-tests.el +++ b/test/src/buffer-tests.el @@ -1508,6 +1508,98 @@ test-overlay-multibyte-transition-2 (ovshould nonempty-eob-end 4 5) (ovshould empty-eob 5 5))))) +(ert-deftest test-overlay-randomly () + "Exercise overlay code, but perform few assertions. + +This test works best when Emacs is configured with +--enable-checking=yes. This is a little bit like fuzz testing, +except this test has no way to reduce to a minimal failng test +case. Regardless, by exercising many corner cases bugs can be +found using Emacs' internal consistency assertions." + (let* ( + ;; The size and slack for the test buffer size. + (buffer-size-target 1000) + (buffer-size-slack 200) + + ;; Use up to 100 overlays. We need not use more to observe + ;; reasonable variation in the overlay data structures. + (overlay-count-limit 100) + + ;; This test maintains a vector of overlays. Each iteration + ;; may append or erase one overlay. + (overlays (make-vector overlay-count-limit nil)) + (overlay-count 0) + + ;; The test is either slowly growing or shrinking the overlay + ;; count. Deletions still occur while growing, and additions + ;; still occur while shrinking. The GROWING variable only + ;; controls the relative probability of doing one or the + ;; other. + (growing t) + + ;; Loop up to 100K times. + (iteration-count 0) + (iteration-target 100000)) + (with-temp-buffer + (while (< (buffer-size) buffer-size-target) + (insert "Sed ut perspiciatis, unde omnis iste natus error sit voluptatem +accusantium doloremque laudantium, totam rem aperiam eaque ipsa, +quae ab illo inventore veritatis et quasi architecto beatae vitae +dicta sunt, explicabo. ")) + + (while (< iteration-count iteration-target) + (cl-incf iteration-count) + + ;; Toggle GROWING if we've reached a size boundary. The idea + ;; is to initially steadily increase the overlay count, then + ;; steadily decrease it, then repeat. + (when (and growing (= overlay-count overlay-count-limit)) + (message "now shrinking") + (setq growing nil)) + (when (and (not growing) (= overlay-count 0)) + (message "now growing") + (setq growing t)) + + ;; Create or delete a random overlay according to a + ;; probability chosen by GROWING. + (let ((create-overlay (>= (random 100) (if growing 40 60)))) + (cond + ;; Possibly create a new overlay in a random place in the + ;; buffer. We have two easy choices. We can choose the + ;; overlay BEGIN randomly, then choose its END among the + ;; valid remaining buffer posiitions. Or we could choose + ;; the overlay width randomly, then choose a valid BEGIN. + ;; We take the former approach, because the overlay data + ;; structure is ordered primarily by BEGIN. + ((and create-overlay (< overlay-count overlay-count-limit)) + (let* ((begin (random (buffer-size))) + (end (+ begin (random (- (buffer-size) begin)))) + (ov (make-overlay begin end nil + (= 0 (random 2)) (= 0 (random 2))))) + (aset overlays overlay-count ov) + (cl-incf overlay-count))) + ((and (not create-overlay) (> overlay-count 0)) + + ;; Possibly delete a random overlay. + (let* ((last-index (1- overlay-count)) + (index (random overlay-count)) + (ov (aref overlays index))) + (when (< index last-index) + (aset overlays index (aref overlays last-index))) + (aset overlays last-index nil) + (cl-decf overlay-count) + (delete-overlay ov))))) + + ;; Modify the buffer on occasion, which exercises the + ;; insert/remove gap logic in the overlay implementation. + (when (and (< (buffer-size) (+ buffer-size-target buffer-size-slack)) + (zerop (random 10))) + (goto-char (1+ (random (buffer-size)))) + (insert (+ ?a (random 26)))) + (when (and (> (buffer-size) (- buffer-size-target buffer-size-slack)) + (zerop (random 10))) + (goto-char (1+ (random (buffer-size)))) + (delete-char 1)))))) -- 2.35.1 --=-=-=--