10:42 a.m.
Hi!
XEmacs 21.5-b11-nomule chokes on the new tramp package:
Loading /home/matsl/work/smoketest/build/packages/package-compile.el...
Loading
/home/matsl/work/smoketest/nomule/lib/xemacs-21.5-b11/lisp/auto-autoloads.elc...
Requiring /home/matsl/work/smoketest/nomule/lib/xemacs-21.5-b11/lisp/bytecomp.elc...
Requiring
/home/matsl/work/smoketest/nomule/lib/xemacs-21.5-b11/lisp/byte-optimize.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/ediff/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/gnus/lisp/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/mail-lib/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/dired/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/efs/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/fsf-compat/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/vc/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/xemacs-base/auto-autoloads.elc...
Loading
/home/matsl/work/smoketest/build/packages/xemacs-packages/tramp/lisp/auto-autoloads.elc...
Compiling
/home/matsl/work/smoketest/build/packages/xemacs-packages/tramp/lisp/tramp-util.el...
Loading /home/matsl/work/smoketest/nomule/lib/xemacs-21.5-b11/lisp/cl-macs.elc...
Requiring
/home/matsl/work/smoketest/build/packages/xemacs-packages/xemacs-base/compile.elc...
Requiring
/home/matsl/work/smoketest/build/packages/xemacs-packages/tramp/lisp/tramp.el...
Requiring
/home/matsl/work/smoketest/build/packages/xemacs-packages/tramp/lisp/trampver.el...make[2]:
*** [lisp/tramp-util.elc] Segmentation fault
make[2]: Leaving directory
`/home/matsl/work/smoketest/build/packages/xemacs-packages/tramp'
make[1]: *** [tramp/bytecompile.target] Error 2
make[1]: Leaving directory
`/home/matsl/work/smoketest/build/packages/xemacs-packages'
make: *** [xemacs-packages/bytecompile.target] Error 2
I can reproduce this on 21.5-b13-nomule as of today. I won't post the
complete backtrace, since it's got more than 10000 lines ... depending
on the free memory I'd guess :-) It's looping through the same parts
for an awful lot of time:
#0 0x8082be7 in basic_alloc_lcrecord (size=76, implementation=0x828e160)
at alloc.c:451
#1 0x8085d66 in alloc_managed_lcrecord (lcrecord_list={gu = {
type = Lisp_Type_Record, val = 34593560}, s = {bits = 0,
val = 69187120}, u = {bits = 0, val = 69187120}, ui = 138374240,
i = 138374240, v = 0x83f6c60}) at alloc.c:2668
#2 0x8179577 in Lstream_new (imp=0x82dabe0, mode=0x828e32c "w")
at lstream.c:214
#3 0x817b6b1 in make_dynarr_output_stream (dyn=0x1d5a9820) at lstream.c:1581
#4 0x810e96a in undecided_convert (str=0x1d5adc48,
src=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;; trampver.el
--- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el. Generated from
trampver.el.in by configure.\n\n;; Copyright (C) "...,
dst=0x1d5a9820, n=1501) at file-coding.c:4013
#5 0x810a80b in coding_writer (stream=0x1d5adc00,
data=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;;
trampver.el --- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el.
Generated from trampver.el.in by configure.\n\n;; Copyright (C) "...,
size=1501) at file-coding.c:2118
#6 0x817976d in Lstream_really_write (lstr=0x1d5adc00,
data=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;;
trampver.el --- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el.
Generated from trampver.el.in by configure.\n\n;; Copyright (C) "...,
size=1501) at lstream.c:365
#7 0x81798fe in Lstream_write_1 (lstr=0x1d5adc00, data=0x8517000, size=1501)
at lstream.c:499
#8 0x8179bb3 in Lstream_write (lstr=0x1d5adc00, data=0x8517000, size=1501)
at lstream.c:587
#9 0x810ed64 in undecided_convert (str=0x1d5addc8,
src=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;; trampver.el
--- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el. Generated from
trampver.el.in by configure.\n\n;; Copyright (C) "...,
dst=0x1d5a98c0, n=1501) at file-coding.c:4094
#10 0x810a80b in coding_writer (stream=0x1d5add80,
data=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;;
trampver.el --- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el.
Generated from trampver.el.in by configure.\n\n;; Copyright (C) "...,
size=1501) at file-coding.c:2118
#11 0x817976d in Lstream_really_write (lstr=0x1d5add80,
data=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;;
trampver.el --- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el.
Generated from trampver.el.in by configure.\n\n;; Copyright (C) "...,
size=1501) at lstream.c:365
#12 0x81798fe in Lstream_write_1 (lstr=0x1d5add80, data=0x8517000, size=1501)
at lstream.c:499
#13 0x8179bb3 in Lstream_write (lstr=0x1d5add80, data=0x8517000, size=1501)
at lstream.c:587
#14 0x810ed64 in undecided_convert (str=0x1d5adf48,
src=0x8517000 ";;; -*- mode: Emacs-Lisp; coding: iso-8859-1; -*-\n;;; trampver.el
--- Transparent Remote Access, Multiple Protocol\n;;; lisp/trampver.el. Generated from
trampver.el.in by configure.\n\n;; Copyright (C) "...,
dst=0x1d5a9960, n=1501) at file-coding.c:4094
[...]
norbert.
2:07 p.m.
Norbert Koch <viteno(a)xemacs.org> writes:
XEmacs 21.5-b11-nomule chokes on the new tramp package:
Hm. I see that the file in question has a latin-1 coding cookie.
For tramp.el, the coding cookie was changed to iso-2022-7bit by Steve Y.
Is this a solution for trampver.el, as well?
I'm guessing it's not a solution, but it might be a workaround.
--
This line is not blank.
2:11 a.m.
|--==> "KG" == Kai Großjohann <kai.grossjohann(a)uni-duisburg.de>
writes:
KG> Hm. I see that the file in question has a latin-1 coding cookie.
KG> For tramp.el, the coding cookie was changed to iso-2022-7bit by
KG> Steve Y. Is this a solution for trampver.el, as well?
KG> I'm guessing it's not a solution, but it might be a workaround.
That'd be my guess too.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
12:27 p.m.
Steve Youngs <youngs(a)xemacs.org> writes:
Hi!
|--==> "KG" == Kai Großjohann
<kai.grossjohann(a)uni-duisburg.de> writes:
KG> Hm. I see that the file in question has a latin-1 coding cookie.
KG> For tramp.el, the coding cookie was changed to iso-2022-7bit by
KG> Steve Y. Is this a solution for trampver.el, as well?
KG> I'm guessing it's not a solution, but it might be a workaround.
That'd be my guess too.
It wouldn't help anyway, because the build then breaks in
tramp-util.el with the same symptoms. You'd have to insert or change
coding cookies in most of the files, I'd guess.
norbert.
9:14 p.m.
Norbert Koch <viteno(a)xemacs.org> writes:
It wouldn't help anyway, because the build then breaks in
tramp-util.el with the same symptoms. You'd have to insert or change
coding cookies in most of the files, I'd guess.
Yeah...
Hm. Does XEmacs really choke on byte-compiling any file that has
;; -*- coding: iso-8859-1; -*-
in the first line? I don't want to start pointing fingers, but I'm
really tempted to...
--
This line is not blank.
7:39 a.m.
>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)gmx.net> writes:
Kai> Hm. Does XEmacs really choke on byte-compiling any file that
Kai> has
Kai> ;; -*- coding: iso-8859-1; -*-
Quite possibly. Almost all XEmacs Lisp files were converted to ISO
2022 seven bit code about four years ago. For Mule safety, compiled
.elcs are in a different seven bit code.
Coding cookies are evil. Lisp sources really should be in a single
specified universal coding system, preferably Unicode UTF-8 but of
course that's not currently feasible.
--
Institute of Policy and Planning Sciences 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.
6 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Coding cookies are evil.
I beg to disagree. They are necessary for informing the system about
the charset used in a file. (Unless all of the files in a system are
of the same encoding, which is not feasible in multi-user systems.)
MIME uses coding cookies (in the form of charset attributes in the
content-type header), HTML uses them, XML uses then (in the <?xml?>
processing instruction), and I'm sure I could find other examples.
Lisp sources really should be in a single specified universal coding
system, preferably Unicode UTF-8 but of course that's not currently
feasible.
For me, it's convenient to store *.el files in Latin-1 or Latin-9
encoding, because that enables me to use grep on them, just like I do
with other files.
Is there any chance that XEmacs will grok *.el files in other
encodings, or do I just have to bite the bullet and convert them to
iso-2022-7bit?
--
This line is not blank.
9:46 a.m.
>>>> "Kai" == Kai Großjohann
<kai.grossjohann(a)gmx.net> writes:
Kai> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Coding cookies are evil.
Kai> I beg to disagree. They are necessary for informing the
Kai> system about the charset used in a file. (Unless all of the
Kai> files in a system are of the same encoding, which is not
Kai> feasible in multi-user systems.)
They are not necessary; if they were, they'd be required, and Emacs
would refuse to edit a file that didn't have one, and dump core if it
were incorrect.
Kai> MIME uses coding cookies (in the form of charset attributes
Kai> in the content-type header), HTML uses them, XML uses then
Kai> (in the <?xml?> processing instruction), and I'm sure I could
Kai> find other examples.
But those are not cookies! Those are specific unambiguous syntax, and
they are required by the standard's semantic specifications if the
file is not in ASCII.
Cookies (as used in Emacs, and now, to my great disgust, in Python)
are random optional heuristics that are not part of the actual syntax.
I'm willing to bet that a string of octets that looks like "coding:
iso-8859-1"---note that that is probably legal Unicode, lowercase
letters wold be the high byte of a Unicode character that falls in the
Unihan block---will trigger the cookie recognizer in a file that is
otherwise UTF-16, for example. Programmers regularly fail to update
them when the coding system changes or copy them incorrectly from one
file to the next, and no system (except for my Latin-unity) that I
know of will warn the user if a cookie is incorrect. (Actually, I
think python may refuse to run.)
> Lisp sources really should be in a single specified universal
> coding system, preferably Unicode UTF-8 but of course that's
> not currently feasible.
Kai> For me, it's convenient to store *.el files in Latin-1 or
Kai> Latin-9 encoding, because that enables me to use grep on
Kai> them, just like I do with other files.
Kai> Is there any chance that XEmacs will grok *.el files in other
Kai> encodings, or do I just have to bite the bullet and convert
Kai> them to iso-2022-7bit?
XEmacs does grok .el files in other encodings in the stable branch,
doesn't it? As for 21.5, I'll take a look when I get back from
Montreal, around 6/10. However, for now the right answer is "don't
build Tramp (or other packages) in public with 21.5 unless your name
is Mats Lidell". 21.5 shares very few lines of code with 21.4 in the
coding system stuff; breakage should be expected.
--
Institute of Policy and Planning Sciences 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.
7632
days inactive
7636
days old
7 comments
5 participants
participants (5)
-
Kai Großjohann -
Kai Großjohann -
Norbert Koch -
Stephen J. Turnbull -
Steve Youngs