Problem advising nreverse.

Problem advising nreverse.

[Sergei Organov]

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? 

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Kevin Rodgers]

[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

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Pascal J. Bourguignon]

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__

Re: Problem advising nreverse.

[Sergei Organov]

> 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.

Re: Problem advising nreverse.

[Barry Margolin]

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 ***

Re: Problem advising nreverse.

[Sergei Organov]

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.

Re: Problem advising nreverse.

[Barry Margolin]

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 ***