Re: [PATCH21.5] Incremental Garbage Collector

BW> -- i think we should go ahead and remove the conditionalization on BW> the parts of your patch that convert internal structures to lisp BW> objects. it won't hurt to have the structures be lisp objects BW> always, even with the old gc, and it will make the code much BW> simpler, as well as easier to maintain OK, I'll remove conditionalization from this parts of my patch. BW> -- my biggest concern is with gc.c. you just copied a lot of BW> stuff from alloc.c, and this tends to lead to bit-rot. is there a BW> way you could conditionalize it so the functions that you need BW> more or less unchanged remain in alloc.c or are split out into BW> some other file? go ahead and put new code in gc.c, but BW> duplicated code is bad bad bad as it leads to bit-rot and BW> maintenance headaches. Yeah, I also don't like the code duplication very much. I'll see what I can do about it. BW> -- once you commit this code, i'll start working on stuff you BW> missed, like in file-coding.c/mule-coding.c, where you have BW> non-Lisp struct coding_stream, which contains a DATA pointer to a BW> separate set of instance data, one per type of coding system, BW> which is also a non-Lisp structure often with Lisp elements in it. BW> I'd suggest reworking this to follow the lead of the main BW> coding-system and specifier objects, and incorporate extra data as BW> part of the object itself, making the object stretchy. that BW> reduces greatly the need to create new objects for each new BW> subtype, and simplifies creation of new subtypes. (I'd suggest BW> doing the same for frame, device, etc. for similar reasons, BW> although that can wait.) Great, I appreciate your help. BW> -- since you are creating a lot of new internal objects, i'd suggest a BW> minor change to the semantics of the object print method. currently BW> if you set it to 0, if calls default_object_printer. for internal BW> objects, which should never escape to Lisp level, we want BW> internal_object_printer instead. currently, even looking among the BW> modules, there is only one object (toolbar-button) that relies on the BW> current behavior by specifying 0 to get default_object_printer, while BW> a number of others (the event-*-data objects -- granted, not currently BW> used) also specify 0 but really want internal_object_printer. your BW> new internal objects do the same. so i'd suggest just changing things BW> in print_internal() to call internal_object_printer when there is no BW> print method, and change the print method for toolbar-button to BW> default_object_printer. I agree, I'll do it this way. BW> overall, thank you very, very much for this work and for your BW> continued commitment to work on generational algorithms and other BW> state-of-the-art stuff! Many thanks, Ben! -- Marcus