eieio, pretty printing, and edebug

eieio, pretty printing, and edebug

[Eric Abrahamsen]

Right now, using edebug with eieio objects can be difficult, as they are
printed with regular prin1.

In the case of very large objects (I ran into this with the Gnus
registry object, which can have an enormous hash table attached to it),
Emacs can run out memory as the cursor passes the variable holding the
object, and tries to pretty print it.

Line 895 in eieio.el, were it not commented out, would fix this by
having edebug print using the object-print generic, not prin1. I eval'ed
the line and tried it, and it seemed to work fine.

How come it's currently commented out? Can I open a bug for this?

Eric

Re: eieio, pretty printing, and edebug

[Stefan Monnier]

> Line 895 in eieio.el, were it not commented out, would fix this by
> having edebug print using the object-print generic, not prin1. I eval'ed
> the line and tried it, and it seemed to work fine.

> How come it's currently commented out? Can I open a bug for this?

`defalias' is clearly not right, since it hijacks the function.  But if
we change it to advice-add, I think it'd be OK to enable this
edebug help.

I think it would also be good to add hooks to the native printing system
so that such tweaks can be done more reliably.  Ideally, these same
hooks could be used for things like desktop and savehist to replace
markers or other "non-printable" objects with alternative output.


        Stefan

Re: eieio, pretty printing, and edebug

[Eric Ludlam]

On 10/28/2014 12:44 PM, Stefan Monnier wrote:
>> Line 895 in eieio.el, were it not commented out, would fix this by
>> having edebug print using the object-print generic, not prin1. I eval'ed
>> the line and tried it, and it seemed to work fine.
>
>> How come it's currently commented out? Can I open a bug for this?
>
> `defalias' is clearly not right, since it hijacks the function.  But if
> we change it to advice-add, I think it'd be OK to enable this
> edebug help.
>
> I think it would also be good to add hooks to the native printing system
> so that such tweaks can be done more reliably.  Ideally, these same
> hooks could be used for things like desktop and savehist to replace
> markers or other "non-printable" objects with alternative output.

Hi,

Related to debugging EIEIO classes, the `data-debug.el' extension which 
is a part of Emacs includes a nice way to browse large data structures. 
  In it, data-debug-eval-expression is something I've bound to M-: for 
myself.  It shows the short version of the eval'd expression when it is 
short, and goes into a browser type buffer when it is particularly large.

Eric

Re: eieio, pretty printing, and edebug

[Eric Abrahamsen]

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

> On 10/28/2014 12:44 PM, Stefan Monnier wrote:
>>> Line 895 in eieio.el, were it not commented out, would fix this by
>>> having edebug print using the object-print generic, not prin1. I eval'ed
>>> the line and tried it, and it seemed to work fine.
>>
>>> How come it's currently commented out? Can I open a bug for this?
>>
>> `defalias' is clearly not right, since it hijacks the function.  But if
>> we change it to advice-add, I think it'd be OK to enable this
>> edebug help.
>>
>> I think it would also be good to add hooks to the native printing system
>> so that such tweaks can be done more reliably.  Ideally, these same
>> hooks could be used for things like desktop and savehist to replace
>> markers or other "non-printable" objects with alternative output.
>
> Hi,
>
> Related to debugging EIEIO classes, the `data-debug.el' extension
> which is a part of Emacs includes a nice way to browse large data
> structures. In it, data-debug-eval-expression is something I've bound
> to M-: for myself.  It shows the short version of the eval'd
> expression when it is short, and goes into a browser type buffer when
> it is particularly large.

That's an interesting library, thanks! Using the eval expression on
gnus-registry-db still causes Emacs to run out of memory, though :)

I've opened bug 18897 for this. I'd be happy to provide a patch, but I
don't quite see how advice-add with :override would be all that
different from the defalias.

Right now, edebug expressions are printed with
`edebug-safe-prin1-to-string', which calls `edebug-prin1-to-string',
which is an alias for `prin1-to-string'. I'd certainly consider printing
objects to be a part of the "safety" routine -- would it be unreasonable
to make edebug aware of eieio, and move most of the logic of
`eieio-edebug-prin1-to-string' into `edebug-safe-prin1-to-string',
guarded by a `featurep'?

Eric

Re: eieio, pretty printing, and edebug

[Stefan Monnier]

> don't quite see how advice-add with :override would be all that
> different from the defalias.

It would be different in the fact that defalias records this location as
"the one and only definition of this function", and a defalias can't
be reverted.

But we shouldn't use :override here either, we should
use :around instead.


        Stefan

Re: eieio, pretty printing, and edebug

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> don't quite see how advice-add with :override would be all that
>> different from the defalias.
>
> It would be different in the fact that defalias records this location as
> "the one and only definition of this function", and a defalias can't
> be reverted.
>
> But we shouldn't use :override here either, we should
> use :around instead.

Okay, preliminary patch on the bug report.

Re: eieio, pretty printing, and edebug

[Stefan Monnier]

> objects to be a part of the "safety" routine -- would it be unreasonable
> to make edebug aware of eieio, and move most of the logic of
> `eieio-edebug-prin1-to-string' into `edebug-safe-prin1-to-string',
> guarded by a `featurep'?

I don't think it'd be better than using advice-add, actually.

If you want it to be cleaner, the first step is to replace
the edebug-prin1-to-string function with a variable
edebug-prin1-to-string-function (so it's clear that it's meant to be
changed), and hence to modify it with add-function rather than
advice-add.

The even better way, as mentioned earlier, is to change prin1's
underlying infrastructure so eieio can hook into it.


        Stefan

Re: eieio, pretty printing, and edebug

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> objects to be a part of the "safety" routine -- would it be unreasonable
>> to make edebug aware of eieio, and move most of the logic of
>> `eieio-edebug-prin1-to-string' into `edebug-safe-prin1-to-string',
>> guarded by a `featurep'?
>
> I don't think it'd be better than using advice-add, actually.
>
> If you want it to be cleaner, the first step is to replace
> the edebug-prin1-to-string function with a variable
> edebug-prin1-to-string-function (so it's clear that it's meant to be
> changed), and hence to modify it with add-function rather than
> advice-add.
>
> The even better way, as mentioned earlier, is to change prin1's
> underlying infrastructure so eieio can hook into it.

I just put up a patch that does considerably less than all that. I can
probably manage solution number one above, but if you'd like to hold out
for solution number two, I'll bow out and leave the bug report for
others.