Improving representation of EIEIO objects in backtraces/error messages

Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen]

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
#<object-class I'm an object> 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.

I've defined `object-print' methods for some classes, and would dearly
love it if those methods could be used everywhere, even in simple
`eval-expression' situations. Or if there were at least an option that
would allow me to turn this behavior on and off.

Can I open a bug report?

Eric

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 29 Dec 2016 11:02:47 -0800
> 
> Can I open a bug report?

Sure, you don't need a permission for that.

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 29 Dec 2016 11:02:47 -0800
>> 
>> Can I open a bug report?
>
> Sure, you don't need a permission for that.

Done, as #25295. Sometimes it seems like a wontfix or early-stage
responses are better got on emacs-devel, but maybe that's not necessary.

Thanks,
Eric

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 29 Dec 2016 12:54:15 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> >> Date: Thu, 29 Dec 2016 11:02:47 -0800
> >> 
> >> Can I open a bug report?
> >
> > Sure, you don't need a permission for that.
> 
> Done, as #25295. Sometimes it seems like a wontfix or early-stage
> responses are better got on emacs-devel, but maybe that's not necessary.

There's nothing wrong with wontfix: the bug is still recorded by the
tracker, and someone, some day could decide to fix it.

Therefore, asking here should not be necessary, but there's nothing
wrong with that, either.

Thanks.

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Ludlam]

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
> #<object-class I'm an object> 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)

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.

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

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen]

Eric Ludlam <eric@siege-engine.com> 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
>> #<object-class I'm an object> 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

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Ludlam]

On 12/31/2016 03:48 PM, Eric Abrahamsen wrote:
> Eric Ludlam <eric@siege-engine.com> writes:
>
>> On 12/29/2016 02:02 PM, Eric Abrahamsen wrote:
...
>> 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.

The slot names should be included in the display.  At least they are for 
me in my older Emacs.  It may be that the eieio-support doesn't work 
quite right after the EIEIO change in Emacs?

In CEDET, eieio-datadebug is separate, but with EIEIO as a piece of core 
emacs with Data Debug, maybe the current tenuous load should be replaced 
by merging eieio-datadebug into data-debug.

...
>> 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
[...]

> 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.

I'm not familiar with Emacs C level expression printing.  That's why I 
just stopped using built ins and added my own top level commands to get 
things done.

The ideas represented in the thread where some special vector-form could 
fork off to a special printer sounds like a pretty nice idea though. 
That way more than just EIEIO objects could be simplified.

In the above thread, someone mentioned giving up an object's ability to 
customize it's print output.  This is a super handy feature where you 
can take some key differentiator of your object that is short to put 
into the short form print output.  Taking advantage of that feature 
makes using the short print output even better.  Of course, the 
developer needs to implement the method to make it work.  I usually go 
add a new print-object method when I'm debugging so I can figure out 
what's going on.

Eric

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen]

Eric Ludlam <eric@siege-engine.com> writes:

> On 12/31/2016 03:48 PM, Eric Abrahamsen wrote:
>> Eric Ludlam <eric@siege-engine.com> writes:
>>
>>> On 12/29/2016 02:02 PM, Eric Abrahamsen wrote:
> ...
>>> 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.
>
> The slot names should be included in the display.  At least they are
> for me in my older Emacs.  It may be that the eieio-support doesn't
> work quite right after the EIEIO change in Emacs?
>
> In CEDET, eieio-datadebug is separate, but with EIEIO as a piece of
> core emacs with Data Debug, maybe the current tenuous load should be
> replaced by merging eieio-datadebug into data-debug.

My mistake, I'd only loaded data-debug, not eieio-datadebug. The slots
are showing now.

> ...
>>> 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
> [...]
>
>> 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.
>
> I'm not familiar with Emacs C level expression printing.  That's why I
> just stopped using built ins and added my own top level commands to
> get things done.
>
> The ideas represented in the thread where some special vector-form
> could fork off to a special printer sounds like a pretty nice idea
> though. That way more than just EIEIO objects could be simplified.
>
> In the above thread, someone mentioned giving up an object's ability
> to customize it's print output.  This is a super handy feature where
> you can take some key differentiator of your object that is short to
> put into the short form print output.  Taking advantage of that
> feature makes using the short print output even better.  Of course,
> the developer needs to implement the method to make it work.  I
> usually go add a new print-object method when I'm debugging so I can
> figure out what's going on.

That was me saying that -- I just meant that, if I had to choose between
customizable object representation in *some* places, and
non-customizable representation in *all* places, I would go with the
latter. But with any luck we'll be able to get both. I agree that a
customizable object-print is a very nice thing.

Eric

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Ludlam]

On 01/08/2017 12:24 PM, Eric Abrahamsen wrote:
>> The slot names should be included in the display.  At least they are
>> for me in my older Emacs.  It may be that the eieio-support doesn't
>> work quite right after the EIEIO change in Emacs?
>>
>> In CEDET, eieio-datadebug is separate, but with EIEIO as a piece of
>> core emacs with Data Debug, maybe the current tenuous load should be
>> replaced by merging eieio-datadebug into data-debug.
 >
> My mistake, I'd only loaded data-debug, not eieio-datadebug. The slots
> are showing now.
>

It should be loaded automatically with data-debug.  At the end of my 
version it says:

;; eieio customizations
(eval-after-load "eieio"
   '(require 'eieio-datadebug))

plus a similar line for semantic.  Perhaps something got lost during the 
merge that should be fixed.

Eric

Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen]

Eric Ludlam <eric@siege-engine.com> writes:

> On 01/08/2017 12:24 PM, Eric Abrahamsen wrote:
>>> The slot names should be included in the display.  At least they are
>>> for me in my older Emacs.  It may be that the eieio-support doesn't
>>> work quite right after the EIEIO change in Emacs?
>>>
>>> In CEDET, eieio-datadebug is separate, but with EIEIO as a piece of
>>> core emacs with Data Debug, maybe the current tenuous load should be
>>> replaced by merging eieio-datadebug into data-debug.
>>
>> My mistake, I'd only loaded data-debug, not eieio-datadebug. The slots
>> are showing now.
>>
>
> It should be loaded automatically with data-debug.  At the end of my
> version it says:
>
> ;; eieio customizations
> (eval-after-load "eieio"
>   '(require 'eieio-datadebug))
>
> plus a similar line for semantic.  Perhaps something got lost during
> the merge that should be fixed.
>
> Eric

Yup, that's not how it looks in the current Emacs tree:

http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/cedet/data-debug.el

Re: Improving representation of EIEIO objects in backtraces/error messages

[Noam Postavsky]

On Wed, Jan 11, 2017 at 7:47 PM, Eric Ludlam <eric@siege-engine.com> wrote:
>
> It should be loaded automatically with data-debug.  At the end of my version
> it says:
>
> ;; eieio customizations
> (eval-after-load "eieio"
>   '(require 'eieio-datadebug))
>
> plus a similar line for semantic.  Perhaps something got lost during the
> merge that should be fixed.

See also #23792 "25.0.95; CEDET included in Emacs should be merged
with upstream"
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23792