[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: please consider emacs-unicode for pervasive changes
From: |
Dave Love |
Subject: |
Re: please consider emacs-unicode for pervasive changes |
Date: |
24 Jul 2002 00:24:10 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Ken Raeburn <address@hidden> writes:
> My string-macro changes, while fairly pervasive, are not as tough to
> make as they might appear. You might be surprised by what can be
> accomplished with a set of regular expressions that correspond to
> various styles of C expressions :-).
I'm not at all surprised, but that's not the point. You're one of the
people I expected actually to understand what such changes entail
practically when it comes to a merge, but it wasn't directed just at
your changes. Even things like straight global exchanges cause
problems in the end. Yes, you _can_ go through all the changes, try
to understand them, and try to duplicate more-or-less the work that
was done originally. But.
> Other changes I'm working on right now are to reduce the uses of SDATA
> that aren't read-only, to make it easier to identify places for
> inserting write-barrier code;
If you want to improve the GC (which would be very useful) what's the
reason for not trying the Boehm collector, as TODO suggests? The
ex-Harlequin Memory Pool System has been released since then, but as
far as I remember it doesn't currently have a suitable licence and I
don't know whether it would be worth considering practically, in
contrast to Boehm's.
> that's a slow and manual process, and
> while by no means as pervasive, still twice as painful if I have to do
> it on a branch as well.
I didn't say anyone else should start a branch, but I don't know
what's being done.
> is that pervasive enough that you want it brought over,
> or small enough to merge later?
Well, if it's slow and painful, I certainly wouldn't want to do it,
especially if I'm not convinced it's going in the right direction.
> It may be better just to say *everything*
> goes into the branch as well as the trunk.
I doubt that's worthwhile for changes that don't go anywhere near Mule
unless they're fixing things which make it difficult actually to run
the branch version (which is the reason I looked at trying to merge
changes which might help).
> I've assumed that when I start work on a Guile branch, I'd be
> responsible for dealing with merges in both directions and all the
> coordination that implies.
Well, I'll give up at that stage.
> It would be helpful for automatic tools or other useful techniques to
> be made available,
I don't know what tool support could help. I think it's basically a
question of management.
> but I wouldn't want to demand that everyone making
> big changes on the trunk also be required to know which branches are
> "active" and how their changes might have to be applied differently to
> those branches, and rewrite their changes to suit.
I disagree. ``CVS is not a substitute for management.''
> If you get around
> to merging in some big changes to the trunk to change the
> character-data handling in ways that better support the Unicode
> changes -- or perhaps the completed set of Unicode changes --
You mean there's some question about that happening, other than the
resources to do it which concerned me? That's not what I understood
when I was pressed to do the Mule work.
> would you want to be required to merge them onto a Guile branch as
> well?
I'm afraid I don't want to waste my time on things related to Guile.
If we're competing against that, I'm going to stop.
Re: please consider emacs-unicode for pervasive changes, Ken Raeburn, 2002/07/18
- Re: please consider emacs-unicode for pervasive changes,
Dave Love <=