From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.help Subject: Re: Can't compile Date: Tue, 27 Feb 2007 20:16:37 -0700 Message-ID: References: <1172489074.509174.190590@t69g2000cwt.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1172632655 2630 80.91.229.12 (28 Feb 2007 03:17:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2007 03:17:35 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Feb 28 04:17:28 2007 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 1HMFJm-0004xA-85 for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Feb 2007 04:17:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMFJm-0004RJ-3i for geh-help-gnu-emacs@m.gmane.org; Tue, 27 Feb 2007 22:17:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HMFJH-00048u-5S for help-gnu-emacs@gnu.org; Tue, 27 Feb 2007 22:16:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HMFJE-00045F-Gb for help-gnu-emacs@gnu.org; Tue, 27 Feb 2007 22:16:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HMFJE-000450-Aq for help-gnu-emacs@gnu.org; Tue, 27 Feb 2007 22:16:52 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HMFJD-0002Gh-VK for help-gnu-emacs@gnu.org; Tue, 27 Feb 2007 22:16:52 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HMFJ2-0003S5-Ox for help-gnu-emacs@gnu.org; Wed, 28 Feb 2007 04:16:40 +0100 Original-Received: from c-24-9-156-178.hsd1.co.comcast.net ([24.9.156.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 04:16:40 +0100 Original-Received: from kevin.d.rodgers by c-24-9-156-178.hsd1.co.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Feb 2007 04:16:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-24-9-156-178.hsd1.co.comcast.net User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) In-Reply-To: <1172489074.509174.190590@t69g2000cwt.googlegroups.com> X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:41519 Archived-At: Robert Thorpe wrote: > On Feb 24, 10:28 am, Xavier Maillard wrote: >> Hi, >> >> I am trying to byte-compile nero.el[1] but it just fails with >> this error: >> >> In nero-restore-match: >> nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs >> 22.1); use `string-to-number' instead. >> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers >> make: *** [nero.elc] Error 1 >> >> The first warning is easy to fix (and I fixed it) but what about >> the second error ? > > I don't know anything about this code, but what is shown here is a > rather common lisp error. > > The function nero-follow-numbers is used in a macro. This macro is > used in the file/compilation block nero.elc. > The bytecompiler works on a per file basis. It compiles each of the > defuns to bytecodes completing it's actions once the file is > finished. Macros though must be expanded when the code is being read, > at this stage the defuns in the file have not yet been finalised. > > This works fine for the normal evalutator because it finalises and > installs a function at the end of the defun form. > > This is why "eval-and-compile" is needed. A cleaner design would be for the macro to return a form that contains a call to the function, rather calling the function during macro expansion to generate the returned form. -- Kevin Rodgers Denver, Colorado, USA