From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.diffs,gmane.emacs.devel Subject: Re: master 724af76 2/2: Fix sxhash-equal on bytecodes, markers, etc. Date: Wed, 8 Jan 2020 19:23:19 +0000 Message-ID: References: <20200107192947.22465.82501@vcs0.savannah.gnu.org> <20200107192950.02DA2211A5@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218244"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Paul Eggert , emacs-diffs@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-diffs-bounces+gnu-emacs-diffs=m.gmane-mx.org@gnu.org Wed Jan 08 20:24:09 2020 Return-path: Envelope-to: gnu-emacs-diffs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ipGw0-000lRa-Mz for gnu-emacs-diffs@m.gmane-mx.org; Wed, 08 Jan 2020 20:24:04 +0100 Original-Received: from localhost ([::1]:48322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipGvz-00063i-AR for gnu-emacs-diffs@m.gmane-mx.org; Wed, 08 Jan 2020 14:24:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49332) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipGvw-00061g-JE for emacs-diffs@gnu.org; Wed, 08 Jan 2020 14:24:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipGvv-0001aD-3q for emacs-diffs@gnu.org; Wed, 08 Jan 2020 14:24:00 -0500 Original-Received: from mail-oi1-x229.google.com ([2607:f8b0:4864:20::229]:37862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ipGvs-0001Y8-L0; Wed, 08 Jan 2020 14:23:56 -0500 Original-Received: by mail-oi1-x229.google.com with SMTP id z64so3690315oia.4; Wed, 08 Jan 2020 11:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=osWvw6jCe/cES9gs9IdPEv8Xz6ojxeM9sBwXSlB7Nos=; b=lO0Ax52Q7PR6WnwbG+RlV8znQxCHZ3raxe7RtQ1ndjciyfAp7W/2tXwqAEvkuhQEAc aq7KTkeG/JvPbhg1ZW9ZoyE1vH4b8OBvb4ocrpdsgywqjk+qUGGnx4QTa83pOUil/fAN TJWRfkTDvrQfCKM++nijND6Z71e04BgKUWZtZ5GIPLUUlgzkTj8ufq9N6uCd/PwTIry/ HH3c96GhlE19TRuIAY5xJKKehfMCTkuP5Vs6hhq3db0lOccMVou7Z1GarZL65UUjbm4O wXgbCzqU1+WoBzl2gPWWkmRy+GtsgZl8/WJbxWLvm8KVFakgS4PS8M4djCN0I4KowNpa TWrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=osWvw6jCe/cES9gs9IdPEv8Xz6ojxeM9sBwXSlB7Nos=; b=n0KOBsLt8psrHOQmHq5IKBOhQ4R9N3aPYxabiTnxJlLdHRZo7gmAKfM8mc2ZAo9qiX Hu2RVSZIcv9uGUDDZ87OwkVqTmRwEm9dKupPq3JBrh+cghSkPvmM/VSiIDfuKukEXAbz DIOcRXZ5joClC0ZTzT9F/rjUOUbVpyyxFtfeAk5zDtgzIgn4yFx5PyvcxMZ2t6ByGkrG v7MAKMIGXkjRIgI1UAGwBeqSJ9MSCqQlg+yn29mhJmpiKtxwCI6XkUtv1FBOW3hfRsM2 HWzJ5AmReas0vrwpIdMZL87TDL+E4ieFeax6NSBq6wiAHExedQBy3W1ZHdtFAEpCmLYY bgxw== X-Gm-Message-State: APjAAAV0IbNPHTEv9VypQ19UjcUnt98I+tMoWjiCpVOK+Bcs+VBIRapn l+JDa9WRT8DIpgCXKsl/tBLCTWJoCwaEQWXdEIk= X-Google-Smtp-Source: APXvYqz27p8azUEinYigFKtpsBJGmrwH2Zha5YiHdAmFSoM3B9WkKp1xkoLlRHlQalBzznbJtl50j62L6v+jzC5fCr4= X-Received: by 2002:a05:6808:312:: with SMTP id i18mr163639oie.44.1578511435872; Wed, 08 Jan 2020 11:23:55 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::229 X-BeenThere: emacs-diffs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Mailing list for Emacs changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-diffs-bounces+gnu-emacs-diffs=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-diffs" Xref: news.gmane.org gmane.emacs.diffs:154540 gmane.emacs.devel:244146 Archived-At: On Tue, Jan 7, 2020 at 11:37 PM Stefan Monnier wrote: > >> Again, I don't think there's any reason for using markers as keys in > >> an equal-based hash table. But if you do, what you probably meant was > >> to use an eq-based hash table, and that used to work; now it doesn't. > >> > >> (puthash marker value ht) > >> <...move marker...> > >> (gethash marker ht) > > > > If it hurts don't do that: the same happens with (It turns out I've already done it. Easy enough to fix in my code, but then I'm aware of the change in behavior. Others might not be.) Out of curiosity, though, how would you fix code that uses a cons cell of two markers, say, as a hash key? I still think it'd be nice to have an equality predicate which looks at lists but doesn't recurse into them, but in the absence of it you'd have to use nested hash tables or your own hash function, right? (My code used to do that, then switched to a single overlay as hash key, but I forgot to change the hash table predicate). > > (puthash conscell value ht) > > <...setcar conscell...> > > (gethash conscell ht) I don't think of inserting text in a buffer "far away" from a marker as modifying the marker. That's probably because I'm playing around with some unfinished code which would put markers and buffer text in a tree-like data structure and wouldn't actually modify the markers upon insertion at all, but that's just an implementation detail. > BTW, id we really wanted it, we could make that work as you expect by > making sxhash only return a value that does not depend on the properties > that can be modified (i.e. doesn't depend on the cons's car and car nor > the marker's current position), but it would lead to lots of objects > with equal hash, hence poor hashing performance. I think for very volatile objects, such as markers, that's the best course of action (they could still depend on the marker's buffer). For explicitly-modified objects, I think the current behavior is something we're going to have to live with, including some bugs when C code assumes its hash keys can't change under it. I personally would prefer not changing the behavior of sxhash/equal more than necessary, and err on the side of caution. For markers and overlays, we can just hash the buffer (if you have many markers or overlays in a single buffer, you'll run into complexity issues anyway), rather than breaking my badly-written real-world code.