synchronizing emacs-unicode branch to HEAD

synchronizing emacs-unicode branch to HEAD

[Kenichi Handa]

About a month ago, I made a branch emacs-unicode-2 from HEAD
and started to work on synchronizing codes of emacs-unicode
branch to HEAD in that new branch.

I've just finished the work and committed the changes.
Changelog files are named as "ChangeLog.22" for the moment.
So, putting this kind of code in your .emacs will make "C-x
4 a" work well when you add changelog for this version of
emacs by using this emacs.

(eval-after-load "add-log"
  '(defun change-log-name ()
     (if (= emacs-major-version 22)
	 "ChangeLog.22"
       "ChangeLog")))

I hope this branch can be merged into HEAD before the HEAD
branch is changed drastically.

To those who have checked out emacs-unicode branch:

That branch is now obsolete.  Please check out the branch
emacs-unicode-2.

To Eli,

I'll start merging emacs-bidi code into emacs-unicode-2
branch soon.  Please send me your BIDI reordering code.

---
Ken'ichi HANDA
handa@m17n.org

Re: synchronizing emacs-unicode branch to HEAD

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> That branch is now obsolete.  Please check out the branch
> emacs-unicode-2.

I'm getting a crash on ia64 during bootstrap while the lisp files are
compiled.  I can fix it with the patch below, but it is probably not the
right fix.  I guess one of the c_functions is not GC clean, but I haven't
been able to find out which one.

