emacs-devel
[Top][All Lists]
Advanced

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

Re: bug#24514: 24.5; Lispy backtraces


From: Eli Zaretskii
Subject: Re: bug#24514: 24.5; Lispy backtraces
Date: Sun, 04 Dec 2016 22:41:35 +0200

> 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'?



reply via email to

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