October 2000 - XEmacs-Beta - XEmacs Mailing List Archives

*previous page* broken 23 years, 6 months

Neal D. Becker

Viewing a multi-page article, there seems to be no way to page back. Going to the bold text saying "previous page", neither hitting return nor clicking button2 works. Both are bound to insert text, giving the message that the buffer is read-only. I'm sure this used to work with earlier xemacs/gnus. Gnus v5.8.7 XEmacs 21.1 (patch 12) "Channel Islands" [Lucid] (i686-pc-linux) of Mon Sep 11 2000 on adglinux1.hns.com 200 hnssysb.hns.com InterNetNews NNRP server INN 1.5.1 17-Dec-1996 ready (posting ok).

1 participants
0 comments

Re: [CRASH] in -nw mode / image specifiers 23 years, 6 months

Didier Verna

Stephen J. Turnbull wrote: > OK, I'm seeing the same thing; I _can_ run under gdb BTW, I've just discovered that I also can run gdb, contrary to what I had thought first. What I hadn't noticed is that after the "Cannot access memory at adress xxx" message, the program is in fact running :-/ This actually has something to do with dynamic loading, as demonstrated by this excerpt of a gdb session: ,---- | (gdb) run | Starting program: /usr/local/src/dxemacs/src/xemacs -nw -vanilla | Cannot access memory at address 0x40016e08 | (gdb) where | #0 0x4000cca4 in _dl_debug_state () from /lib/ld-linux.so.2 | (gdb) cont | Continuing. | Cannot access memory at address 0x40016e08 | (gdb) where | #0 0x4000cca4 in _dl_debug_state () from /lib/ld-linux.so.2 | (gdb) cont `----- after that, everything goes well ... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

[CRASH] in -nw mode / image specifiers 23 years, 6 months

Didier Verna

