* Problem advising nreverse.
@ 2009-12-11 13:22 Sergei Organov
0 siblings, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-11 13:22 UTC (permalink / raw
To: help-gnu-emacs
Hello,
It seems that an advice set for `nreverse' function fails to be called
when `nreverse' is called from a byte compiled function:
(let ((calls))
(defun test (problem)
(setq calls (concat calls "["))
(defun foo () (nreverse '()))
(and problem (byte-compile 'foo))
(defadvice nreverse (before nrev-adv activate)
(setq calls (concat calls "nrev-adv")))
(foo)
(ad-unadvise 'nreverse)
(setq calls (concat calls "]")))
(test t) (test nil) (test t)
calls)
Evaluating this gives me (in either GNU Emacs 22.2.1 or GNU Emacs 23.1.1):
"[][nrev-adv][]"
Is it bug or feature? What's going on here?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] <mailman.12764.1260538816.2239.help-gnu-emacs@gnu.org>
@ 2009-12-12 12:18 ` Pascal J. Bourguignon
2009-12-14 11:07 ` Sergei Organov
[not found] ` <mailman.12932.1260788943.2239.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-12 12:18 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> Hello,
>
> It seems that an advice set for `nreverse' function fails to be called
> when `nreverse' is called from a byte compiled function:
>
> (let ((calls))
> (defun test (problem)
> (setq calls (concat calls "["))
> (defun foo () (nreverse '()))
> (and problem (byte-compile 'foo))
> (defadvice nreverse (before nrev-adv activate)
> (setq calls (concat calls "nrev-adv")))
> (foo)
> (ad-unadvise 'nreverse)
> (setq calls (concat calls "]")))
> (test t) (test nil) (test t)
> calls)
>
> Evaluating this gives me (in either GNU Emacs 22.2.1 or GNU Emacs 23.1.1):
>
> "[][nrev-adv][]"
>
> Is it bug or feature? What's going on here?
Indeed, it is a feature.
Advices are not available from several call points:
1- when the advised function is called from C code.
2- when the advised function is a an opcode of the virtual machine.
You can observe the difference between the two primitives nreverse
and buffer-name for example, with:
(disassemble (byte-compile (lambda (x) (nreverse x))))
vs.:
(disassemble (byte-compile (lambda (x) (buffer-name x))))
In the former case, nreverse is a byte code, and therefore no
advice applies. In the later case, buffer-name is called with the
call byte code, which will go thru the advice.
Notice that if you really want to advice such a low level primitive
function as nreverse, you can replace it with a lisp function (and
recompile all the code that uses it).
(defvar primitive-nreverse (symbol-function 'nreverse))
(defun nreverse (list) (funcall primitive-nreverse list))
Then nreverse will be a normal lisp function and you will be able to
advise it. Be sure to recompile all the code that uses nreverse
otherwise it will still shortcut to the primitive nreverse.
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-12 12:18 ` Problem advising nreverse Pascal J. Bourguignon
@ 2009-12-14 11:07 ` Sergei Organov
[not found] ` <mailman.12932.1260788943.2239.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-14 11:07 UTC (permalink / raw
To: help-gnu-emacs
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Hello,
>>
>> It seems that an advice set for `nreverse' function fails to be called
>> when `nreverse' is called from a byte compiled function:
[...]
>> Is it bug or feature? What's going on here?
>
> Indeed, it is a feature.
>
> Advices are not available from several call points:
>
> 1- when the advised function is called from C code.
>
> 2- when the advised function is a an opcode of the virtual machine.
> You can observe the difference between the two primitives nreverse
> and buffer-name for example, with:
>
> (disassemble (byte-compile (lambda (x) (nreverse x))))
> vs.:
> (disassemble (byte-compile (lambda (x) (buffer-name x))))
>
> In the former case, nreverse is a byte code, and therefore no
> advice applies. In the later case, buffer-name is called with the
> call byte code, which will go thru the advice.
>
> Notice that if you really want to advice such a low level primitive
> function as nreverse, you can replace it with a lisp function (and
> recompile all the code that uses it).
Thanks a lot for the explanations and suggestion.
Unfortunately this is not an option as intention was to advise
`nreverse' during calls to a possibly buggy `ewoc-collect' function that
for a long time errorneously called `nreverse' at the end (fixed since
2008).
-- Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.12932.1260788943.2239.help-gnu-emacs@gnu.org>
@ 2009-12-14 13:01 ` Pascal J. Bourguignon
2009-12-14 15:05 ` Sergei Organov
[not found] ` <mailman.12940.1260803316.2239.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-14 13:01 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>> Sergei Organov <osv@javad.com> writes:
>>
>>> Hello,
>>>
>>> It seems that an advice set for `nreverse' function fails to be called
>>> when `nreverse' is called from a byte compiled function:
>
> [...]
>
>>> Is it bug or feature? What's going on here?
>>
>> Indeed, it is a feature.
>>
>> Advices are not available from several call points:
>>
>> 1- when the advised function is called from C code.
>>
>> 2- when the advised function is a an opcode of the virtual machine.
>> You can observe the difference between the two primitives nreverse
>> and buffer-name for example, with:
>>
>> (disassemble (byte-compile (lambda (x) (nreverse x))))
>> vs.:
>> (disassemble (byte-compile (lambda (x) (buffer-name x))))
>>
>> In the former case, nreverse is a byte code, and therefore no
>> advice applies. In the later case, buffer-name is called with the
>> call byte code, which will go thru the advice.
>>
>> Notice that if you really want to advice such a low level primitive
>> function as nreverse, you can replace it with a lisp function (and
>> recompile all the code that uses it).
>
> Thanks a lot for the explanations and suggestion.
>
> Unfortunately this is not an option as intention was to advise
> `nreverse' during calls to a possibly buggy `ewoc-collect' function that
> for a long time errorneously called `nreverse' at the end (fixed since
> 2008).
Redefining nreverse and reloading the ewoc-collect function would help
as indicated...
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-14 13:01 ` Pascal J. Bourguignon
@ 2009-12-14 15:05 ` Sergei Organov
2009-12-15 8:19 ` Kevin Rodgers
[not found] ` <mailman.12940.1260803316.2239.help-gnu-emacs@gnu.org>
1 sibling, 1 reply; 18+ messages in thread
From: Sergei Organov @ 2009-12-14 15:05 UTC (permalink / raw
To: help-gnu-emacs
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sergei Organov <osv@javad.com> writes:
>
>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> Hello,
>>>>
>>>> It seems that an advice set for `nreverse' function fails to be called
>>>> when `nreverse' is called from a byte compiled function:
>>
>> [...]
>>
>>>> Is it bug or feature? What's going on here?
>>>
>>> Indeed, it is a feature.
>>>
>>> Advices are not available from several call points:
>>>
>>> 1- when the advised function is called from C code.
>>>
>>> 2- when the advised function is a an opcode of the virtual machine.
>>> You can observe the difference between the two primitives nreverse
>>> and buffer-name for example, with:
>>>
>>> (disassemble (byte-compile (lambda (x) (nreverse x))))
>>> vs.:
>>> (disassemble (byte-compile (lambda (x) (buffer-name x))))
>>>
>>> In the former case, nreverse is a byte code, and therefore no
>>> advice applies. In the later case, buffer-name is called with the
>>> call byte code, which will go thru the advice.
>>>
>>> Notice that if you really want to advice such a low level primitive
>>> function as nreverse, you can replace it with a lisp function (and
>>> recompile all the code that uses it).
>>
>> Thanks a lot for the explanations and suggestion.
>>
>> Unfortunately this is not an option as intention was to advise
>> `nreverse' during calls to a possibly buggy `ewoc-collect' function that
>> for a long time errorneously called `nreverse' at the end (fixed since
>> 2008).
>
> Redefining nreverse and reloading the ewoc-collect function would help
> as indicated...
Yeah, but:
1. I don't really want `nreverse' to be always redefined.
2. I don't know how to reload `ewoc-collect' (from elisp) provided it's
already byte-compiled.
Here what I've actually originally tried (that didn't work):
(defadvice ewoc-collect (around fix-ewoc-collect activate)
"Fix buggy `ewoc-collect' by reversing its result provided it
was altered by `nreverse'."
(let ((last-nreverse-result))
(unwind-protect
(progn
(defadvice nreverse (after notice-nreverse activate)
(setq last-nreverse-result ad-return-value))
ad-do-it)
(ad-unadvise 'nreverse))
(if (eq last-nreverse-result ad-return-value)
(setq ad-return-value (nreverse ad-return-value)))))
This starts to work as soon as I re-evaluate the (defun ewoc-collect
...) in the ewoc.el file after the above defadvice is evaluated and
continues to work even if I byte-compile the (defun ewoc-collect...)
after that (though I still don't understand why it works after
byte-compiling), but then it's both easier and cleaner to just re-define
ewoc-collect to a correct version.
-- Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.12940.1260803316.2239.help-gnu-emacs@gnu.org>
@ 2009-12-14 15:23 ` Pascal J. Bourguignon
2009-12-14 16:01 ` Sergei Organov
[not found] ` <mailman.12941.1260806509.2239.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-14 15:23 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>
>>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>>> Sergei Organov <osv@javad.com> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> It seems that an advice set for `nreverse' function fails to be called
>>>>> when `nreverse' is called from a byte compiled function:
>>>
>>> [...]
>>>
>>>>> Is it bug or feature? What's going on here?
>>>>
>>>> Indeed, it is a feature.
>>>>
>>>> Advices are not available from several call points:
>>>>
>>>> 1- when the advised function is called from C code.
>>>>
>>>> 2- when the advised function is a an opcode of the virtual machine.
>>>> You can observe the difference between the two primitives nreverse
>>>> and buffer-name for example, with:
>>>>
>>>> (disassemble (byte-compile (lambda (x) (nreverse x))))
>>>> vs.:
>>>> (disassemble (byte-compile (lambda (x) (buffer-name x))))
>>>>
>>>> In the former case, nreverse is a byte code, and therefore no
>>>> advice applies. In the later case, buffer-name is called with the
>>>> call byte code, which will go thru the advice.
>>>>
>>>> Notice that if you really want to advice such a low level primitive
>>>> function as nreverse, you can replace it with a lisp function (and
>>>> recompile all the code that uses it).
>>>
>>> Thanks a lot for the explanations and suggestion.
>>>
>>> Unfortunately this is not an option as intention was to advise
>>> `nreverse' during calls to a possibly buggy `ewoc-collect' function that
>>> for a long time errorneously called `nreverse' at the end (fixed since
>>> 2008).
>>
>> Redefining nreverse and reloading the ewoc-collect function would help
>> as indicated...
>
> Yeah, but:
>
> 1. I don't really want `nreverse' to be always redefined.
Of course. You do that only while "debugging" ewoc-collect. Then you
can either put back the old nreverse, or reboot emacs.
(require 'cl)
(setf (symbol-function 'old-nreverse) (symbol-function 'nreverse))
(defun nreverse (&rest arguments)
(message "nreverse called with %S" arguments)
(funcall old-nreverse arguments))
;; possibly add an advice, but you can as well put the code in the
;; new definition of nreverse above.
(do-stuff-with-new-nreverse)
;; When done:
(setf (symbol-function 'nreverse) (symbol-function 'old-nreverse))
> 2. I don't know how to reload `ewoc-collect' (from elisp) provided it's
> already byte-compiled.
C-h f ewoc-collect RET C-x o TAB RET
should bring you to the file where ewoc-collect is defined. Then you
can load it, or just re-evaluate the ewoc-collect definition to have
it take into account the new nreverse. If you want to debug it while
compiled, you can byte-compile it too.
> Here what I've actually originally tried (that didn't work):
>
> (defadvice ewoc-collect (around fix-ewoc-collect activate)
> "Fix buggy `ewoc-collect' by reversing its result provided it
> was altered by `nreverse'."
> (let ((last-nreverse-result))
> (unwind-protect
> (progn
> (defadvice nreverse (after notice-nreverse activate)
> (setq last-nreverse-result ad-return-value))
> ad-do-it)
> (ad-unadvise 'nreverse))
> (if (eq last-nreverse-result ad-return-value)
> (setq ad-return-value (nreverse ad-return-value)))))
>
> This starts to work as soon as I re-evaluate the (defun ewoc-collect
> ...) in the ewoc.el file
Then you know where ewoc-collect is defined, you can load this ewoc.el
file!
> after the above defadvice is evaluated and
> continues to work even if I byte-compile the (defun ewoc-collect...)
> after that (though I still don't understand why it works after
> byte-compiling), but then it's both easier and cleaner to just re-define
> ewoc-collect to a correct version.
Indeed.
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-14 15:23 ` Pascal J. Bourguignon
@ 2009-12-14 16:01 ` Sergei Organov
[not found] ` <mailman.12941.1260806509.2239.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-14 16:01 UTC (permalink / raw
To: help-gnu-emacs
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sergei Organov <osv@javad.com> writes:
>
>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>>>>> Sergei Organov <osv@javad.com> writes:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> It seems that an advice set for `nreverse' function fails to be called
>>>>>> when `nreverse' is called from a byte compiled function:
>>>>
>>>> [...]
>>>>
>>>>>> Is it bug or feature? What's going on here?
>>>>>
>>>>> Indeed, it is a feature.
>>>>>
>>>>> Advices are not available from several call points:
>>>>>
>>>>> 1- when the advised function is called from C code.
>>>>>
>>>>> 2- when the advised function is a an opcode of the virtual machine.
>>>>> You can observe the difference between the two primitives nreverse
>>>>> and buffer-name for example, with:
>>>>>
>>>>> (disassemble (byte-compile (lambda (x) (nreverse x))))
>>>>> vs.:
>>>>> (disassemble (byte-compile (lambda (x) (buffer-name x))))
>>>>>
>>>>> In the former case, nreverse is a byte code, and therefore no
>>>>> advice applies. In the later case, buffer-name is called with the
>>>>> call byte code, which will go thru the advice.
>>>>>
>>>>> Notice that if you really want to advice such a low level primitive
>>>>> function as nreverse, you can replace it with a lisp function (and
>>>>> recompile all the code that uses it).
>>>>
>>>> Thanks a lot for the explanations and suggestion.
>>>>
>>>> Unfortunately this is not an option as intention was to advise
>>>> `nreverse' during calls to a possibly buggy `ewoc-collect' function that
>>>> for a long time errorneously called `nreverse' at the end (fixed since
>>>> 2008).
>>>
>>> Redefining nreverse and reloading the ewoc-collect function would help
>>> as indicated...
>>
>> Yeah, but:
>>
>> 1. I don't really want `nreverse' to be always redefined.
>
> Of course. You do that only while "debugging" ewoc-collect. Then you
> can either put back the old nreverse, or reboot emacs.
>
> (require 'cl)
> (setf (symbol-function 'old-nreverse) (symbol-function 'nreverse))
> (defun nreverse (&rest arguments)
> (message "nreverse called with %S" arguments)
> (funcall old-nreverse arguments))
> ;; possibly add an advice, but you can as well put the code in the
> ;; new definition of nreverse above.
> (do-stuff-with-new-nreverse)
>
> ;; When done:
> (setf (symbol-function 'nreverse) (symbol-function 'old-nreverse))
I'm not now sure, but I think I've tried replacing defadvice with
re-defining of the function, but it worked (didn't work) exactly the
same way as defadvice.
>> 2. I don't know how to reload `ewoc-collect' (from elisp) provided it's
>> already byte-compiled.
>
> C-h f ewoc-collect RET C-x o TAB RET
>
> should bring you to the file where ewoc-collect is defined. Then you
> can load it, or just re-evaluate the ewoc-collect definition to have
> it take into account the new nreverse. If you want to debug it while
> compiled, you can byte-compile it too.
>
You see, I wanted automatic elisp-only solution to "fixing"
ewoc-collect, but only if it indeed happens to be buggy. Manual
reloading is not an option then. Alternate approach would be to execute
simple test-case to determine if ewoc-collect is indeed buggy and then
re-define it to the correct version if so. That's what I'm going to
implement now, provided there doesn't seem to be a way to do what I want
by means of advising ewoc-collect and nreverse.
>
>> Here what I've actually originally tried (that didn't work):
>>
>> (defadvice ewoc-collect (around fix-ewoc-collect activate)
>> "Fix buggy `ewoc-collect' by reversing its result provided it
>> was altered by `nreverse'."
>> (let ((last-nreverse-result))
>> (unwind-protect
>> (progn
>> (defadvice nreverse (after notice-nreverse activate)
>> (setq last-nreverse-result ad-return-value))
>> ad-do-it)
>> (ad-unadvise 'nreverse))
>> (if (eq last-nreverse-result ad-return-value)
>> (setq ad-return-value (nreverse ad-return-value)))))
>>
>> This starts to work as soon as I re-evaluate the (defun ewoc-collect
>> ...) in the ewoc.el file
>
> Then you know where ewoc-collect is defined, you can load this ewoc.el
> file!
I do know, but I wanted lisp-only, entirely automated solution.
-- Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.12941.1260806509.2239.help-gnu-emacs@gnu.org>
@ 2009-12-14 17:56 ` Pascal J. Bourguignon
2009-12-14 19:59 ` Sergei Organov
[not found] ` <mailman.12952.1260820780.2239.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-14 17:56 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> You see, I wanted automatic elisp-only solution to "fixing"
> ewoc-collect, but only if it indeed happens to be buggy. Manual
> reloading is not an option then. Alternate approach would be to execute
> simple test-case to determine if ewoc-collect is indeed buggy and then
> re-define it to the correct version if so. That's what I'm going to
> implement now, provided there doesn't seem to be a way to do what I want
> by means of advising ewoc-collect and nreverse.
I see.
Perhaps you can statically characterize what version (variables
emacs-version, emacs-major-version, emacs-minor-version) contains the
broken ewoc, and then just redefine it in these versions, in your
~/.emacs:
(require 'ewoc)
(when (or (< emacs-version-major NN)
(and (= emacs-version-major NN)
(< emacs-version-minor MM)))
(defun ewoc-collect (...)
...))
or else, if you can detect the broken version with a test:
(require 'ewoc)
(unless (equal 'expected-result
(ewoc-collect 'test-arguments))
(defun ewoc-collect (...)
...))
(you can add a (byte-compile 'ewoc-collect) after the defun in either
case if you need it fast).
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-14 17:56 ` Pascal J. Bourguignon
@ 2009-12-14 19:59 ` Sergei Organov
[not found] ` <mailman.12952.1260820780.2239.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-14 19:59 UTC (permalink / raw
To: help-gnu-emacs
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sergei Organov <osv@javad.com> writes:
>
>> You see, I wanted automatic elisp-only solution to "fixing"
>> ewoc-collect, but only if it indeed happens to be buggy. Manual
>> reloading is not an option then. Alternate approach would be to execute
>> simple test-case to determine if ewoc-collect is indeed buggy and then
>> re-define it to the correct version if so. That's what I'm going to
>> implement now, provided there doesn't seem to be a way to do what I want
>> by means of advising ewoc-collect and nreverse.
>
> I see.
>
[...]
> or else, if you can detect the broken version with a test:
>
> (require 'ewoc)
> (unless (equal 'expected-result
> (ewoc-collect 'test-arguments))
> (defun ewoc-collect (...)
> ...))
>
> (you can add a (byte-compile 'ewoc-collect) after the defun in either
> case if you need it fast).
Exactly. After realizing with your help that I'll have no luck with
defadvicing nreverse, I finally ended up with the following simple
solution:
;; Fix buggy `ewoc-collect' by reversing its result. Nothing will be
;; changed if `ewoc-collect' is fine.
(require 'ewoc)
(with-temp-buffer
(let ((ewoc (ewoc-create (lambda (elem) ()))))
(ewoc-enter-last ewoc 0) (ewoc-enter-last ewoc 1)
(if (equal 1 (car (ewoc-collect ewoc (lambda (elem) t))))
(defadvice ewoc-collect (after ewoc-collect-reverse activate compile)
"Reverse the result to compensate for buggy implementation."
(setq ad-return-value (nreverse ad-return-value))))))
I still wonder if it's documented somewhere in some manual when
defadvice doesn't actually work. It seems it is not there in the Elisp
manual, or did I miss it?
--
Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.12952.1260820780.2239.help-gnu-emacs@gnu.org>
@ 2009-12-15 1:47 ` Pascal J. Bourguignon
2009-12-15 12:06 ` Sergei Organov
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-15 1:47 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> I still wonder if it's documented somewhere in some manual when
> defadvice doesn't actually work. It seems it is not there in the Elisp
> manual, or did I miss it?
See: (info "(elisp)Advising Primitives")
For the byte-compiled case, I just tried it out and infered the
explaination from the disassemblies, applying common sense.
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-14 15:05 ` Sergei Organov
@ 2009-12-15 8:19 ` Kevin Rodgers
2009-12-15 12:02 ` Sergei Organov
0 siblings, 1 reply; 18+ messages in thread
From: Kevin Rodgers @ 2009-12-15 8:19 UTC (permalink / raw
To: help-gnu-emacs
[I'm responding to this message, because subsequently the thread spun out of
control beyond my comprehension.]
Sergei Organov wrote:
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
...
>> Redefining nreverse and reloading the ewoc-collect function would help
>> as indicated...
>
> Yeah, but:
>
> 1. I don't really want `nreverse' to be always redefined.
If you know the bug is in ewoc, you don't want nreverse redefined ever.
> 2. I don't know how to reload `ewoc-collect' (from elisp) provided it's
> already byte-compiled.
Put the new defun in a file and explicitly reload it.
> Here what I've actually originally tried (that didn't work):
>
> (defadvice ewoc-collect (around fix-ewoc-collect activate)
> "Fix buggy `ewoc-collect' by reversing its result provided it
> was altered by `nreverse'."
> (let ((last-nreverse-result))
> (unwind-protect
> (progn
> (defadvice nreverse (after notice-nreverse activate)
> (setq last-nreverse-result ad-return-value))
> ad-do-it)
ad-do-it is not a variable: it is a form that can only be meaningfully
referenced *within* a defadvice form.
> (ad-unadvise 'nreverse))
> (if (eq last-nreverse-result ad-return-value)
> (setq ad-return-value (nreverse ad-return-value)))))
I don't understand: How can you determine whether any value "was
altered by nreverse"? That is not Lispish thinking.
> This starts to work as soon as I re-evaluate the (defun ewoc-collect
> ...) in the ewoc.el file after the above defadvice is evaluated and
> continues to work even if I byte-compile the (defun ewoc-collect...)
> after that (though I still don't understand why it works after
> byte-compiling), but then it's both easier and cleaner to just re-define
> ewoc-collect to a correct version.
>
> -- Sergei.
>
>
>
>
--
Kevin Rodgers
Denver, Colorado, USA
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-15 8:19 ` Kevin Rodgers
@ 2009-12-15 12:02 ` Sergei Organov
0 siblings, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-15 12:02 UTC (permalink / raw
To: help-gnu-emacs
Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> [I'm responding to this message, because subsequently the thread spun out of
> control beyond my comprehension.]
>
> Sergei Organov wrote:
>> pjb@informatimago.com (Pascal J. Bourguignon) writes:
> ...
>>> Redefining nreverse and reloading the ewoc-collect function would help
>>> as indicated...
>>
>> Yeah, but:
>>
>> 1. I don't really want `nreverse' to be always redefined.
>
> If you know the bug is in ewoc, you don't want nreverse redefined ever.
>
>> 2. I don't know how to reload `ewoc-collect' (from elisp) provided it's
>> already byte-compiled.
>
> Put the new defun in a file and explicitly reload it.
Copy-paste the original and fix that? This has its own drawbacks. Think
what will happen when new version of the package with incompatible
function appears.
>> Here what I've actually originally tried (that didn't work):
>>
>> (defadvice ewoc-collect (around fix-ewoc-collect activate)
>> "Fix buggy `ewoc-collect' by reversing its result provided it
>> was altered by `nreverse'."
>> (let ((last-nreverse-result))
>> (unwind-protect
>> (progn
>> (defadvice nreverse (after notice-nreverse activate)
>> (setq last-nreverse-result ad-return-value))
>> ad-do-it)
>
> ad-do-it is not a variable: it is a form that can only be meaningfully
> referenced *within* a defadvice form.
But it *is* within 'fix-ewoc-collect' defadvice form (look at top-level).
>
>> (ad-unadvise 'nreverse))
>> (if (eq last-nreverse-result ad-return-value)
>> (setq ad-return-value (nreverse ad-return-value)))))
>
> I don't understand: How can you determine whether any value "was
> altered by nreverse"? That is not Lispish thinking.
Yeah, probably it is not Lispish. Another option was to make 'nreverse'
a no-op for duration of 'ewoc-collect' call, but that didn't work
either, apparently due to the same reason defadvice of nreverse doesn't
work.
--
Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-15 1:47 ` Pascal J. Bourguignon
@ 2009-12-15 12:06 ` Sergei Organov
[not found] ` <mailman.13009.1260879016.2239.help-gnu-emacs@gnu.org>
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-15 12:06 UTC (permalink / raw
To: help-gnu-emacs
pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sergei Organov <osv@javad.com> writes:
>> I still wonder if it's documented somewhere in some manual when
>> defadvice doesn't actually work. It seems it is not there in the Elisp
>> manual, or did I miss it?
>
> See: (info "(elisp)Advising Primitives")
Well, but I didn't find even single word there describing cases when
it does not work to advise a funciton.
> For the byte-compiled case, I just tried it out and infered the
> explaination from the disassemblies, applying common sense.
So it's not known to be documented, right?
--
Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.13009.1260879016.2239.help-gnu-emacs@gnu.org>
@ 2009-12-15 19:54 ` Pascal J. Bourguignon
0 siblings, 0 replies; 18+ messages in thread
From: Pascal J. Bourguignon @ 2009-12-15 19:54 UTC (permalink / raw
To: help-gnu-emacs
Sergei Organov <osv@javad.com> writes:
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>> I still wonder if it's documented somewhere in some manual when
>>> defadvice doesn't actually work. It seems it is not there in the Elisp
>>> manual, or did I miss it?
>>
>> See: (info "(elisp)Advising Primitives")
>
> Well, but I didn't find even single word there describing cases when
> it does not work to advise a funciton.
>
>> For the byte-compiled case, I just tried it out and infered the
>> explaination from the disassemblies, applying common sense.
>
> So it's not known to be documented, right?
AFAIK, no. But there's always the sources.
--
__Pascal Bourguignon__
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-15 1:47 ` Pascal J. Bourguignon
2009-12-15 12:06 ` Sergei Organov
[not found] ` <mailman.13009.1260879016.2239.help-gnu-emacs@gnu.org>
@ 2009-12-15 20:38 ` Sergei Organov
[not found] ` <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>
3 siblings, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-15 20:38 UTC (permalink / raw
To: help-gnu-emacs
> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>> I still wonder if it's documented somewhere in some manual when
>>> defadvice doesn't actually work. It seems it is not there in the Elisp
>>> manual, or did I miss it?
>>
>> See: (info "(elisp)Advising Primitives")
>
> Well, but I didn't find even single word there describing cases when
> it does not work to advise a funciton.
Sorry, my mistake. In fact, this topic does tell about when advice won't
work, but it tells exactly opposite to what actually happens:
"Calls to the primitive from Lisp code will take note of the advice, but
calls from C code will ignore the advice."
Now, in my case `nreverse' is called from Lisp code, not from C code, so
according to the manual advice must work, right? And there is no single
word about differences in behavior due to byte-compiling.
--
Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>
@ 2009-12-15 21:12 ` Barry Margolin
2009-12-16 11:27 ` Sergei Organov
[not found] ` <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 18+ messages in thread
From: Barry Margolin @ 2009-12-15 21:12 UTC (permalink / raw
To: help-gnu-emacs
In article <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>,
Sergei Organov <osv@javad.com> wrote:
> > pjb@informatimago.com (Pascal J. Bourguignon) writes:
> >
> >> Sergei Organov <osv@javad.com> writes:
> >>> I still wonder if it's documented somewhere in some manual when
> >>> defadvice doesn't actually work. It seems it is not there in the Elisp
> >>> manual, or did I miss it?
> >>
> >> See: (info "(elisp)Advising Primitives")
> >
> > Well, but I didn't find even single word there describing cases when
> > it does not work to advise a funciton.
>
> Sorry, my mistake. In fact, this topic does tell about when advice won't
> work, but it tells exactly opposite to what actually happens:
>
> "Calls to the primitive from Lisp code will take note of the advice, but
> calls from C code will ignore the advice."
>
> Now, in my case `nreverse' is called from Lisp code, not from C code, so
> according to the manual advice must work, right? And there is no single
> word about differences in behavior due to byte-compiling.
Byte compiling effectively changes it to a call from C code, because the
byte code is a direct reference to the primitive. "Called from Lisp
code" means interpreting Lisp source code, since that indirects through
the function name, which is where advice is stored.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
2009-12-15 21:12 ` Barry Margolin
@ 2009-12-16 11:27 ` Sergei Organov
[not found] ` <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 18+ messages in thread
From: Sergei Organov @ 2009-12-16 11:27 UTC (permalink / raw
To: help-gnu-emacs
Barry Margolin <barmar@alum.mit.edu> writes:
> In article <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>,
> Sergei Organov <osv@javad.com> wrote:
>
>> > pjb@informatimago.com (Pascal J. Bourguignon) writes:
>> >
>> >> Sergei Organov <osv@javad.com> writes:
>> >>> I still wonder if it's documented somewhere in some manual when
>> >>> defadvice doesn't actually work. It seems it is not there in the Elisp
>> >>> manual, or did I miss it?
>> >>
>> >> See: (info "(elisp)Advising Primitives")
>> >
>> > Well, but I didn't find even single word there describing cases when
>> > it does not work to advise a funciton.
>>
>> Sorry, my mistake. In fact, this topic does tell about when advice won't
>> work, but it tells exactly opposite to what actually happens:
>>
>> "Calls to the primitive from Lisp code will take note of the advice, but
>> calls from C code will ignore the advice."
>>
>> Now, in my case `nreverse' is called from Lisp code, not from C code, so
>> according to the manual advice must work, right? And there is no single
>> word about differences in behavior due to byte-compiling.
>
> Byte compiling effectively changes it to a call from C code, because the
> byte code is a direct reference to the primitive. "Called from Lisp
> code" means interpreting Lisp source code, since that indirects through
> the function name, which is where advice is stored.
I do understand what you are saying, but I can't persuade myself to
believe that "calls from C code" include "calls from byte-compiled Lisp
code" in general. As far as I understand, byte-compiled Lisp code is
never seen by a C compiler and can't be compiled by a C compiler, so
it's not C code, thus calls from byte-compiled code are not calls from C
code. IMHO it should be explicitly specified in the documentation that
calls to a primitive from byte-compiled Lisp code will ignore the
advice, provided this is feature indeed.
--
Sergei.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Problem advising nreverse.
[not found] ` <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>
@ 2009-12-17 16:52 ` Barry Margolin
0 siblings, 0 replies; 18+ messages in thread
From: Barry Margolin @ 2009-12-17 16:52 UTC (permalink / raw
To: help-gnu-emacs
In article <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>,
Sergei Organov <osv@javad.com> wrote:
> Barry Margolin <barmar@alum.mit.edu> writes:
>
> > In article <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>,
> > Sergei Organov <osv@javad.com> wrote:
> >
> >> > pjb@informatimago.com (Pascal J. Bourguignon) writes:
> >> >
> >> >> Sergei Organov <osv@javad.com> writes:
> >> >>> I still wonder if it's documented somewhere in some manual when
> >> >>> defadvice doesn't actually work. It seems it is not there in the Elisp
> >> >>> manual, or did I miss it?
> >> >>
> >> >> See: (info "(elisp)Advising Primitives")
> >> >
> >> > Well, but I didn't find even single word there describing cases when
> >> > it does not work to advise a funciton.
> >>
> >> Sorry, my mistake. In fact, this topic does tell about when advice won't
> >> work, but it tells exactly opposite to what actually happens:
> >>
> >> "Calls to the primitive from Lisp code will take note of the advice, but
> >> calls from C code will ignore the advice."
> >>
> >> Now, in my case `nreverse' is called from Lisp code, not from C code, so
> >> according to the manual advice must work, right? And there is no single
> >> word about differences in behavior due to byte-compiling.
> >
> > Byte compiling effectively changes it to a call from C code, because the
> > byte code is a direct reference to the primitive. "Called from Lisp
> > code" means interpreting Lisp source code, since that indirects through
> > the function name, which is where advice is stored.
>
> I do understand what you are saying, but I can't persuade myself to
> believe that "calls from C code" include "calls from byte-compiled Lisp
> code" in general. As far as I understand, byte-compiled Lisp code is
> never seen by a C compiler and can't be compiled by a C compiler, so
> it's not C code, thus calls from byte-compiled code are not calls from C
> code. IMHO it should be explicitly specified in the documentation that
> calls to a primitive from byte-compiled Lisp code will ignore the
> advice, provided this is feature indeed.
I agree that the documentation should say this explicitly.
What's presumably going on is that nreverse is a primitive byte-code
operation. The code is presumably an index into a table of C function
pointers, so the byte code interpreter simply calls those function
directly. That's why it's equivalent to calling the function directly
from other C code.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-12-17 16:52 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.12764.1260538816.2239.help-gnu-emacs@gnu.org>
2009-12-12 12:18 ` Problem advising nreverse Pascal J. Bourguignon
2009-12-14 11:07 ` Sergei Organov
[not found] ` <mailman.12932.1260788943.2239.help-gnu-emacs@gnu.org>
2009-12-14 13:01 ` Pascal J. Bourguignon
2009-12-14 15:05 ` Sergei Organov
2009-12-15 8:19 ` Kevin Rodgers
2009-12-15 12:02 ` Sergei Organov
[not found] ` <mailman.12940.1260803316.2239.help-gnu-emacs@gnu.org>
2009-12-14 15:23 ` Pascal J. Bourguignon
2009-12-14 16:01 ` Sergei Organov
[not found] ` <mailman.12941.1260806509.2239.help-gnu-emacs@gnu.org>
2009-12-14 17:56 ` Pascal J. Bourguignon
2009-12-14 19:59 ` Sergei Organov
[not found] ` <mailman.12952.1260820780.2239.help-gnu-emacs@gnu.org>
2009-12-15 1:47 ` Pascal J. Bourguignon
2009-12-15 12:06 ` Sergei Organov
[not found] ` <mailman.13009.1260879016.2239.help-gnu-emacs@gnu.org>
2009-12-15 19:54 ` Pascal J. Bourguignon
2009-12-15 20:38 ` Sergei Organov
[not found] ` <mailman.13027.1260909564.2239.help-gnu-emacs@gnu.org>
2009-12-15 21:12 ` Barry Margolin
2009-12-16 11:27 ` Sergei Organov
[not found] ` <mailman.13051.1260962896.2239.help-gnu-emacs@gnu.org>
2009-12-17 16:52 ` Barry Margolin
2009-12-11 13:22 Sergei Organov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.