9:11 a.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
Several problems:
A. In submitting bug reports, the instructions to press "C-c TAB"
for info don't seem to work, BTW. It's also not helpful to be
asked to do a "M-x emacs-version" when the results from that show
up in the minibuffer, which results in it not being
cuttable-and-pasteable (which might be necessary if this
bug-mailing function doesn't work).
B. Errors in a custom.el file show up as being in the init.el file
(specifically, if there's a parentheses imbalance in the
custom.el file, an "End of file" error shows up for the init.el
file... not the custom.el file).
C. XEmacs gives errors when there isn't an init.el file, which is
particularly maddening when the cause of removal of the init.el
file is the previous problem.
D. auto-autoload.el should _not_ be doing "error" if a file is
already included; it should simply return. (As it is, I'm writing
a Perl script to correct all the auto-autoload.el files, since
there doesn't seem to be a way to automatically reconstruct them
properly. I tried xemacs -batch -f batch-update-autoloads
[various permutations] after correcting autoload.el; it didn't
modify the files, and didn't recreate them when I deleted them.)
Otherwise, one gets the following sort of garbage on every
startup:
(1) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/xemacs-devel/auto-autoloads:
Already loaded
(2) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/xemacs-base/auto-autoloads:
Already loaded
(3) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/w3/auto-autoloads:
Already loaded
(4) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/vm/auto-autoloads:
Already loaded
(5) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/view-process/auto-autoloads:
Already loaded
(6) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/vc/auto-autoloads:
Already loaded
(7) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/tpu/auto-autoloads:
Already loaded
(8) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/textools/auto-autoloads:
Already loaded
(9) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/text-modes/auto-autoloads:
Already loaded
(10) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/texinfo/auto-autoloads:
Already loaded
(11) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/supercite/auto-autoloads:
Already loaded
(12) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/strokes/auto-autoloads:
Already loaded
(13) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/speedbar/auto-autoloads:
Already loaded
(14) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/slider/auto-autoloads:
Already loaded
(15) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/sh-script/auto-autoloads:
Already loaded
(16) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/semantic/auto-autoloads:
Already loaded
(17) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/sasl/auto-autoloads:
Already loaded
(18) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/rmail/auto-autoloads:
Already loaded
(19) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/reftex/auto-autoloads:
Already loaded
(20) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ps-print/auto-autoloads:
Already loaded
(21) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/prog-modes/auto-autoloads:
Already loaded
(22) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/pcomplete/auto-autoloads:
Already loaded
(23) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/pcl-cvs/auto-autoloads:
Already loaded
(24) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/os-utils/auto-autoloads:
Already loaded
(25) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/net-utils/auto-autoloads:
Already loaded
(26) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/mmm-mode/auto-autoloads:
Already loaded
(27) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/mh-e/auto-autoloads:
Already loaded
(28) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/mailcrypt/auto-autoloads:
Already loaded
(29) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/mail-lib/auto-autoloads:
Already loaded
(30) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ispell/auto-autoloads:
Already loaded
(31) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ilisp/auto-autoloads:
Already loaded
(32) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/igrep/auto-autoloads:
Already loaded
(33) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ibuffer/auto-autoloads:
Already loaded
(34) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/gnus/auto-autoloads:
Already loaded
(35) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/fsf-compat/auto-autoloads:
Already loaded
(36) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/footnote/auto-autoloads:
Already loaded
(37) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/eterm/auto-autoloads:
Already loaded
(38) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ess/auto-autoloads:
Already loaded
(39) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/emerge/auto-autoloads:
Already loaded
(40) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/elib/auto-autoloads:
Already loaded
(41) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/eieio/auto-autoloads:
Already loaded
(42) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/efs/auto-autoloads:
Already loaded
(43) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/edt/auto-autoloads:
Already loaded
(44) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/edit-utils/auto-autoloads:
Already loaded
(45) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ediff/auto-autoloads:
Already loaded
(46) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/edebug/auto-autoloads:
Already loaded
(47) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/ecrypto/auto-autoloads:
Already loaded
(48) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/dired/auto-autoloads:
Already loaded
(49) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/cc-mode/auto-autoloads:
Already loaded
(50) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/calendar/auto-autoloads:
Already loaded
(51) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/calc/auto-autoloads:
Already loaded
(52) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/c-support/auto-autoloads:
Already loaded
(53) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/build/auto-autoloads:
Already loaded
(54) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/auctex/auto-autoloads:
Already loaded
(55) (warning/warning) Autoload error in:
/server/people/staff/easmith/lib/xemacs/xemacs-packages/lisp/apel/auto-autoloads:
Already loaded
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: IRIX64 puck2 6.5 04101931 IP30
./configure '--site-includes=/server/people/staff/easmith/include'
'--site-libraries=/server/people/staff/easmith/lib32:/usr/lib32/mips4:/usr/lib32:/lib32'
'--dynamic' '--prefix=/server/people/staff/easmith'
'--external-widget' '--with-sound=native' '--mail-locking=dot'
XEmacs 21.4.9 "Informed Management" configured for `mips-sgi-irix6.5'.
Compilation / Installation:
Source code location:
/server/people/staff/easmith/bin/xemacs/xemacs-21.4.9
Installation prefix: /server/people/staff/easmith
Additional header files: /server/people/staff/easmith/include
Additional libraries: /server/people/staff/easmith/lib32 /usr/lib32/mips4
/usr/lib32 /lib32
Runtime library search path:
/server/people/staff/easmith/lib32:/usr/lib32/mips4:/usr/lib32:/lib32
Operating system description file: `s/irix6-0.h'
Machine description file: `m/iris6d.h'
Compiler: cc -mips4 -n32 -L/server/people/staff/easmith/lib32
-L/usr/lib32/mips4 -L/usr/lib32 -L/lib32
-Wl,-rpath,/server/people/staff/easmith/lib32:/usr/lib32/mips4:/usr/lib32:/lib32
-Wl,-multigot -woff 1110 -I${HOME}/include -O3 -OPT:fast_sqrt=OFF:Olimit=0 -TENV:X=1
-LNO:opt=1:ou_further=3
-OPT:fold_unsafe_relops=OFF:div_split=OFF:IEEE_arithmetic=1:roundoff=0 -LNO:vintr=OFF
Relocating allocator for buffers: yes
GNU version of malloc: yes
Window System:
Compiling in support for the X window system:
- X Windows headers location:
- X Windows libraries location:
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for GNU DBM.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Load-Path Lisp Shadows:
----------------------
(/server/people/staff/easmith/lib/xemacs-21.4.9/xemacs-packages/lisp/ecrypto/md5
/server/people/staff/easmith/lib/xemacs-21.4.9/xemacs-packages/lisp/gnus/md5)
Installed XEmacs Packages:
-------------------------
((xemacs-devel:version 1.48 :type single-file)
(xemacs-base :version 1.68 :type regular)
(w3 :version 1.25 :type regular)
(vm :version 7.07 :type regular)
(view-process :version 1.12 :type regular)
(vc :version 1.33 :type regular)
(tpu :version 1.12 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.52 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.24 :type regular)
(slider :version 1.13 :type regular)
(sh-script :version 1.15 :type regular)
(semantic :version 1.14 :type regular)
(sasl :version 1.12 :type regular)
(rmail :version 1.13 :type regular)
(reftex :version 1.28 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.65
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.64 :type regular)
(os-utils :version 1.28 :type single-file)
(net-utils :version 1.28 :type single-file)
(mmm-mode :version 1.0 :type regular)
(mh-e :version 1.15 :type regular)
(mailcrypt :version 2.11 :type regular)
(mail-lib :version 1.49 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.28 :type regular)
(igrep :version 1.09 :type regular)
(ibuffer :version 1.08 :type regular)
(gnus :version 1.62 :type regular)
(fsf-compat :version 1.11 :type single-file)
(footnote :version 1.15 :type regular)
(eterm :version 1.13 :type regular)
(ess :version 1.02 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.03 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.93 :type single-file)
(ediff :version 1.41 :type regular)
(edebug :version 1.14 :type regular)
(ecrypto :version 0.11 :type regular)
(dired :version 1.12 :type regular)
(cc-mode :version 1.3 :type regular)
(calendar :version 1.18 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.07 :type regular)
(auctex :version 1.32 :type regular)
(apel :version 1.25 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 efs-cu info paren blink-paren
cus-face big-menubar filladapt xemacs-devel-autoloads xemacs-base-autoloads
w3-autoloads vm-autoloads view-process-autoloads vc-autoloads tpu-autoloads
textools-autoloads text-modes-autoloads texinfo-autoloads
supercite-autoloads strokes-autoloads speedbar-autoloads slider-autoloads
sh-script-autoloads semantic-autoloads sasl-autoloads rmail-autoloads
reftex-autoloads ps-print-autoloads prog-modes-autoloads pcomplete-autoloads
pcl-cvs-autoloads os-utils-autoloads net-utils-autoloads mmm-mode-autoloads
mh-e-autoloads mailcrypt-autoloads mail-lib-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads ibuffer-autoloads gnus-autoloads
fsf-compat-autoloads footnote-autoloads eterm-autoloads ess-autoloads
emerge-autoloads elib-autoloads eieio-autoloads efs-autoloads edt-autoloads
edit-utils-autoloads ediff-autoloads edebug-autoloads ecrypto-autoloads
dired-autoloads cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads auctex-autoloads apel-autoloads
lisp-autoloads loadhist auto-show fontl-hooks x-iso8859-1 gutter-items
menubar-items x-menubar mode-motion mouse itimer auto-save lisp-mode
easymenu iso8859-1 page buff-menu lib-complete help-nomule cus-file derived
frame text-props obsolete cus-start custom widget cl-extra mini-cl cl cl-19
packages backquote very-early-lisp lucid-scrollbars cut-buffer
lucid-menubars external-widget motif-dialogs x c-balloon-help tty-frames tty
toolbar native-sound scrollbar unix-processes multicast network-streams
subprocesses modules menu-accelerator-support menubar berkeley-db dbm md5
xemacs gutter tiff png gif jpeg xpm xbm lisp-float-type irix dialog devices
window-system base64)
Recent keystrokes:
-----------------
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user misc-user misc-user
misc-user misc-user misc-user misc-user
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Selecting menu item Bugs...done
Selecting menu item Bugs...
Selecting menu item XEmacs...done
Selecting menu item XEmacs...
Composing main Info directory...done
Wrong type argument: windowp, nil
Creating temporary dir in
/server/people/staff/easmith/lib/xemacs-21.4.9/xemacs-packages/info/...done
(New file)
Creating temporary dir in
/server/people/staff/easmith/lib/xemacs-21.4.9/xemacs-packages/info/...
Composing main Info directory...
Rebuilding temporary /server/people/staff/easmith/info/dir...done
Rebuilding temporary /server/people/staff/easmith/info/dir...
Loading efs-cu...done
Loading efs-cu...
Loading info...done
Loading info...
Paren mode is sexp
Loading paren...done
4:47 p.m.
On Sat, 2002-10-05 at 11:11, Ed Allen Smith wrote:
D. auto-autoload.el should _not_ be doing "error" if a
file is
already included; it should simply return. (As it is, I'm writing
a Perl script to correct all the auto-autoload.el files, since
there doesn't seem to be a way to automatically reconstruct them
properly. I tried xemacs -batch -f batch-update-autoloads
[various permutations] after correcting autoload.el; it didn't
modify the files, and didn't recreate them when I deleted them.)
Otherwise, one gets the following sort of garbage on every
startup:
A quick and dirty way to just get rid of the startup warnings could be
to stick something like this into your init.el:
(add-hook
'emacs-startup-hook
'(lambda()
(setq inhibit-warning-display t)))
--
\/ille Skyttä
ville.skytta at xemacs.org
5:21 p.m.
>>>> "Ed" == Ed Allen Smith
<easmith(a)beatrice.rutgers.edu> writes:
for info don't seem to work, BTW. It's also not helpful to be
asked to do a "M-x emacs-version" when the results from that show
up in the minibuffer, which results in it not being
cuttable-and-pasteable (which might be necessary if this
bug-mailing function doesn't work).
If things are that hosed, there are other reasons why you're going to
need to be sophisticated enough to use M-x view-lossage or C-x b "
*Message-Log*" to get the output. I think our play here is to make
the report function as robust as possible.
B. Errors in a custom.el file show up as being in the init.el file
(specifically, if there's a parentheses imbalance in the
custom.el file, an "End of file" error shows up for the init.el
file... not the custom.el file).
Because of the way XEmacs handles these files, I suspect that you
probably have imbalanced parens in _both_ files. I'll check when I
get back to my devel workspace, though.
N.B. custom.el is designed to be written only by code that prints
sexps, there is no user-editable code in there. If you are getting
imbalanced parens in custom.el, all I can say is "whatever you're
doing, it's unsupported by XEmacs.org".
C. XEmacs gives errors when there isn't an init.el file, which is
particularly maddening when the cause of removal of the init.el
file is the previous problem.
What errors?
D. auto-autoload.el should _not_ be doing "error" if a file is
It's not doing error (which means to stop loading autoloads and throw
to top-level), it's giving a warning about a very-hard-to-debug
situation. Live with it or use display-warning-minimum-level; that
information is needed to help other users.
already included; it should simply return.
Wrong. If auto-autoloads detects that it has been previously loaded,
that means one of three things: a bad build, multiple copies of
packages on your load-path, or a seriously mutilated load-path.
Either way, we want XEmacs to yell about it.
Ed> (As it is, I'm writing a Perl script to correct all the
Ed> auto-autoload.el files, since there doesn't seem to be a way
Ed> to automatically reconstruct them properly.
Don't do this. It is a known design bug in the package system that
there is no easy way to build the packages correctly without checking
out the whole source hierarchy. However, it is not going to be easy
to fix in a backward compatible way. In the meantime I strongly urge
you to find all the copies of the package hierarchy you have
installed, delete them, download the sumo tarball (tarballs if you
want Mule), and reinstall packages from scratch. Unless you have a
really slow (worse than ISDN) link, this will be faster than doing it
by hand, and much more likely to be correct.
Since you only show the md5 shadow, I conclude there is something
wrong with either your build or your init files (user or system);
otherwise you would not be getting duplicate loads 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
8:10 a.m.
In message <87smzjh72g.fsf(a)tleepslib.sk.tsukuba.ac.jp> (on 7 October 2002 01:21:11
+0900), stephen(a)xemacs.org (Stephen J. Turnbull) wrote:
I apologize if this is overly bad-tempered, but I really, really hate
dealing with Lisp, among other things, and also really don't like GUIs in
general - X Windows is about the limit that I can deal with. Due to brain
damage, I've got enough of a difference between verbal and nonverbal IQs for
it to be a disability in and of itself, and thus have great difficulty with
trying to figure out how a nonverbal language like Lisp is working - just as
much as I do trying to figure out what people mean their GUIs to be
doing. (Given this, it is unsurprising that my favored programming language
is Perl... the presence of cperl-mode (which should really have some
increased backward-compatibility enhancements...) is one thing causing me to
favor emacs/xemacs. I'm also now going with VM as a mailer due to, among
other things, the restrictive anti-open-source policies of the PINE
developers (no distribution of modified versions), incidentally.)
>>>>> "Ed" == Ed Allen Smith
<easmith(a)beatrice.rutgers.edu> writes:
for info don't seem to work, BTW. It's also not helpful to be
asked to do a "M-x emacs-version" when the results from that show
up in the minibuffer, which results in it not being
cuttable-and-pasteable (which might be necessary if this
bug-mailing function doesn't work).
If things are that hosed, there are other reasons why you're going to
need to be sophisticated enough to use M-x view-lossage or C-x b "
*Message-Log*" to get the output. I think our play here is to make
the report function as robust as possible.
This is preferable, yes.
B. Errors in a custom.el file show up as being in the init.el file
(specifically, if there's a parentheses imbalance in the
custom.el file, an "End of file" error shows up for the init.el
file... not the custom.el file).
Because of the way XEmacs handles these files, I suspect that you
probably have imbalanced parens in _both_ files.
No. It was custom.el. Changes in init.el didn't do anything; changes in
custom.el, namely locating a forgotten parenthesis, did.
I'll check when I get back to my devel workspace, though.
N.B. custom.el is designed to be written only by code that prints
sexps, there is no user-editable code in there.
If I wanted to deal with software without user-editable parts, I wouldn't
use open-source software...
If you are getting imbalanced parens in custom.el, all I can say is
"whatever you're doing, it's unsupported by XEmacs.org".
I'm afraid that you'll need to get the customization features a _lot_ better
(including clearer, etcetera) before it won't be necessary to edit
custom.el, especially when porting from an earlier version of XEmacs, when
trying to figure out the corresponding modifications to a site-init.el file
(so that I don't have to create seperate custom.el files for root et al
accounts on all the machines...), etcetera.
C. XEmacs gives errors when there isn't an init.el file, which
is
particularly maddening when the cause of removal of the init.el
file is the previous problem.
What errors?
Given that I'm currently in the middle of editing some modules for BioPerl,
doing email via VM, etcetera, I'm afraid that I can't tinker with things at
the moment - I will try to get back to you with this info.
D. auto-autoload.el should _not_ be doing "error" if a
file is
It's not doing error (which means to stop loading autoloads and throw
to top-level),
Then why is the function called "error" (holding head...)?
it's giving a warning about a very-hard-to-debug
situation. Live with it or use display-warning-minimum-level; that
information is needed to help other users.
You're saying that we'll never need any of the information that
display-warning-minimum-level will cut off?
already included; it should simply return.
Wrong. If auto-autoloads detects that it has been previously loaded,
that means one of three things: a bad build,
Doesn't seem to be the case.
multiple copies of packages on your load-path,
Not the case, unless it's looking in the old xemacs-20.4 directory.
or a seriously mutilated load-path.
It's loading from one directory and its subdirectories, the major ones being
lisp (normal installed code), xemacs-packages (packages), and site-packages
(one subdirectory, lisp, with site-init.el in it).
Either way, we want XEmacs to yell about it.
Ed> (As it is, I'm writing a Perl script to correct all the
Ed> auto-autoload.el files, since there doesn't seem to be a way
Ed> to automatically reconstruct them properly.
Don't do this. It is a known design bug in the package system that
there is no easy way to build the packages correctly without checking
out the whole source hierarchy. However, it is not going to be easy
to fix in a backward compatible way.
I see. Unfortunate.
In the meantime I strongly urge
you to find all the copies of the package hierarchy you have
installed, delete them, download the sumo tarball (tarballs if you
want Mule),
Not doable - one reason that we've been forced to upgrade to Xemacs 21.* is
that 20.*'s use-every-package system resulted in entirely too much
memory/swap-space consumption. (BTW, speaking of this, if one is not doing a
MULE xemacs, why pray tell is it considered necessary to have iso-8859-1
capabilities, as opposed to us-ascii? I note that 'x-iso8859-1.el' and
'iso8859-1.el' are, for some reason, not in the 'mule' directory - why
that
one is present at all in a non-MULE xemacs is also mystifying.) Admittedly,
IRIX has problems with memory and swap space... incidentally, if people ever
start looking at doing Xemacs with threading, you will need to use the
standard IRIX malloc, not any other malloc. sbrk is _not_ thread-safe on
IRIX! IRIX's malloc has internal thread coding so that it _is_ thread-safe
to use, but only if it's the only thing doing memory allocations. Currently,
xemacs' malloc does seem to be working, which I do find impressive, BTW -
good job with it.
and reinstall packages from scratch. Unless you have a
really slow (worse than ISDN) link,
Network speed is not the problem by any means.
this will be faster than doing it by hand, and much more likely to
be
correct.
I didn't do the editing by hand... after some experimentation, I concluded
that there wasn't any way to easily persuade them to simply skip all the
initiation code if it'd already been done (lisp badly needs a _built-in_ return
command...), so I wrote a script that went through and deleted the
error-exit line. This has not caused any easily-noticeable problems; it's
possible that things are being slowed by loading more than once, however,
especially when going into the customization code.
If you're meaning the package-dependency coding, I would agree that there
are problems - many packages seem to be down as depending on gnus when they
actually simply are _helpful_ to be used _with_ gnus, but there are other
packages they're also usable with, for instance, although this is more an
author's problem than with the code.
Since you only show the md5 shadow, I conclude there is something
wrong with either your build
What? Only possibility is because configure needs to allow input of more
detailed path information, instead of making one do it at the make and make
install stage - unless configure already can do this, and it isn't
documented? (sh configure --help gives, interestingly enough, the error "|:
No such file or directory", which I will confess I find odd; other configure
arguments don't cause this, and it isn't because IRIX uses the Korn shell
instead of the Bourne shell by default - bsh configure --help gives the same
thing.)
or your init files (user or system);
System site-start.el:
(setq auto-mode-alist (cons '("\\.pm$" . cperl-mode) auto-mode-alist)) ;
Perl Modules
(setq auto-mode-alist (cons '("\\.not$" . text-mode) auto-mode-alist)) ;
Notes
(setq auto-mode-alist (cons '("/tmp/[^.]*/\\.ed[^/]*$" . text-mode)
auto-mode-alist)) ; MediaMail
(setq auto-mode-alist (cons '("\\.tmpl$" . c-mode) auto-mode-alist)) ; Imake
templates
(setq auto-mode-alist (cons
'("config/\\(cf/\\)?[^/]+\\.\\(cf\\|def\\|rules\\)$" . c-mode)
auto-mode-alist)) ;; Imake cf, def, and rules files
(setq auto-mode-alist (cons '("\\.login$" . shell-script-mode)
auto-mode-alist)) ; Login scripts
(setq auto-mode-alist (cons '("L[0-9]+\\-[0-9]+TMP$" . text-mode)
auto-mode-alist)); Lynx temp editing files
(require 'font-lock)
(set-face-foreground 'font-lock-comment-face "Red")
(add-hook 'perl-mode-hook 'turn-on-font-lock)
(add-hook 'cperl-mode-hook 'turn-on-font-lock)
(setq-default cperl-label-offset 0) ; No label offset
(setq-default font-lock-maximum-decoration t)
(require 'filladapt)
(setq text-mode-hook 'turn-on-auto-fill)
(add-hook 'text-mode-hook 'turn-on-filladapt-mode)
(setq html-mode-hook 'turn-off-filladapt-mode)
(setq html-mode-hook '(auto-fill-mode 0))
(setq hm--html-mode-hook 'turn-off-filladapt-mode)
(setq hm--html-mode-hook '(auto-fill-mode 0))
(setq-default line-number-mode t)
(load "big-menubar")
(setq ediff-diff-options "-bdB")
(setq-default coding-system-for-write 'raw-text)
(custom-set-variables
'(font-lock-maximum-size nil)
'(widget-push-button-gui nil)
'(pop-up-windows nil)
'(popper-pop-buffers nil)
'(widget-glyph-enable nil)
'(cperl-font-lock t)
'(cperl-min-label-indent 0)
'(cperl-extra-perl-args "-w")
'(paren-mode (quote sexp) nil (paren))
'(cperl-invalid-face nil)
'(ctl-arrow 256)
)
(custom-set-faces
'(default ((t (:background "white"))) t)
'(yellow ((t (:foreground "yellow" :background "gray80"))) t)
'(cperl-invalid-face "default")
'(cperl-nonoverridable-face ((((class color) (background light)) nil)))
)
Given that it was showing up with _all_ packages, I would not think the "load"
or "require" statements in the above would be enough to cause
problems. Given that it was happening no matter _what_ was done to the
init.el files, and for all users, I don't think it can be user init files
(unless it's a problem with installing the updated versions - .emacs does
_not_ seem to get created properly, for instance, if there was an old
version that is now supposed to be referring to .xemacs/init.el).
otherwise you would not be getting duplicate loads of the packages.
Umm... methinks you are making assumptions of perfect coordination of
packages dependent on each other wanting loading (possibly when they
autoload to supply a function, if that's how this works?) that may not be
allowing for unanticipated but non-erroneous situations.
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
For those of us who have brain damage restricting our non-verbal abilities,
a verbally-oriented programming language like Perl is a "god"send...
Yours,
-Allen
--
Allen Smith http://cesario.rutgers.edu/easmith/
September 11, 2001 A Day That Shall Live In Infamy II
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin
10:37 a.m.
>>>> "Ed" == Ed Allen Smith
<easmith(a)beatrice.rutgers.edu> writes:
Ed> I apologize if this is overly bad-tempered,
Not bad-tempered IMO. But not knowing your particular situation, I
addressed what I believe to be the most common reasoning for the
particular issues you raise. Some of them are XEmacs bugs, but mostly
they are constraints we have to live with.
Ed> If I wanted to deal with software without user-editable parts,
Ed> I wouldn't use open-source software...
XEmacs has _lots_ of user-editable parts. custom.el happens to be one
of the few that you should not edit. Really. If custom.el is broken,
it is possible to lose all your customizations.
Ed> I'm afraid that you'll need to get the customization features
Ed> a _lot_ better (including clearer, etcetera) before it won't
Ed> be necessary to edit custom.el,
*shrug* You've been warned. You really really should move it
somewhere else, take what you need, and put that in site-init. Then
_delete_ custom.el and reset what is left by hand.
There is work being done on creating "custom themes", but I don't know
when it will be usable, or whether those themes will be easily
portable across users. They're supposed to be....
> D. auto-autoload.el should _not_ be doing "error" if a
file is
>
> It's not doing error (which means to stop loading autoloads and
> throw to top-level),
Ed> Then why is the function called "error" (holding head...)?
I didn't see any "errors" in your list, just warnings. AFAICT those
warnings were generated by `display-warning'. ... OK, you're right,
auto-autoloads is calling error. Evidently for packages those errors
(maybe a better term would be "exceptions", the primitive function
that implements this stuff is called "signal") are caught and turned
into warnings, I'm not sure where. If this happens with the "core"
lisp it is _not_ caught and XEmacs does return to top-level (we have a
bug like that going on currently in the devel branch, where we're
working on autoloads for DSOs).
> it's giving a warning about a very-hard-to-debug situation.
> Live with it or use display-warning-minimum-level; that
> information is needed to help other users.
Ed> You're saying that we'll never need any of the information
Ed> that display-warning-minimum-level will cut off?
No, you are. :-) I know we need that information; it's up to you to
decide if you want it turned off because you don't like it. If you
_do_ want that information later, it will be _logged_ to the buffer
named " *Message-Log*"; you just don't get the pop-up warning.
There's also `display-warning-suppressed-classes' which might be more
appropriate, except that it looks like the class is "warning" which
you probably don't want to suppress as a class.
> multiple copies of packages on your load-path,
Ed> Not the case, unless it's looking in the old xemacs-20.4
Ed> directory.
It might very well be doing so if it was configured that way.
However, I don't think so, because it's complaining about ecrypto,
which is not a 20.4 package, it's only a couple months old.
> or a seriously mutilated load-path.
Ed> It's loading from one directory and its subdirectories, the
Ed> major ones being lisp (normal installed code), xemacs-packages
Ed> (packages), and site-packages (one subdirectory, lisp, with
Ed> site-init.el in it).
Try evaluating
(cl-prettyprint load-path)
in the buffer named "*scratch*". Use C-x h M-x sort-lines RET to sort
the lines so that identical ones will be neighbors and see what you
get. Also the output of xemacs -batch -debug-paths would be useful.
Ed> This has not caused any easily-noticeable problems; it's
Ed> possible that things are being slowed by loading more than
Ed> once, however, especially when going into the customization
Ed> code.
You _will_ run into problems with this eventually when you have two
non-identical versions of some library and ignore the warnings.
Ed> What? Only possibility is because configure needs to allow
Ed> input of more detailed path information,
_What_ "detailed path information"?!!?! If you're mucking with the
definitions of $lispdir and/or $sitelispdir in the Makefile then you
may have introduced multiple mentions of the packages in there. We
are not kidding when we call these options "DEPRECATED". Furthermore,
that will not show up in Installation, which is generated by configure.
Ed> unless configure already can do this, and it isn't documented?
If you mean stuff like --bindir=/path/to/home/of/user/binaries/ and
--infodir=/path/to/info/, yes, configure can do that. Here's the
list:
dnl Has the user specified one of the path options?
prefix | exec_prefix | bindir | datadir | statedir | libdir | \
mandir | infodir | infopath | lispdir | etcdir | pkgdir | \
archlibdir | docdir | package_path | moduledir )
Here's the documentation, such as it is:
$ ./configure --usage | fgrep -A9 'Installation options:'
Installation options:
--prefix=DIR Install files below DIR. Defaults to `/usr/local'.
--with-prefix=no (Bool) Compile the value of `--prefix' into XEmacs.
--infodir=DIR Install XEmacs Info manuals and dir in DIR.
--moduledir=DIR Install dynamic modules in DIR.
You may also specify any of the `path' variables found in Makefile.in.in,
including `--bindir', `--libdir', `--docdir', `--lispdir',
`--sitelispdir',
`--datadir', `--mandir' and so on. These options are DEPRECATED; see INSTALL.
(I don't have a copy of the old configure.usage around, this is the
21.4.10 version. There is similar wording somewhere in ./configure
--help for 21.4.9, though.)
Ed> (sh configure --help gives, interestingly enough, the error
Ed> "|: No such file or directory", which I will confess I find
Ed> odd;
I can't replicate this on Linux. I'll try some other systems, but
this looks like something that would be specific to Irix, then.
Ed> (unless it's a problem with installing the updated versions -
Ed> .emacs does _not_ seem to get created properly, for instance,
Ed> if there was an old version that is now supposed to be
Ed> referring to .xemacs/init.el).
Details? Works for me, as they say. So I can't guess how it's not
working for you.
> otherwise you would not be getting duplicate loads of the
> packages.
Ed> Umm... methinks you are making assumptions of perfect
Ed> coordination of packages dependent on each other wanting
Ed> loading (possibly when they autoload to supply a function, if
Ed> that's how this works?) that may not be allowing for
Ed> unanticipated but non-erroneous situations.
Methinks you're not allowing for the fact that something this ugly
would have been reported multiple times, and I've never heard of it
before. It is possibly an XEmacs bug, this stuff is incredibly hairy
(it used to be worse, and often simply incorrect), but whatever it is
it requires a rather unusual environment to manifest.
Here's the scheme: normally the code in libraries is declarations and
definitions of data and functions. This means that up to certain
ugliness concerned with inlining of Lisp macros during compilation,
order of loading doesn't matter, as long as functions are not being
redefined. Where files recursively require each other, you can simply
provide feature-a before requiring feature-b. Since autoloading
simply executes all the necessary loading before returning to execute
the user code, all the relevant functions should be properly defined
in the environment when the user code starts executing again.
This _does_ work as desired unless someone deliberately introduces
code that manipulates the load process directly.
Now, what the auto-autoloads do is to set up the triggers for lazy
loading when a function is called. This allows XEmacs to dispense
with requires in init.el. The only exceptions are programs like
filladapt, whose entry points are modified core functions, and
therefore may only be loaded explicitly on user request.
If you "double-load" an autoload during the initialization process,
you are OK (unless some package is set up to do perverse things while
loading). That's why those double-loads are caught and converted from
errors to warnings at initialization. However, consider the example
of filladapt. Suppose you load filladapt, and then one of its
functions gets overwritten by an autoload? filladapt cannot find out
about this---it does not reset the filladapt feature to nil. Thus, a
duplicate load of an auto-autoloads file is likely to be a severe
error.
> this will be faster than doing it by hand, and much more likely
> to be correct.
Ed> I didn't do the editing by hand...
Of course not. But you won't do any debugging by script....
Ed> This has not caused any easily-noticeable problems; it's
Ed> possible that things are being slowed by loading more than
Ed> once, however, especially when going into the customization
Ed> code.
It probably won't cause any problems if in fact what is happening is
that identical packages are being loaded twice at initialization. If
the packages are not identical, you could have dependency problems
where an old version of the code is the one left when all is said and
done, or there are mixtures of old and new code, and if happens after
some of the packages are actually loaded, you could have bugs like the
filladapt case above.
Ed> If you're meaning the package-dependency coding, I would agree
Ed> that there are problems - many packages seem to be down as
Ed> depending on gnus when they actually simply are _helpful_ to
Ed> be used _with_ gnus,
Those are compile-time dependencies. If they require or load a file
from Gnus, or autoload a function from Gnus, or do so recursively via
some other file they load .... This is a reasonable heuristic for
run-time dependencies, too, with the exception of dependencies on
Gnus. Lisp has a lot more mutual recursion than I ever saw in Perl.
Ed> (BTW, speaking of this, if one is not doing a MULE xemacs, why
Ed> pray tell is it considered necessary to have iso-8859-1
Ed> capabilities, as opposed to us-ascii? I note that
Ed> 'x-iso8859-1.el' and 'iso8859-1.el' are, for some reason, not
Ed> in the 'mule' directory - why that one is present at all in a
Ed> non-MULE xemacs is also mystifying.)
This is The Kitchen Sink. You can do 8-bit character sets, including
all the ISO-8859 sets, KOI8 and VISCII in a non-Mule XEmacs, so we
provide some helper functions for folks (including English speakers
who need some of the graphics, the pound sterling sign, and the Euro)
so that the use is a little more convenient.
The mule-packages hierarchy is not the home for Mule functionality.
It is a quarantine area for code that a non-Mule XEmacs can't read
correctly. Whenever possible we move code out of there, and into the
xemacs-packages hierarchy.
Ed> incidentally, if people ever start looking at doing Xemacs
Ed> with threading,
Not soon. Minimum of a year from now.
--
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
8082
days inactive
8084
days old
4 comments
3 participants
participants (3)
-
Ed Allen Smith -
Stephen J. Turnbull -
Ville Skyttä