[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation to native
From: |
Kenichi Handa |
Subject: |
Re: Compilation to native |
Date: |
Wed, 7 Apr 2004 22:12:43 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, David Kastrup <address@hidden> writes:
> Kenichi Handa <address@hidden> writes:
>> In article <address@hidden>, Richard Stallman <address@hidden> writes:
>>
>> > I thought about a different approach: predefined CCL programs
>> > could be statically converted into C code and compiled by a C
>> > compiler into Emacs core.
>>
>> > It is worth a try. On the other hand, I have to wonder
>> > if the CCL interpreter could be faster.
>>
>> I think there's not much room of improvement in the CCL
>> interpreter (i.e. the function ccl_driver).
>>
>> In addtion, in emacs-unicode, CCL is, by default, used only
>> for Ethiopic font encoding, and it can easily be changed not
>> to use CCL.
>>
>> So, I think it's not that worth working on CCL interpreter.
> If we have a development plan to switch to emacs-unicode soon. We
> really need to get a grip about what should be in the next feature
> release.
> If the unicode and bidi branches are considerable usable, what are we
> waiting for?
I think Unicode branch is fairly usable in normal use. At
least it's stable enough for my daily work. But if it is
used with third party packages, I think some of them must be
adjusted for emacs-unicode.
Bidi branch is far from usable. I created that branch
mainly for that the other people can contribute. It's very
difficult to find a time to work on it for me.
> We are in the situation that currently for many purposes one has to
> tell people "try using CVS". People get more and more to rely on it
> for daily work. This situation is unhealthy. If things like
> emacs-unicode and emacs-bidi are expected to cause longer-lasting
> trouble, then we should crank out something like a full-featured 21.5
> or so just before merging them. If the merge phase leads to longer
> problems, we at least have a somewhat stable release to refer people
> to while we are sorting the problems out.
> If, on the other hand, users and developers of the unicode and bidi
> branches are confident enough that under _normal_ use (i.e., if one
> does not use bidi texts) stability should not be affected much, then
> I'd say "what the heck, give it to us". Maintaining separate branches
> for longer always leads to merging headaches.
I fully agree.
When I synchronized emacs-unicode branch to HEAD a half year
ago, it took about 10 days concentrated work. I think it
will need the same amount of work to merge emacs-unicode to
HEAD. If Richard says "go ahead", I'll manage to make that
time.
---
Ken'ichi HANDA
address@hidden
- Re: Compilation to native, Matthew Mundell, 2004/04/02
- Re: Compilation to native, Kenichi Handa, 2004/04/07
- Re: Compilation to native, David Kastrup, 2004/04/07
- Re: Compilation to native,
Kenichi Handa <=
- Re: Compilation to native, Alex Schroeder, 2004/04/07
- Re: Compilation to native, Kenichi Handa, 2004/04/07
- It is time for a feature freeze (it is NOW or never)., Kim F. Storm, 2004/04/07
- Re: It is time for a feature freeze (it is NOW or never)., Kenichi Handa, 2004/04/07
- Re: It is time for a feature freeze (it is NOW or never)., John Wiegley, 2004/04/07
- Re: It is time for a feature freeze (it is NOW or never)., YAMAMOTO Mitsuharu, 2004/04/08
- Re: It is time for a feature freeze (it is NOW or never)., John Wiegley, 2004/04/08
- Re: It is time for a feature freeze (it is NOW or never)., Piet van Oostrum, 2004/04/08
- Re: It is time for a feature freeze (it is NOW or never)., Jason Rumney, 2004/04/08
- Re: It is time for a feature freeze (it is NOW or never)., Kim F. Storm, 2004/04/08