From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.eieio,gmane.emacs.devel Subject: Re: Cleaning up the EIEIO namespace Date: Thu, 14 Feb 2013 17:17:50 -0500 Message-ID: References: <87sj51fakd.fsf@engster.org> <87k3qcfa4x.fsf@engster.org> <87zjz6egb2.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1360880278 7934 80.91.229.3 (14 Feb 2013 22:17:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Feb 2013 22:17:58 +0000 (UTC) Cc: "Eric M. Ludlam" , emacs-devel@gnu.org To: cedet-eieio@lists.sourceforge.net Original-X-From: cedet-eieio-bounces@lists.sourceforge.net Thu Feb 14 23:18:19 2013 Return-path: Envelope-to: sf-cedet-eieio@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U678F-0003f3-0i for sf-cedet-eieio@m.gmane.org; Thu, 14 Feb 2013 23:18:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U677u-0003vS-LW; Thu, 14 Feb 2013 22:17:58 +0000 Original-Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U677t-0003vH-Mz for cedet-eieio@lists.sourceforge.net; Thu, 14 Feb 2013 22:17:57 +0000 Received-SPF: softfail (sog-mx-1.v43.ch3.sourceforge.com: transitioning domain of iro.umontreal.ca does not designate 206.248.154.182 as permitted sender) client-ip=206.248.154.182; envelope-from=monnier@iro.umontreal.ca; helo=ironport2-out.teksavvy.com; Original-Received: from [206.248.154.182] (helo=ironport2-out.teksavvy.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U677s-0004Wk-G4 for cedet-eieio@lists.sourceforge.net; Thu, 14 Feb 2013 22:17:57 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKjI/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDYhCBsEtjWGDKQOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFxKjI/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDYhCBsEtjWGDKQOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="1442345" Original-Received: from 69-196-168-200.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.200]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 14 Feb 2013 17:17:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 93DD66D7F4; Thu, 14 Feb 2013 17:17:50 -0500 (EST) In-Reply-To: <87zjz6egb2.fsf@engster.org> (David Engster's message of "Thu, 14 Feb 2013 22:28:17 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.0 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1U677s-0004Wk-G4 X-BeenThere: cedet-eieio@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cedet-eieio-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.eieio:144 gmane.emacs.devel:157037 Archived-At: >>> In toplevel form: >>> eieio.el:168:1:Error: Symbol's function definition is void: eieio--class-parent >> Can you (setq byte-compile-error t debug-on-error t) so as to get >> a backtrace? > Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just > don't get a backtrace with debug-on-error. No, I meant byte-compile-debug sorry. >>> I also cannot find a definition for eieio--class-parent, but maybe it's >>> hidden somewhere? >> It's defined (as a macro) by the call to (eieio--define-field-accessors >> class ...) which is kind of a "mini cl-defstruct". > I see. Now, I can compile your patched EIEIO with trunk, but using the > latest pretest gives me the above error. I can fix this by including the > define-field-accessor macro and its following two calls (for class and > object) in the 'eval-and-compile' clause. Not sure if that's the right > thing to do, though. Something must have changed in trunk in how this is > handled? Let me get back to you on this one, later, Stefan ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb