From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Joakim Jalap Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Tue, 27 Sep 2016 08:26:41 +0200 Message-ID: <87k2dx97tq.fsf@fastmail.com> References: <87d1jylv43.fsf@fastmail.com> <87a8f0p69w.fsf@fastmail.com> <878tujlmp0.fsf@fastmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1474957642 21663 195.159.176.226 (27 Sep 2016 06:27:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2016 06:27:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 27 08:27:18 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bolr9-0003wc-Uh for ged-emacs-devel@m.gmane.org; Tue, 27 Sep 2016 08:27:08 +0200 Original-Received: from localhost ([::1]:48276 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bolr7-0001se-Lg for ged-emacs-devel@m.gmane.org; Tue, 27 Sep 2016 02:27:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bolr0-0001sW-VQ for emacs-devel@gnu.org; Tue, 27 Sep 2016 02:26:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bolqw-0007Wl-Oy for emacs-devel@gnu.org; Tue, 27 Sep 2016 02:26:57 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:58205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bolqu-0007Py-8r for emacs-devel@gnu.org; Tue, 27 Sep 2016 02:26:54 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED19820814; Tue, 27 Sep 2016 02:26:41 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 27 Sep 2016 02:26:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=f8iEK +hgA9ZbS/8i2fYopGLLD2g=; b=2lm8hfKRrAhVdy8yMyfveCraiLOvwVKbl/szM xY29cRyJLATAhZQWuOEoaBAcqznZFHOFJU26RmWVt7cE7XGQiHSxjBLngfHxUtfY Q55S8YsDDEl6A5r+VbtBd1GBKCNh/OirGg4Xuin3sLP6mi9PWmKIKf23Hj1jSbdL Fi4MaY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=f8iEK+hgA9ZbS/8i2fYopGLLD2g=; b=mQlG+ nl2OfbNrbZN+n0H0FDonHdWrhE0mjGpsxMdIlHlm03oE4qhRs3T60GuYgKG8DYW5 pEV0EH66MRvqHxXDQ+9Ix/28O9ARziqTAILUXDuJX+eFgHvCt9oFK12jgoY9iS7U Csz4D6zAlakmikpsK6u5B5g0NVPlkTx/5AqjRQ= X-Sasl-enc: qYUH5CfW9tIAZIdfBBDJrZ3Yl8vUxn5xnmiGjnVTZLob 1474957601 Original-Received: from thinkpad (79.138.130.193.mobile.tre.se [79.138.130.193]) by mail.messagingengine.com (Postfix) with ESMTPA id E70EDF2C38; Tue, 27 Sep 2016 02:26:40 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Thu, 22 Sep 2016 21:29:19 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.26 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207826 Archived-At: Stefan Monnier writes: >> Store the position in the root and then an offset from the parent in >> every child node? > > Something like that, I guess, yes. That actually sounds quite neat. >> But doing it like I do it now (updating all the char-positions after the >> modification) shouldn't be slower than updating the positions of all >> markers, right? > > Indeed, it's no worse than what we have, but it reduces the algorithmic > benefit of the change. IOW we can keep this for later. For later it is :) I followed Eli's advice and tried to more or less rip out all the code which deals with overlays in xdisp.c etc, so that all functions that try to gather overlays always act as if none were found. I managed to get it to compile at last, but now I'm hitting another issue. temacs segfaults in a gc while loading simple.el. It seems somehow some memory doesn't look like it should, because the stack trace from the gc is about 1100 frames! Mostly mark_object, with some mark_vectorlike here and there. How do I debug something like that? I tried putting a breakpoint in mark_buffer, but that function is called like a million times, and from what I can see at least the first hundred or so don't cause a crash. When it crashes, it always seems to be on the 10th Lisp_Object in struct buffer, which by my calculations is major_mode_. From there it seems to go haywire and into a thousand or more calls to mainly_mark object. I will try to investigate further, but any pointers (pun intended) would be very much appreciated. -- Jocke