7:27 a.m.
The XEmacs Package Smoketest wrote:
These are the results from the XEmacs Package Smoketest:
21.5-nomule -- errors
[...]
The 21.5-nomule build has failed again. Actually I can't remember if it ever worked.
I'm
thinking of dropping that build from the smoketest since:
* it is a pain for other users on the machine since it often makes xemacs spin and use
all CPU before the watchdog script or root kills it, and
* there isn't any interest in fixing the problem as it seems.
Yours
--
%% Mats
3:47 p.m.
Mats Lidell wrote:
The XEmacs Package Smoketest wrote:
> These are the results from the XEmacs Package Smoketest:
>
> 21.5-nomule -- errors
> [...]
The 21.5-nomule build has failed again. Actually I can't remember if it ever worked.
I'm
thinking of dropping that build from the smoketest since:
* it is a pain for other users on the machine since it often makes xemacs spin and use
all CPU before the watchdog script or root kills it, and
* there isn't any interest in fixing the problem as it seems.
On what platform? I always build with nomule on Cygwin and Linux
(FC4) with no problems. However, I haven't built in a few weeks.
I'll try it with the latest code when I get home this evening.
--Rick
7:51 p.m.
>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> On what platform? I always build with nomule on Cygwin and Linux (FC4)
Rick> with no problems.
Mats means the building of the XEmacs packages with 21.5 nomule. In
particular compiling the haskell and tramp packages cause XEmacs to crash.
I'm somewhat torn by this request but on balance I'll support it. I
personally use 21.5 nomule so I'm sad to see it go, but as you say no one as
gotten around to fixing the problems.
Would it be possible to disable the build but leave the red column on the
smoketest page as a reminder?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
5:28 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
>>>> Malcolm wrote:
Malcolm> Would it be possible to disable the build but leave the
Malcolm> red column on the smoketest page as a reminder?
Mats> Of course. I'll keep the column.
I hope that will also keep the "21.5 is broken" notification in the
emails the 'bot sends out. I don't often visit the 'bot page, but I
appreciate having my guilty conscience tickled on a regular basis.
One of these days....
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:57 a.m.
Stephen J. Turnbull wrote:
I hope that will also keep the "21.5 is broken"
notification in the
emails the 'bot sends out. I don't often visit the 'bot page, but I
appreciate having my guilty conscience tickled on a regular basis.
OK, I'll add it. The script only reports about builds beeing performed but it is easy
change the text to include a reminder.
Yours
--
%% Mats
11:27 p.m.
Malcolm Purvis wrote:
>>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> On what platform? I always build with nomule on Cygwin and Linux (FC4)
Rick> with no problems.
Mats means the building of the XEmacs packages with 21.5 nomule. In
particular compiling the haskell and tramp packages cause XEmacs to crash.
Sorry for the confusion. I guess I didn't read the original
closely enough. Wouldn't be the first time ;-)
--Rick
8:47 a.m.
Malcolm Purvis wrote:
Would it be possible to disable the build but leave the red column on
the
smoketest page as a reminder?
Done.
The good thing with dropping the 21.5 nomule build is that the package smoketest now
reports success for the first time. This means that the next time a failure is reported
it actually is a problem. So it will be more informative now.
Yours
--
%% Mats
10:33 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> Done.
Thanks!
I had a look for the underlying cause while commuting today and it turns out
that a workaround isn't too difficult to implement.
The problem is that 21.5 nomule handling of the '-*- coding: -*-' token is
broken when in batch mode. I suspect that it is similar bug to the one that
is causing 'make check' to fail, which has been quite difficult to pin down.
The workaround is to remove the coding token, as shown in the patch below.
Fortunately all of the non 7-bit ASCII chars are in comments.
Is this the way we should go?
Malcolm
Index: xemacs-packages/haskell-mode/haskell-mode.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/haskell-mode/haskell-mode.el,v
retrieving revision 1.6
diff -u -r1.6 haskell-mode.el
--- xemacs-packages/haskell-mode/haskell-mode.el 2004/06/16 15:16:49 1.6
+++ xemacs-packages/haskell-mode/haskell-mode.el 2006/02/23 10:29:40
＠＠ -1,4 +1,4 ＠＠
-;;; haskell-mode.el --- A Haskell editing mode -*-coding: iso-8859-1;-*-
+;;; haskell-mode.el --- A Haskell editing mode
;; Copyright (C) 1992, 1997-1998 Simon Marlow, Graeme E Moss, and Tommy Thorn
;; Copyright (C) 2003 Free Software Foundation, Inc
Index: xemacs-packages/tramp//lisp/tramp-efs.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp-efs.el,v
retrieving revision 1.4
diff -u -r1.4 tramp-efs.el
--- xemacs-packages/tramp//lisp/tramp-efs.el 2005/08/07 15:55:38 1.4
+++ xemacs-packages/tramp//lisp/tramp-efs.el 2006/02/23 10:30:14
＠＠ -1,9 +1,8 ＠＠
-;;; -*- coding: iso-2022-7bit; -*-
;;; tramp-efs.el --- Make EFS a foreign method in Tramp
;; Copyright (C) 2003, 2004 Free Software Foundation, Inc.
-;; Author: Kai Gro,A_(Bjohann <kai.grossjohann(a)gmx.net>
+;; Author: Kai Grossjohann <kai.grossjohann(a)gmx.net>
;; Keywords: comm, processes
;; This file is free software; you can redistribute it and/or modify
Index: xemacs-packages/tramp//lisp/tramp-ftp.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp-ftp.el,v
retrieving revision 1.1
diff -u -r1.1 tramp-ftp.el
--- xemacs-packages/tramp//lisp/tramp-ftp.el 2003/05/24 20:28:32 1.1
+++ xemacs-packages/tramp//lisp/tramp-ftp.el 2006/02/23 10:30:14
＠＠ -1,4 +1,4 ＠＠
-;;; tramp-ftp.el --- Tramp convenience functions for Ange-FTP and EFS -*- coding:
iso-8859-1; -*-
+;;; tramp-ftp.el --- Tramp convenience functions for Ange-FTP and EFS
;; Copyright (C) 2002, 2003 Free Software Foundation, Inc.
Index: xemacs-packages/tramp//lisp/tramp-smb.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp-smb.el,v
retrieving revision 1.7
diff -u -r1.7 tramp-smb.el
--- xemacs-packages/tramp//lisp/tramp-smb.el 2005/08/07 15:55:39 1.7
+++ xemacs-packages/tramp//lisp/tramp-smb.el 2006/02/23 10:30:16
＠＠ -1,4 +1,4 ＠＠
-;;; tramp-smb.el --- Tramp access functions for SMB servers -*- coding: iso-8859-1; -*-
+;;; tramp-smb.el --- Tramp access functions for SMB servers
;; Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
Index: xemacs-packages/tramp//lisp/tramp-util.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp-util.el,v
retrieving revision 1.9
diff -u -r1.9 tramp-util.el
--- xemacs-packages/tramp//lisp/tramp-util.el 2006/01/22 22:10:49 1.9
+++ xemacs-packages/tramp//lisp/tramp-util.el 2006/02/23 10:30:16
＠＠ -1,4 +1,3 ＠＠
-;;; -*- coding: iso-2022-7bit; -*-
;;; tramp-util.el --- Misc utility functions to use with Tramp
;; Copyright (C) 2001, 2002, 2003, 2004, 2005,
Index: xemacs-packages/tramp//lisp/tramp-uu.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp-uu.el,v
retrieving revision 1.5
diff -u -r1.5 tramp-uu.el
--- xemacs-packages/tramp//lisp/tramp-uu.el 2005/08/07 15:55:39 1.5
+++ xemacs-packages/tramp//lisp/tramp-uu.el 2006/02/23 10:30:16
＠＠ -1,9 +1,8 ＠＠
-;;; -*- coding: iso-2022-7bit; -*-
;;; tramp-uu.el --- uuencode in Lisp
;; Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
-;; Author: Kai Gro,A_(Bjohann <kai.grossjohann(a)gmx.net>
+;; Author: Kai Grossjohann <kai.grossjohann(a)gmx.net>
;; Keywords: comm, terminals
;; This file is free software; you can redistribute it and/or modify
Index: xemacs-packages/tramp//lisp/tramp.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/tramp.el,v
retrieving revision 1.31
diff -u -r1.31 tramp.el
--- xemacs-packages/tramp//lisp/tramp.el 2006/02/12 20:29:37 1.31
+++ xemacs-packages/tramp//lisp/tramp.el 2006/02/23 10:30:27
＠＠ -1,10 +1,10 ＠＠
-;;; -*- mode: Emacs-Lisp; coding: iso-2022-7bit; -*-
+;;; -*- mode: Emacs-Lisp -*-
;;; tramp.el --- Transparent Remote Access, Multiple Protocol
;; Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004,
;; 2005, 2006 Free Software Foundation, Inc.
-;; Author: Kai Gro,A_(Bjohann <kai.grossjohann(a)gmx.net>
+;; Author: Kai Grossjohann <kai.grossjohann(a)gmx.net>
;; Michael Albinus <michael.albinus(a)gmx.de>
;; Keywords: comm, processes
＠＠ -2665,7 +2665,7 ＠＠
;; Other file name ops.
-;; ;; Matthias K,Av(Bppe <mkoeppe(a)mail.math.uni-magdeburg.de>
+;; ;; Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de>
;; (defun tramp-handle-directory-file-name (directory)
;; "Like `directory-file-name' for tramp files."
;; (if (and (eq (aref directory (- (length directory) 1)) ?/)
＠＠ -7711,7 +7711,7 ＠＠
;; transfer method to use. (Greg Stark)
;; * Remove unneeded parameters from methods.
;; * Invoke rsync once for copying a whole directory hierarchy.
-;; (Francesco Potort,Al(B)
+;; (Francesco Potorti)
;; * Should we set PATH ourselves or should we rely on the remote end
;; to do it?
;; * Make it work for XEmacs 20, which is missing `with-timeout'.
Index: xemacs-packages/tramp//lisp/trampver.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/tramp/lisp/trampver.el,v
retrieving revision 1.12
diff -u -r1.12 trampver.el
--- xemacs-packages/tramp//lisp/trampver.el 2006/01/22 22:10:50 1.12
+++ xemacs-packages/tramp//lisp/trampver.el 2006/02/23 10:30:27
＠＠ -1,10 +1,10 ＠＠
-;;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-
+;;; -*- mode: Emacs-Lisp -*-
;;; trampver.el --- Transparent Remote Access, Multiple Protocol
;;; lisp/trampver.el. Generated from trampver.el.in by configure.
;; Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
-;; Author: Kai Gro,A_(Bjohann <kai.grossjohann(a)gmx.net>
+;; Author: Kai Grossjohann <kai.grossjohann(a)gmx.net>
;; Keywords: comm, processes
;; This file is part of GNU Emacs.
--
Malcolm Purvis <malcolmp(a)xemacs.org>
10:36 p.m.
>>>> Malcolm wrote:
Malcolm> The workaround is to remove the coding token, as shown in the
Malcolm> patch below. Fortunately all of the non 7-bit ASCII chars
Malcolm> are in comments.
Malcolm> Is this the way we should go?
The smoketest doesn't care how the build is fixed. If it works we can
start the build again.
It doesn't sound though as a good solution for the system. Better fix
the coding problem I'd say.
Yours
--
%% Mats
7:39 a.m.
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Malcolm wrote:
Malcolm> The workaround is to remove the coding token, as shown in the
Malcolm> patch below. Fortunately all of the non 7-bit ASCII chars
Malcolm> are in comments.
Malcolm> Is this the way we should go?
The smoketest doesn't care how the build is fixed. If it works we can
start the build again.
It doesn't sound though as a good solution for the system. Better fix
the coding problem I'd say.
I agree, especially since the failing packages are tracking upstream
sources.
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:52 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> It doesn't sound though as a good solution for the
Mats> system. Better fix the coding problem I'd say.
This kind of improper use of coding cookies is precisely why I hate
them.
If the cookie isn't needed, it shouldn't be there.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:53 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> This kind of improper use of coding cookies is precisely why I hate
Stephen> them.
In the case of tramp the files are not plain 7-bit ASCII, so the cookie might
be unnecessary but I don't think that the use is improper.
I agree that it's better to fix the underlying problem, so I won't check in my
proposed patch.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
3:40 p.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> This kind of improper use of coding cookies is precisely
Stephen> why I hate them.
Malcolm> I agree that it's better to fix the underlying problem,
Do you understand what a radical thing you are saying? The problem is
that having coding cookies in the xemacs-packages hierarchy implies
calling a Mule API in a no-Mule XEmacs. The only way to fix that is
to remove support for no-Mule builds. Vin will love that!<wink>
If you mean to have the no-Mule XEmacs recognize but ignore the
cookies it knows it can't handle, that's pretty evil. "Hey, Emacs,
we're gonna stuff input you can't handle into the Lisp interpreter!"
"OK, I'll just hold my nose and swallow!" Not a good idea.
No coding cookies, and files are ISO-8859-1 has been the policy for
the xemacs-packages hierarchy since it was invented. If this is going
to be a problem for the package maintainer, we move the package to
mule-packages. That's precisely why we have mule-packages.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:51 p.m.
>>>> Stephen wrote:
Stephen> The problem is that having coding cookies in the
Stephen> xemacs-packages hierarchy implies calling a Mule API in a
Stephen> no-Mule XEmacs. The only way to fix that is to remove
Stephen> support for no-Mule builds.
What about an error message when a non-mule XEmacs finds a coding
cookie then? XEmacs eating all CPU endlessly or crashing due to SEGV
doesn't seem that user friendly.
[...]
Stephen> No coding cookies, and files are ISO-8859-1 has been the
Stephen> policy for the xemacs-packages hierarchy since it was
Stephen> invented. If this is going to be a problem for the package
Stephen> maintainer, we move the package to mule-packages. That's
Stephen> precisely why we have mule-packages.
OK. So either the offending packages need to go strictly ISO-8859-1 or
move out to mule-packages. Right?
Yours
--
%% Mats
4:07 a.m.
>>>> Stephen wrote:
Stephen> The problem is that having coding cookies in the
Stephen> xemacs-packages hierarchy implies calling a Mule API in a
Stephen> no-Mule XEmacs. The only way to fix that is to remove
Stephen> support for no-Mule builds.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> What about an error message when a non-mule XEmacs finds a
Mats> coding cookie then? XEmacs eating all CPU endlessly or
Mats> crashing due to SEGV doesn't seem that user friendly.
It needs to be an error, though---a warning isn't good enough because
you'll crash anyway. So no matter how you look at it, the cookies
have to come out of packages in xemacs-packages.
It should be possible to allow 8-bit coding systems. If something
more than 8-bit clean processing is needed (eg, correct syntax and
case tables), you will lose, but that could be demoted to a warning by
default. We should be able to handle ISO-8859-1 correctly, and all of
the Latin ISO-8859-X family should be safe and "almost correct". For
the non-Latin alphabets (Cyrillic, Greek, Arabic, and Hebrew), it
should be safe but I doubt correct.
Mats> OK. So either the offending packages need to go strictly
Mats> ISO-8859-1 or move out to mule-packages. Right?
Yes. I don't like it, but something is necessary, and that is the
best policy we were able to come up with. However, nobody's thought
about it for a long time, so I'm open to suggestions. (They need to
be gradual and backward-compatible, though, for 21.4.)
I'd like to work on this, but I'm currently over-promised. Maybe
Aidan or Ben will, though.
I should mention that Ben talked about putting at least a UTF-8 codec
into 21.4, which would theoretically allow us to remove the
distinction between xemacs-packages and mule-packages for all future
versions of XEmacs. I don't recall a transition strategy though.
Doing the coding system wouldn't be hard, I think. The hard part is
arranging that "old" non-mule XEmacsen get no-mule packages. I think
this would probably involve some duplication across the mule/xemacs
hierarchies.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:08 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> So no matter how you look at it, the cookies have to come out of
Stephen> packages in xemacs-packages.
I'll agree with that, but does 21.4 nomule do in this situation? Treat
everything as ISO-8859-1? It clearly 'works' with xemacs-packages, however
broken it really is, and that was the level of functionality I was hoping to
restore in 21.5.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
12:07 p.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> So no matter how you look at it, the cookies have to come
Stephen> out of packages in xemacs-packages.
Malcolm> I'll agree with that, but does 21.4 nomule do in this
Malcolm> situation? Treat everything as ISO-8859-1? It clearly
Malcolm> 'works' with xemacs-packages, however broken it really
Malcolm> is, and that was the level of functionality I was hoping
Malcolm> to restore in 21.5.
What 21.5 does differently from 21.4 is to default --with-file-coding
on, I believe. Or maybe it's the fact that for Windows support all
21.5 XEmacs understand Unicode to some extent.
Anyway, the problem is that 21.5 (for sure) and 21.4 (IIRC) can be
configured to have partial support for coding systems. This is what
causes the problem. (If we're getting crashes and infloops there are
other problems, too, of course.)
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:26 p.m.
Ar an seachtú lá is fiche de mí Feabhra, scríobh Stephen J. Turnbull:
Mats> OK. So either the offending packages need to go
strictly
Mats> ISO-8859-1 or move out to mule-packages. Right?
Yes. I don't like it, but something is necessary, and that is the
best policy we were able to come up with. However, nobody's thought
about it for a long time, so I'm open to suggestions. (They need to
be gradual and backward-compatible, though, for 21.4.)
The offending packages need to go strictly iso-8859-1--there’s no need,
beyond supporting no-Mule, for them to be in mule-packages, and the
information can be preserved easily in 8859-1.
I'd like to work on this, but I'm currently over-promised.
Maybe
Aidan or Ben will, though.
I should mention that Ben talked about putting at least a UTF-8 codec
into 21.4, which would theoretically allow us to remove the
distinction between xemacs-packages and mule-packages for all future
versions of XEmacs.
He suggested it; we pointed out that would involve hacking Mule-UCS; he
thought better of it.
21.5 no-Mule should be able to handle ISO-8859-1 coding cookies, because it
does support the coding system API. If the ISO-8859-1 coding cookies (not
just the iso-2022-7 ones) are indeed breaking the build--as the proposed
band-aid seems to imply--then that’s a recent bug in 21.5.
I don't recall a transition strategy though. Doing the coding
system
wouldn't be hard, I think. The hard part is arranging that "old" non-mule
XEmacsen get no-mule packages. I think this would probably involve some
duplication across the mule/xemacs hierarchies.
--
In the beginning God created the heavens and the earth. And God was a
bug-eyed, hexagonal smurf with a head of electrified hair; and God said:
“Si, mi chiamano Mimi...”
12:13 p.m.
>>>> "Aidan" == Aidan Kehoe
<kehoea(a)parhasard.net> writes:
> I should mention that Ben talked about putting at least a UTF-8
> codec into 21.4, which would theoretically allow us to remove
> the distinction between xemacs-packages and mule-packages for
> all future versions of XEmacs.
Aidan> He suggested it; we pointed out that would involve hacking
Aidan> Mule-UCS; he thought better of it.
No, that was a different proposal. This one was to understand enough
of UTF-8 that XEmacs could recognize a character and continue parsing,
even if the character couldn't be represented in 8 bits. Then you
could wrap Mule-specific _parts_ of files in (if (featurep 'mule) ...).
Aidan> If the ISO-8859-1 coding cookies (not just the iso-2022-7
Aidan> ones) are indeed breaking the build
They're breaking the _package_ build, which is what they should do
under current policy. We probably can and should change it, though,
since ISO 8859/1 is mandatory. What to do about other
ASCII-compatible 8-bit codes is another question.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6632
days inactive
6638
days old
20 comments
7 participants
participants (7)
-
Adrian Aichner -
Aidan Kehoe -
Malcolm Purvis -
Norbert Koch -
Rick Rankin -
Stephen J. Turnbull -
The XEmacs Package Smoketest