-----Original Message----- From: Martin Buchholz [mailto:martin＠xemacs.org] Sent: Friday, June 02, 2000 7:43 PM To: Andrew Begel Cc: &#39;xemacs-beta(a)xemacs.org&#39;; Marat Boshernitsan Subject: Re: Dynamic Modules in XEmacs 21.2 >>>>> "AB" == Andrew Begel <abegel(a)cs.berkeley.edu&gt; writes: AB> Ok, here's the next part. My dynamic module needs to define new LRECORD AB> types. In XEmacs 21.2, someone went and changed how this works so that I AB> have to go into the XEmacs source code (lrecord.h) and modify an enum AB> (lrecord_type) to add my types in there. That's lame, and certainly not what AB> I was expecting when writing a dynamic module (that XEmacs shouldn't be AB> required to know about it when i compile Xemacs). AB> In addition, the docs should be updated to note that not only do you have to AB> DECLARE_LRECORD and DEFINE_LRECORD_IMPLEMENTATION, but you also have to now AB> init your new types in syms_of_<module> by INIT_LRECORD_IMPLEMENTATION AB> before you call any DEFSUBR's. I was not aware of a module that defined a new lisp object type. I'm surprised. The intention was for the modules to be able to define new lisp object types, but in view of the lack of an existing such external module, this capability still needs to be completely implemented. The idea was that lrecord.h only contains a list of the *predefined* lisp object types, and a module that adds new lisp object types extends the list and increments the count of lisp object types used in alloc.c and dump.c. Also, there is some implementation inconsistency, since both I and Olivier Galibert have hacked this code.

Would you like to work on this?

For your purposes, it might be easier to modify lrecord.h, depending on where your module is to be used.

AB> Whoever owns the lrecord.h type stuff, will this be changed to enable AB> dynamic modules to declare new LRECORD types? That's the intention. You could provide a patch. Non-built-in lisp object types will have a slight performance penalty. Builtin object types (i.e. those defined in lrecord.h) can have a slightly more efficient FOOP macro, since the lrecord_type index can be compared to a compile-time constant, while types defined at runtime need to be compared to a runtime constant. As a result, non-built-in lisp object types need a slightly different API - the current DEFINE_LRECORD_IMPLEMENTATION and INIT_LRECORD_IMPLEMENTATION won't work without hacking, and perhaps can't be made to work without a performance penalty on all existing code. Martin