January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Long absence/near inactivity 24 years, 10 months

Colin Rafferty

Jan Vroonhof writes: > Paul Bibilo <peb(a)delcam.com> writes: >> > IMO the most important unapplied patch is Max Matveev improved version >> > of the IRIX dumping from "unexelf on irix (kinda digest)". >> > >> Yes please. I still can't build the current source on my Indy. Here's >> the latest traceback. > You can start by applying the patch by hand and try it out. I have put > the latest version on > http://www.math.ethz.ch/~vroonhof/emacs/sgidump.patch It works for me. Finally. I sent in a build report. -- Colin

1 participants
0 comments

Gutter face fix 24 years, 10 months

Andy Piper

This at least fixes Karl's gripe about changing the buffers tab face changing the whole world. There is still the bug that attributes for the current frame are not changed. andy 2000-01-11 Andy Piper <andy(a)xemacs.org> * gutter-items.el (buffers-tab): Create a new face for the buffers tab. (buffers-tab-face): use it. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: Long absence/near inactivity 24 years, 10 months

Jan Vroonhof

Paul Bibilo <peb(a)delcam.com> writes: > > IMO the most important unapplied patch is Max Matveev improved version > > of the IRIX dumping from "unexelf on irix (kinda digest)". > > > Yes please. I still can't build the current source on my Indy. Here's > the latest traceback. You can start by applying the patch by hand and try it out. I have put the latest version on http://www.math.ethz.ch/~vroonhof/emacs/sgidump.patch Jan

1 participants
0 comments

Re: Long absence/near inactivity 24 years, 10 months

Colin Rafferty

Paul Bibilo writes: > Jan Vroonhof writes: >> IMO the most important unapplied patch is Max Matveev improved version >> of the IRIX dumping from "unexelf on irix (kinda digest)". > Yes please. I still can't build the current source on my Indy. Here's > the latest traceback. On my 6.5 server, I cannot even dump. However, I am doing just fine with run-temacs. -- Colin

1 participants
0 comments

21.2.26 config failure on NT 24 years, 10 months

Raymond Toy

I apologize if I've already sent this in. I don't recall see the message at all. While configuring 21.2.26 on NT with cygwin, the autodetect of sound fails to detect NAS, which I have installed and working on NT. (It worked with version beta 23, the last version I build on NT.) The problem is when configure tries to find AuOpenServer, it fails to link with -lXau to get an authorization routine. To get past this point, I had to add it to the list of libraries to link with. Unfortunately, I don't know enough about configure to know how to fix this. This problem also shows up later when trying to make xemacs. Linking temacs fails for the same reason we couldn't detect AuOpenServer: the link needs to include the libXau library. I suppose this might be a problem of the X11 libraries I have. These are the ones that Andy made for cygwin 19.1 a very long time ago. Ray

1 participants
0 comments

Re: Long absence/near inactivity 24 years, 10 months

Paul Bibilo

Jan Vroonhof writes: > > IMO the most important unapplied patch is Max Matveev improved version > of the IRIX dumping from "unexelf on irix (kinda digest)". > Yes please. I still can't build the current source on my Indy. Here's the latest traceback. dr2% gdb xemacs GNU gdb 19990519 Copyright 1998 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 "mips-sgi-irix6.2"... (gdb) run Starting program: /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/i62-r4k/src/xemacs allocating string (size 16) [] allocating symbol (size 24) [] allocating vector (size 65660) [] allocating string (size 16) [] allocating symbol (size 24) [] allocating string (size 16) [] allocating symbol (size 24) [] allocating string (size 16) [] allocating symbol (size 24) [] allocating string (size 16) [] allocating symbol (size 24) [] Program received signal SIGSEGV, Segmentation fault. 0x44c1e0 in Fcons (car=271689828, cdr=271689732) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/alloc.c:1654 1654 ALLOCATE_FIXED_TYPE (event, struct Lisp_Event, e); (gdb) bt #0 0x44c1e0 in Fcons (car=271689828, cdr=271689732) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/alloc.c:1654 #1 0x6b7790 in deferror (symbol=0x100d6bec, name=0x1001f478 "error", messuhhj=0x1001f480 "error", inherits_from=271689732) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/symbols.c:3424 #2 0x497ea8 in init_errors_once_early () at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/data.c:2227 #3 0x4c1034 in xemacs_21_2_b26_mips_sgi_irix6_2 (argc=1, argv=0x7fff2f24, envp=0x7fff2f2c, restart=0) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:2501 #4 0x4c30b8 in main (argc=1, argv=0x7fff2f24, envp=0x7fff2f2c) at /devdisk/d54man/gnu/xemacs-beta/xemacs-21.2/src/emacs.c:3367 (gdb) -- Paul Bibilo, Delcam plc, | Tel: +44 121 766 5544 Talbot Way, Small Heath, Birmingham, | Fax: +44 121 766 5511 England, B10 0HJ. _____|_____ ICBM-mail: 52 17N 1 30W #include <disclaimer.h> | BLAT FOOP | ICQ: 32045109

