9:59 p.m.
Hello all
I encounter some problems when working with Gnus under XEmacs Beta. Here
they are:
If I write a new article when running under 21.5.7 from 25. July
ISO-8859-1 is used, only if I use the Euro sign ISO-8859-15 is used, if
I reply to an 8859-1 message and use the Euro everything is send as
8859-15. This is what I want, I needed no special configuration for this
to work.
If I write a new article when running under 21.5.8 from 25. August
ISO-8859-15 is used even if the characters I use all fit into 8859-1, if
I reply to an 8859-1 message everything is always send as 8859-15.
If I write a new article when running under 21.5.9 from 24. September
ISO-8859-9 is used (it's the same as 8859-15 AFAIK) even if the
characters I use all fit into 8859-1, if I reply to an 8859-1 message
the unification is broken, Gnus wants to split the message into several
parts.
Because of this 21.5.8 is unusable for me at the moment. Latin-unity is
installed and up-to-date.
I'm running under Windows, native build, all optional libraries, all
packages installed and updated, you should find build-reports for all
three builds on the build-reports list. Gnus is CVS from yesterday but
should be innocent as everything still works with 21.5.7 (the same Gnus
was used in all three tests).
Any idea what is broken and how to fix it?
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
10:14 p.m.
Frank Schmitt <ich(a)Frank-Schmitt.net> writes:
If I write a new article when running under 21.5.7 from 25. July
ISO-8859-1 is used, only if I use the Euro sign ISO-8859-15 is used, if
I reply to an 8859-1 message and use the Euro everything is send as
8859-15. This is what I want, I needed no special configuration for this
to work.
This should read 05 July
Because of this 21.5.8 is unusable for me at the moment. Latin-unity
is
installed and up-to-date.
and this 21.5.9
I also forgot to mention, that language-environment is set to german,
setting it to ISO-8859-1 doesn't make a difference, the problems occur
as described also if I say xemacs --vanilla.
Frank needs bed, badly.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
6:59 p.m.
For myself, contrarily to what I thought at first try,
(latin-unity-install) did not solve the problem.
So I have hacked lisp/gnus/mm-util.el with this patch :
D:\Local\XEmacs\site-packages\lisp\gnus>diff -u mm-util.el~ mm-util.el
--- mm-util.el~ Fri Sep 27 13:49:10 2002
+++ mm-util.el Fri Sep 27 19:58:08 2002
＠＠ -531,6 +531,9 ＠＠
(mapcar 'mm-mime-charset
(delq 'ascii
(mm-find-charset-region b e))))))
+ (if (and (memq 'iso-8859-1 charsets)
+ (memq 'iso-8859-9 charsets))
+ (push 'iso-8859-15 charsets))
(if (and (memq 'iso-8859-15 charsets)
(memq 'iso-8859-15 hack-charsets)
(save-excursion (mm-iso-8859-x-to-15-region b e)))
But this is ugly. Probably the truth is somewhere else.
--
Fabrice
7:37 a.m.
>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr> writes:
Fabrice> For myself, contrarily to what I thought at first try,
Fabrice> (latin-unity-install) did not solve the problem.
I haven't had any time to work with 21.5. The guts of charset
handling have changed radically, so I really don't know whether
latin-unity buys you anything with 21.5.
Does it really work in other ways on 21.5? I'd love to know.
--
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
10:01 a.m.
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
Does it really work in other ways on 21.5? I'd love to know.
Well, as long as I'm playing only with iso-8859-1, -9 and -15, the
crude patch seems to do it. At least no more multipart messages. The
real trick is that `charsets-in-region' and `charsets-in-string' seems
to do it. If I look a little bit closer, here is what I find with
21.5.9:
(loop with i = 1
while (< i 255)
collect (progn
(incf i)
(char-charset i)))
(ascii ... ascii
control-1 ... control-1
latin-iso8859-1 ... latin-iso8859-1)
All chars as expected are 8859-1 up to 255.
However this one gives only 8859-9 :
(mapcar #'char-charset '(?a ?z ?é ?è ?ç ?à ?ù ?£ ?€ ?â ?ô ?û ?î ?ä ?ü ?ë ?ï ?ö))
(ascii ascii latin-iso8859-9 ... latin-iso8859-9)
Which is confirmed by the fact that :
(mapcar #'char-int '(?a ?z ?é ?è ?ç ?à ?ù ?£ ?€ ?â ?ô ?û ?î ?ä ?ü ?ë ?ï ?ö))
(97 122 1641 1640 1639 1632 1657 1571 1700 1634 1652 1659 1646 1636 1660 1643 1647 1654)
So the chars are actually read as 8859-9. Seems wrong to me. That
should be better either 8859-1 or 8859-15. Or am I wrong ?
--
Fabrice
12:44 p.m.
>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr> writes:
Fabrice> So the chars are actually read as 8859-9. Seems wrong to
Fabrice> me. That should be better either 8859-1 or 8859-15.
Fabrice> Or am I wrong ?
In spirit, no. However, with conventional Mule this is hard to deal
with. What should happen is that all of these characters should map
to an "iso-extended-latin" charset internally, and be translated on
I/O according to the coding system. (This would be fixed
"automagically" if we used a Unicode internal representation, a la
UTF-2000 XEmacs.)
latin-unity actually implements this (crudely) by considering all of
the Latin character sets as a "union" character set (where each
character has multiple internal representations). GNU Emacs 21 allows
you to decide which charset at read time, but I don't think you can
reverse that decision easily as you can with latin-unity.[1]
It looks to me like 21.5's internal implementation differs from 21.4
enough to make latin-unity non-functional. I'll try to get to this
issue soon; I know how important it is.
Footnotes:
[1] latin-unity provides commands for the purpose, but has a number
of bugs that mean it's easier said than done in some cases. However,
it does work for me in many cases -- especially in my test cases. ;-)
--
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
1:03 p.m.
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr>
>>>>> writes:
Fabrice> So the chars are actually read as 8859-9.
Seems wrong to
Fabrice> me. That should be better either 8859-1 or 8859-15. Or am I
Fabrice> wrong ?
In spirit, no.
I understand that. But what is the point in saying that (é) \'e is
latin-9 ? It was latin-1 before being latin-9 ...
1:04 p.m.
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr>
>>>>> writes:
Fabrice> So the chars are actually read as 8859-9.
Seems wrong to
Fabrice> me. That should be better either 8859-1 or 8859-15. Or am I
Fabrice> wrong ?
In spirit, no.
I understand that. But what is the point in Xemacs saying that (é) \'e is
latin-9 ? It was latin-1 before being latin-9 ...
Fabrice
1:51 p.m.
>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr> writes:
Fabrice> So the chars are actually read as 8859-9. Seems wrong to
Fabrice> me. That should be better either 8859-1 or 8859-15. Or
Fabrice> am I wrong ?
> In spirit, no.
Fabrice> I understand that. But what is the point in Xemacs saying
Fabrice> that (é) \'e is latin-9 ? It was latin-1 before being
Fabrice> latin-9 ...
It's a quirk of the Mule implementation. Mule _must_ associate a
charset with every character. This makes a politically noisy subset
of Japanese happy, and in those pre-Unicode days it was a reasonable
implementation strategy.
Why Ben changed these associations for 21.5, I don't know. I suspect
that what happens is that when the various character data is read in
from etc/unicode/unicode-consortium/8859-*.TXT Mule's idea of the
internal representation of the character gets changed every time it is
mentioned and the last of those files to mention it wins.
Ie, it's a bug in the new implementation. Some things never change. :-)
--
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
2:29 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Fabrice" == Fabrice Popineau
<Fabrice.Popineau(a)supelec.fr> writes:
Fabrice> So the chars are actually read as 8859-9. Seems wrong to
Fabrice> me. That should be better either 8859-1 or 8859-15. Or
Fabrice> am I wrong ?
>> In spirit, no.
Fabrice> I understand that. But what is the point in Xemacs saying
Fabrice> that (é) \'e is latin-9 ? It was latin-1 before being
Fabrice> latin-9 ...
It's a quirk of the Mule implementation. Mule _must_ associate a
charset with every character. This makes a politically noisy subset
of Japanese happy, and in those pre-Unicode days it was a reasonable
implementation strategy.
Why Ben changed these associations for 21.5, I don't know. I suspect
that what happens is that when the various character data is read in
from etc/unicode/unicode-consortium/8859-*.TXT Mule's idea of the
internal representation of the character gets changed every time it is
mentioned and the last of those files to mention it wins.
No, Ben didn't change this. Everything worked perfect before Ben went to
his holyday. It broke afterwards (In the last few weeks mainly). See my
post starting this thread.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
3:08 p.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Thanks for following up. I'd forgotten about my patch....
Frank> No, Ben didn't change this. Everything worked perfect
Frank> before Ben went to his holyday. It broke afterwards (In the
Frank> last few weeks mainly). See my post starting this thread.
Hm. Maybe I done it. I discussed the following patch with Ben before
applying it, and he agreed it was the right thing in principle, but I
doubt he reviewed it carefully, and he probably would not notice the
kind of behavior change we're talking about (he doesn't use Gnus).
It's the `add_charsets_to_precedence_list' hunk I suspect, if anybody
wants to look at it. I'll try to get to this next week.
2002-06-23 Stephen J. Turnbull <stephen(a)xemacs.org>
* unicode.c: Improve top-level comments and many docstrings.
(Fparse_unicode_translation_table): Use right function name in error.
(unicode_to_ichar): Renamed from unicode_to_char.
(Funicode_to_char):
(decode_unicode_char):
Use new name.
(add_charsets_to_precedence_list): Change the dynarr argument
instead of the global precedence list.
(Funicode_precedence_list): New function.
(Fset_language_unicode_precedence_list,
Flanguage_unicode_precedence_list,
Fset_default_unicode_precedence_list,
Fdefault_unicode_precedence_list):
Docstrings refer to docstring of Funicode_precedence_list.
(set_unicode_conversion): Assert attempts to change Basic Latin
(Unicode BMP, row 00).
(Fset_unicode_conversion): Signal error on changes to Basic Latin.
--
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:35 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
It's the `add_charsets_to_precedence_list' hunk I suspect, if
anybody
wants to look at it. I'll try to get to this next week.
2002-06-23 Stephen J. Turnbull <stephen(a)xemacs.org>
No, as I stated in my first post it was perfect at least until
2002-07-05 (that's the last build I still own which works completely as
I want it)
Some when between this date and 2002-08-25 behavior changed: XEmacs now
used ISO-8859-15 for both language-environments German and Latin-1 if I
inputted any German "Umlaut" like ä, ö, ü, ß. At least for Latin-1 this
was already a _severe_ bug.
The final breakage came some when between 2002-08-25 and
2002-09-24. XEmacs now used for both language-environments German and
Latin-1 ISO-8859-9. If it helps, I can try and search for more precise
dates when it broke (just have to search through my archived postings
and mails).
This bug is really essential to me, since I spend 90% of the time I use
XEmacs with Gnus.
MFG Frank.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
5:46 p.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> No, as I stated in my first post it was perfect at least
Frank> until 2002-07-05 (that's the last build I still own which
Frank> works completely as I want it)
Don't take the ChangeLog dates too seriously; those are submission
dates, not commit dates. However, my patch was committed before
release of 21.5.7 on 2002-07-02 (possibly within the day), so that's
too early unless you had a stale CVS tree lying around. Seems
unlikely.
Frank> Some when between this date and 2002-08-25 behavior
Frank> changed: XEmacs now used ISO-8859-15 for both
Frank> language-environments German and Latin-1 if I inputted any
Frank> German "Umlaut" like ä, ö, ü, ß. At least for Latin-1 this
Frank> was already a _severe_ bug.
Maybe it's this one, then:
2002-05-28 Katsumi Yamaoka <yamaoka(a)jpl.org>
* mule/japan-util.el: Use `characterp' instead of `integerp' while
defining char properties for katakana.
* mule/mule-category.el: Clear the category table before defining
categories for `predefined-category-list'.
* mule/mule-cmds.el (finish-set-language-environment): Fit the
charsets preferences in unicode conversions for the language
environment. Suggested by ARISAWA Akihiro <ari(a)mbf.sphere.ne.jp>.
Despite the date it was probably committed on 2002-08-02, and
definitely after the release of 21.5.8 on 2002-07-27. There were very
few Mule-related changes in the period you focus on. If it isn't that
one, it will take serious debugging.
--
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
noon
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Maybe it's this one, then:
2002-05-28 Katsumi Yamaoka <yamaoka(a)jpl.org>
* mule/japan-util.el: Use `characterp' instead of `integerp' while
defining char properties for katakana.
* mule/mule-category.el: Clear the category table before defining
categories for `predefined-category-list'.
* mule/mule-cmds.el (finish-set-language-environment): Fit the
charsets preferences in unicode conversions for the language
environment. Suggested by ARISAWA Akihiro <ari(a)mbf.sphere.ne.jp>.
Despite the date it was probably committed on 2002-08-02, and
definitely after the release of 21.5.8 on 2002-07-27. There were very
few Mule-related changes in the period you focus on. If it isn't that
one, it will take serious debugging.
Yes, this date matches. I seem to have build my first 21.5.8 on
2002-08-03 and it was already broken. Shall I get the last 21.5.7 from
CVS, build it and have a look if it works? Then we would know, that it
broke between 2002-07-27 and 2002-08-03.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
2:11 p.m.
Hi, here I am.
>>>> In
<smzthxgc.fsf(a)hschmi22.userfqdn.rz-online.de>
>>>> Frank Schmitt <ich(a)Frank-Schmitt.net> wrote:
> 2002-05-28 Katsumi Yamaoka <yamaoka(a)jpl.org>
> * mule/japan-util.el: Use `characterp' instead of
`integerp' while
> defining char properties for katakana.
> * mule/mule-category.el: Clear the category table before
defining
> categories for `predefined-category-list'.
> * mule/mule-cmds.el (finish-set-language-environment): Fit the
> charsets preferences in unicode conversions for the language
> environment. Suggested by ARISAWA Akihiro <ari(a)mbf.sphere.ne.jp>.
Those changes intended to make XEmacs 21.5 work under Japanese
language environment. However, it considers now that only
fixing japan-util.el can be a success. In Japanese language
environment, though the other two changes aren't meaningless
(that I think), it is insufficient to make XEmacs 21.5 perfect.
Furthermore, I am uncertain about non-Japanese languages. Then,
I'll withdraw them until Ben returns, how is it?
Here's a reverse patch:
--
Katsumi(a)Yamaoka.cc
10:16 a.m.
I too was pretty sure that this was the patch that broke up gnus at
least for iso-8859-* encodings. I should redump without it to see if
it makes any difference.
--
Fabrice
10:49 a.m.
>>>> In <fzvrkfbh.fsf(a)supelec.fr>
>>>> Fabrice Popineau <Fabrice.Popineau(a)supelec.fr> wrote:
I too was pretty sure that this was the patch that broke up gnus at
least for iso-8859-* encodings. I should redump without it to see if
it makes any difference.
If so, although my patch to mule-category.el and/or mule-cmds.el
improves Japanese environment partially, it breaks the latin
environments. Since it doesn't fix Japanese environment
completely, I don't have regret in throwing it away (probably
other Japanese will agree). I ask the XEmacs maintainers to
apply the reverse patch which has been archived in:
http://list-archive.xemacs.org/xemacs-beta/200209/msg00454.html
Regards,
--
Katsumi Yamaoka <yamaoka(a)jpl.org>
2:32 p.m.
Katsumi Yamaoka <yamaoka(a)jpl.org> writes:
> I too was pretty sure that this was the patch that broke up gnus
at
> least for iso-8859-* encodings. I should redump without it to see if
> it makes any difference.
If so, although my patch to mule-category.el and/or mule-cmds.el
improves Japanese environment partially, it breaks the latin
environments. Since it doesn't fix Japanese environment
completely, I don't have regret in throwing it away (probably
other Japanese will agree). I ask the XEmacs maintainers to
apply the reverse patch which has been archived in:
http://list-archive.xemacs.org/xemacs-beta/200209/msg00454.html
I finally found time to try the reverse patch and it does indeed fix the
problems for us Latin-x users, so I'd vote for applying it to 21.5.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
11:13 p.m.
Frank Schmitt <ich(a)Frank-Schmitt.net> writes:
> http://list-archive.xemacs.org/xemacs-beta/200209/msg00454.html
I finally found time to try the reverse patch and it does indeed fix the
problems for us Latin-x users, so I'd vote for applying it to 21.5.
No comments?
Nobody willing to put it into CVS?
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
2:02 a.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> Frank Schmitt <ich(a)Frank-Schmitt.net> writes:
>>
http://list-archive.xemacs.org/xemacs-beta/200209/msg00454.html
> I finally found time to try the reverse patch and it does
> indeed fix the problems for us Latin-x users, so I'd vote for
> applying it to 21.5.
Frank> No comments?
Not from the people who understand that code. Ben and I are busy
doing other things. The original contributor says he doesn't
understand how it affects non-Japanese locales, which is damning.
Ben should be back in action in a couple of weeks; he's currently
coping with school, several months' mail backlog, and getting
reacquainted with his workspaces. I've got a few last things to do
with 21.4, and then I'm going to start working on these language
environment issues. But I haven't worked directly on the devel branch
in a year. It will take a while for me to spin up, especially since
Ben has made significant changes to this code. None of the other
currently active developers have done much work on this part of Mule.
Frank> Nobody willing to put it into CVS?
Not in these circumstances, no. Steve Y. approved the original patch,
IIRC; ping him personally.
--
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
9:34 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Frank> No comments?
Not from the people who understand that code. Ben and I are busy
doing other things. The original contributor says he doesn't
understand how it affects non-Japanese locales, which is damning.
Well I now in which way it affects non-Japanese locales - it breaks
them. This is just a revert to a state when everything worked, so I
really don't see the problem.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
11:11 a.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> This is just a revert to a state when everything worked,
Frank> so I really don't see the problem.
For you, everything worked. Obviously not so for Japanese. So patch
your own copy of the sources as you like, and there will be an
official patch which should make everybody happy in due time.
--
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
12:02 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> This is just a revert to a state when everything worked,
Frank> so I really don't see the problem.
For you, everything worked. Obviously not so for Japanese. So patch
your own copy of the sources as you like, and there will be an
official patch which should make everybody happy in due time.
No problem, I just thought the patch was insufficient for Japanese
environment so it wouldn't help them and reverting it wasn't a problem.
(BTW: Couldn't you just do an ugly hack like
(if (equal language-environment 'japan)
(stuff from patch)
(old-behavior)
)
)
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
12:27 p.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> (BTW: Couldn't you just do an ugly hack like
Frank> (if (equal language-environment 'japan)
Frank> (stuff from patch)
Frank> (old-behavior)
In 21.4, I'd strongly consider that (assuming the Japanese bug was
considered important enough to fix in the first place). But in 21.5,
we'd really like to get it right, even at the cost of some delay/
instability.
Anyway, Ben is expected to be back in production shortly, so enjoy
your period of relative peace while you can. He's got at least two
projects pending, so I expect there will be crashes, broken builds and
all the usual fun and mayhem until about Christmas. :-)
--
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
12:55 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Anyway, Ben is expected to be back in production shortly, so enjoy
your period of relative peace while you can. He's got at least two
projects pending, so I expect there will be crashes, broken builds and
all the usual fun and mayhem until about Christmas. :-)
Hey, now is my university break :-). (Term starts at 10/28/02.)
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
10:44 a.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
Frank> Yes, this date matches. I seem to have build my first
Frank> 21.5.8 on 2002-08-03 and it was already broken. Shall I get
Frank> the last 21.5.7 from CVS, build it and have a look if it
Frank> works? Then we would know, that it broke between 2002-07-27
Frank> and 2002-08-03.
Better yet, try Katsumi's patch in this thread. You need to (1) patch
or hand-edit the two files, (2) then do M-x byte-compile-and-load-file
on each one, and you can test in a running XEmacs.
Note that those files are dumped (IIRC); to get your XEmacs executable
to reuse them, redump by removing xemacs.dmp (if you use --pdump) or
xemacs(.exe) (if not) and running make.
If that doesn't work, then you can try to isolate the patch using the
"build different XEmacs going backward until it works" method (you can
also use the -D ISODATE flag to cvs update).
Don't do any more builds than you need to get a working XEmacs
reasonably current for you; we've already got it down to "patches in
(probably late) July". The constraint now is developer time to look
at it, not information about the problem. :-(
--
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
8416
days inactive
8437
days old
25 comments
5 participants
participants (5)
-
Fabrice Popineau -
Frank Schmitt -
Katsumi Yamaoka -
Katsumi＠yamaoka.cc -
Stephen J. Turnbull