December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Is this the progress gauge ? 24 years, 3 months

Karl M. Hegbloom

>>>>> "Stefanie" == Stefanie Teufel <s.teufel(a)ndh.net> writes: Stefanie> On Tue, Dec 28, 1999 at 17:46:18 +0100, Didier Verna Stefanie> wrote: >> Now that Athena3d doesn't crash my XEmacs anymore, I can see Stefanie> I cannot confirm that - invoking w3 and/or Gnus crashes Stefanie> my XEmacs immediately. I compiled the latest Stefanie> Beta-Version with "--with-athena=xaw" because I read Stefanie> somewhere on xemacs-beta, that there are problems with Stefanie> athena3d and neXT. Okay, I have to admit, that both Stefanie> - athena/athena3d - are linked against the Stefanie> neXTaw-lib. What should I do Stefanie> in order to get a running XEmacs with w3/gnus? I found that what happened here is that XEmacs compiled with athena flat headers, but then run-time linked against xaw3d. There are incompatiblities... on startup, XEmacs would print messages to stdout telling me that some structure sizes are wrong, and to try relinking. It crashed a lot. When I used a LD_PRELOAD telling it to load flat athena, it worked again. I editted /etc/ld.so.conf to put the xaw3d AFTER the standard X libraries, ran ldconfig, and now it links against flat xaw without the LD_PRELOAD. Maybe we should try explicitly building with xaw3d/nextaw, or whatever and see if it works then.

3 participants
3 comments

Re: "Fix" for Progressbar crash....(and the Gutters exit?) 24 years, 3 months

Daniel Pittman

On Mon, 27 Dec 1999, Martin Buchholz <martin(a)xemacs.org> wrote: >>>>>> "KMH" == Karl M Hegbloom <karlheg(a)inetarena.com> writes: > > KMH> On my machine, there is: > > KMH> /usr/X11R6/include/X11/Xaw{,3d} > > KMH> ... and /usr/include/X11 -> ../X11R6/include/X11/ > > KMH> I've found that it is important that /usr/X11R6/lib is BEFORE > KMH> /usr/X11R6/lib/Xaw3d in /etc/ld.so.conf, otherwise, XEmacs is > KMH> built with flat athena headers, but run-time links to athena3d. > > KMH> Hope this helps. > > If you create a `drop-in' replacement for something else, you had > better make sure you do it right. Xaw3d, however, randomly crashes > applications that subclass Athena widgets, so we will have crash > reports from here to eternity. Indeed. That's the second most irritating thing about Xaw3d and friends. The most irritating is that they get installed over the top (or looking like it) of Xaw.so in a lot of places. > Daniel or Andy, suggestions? The new configure stuff will try to link with -lXaw3d when using the 3D stuff. That's usually there any prevents the problem one way around. As to going the other... um... static linking? I can't see any way, other than big red letters in the PROBLEMS file of avoiding the particular lossage with flat Xaw. Painfully. As long as people put incompatible libraries over the top of each other... :( > Do we have to subclass the Athena widgets? I don't know, X is still mostly a mystery to me :/ Daniel (Back from holidays and just under a thousand messages :) -- Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet School of Simulated Simplicity. [Was that sufficiently incendiary? :-)] -- Larry Wall in <1992Jan10.201804.11926(a)netlabs.com>

1 participants
0 comments

OS/2 port of XEmacs -- Re: About some correction... 24 years, 3 months

Ben Wing

This sounds great! If you sync up your work with the latest XEmacs (21.2.25), we will integrate it into the main sources, which should make your life much easier. The latest XEmacs has the portable dumping mechanism in place, so you don't need to worry about your lack of this. ben Alexander Nikolaev wrote: > Hello > > I have some new info about OS/2 port of XEmacs. XEmacs now been compiled using EMX0.9d/PGCC 1.1.3, and now I will debugging some system depended components. > > I work in followed XEmacs configuration: Using XFree86, disabled TTY, enabled PNG/TIFF/GIF supporting,disabled MULE, and DISABLED DUMPING!!! (I don't known how make dumping, i read about plans make dump to separate data file, and merge dumping to OS/2 version after realizing this plan). > > I plan to disribute this port as separate patch (because it not fit to XEmacs architecture - dumping/unexec missing) > > With best regards, Alexander > PS Sorry, my english too ulgy (my native language is russian) -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding.