--- chartab.c.~1.1.4.1.~	2003-09-09 10:27:16.000000000 +0200
+++ chartab.c	2003-09-09 11:41:35.000000000 +0200
@@ -773,8 +773,10 @@ map_char_table (c_function, function, ta
 {
   Lisp_Object range, val;
   int c, i;
+  struct gcpro gcpro1;
 
   range = Fcons (make_number (0), Qnil);
+  GCPRO1 (range);
   val = XCHAR_TABLE (table)->ascii;
   if (SUB_CHAR_TABLE_P (val))
     val = XSUB_CHAR_TABLE (val)->contents[0];
@@ -818,6 +820,8 @@ map_char_table (c_function, function, ta
       else
 	call2 (function, range, val);
     }
+
+  UNGCPRO;
 }
 
 DEFUN ("map-char-table", Fmap_char_table, Smap_char_table,

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: synchronizing emacs-unicode branch to HEAD

[Kenichi Handa]

In article <jebrtuqo40.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>  That branch is now obsolete.  Please check out the branch
>>  emacs-unicode-2.

> I'm getting a crash on ia64 during bootstrap while the lisp files are
> compiled.  I can fix it with the patch below, but it is probably not the
> right fix.  I guess one of the c_functions is not GC clean, but I haven't
> been able to find out which one.

Oops, as I've been testing emacs-unicode on GNU/Linux which
defines GC_MARK_STACK to GC_MAKE_GCPROS_NOOPS, I have not
paid match attention to GC cleanness.

I think we can test if c_functions is GC clean or not by
setting and resetting abort_on_gc before and after calling
that function.  Could you do that and verify it?  As I don't
have ia64 machine, I can't test it.

---
Ken'ichi HANDA
handa@m17n.org

Re: synchronizing emacs-unicode branch to HEAD

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> I think we can test if c_functions is GC clean or not by
> setting and resetting abort_on_gc before and after calling
> that function.  Could you do that and verify it?

I'll try.

>  As I don't have ia64 machine, I can't test it.

You can force use of GCPRO on any machine.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: synchronizing emacs-unicode branch to HEAD

[Dave Love]

Andreas Schwab <schwab@suse.de> writes:

> I'm getting a crash on ia64 during bootstrap while the lisp files are
> compiled.  I can fix it with the patch below, but it is probably not the
> right fix.  I guess one of the c_functions is not GC clean, but I haven't
> been able to find out which one.

That looks the right sort of fix to me at a quick glance.  There's
clearly a gcpro missing somewhere.  Mapping over keymaps might cause
autoloading as a possible source of GC.

However, I'm surprised it worked at all.  The head code hasn't built
for some time on any of the three 64-bit systems I have (Solaris,
Irix, Tru64 -- I don't have 64-bit userland installed on Debian
sparc).  This is apparently due to GC changes.  It isn't a gcpro
issue, anyway.  I'd hoped someone with an interest in ia64 would fix
it :-(.

Why not sort out conservative marking on ia64, by the way?  See
comments probably in alloc.c and s/gnu-linux.h.

[This is one of the things that would just fall out of using the Boehm
collector, and I'm sure effort would be better spent on making that
work than messing with the current GC.]

Re: synchronizing emacs-unicode branch to HEAD

[Dave Love]

Kenichi Handa <handa@m17n.org> writes:

> I think we can test if c_functions is GC clean or not by
> setting and resetting abort_on_gc before and after calling
> that function.

If you mean to do gcpro only when it's calling Lisp or specific C, I
doubt that it is worth the trouble, especially as it could break with
a newly-defined c_function.

I don't think it's worth worrying about optimizing use of gcpro.
There are probably no modern systems where it can't be turned off if
anyone cares, at least with gcc.

Re: synchronizing emacs-unicode branch to HEAD

[Andreas Schwab]

Dave Love <d.love@dl.ac.uk> writes:

> However, I'm surprised it worked at all.  The head code hasn't built
> for some time on any of the three 64-bit systems I have (Solaris,
> Irix, Tru64 -- I don't have 64-bit userland installed on Debian
> sparc).  This is apparently due to GC changes.  It isn't a gcpro
> issue, anyway.  I'd hoped someone with an interest in ia64 would fix
> it :-(.

I can't find anything wrong.  It works pretty flawlessly for me.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: synchronizing emacs-unicode branch to HEAD

[Miles Bader]

On Tue, Sep 09, 2003 at 08:32:34AM +0900, Kenichi Handa wrote:
> I hope this branch can be merged into HEAD before the HEAD
> branch is changed drastically.

I'm wondering about the opposite question: should I worry about the unicode
merge, with respect to my own branches?  How pervasive are the changes
(fairly concentrated into certain areas, or affecting every nook-and-cranny
of emacs)?

When I get the time I'll probably import the new unicode branch into arch
and check it out for myself ... actually I suppose you probably merged from
HEAD too early to get my arch-tagging changes; would you mind if I make that
same change to your CVS unicode branch?

Thanks,

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: synchronizing emacs-unicode branch to HEAD

[Kenichi Handa]

In article <20030909203229.GA28335@fencepost>, Miles Bader <miles@gnu.org> writes:

> On Tue, Sep 09, 2003 at 08:32:34AM +0900, Kenichi Handa wrote:
>>  I hope this branch can be merged into HEAD before the HEAD
>>  branch is changed drastically.

> I'm wondering about the opposite question: should I worry about the unicode
> merge, with respect to my own branches?  How pervasive are the changes
> (fairly concentrated into certain areas, or affecting every nook-and-cranny
> of emacs)?

Almost all changes are about character and fontset handling;
charset.[ch], coding.[ch], fontset.c are mostly re-written,
character.[ch] and chartab.c are newly created.  So, if your
change depends on macros in old charset.h and coding.h, you
must pay big attention to the change.  Otherwise, I think
you don't have to worry about the unicode merge that much.

> When I get the time I'll probably import the new unicode branch into arch
> and check it out for myself ... actually I suppose you probably merged from
> HEAD too early to get my arch-tagging changes; would you mind if I make that
> same change to your CVS unicode branch?

I don't mind as far as that change doesn't make future
merging of emacs-unicode-2 into HEAD difficult.

---
Ken'ichi HANDA
handa@m17n.org

Re: synchronizing emacs-unicode branch to HEAD

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> So, if your change depends on macros in old charset.h and coding.h,
> you must pay big attention to the change.  Otherwise, I think you
> don't have to worry about the unicode merge that much.

Cool.

> > I suppose you probably merged from HEAD too early to get my
> > arch-tagging changes; would you mind if I make that same change to
> > your CVS unicode branch?
> 
> I don't mind as far as that change doesn't make future merging of
> emacs-unicode-2 into HEAD difficult.

If I make changes to the unicode branch which I've also made to HEAD,
then there will be be redundant hunks.  In general I think CVS silently
ignores redundant changes (and the tagline changes are pretty well
isolated at the end of files), so this shouldn't cause any problems, but
I'm not entirely sure about the the specific case of `cvs update -j'
(which is what I presume you'll use to do the merge); does anyone know
for sure?

Thanks

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: synchronizing emacs-unicode branch to HEAD

[Dave Love]

Kenichi Handa <handa@m17n.org> writes:

> So, putting this kind of code in your .emacs will make "C-x
> 4 a" work well when you add changelog for this version of
> emacs by using this emacs.

For what it's worth, I did this, having checked out into a directory
`emacs-unicode-2', so it doesn't matter what I do in which version.
However, it seems better to me to have ChangeLog just refer to the
branch, as before.  That way, things like VC and PCL-CVS still work
properly to extract log entries.  Maybe they already have appropriate
hooks or can be changed, but I haven't time to check now.

(add-hook 'find-file-hooks
	  (lambda ()
	    (if (and (buffer-file-name)
		     (string-match "emacs-unicode-2" (buffer-file-name)))
		(set (make-local-variable 'change-log-default-name)
		     "ChangeLog.22"))))

Re: synchronizing emacs-unicode branch to HEAD

[Eli Zaretskii]

> Date: Tue, 9 Sep 2003 08:32:34 +0900 (JST)
> From: Kenichi Handa <handa@m17n.org>
> 
> To Eli,
> 
> I'll start merging emacs-bidi code into emacs-unicode-2
> branch soon.  Please send me your BIDI reordering code.

Done (in a separate private email).

Re: synchronizing emacs-unicode branch to HEAD

[Kenichi Handa]

In article <je65k2p1wb.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>  I think we can test if c_functions is GC clean or not by
>>  setting and resetting abort_on_gc before and after calling
>>  that function.  Could you do that and verify it?

> I'll try.

>>   As I don't have ia64 machine, I can't test it.

> You can force use of GCPRO on any machine.

Ah!  You are right.   Anyway, I found that you already
commited a proper fix.   Thank you.

Dave Love <d.love@dl.ac.uk> writes:
> If you mean to do gcpro only when it's calling Lisp or specific C, I
> doubt that it is worth the trouble, especially as it could break with
> a newly-defined c_function.

> I don't think it's worth worrying about optimizing use of gcpro.
> There are probably no modern systems where it can't be turned off if
> anyone cares, at least with gcc.

Ok, I see.

---
Ken'ichi HANDA
handa@m17n.org