* Re: synchronizing emacs-unicode branch to HEAD
2003-09-08 23:32 synchronizing emacs-unicode branch to HEAD Kenichi Handa
@ 2003-09-09 9:59 ` Andreas Schwab
2003-09-09 12:12 ` Kenichi Handa
2003-09-09 19:02 ` Dave Love
2003-09-09 20:32 ` Miles Bader
` (2 subsequent siblings)
3 siblings, 2 replies; 13+ messages in thread
From: Andreas Schwab @ 2003-09-09 9:59 UTC (permalink / raw
Cc: emacs-unicode, d.love, emacs-bidi, emacs-devel
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."
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 9:59 ` Andreas Schwab
@ 2003-09-09 12:12 ` Kenichi Handa
2003-09-09 12:44 ` Andreas Schwab
2003-09-09 19:04 ` Dave Love
2003-09-09 19:02 ` Dave Love
1 sibling, 2 replies; 13+ messages in thread
From: Kenichi Handa @ 2003-09-09 12:12 UTC (permalink / raw
Cc: emacs-bidi, emacs-unicode, d.love, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 12:12 ` Kenichi Handa
@ 2003-09-09 12:44 ` Andreas Schwab
2003-09-16 2:27 ` Kenichi Handa
2003-09-09 19:04 ` Dave Love
1 sibling, 1 reply; 13+ messages in thread
From: Andreas Schwab @ 2003-09-09 12:44 UTC (permalink / raw
Cc: emacs-bidi, emacs-unicode, d.love, emacs-devel
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."
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 12:44 ` Andreas Schwab
@ 2003-09-16 2:27 ` Kenichi Handa
0 siblings, 0 replies; 13+ messages in thread
From: Kenichi Handa @ 2003-09-16 2:27 UTC (permalink / raw
Cc: d.love, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 12:12 ` Kenichi Handa
2003-09-09 12:44 ` Andreas Schwab
@ 2003-09-09 19:04 ` Dave Love
1 sibling, 0 replies; 13+ messages in thread
From: Dave Love @ 2003-09-09 19:04 UTC (permalink / raw
Cc: schwab, emacs-unicode, emacs-bidi, emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 9:59 ` Andreas Schwab
2003-09-09 12:12 ` Kenichi Handa
@ 2003-09-09 19:02 ` Dave Love
2003-09-09 19:51 ` Andreas Schwab
1 sibling, 1 reply; 13+ messages in thread
From: Dave Love @ 2003-09-09 19:02 UTC (permalink / raw
Cc: emacs-unicode, emacs-devel, emacs-bidi, Kenichi Handa
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.]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 19:02 ` Dave Love
@ 2003-09-09 19:51 ` Andreas Schwab
0 siblings, 0 replies; 13+ messages in thread
From: Andreas Schwab @ 2003-09-09 19:51 UTC (permalink / raw
Cc: emacs-unicode, emacs-devel, emacs-bidi, Kenichi Handa
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."
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-08 23:32 synchronizing emacs-unicode branch to HEAD Kenichi Handa
2003-09-09 9:59 ` Andreas Schwab
@ 2003-09-09 20:32 ` Miles Bader
2003-09-10 1:15 ` Kenichi Handa
2003-09-11 9:21 ` Dave Love
2003-09-11 18:28 ` Eli Zaretskii
3 siblings, 1 reply; 13+ messages in thread
From: Miles Bader @ 2003-09-09 20:32 UTC (permalink / raw
Cc: emacs-unicode, d.love, emacs-bidi, emacs-devel
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 raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-09 20:32 ` Miles Bader
@ 2003-09-10 1:15 ` Kenichi Handa
2003-09-10 2:25 ` Miles Bader
0 siblings, 1 reply; 13+ messages in thread
From: Kenichi Handa @ 2003-09-10 1:15 UTC (permalink / raw
Cc: d.love, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-10 1:15 ` Kenichi Handa
@ 2003-09-10 2:25 ` Miles Bader
0 siblings, 0 replies; 13+ messages in thread
From: Miles Bader @ 2003-09-10 2:25 UTC (permalink / raw
Cc: d.love, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-08 23:32 synchronizing emacs-unicode branch to HEAD Kenichi Handa
2003-09-09 9:59 ` Andreas Schwab
2003-09-09 20:32 ` Miles Bader
@ 2003-09-11 9:21 ` Dave Love
2003-09-11 18:28 ` Eli Zaretskii
3 siblings, 0 replies; 13+ messages in thread
From: Dave Love @ 2003-09-11 9:21 UTC (permalink / raw
Cc: emacs-unicode, emacs-devel
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"))))
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: synchronizing emacs-unicode branch to HEAD
2003-09-08 23:32 synchronizing emacs-unicode branch to HEAD Kenichi Handa
` (2 preceding siblings ...)
2003-09-11 9:21 ` Dave Love
@ 2003-09-11 18:28 ` Eli Zaretskii
3 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2003-09-11 18:28 UTC (permalink / raw
Cc: emacs-unicode, d.love, emacs-bidi, emacs-devel
> 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).
^ permalink raw reply [flat|nested] 13+ messages in thread