3 participants
2 comments

Re: More widget flashing 24 years, 3 months

Karl M. Hegbloom

Thanks, Andy. It works now, no flashing. Do you think it will work with athena3d yet?

2 participants
1 comments

Solarys 2.7 21.2.25 crash 24 years, 3 months

Raymond Toy

For the first time in a while, I had enabled the gutter tabs. I was trying to compose a mail via VM when it crashed. I'm not exactly sure when it happened, because I went off and did something else because I thought it was swapping but xemacs was really dumping 100 MB of core. :-) Sorry, the lisp backtrace was truncated, but here's the C backtrace: (gdb) bt #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa757c in fatal_error_signal (sig=11) at emacs.c:276 #2 <signal handler called> #3 DrawHighlight (tw=0x1c43200, child=0x2576a00, undraw=0) at xlwtabs.c:1562 #4 0x23cff8 in TabsHighlight (w=0x1c43200, event=0xffbee57c, params=0x0, num_params=0xfeefa124) at xlwtabs.c:1161 #5 0xfeec1c30 in HandleActions () from /usr/openwin/lib/libXt.so.4 #6 0xfeec0a50 in HandleSimpleState () from /usr/openwin/lib/libXt.so.4 #7 0xfeec0528 in _XtTranslateEvent () from /usr/openwin/lib/libXt.so.4 #8 0xfeec045c in XtDispatchEventToWidget () from /usr/openwin/lib/libXt.so.4 #9 0xfeebfb80 in _XtDefaultDispatcher () from /usr/openwin/lib/libXt.so.4 #10 0xfeebf810 in XtDispatchEvent () from /usr/openwin/lib/libXt.so.4 #11 0xfeec2fa0 in XtAppProcessEvent () from /usr/openwin/lib/libXt.so.4 #12 0x1febdc in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:2600 #13 0x100d4c in detect_input_pending () at event-stream.c:943 #14 0x1034b4 in Fnext_event (event=9192124, prompt=3110916) at event-stream.c:2236 #15 0x898a4 in Fcommand_loop_1 () at cmdloop.c:566 #16 0x89600 in command_loop_1 (dummy=3110916) at cmdloop.c:490 #17 0xada94 in condition_case_1 (handlers=2891776, bfun=0x8959c <command_loop_1>, barg=3110916, hfun=0x89a88 <cmd_error>, harg=3110916) at eval.c:1630 #18 0x89b98 in command_loop_2 (dummy=3110916) at cmdloop.c:252 #19 0xad5e0 in internal_catch (tag=3193172, func=0x89b4c <command_loop_2>, arg=3110916, threw=0x0) at eval.c:1305 #20 0x88e14 in initial_command_loop (load_me=564044) at cmdloop.c:301 #21 0xa9170 in xemacs_21_2_b25_sparc_sun_solaris2_7 (argc=4, argv=0xffbeee9c, envp=0xffbeeeb0, restart=0) at emacs.c:1898 #22 0xa99a8 in main (argc=4, argv=0xffbeee9c, envp=0xffbeeeb0) at emacs.c:2323 Ray

2 participants
1 comments

Re: Xemacs 21.4 unstable 24 years, 3 months

Ben Wing

I mean, did you try temacs -batch -l loadup.el run-temacs? Fabrice Popineau wrote: > * Ben Wing <ben(a)666.com> writes: > > > Have you tried using run-temacs? Fabrice Popineau wrote: > > I have succeded in running temacs under BoundsChecker and dumping > xemacs from there. Some strange things have been reported (I can be > more precise if needed) about some memory blocks overwritten. However, > emacs is doing clever things and it may happen that BoundsChecker be > fooled. > > The most annoying problem is that it is almost impossible to run > xemacs from BoundsChecker : the program is instrumended at ath win32 > api level while running and is far too slow. I might try it on a > faster machine in a few days, but this is a serious problem. It is a > pity because BoundsChecker has proven ti be very useful in tracking > resources leaks in the past. > > All this has been triggered by Adrian Aichner telling me that > something like 'M-x compile' then 'dir' will result in a leak of 2 > handles (xemacs 21.2beta24, native win32). > > Any hint / suggestion /comment welcome, > > Fabrice Popineau -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding.

1 participants
0 comments

21.1.8 crash 24 years, 3 months

