Re: Final version of dumper fixes patch

Why is this discussion happening on -review? [To those viewers who have just joined us, Martin and Olivier are seriously messing around with the pdumper. Olivier assures me that even if the code Martin is writing has "accidental" bugs, it is much more maintainable, so The Release Manager has approved it for the upcoming release as "contributing to stability in expectation". However, the thread has degenerated into a design discussion....] OG> Please, let's stay realist here :-) mb> OK, I'll confess. I'm secretly pining for an xemacs that has mb> 63-bit lisp ints on a 32-bit system. Let's not go there. Why stop at 63? Anyway with that many bits, I'm going to demand ISO 100646 characters, which require 63 bits. You only get 62 ;-) Please, implement bignums instead. mb> I actually don't like the assumption mb> sizeof (EMACS_INT) == sizeof (void *) I like it a lot. The kinds of things that real people do with XEmacs work fine with the current structure; 32 bits is enough for almost any daily-life task. The few things that real people do that require more (computing the number of salt molecules in a mole of yoghurt, for example) generally don't require efficient calculation. The main example I can think of is Hrvoje's sysadmin with humongous logs. However, neither humans nor the programs they write to deal with them normally need random access; with sensible buffering strategies it will normally be possible to deal with these things using normal XEmacs techniques. mb> Removing that assumption will take some work, though... Work which will never appear in an XEmacs I release.... Nyaah, nyaah, nyaah. :-P -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."