On Thu, Apr 30, 1998 at 02:31:27AM +0200, Hrvoje Niksic wrote:
I don't think minimal tagbits should be default, because I
any good reasons to make them so before the new dumper is written.
*mumble*. I'm going to go and write it if it continues that way.
Yes, performance is equivalent (although I don't remember any
study), but memory usage is not. Minimal tagbits consume more memory
for conses. This will be fixed by Kyle's dumper, which will not dump
Do you mean "lists the garbage collector freed but for which free()
didn't give the memory bakc to the system" ? Or something else ?
31-bit integers are nice, but they are hardly that important to a
normal user. Even so, the configure option is documented in NEWS, so
the interesting parties will be able to test it.
I just remembered a thing. (point) being a integer, it limits the
maximum size of a buffer to 8Mb, right ? I don't have a non-gung-ho
XEmacs handy to test that. More and more binary files are over this
size, and I, and others, often use XEmacs as a binary patcher. The new
1Gb limit can be interesting for a lot of people.
Removing the old code is an even worse idea. While I personally
prefer the code with less #ifdef's, being able to run regression tests
is *crucial*. With the new dumper in place, it will be even more
important for tracking dumper bugs.
What prevents from running regression tests ? I don't follow what you
mean there. *Which* regression tests do you have in mind anyway that
would work with maximal tagbits, not work with minimal ones, and be
useful with the new dumper. I'm afraid I'm completely lost there.
I won't comment the first reason, but if you want to purify
nothing stops you from using minimal tagbits.
Once code freeze activated, I won't, except for my personal hacking,
run anything different than what the distribution will be.