Neal D. Becker

21.1 patch 8 i686-pc-linux-gnu (RH5.1) (gdb) where #0 0x403b14e1 in __kill () from /lib/libc.so.6 #1 0x80a1fcb in fatal_error_signal (sig=11) at /net/nbeckerpc/usr/local/src/xemacs-21/src/emacs.c:263 #2 0x403b1408 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x80f11ee in image_instantiate (specifier=143139528, matchspec=136683532, domain=146373736, instantiator=147614752, depth=3) at /net/nbeckerpc/usr/local/src/xemacs-21/src/glyphs.c:514 #4 0x80a4879 in primitive_funcall (fn=0x80f0e58 <image_instantiate>, nargs=5, args=0xbffff080) at /net/nbeckerpc/usr/local/src/xemacs-21/src/eval.c:2862 #5 0x80aa66d in call_with_suspended_errors_1 (opaque_arg=137072880) at /net/nbeckerpc/usr/local/src/xemacs-21/src/eval.c:2060 #6 0x80a3f00 in call_with_suspended_errors ( fun=0x80f0e58 <image_instantiate>, retval=136683532, class=137034168, errb=ERROR_ME_NOT, nargs=5) at /net/nbeckerpc/usr/local/src/xemacs-21/src/eval.c:1328 #7 0x8132fdb in specifier_instance_from_inst_list (specifier=143139528, matchspec=136683532, domain=146373736, inst_list=144181348, errb=ERROR_ME_NOT, no_quit=1, depth=3) at /net/nbeckerpc/usr/local/src/xemacs-21/src/specifier.c:2384 #8 0x81332b3 in specifier_instance (specifier=143139528, matchspec=136683532, domain=146373736, errb=ERROR_ME_NOT, no_quit=1, no_fallback=0, depth=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/specifier.c:2500 ---Type <return> to continue, or q <return> to quit--- #9 0x80f37a1 in glyph_image_instance (glyph=146477968, domain=146373736, errb=ERROR_ME_NOT, no_quit=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/glyphs.c:2866 #10 0x80f1906 in glyph_width (glyph=146477968, frame_face=136934004, window_findex=0, window=146373736) at /net/nbeckerpc/usr/local/src/xemacs-21/src/glyphs.c:2796 #11 0x81177e0 in add_glyph_rune (data=0xbffff3f8, gb=0x8d5feb0, pos_type=1, allow_cursor=0, cachel=0x0) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:1506 #12 0x811828c in create_text_block (w=0x8b97c68, dl=0xbffff578, bi_start_pos=2578, start_col=0, prop=0xbffff574, type=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:1721 #13 0x81164ee in generate_display_line (w=0x8b97c68, dl=0xbffff578, bounds=1, start_pos=2578, start_col=0, prop=0xbffff574, type=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:713 #14 0x811bffa in regenerate_window (w=0x8b97c68, start_pos=2578, point=2394, type=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:4253 #15 0x811ceb2 in redisplay_window (window=146373736, skip_selected=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5040 #16 0x8122da0 in redisplay_windows (window=143429248, skip_selected=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5292 #17 0x811cc13 in redisplay_window (window=147783744, skip_selected=1) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:4935 ---Type <return> to continue, or q <return> to quit--- #18 0x811d91b in redisplay_frame (f=0x87be2f8, preemption_check=0) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5292 #19 0x811da5c in redisplay_device (d=0x8b3cfd8) at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5502 #20 0x811dc59 in redisplay_without_hooks () at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5618 #21 0x81227a6 in redisplay () at /net/nbeckerpc/usr/local/src/xemacs-21/src/redisplay.c:5686 #22 0x80c599a in Fnext_event (event=143502700, prompt=136934004) at /net/nbeckerpc/usr/local/src/xemacs-21/src/event-stream.c:2238 #23 0x808cf6c in Fcommand_loop_1 () at /net/nbeckerpc/usr/local/src/xemacs-21/src/cmdloop.c:570 #24 0x808d19d in command_loop_1 (dummy=136934004) at /net/nbeckerpc/usr/local/src/xemacs-21/src/cmdloop.c:494 #25 0x80a97e2 in condition_case_1 (handlers=136934116, bfun=0x808d184 <command_loop_1>, barg=136934004, hfun=0x808d210 <cmd_error>, harg=136934004) at /net/nbeckerpc/usr/local/src/xemacs-21/src/eval.c:1653 #26 0x808d307 in command_loop_2 (dummy=136934004) at /net/nbeckerpc/usr/local/src/xemacs-21/src/cmdloop.c:256 #27 0x80a96b0 in internal_catch (tag=137008376, func=0x808d2cc <command_loop_2>, arg=136934004, threw=0x0) at /net/nbeckerpc/usr/local/src/xemacs-21/src/eval.c:1328 ---Type <return> to continue, or q <return> to quit--- #28 0x808cc8e in initial_command_loop (load_me=136934004) at /net/nbeckerpc/usr/local/src/xemacs-21/src/cmdloop.c:305 #29 0x80a0a35 in xemacs_21_1_8_i686_pc_linux (argc=1, argv=0xbffffd54, envp=0xbffffd5c, restart=0) at /net/nbeckerpc/usr/local/src/xemacs-21/src/emacs.c:1715 #30 0x80a21e4 in main (argc=1, argv=0xbffffd54, envp=0xbffffd5c) at /net/nbeckerpc/usr/local/src/xemacs-21/src/emacs.c:2132 uname -a: Linux rpppc2.hns.com 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown /net/nbeckerpc/usr/local/src/xemacs-21/configure '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' XEmacs 21.1.8 "Bryce Canyon" configured for `i686-pc-linux'. Where should the build process find the source code? /net/nbeckerpc/usr/local/src/xemacs-21 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits.

