Re: Cleaning up the EIEIO namespace

>>>>> 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.
> Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I
> gzipped it.

eieio's extensive abuse of eval-and-compile is a real pain in the rear!
Does the additional patch below make it work for you?


        Stefan


--- lisp/emacs-lisp/eieio.el.orig       2013-02-17 12:06:09.252331190 -0500
+++ lisp/emacs-lisp/eieio.el    2013-02-17 12:06:20.336456193 -0500
@@ -121,10 +121,9 @@
                  (list 'aref x ,index))
               defs)
         (setq index (1+ index))))
-    `(progn
+    `(eval-and-compile
        ,@(nreverse defs)
-       (eval-and-compile
-         (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index)))))
+       (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index))))
 
 (eieio--define-field-accessors class
   (-unused-0 ;;FIXME: not sure, but at least there was no accessor!

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/