12:47 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!
There appears to be a very annoying border display glitch which is
most evident when you set the following X resource (although see below
for a reproducible recipe in a vanilla environment):
XEmacs*EmacsFrame.internalBorderWidth: 0
Here's the odd thing: building XEmacs 21.4.8 from scratch, and from
source, I only see the bug on my Redhat 7.3 box. I do not see the bug
on my Mandrake 8.2, 8.1, or Redhat 6.1 systems. All are built with
the same configure option (see below). Note that it's the build box
that matters, not the box the window is being displayed on. If I
gnuclient tunnel a window over ssh from the RH6.1 system to the RH7.3
display, no border display glitch. If I tunnel the window from RH7.3
to the RH6.1 display, border glitch.
Here's how to reproduce it in a completely vanilla environment.
1. Make sure you have no XEmacs or Emacs X resources set.
2. xemacs -vanilla
3. M-x customize-face RET default RET
4. (set the background to gray25)
5. (set face for current session)
6. C-l
After hitting the C-l you should see a thin gray line drawn just
inside the X window's frame border. This line is the same color as
the gutter, modeline, and toolbar background. When the X resource
internalBorderWidth is set to 0, this will draw over any characters in
column zero. Because C-l nails you it's very difficult to clean up.
One more piece of information which may or may not matter: I'm using
Fvwm 2.4.6 as my window manager. On the RH7.3 system this comes from
the standard RH install. On the Mandrake 8.2 box, it is also the
standard package (I believe). On the MD8.1 and RH6.1 systems, it's
the same Fvwm version built from source.
I'm going to build Fvwm2 from source on RH7.3 just to see if it's a
window manager problem, although I doubt it is. I can send a screen
capture if you don't believe me. :)
-Barry
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: Linux dhcp113.zope.com 2.4.18-4 #1 Thu May 2 18:47:38 EDT 2002 i686 unknown
./configure '--with-mule'
XEmacs 21.4.8 "Honest Recruiter" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /usr/local/src/xemacs-21.4.8
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Linking with `-z nocombreloc'.
- Consider configuring with --pdump.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
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 LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using Motif to provide XIM support.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
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:
----------------------
nil
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.07 :type regular)
(xslide :version 1.02 :type regular)
(xemacs-devel :version 1.44 :type single-file)
(xemacs-base :version 1.63 :type regular)
(w3 :version 1.23 :type regular)
(vm :version 7.04 :type regular)
(viper :version 1.34 :type regular)
(view-process :version 1.11 :type regular)
(vhdl :version 1.15 :type regular)
(vc-cc :version 1.18 :type regular)
(vc :version 1.3 :type regular)
(tramp :version 1.05 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.32 :type regular)
(time :version 1.11 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.43 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.23 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(slider :version 1.13 :type regular)
(skk :version 1.22 :type regular)
(sieve :version 1.02 :type regular)
(sh-script :version 1.15 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.12 :type regular)
(scheme :version 1.11 :type regular)
(rmail :version 1.13 :type regular)
(reftex :version 1.25 :type regular)
(psgml :version 1.28 :type regular)
(ps-print :version 1.04 :type regular)
(prog-modes
:version
1
.56
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.61 :type regular)
(pc :version 1.22 :type single-file)
(os-utils :version 1.28 :type single-file)
(net-utils :version 1.24 :type single-file)
(mule-ucs :version 1.04 :type regular)
(mule-base :version 1.4 :type regular)
(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.14 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.11 :type regular)
(mail-lib :version 1.46 :type regular)
(lookup :version 1.1 :type regular)
(locale :version 1.18 :type regular)
(liece :version 1.04 :type regular)
(leim :version 1.18 :type regular)
(latin-unity :version 1.05 :type regular)
(jde :version 1.35 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.22 :type regular)
(igrep :version 1.08 :type regular)
(idlwave :version 1.25 :type regular)
(ibuffer :version 1.07 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.04 :type regular)
(gnus :version 1.6 :type regular)
(gnats :version 1.14 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(frame-icon :version 1.09 :type regular)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.36 :type regular)
(eterm :version 1.13 :type regular)
(eshell :version 1.03 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.02 :type regular)
(egg-its :version 1.26 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.85 :type single-file)
(ediff :version 1.41 :type regular)
(edict :version 1.13 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.12 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.15 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.03 :type regular)
(cc-mode :version 1.28 :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.05 :type regular)
(bbdb :version 1.2 :type regular)
(auctex :version 1.31 :type regular)
(apel :version 1.23 :type regular)
(ada :version 1.1 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 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
slider-autoloads skk-autoloads sieve-autoloads sh-script-autoloads
sgml-autoloads semantic-autoloads scheme-autoloads rmail-autoloads
reftex-autoloads psgml-autoloads ps-print-autoloads
prog-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads net-utils-autoloads mule-ucs-autoloads
mule-base-autoloads mmm-mode-autoloads misc-games-autoloads
mine-autoloads mh-e-autoloads mew-autoloads mailcrypt-autoloads
mail-lib-autoloads lookup-autoloads locale-autoloads liece-autoloads
leim-autoloads latin-unity-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 forms-autoloads footnote-autoloads eudc-autoloads
eterm-autoloads eshell-autoloads emerge-autoloads elib-autoloads
eieio-autoloads egg-its-autoloads efs-autoloads edt-autoloads
edit-utils-autoloads ediff-autoloads edict-autoloads edebug-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
lisp-autoloads loadhist auto-show fontl-hooks x-iso8859-1 canna-leim
slovenian czech romanian ccl mule-help code-cmds gutter-items
menubar-items x-menubar mode-motion mouse itimer auto-save lisp-mode
easymenu iso8859-1 page buff-menu lib-complete cus-file derived frame
text-props obsolete cus-start custom widget cl-extra mini-cl cl cl-19
packages backquote very-early-lisp postgresqlv7 postgresql CANNA
file-coding wnn mule lucid-scrollbars cut-buffer lucid-menubars
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 md5 xemacs xim
gutter tiff png gif jpeg xpm xbm lisp-float-type linux dialog devices
window-system base64)
Recent keystrokes:
-----------------
ESC x r e p o r t - x e TAB RET
Recent messages (most recent first):
-----------------------------------
Parsing /home/barry/.mailrc...
Loading xemacsbug...done
Loading xemacsbug...
3:45 a.m.
>>>> "BAW" == Barry A Warsaw
<barry(a)python.org> writes:
BAW> I only see the bug on my Redhat 7.3 box.
Yup.
You'd think that Somebody(a)python.org could figure that out in
under 1.52 seconds.<wink>
In the near future I'll be making up an issues list (finals are over,
only the grading is left), but IIRC the kludges needed to work around
the upstream (RH 7.3 only, not XFree, maybe) breakage are too
complicated for 21.4, so .... There's always NetBSD.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:38 a.m.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "BAW" == Barry A Warsaw
<barry(a)python.org> writes:
BAW> I only see the bug on my Redhat 7.3 box.
SJT> Yup.
Ah, cool, you see it too then?!
SJT> You'd think that Somebody(a)python.org could figure that out in
SJT> under 1.52 seconds.<wink>
Oh dang, you're right, it's the Python bridge between XEmacs and
XFree86. At line 732 in border.py where it says
while 1:
distance += 1
if text.obscures(distance):
lisp.eval('(draw-annoying-line t)')
break
Change the `annoying' to `beautiful'.
SJT> In the near future I'll be making up an issues list (finals
SJT> are over, only the grading is left), but IIRC the kludges
SJT> needed to work around the upstream (RH 7.3 only, not XFree,
SJT> maybe) breakage are too complicated for 21.4, so ....
SJT> There's always NetBSD.
Ouch. Or... MacOSX? :)
So what did RH /do/ to break this? Is the problem in the XEmacs code,
the X libraries, some place else? Any ideas, or hints of places to
look?
-Barry
9:32 a.m.
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
BAW> So what did RH /do/ to break this? Is the problem in the
BAW> XEmacs code, the X libraries, some place else? Any ideas, or
BAW> hints of places to look?
I'm not sure it's RH after all. Nix seems to think it's GCC 3. See
thread at http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
Now, of course there's a good chance that whatever broke in GCC 3 is
in Red Hat's "improved" version of gcc 2.9x.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:08 p.m.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
BAW> So what did RH /do/ to break this? Is the problem in the
BAW> XEmacs code, the X libraries, some place else? Any ideas, or
BAW> hints of places to look?
SJT> I'm not sure it's RH after all. Nix seems to think it's GCC
SJT> 3. See thread at
SJT> http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
SJT> Now, of course there's a good chance that whatever broke in
SJT> GCC 3 is in Red Hat's "improved" version of gcc 2.9x.
Yup, that's the exact same problem I'm seeing, and just like the folks
in that thread, I'm also using "RH-enhanced" gcc 2.96:
% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
Thanks for the pointer.
I'll try sucking down various gcc 3.x's and see if they make any
difference.
Note also that RH has released some updated libc's although their free
support line is severely overloaded so I'm unable to update. Perhaps
it's a libc problem, although some broken optimization in gcc seems a
more likely candidate.
Thanks,
-Barry
6:46 p.m.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> I'm not sure it's RH after all. Nix seems to think it's GCC
SJT> 3. See thread at
SJT> http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
SJT> Now, of course there's a good chance that whatever broke in
SJT> GCC 3 is in Red Hat's "improved" version of gcc 2.9x.
>>>> "BAW" == <bwarsaw(a)python.org>
writes:
BAW> Yup, that's the exact same problem I'm seeing, and just like
BAW> the folks in that thread, I'm also using "RH-enhanced" gcc
BAW> 2.96:
BAW> % gcc -v Reading specs from
BAW> /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version
BAW> 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
BAW> I'll try sucking down various gcc 3.x's and see if they make
BAW> any difference.
Building w/ a from-source fresh build of gcc 3.1 makes no
difference.:(
What next?
-Barry
3:32 a.m.
[Nix:
I been taking your name in vain.... Barry is seeing the bug described
at http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
Any progress?]
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
BAW> Building w/ a from-source fresh build of gcc 3.1 makes no
BAW> difference. :(
BAW> What next?
If I read Nix's comments right, it's GCC 3.x that is (possibly) doing
something bogus, and I suspect RH has backported it. Possibilities:
(1) --debug, --pdump, --use-union-type all change the layout of the
code in ways that change optimizer behavior. Especially
--use-union-type.
(2) Back up to vanilla 2.95.4. (I am _not_ seeing this on Debian.)
(3) Ping Nix Who Seems To Know. (done with this message)
--
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
5:46 a.m.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> I been taking your name in vain.... Barry is seeing the bug
SJT> described at
SJT> http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
SJT> Any progress?
For me, just in getting more confuzzled. :(
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
BAW> Building w/ a from-source fresh build of gcc 3.1 makes no
BAW> difference. :(
So I just brought up another box on Redhat 7.3, updated all my
installed packages, rsync'd my XEmacs 21.4.8 source from my RH6.1 box,
did a "make distclean ; ./configure --with-mule ; make" and guess
what?
No display glitches.
I also tried the XEmacs 21.4.6 package that comes w/ RH7.3 and it also
displays just fine.
I'm baffled. The only difference I can tell between the two RH7.3
machines is that the first one (the one with the display glitch) I
didn't install, while I did install the one that works fine. I can't
see how that could make any difference though -- both are up2date with
all packages.
I actually can't get into the buggy box right now as that's at the
office and the network appears down. :( Here at home, I'm using the
following packages:
XFree86-4.2.0-8
gcc-2.96-10
glibc-2.2.5-36
SJT> If I read Nix's comments right, it's GCC 3.x that is
SJT> (possibly) doing something bogus, and I suspect RH has
SJT> backported it. Possibilities:
SJT> (1) --debug, --pdump, --use-union-type all change the layout
SJT> of the code in ways that change optimizer behavior.
SJT> Especially --use-union-type.
Those options aren't advertised as available on the gcc on my home
RH7.3 box.
SJT> (2) Back up to vanilla 2.95.4. (I am _not_ seeing this on
SJT> Debian.)
SJT> (3) Ping Nix Who Seems To Know. (done with this message)
Nix? What can you tell us?
-Barry
6:15 a.m.
RH 7.3 on my laptop with 21.4.8 (Windows) works just fine.
andy
At 12:46 AM 6/28/02 -0400, bwarsaw(a)python.org wrote:
>>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> I been taking your name in vain.... Barry is seeing the bug
SJT> described at
SJT> http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
SJT> Any progress?
For me, just in getting more confuzzled. :(
>>>>> "BAW" == bwarsaw <bwarsaw(a)python.org> writes:
BAW> Building w/ a from-source fresh build of gcc 3.1 makes no
BAW> difference. :(
So I just brought up another box on Redhat 7.3, updated all my
installed packages, rsync'd my XEmacs 21.4.8 source from my RH6.1 box,
did a "make distclean ; ./configure --with-mule ; make" and guess
what?
No display glitches.
I also tried the XEmacs 21.4.6 package that comes w/ RH7.3 and it also
displays just fine.
I'm baffled. The only difference I can tell between the two RH7.3
machines is that the first one (the one with the display glitch) I
didn't install, while I did install the one that works fine. I can't
see how that could make any difference though -- both are up2date with
all packages.
I actually can't get into the buggy box right now as that's at the
office and the network appears down. :( Here at home, I'm using the
following packages:
XFree86-4.2.0-8
gcc-2.96-10
glibc-2.2.5-36
SJT> If I read Nix's comments right, it's GCC 3.x that is
SJT> (possibly) doing something bogus, and I suspect RH has
SJT> backported it. Possibilities:
SJT> (1) --debug, --pdump, --use-union-type all change the layout
SJT> of the code in ways that change optimizer behavior.
SJT> Especially --use-union-type.
Those options aren't advertised as available on the gcc on my home
RH7.3 box.
SJT> (2) Back up to vanilla 2.95.4. (I am _not_ seeing this on
SJT> Debian.)
SJT> (3) Ping Nix Who Seems To Know. (done with this message)
Nix? What can you tell us?
-Barry
6:26 a.m.
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
SJT> (1) --debug, --pdump, --use-union-type all change the layout
SJT> of the code in ways that change optimizer behavior.
SJT> Especially --use-union-type.
BAW> Those options aren't advertised as available on the gcc on my
BAW> home RH7.3 box.
That's 'cause they're options to XEmacs's ./configure. Sorry, shoulda
been more explicit.
--
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
6:36 a.m.
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> That's 'cause they're options to XEmacs's ./configure.
SJT> Sorry, shoulda been more explicit.
Gotcha. Will try again tomorrow when They fix the routers that must
have gotten zapped by lightening earlier tonight.
-Barry
8:39 a.m.
On Fri, 28 Jun 2002, bwarsaw(a)python.org stipulated:
>>>>> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org>
writes:
SJT> I been taking your name in vain.... Barry is seeing the bug
SJT> described at
SJT> http://list-archive.xemacs.org/xemacs-beta/200205/msg00189.html.
SJT> Any progress?
For me, just in getting more confuzzled. :(
The glitches went away when I upgraded to GCC-3.1, by the way. (I only
saw them on a sparc-sun-solaris2.8 box, but that was the only box I was
using with both XEmacs and GCC-3.0.x on it...)
I'm baffled. The only difference I can tell between the two
RH7.3
machines is that the first one (the one with the display glitch) I
didn't install, while I did install the one that works fine. I can't
How *utterly* bizarre.
SJT> If I read Nix's comments right, it's GCC 3.x that
is
SJT> (possibly) doing something bogus, and I suspect RH has
SJT> backported it. Possibilities:
It may be GCC-3.0.x (at least on SPARC/Solaris 2.8) but if it is then
the problem was fixed before 3.1 was released. So I'm not likely to
bother tracking this down. :)
SJT> (1) --debug, --pdump, --use-union-type all change the
layout
SJT> of the code in ways that change optimizer behavior.
SJT> Especially --use-union-type.
Those options aren't advertised as available on the gcc on my home
RH7.3 box.
Er, that's because those are XEmacs configure script options ;}
SJT> (3) Ping Nix Who Seems To Know. (done with this
message)
Nix? What can you tell us?
If it is GCC (and I'm really not sure; I've only got one data point)
then GCC-3.1 doesn't have the problem.
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'
3:19 p.m.
>>>> "N" == Nix <nix(a)esperi.demon.co.uk>
writes:
N> The glitches went away when I upgraded to GCC-3.1, by the
N> way. (I only saw them on a sparc-sun-solaris2.8 box, but that
N> was the only box I was using with both XEmacs and GCC-3.0.x on
N> it...)
gcc3.1's had no effect for me on the glitchy box.
> I'm baffled. The only difference I can tell between the two
> RH7.3 machines is that the first one (the one with the display
> glitch) I didn't install, while I did install the one that
> works fine. I can't
N> How *utterly* bizarre.
Indeed!
> SJT> (1) --debug, --pdump, --use-union-type all change the
> layout SJT> of the code in ways that change optimizer behavior.
> SJT> Especially --use-union-type.
> Those options aren't advertised as available on the gcc on my
> home RH7.3 box.
N> Er, that's because those are XEmacs configure script options ;}
Yup, and none of them seem to make any difference either. :(
> SJT> (3) Ping Nix Who Seems To Know. (done with this
message)
> Nix? What can you tell us?
N> If it is GCC (and I'm really not sure; I've only got one data
N> point) then GCC-3.1 doesn't have the problem.
Very Strange Things are Going On. I bet It is the Law of Conservation
of Glitchy Universal Secret Revelation. Only one person in the world
is allowed to view This Mysterious and Enlightening Phenomenon at a
time. Either you were powerful enough to decipher Its Meanings and
aren't telling us (I know we must discover Them on our own), or you
too failed to grasp Its Universal Message. Either way, It's moved on
to attempt another Conversion. I admit intellectual defeat now, so
can The Glitch please go Visit someone else for a while?
been-reading-A-Beautiful-Mind-too-much-this-morning-ly y'rs,
-Barry
3:56 p.m.
>>>> "BAW" == <bwarsaw(a)python.org>
writes:
BAW> Very Strange Things are Going On. I bet It is the Law of
BAW> Conservation of Glitchy Universal Secret Revelation. Only
BAW> one person in the world is allowed to view This Mysterious
BAW> and Enlightening Phenomenon at a time. Either you were
BAW> powerful enough to decipher Its Meanings and aren't telling
BAW> us (I know we must discover Them on our own), or you too
BAW> failed to grasp Its Universal Message. Either way, It's
BAW> moved on to attempt another Conversion. I admit intellectual
BAW> defeat now, so can The Glitch please go Visit someone else
BAW> for a while?
See? Invoke the name of the Glitch Witch and ye shall be redeemed.
I figure it out (for me, at least ;).
The glitchy machine had the openmotif-devel-2.2.2-5 package installed,
which caused XEmacs's configure to link against libXm.so and use
"Motif dialog boxes", "Motif native widgets", and "Motif to
provide
XIM Support". Found by comparing ldd output against the two executables.
On the non-glitchy box, this package wasn't installed so it just uses
the Lucid widgets and "raw Xlib" for XIM.
Removed the rpm (nothing else depended on it), recompile, and so long
Wicked Glitch of the East (or perhaps West for Steve? ;).
I'm willing to chalk this up as a bug in the openmotif-devel package
and be done with it, but if anybody has more motifation <wink> they
may want to at least verify and perhaps pursue this more with the
openmotif developers.
-Barry
5:01 p.m.
At 10:56 AM 6/28/02 -0400, bwarsaw(a)python.org wrote:
I'm willing to chalk this up as a bug in the openmotif-devel
package
and be done with it, but if anybody has more motifation <wink> they
may want to at least verify and perhaps pursue this more with the
openmotif developers.
Hmmn, does this bug cause the top pixel of the toolbar to get obscured? If
so then yes I am seeing it on RH 7.3 with motif.
And I thought it was a bug I had introduced :)
andy
5:46 p.m.
>>>> "AP" == Andy Piper <andyp(a)bea.com>
writes:
AP> At 12:21 PM 6/28/02 -0400, bwarsaw(a)python.org wrote:
> I hadn't noticed, but I typically run without toolbars.
AP> You run without toolbars, but *with* gutters?!
You're kidding, right? :)
I only run with wm borders and scrollbars because removing them
wouldn't let me get any more usable screen real-estate (in a font and
resolution my aging eyes can still read).
no-gutters-for-me-ly y'rs,
-Barry
7:02 p.m.
bwarsaw(a)python.org writes:
I only run with wm borders and scrollbars because removing them
wouldn't let me get any more usable screen real-estate (in a font and
resolution my aging eyes can still read).
Since the real-estate problem is usually in the vertical direction, I
move the toolbars to the left.
(set-default-toolbar-position 'left)
Cheers,
Sean
3:22 a.m.
>>>> "BAW" == bwarsaw
<bwarsaw(a)python.org> writes:
BAW> The glitchy machine had the openmotif-devel-2.2.2-5 package
Get thee behind me, Satan! To PROBLEMS with ye!
That openmotif stuff (reported on RH only, interestingly) is related
to a lot of hard-to-diagnose problems.
Nix, does OpenMotif seem related for you? Have you rebuilt OpenMotif
with GCC 3.1?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:28 p.m.
On 29 Jun 2002, Stephen J. Turnbull muttered drunkenly:
Nix, does OpenMotif seem related for you? Have you rebuilt
OpenMotif
with GCC 3.1?
I'm using LessTif here, but the Solaris box I saw the problems on was,
indeed, using Motif.
I'll try rebuilding on that with GCC-3.1 next week (when I have access
to that machine next): if the problem is indeed Motif-related, I expect
it not to go away.
(Who needs MS software when you've got Motif :( )
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'
7972
days inactive
7975
days old
20 comments
6 participants
participants (6)
-
Andy Piper -
Barry Warsaw -
bwarsaw＠python.org -
Nix -
Sean MacLennan -
Stephen J. Turnbull