1 participants
0 comments

Re: New Release of XEmacs-Packages 24 years, 3 months

Raymond Toy

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Raymond> Unfortunately, my load-path didn't include anything from Raymond> my ~/.xemacs packages, so ilisp couldn't really find out Raymond> where it was loaded from. Stephen> This is what surprised me. AFAIK the library loading code does _not_ Stephen> normally look at the package path variables; these are used to Stephen> determine what goes into the load path. The load path is determined Stephen> by taking certain defaults from paths.h (normally empty), Stephen> EMACSLOADPATH, certain places relative to the XEmacs binary file, and Stephen> then groveling over the various package paths. The latter operation Stephen> is quite expensive (large numbers of stat calls), so the result is Stephen> then cached in `load-path'. But it was my understanding that they Stephen> would only be entered in `load-path' if Lisp libraries were found Stephen> there. Some further investigation now shows the problem. My ~/.xemacs/xemacs-packages and subdirectories are in my load-path. The problem is that ilisp tries to find the file ilisp.elc in my load-path; ilisp.el is there, but it was never compiled. Thus, ilisp finds itself using the wrong path. This is a bug in either ilisp or the Makefile for ilisp since ilisp.el never gets compiled. I'll send this off to the ilisp maintainers. I like Martin's solution though. (Haven't tested it yet.) Ray

1 participants
0 comments

Re: Is this the progress gauge ? 24 years, 3 months

William M. Perry

Stefanie Teufel <s.teufel(a)ndh.net> writes: > On Tue, Dec 28, 1999 at 17:46:18 +0100, Didier Verna wrote: > > > Now that Athena3d doesn't crash my XEmacs anymore, I can see > > I cannot confirm that - invoking w3 and/or Gnus crashes my XEmacs > immediately. I compiled the latest Beta-Version with > "--with-athena=xaw" because I read somewhere on xemacs-beta, that there > are problems with athena3d and neXT. Okay, I have to admit, that both > - athena/athena3d - are linked against the neXTaw-lib. What should I do > in order to get a running XEmacs with w3/gnus? (fmakunbound 'progress) Or remove all references to the 'progress' function in Emacs/W3. url-http.el, url.el, w3-display.el -Bill P.

1 participants
0 comments

LDAP search base? 24 years, 3 months

Raymond Toy

Sometime ago, the new LDAP stuff added a search base. Now when I start xemacs and use ldap for the first time, it asks me if I want to configure a search base. If I answer no, everything is fine. If I answer yes, I get dropped into customize appropriately. However, for someone who knows nothing about ldap, I haven't the faintest clue on what to put into the search base, except that it's a string. There's no help in the customize buffer, so for clueless people like myself, I'm stuck. Yes, I suppose I could go read the appropriate LDAP docs, but there should be some way of disabling the check for search base. Any hints? Ray

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 December 1999