From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Tue, 27 Nov 2018 21:43:31 -0500 Message-ID: References: <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> <20181125212920.GK27152@ACM> <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> <83in0kijz0.fsf@gnu.org> <9e216e61-7d95-94f0-cbee-593b4f32ced2@cs.ucla.edu> <20181126184359.GG4030@ACM> <55044caa-18fb-9e9a-81b4-3912f64d0aa4@cs.ucla.edu> <20181127074336.GA4705@ACM> <0ec5806a-0cc6-8b9f-6bc2-97875e36a511@cs.ucla.edu> <20181127211539.GB4705@ACM> <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> <587da59a-eed1-9fdd-f362-ea72510413dc@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543372953 17569 195.159.176.226 (28 Nov 2018 02:42:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2018 02:42:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: michael_heerdegen@web.de, Alan Mackenzie , Eli Zaretskii , cpitclaudel@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 28 03:42:28 2018 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 1gRpo4-0004T2-3j for ged-emacs-devel@m.gmane.org; Wed, 28 Nov 2018 03:42:28 +0100 Original-Received: from localhost ([::1]:45558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRpqA-0000oH-PJ for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 21:44:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRppJ-0000nB-3n for emacs-devel@gnu.org; Tue, 27 Nov 2018 21:43:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRppE-0004i4-Rf for emacs-devel@gnu.org; Tue, 27 Nov 2018 21:43:45 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:33640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRppE-0004h9-NC; Tue, 27 Nov 2018 21:43:40 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wAS2hWQO004874; Tue, 27 Nov 2018 21:43:32 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 7EF5B6619A; Tue, 27 Nov 2018 21:43:31 -0500 (EST) In-Reply-To: <587da59a-eed1-9fdd-f362-ea72510413dc@cs.ucla.edu> (Paul Eggert's message of "Tue, 27 Nov 2018 18:18:49 -0800") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6427=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6427> : inlines <6972> : streams <1805536> : uri <2756806> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:231468 Archived-At: > That's too bad. Why is hashing so slow? Can we speed it up? Possibly. > Another possibility is to have a special hashing mechanism just for pairs > that are allocated to be hashable. This would work by having a special > alternative to struct cons_block for which it would be trivial to convert > the address of a hashable pair to the address of the corresponding value > (simply add a constant to the address, say). The new 'read' function could > return hashable pairs. A hashable pair would have the same structure as an > ordinary pair so all existing functions (including C macros) would work with > it. This should be fast enough. If we only do it for cons cells, then we don't need hashing: we can make "fat-cons-cells" which contain extra position info after car/cdr. >> So I was thinking of reducing the pain by re-using the edebug info so as >> to find those arguments (or parts of arguments) which are treated as >> normal expressions, which we don't need to de-annotate. > Hmm, I know little about edebug so I'm afraid this suggestion is mostly > Greek to me. E.g. for a macro like `when` where the edebug spec is just `t` (which means all the arguments are Elisp expressions) we don't need to de-annotate anything at all. And for `dolist` whose edebug spec is ((symbolp form &optional form) body), we can use that debug spec to find that the first arg needs to be partially de-annotated, and the rest can be left fully annotated. Stefan