From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: cedet-bzr build failure (was : Lexical binding) Date: Sat, 02 Apr 2011 14:40:31 +0200 Message-ID: <871v1kygg0.fsf@engster.org> References: <87vcyxu2o2.fsf@gmail.com> <87aag9acsc.fsf@engster.org> <87wrjd38xm.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1301748101 30820 80.91.229.12 (2 Apr 2011 12:41:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2011 12:41:41 +0000 (UTC) Cc: "Eric M. Ludlam" , emacs-devel@gnu.org To: Darren Hoo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 02 14:41:37 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q608x-0002WD-Vr for ged-emacs-devel@m.gmane.org; Sat, 02 Apr 2011 14:41:32 +0200 Original-Received: from localhost ([127.0.0.1]:40833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q608x-0004mB-It for ged-emacs-devel@m.gmane.org; Sat, 02 Apr 2011 08:41:31 -0400 Original-Received: from [140.186.70.92] (port=39873 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q608t-0004ly-0o for emacs-devel@gnu.org; Sat, 02 Apr 2011 08:41:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q608r-0008H6-QQ for emacs-devel@gnu.org; Sat, 02 Apr 2011 08:41:26 -0400 Original-Received: from v3-1008.vxen.de ([79.140.41.8]:40076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q608r-0008GZ-CU for emacs-devel@gnu.org; Sat, 02 Apr 2011 08:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=UoQEN3ul6KTnZz2m8oKvw6vgULfzN4dfEXdNxB5DwFE=; b=RluenurF1frvJS0aQof5kwp+yFpA8n/GH9bknsxfYJM31BAFHZIffYp/7MdYIgc1SMBaVnPwg4sVe69ZEtw0iDYNLsczSLKq6FJFJlmE8ogCzMcM1kzuZ5b+i2DRJ52t; Original-Received: from dslc-082-082-182-187.pools.arcor-ip.net ([82.82.182.187] helo=spaten) by v3-1008.vxen.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Q608n-0004qa-6E; Sat, 02 Apr 2011 14:41:21 +0200 In-Reply-To: <87wrjd38xm.fsf@gmail.com> (Darren Hoo's message of "Sat, 02 Apr 2011 06:26:13 +0800") User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Mail-Followup-To: Darren Hoo , emacs-devel@gnu.org, "Eric M. Ludlam" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 79.140.41.8 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138057 Archived-At: --=-=-= Content-Type: text/plain Darren Hoo writes: > David Engster writes: > >>> fail to build cedet-bzr after this merge >>> >>> Debugger entered--Lisp error: >>> (wrong-type-argument listp "Forgot to expand macro eieio-object-p") >> >> Inside the cedet-bzr directory, try 'make clean-all' and compile again. >> > hmm, so there are changes in eieio.el in this merge, after I steal the > changes and applied to cedet-bzr, eieio.el now builds successfully, > > But then I got another error: > > In toplevel form: > semantic-grammar-wy.el:169:12:Error: Wrong type argument: listp, "Forgot > to expand macro backquote-list*" Yes, you're right. There was also a change to wisent-comp.el (revno. 100595.1.31; you'll have to use "bzr log -n0" to see it). I attached the patch with the changes for eieio.el and wisent-comp.el to this mail. Eric, do you see a problem with committing those? I also tested compilation with Emacs versions 23 and 22, and it seems to work fine. -David --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=cedet-lexbind.patch === modified file 'eieio/eieio.el' --- eieio/eieio.el 2011-01-27 20:42:06 +0000 +++ eieio/eieio.el 2011-04-02 12:29:01 +0000 @@ -1207,7 +1207,7 @@ (let ((byte-compile-free-references nil) (byte-compile-warnings nil) ) - (byte-compile-lambda + (byte-compile `(lambda (&rest local-args) ,doc-string ;; This is a cool cheat. Usually we need to look up in the === modified file 'semantic/wisent/wisent-comp.el' --- semantic/wisent/wisent-comp.el 2010-04-09 02:08:59 +0000 +++ semantic/wisent/wisent-comp.el 2011-04-02 12:32:40 +0000 @@ -3500,9 +3500,19 @@ ;; automaton internal data structure. Then, because the internal ;; data structure contains an obarray, convert it to a lisp form so ;; it can be byte-compiled. - (byte-compile-form (wisent-automaton-lisp-form (eval form)))) + (byte-compile-form + ;; FIXME: we macroexpand here since `byte-compile-form' expects + ;; macroexpanded code, but that's just a workaround: for lexical-binding + ;; the lisp form should have to pass through closure-conversion and + ;; `wisent-byte-compile-grammar' is called much too late for that. + ;; Why isn't this `wisent-automaton-lisp-form' performed at + ;; macroexpansion time? --Stef + (macroexpand-all + (wisent-automaton-lisp-form (eval form))))) -;;;###autoload +;; FIXME: We shouldn't use a `byte-compile' handler. Maybe using a hash-table +;; instead of an obarray would work around the problem that obarrays +;; aren't printable. Then (put 'wisent-compile-grammar 'side-effect-free t). (put 'wisent-compile-grammar 'byte-compile 'wisent-byte-compile-grammar) (defun wisent-automaton-lisp-form (automaton) --=-=-=--