From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/78337 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: bizarre byte-compile issue, possibly due to EIEIO Date: Mon, 04 Apr 2011 17:34:10 +0200 Message-ID: <87tyeeyqrx.fsf@randomsample.de> References: <87hbahww99.fsf@lifelogs.com> <8762qxo4l3.fsf@lifelogs.com> <87lizs9w5e.fsf@randomsample.de> <87sjtzznil.fsf@randomsample.de> <8762qub9q5.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301931316 12423 80.91.229.12 (4 Apr 2011 15:35:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2011 15:35:16 +0000 (UTC) Cc: emacs-devel@gnu.org, ding@gnus.org To: Ted Zlatanov Original-X-From: ding-owner+M26643@lists.math.uh.edu Mon Apr 04 17:35:12 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q6lo7-0002Lt-0P for ding-account@gmane.org; Mon, 04 Apr 2011 17:35:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Q6lo2-00006v-2H; Mon, 04 Apr 2011 10:35:06 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Q6lo0-00006h-TT for ding@lists.math.uh.edu; Mon, 04 Apr 2011 10:35:04 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Q6lnw-0006Ia-Hd for ding@lists.math.uh.edu; Mon, 04 Apr 2011 10:35:04 -0500 Original-Received: from v3-1008.vxen.de ([79.140.41.8]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Q6lnv-0003E9-PL for ding@gnus.org; Mon, 04 Apr 2011 17:34:59 +0200 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=jWg1m8RNnf9Xwhm/YUXg6S8OYecThi0NPfDI1D9dJ/8=; b=i3fxyFabC8jmCE7ydqYUxsngWiMP3WOkT4lUCuIoguVymk535SMvdgud/QS+B0qH3yoJpMMdXCHsPPJp0861Gep+fYiexV+jZ6QZ/FLtOMWiggNEbC58ohgDXs2s9ccc; Original-Received: from dslc-082-083-056-181.pools.arcor-ip.net ([82.83.56.181] helo=spaten) by v3-1008.vxen.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Q6lnv-0001Br-1Q; Mon, 04 Apr 2011 17:34:59 +0200 In-Reply-To: <8762qub9q5.fsf@lifelogs.com> (Ted Zlatanov's message of "Mon, 04 Apr 2011 05:18:42 -0500") User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Mail-Copies-To: never Mail-Followup-To: Ted Zlatanov , emacs-devel@gnu.org, ding@gnus.org X-Spam-Score: -2.0 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:78337 gmane.emacs.devel:138122 Archived-At: Ted Zlatanov writes: > On Sun, 03 Apr 2011 11:34:42 +0200 David Engster wrote: > > DE> Here's what I observe: > > DE> * The 'mapcar' method always works. > DE> * If you don't byte-compile, the 'loop' method will also work. > DE> * If you byte-compile, the 'loop' method will fail with Emacs24 *before* > DE> the lexbind merge. After the lexbind merge, it works as expected. > > Of course, I found and reported all of this right before the lexbind > merge. Argh. Yes, but we can't be sure the "real bug" has been fixed here... > DE> Note that the :initform evaluation will not work with the EIEIO version > DE> which ships with Emacs23. I remember some discussions regarding this > DE> issue; it's probably best to use an explicit constructor. I included it > DE> in the test case (you have to uncomment it). When using the class w/ > DE> constructor, you can also compile it under Emacs23, and the 'loop' > DE> method will then also fail. > > When I use the explicit constructor (commented out right now), many > tests fail. Do you want to take a look at that? It's the only > remaining merge blocker. I wasn't thinking. The constructor has to check if there was an initarg provided for 'data', otherwise it will overwrite it. Hence you have to use something like (defmethod initialize-instance :after ((this registry-db) slots) "Set value of data slot of THIS after initialization." ;; 'data' will already be set if read from file, so don't overwrite it. (with-slots (data tracker) this (unless (member :data slots) (setq data (make-hash-table :size 10000 :rehash-size 2.0 :test 'equal))) (unless (member :tracker slots) (setq tracker (make-hash-table :size 100 :rehash-size 2.0))))) This is also why you shouldn't set the other slot values here. BTW, you can use :type hash-table for 'tracker' and 'data'. It will then use 'hash-table-p' for checking the provided argument. > DE> The funny thing is that Emacs24 *after* the lexbind merge cannot run > DE> that byte-compiled code from Emacs23; is that to be expected? > > I would assume major versions introduce binary incompatibilities, so I > wouldn't worry about that. The docs say: "In general, any version of Emacs can run byte-compiled code produced by recent earlier versions of Emacs, but the reverse is not true." So I'm guessing this is one exception from this general rule. :-) -David