From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: Problem advising nreverse. Date: Mon, 14 Dec 2009 16:23:52 +0100 Organization: Informatimago Message-ID: <873a3dmvef.fsf@galatea.local> References: <87skbg8jww.fsf@galatea.local> <87bpi1n1z7.fsf@galatea.local> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260805248 10168 80.91.229.12 (14 Dec 2009 15:40:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Dec 2009 15:40:48 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Dec 14 16:40:41 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NKD2P-00060W-Al for geh-help-gnu-emacs@m.gmane.org; Mon, 14 Dec 2009 16:40:41 +0100 Original-Received: from localhost ([127.0.0.1]:59972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKD2P-0008F8-5e for geh-help-gnu-emacs@m.gmane.org; Mon, 14 Dec 2009 10:40:41 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 113 Original-X-Trace: individual.net tEobRsREul7wc4Ki0KKPzAtZzjZNrXOPNnRIQ+yCY4MUIXnVyK Cancel-Lock: sha1:YzkyNzBlMzNlZThiYWNmZDZkYTdlOTg1NjdlODJiMWRlZjIzZGU4OQ== sha1:P0opwPsHo4pTNsIAN0ekCkvWvYE= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Original-Xref: news.stanford.edu gnu.emacs.help:175564 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70641 Archived-At: Sergei Organov writes: > pjb@informatimago.com (Pascal J. Bourguignon) writes: > >> Sergei Organov writes: >> >>> pjb@informatimago.com (Pascal J. Bourguignon) writes: >>>> Sergei Organov 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__