headers
Kenichi Handa | 9 Sep 01:32

synchronizing emacs-unicode branch to HEAD

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.

---
(Continue reading)

Permalink | Reply | 20 comments |
headers
Andreas Schwab | 9 Sep 11:59
Picon
Favicon

Re: synchronizing emacs-unicode branch to HEAD

Kenichi Handa <handa <at> 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;
 }
(Continue reading)

Permalink | Reply | 11 comments |
headers
Kenichi Handa | 9 Sep 14:12

Re: synchronizing emacs-unicode branch to HEAD

In article <jebrtuqo40.fsf <at> sykes.suse.de>, Andreas Schwab <schwab <at> suse.de> writes:
> Kenichi Handa <handa <at> 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 <at> m17n.org
Permalink | Reply | 5 comments |
headers
Andreas Schwab | 9 Sep 14:44
Picon
Favicon

Re: synchronizing emacs-unicode branch to HEAD

Kenichi Handa <handa <at> 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 <at> 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."
Permalink | Reply | 1 comment |
headers
Dave Love | 9 Sep 21:02
Picon
Picon

Re: synchronizing emacs-unicode branch to HEAD

Andreas Schwab <schwab <at> 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.]
Permalink | Reply | 2 comments |
headers
Dave Love | 9 Sep 21:04
Picon
Picon

Re: synchronizing emacs-unicode branch to HEAD

Kenichi Handa <handa <at> 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.
Permalink | Reply | 0 comments |
headers
Andreas Schwab | 9 Sep 21:51
Picon
Favicon

Re: synchronizing emacs-unicode branch to HEAD

Dave Love <d.love <at> 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 <at> 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."
Permalink | Reply | 0 comments |
headers
Miles Bader | 9 Sep 22:32
Picon
Gravatar

Re: synchronizing emacs-unicode branch to HEAD

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
Permalink | Reply | 2 comments |
headers
Eli Zaretskii | 11 Sep 20:28
Picon

Re: synchronizing emacs-unicode branch to HEAD

> Date: Tue, 9 Sep 2003 08:32:34 +0900 (JST)
> From: Kenichi Handa <handa <at> 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).
Permalink | Reply | 0 comments |

Gmane