This is under debian woody, latest CVS version. ,---- | - Start XEmacs (21.2) in no-window mode. | - Do: (set-face-background-pixmap 'default "a/path/to/a/pixmap/file") | - Do: C-x 2 (split-window) `----- For me, it crashes immediately. The concerned face-property is the following: #<image-specifier global=((tty) . [string :data "~/share/images/tile/marble.xpm"]) 0x1c8> which looks really bizarre to me. Here the C stacktrace that I get (after a core dump, I can't run "XEmacs -nw" within gdb). What I don't understand is that XEmacs is calling text_query_geometry on the *pixmap file name*. This sounds like a completely bogus image specifier behavior to me, but maybe I'm wrong. I'm not familiar at all with the specifier code, so I can't debug this. Any ideas are welcome. Andy, do you have one ? Current directory is /usr/local/src/dxemacs/src/ GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `./xemacs -vanilla -nw'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x40016e08 #0 0x40456dc1 in ?? () (gdb) up #1 0x40456cf8 in ?? () (gdb) #2 0x81517df in ensure_face_cachel_complete (cachel=0x0, domain={...}, charsets=0xbfffdf18 "") at /usr/local/src/XEmacs-21.2/src/faces.c:1119 (gdb) #3 0x817e826 in query_string_geometry (string={...}, face={...}, width=0xbfffe03c, height=0xbfffe038, descent=0xbfffdff4, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2303 (gdb) #4 0x817eb6a in text_query_geometry (image_instance={...}, width=0xbfffe03c, height=0xbfffe038, disp=IMAGE_DESIRED_GEOMETRY, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2368 (gdb) #5 0x817de8a in image_instance_layout (image_instance={...}, width=-1, height=-1, xoffset=-2, yoffset=-2, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2009 (gdb) print meths $1 = (struct image_instantiator_methods *) 0x8382090 (gdb) print *meths $2 = {symbol = {...}, device = {...}, keywords = 0x83820d8, consoles = 0x83820f0, validate_method = 0, normalize_method = 0, governing_domain_method = 0, possible_dest_types_method = 0, instantiate_method = 0, post_instantiate_method = 0, property_method = 0, set_property_method = 0, update_method = 0x817eb78 <text_update>, redisplay_method = 0, query_geometry_method = 0x817eac0 <text_query_geometry>, layout_method = 0} (gdb) down #4 0x817eb6a in text_query_geometry (image_instance={...}, width=0xbfffe03c, height=0xbfffe038, disp=IMAGE_DESIRED_GEOMETRY, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2368 (gdb) #3 0x817e826 in query_string_geometry (string={...}, face={...}, width=0xbfffe03c, height=0xbfffe038, descent=0xbfffdff4, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2303 (gdb) up #4 0x817eb6a in text_query_geometry (image_instance={...}, width=0xbfffe03c, height=0xbfffe038, disp=IMAGE_DESIRED_GEOMETRY, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2368 (gdb) #5 0x817de8a in image_instance_layout (image_instance={...}, width=-1, height=-1, xoffset=-2, yoffset=-2, domain={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:2009 (gdb) #6 0x817a062 in instantiate_image_instantiator (governing_domain={...}, domain={...}, instantiator={...}, pointer_fg={...}, pointer_bg={...}, dest_mask=-1, glyph={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:793 (gdb) #7 0x818113d in image_instantiate (specifier={...}, matchspec={...}, domain={...}, instantiator={...}, depth={...}) at /usr/local/src/XEmacs-21.2/src/glyphs.c:3217 (gdb) #8 0x80d06fb in call_with_suspended_errors_1 (opaque_arg={...}) at /usr/local/src/XEmacs-21.2/src/eval.c:2112 (gdb) #9 0x80cf278 in internal_catch (tag={...}, func=0x80d0564 <call_with_suspended_errors_1>, arg={...}, threw=0xbfffe340) at /usr/local/src/XEmacs-21.2/src/eval.c:1317 (gdb) #10 0x80d0c5a in call_with_suspended_errors ( fun=0x8180944 <image_instantiate>, retval={...}, class={...}, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, nargs=5) at /usr/local/src/XEmacs-21.2/src/eval.c:2204 (gdb) #11 0x821111c in specifier_instance_from_inst_list (specifier={...}, matchspec={...}, domain={...}, inst_list={...}, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, no_quit=1, depth={...}) at /usr/local/src/XEmacs-21.2/src/specifier.c:2506 (gdb) #12 0x82115d0 in specifier_instance (specifier={...}, matchspec={...}, domain={...}, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, no_quit=1, no_fallback=1, depth={...}) at /usr/local/src/XEmacs-21.2/src/specifier.c:2625 (gdb) #13 0x8151d3d in update_face_cachel_data (cachel=0xbfffe58c, domain={...}, face={...}) at /usr/local/src/XEmacs-21.2/src/faces.c:1194 (gdb) #14 0x8152dec in add_face_cachel (w=0x86a1110, face={...}) at /usr/local/src/XEmacs-21.2/src/faces.c:1330 (gdb) #15 0x8152fc0 in get_builtin_face_cache_index (w=0x86a1110, face={...}) at /usr/local/src/XEmacs-21.2/src/faces.c:1361 (gdb) #16 0x8153072 in reset_face_cachels (w=0x86a1110) at /usr/local/src/XEmacs-21.2/src/faces.c:1380 (gdb) #17 0x8254dab in Fsplit_window (window={...}, chsize={...}, horflag={...}) at /usr/local/src/XEmacs-21.2/src/window.c:3637 (gdb) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

3 participants
2 comments

Re: [CRASH] in -nw mode / image specifiers 23 years, 6 months

Didier Verna

Andy Piper <andyp(a)bea.com> wrote: > Do you have the config that is causing this (Xdefaults?) Nothing actually: it's also with -vanilla, and I don't have any X resources app-defaults (neither on the root window) for XEmacs. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Re: [CRASH] in -nw mode / image specifiers 23 years, 6 months

Didier Verna

Gunnar Evermann wrote: > > I can't run "XEmacs -nw" within gdb > > Why not? I do that all the time. You can even return to the gdb prompt > with C-g. I appearantly can't do that on my linux box. gdb complains that it "Cannot access memory at address 0x40016e08" as soon as I try to run xemacs within it. BTW, I have other weird problems from time to time, like once in a while a core produced by XEmacs is in "unreadable format" for gdb, I don't know why. These strange problems have only occured on linux in my experience. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

21.2.36 - STATUS_ACCESS_VIOLATION in temacs with cygwin 1.1.4 23 years, 6 months

Dr. Volker Zell

Hi With cygwin-1.1.4 compiling 21.2.36 I get at the temacs run: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow -L/usr/X11/lib -Wl,-export-dynamic -I/gnu/src/xemacs-21.2.36/src -o temacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o debug.o tests.o filelock.o ntplay.o unexcw.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o file-coding.o realpath.o getloadavg.o inline.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o ! ! event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o sheap.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o free-hook.o vm-limit.o ralloc.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lipc -lXm -ltiff -lpng -ljpeg -lz -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lgdbm -lncurses -lpq -lldap -llber -L/usr/local/pgsql/lib -L/usr/local/lib -lssl -lcrypto -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32! ! -lcomctl32 -lwinspool ./temacs -nd -batch -l /gnu/src/xemacs-21.2.36/src/../lisp/update-elc.el 0 [main] temacs 11706 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 44490 [main] temacs 11706 stackdump: Dumping stack trace to temacs.exe.stackdump Signal 11 make[1]: *** [update-elc.stamp] Error 139 Running gdb gives the following: vzell:/gnu/src/xemacs-21.2.36/src> gdb -nw ./temacs GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) r Starting program: /gnu/src/xemacs-21.2.36/src/./temacs.exe Program received signal SIGSEGV, Segmentation fault. 0x444f15 in xhash_table (hash_table=0) at elhash.c:416 416 CHECK_HASH_TABLE (hash_table); Any hints ? Compiling 21.2.35 worked fine with the same environment. Ciao Volker

2 participants
1 comments

Re: [sumner@graphics.lcs.mit.edu] Faces wrong when opening new frame (PR#1465) 23 years, 6 months

Daniel Pittman

On 11 Oct 2000, Daniel Pittman <daniel(a)rimspace.net> wrote: > On 11 Oct 2000, Yoshiki Hayashi <yoshiki(a)xemacs.org> wrote: > >> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > [...] > >>> (1) Custom is _full_ of calls to reset-face type functions that >>> destroy user customizations unless they were made through >>> Custom. >> >> Not in this case. Suppose you use Alexander's .emacs and >> opened a new frame. As he wrote, it's shown in default >> face. Then evaluate (setq frame-background-mode 'dark) and >> open another frame. It's displayed in right faces. > > Not in my case. I still see the same effects. I end up with the > font-lock-comment-face being cyan in the second frame, while it's > green in the first frame. > > I made sure that `frame-background-mode' was set correctly, as well. > It seemed to be right. Further to this, the face changes are made by `initialize-custom-faces'. This is called from `custom-initialize-frame', because the global frame properties don't match the new frame properties. These values come from `get-custom-frame-properties', with the global properties already being cached in `default-custom-frame-properties'. The value in there, incidentally, has `light' as the background. Daniel -- Trust the art, not the artist. -- Bruce Springsteen

1 participants
0 comments

Re: [sumner@graphics.lcs.mit.edu] Faces wrong when opening new frame (PR#1465) 23 years, 6 months

Daniel Pittman

On 11 Oct 2000, Yoshiki Hayashi <yoshiki(a)xemacs.org> wrote: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: [...] >> (1) Custom is _full_ of calls to reset-face type functions that >> destroy user customizations unless they were made through Custom. > > Not in this case. Suppose you use Alexander's .emacs and > opened a new frame. As he wrote, it's shown in default > face. Then evaluate (setq frame-background-mode 'dark) and > open another frame. It's displayed in right faces. Not in my case. I still see the same effects. I end up with the font-lock-comment-face being cyan in the second frame, while it's green in the first frame. I made sure that `frame-background-mode' was set correctly, as well. It seemed to be right. [...] >> I think adjusting faces with respect to the default face's background >> is a very bad idea as a basic function; it should be done at a very >> high level, such as Custom themes. At lower levels, functions should >> do what the user says. > > Hmm... Then what background spec of defface is for? I'm > not a particular fun of it, but I think it's useful. I think that the big issue is that the software continues to adapt itself to the default background color, despite my telling explicitly what I want. I think that if I only set the default face, having XEmacs change the rest of it's faces to something readable is nice. When I explicitly set the face properties, I would expect them to stay, even if that's unreadable. Daniel -- We fear that pop-culture is the only culture we're ever going to have. We want to stop reading magazines, stop watching tv, stop caring about Hollywood, but we're addicted to the things we hate. -- KMFDF, _Dogma_

