April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Mule and obsolescence 25 years, 7 months

Olivier Galibert

I want to mark some mule functions as obsolete aliases. Where should I do that? obsolete.el while protected by boundp mule ? Some mule-obsolete.el ? OG.

1 participants
0 comments

core dumped 25 years, 7 months

Nick V. Pakoulin

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. In XEmacs 21.2 "Artemis" [Lucid] (i686-pc-linux) of Wed Feb 10 1999 on pegas configured using `configure --external-widget --debug=yes --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/bin/xemacs core ---------------------------------------------------------- #0 0x4027f811 in __kill () #1 0x80a03e1 in fatal_error_signal (sig=6) at emacs.c:264 #2 <signal handler called> #3 0x4027f811 in __kill () #4 0x4028084f in abort () at ../sysdeps/generic/abort.c:83 #5 0x80a202f in assert_failed (file=0x8171ee4 "eval.c", line=1872, expr=0x8171edc "abort()") at emacs.c:2631 #6 0x80a449a in signal_1 (sig=136872548, data=140802532) at eval.c:1872 #7 0x80a4a91 in Fsignal (error_symbol=136872548, data=140802532) at eval.c:2039 #8 0x80912eb in Fcar (list=141566652) at data.c:107 #9 0x80a94ee in Fbacktrace (stream=136984172, detailed=136872408) at eval.c:4816 #10 0x80a03cd in fatal_error_signal (sig=11) at emacs.c:247 #11 <signal handler called> #12 0x807e1de in garbage_collect_1 () at alloc.c:3160 #13 0x80a6681 in Ffuncall (nargs=1, args=0xbfffe9bc) at eval.c:3135 #14 0x80a7389 in run_hook_with_args_in_buffer (buf=0x8876610, nargs=1, args=0xbfffe9bc, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3671 #15 0x80a73d3 in run_hook_with_args (nargs=1, args=0xbfffe9bc, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3684 #16 0x80a74da in run_hook (hook=137595688) at eval.c:3539 #17 0x80825e5 in Fkill_buffer (buffer=143091216) at buffer.c:1216 #18 0x80a689c in Ffuncall (nargs=2, args=0xbfffea74) at eval.c:3189 #19 0x8085d38 in execute_optimized_program ( program=0xbfffeac4 "À\tÂ\"«\016\212\tq\210Ã \210Ä \210)ª\005Å\t!\210Æ\016\a!\210\016\b\026\t\016\n\026\013\016\f\026\r\016\016\026\017\016\020\026\021\016\022\026\021\016\023\026\024\016\025\026\026\016\027\026\030\016\031\026\032\016\e\026\034\016\035\026\036\016\037\026 \016!\026\"\016#\026$À\207\023\b\220Õ\016\b€î$\b\220õ\231\b\002", stack_depth=3, constants_data=0x8681978) at bytecode.c:750 #20 0x8088575 in Fbyte_code (instructions=141406348, constants=141039976, stack_depth=7) at bytecode.c:2398 #21 0x80a6016 in Feval (form=140932320) at eval.c:2986 #22 0x80a32a8 in Fprogn (args=140931888) at eval.c:761 #23 0x80a91dc in unbind_to_hairy (count=0) at eval.c:4625 #24 0x80a9157 in unbind_to (count=0, value=136872380) at eval.c:4600 #25 0x80a3d98 in Fthrow (tag=136947116, val=136872380) at eval.c:1378 #26 0x80a68af in Ffuncall (nargs=3, args=0xbfffed48) at eval.c:3189 #27 0x8085d38 in execute_optimized_program (program=0x81b0fa8 "ÀÁÂ\"\207", stack_depth=3, constants_data=0x81b0f88) at bytecode.c:750 #28 0x808576c in funcall_compiled_function (fun=135991120, nargs=0, args=0xbfffee6c) at bytecode.c:527 ----------------------------------------------------------------------------- Lisp backtrace follows: Fatal error: assertion failed, file eval.c, line 1872, abort()

1 participants
0 comments

Re: XEmacs and its multiuser roots (was Re: change \C-m binding to newline-and-indent) 25 years, 7 months

Darron Shaffer

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "HS" == Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: > > >>>>"sb" == SL Baur schrieb am 06 Apr 1999 03:59:30 -0700: > > sb> The XEmacs user base has changed dramatically over the last > sb> three years in favor of systems that are typically > sb> single-user. > > HS> How do you know ? > > I'm sure that Steve meant that the majority of users do so on > single-user systems, as you interpret his statement. Of course that's > open to question. But I think that you cannot question that the trend > is toward single-user installations, even if they do not dominate yet. > (snip) > > The Win95 port introduces an interesting new problem, since > most users have write privileges on the system directories. Is that > really such a problem? Win95 (and WinNT for that matter in my limited > experience) are basically single-user systems. If you go to the > trouble making NT into a true multi-user system, then presumably you > protect the system directories from J. R. Ewser; ditto shared volumes > containing system software. Sysadmins who care and have the smarts to > enforce it will use some such system. Then they can take care of > J. R. Powawoozer who installs his own packages using the strategies > above. Turning WinNT into a true multi-user system is quite difficult. Many issues have not yet been cleaned up. For instance, does XEmacs cass either tmpname() or tmpfile()? The standard VC++ library provides versions of these routines that put your temporary files in the *root* directory of the *current* drive -- with no way to override this. A secure multi-user system will not give the average user write permissions on C:\. Darron Shaffer

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Jan Vroonhof

Enrico Scholz <enrico.scholz(a)wirtschaft.tu-chemnitz.de> writes: > lseek(12, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) > read(12, "", > [.... now it stops ....] For some reason it is not generating a signal for input on the X device. Maybe something subtle changed here. (We need straces from opening the X device and/or the setting of the signal handlers). Jan (p.s. who is definately NOT an expert here)

1 participants
0 comments

Re: strange insertion in the mail headers 25 years, 7 months

Didier Verna

Colin Rafferty <craffert(a)ms.com> writes: > Didier Verna writes: > > > I received 2 different mails from David Funk <david(a)jna.com.au> with > > some strange stuff in the headers field as displayed by Gnus. > > > Didn't we have a similar problem a while ago ? I think David's MTA is more > > likely to mess up with the message and add this piece of text by itself. > > I think that the problem is with the xemacs.org MTA. When the very > first line of the message is indented, then xemacs.org thinks it is a > continuation of the last header. That's it! I remember it now. But still, I think David's MTA adds the Mime paragraph that we get under the X-Mailing-List: header. > I have put a line at the beginning of my message that should be mashed > into the headers. very likely. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: strange insertion in the mail headers 25 years, 7 months

Colin Rafferty

Tor Arntsen writes: > On Apr 6, 20:07, Colin Rafferty wrote: >> User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) XEmacs/21.0(beta67) (20 minutes to Nikko) >> Sender: owner-xemacs-beta(a)xemacs.org >> X-Mailing-List: <xemacs-beta(a)xemacs.org> >> Hello Didier, this should be in the header. > It did end up in the heaader.. it should have been a blank line in between > there, right? You bet! The problem is certainly on xemacs.org's side. -- Colin

2 participants
1 comments

Re: XEmacs and its multiuser roots (was Re: change \C-m binding to newline-and-indent) 25 years, 7 months

Holger Schauer

>>>>"sb" == SL Baur schrieb am 06 Apr 1999 03:59:30 -0700: >> IMHO, this would be another case that shows that XEmacs is >> starting to forget its multi-user roots [1]. sb> Is this such a problem? It may become a problem if/when there were decisions made that make it difficult to easily support multi-user systems (in terms of administration). sb> The XEmacs user base has changed dramatically over the last three sb> years in favor of systems that are typically single-user. How do you know ? Over the last seven years I have been using XEmacs mainly in multi-user environments (apart from my home-based linux-box). On each of these there was a single maintainer handling the Emacs installation, with a _lot_ of users you never even noticed, until you heard somebody calling for a third hand and foot-pedals ;-) Typically you will never ever hear from a lot of Emacs users in the newsgroups. [packages should be installed by sysadmins] sb> Users have always been encouraged to install their own lisp. That is something that gives any sysadmin the headaches. I have been bitten much to often by having old packages lying around, breaking new clean installs (mailcrypt, VM and bbdb, anybody ?). What you say is certainly true for private additions and configurations - but it is a very different story, if all users keep their own "newest version of package xy, since that bloddy sysad never installs it" - and the sysadmin in fact is only one day late or has good reason not to install a package. Note that I'm not asking to disable the package-system or to discourage its use. I'm just pointing out that seen from a Unix point-of-view packages may pose a problem (let the user use, let the admin administrate). sb> Anyway, granting that "XEmacs is forgotting its multi-user roots" sb> whether or not this is in fact the case, my question is "What sb> difference does it make?" This is not a flame. Well, from what I've heard over the years, there always have been the kind of administrators that said "XEmacs, oh no, that's just to big, I won't install it". Maybe "forgetting its multi-user roots" can give those folks a whole new bunch of arguments (again: I'm not saying that it currently does, I'm just pointing out that we should try to avoid those arguments in the first place). Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "While it may look like it at a casual glance, XEmacs does not link against every library in Known Space." -- SL Baur on xemacs-beta

2 participants
1 comments

Problem with fonts under NT 25 years, 7 months

David Funk

Hi. I am using Xemacs 21.0.67 under NT, and had a problem using my favourite fonts (e.g. the 6x13 font that comes with Reflection X). I traced this to 2 problems in objects-msw.c: 1. font_enum_callback_2() contains this code: 978 for (i=0; i<countof (charset_map); i++) 979 if (lpelfe->elfLogFont.lfCharSet == charset_map[i].value) 980 { 981 strcat (fontname, charset_map[i].name); 982 break; 983 } 984 if (i==countof (charset_map)) 985 strcpy (fontname, charset_map[0].name); The intention of line 985 seems to be to select the default charset (the first in charset_map) for the font. I think line 985 should be: 985 strcat (fontname, charset_map[0].name); i.e. it should add the default charset to the end of the font name, as per line 981. 2. The default charset - i.e. the first in charset_map - is "Western", which maps to a logfont.lfCharSet of ANSI_CHARSET. Thus, if I use a font like 6x13 that doesn't have a matching lfCharSet in charset_map, it gets a default charset of "Western". Later, when mswindows_initialize_font_instance() looks up the "Western" in charset_map, it sets lfCharSet of ANSI_CHARSET. The result is that NT looks for the 6x13 font in the ANSI charset, and can't find it. If, however, you use lfCharSet = DEFAULT_CHARSET, NT looks in all charsets, and finds it. To fix this, I changed charset_map from this: 754 static CONST fontmap_t charset_map[] = 755 { 756 {"Western" , ANSI_CHARSET}, 757 {"Symbol" , SYMBOL_CHARSET}, etc to this: 754 static CONST fontmap_t charset_map[] = 755 { 756 {"Default" , DEFAULT_CHARSET}, 757 {"Western" , ANSI_CHARSET}, 758 {"Symbol" , SYMBOL_CHARSET}, etc Now, when a font has a charset that is not in the map, it gets lfCharSet = DEFAULT_CHARSET, and the font works. Note that you don't have to use "Default" as the string. An empty string would be just as good. I chose "Default" as it maps to "DEFAULT_CHARSET". This is consistent with most other entries. Having made these 2 changes, my favourite fonts now work. Also, fyi: I had a problem where the NT make would keep repeating forever. When I first ran it, it created src/puresize-adjust.h by copying it from nt/puresize-adjust.h. It then adjusted puresize-adjust.h and restarted the make. But the next make ran the puresize-adjust.h rule again, thereby wiping out the modified file, and thereby causing another make restart. This went on forever. I traced this to the fact than when I untar'd the source, the files had a timestamp of 1/1/1970. The modified puresize-adjust.h had a time in 1999, but there seems to be a bug in NT and/or nmake which made it think that 1999 was before 1970. If I touched nt/puresize-adjust.h before doing the make, it all worked fine. (Similarly, giving tar the 'm' flag when extracting the files also solved the problem.) Many thanks for your work with xemacs. I hope this report is useful. Regards, David Funk

3 participants
5 comments

cc-mode problem... 25 years, 7 months

Eric Knudstrup

I am running XEmacs 21.2 under Windows NT, and it seems like every time I open a new C file it resets c-basic-offset. This is version 5.25 of CC Mode. Is there something I'm probably doing wrong? TIA, Eric

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Enrico Scholz

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Enrico Scholz <enrico.scholz(a)wirtschaft.tu-chemnitz.de> writes: > > > > > Is this a documented behaviour or just a bug? > > It is a bug. Probably some weird configure failure or glibc 2.1 > changed the signal semantics again. Does config.h look reasonable? > > (At first I thought it might be the new vfork() stuff in the 2.2 > kernels but Fcall_process_internal uses a normal fork.) No, the normal fork() will be used. I have done some analysis, but can not provide a patch: 1. The problems occurs in the X11-mode only. Under "xemacs -nw" "call-process" works like expected. 2. The backtrace is -------------------------------- #0 0x40491ef4 in __libc_read () #1 0x8647b50 in ?? () #2 0x80d5af3 in read_allowing_quit (fildes=13, buf=0x8647b78, size=512) at fileio.c:293 #3 0x8120f1a in filedesc_reader (stream=0x8647b08, data=0x8647b78 "h¯M＠h¯M＠", size=512) at lstream.c:931 #4 0x81202e0 in Lstream_raw_read (lstr=0x8647b08, buffer=0x8647b78 "h¯M＠h¯M＠", size=512) at lstream.c:509 #5 0x8120399 in Lstream_read_more (lstr=0x8647b08) at lstream.c:527 #6 0x81204f5 in Lstream_read (lstr=0x8647b08, data=0xbfffb000, size=16384) at lstream.c:571 #7 0x806918a in Fcall_process_internal (nargs=5, args=0xbffff15c) at callproc.c:453 #8 0x808f6e6 in Ffuncall (nargs=6, args=0xbffff158) at eval.c:3206 -------------------------------- 3. libc_read(), called by sys_read_1() in sysdep.c (the #1 above), gets in the console-mode a SIGINT signal but in the X11-mode not. strace says under X11: .... access("/bin/sleep", X_OK) = 0 open("/dev/null", O_RDONLY) = 11 pipe([12, 13]) = 0 fork() = 567 close(13) = 0 close(11) = 0 close(13) = -1 EBADF (Bad file descriptor) lseek(12, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) read(12, "", [.... now it stops ....] 512) --- SIGCHLD (Der Kind-Prozeß ist beendet) --- and at the console: .... access("/bin/sleep", X_OK) = 0 open("/dev/null", O_RDONLY) = 10 pipe([11, 12]) = 0 fork() = 627 close(12) = 0 close(10) = 0 close(12) = -1 EBADF (Bad file descriptor) lseek(11, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) read(11, 0x850c960, 512) = ? ERESTARTSYS (To be restarted) --- SIGINT (Unterbrechung) --- write(9, "\0", 1) = 1 sigreturn() = ? (mask now []) kill(-627, SIGINT) = 0 write(1, "\33[37;1HWaiting for process to "..., 82) = 82 wait4(627, [WIFSIGNALED(s) && WTERMSIG(s) == SIGINT], 0, NULL) = 627 --- SIGCHLD (Der Kind-Prozeß ist beendet) --- 4. The console-xemacs calls a lot of ioctl's setting the SIGINT character. This calls are missing under X11 naturally. I am not very familiarly with the internal xemacs structures and process-flows, but I hope this mail helps a little bit. Enrico -- eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de talk: ensc(a)ultra.csn.tu-chemnitz.de

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