Re: modules anyone?

JV> wmperry(a)aventail.com (William M. Perry) writes: JV> Steve's postgress code I guess. JV> Does that also include an option where they still get linked into the JV> core? Would it be possible to leave the source files in src (is also JV> more convenient for grep'ping?) JV> More importantly is that Martin made the number of lrecord types a JV> compile time constant. Of course that does not matter for modules that JV> are basically lazy loaded parts of the core. Oops.... I just noticed that Olivier got rid of last_lrecord_type_assigned (a C variable), and replaced it with lrecord_type_count (a C compile-time constant). Olivier, this was not my intent with the changes to use compile-time constants for lisp object type identification. The idea was that future code in a module could define a new lrecord type dynamically, and increment last_lrecord_type_assigned. So it actually makes sense for last_lrecord_type_assigned to be initialized to lrecord_type_count and never subsequently modified in any code shipped with XEmacs, and for various bits of code to use last_lrecord_type_assigned instead of lrecord_type_count. Of course, it doesn't make sense for modules to be loaded before being dumped, so the dumper could use either symbol. However, it seems cleaner to use last_lrecord_type_assigned. I suggest you resurrect last_lrecord_type_assigned. On the other hand, this will only become significant if some third party wants a module that defines its own lisp object type, and in practice this is unlikely to happen. Given that getting 21.2 out should be our main goal, making this architectural change has no urgency. However, at least a comment should be added to the appropriate places in the code. I leave the choice to Olivier. Martin