[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25295: Represent eieio objects using object-print in backtraces and

From: Eric Abrahamsen
Subject: bug#25295: Represent eieio objects using object-print in backtraces and edebug
Date: Wed, 04 Jan 2017 15:40:24 -0800
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux)

On 01/03/17 13:21 PM, Stefan Monnier wrote:
>> I guess this would require going into print.c and adding another branch
>> under the Lisp_Vectorlike case statement of object_print.
> That's right.
>> Is this sort of C code allowed to call back up to the lisp object-print
>> function? This is where I get lost...
> The Elisp-level printer and the interaction between the C code and
> the Elisp ill have to be worked out, indeed.
> E.g. you probably won't want to have Elisp-level printer to just call
> `format` or `prin1` since that does more than just print (it sets up
> a printing destination, initializes the cycle-detection table, then
> checks for cycles, ...).
> This said, making `prin1` reentrant will probably be helpful.

If an Elisp-level printer is available to users and developers, I think
we'd have to assume they will throw any old thing in there, including
`format' and `prin1'. Would making `prin1' reentrant solve all of the
resulting problems?

> One more thing: there have already been other desires/needs to tweak the
> printing from Elisp.  E.g. to special case printing of objects that
> can't be printed readably (e.g. buffers, markers, overlays, ...).

That's good! But the previous issue would still need to be resolved.

>         Stefan
> PS: One more thing; currently cl-structs and EIEIO objects are
> represented as plain normal arrays (and they mostly use the same
> representation now, where the first field contains a symbol whose
> function cell contains `:quick-object-witness-check` and whose value
> cell is the actual class object, which is a cl-struct that inherits
> from cl--class).
> It'd be good to instead provide a new kind of array just for
> objects/records/structs (just like we have the `compiled-function` type
> which is basically a normal array just with a different tag).
> This would let us get rid of the "symbol with
> a :quick-object-witness-check" indirection and would make it easier for
> the print.c code to delegate to the Elisp-level printer since it
> wouldn't need to know about the hackish representation choices of EIEIO
> and cl-structs.

I really wish I could help, but I've never written a line of C, and
in twenty minutes of looking through the sources earlier today, I
couldn't even find where the array types were defined.

It sounds like this would be Step One of solving the problem, but I
would not be able to do it without some substantial hand-holding.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]