Re: bizarre byte-compile issue, possibly due to EIEIO

[David Engster]

Ted Zlatanov writes:
> On Sun, 03 Apr 2011 11:34:42 +0200 David Engster <address@hidden> 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