7:21 p.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!
The function set-progress-feedback-instantiator in gutter-items.el
does not work correctly if called with the LOCALE argument omitted.
A simple fix is as follows:
diff -u gutter-items.el.orig gutter-items.el
--- gutter-items.el.orig Sat Mar 08 19:19:20 2003
+++ gutter-items.el Sat Mar 08 19:19:32 2003
＠＠ -423,6 +423,7 ＠＠
:descriptor "Progress"])
(defun set-progress-feedback-instantiator (&optional locale)
+ (setq locale (or locale (current-locale)))
(cond
((eq progress-feedback-style 'small)
(setq progress-glyph-height 16)
================================================================
System Info to help track down your bug:
---------------------------------------
OS version:
4NT 5.00U Windows XP 5.1
OS: Windows_NT
XEmacs 21.5-b11 "cabbage" configured for `i586-pc-win32'.
Building XEmacs using "nmake".
Building XEmacs using make flags " ".
Building XEmacs in "C:\\Data\\XEmacs\\xemacs-21.5.11\\nt".
Using compiler "cl -nologo -W3 -DSTRICT -O2 -G5 -Ob2 -MD".
Installing XEmacs in "C:\\Apps\\XEmacs\\XEmacs-21.5-b11".
Package path is
"~\\.xemacs;;C:\\Apps\\XEmacs\\site-packages;C:\\Apps\\XEmacs\\mule-packages;C:\\Apps\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in international (MULE) support.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for GZIP compression/decompression.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library.
Compiling with optimization.
Load-Path Lisp Shadows:
----------------------
(c:\Apps\XEmacs\xemacs-packages\lisp\ecrypto\sha1-el
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\sha1-el
c:\Apps\XEmacs\xemacs-packages\lisp\ecrypto\hex-util
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\hex-util
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\starttls
c:\Apps\XEmacs\xemacs-packages\lisp\mail-lib\starttls
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\rfc2104
c:\Apps\XEmacs\xemacs-packages\lisp\mail-lib\rfc2104
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pop3
c:\Apps\XEmacs\xemacs-packages\lisp\mail-lib\pop3
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\netrc
c:\Apps\XEmacs\xemacs-packages\lisp\mail-lib\netrc
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg-pgp5
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg-pgp5
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg-pgp
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg-pgp
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg-parse
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg-parse
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg-gpg
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg-gpg
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\pgg-def
c:\Apps\XEmacs\xemacs-packages\lisp\pgg\pgg-def
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\sieve
c:\Apps\XEmacs\xemacs-packages\lisp\sieve\sieve
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\sieve-mode
c:\Apps\XEmacs\xemacs-packages\lisp\sieve\sieve-mode
c:\Apps\XEmacs\xemacs-packages\lisp\gnus\sieve-manage
c:\Apps\XEmacs\xemacs-packages\lisp\sieve\sieve-manage
c:\Apps\XEmacs\mule-packages\lisp\mule-base\viet-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\viet-util
c:\Apps\XEmacs\mule-packages\lisp\mule-base\korea-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\korea-util
c:\Apps\XEmacs\mule-packages\lisp\mule-base\japan-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\japan-util
c:\Apps\XEmacs\mule-packages\lisp\mule-base\ethio-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\ethio-util
c:\Apps\XEmacs\mule-packages\lisp\mule-base\cyril-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\cyril-util
c:\Apps\XEmacs\mule-packages\lisp\mule-base\china-util
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\mule\china-util
c:\Apps\XEmacs\mule-packages\lisp\mule-ucs\unicode
c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\unicode)
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.11 :type regular)
(xslide :version 1.03 :type regular)
(xemacs-devel :version 1.48 :type single-file)
(xemacs-base :version 1.71 :type regular)
(w3 :version 1.26 :type regular)
(vm :version 7.07 :type regular)
(viper :version 1.35 :type regular)
(view-process :version 1.12 :type regular)
(vhdl :version 1.15 :type regular)
(vc-cc :version 1.21 :type regular)
(vc :version 1.33 :type regular)
(tramp :version 1.1 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.34 :type regular)
(time :version 1.12 :type regular)
(textools :version 1.13 :type regular)
(text-modes :version 1.55 :type single-file)
(texinfo :version 1.21 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.24 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(sml-mode :version 0.05 :type regular)
(slider :version 1.13 :type regular)
(sieve :version 1.1 :type regular)
(sh-script :version 1.16 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.14 :type regular)
(scheme :version 1.12 :type regular)
(sasl :version 1.12 :type regular)
(ruby-modes :version 1.0 :type single-file)
(rmail :version 1.13 :type regular)
(reftex :version 1.28 :type regular)
(python-modes :version 1.01 :type single-file)
(psgml-dtds :version 1.02 :type regular)
(psgml :version 1.35 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.67
:type
single-file)
(pgg :version 1.01 :type regular)
(perl-modes :version 1.02 :type single-file)
(pcomplete :version 1.02 :type regular)
(pcl-cvs :version 1.64 :type regular)
(pc :version 1.25 :type single-file)
(os-utils :version 1.29 :type single-file)
(ocaml :version 0.03 :type regular)
(net-utils :version 1.28 :type single-file)
(mmm-mode :version 1.0 :type regular)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.16 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.12 :type regular)
(mail-lib :version 1.54 :type regular)
(liece :version 1.1 :type regular)
(jde :version 1.38 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.28 :type regular)
(igrep :version 1.1 :type regular)
(idlwave :version 1.27 :type regular)
(ibuffer :version 1.08 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.03 :type regular)
(gnus :version 1.64 :type regular)
(gnats :version 1.15 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(frame-icon :version 1.09 :type regular)
(fortran-modes :version 1.01 :type single-file)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.36 :type regular)
(eterm :version 1.13 :type regular)
(ess :version 1.02 :type regular)
(eshell :version 1.03 :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.95 :type single-file)
(ediff :version 1.44 :type regular)
(edebug :version 1.14 :type regular)
(ecrypto :version 0.12 :type regular)
(docbookide :version 0.05 :type regular)
(dired :version 1.12 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.16 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.04 :type regular)
(cc-mode :version 1.31 :type regular)
(calendar :version 1.19 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.07 :type regular)
(bbdb :version 1.21 :type regular)
(auctex :version 1.32 :type regular)
(apel :version 1.25 :type regular)
(ada :version 1.11 :type regular)
(skk :version 1.23 :type regular)
(mule-ucs :version 1.04 :type regular)
(mule-base :version 1.42 :type regular)
(lookup :version 1.13 :type regular)
(locale :version 1.2 :type regular)
(leim :version 1.19 :type regular)
(latin-unity :version 1.07 :type regular)
(egg-its :version 1.26 :type regular)
(edict :version 1.13 :type regular))
Features:
--------
(xemacsbug shadow info view-less view debug hyper-apropos gnus-topic
nnfolder pop3 byte-optimize bytecomp byte-compile nnml nndraft nnmh
efs-cu bbdb-gnus bbdb-snarf mail-extr bbdb-com gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mm-view
gnus-sum gnus-group gnus-undo nnmail mail-source format-spec nntp nnoo
gnus-cache filladapt gnus-start gnus-spec gnus-int gnus-range message
mml mml-sec mml-smime smime comint ring dig mml1991 mml2015 pgg
pgg-parse pgg-def mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2045 rfc2231 rfc2047 qp ietf-drums mail-abbrevs sendmail rfc822
mailheader canlock gnus-win gnus gnus-ems gnus-xmas messagexmas
gnus-util netrc time-date parse-time nnheader nnheaderxm mail-utils
mm-util mail-prsvr wid-edit dabbrev pending-del font-lock cus-face
bbdb timezone zenirc-autoloads xslt-process-autoloads xslide-autoloads
xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads
viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads
vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads
tm-autoloads time-autoloads textools-autoloads text-modes-autoloads
texinfo-autoloads supercite-autoloads strokes-autoloads
speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads
sml-mode-autoloads slider-autoloads sieve-autoloads
sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads
sasl-autoloads ruby-modes-autoloads rmail-autoloads reftex-autoloads
python-modes-autoloads psgml-dtds-autoloads psgml-autoloads
ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads ocaml-autoloads net-utils-autoloads
mmm-mode-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads
mew-autoloads mailcrypt-autoloads mail-lib-autoloads liece-autoloads
jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads
idlwave-autoloads ibuffer-autoloads hm--html-menus-autoloads
haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads
fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
ess-autoloads eshell-autoloads emerge-autoloads elib-autoloads
eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads
ediff-autoloads edebug-autoloads ecrypto-autoloads
docbookide-autoloads dired-autoloads dictionary-autoloads
debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads
cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
apel-autoloads ada-autoloads skk-autoloads mule-ucs-autoloads
mule-base-autoloads lookup-autoloads locale-autoloads leim-autoloads
latin-unity-autoloads egg-its-autoloads edict-autoloads mule-autoloads
auto-autoloads loadhist rsz-minibuf auto-show fontl-hooks tibetan lao
devanagari indian slovenian czech romanian ccl code-cmds gutter-items
menubar-items x-menubar dragdrop mode-motion mouse behavior itimer
auto-save lisp-mode easymenu iso8859-1 page buff-menu lib-complete
cus-file derived env text-props frame obsolete cus-start custom widget
cl-extra mini-cl cl cl-19 packages backquote very-early-lisp unicode
mswindows-scrollbars mswindows toolbar native-sound scrollbar
network-streams subprocesses menu-accelerator-support menubar md5
xemacs mule gutter tiff png gif jpeg xface xpm xbm lisp-float-type
file-coding dde windows-nt dragdrop-api dialog devices window-system
base64)
Recent keystrokes:
-----------------
t e - c o m p i l e - TAB f TAB RET misc-user Sh-home
DEL Sh-insert \ g u t t TAB - i TAB RET M-x l o a d
- l i TAB RET g u t t TAB - i t TAB RET misc-user q
C-c C-k m C-c C-k misc-user M-x x e m a c s - b u TAB
BS BS BS BS BS BS BS BS BS BS q C-h a b u g RET next
q M-x r e p o r t - x e m TAB RET
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Notice: Unable to instantiate font for charset japanese-jisx0208, face default
Notice: Unable to instantiate font for charset japanese-jisx0208, face
hyper-apropos-documentation
Entering debugger...
Loading gutter-items...done
Loading gutter-items...
Wrote c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\gutter-items.elc
Compiling c:\Apps\XEmacs\XEmacs-21.5-b11\lisp\gutter-items.el...done
Compiling gutter-items.el... (buffers-tab-omit-some-buffers)
Compiling gutter-items.el... (progress-feedback-with-label)
Compiling gutter-items.el... (progress-feedback)
Compiling gutter-items.el... (current-progress-feedback-label)
Compiling gutter-items.el... (current-progress-feedback)
Compiling gutter-items.el... (display-progress-feedback)
Compiling gutter-items.el... (raw-append-progress-feedback)
Compiling gutter-items.el... (abort-progress-feedback)
Compiling gutter-items.el... (append-progress-feedback)
Compiling gutter-items.el... (progress-feedback-dispatch-non-command-events)
Compiling gutter-items.el... (remove-progress-feedback)
4:10 p.m.
The function set-progress-feedback-instantiator in gutter-items.el
does not work correctly if called with the LOCALE argument omitted.
A simple fix is as follows:
Unforunately, the fix doesn't seem to work. There's something strange
going on here, as the function is defined
(defun set-progress-feedback-instantiator (&optional locale) ...)
which *should* mean that locale is nil if it wasn't specified.
The actual problem is that in Oort Gnus 0.15, sending an e-mail fails
to work, with the message "Variable's value is void: locale". An error
backtrace shows
Signaling: (void-variable locale)
set-progress-feedback-instantiator(#<window on "*mail to
xemacs-beta(a)xemacs.org*" 0x1ed7>)
raw-append-progress-feedback("Fontifying *mail to xemacs-beta＠xemacs.org*..."
0 #<mswindows-frame "emacs" 0xd20>)
append-progress-feedback(font-lock "Fontifying *mail to
xemacs-beta＠xemacs.org*..." 0 nil)
display-progress-feedback(font-lock "Fontifying *mail to
xemacs-beta＠xemacs.org*..." 0)
progress-feedback-with-label(font-lock "Fontifying %s..." 0 "*mail to
xemacs-beta(a)xemacs.org*")
font-lock-default-unfontify-region(1 1 t)
font-lock-unfontify-region(1 1 t)
font-lock-default-fontify-buffer()
font-lock-fontify-buffer()
font-lock-mode(1)
turn-on-font-lock()
font-lock-set-defaults()
message-xmas-maybe-fontify()
run-hooks(message-xmas-maybe-fontify)
derived-mode-run-hooks(message-mode)
message-mode()
message-pop-to-buffer("*mail to xemacs-beta(a)xemacs.org*")
... some lines omitted here ...
call-interactively(report-xemacs-bug)
command-execute(report-xemacs-bug t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
The odd things are:
1. set-progress-feedback-instantiator is being called with a window as
the argument, not a locale.
2. The problem doesn't exist with 21.6.10, even though the code for
set-progress-feedback-instantiator is the same.
3. Executing (load-library "gutter-items") makes the problem go away,
even though it's the same version of the module as is compiled into
XEmacs.
If anyone has any suggestions on how to locate this problem, I'd be
happy to help.
Paul.
12:06 p.m.
hmm ...
[1] do you have any local modifications in your code base?
[2] try doing a total, total rebuild. `make realclean' and then rm *.elc in the
lisp/ and lisp/mule/ directories, then rebuild. it will take a while.
if after [2] you still see the problem, then something is definitely weird. but
i have a feeling it'll go away.
ben
----- Original Message -----
From: "Paul Moore" <gustav(a)morpheus.demon.co.uk>
To: <xemacs-beta(a)xemacs.org>
Cc: <ben(a)xemacs.org>
Sent: Sunday, March 09, 2003 9:10 AM
Subject: Re: Error if locale is omitted in set-progress-feedback-instantiator
> The function set-progress-feedback-instantiator in
gutter-items.el
> does not work correctly if called with the LOCALE argument omitted.
> A simple fix is as follows:
Unforunately, the fix doesn't seem to work. There's something strange
going on here, as the function is defined
(defun set-progress-feedback-instantiator (&optional locale) ...)
which *should* mean that locale is nil if it wasn't specified.
The actual problem is that in Oort Gnus 0.15, sending an e-mail fails
to work, with the message "Variable's value is void: locale". An error
backtrace shows
Signaling: (void-variable locale)
set-progress-feedback-instantiator(#<window on "*mail to
...
raw-append-progress-feedback("Fontifying *mail to
xemacs-beta＠xemacs.org*..." 0 #<mswindows-frame "emacs"
0xd20>)
append-progress-feedback(font-lock "Fontifying *mail to
xemacs-beta＠xemacs.org*..." 0 nil)
display-progress-feedback(font-lock "Fontifying *mail to
xemacs-beta＠xemacs.org*..." 0)
progress-feedback-with-label(font-lock "Fontifying %s..."
0 "*mail to ...
font-lock-default-unfontify-region(1 1 t)
font-lock-unfontify-region(1 1 t)
font-lock-default-fontify-buffer()
font-lock-fontify-buffer()
font-lock-mode(1)
turn-on-font-lock()
font-lock-set-defaults()
message-xmas-maybe-fontify()
run-hooks(message-xmas-maybe-fontify)
derived-mode-run-hooks(message-mode)
message-mode()
message-pop-to-buffer("*mail to xemacs-beta(a)xemacs.org*")
... some lines omitted here ...
call-interactively(report-xemacs-bug)
command-execute(report-xemacs-bug t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
The odd things are:
1. set-progress-feedback-instantiator is being called with a window as
the argument, not a locale.
2. The problem doesn't exist with 21.6.10, even though the code for
set-progress-feedback-instantiator is the same.
3. Executing (load-library "gutter-items") makes the problem go away,
even though it's the same version of the module as is compiled into
XEmacs.
If anyone has any suggestions on how to locate this problem, I'd be
happy to help.
Paul.
10:03 p.m.
"Ben Wing" <ben(a)666.com> writes:
hmm ...
[1] do you have any local modifications in your code base?
[2] try doing a total, total rebuild. `make realclean' and then rm *.elc in the
lisp/ and lisp/mule/ directories, then rebuild. it will take a while.
if after [2] you still see the problem, then something is definitely weird. but
i have a feeling it'll go away.
OK. I went a bit further than this, and extracted the distribution
tarball again from scratch.
I set HAVE_xxx on for pretty much everything under the sun (MULE, PNG,
JPEG, compface...). I have OPTIMIZED_BUILD=1 and DEBUG_XEMACS=0 and
ERROR_CHECK_ALL=0. When I ran with all the debugging stuff in place,
the build was done in C++ mode, which generated some strange prototype
errors which I didn't have time to diagnose.
The only other change I made was to remove the use of lib-src\i from
xemacs.mak, because it was causing crashes (not sure why, possibly
some interaction with MSVC 6.0 nmake).
[time passes...]
Nope. It still happens.
I now tried another complete rebuild, this time with debug mode on but
with CPLUSPLUS_COMPILE=0 to force C-mode compiling. This fixed the
prototype errors, and let me build OK. With debug mode (and my patch)
there was no problem.
Now I'll try debug mode without my patch.
[time passes...]
No problem. So it looks like it's not my patch, but some sort of
optimiser bug in Visual C 6.0. Ack. That means it's going to be a real
pain to identify.
If there's anything more I can do, let me know. For now, I can add a
line (load-library "gutter-items") into my .gnus, which works around
the problem.
Paul.
PS There seems to be a redraw bug as well. If I start a new frame,
with C-X 5 f ~/.gnus RET, the new frame appears but the contents is
not drawn until I minimise and then restore the window (or
something similar, which causes Windows to request a full repaint
of the window). This is on Windows XP Home, with Service Pack 1, if
it matters...
--
This signature intentionally left blank
8:56 a.m.
hmmmm.
i also use vc 6.
do you have the latest service packs installed? [sp 5 i think]
can you give me a relatively simple way of reproducing the problem, without any
init files etc.? if i can reproduce it i'll see if i can figure out what's
going on.
ben
----- Original Message -----
From: "Paul Moore" <gustav(a)morpheus.demon.co.uk>
To: "Ben Wing" <ben(a)666.com>
Cc: <xemacs-beta(a)xemacs.org>
Sent: Monday, March 10, 2003 3:03 PM
Subject: Re: Error if locale is omitted in set-progress-feedback-instantiator
"Ben Wing" <ben(a)666.com> writes:
> hmm ...
>
> [1] do you have any local modifications in your code base?
> [2] try doing a total, total rebuild. `make realclean' and then rm *.elc in
the
> lisp/ and lisp/mule/ directories, then rebuild. it will take a
while.
>
> if after [2] you still see the problem, then something is definitely weird.
but
> i have a feeling it'll go away.
OK. I went a bit further than this, and extracted the distribution
tarball again from scratch.
I set HAVE_xxx on for pretty much everything under the sun (MULE, PNG,
JPEG, compface...). I have OPTIMIZED_BUILD=1 and DEBUG_XEMACS=0 and
ERROR_CHECK_ALL=0. When I ran with all the debugging stuff in place,
the build was done in C++ mode, which generated some strange prototype
errors which I didn't have time to diagnose.
The only other change I made was to remove the use of lib-src\i from
xemacs.mak, because it was causing crashes (not sure why, possibly
some interaction with MSVC 6.0 nmake).
[time passes...]
Nope. It still happens.
I now tried another complete rebuild, this time with debug mode on but
with CPLUSPLUS_COMPILE=0 to force C-mode compiling. This fixed the
prototype errors, and let me build OK. With debug mode (and my patch)
there was no problem.
Now I'll try debug mode without my patch.
[time passes...]
No problem. So it looks like it's not my patch, but some sort of
optimiser bug in Visual C 6.0. Ack. That means it's going to be a real
pain to identify.
If there's anything more I can do, let me know. For now, I can add a
line (load-library "gutter-items") into my .gnus, which works around
the problem.
Paul.
PS There seems to be a redraw bug as well. If I start a new frame,
with C-X 5 f ~/.gnus RET, the new frame appears but the contents is
not drawn until I minimise and then restore the window (or
something similar, which causes Windows to request a full repaint
of the window). This is on Windows XP Home, with Service Pack 1, if
it matters...
--
This signature intentionally left blank
3:31 p.m.
(Apologies if this comes through in HTML, or some other junk - I'm having to
use Outlook Express due to problems with my ISP :-()
ben(a)666.com wrote:
hmmmm.
i also use vc 6.
do you have the latest service packs installed? [sp 5 i think]
Yes. Whether it's relevant or not, I'm running on Windows XP Home. I have a
Windows 2000 Professional box I can try this on, but I'll have to get it set
up, so I may not get to it today...
can you give me a relatively simple way of reproducing the problem,
without
any init files etc.?
It's pretty simple for me to create:
1. Build XEmacs 21.5.11, with MULE and with optimisation on.
Nondefault options from config.inc.samp (from memory...)
MULE=1
HAVE_TIFF=1
HAVE_XFACE=1
OPTIMIZED_BUILD=1
DEBUG_XEMACS=0
ERROR_CHECK_ALL=0
Also, edit xemacs.mak to remove "$(LIB_SRC)\i" from the definitions of
TEMACS_BATCH, XEMACS_BATCH and XEMACS_BATCH_PACKAGES
(it gave me odd errors - I just click the "OK" button as needed...)
2. Install it (I install to C:\Apps\XEmacs)
3. Unpack the standard and mule sumo distributions into the install dir
(I used the versions dated 2002-12-30)
3. Get Oort Gnus 0.15 from www.gnus.org, at
http://quimby.gnus.org/gnus/dist/ognus-0.15.tar.gz
4. Unpack Gnus, and build/install with make-x.bat <XEmacs location> /copy
5. You should now be able to reproduce the problem with
xemacs.exe -q -f message-mail
if i can reproduce it i'll see if i can figure out what's
going on.
Hope that's enough for you to reproduce it...
Paul.
PS Just tried this on my Windows 2000 box, and it works perfectly :-(
I'll copy the exact installed tree to my XP Home box this evening, and
see if it fails there. (It may be that -q -f message-mail isn't enough
to reproduce the problem. I'll try to get a minimal case that triggers
the bug if that's the case).
9:41 p.m.
"Paul Moore" <gustav(a)morpheus.demon.co.uk> writes:
PS Just tried this on my Windows 2000 box, and it works perfectly
:-(
Actually, with the "broken" version on my XP Home box, xemacs -q -f
message-mail wasn't enough. It needed something extra from my Gnus
setup to trigger the problem. I don't know what, though (Yes I do! See
below).
I'll copy the exact installed tree to my XP Home box this
evening, and
see if it fails there. (It may be that -q -f message-mail isn't enough
to reproduce the problem. I'll try to get a minimal case that triggers
the bug if that's the case).
Ack. I copied the directory tree built on Win2000 across unchanged,
and ran Gnus. No bug. So the same sources, with the same version of
MSVC6, built (as far as I can manage) the same, run on the same box,
with the same configuration, work fine when the build was done on
Windows 2000, but fail when the build was done on XP Home.
I did a complete diff of the 2 installed trees. The only files which
differ are:
* The executables
* The elc files under XEmacs-21.5-b11/lisp
* The elc files under xemacs-packages/lisp/gnus
Why would the elc files differ? Are they not architecture independent?
Could this point to a problem in the byte-compiler somehow? [Nope, I
looked at a bytecode file, the username and machine the bytecode was
compiled on is in there. So that's a red herring...]
I'm baffled. I'll do a few more experiments...
OK, after a bit more checking, the only file that matters is the
executable. Running the EXE built on XP fails with the bug, running
the one built on 2K works, when the executable is in the exact same
installation tree. (I copied both exes into both trees, the 2K exe
worked in both, the XP exe failed in both).
Right. I did a binary search on the initialisation files. The line
that causes the problem is in my custom.el custom-set-variables
section:
'(font-lock-mode nil nil (font-lock))
I've no idea why this breaks one build but not the other.
Just as a check, I looked at (current-locale) on both machines. Both
show "English_United States.1252", so that doesn't look relevant...
I'm out of ideas now. Any suggestions?
Paul.
--
This signature intentionally left blank
12:30 a.m.
On Tue, 11 Mar 2003, Paul Moore wrote:
Right. I did a binary search on the initialisation files. The line
that causes the problem is in my custom.el custom-set-variables
section:
'(font-lock-mode nil nil (font-lock))
I've no idea why this breaks one build but not the other.
Just as a check, I looked at (current-locale) on both machines. Both
show "English_United States.1252", so that doesn't look relevant...
I'm out of ideas now. Any suggestions?
How is stack space handled in MSC exe files? Could it be too small in the
executable compiled under XP? Is any of this statically created at link
time?
4:36 a.m.
the stack space is specified in the makefile.
----- Original Message -----
From: "robert delius royar" <royar(a)adelphia.net>
To: "Paul Moore" <gustav(a)morpheus.demon.co.uk>
Cc: "Ben Wing" <ben(a)666.com>; <xemacs-beta(a)xemacs.org>
Sent: Tuesday, March 11, 2003 5:30 PM
Subject: Re: Error if locale is omitted in set-progress-feedback-instantiator
On Tue, 11 Mar 2003, Paul Moore wrote:
> Right. I did a binary search on the initialisation files. The line
> that causes the problem is in my custom.el custom-set-variables
> section:
>
> '(font-lock-mode nil nil (font-lock))
>
> I've no idea why this breaks one build but not the other.
>
> Just as a check, I looked at (current-locale) on both machines. Both
> show "English_United States.1252", so that doesn't look relevant...
>
> I'm out of ideas now. Any suggestions?
How is stack space handled in MSC exe files? Could it be too small in the
executable compiled under XP? Is any of this statically created at link
time?
4:36 a.m.
i bet there's something subtle going wrong with vc 6 on windows xp, since it's
the build os, not the run os, that matters. this makes some sense since windows
xp didn't exist when vc 6 was created.
it may be that all we can do is put something in PROBLEMS. i dunno. if you can
track down further what's being miscompiled, we may be able to work around it.
[often, it's an expression that's miscompiled, and it's enough to simplify it
using temporary variables.]
but you have to find where the problem is -- that's the rub. if you're patient,
you could try copying over some of the .obj files and relinking -- with a
binary-search-type approach, you can maybe find a single file that's
problematic. to get farther, though, you have to look at the assembly, which is
difficult. [maybe you could get the compiler to output assembly language and do
a diff ...]
ben
----- Original Message -----
From: "Paul Moore" <gustav(a)morpheus.demon.co.uk>
To: "Ben Wing" <ben(a)666.com>
Cc: <xemacs-beta(a)xemacs.org>
Sent: Tuesday, March 11, 2003 2:41 PM
Subject: Re: Error if locale is omitted in set-progress-feedback-instantiator
"Paul Moore" <gustav(a)morpheus.demon.co.uk> writes:
> PS Just tried this on my Windows 2000 box, and it works perfectly
>:-(
Actually, with the "broken" version on my XP Home box, xemacs -q -f
message-mail wasn't enough. It needed something extra from my Gnus
setup to trigger the problem. I don't know what, though (Yes I do! See
below).
> I'll copy the exact installed tree to my XP Home box this evening, and
> see if it fails there. (It may be that -q -f message-mail isn't enough
> to reproduce the problem. I'll try to get a minimal case that triggers
> the bug if that's the case).
Ack. I copied the directory tree built on Win2000 across unchanged,
and ran Gnus. No bug. So the same sources, with the same version of
MSVC6, built (as far as I can manage) the same, run on the same box,
with the same configuration, work fine when the build was done on
Windows 2000, but fail when the build was done on XP Home.
I did a complete diff of the 2 installed trees. The only files which
differ are:
* The executables
* The elc files under XEmacs-21.5-b11/lisp
* The elc files under xemacs-packages/lisp/gnus
Why would the elc files differ? Are they not architecture independent?
Could this point to a problem in the byte-compiler somehow? [Nope, I
looked at a bytecode file, the username and machine the bytecode was
compiled on is in there. So that's a red herring...]
I'm baffled. I'll do a few more experiments...
OK, after a bit more checking, the only file that matters is the
executable. Running the EXE built on XP fails with the bug, running
the one built on 2K works, when the executable is in the exact same
installation tree. (I copied both exes into both trees, the 2K exe
worked in both, the XP exe failed in both).
Right. I did a binary search on the initialisation files. The line
that causes the problem is in my custom.el custom-set-variables
section:
'(font-lock-mode nil nil (font-lock))
I've no idea why this breaks one build but not the other.
Just as a check, I looked at (current-locale) on both machines. Both
show "English_United States.1252", so that doesn't look relevant...
I'm out of ideas now. Any suggestions?
Paul.
--
This signature intentionally left blank
10:45 p.m.
"Ben Wing" <ben(a)666.com> writes:
i bet there's something subtle going wrong with vc 6 on windows
xp, since it's
the build os, not the run os, that matters. this makes some sense since windows
xp didn't exist when vc 6 was created.
Sadly, that sounds plausible...
it may be that all we can do is put something in PROBLEMS. i dunno.
I suppose that's reasonable, although I can imagine it would be
frustrating for people with no access to anything other than XP (it
might be worth pointing out that I've not tried XP Professional, so
that may be fine).
if you can track down further what's being miscompiled, we may
be
able to work around it. [often, it's an expression that's
miscompiled, and it's enough to simplify it using temporary
variables.]
but you have to find where the problem is -- that's the rub. if
you're patient, you could try copying over some of the .obj files
and relinking -- with a binary-search-type approach, you can maybe
find a single file that's problematic. to get farther, though, you
have to look at the assembly, which is difficult. [maybe you could
get the compiler to output assembly language and do a diff ...]
I'll keep that in mind, but frankly I don't imagine I'll have the time
in the forseeable future. The XP box isn't particularly fast, so a
rebuild (even just a relink) takes a while. Binary searching the
object modules sounds like a few days' work...
I'll report back if I ever get this done.
Thanks for the help and suggestions,
Paul.
--
This signature intentionally left blank
10:33 p.m.
Paul Moore <gustav(a)morpheus.demon.co.uk> wrote in
news:vfyofblv.fsf＠morpheus.demon.co.uk:
"Ben Wing" <ben(a)666.com> writes:
> i bet there's something subtle going wrong with vc 6 on windows xp,
> since it's the build os, not the run os, that matters. this makes
> some sense since windows xp didn't exist when vc 6 was created.
Sadly, that sounds plausible...
But isn't true :-(
I've just had the same problem, but this time the other way round. With
beta 21.5.14. I built on Windows 2000, copied to XP Home, and everything
runs fine on XP, but gives the "locale" error on 2000.
And in this case, it's the *same* binary exhibiting different behaviour
on 2 platforms. So whatever's going on, it's a runtime issue rather than
a compiler problem. (At least in part)
> if you can track down further what's being miscompiled, we
may be
> able to work around it. [often, it's an expression that's
> miscompiled, and it's enough to simplify it using temporary
> variables.]
>
> but you have to find where the problem is -- that's the rub. if
> you're patient, you could try copying over some of the .obj files
> and relinking -- with a binary-search-type approach, you can maybe
> find a single file that's problematic. to get farther, though, you
> have to look at the assembly, which is difficult. [maybe you could
> get the compiler to output assembly language and do a diff ...]
There's no way I'm going to have time to do much more with this. I don't
use XEmacs for much more than Gnus, so I don't really have much
incentive to work on this, and my time is seriously limited. So all I
can really offer is to report the problem. If that means it's unfixable,
so be it.
Sorry,
Paul.
7837
days inactive
7930
days old
11 comments
3 participants
participants (3)
-
Ben Wing -
Paul Moore -
robert delius royar