[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.
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Stefan Monnier, 2017/01/03
- bug#25295: Represent eieio objects using object-print in backtraces and edebug,
Eric Abrahamsen <=
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Stefan Monnier, 2017/01/04
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Stefan Monnier, 2017/01/04
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Stefan Monnier, 2017/01/04
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Eli Zaretskii, 2017/01/05
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Stefan Monnier, 2017/01/05
- bug#25295: Represent eieio objects using object-print in backtraces and edebug, Eli Zaretskii, 2017/01/06