1 participants
0 comments

Re: [PATCH] fixes and stuff for the modeline 24 years, 10 months

Didier Verna

Kyle Jones <kyle_jones(a)wonderworks.com> wrote: > Didier, I really don't think there ought to be unscrollable parts > of the modeline. I foresee trouble developing a rationale UI for > such a thing, let alone the hideous uses some will find for it. I find it nice to have some fixed text on the left. People could want for instance to preserve the buffer name from being scrolled out. The idea came to me almost by accident. However, I'm not strongly attached to it, so if the majority thinks it's a bad idea, I'm ready to remove that part. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Re: PATCH: remove warning in gpmevent.c 24 years, 10 months

William M. Perry

Martin Buchholz <martin(a)xemacs.org> writes: > Thanks for the patch. > > Committed to CVS. > > Hey, Bill, is it just a historical accident that you don't have CVS > commit access? > > http://cvs.xemacs.org/#committers Probably. :) I read that the other day and was going to ask for commit access for the URL portions of the code, which I want to see integrated in before 21.2 ships. And do some hacking of the package code to use it. -Bill P.

2 participants
1 comments

Strange error message (INTERNAL EMACS BUG) 24 years, 10 months

Martin Gregory

In XEmacs 21.0 "20 minutes to Nikko" [Lucid] (sparc-sun-solaris2.5.1) of Fri Apr 9 1999 on brabham configured using `configure --prefix=/app_share/xemacs/21.0.67 --with-jpeg=no' When I switch my virtual window manager window away from a virtual window in which I have a Windows terminal server running back to the window in which xemacs is, I get the message you can see below. I have no idea what is special about the Windows terminal server window, except perhaps that it causes colormap flashing on my xterm (if that means anything) wheras none of the other virtual windows do. Also, when I come back from the Windows window, the "I beam" cursor in xemacs is too fat. It changes back if I take it off the xemacs frame and back on again. The error message below occurs even if focus is not given back to xemacs - the message happens as soon as the virtual window is mapped back. It doesn't happen every time, either, of course :-) I'm using fvwm2 for window manager. Wierd, huh? Martin. Recent keystrokes: b u g RET C-s x e m a c s RET ESC x r e p o r t - e m a c s - b u g RET S t r a n g e SPC e r r o r SPC m e s s a g e RET C-x 1 C-l SPC C-a C-h l C-x k RET C-x o C-x k RET C-h a b u s BS g RET ESC x r e p o r t SPC C-g C-l ESC x r e p o r t - e m TAB RET Recent messages (most recent first): unrecognized selection-conversion type: nil, #<INTERNAL EMACS BUG (opaque, size=4) 0x783640> unrecognized selection-conversion type: nil, #<INTERNAL EMACS BUG (opaque, size=4) 0x783640> Quit Loading view-less...done Loading view-less... unrecognized selection-conversion type: nil, #<INTERNAL EMACS BUG (opaque, size=4) 0x783640> Loading emacsbug...done Loading emacsbug... Quit Quit

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 10 months

Daniel Pittman

On Mon, 10 Jan 2000, Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp> wrote: >>>>>> "Daniel" == Daniel Pittman <daniel(a)danann.net> writes: > > Daniel> This is the /wonderful/ Debian thing. > > Daniel> This can't be found through any method short of > Daniel> dynamic-linking of an executable at configure time and > Daniel> looking in the output on STDERR for the cursed `consider > Daniel> relinking' thing. > > Is it really Debian-only (or even Linux-only)? Debian is the only system I know of where having the paths for ld and the dynamic loader are different _and_ a 3D Athena library is placed, named `libXaw.so' in the dynamic load path before the real Xaw library. > If so, you can pick it up by running > > (a) /sbin/ldconfig -p | grep 'libXaw.so.6 \(libc6\).*' | head -1 > (b) grep -i xaw /etc/ld.so.conf | head -1 > or (c) dpkg -l xaw* > > (a) and (b) are probably portable to any glibc system and possibly to > others, (c) only works on Debian. Ugly, but workable, no? Well, yes. I will have a hack at implementing something like this and, at the least, spitting out a warning about the problem. > AFAIK you don't have to be root to use any of those tests (where > available on the system). > > Daniel> It's not actually fixable easily (thanks, Debian) as far > Daniel> as I can see. > > But we only need to detect it and use explicit linking of Xaw3d (or > error and die, if getting that far means we don't know how to > explicitly link Xaw3d), right? Well, that would make the Debian XEmacs binaries depend on the 3D library of choice. I think that the behavior is to detect the Debian lossage, spit out a nasty message and indicate that requesting one of the 3D Athena varieties is needed. > It's the Debian maintainer who has to worry about how to deal with > different libraries on different systems in the Debian release. Well, I guess. So long as our sysadmins here don't decide to make a shared NFS drive available to the two or three dozen Debian boxes we have or something. If they do, it's their problem :/ Still, it's not /that/ big a deal, I guess. Daniel -- They always say time changes things, but you actually have to change them yourself. -- Andy Warhol

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 January 2000