1 participants
0 comments

gcc 2.7.2 on ix86 23 years, 6 months

Gunnar Evermann

configure.in contains the following: --------------------------- *:i*86*:2.7.2*) case "$GCC_VERSION" in 2.7.2) case "$CFLAGS" in *-O2*|*-O3*) case "$CFLAGS" in *-fno-strength-reduce*) ;; *) AC_MSG_RESULT(yes) AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) AC_MSG_WARN(-fno-strength-reduce.) AC_MSG_ERROR(Aborting due to known problem) ;; esac ;; esac ;; esac case "$CFLAGS" in *-fno-caller-saves*) ;; *) AC_MSG_RESULT(yes) AC_MSG_WARN(Don't use -O2 with gcc 2.7.2 under Intel/XXX without also using) AC_MSG_WARN(-fno-caller-saves.) AC_MSG_ERROR(Aborting due to known problem) ;; esac ;; ----------------------------- what exactly is the point pf the second block? Do we really want to prevent people using -O1 or no optimisation at all from building XEmacs. If so, we should adjust the message. Gunnar

2 participants
1 comments

CORE on close-buffer 23 years, 6 months

Norbert Koch

Hi! XEmacs 21.2 (beta36) "Notus" [Lucid] (i386-unknown-freebsd3.3) of Tue Oct 10 2000 on lamia.LF.net I was copying a section from a file-buffer into a Gnus article. After closing the file-buffer, xemacs closed on me... with the following C-stack, no Lisp-backtrace besides the abort-trap I saw the same behaviour some days ago. I guess, it's a GC issue, because of (gdb) up 5 #5 0x80c1499 in error (fmt=0x8298960 "Marker does not point #anywhere") at eval.c:2052 2052 RETURN_UNGCPRO (signal_1 (error_symbol, data)); But perhaps the corrupt marker is the culprit in the first place. #0 0x184e23d0 in kill () from /usr/lib/libc.so.3 #1 0x80ba5c3 in fatal_error_signal (sig=6) at emacs.c:531 #2 0xbfbfdfdc in ?? () #3 0x80bd55a in assert_failed (file=0x826bbcf "eval.c", line=1885, expr=0x826bbc7 "abort()") at emacs.c:3189 #4 0x80bffe5 in signal_1 (sig=137410660, data=156630796) at #eval.c:1885 #5 0x80c1499 in error (fmt=0x8298960 "Marker does not point #anywhere") at eval.c:2052 #6 0x817925e in marker_position (marker=158115548) at marker.c:348 #7 0x819217c in redisplay_window (window=158399488, skip_selected=0) at redisplay.c:5897 #8 0x8192eb0 in redisplay_frame (f=0x8e98400, preemption_check=0) at redisplay.c:6394 #9 0x8193093 in redisplay_device (d=0x9470d00, automatic=1) at redisplay.c:6468 #10 0x8193409 in redisplay_without_hooks () at redisplay.c:6557 #11 0x819b3ce in redisplay () at redisplay.c:6614 #12 0x80fdfc0 in Fnext_event (event=148261680, prompt=137410564) at event-stream.c:2206 #13 0x80a230f in Fcommand_loop_1 () at cmdloop.c:570 #14 0x80a25c2 in command_loop_1 (dummy=137410564) at cmdloop.c:494 #15 0x80c993a in condition_case_1 (handlers=137410660, bfun=0x80a2584 <command_loop_1>, barg=137410564, hfun=0x80a2634 <cmd_error>, harg=137410564) at eval.c:1651 #16 0x80a2727 in command_loop_2 (dummy=137410564) at cmdloop.c:256 #17 0x80c983c in internal_catch (tag=137494628, func=0x80a26ec <command_loop_2>, arg=137410564, threw=0x0) at eval.c:1317 #18 0x80a1b66 in initial_command_loop (load_me=137410564) at #cmdloop.c:305 #19 0x80bb8fe in xemacs_21_2_b36_i386_unknown_freebsd3_3 (argc=4, argv=0xbfbfd790, envp=0xbfbfd7a4, restart=0) at emacs.c:2228 #20 0x80bd7b9 in main (argc=4, argv=0xbfbfd790, envp=0xbfbfd7a4) at emacs.c:2657 #21 0x808607d in _start ()

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta October 2000