From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Improving representation of EIEIO objects in backtraces/error messages Date: Sat, 31 Dec 2016 12:48:45 -0800 Message-ID: <87wpefakpe.fsf@ericabrahamsen.net> References: <87ful6o8x4.fsf@ericabrahamsen.net> <7b792dd9-491a-b442-f837-e85326a6c924@siege-engine.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1483217358 25166 195.159.176.226 (31 Dec 2016 20:49:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 20:49:18 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 31 21:49:12 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 1cNQaV-0005kB-3t for ged-emacs-devel@m.gmane.org; Sat, 31 Dec 2016 21:49:11 +0100 Original-Received: from localhost ([::1]:45332 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNQaZ-0005z1-RV for ged-emacs-devel@m.gmane.org; Sat, 31 Dec 2016 15:49:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNQaU-0005yw-A5 for emacs-devel@gnu.org; Sat, 31 Dec 2016 15:49:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNQaR-00030O-9S for emacs-devel@gnu.org; Sat, 31 Dec 2016 15:49:10 -0500 Original-Received: from [195.159.176.226] (port=36528 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNQaR-000305-1x for emacs-devel@gnu.org; Sat, 31 Dec 2016 15:49:07 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cNQaC-0003dn-Qn for emacs-devel@gnu.org; Sat, 31 Dec 2016 21:48:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 84 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:uzlvyhycPcIjyd3P2EwoeeXMARs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:211043 Archived-At: Eric Ludlam writes: > On 12/29/2016 02:02 PM, Eric Abrahamsen wrote: >> I can't be the first one to be bitten by this... >> >> When developing using EIEIO objects, backtraces and edebug messages >> can be very difficult to use. In edebug, if you're lucky, you get the >> # representation, but if you're unlucky, >> you get the vector. In backtraces, you always get the vector. >> >> For large objects, or those involving recursive data structures, this >> makes error reporting frustrating, to put it delicately. It can take >> the printer a good couple seconds to barf up the representation of an >> object, and when it does it makes a huge mess of the minibuffer >> and/or *Message* buffer. > > Hi Eric, > > CEDET includes a 'data-debug' package. If you enable that it provides a > way to navigate giant data structures as you might get with EIEIO. It > is also a part of Emacs now, though I'm not that familiar with how it > all was merged. > > I have this in my .emacs file to take advantage of it: > > (require 'data-debug) > (global-set-key "\M-:" 'data-debug-eval-expression) That's interesting, thanks! I'll play with it a bit, it might be nice to add the slot names in with the values. > I also include this for eieio: > > (add-hook 'edebug-setup-hook > (lambda () > (defalias 'edebug-prin1-to-string 'eieio-edebug-prin1-to-string))) > > though I'm not sure if something equivalent is enabled by default > during the EIEIO merge. We did end up enabling this by default, as an advice on `edebug-prin1-to-string'. It's a great relief when it works, which it only does sometimes (perhaps related to how deeply nested the objects are in the data being printed? hard to tell). > In the CEDET repository, you can get cedet-edebug.el. It includes > these two snippets that bind "A" to data debug. > > ;;;###autoload > (add-hook 'edebug-setup-hook > (lambda () > (require 'cedet-edebug) > ;; I suspect this isn't the best way to do this, but when > ;; cust-print was used on my system all my objects > ;; appeared as "#1 =" which was not useful. This allows > ;; edebug to print my objects in the nice way they were > ;; meant to with `object-print' and `class-name' > (defalias 'edebug-prin1-to-string 'cedet-edebug-prin1-to-string) > ;; Add a fancy binding into EDEBUG's keymap for ADEBUG. > (define-key edebug-mode-map "A" 'data-debug-edebug-expr) > )) > > ;;; DEBUG MODE TOO > ;; This seems like as good a place as any to stick this hack. > ;;;###autoload > (add-hook 'debugger-mode-hook > (lambda () > (require 'cedet-edebug) > ;; Add a fancy binding into the debug mode map for ADEBUG. > (define-key debugger-mode-map "A" 'data-debug-edebug-expr) > )) > > > Eric These are all good for me as a developer, but I would also like to protect users from backtraces that might, ahem, arise from my code. Do you have any opinion on the discussion in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25295 ? Anything would be welcome. Thanks for your message! Eric