unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* New branch feature/named-lambdas.
@ 2023-07-17 10:14 Alan Mackenzie
  2023-07-17 19:52 ` Philip Kaludercic
  2023-07-19  8:07 ` Ihor Radchenko
  0 siblings, 2 replies; 5+ messages in thread
From: Alan Mackenzie @ 2023-07-17 10:14 UTC (permalink / raw)
  To: emacs-devel

Hello, Emacs.

I've just committed the first version of branch feature/named-lambdas.

This will output the @dfn{defining symbol} of any anonymous functions in
backtraces.

For example, in

    (defun foo ()
      "foo doc string"
      (lambda (bar) "lambda doc string" (car bar)))

M-: (funcall (foo) 'baz) will produce this backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp baz)
  car(baz)
  {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
  funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
  (progn (funcall (foo) 'baz))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

..  Note the {foo} on the third and fourth lines.  This is (usually) the
defun where the lambda was defined, and is helpful in locating its
source code.

This was achieved by adding an extra defining-symbol field to each of
the three forms of function (interpreted, byte-compiled,
native-compiled).  It is indended that this version of Emacs will
continue to handle functions compiled without this enhancement.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: New branch feature/named-lambdas.
  2023-07-17 10:14 New branch feature/named-lambdas Alan Mackenzie
@ 2023-07-17 19:52 ` Philip Kaludercic
  2023-07-17 21:37   ` Alan Mackenzie
  2023-07-19  8:07 ` Ihor Radchenko
  1 sibling, 1 reply; 5+ messages in thread
From: Philip Kaludercic @ 2023-07-17 19:52 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

Alan Mackenzie <acm@muc.de> writes:

> Hello, Emacs.
>
> I've just committed the first version of branch feature/named-lambdas.
>
> This will output the @dfn{defining symbol} of any anonymous functions in
> backtraces.
>
> For example, in
>
>     (defun foo ()
>       "foo doc string"
>       (lambda (bar) "lambda doc string" (car bar)))
>
> M-: (funcall (foo) 'baz) will produce this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument listp baz)
>   car(baz)
>   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
>   funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
>   (progn (funcall (foo) 'baz))
>   elisp--eval-last-sexp(nil)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   command-execute(eval-last-sexp)
>
> ..  Note the {foo} on the third and fourth lines.  This is (usually) the
> defun where the lambda was defined, and is helpful in locating its
> source code.
>
> This was achieved by adding an extra defining-symbol field to each of
> the three forms of function (interpreted, byte-compiled,
> native-compiled).  It is indended that this version of Emacs will
> continue to handle functions compiled without this enhancement.

I think the idea is nice, but there are a lot of whitespace changes in
your commit that make identifying the real changes a bit difficult.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: New branch feature/named-lambdas.
  2023-07-17 19:52 ` Philip Kaludercic
@ 2023-07-17 21:37   ` Alan Mackenzie
  2023-07-18 11:14     ` Alan Mackenzie
  0 siblings, 1 reply; 5+ messages in thread
From: Alan Mackenzie @ 2023-07-17 21:37 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

Hello, Philip.

On Mon, Jul 17, 2023 at 19:52:01 +0000, Philip Kaludercic wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.

> > I've just committed the first version of branch feature/named-lambdas.

> > This will output the @dfn{defining symbol} of any anonymous functions in
> > backtraces.

> > For example, in

> >     (defun foo ()
> >       "foo doc string"
> >       (lambda (bar) "lambda doc string" (car bar)))

> > M-: (funcall (foo) 'baz) will produce this backtrace:

> > Debugger entered--Lisp error: (wrong-type-argument listp baz)
> >   car(baz)
> >   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)  <=============================
> >   funcall({foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>) baz)
> >   (progn (funcall (foo) 'baz))
> >   elisp--eval-last-sexp(nil)
> >   eval-last-sexp(nil)
> >   funcall-interactively(eval-last-sexp nil)
> >   command-execute(eval-last-sexp)

> > ..  Note the {foo} on the third and fourth lines.  This is (usually) the
> > defun where the lambda was defined, and is helpful in locating its
> > source code.

> > This was achieved by adding an extra defining-symbol field to each of
> > the three forms of function (interpreted, byte-compiled,
> > native-compiled).  It is indended that this version of Emacs will
> > continue to handle functions compiled without this enhancement.

> I think the idea is nice, but there are a lot of whitespace changes in
> your commit that make identifying the real changes a bit difficult.

Yes.  I was instinctively correcting WS mis-alignment as I went along.
This was a mistake, sorry.

I've found a way to identify where these WS changes are, involving a git
diff, and a git diff -b, taking the diff -u between these two outputs,
then feeding that to grep '^[+-]@@'.  This identifies 10 places where the
whitespace has changed.  I hope that's all of them, but I'll check.

I'll go through these tomorrow morning and commit them to
feature/named-lambdas.  This will have the advantage of making my patch
file several hundred lines shorter.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: New branch feature/named-lambdas.
  2023-07-17 21:37   ` Alan Mackenzie
@ 2023-07-18 11:14     ` Alan Mackenzie
  0 siblings, 0 replies; 5+ messages in thread
From: Alan Mackenzie @ 2023-07-18 11:14 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

Hello, Philip.

On Mon, Jul 17, 2023 at 21:37:41 +0000, Alan Mackenzie wrote:
> On Mon, Jul 17, 2023 at 19:52:01 +0000, Philip Kaludercic wrote:
> > Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > > This was achieved by adding an extra defining-symbol field to each of
> > > the three forms of function (interpreted, byte-compiled,
> > > native-compiled).  It is indended that this version of Emacs will
> > > continue to handle functions compiled without this enhancement.

> > I think the idea is nice, but there are a lot of whitespace changes in
> > your commit that make identifying the real changes a bit difficult.

> Yes.  I was instinctively correcting WS mis-alignment as I went along.
> This was a mistake, sorry.

> I've found a way to identify where these WS changes are, involving a git
> diff, and a git diff -b, taking the diff -u between these two outputs,
> then feeding that to grep '^[+-]@@'.  This identifies 10 places where the
> whitespace has changed.  I hope that's all of them, but I'll check.

> I'll go through these tomorrow morning and commit them to
> feature/named-lambdas.  This will have the advantage of making my patch
> file several hundred lines shorter.  ;-)

I've reverted a few whitespace changes (together with an unintentional
deletion of a condition-case in comp.el).

Most of the the WS changes were actually due to semantic changes, e.g. by
enclosing a block of forms in an extra (let ....).

It can help to use the -b flag in git diff (or indeed in diff itself),
e.g.

    git diff -b master..feature/named-lambdas

..

> -- 
> Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: New branch feature/named-lambdas.
  2023-07-17 10:14 New branch feature/named-lambdas Alan Mackenzie
  2023-07-17 19:52 ` Philip Kaludercic
@ 2023-07-19  8:07 ` Ihor Radchenko
  1 sibling, 0 replies; 5+ messages in thread
From: Ihor Radchenko @ 2023-07-19  8:07 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

Alan Mackenzie <acm@muc.de> writes:

> Debugger entered--Lisp error: (wrong-type-argument listp baz)
>   car(baz)
>   {foo} #f(compiled-function (bar) "lambda doc string" #<bytecode -0x105933d3d8452e4e>)(baz)

One slightly annoying thing here is that argument values are listed all
the way at the end, after the long unreadable <...bytecode...> part.

Would it make sense to have {foo(baz)} #f... instead?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-07-19  8:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-17 10:14 New branch feature/named-lambdas Alan Mackenzie
2023-07-17 19:52 ` Philip Kaludercic
2023-07-17 21:37   ` Alan Mackenzie
2023-07-18 11:14     ` Alan Mackenzie
2023-07-19  8:07 ` Ihor Radchenko

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).