Re: bug#24514: 24.5; Lispy backtraces

[Clément Pit--Claudel]

On 2016-12-04 15:41, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Clément Pit--Claudel <address@hidden>
>> Date: Sun, 4 Dec 2016 14:27:59 -0500
>>
>>>> The C implementation of backtrace-frame seems to be linear in the index of 
>>>> the requested frame, so a Lisp implementation of backtrace would be 
>>>> quadratic in the depth of the stack trace.  Would a new function 
>>>> backtrace-frames that returns all frames at once be acceptable?
>>>
>>> But such a backtrace-frames function would have to be implemented in
>>> C, right?  And you wanted to move the implementation of "backtrace" to
>>> Lisp, AFAIU.  So it sounds like we will be replacing one C primitive
>>> with another, or did I miss something?
>>
>> I think you're correct. It would seem good to have the flexible primitive 
>> backtrace-frames available, and it must be in C; then we can move backtrace 
>> itself to lisp.
>>
>> The idea is that enumerating frames must be done in C, but printing them 
>> doesn't need to be done there.
> 
> So would it perhaps make sense to rename 'backtrace' into something
> like 'backtrace--internal', and make it accept one more argument, the
> function to apply to each frame, which is now hard-coded as 'prin1'?
> Would that allow you to implement 'backtrace' in Lisp and also
> implement whatever application you had in mind, by calling
> 'backtrace--internal' passing it your own function instead of 'prin1'?

Quite possibly! Are you worried about the cost of allocating a list containing 
all frames? 
IN any case, that would be consistent with the style of maphash, for example. 
And a variant of backtrace taking a callback would definitely make 
backtrace-frames easy to implement on the lisp side :)

There's no big hurry on this, anyway: it's just that we recently added a neat 
option to backtrace, and there were mentions of making the backtrace buffer 
more useful in various ways, too.

Clément.

signature.asc
Description: OpenPGP digital signature