From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: backtrace-mode Date: Thu, 21 Jun 2018 17:08:52 -0700 Message-ID: <871sczsmwb.fsf@runbox.com> References: <871sd2mli3.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1529630657 32733 195.159.176.226 (22 Jun 2018 01:24:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2018 01:24:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: Gemini Lasswell , emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 22 03:24:12 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 1fWAo2-0008Mh-MT for ged-emacs-devel@m.gmane.org; Fri, 22 Jun 2018 03:24:11 +0200 Original-Received: from localhost ([::1]:58304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWAq9-0000JQ-8a for ged-emacs-devel@m.gmane.org; Thu, 21 Jun 2018 21:26:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fW9da-0005k5-I6 for emacs-devel@gnu.org; Thu, 21 Jun 2018 20:09:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fW9dX-0000lJ-Be for emacs-devel@gnu.org; Thu, 21 Jun 2018 20:09:14 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:33560) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fW9dW-0000kV-Vm for emacs-devel@gnu.org; Thu, 21 Jun 2018 20:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=L687cwyjZiuAtFCws3I5qQQBYmf3ZGVR17lS678k6es=; b=PVGChKnUYockVjoCbqXRsVu7Ne 9IaKXDiiz9ViJ3fbggQEgxPmPm+xgaE6uQ2uGQO57UwdPtvN2ZLPyqLtA4DOv8VdUVqn3C4aKlUZn 9OqbCXf4jtxZtZcuXPlV9z886Djltkb9+dksLtTGQbRoZANkmTCFTYfXtXo0d+5RR8M9NlxlRz1v3 AXzwbjacZhrpMxcfyxI37fLAgcIelEO0oT29vln8OnvSolM83YgiWD15fdlrfMdWyS71gltC/aG2m 8OsfLCi1YeGJQZW2IPnzRSkdkmv68dUiXfko8TjayTksftTKiEUuKcqhMusqFOJXpd596f0deIYpF VBfXWeeA==; Original-Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fW9dU-00034A-LO; Fri, 22 Jun 2018 02:09:08 +0200 Original-Received: from c-24-22-244-161.hsd1.wa.comcast.net ([24.22.244.161] helo=chinook) by mailfront11.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fW9dH-00088P-8K; Fri, 22 Jun 2018 02:08:55 +0200 In-Reply-To: (Helmut Eller's message of "Wed, 20 Jun 2018 07:52:07 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.220.196.211 X-Mailman-Approved-At: Thu, 21 Jun 2018 21:25:30 -0400 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:226580 Archived-At: Helmut Eller writes: > So I think there > should either be a proper "view source" command or xref backend for > backtraces. I agree. I think there should be three commands: 1. "View source", to jump to the source for the frame at point. I haven't done it yet but I plan on implementing it and binding it to the 's' key. For now it is going to work best with Edebug, but when the byte compiler or Lisp reader gain the ability someday to save source code positions, it could be made to work with those as well. 2. "Go to definition", to jump to the source code for the definition of the symbol at point, which can be used on any function or variable name in the buffer. I think xref-find-definitions with the Elisp backend works well for this. 3. "Show help", to bring up help for the symbol at point, currently implemented by backtrace-help-follow-symbol, bound to RET. > Another issue: backtrace-get-frames seems to compute the entire > backtrace and all possibly relevant information in advance. Maybe that > should be done a bit more lazily, e.g. compute the next N frames only if > somebody needs them. For local variable also keep in mind that > backtrace--locals is implemented rather inefficiently. That would also > be less problematic if locals are only fetched when needed. I'm aware that there's an O(n^2) here but I didn't want to prematurely optimize and make the code more complicated without noticable benefit. While working on this code I had tried generating backtraces from max-lisp-eval-depth errors a few times and they always came up quickly. Yesterday I realized that was due to a bug, now on debbugs as #31919. With that fixed I tried wrapping the calls to backtrace-get-frames and backtrace-print with benchmark-run, and then evaluating this code: (toggle-debug-on-error) (defun my-func (arg) (let ((arg1 arg)) (+ (length arg) (my-func arg)))) And then I tried both (my-func "hello") and (my-func my-str) with my-str bound to the buffer-string of a magit-status buffer, which for the one I used made (length (cl-prin1-to-string my-str)) evaluate to 1711302, and which is the sort of value which would make previous versions of Emacs backtraces excruciatingly slow. >From my experiments I concluded backtrace-get-frames is not a performance problem. With standard stack limits it takes about 0.015 seconds, and even after increasing both max-lisp-eval-depth and max-specpdl-size by a factor of 5, it still only takes 0.2 seconds (on a 5-year old Intel cpu, 2.6GHz). But backtrace-print is far slower, taking 3.7 seconds with high stack limits and "hello" and 60 seconds with default stack limits and the magit buffer-string. So I'll look into what can be done lazily when rendering the backtrace frames into the buffer. Gemini