bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#12329: 24.1.50; edebug with defun* and defmacro*


From: Alan Mackenzie
Subject: bug#12329: 24.1.50; edebug with defun* and defmacro*
Date: Thu, 24 Dec 2015 18:46:50 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Nic.

I know it's over three years ago, but .....

On Sun, Sep 02, 2012 at 12:35:10AM +0100, Nic Ferrier wrote:

> (require 'cl)
> (defun* nic-test-1 (a)
>   10)

> ;; instrument the above function - it will enter the debugger instead of
> ;; instrumenting, that's wrong

I don't have an Emacs 24.1, and have difficulty building one.  So I've
tried these things out on 23.2 and 24.2.  My comments below apply
equally to both versions.

When I try to instrument the `defun*' form without having done the
`require', the instrumentation process does indeed enter edebug as
though it were a defvar.  After doing the `require', it instruments the
`defun*' properly.

> (nic-test-1 20)

> ;; evaling that will call the function but does not enter the debugger,
> ;; because the instrumenting didn't work

On evaluating (symbol-function 'nic-test-1), I get this form:

    (lambda (a) (block nic-test-1 (edebug-enter (quote nic-test-1) (list a) 
(function (lambda nil 10)))))

, which shows that the original form _has_ been instrumented.  This is
not apparent on running it, though, because there is no "stop point"
anywhere in the function for edbug to stop at.  When "10" is replaced by
"a", the instrumented form looks like:

   (lambda (a) (block nic-test-2 (edebug-enter (quote nic-test-2) (list a) 
(function (lambda nil (edebug-after 0 0 a))))))

; on running this, edebug does stop inside the function, just after
evaluating "a". 

> (cl-defun nic-test-2 (a)
>   30)

> ;; instrumenting that does seem to result in proper instrumentation

> (nic-test-2 20)

> ;; evaling that does not result in the debugger being entered though.


> I had a quick look on github, here are the relevant patches that look
> like they might be the problem:

> https://github.com/emacsmirror/emacs/commit/74e7f3ee6e3147e3c8f570ffeaadb4a9a5504f39
> https://github.com/emacsmirror/emacs/commit/498110b9cee6e53cc5339206772b7e0e840b9330

Sadly, these patches are now lost forever.  :-(.  This is an example of
why 40 hex-digit hashes are a poor identifier.  With a savannah (bzr)
revision number, or a date together with commit message text, they could
have been found easily.

> In GNU Emacs 24.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
>  of 2012-08-29 on nferrier
> Windowing system distributor `The X.Org Foundation', version 11.0.11103000
> Configured using:
>  `configure '--prefix=/home/nferrier/emacs-local''

[ .... ]

There may have been a bug here, in Emacs 24.1.  I don't think there was
in either 23.2 or 24.2.  So I'm closing this bug.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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