7:53 p.m.
On Mon, 2002-07-15 at 06:41, Katsumi Yamaoka wrote:
>>>>> In [apel-en : No.00015]
>>>>> Ville Skyttä <ville.skytta(a)xemacs.org> wrote:
> this patch to APEL was sent to xemacs-patches(a)xemacs.org, and has
> already been committed to XEmacs CVS. Please consider applying in APEL
> CVS too.
Thank you very much for the forwarding. The patch is correct,
but...
> From: Daiki Ueno <daiki(a)xemacs.org>
> To: Adrian Aichner <adrian(a)xemacs.org>, xemacs-patches(a)xemacs.org
> Subject: [PATCH] packages: Define encode-mime-charset-string as function
> Date: 13 Jul 2002 18:36:56 +0900
> I think this is a bug of APEL. The background is that Liece uses
> encode-mime-charset-string, the function is defined seperately in APEL
> (for MULE and non-MULE), and the version for MULE calls
> mime-charset-to-coding-system with the second argument. Unfortunately
> if the package is compiled for MULE, encode-mime-charset-string is
> inlined into bytecode here:
The problem arises from the difference between the intention of
the developers on APEL and the management policy for the XEmacs
packages. In my interpretation, all emulating functions and
utility functions in APEL will be provided for the particular
version of Emacs in principle, e.g. specialize for Emacs 18.59,
specialize for XEmacs 21.5-b7, etc. It is aimed at a high
performance, not a portability. So, the APEL developers require
user to compile and install APEL for each version of Emacs one
by one. For instance, if APEL provides the function
string-to-char-list supposing that it only exists in XEmacs 21.4
and earlier as follows:
(defun-maybe string-to-char-list (str)
(mapcar #'identity str))
The byte-code for this function will never be produced if the
XEmacs APEL package is compiled with XEmacs 21.4. What should
XEmacs 21.5 users do?
It seems that there are three choices for the future XEmacs:
1. Put APEL in each version of the XEmacs core.
2. Leave APEL out of the XEmacs packages. Users who need to
have APEL should install it by themselves.
3. Rewrite all the APEL modules in order to have a portability
at the sacrifice of a performance.
IMHO, any of these choices doesn't sound too good. Would this one work?
4. Provide the XEmacs apel package without byte-compiled files.
--
\/ille Skyttä
7:29 a.m.
New subject: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Mon, 2002-07-15 at 06:41, Katsumi Yamaoka wrote:
> It seems that there are three choices for the future XEmacs:
> 1. Put APEL in each version of the XEmacs core.
No chance. APEL in practice is a third dialect of Emacs Lisp, similar
to both GNU Emacs Lisp and XEmacs Lisp, but still subtly different. I
can think of three XEmacs Reviewers who would veto that immediately
for the devel branch, and anyway there's no way we can retroactively
install it in existing installations of already released versions.
> 2. Leave APEL out of the XEmacs packages. Users who need to
> have APEL should install it by themselves.
This deserves strong consideration.
> 3. Rewrite all the APEL modules in order to have a portability
> at the sacrifice of a performance.
I don't see a serious performance hit, unless you're writing CGIs for
a high-traffic web site in Elisp. Loading would be negligibly slower,
execution no change, if defun-maybe decided whether to defun at load
time rather than compile time, no? But this would require a lot of
effort from the APEL maintainers (I think XEmacs effort would be far
better devoted to synching with GNU Emacs and making as much of APEL
unnecessary as possible).
Ville> IMHO, any of these choices doesn't sound too good. Would
Ville> this one work?
Ville> 4. Provide the XEmacs apel package without byte-compiled
Ville> files.
No. That's basically a source package, and source packages currently
are completely unsupported. It's hard enough to get a clean compile
environment in the source tree; I think it highly unlikely that we'll
be able to give quality support in the installed tree.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:21 a.m.
New subject: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]
On Tue, 2002-07-16 at 09:29, Stephen J. Turnbull wrote:
>>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Mon, 2002-07-15 at 06:41, Katsumi Yamaoka wrote:
>> It seems that there are three choices for the future XEmacs:
>> 1. Put APEL in each version of the XEmacs core.
No chance. APEL in practice is a third dialect of Emacs Lisp, similar
to both GNU Emacs Lisp and XEmacs Lisp, but still subtly different. I
can think of three XEmacs Reviewers who would veto that immediately
for the devel branch, and anyway there's no way we can retroactively
install it in existing installations of already released versions.
100% agreement.
>> 2. Leave APEL out of the XEmacs packages. Users who
need to
>> have APEL should install it by themselves.
This deserves strong consideration.
Ouch. A grep into the package source tree reveals that mule-base, bbdb,
liece, rmail and tm require apel... maybe they should be "fixed"?
>> 3. Rewrite all the APEL modules in order to have a
portability
>> at the sacrifice of a performance.
(I think XEmacs effort would be far
better devoted to synching with GNU Emacs and making as much of APEL
unnecessary as possible).
Again, agreed.
Ville> IMHO, any of these choices doesn't sound too good.
Would
Ville> this one work?
Ville> 4. Provide the XEmacs apel package without byte-compiled
Ville> files.
No. That's basically a source package, and source packages currently
are completely unsupported. It's hard enough to get a clean compile
environment in the source tree; I think it highly unlikely that we'll
be able to give quality support in the installed tree.
Okay. But I wasn't suggesting that the package would be byte-compiled
at all before it's loaded, neither in the released package or locally
after installation. Wouldn't the .el files be enough, provided that the
package system would really enforce the requirements (fsf-compat,
xemacs-base)? People wanting to byte-compile apel would be on their
own. OTOH, as you noted, I guess this probably wouldn't make our
support task easier.
--
\/ille Skyttä
9:46 a.m.
New subject: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]
apel-en removed because it just bounces for non-members.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Ouch. A grep into the package source tree reveals that
Ville> mule-base, bbdb, liece, rmail and tm require apel... maybe
Ville> they should be "fixed"?
rmail and tm are obsolete; rmail is actively maintained at GNU, but I
don't think anybody here uses it at all. tm is needed for rmail, I
think, and ancient Gnus, and mh-e, and that's about it.
I don't know how hard removing an APEL dependency from any of those
packages would be. For mule-base, we might just want to move it into
core anyway. The other two are externally maintained, so would
require negotiation to "fix". For BBDB at least if we were to remove
that dependency by synching to GNU I bet they'd jump for joy ;-)
Ville> Okay. But I wasn't suggesting that the package would be
Ville> byte-compiled at all before it's loaded, neither in the
Ville> released package or locally after installation. Wouldn't
Ville> the .el files be enough, provided that the package system
Ville> would really enforce the requirements (fsf-compat,
Ville> xemacs-base)?
This is one problem; the package system does _not_ enforce such
requirements. This also is a real performance hit.
Ville> People wanting to byte-compile apel would be on their
Ville> own. OTOH, as you noted, I guess this probably wouldn't
Ville> make our support task easier.
No, and it's really against the philosphy of the packages.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:48 p.m.
New subject: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]
Date: Tue, 16 Jul 2002 17:46:30 +0900
From: "Stephen J. Turnbull" <stephen(a)xemacs.org>
Sender: xemacs-beta-admin(a)xemacs.org
apel-en removed because it just bounces for non-members.
>>>>> "Ville" == Ville Skytt <Ville> writes:
Ville> Ouch. A grep into the package source tree reveals that
Ville> mule-base, bbdb, liece, rmail and tm require apel... maybe
Ville> they should be "fixed"?
rmail and tm are obsolete; rmail is actively maintained at GNU, but I
don't think anybody here uses it at all. tm is needed for rmail, I
think, and ancient Gnus, and mh-e, and that's about it.
Ouch! Some people still use mh-e. And some people still use tm, as
broken as it is. My hooks for mh-e to support exmh are dependent on tm
for MIME support.
I really should re-write all of it in some more current (and less
broken) package, but I am still dependent on tm at the moment.
Maybe I need to look at mew.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman(a)es.net Phone: +1 510 486-8634
6:04 p.m.
New subject: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]
>>>> "Kevin" == Kevin Oberman
<oberman(a)es.net> writes:
Kevin> Ouch! Some people still use mh-e. And some people still use
Kevin> tm, as broken as it is. My hooks for mh-e to support exmh
Kevin> are dependent on tm for MIME support.
We're not going to make anything go away unless we have a migration
path for existing users, no matter how few, or we have no sane
alternative to stranding them.
However, the present situation with APEL is not very sane. I would
really like to reduce dependence on it as much as possible.
Kevin> I really should re-write all of it in some more current
Kevin> (and less broken) package, but I am still dependent on tm
Kevin> at the moment.
Unfortunately there is no general MIME package; all of the various
MUAs do their own thing. larsi went to the extent of writing a whole
new markup language schema for Gnus :-(. SEMI (the successor to tm)
isn't much help on that score.
Kevin> Maybe I need to look at mew.
Let us know if you do; I haven't looked at mew in quite a while.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8166
days inactive
8167
days old
5 comments
3 participants
participants (3)
-
Kevin Oberman -
Stephen J. Turnbull -
Ville Skyttä