From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: please consider emacs-unicode for pervasive changes Date: 24 Jul 2002 00:24:10 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027466736 24619 127.0.0.1 (23 Jul 2002 23:25:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2002 23:25:36 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17X927-0006Oy-00 for ; Wed, 24 Jul 2002 01:25:35 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17X9Ge-0001nV-00 for ; Wed, 24 Jul 2002 01:40:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17X91z-00017U-00; Tue, 23 Jul 2002 19:25:27 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17X90s-00016c-00 for ; Tue, 23 Jul 2002 19:24:18 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 17X90k-0007BO-00; Wed, 24 Jul 2002 00:24:10 +0100 Original-To: Ken Raeburn Original-Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5999 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5999 Ken Raeburn 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.