1:31 a.m.
Olivier Galibert <galibert(a)pobox.com> writes:
I'd like to see --use-minimal-tagbits being default, and the
other
alternative actually removed.
I don't think minimal tagbits should be default, because I don't see
any good reasons to make them so before the new dumper is written.
Yes, performance is equivalent (although I don't remember any actual
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
free lists.
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.
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.
* it removes the need for DATA_SEG_BITS which, basically, sucks
* it makes purify-like memory leak detection possible
I won't comment the first reason, but if you want to purify XEmacs,
nothing stops you from using minimal tagbits.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Sauron is alive in Argentina!
2 a.m.
New subject: Plea for minimal tagbits
On Thu, Apr 30, 1998 at 02:31:27AM +0200, Hrvoje Niksic wrote:
Olivier Galibert <galibert(a)pobox.com> writes:
> I'd like to see --use-minimal-tagbits being default, and the other
> alternative actually removed.
I don't think minimal tagbits should be default, because I don't see
any good reasons to make them so before the new dumper is written.
You missed the main point. When in code freeze mode, we should choose
one of the options and stay with it. Or we have twice the number of
tests to do.
OG.
5:41 a.m.
New subject: Plea for minimal tagbits
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> 31-bit integers are nice, but they are hardly that
Hrvoje> important to a normal user.
But when Olivier gets his UCS-4 text manipulation stuff working....
Although extremely few users will want to use UCS-4 for itself, the
least buggy quick path to a wide-char Mule in multilingual contexts
uses UCS-4 in the implementation. UCS-4 characters, by a strange
coincidence, just barely fit into a 31-bit integer.
Unifying the Han ideographs through UCS-2/Unicode is possible, but
will surely introduce new coding-system I/O bugs. The UCS-4 approach
will allow us to change the current low-level buffer implementation
with minimal impact on higher-level Mule code by preserving the
coding-system information at the character level as the current Mule
implementation does.
I think there's a pretty good argument here for pushing at least for
Mule builds to get minimal tagbits by default, maybe not for 21.x, but
soon.
6:04 a.m.
New subject: Plea for minimal tagbits
On Thu, Apr 30, 1998 at 01:41:39PM +0900, Stephen J. Turnbull wrote:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> 31-bit integers are nice, but they are hardly that
Hrvoje> important to a normal user.
But when Olivier gets his UCS-4 text manipulation stuff working....
Although extremely few users will want to use UCS-4 for itself, the
least buggy quick path to a wide-char Mule in multilingual contexts
uses UCS-4 in the implementation. UCS-4 characters, by a strange
coincidence, just barely fit into a 31-bit integer.
Errr, didn't we agree that 0-FFFFFF (aka, 24 bits) was enough ?
Maximal tagbits have 24bits characters, minimal tagbits 30bits ones
(and not 31, that's only for integers).
The 6 added bits may be useful later for ucs-2000 though. I don't know
(nor they seem to know themselves :-) how far they want to go.
Unifying the Han ideographs through UCS-2/Unicode is possible, but
will surely introduce new coding-system I/O bugs. The UCS-4 approach
will allow us to change the current low-level buffer implementation
with minimal impact on higher-level Mule code by preserving the
coding-system information at the character level as the current Mule
implementation does.
Sorry but I don't parse that.
I think there's a pretty good argument here for pushing at least
for
Mule builds to get minimal tagbits by default, maybe not for 21.x, but
soon.
I'm not sure about that. Remember that what I'm writing is still
vaporware and should be considered as such as long as I don't give out
patches. I don't want to see implementation choices done solely on the
basis of things that may exist someday.
OG.
7 a.m.
New subject: Plea for minimal tagbits
>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
On Thu, Apr 30, 1998 at 01:41:39PM +0900, Stephen J. Turnbull wrote:
> Although extremely few users will want to use UCS-4 for itself,
> the least buggy quick path to a wide-char Mule in multilingual
> contexts uses UCS-4 in the implementation. UCS-4 characters,
> by a strange coincidence, just barely fit into a 31-bit
> integer.
OG> Errr, didn't we agree that 0-FFFFFF (aka, 24 bits) was enough
OG> ? Maximal tagbits have 24bits characters, minimal tagbits
OG> 30bits ones (and not 31, that's only for integers).
OK, I retract that, then. I forgot about "Ebola". I was thinking
that we could avoid a bunch of masking operations by using 31-bit
characters. But even if it's only one bit, we're going to have to do
it.
> Unifying the Han ideographs through UCS-2/Unicode is possible,
> but will surely introduce new coding-system I/O bugs.
OG> Sorry but I don't parse that.
The point is that putting the external coding system tag on an extent
property (as I have suggested) requires the higher-level Mule code to
test the extent property. Since the extent is different from the
character, the access operation introduces a potential for confusion
and bugs. Doing it efficiently suggests that functions that operate
on regions or strings should remember the relevant extents.
Current implementation of Mule looks at bufchars one-by-one as far as
I can remember. Your UCS-4 scheme lends itself to direct integration
into the current higher level interface more so than the UCS-2 +
extents scheme I've advocated.
> I think there's a pretty good argument here
OG> I don't want to see implementation choices done solely on the
OG> basis of things that may exist someday.
You're right.
9:56 a.m.
New subject: Plea for minimal tagbits
>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
OG> Errr, didn't we agree that 0-FFFFFF (aka, 24 bits) was enough ?
OG> Maximal tagbits have 24bits characters, minimal tagbits 30bits ones
OG> (and not 31, that's only for integers).
There's a misunderstanding here. At one time there were only 24
valbits, but modern emacsen have 28 valbits, allowing for buffers much
bigger than 8MB.
Martin
9:58 a.m.
New subject: Plea for minimal tagbits
On Thu, Apr 30, 1998 at 01:56:51AM -0700, Martin Buchholz wrote:
>>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
OG> Errr, didn't we agree that 0-FFFFFF (aka, 24 bits) was enough ?
OG> Maximal tagbits have 24bits characters, minimal tagbits 30bits ones
OG> (and not 31, that's only for integers).
There's a misunderstanding here. At one time there were only 24
valbits, but modern emacsen have 28 valbits, allowing for buffers much
bigger than 8MB.
I can't count. 32-1(mark)-3(type)=28. *Autolart*.
128Mb buffers. More reasonable.
OG.
6:44 a.m.
New subject: Plea for minimal tagbits
On Thu, Apr 30, 1998 at 02:31:27AM +0200, Hrvoje Niksic wrote:
I don't think minimal tagbits should be default, because I
don't see
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
actual
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
free lists.
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
XEmacs,
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.
OG.
9703
days inactive
9703
days old
7 comments
4 participants
participants (4)
-
Hrvoje Niksic -
Martin Buchholz -
Olivier Galibert -
Stephen J. Turnbull