August 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[crash] beep in readonly buffer, sigusr1 from libesd?? 24 years, 3 months

Karl M. Hegbloom

This didn't happen last week. I recently upgraded a bunch of stuff from Debian "Woody" using `apt-get'. My guess is that likely the ESD libs have been changed. I recompiled XEmacs after a fresh CVS update today, and it still happens. Touch a file, chown it read only, start xemacs -vanilla, evaluate `(load-default-sounds)', then type in the read only buffer. Probably only does it on Linux with ESD; perhaps only on current Debian "Woody"? I lack the skills and time to track this down. I really need to spend the day working on my math assignment, sorry. I will give a trusted individual a SSH login to test this XEmacs binary and setup with. Drop me a note. I won't recompile until then. I'll just be careful to save often, etc. (I have to get back to my math then go for a run.) bittersweet% ldd =xemacs libXaw3d.so.6 => /usr/X11R6/lib/libXaw3d.so.6 (0x4001f000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40072000) libpng.so.2 => /usr/lib/libpng.so.2 (0x400b4000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400db000) libz.so.1 => /usr/lib/libz.so.1 (0x400fc000) libcompface.so.1 => /usr/lib/libcompface.so.1 (0x4010b000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40116000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40124000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40136000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4017e000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4018b000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4022c000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40235000) libdl.so.2 => /lib/libdl.so.2 (0x4024b000) libdb.so.3 => /lib/libdb.so.3 (0x4024f000) libgpm.so.1 => /usr/lib/libgpm.so.1 (0x4028a000) libncurses.so.5 => /lib/libncurses.so.5 (0x40291000) libesd.so.0 => /usr/lib/libesd.so.0 (0x402cf000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402d7000) libm.so.6 => /lib/libm.so.6 (0x402ea000) libpq.so.2.1 => /usr/lib/libpq.so.2.1 (0x40307000) libopenldap.so.1 => /usr/lib/libopenldap.so.1 (0x40318000) liblber-openldap.so.1 => /usr/lib/liblber-openldap.so.1 (0x4032e000) libc.so.6 => /lib/libc.so.6 (0x40333000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libasound.so.1 => /usr/lib/libasound.so.1 (0x40410000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40427000) bittersweet% dpkg --search libesd.so.0 libesd-alsa0: /usr/lib/libesd.so.0.2.19 libesd-alsa0: /usr/lib/libesd.so.0 bittersweet% dpkg --status libesd-alsa0 Package: libesd-alsa0 Status: install ok installed Priority: optional Section: libs Installed-Size: 68 Maintainer: Ryan Murray <rmurray(a)debian.org> Source: esound Version: 0.2.19-1 Provides: libesd0 Depends: libasound1 (>= 0.5.5), libaudiofile0, libc6 (>= 2.1.2), esound-common Suggests: esound-alsa Conflicts: libesd0 Description: Enlightened Sound Daemon (ALSA) - Shared libraries This program is designed to mix together several digitized audio streams for playback by a single device. bittersweet% uname -a: Linux bittersweet 2.4.0-test1-ac10 #2 Fri Jun 9 18:11:30 PDT 2000 i586 unknown ../xemacs/configure '--cflags=-mcpu=k6 -march=k6 -ggdb -O3' '--with-database=berkdb' '--with-athena=3d' '--with-widgets=athena' '--with-dialogs=athena' '--with-scrollbars=lucid' '--with-menubars=lucid' '--with-sound=esd,native' '--with-modules' '--package-path=/usr/local/src/PKG/unstable/main/xemacs/run-in-place/../Packages' '--infopath=/usr/share/info:/usr/local/share/info:/usr/info:/usr/local/info' '--with-mule' '--with-canna=no' '--with-wnn=no' '--debug=yes' '--error-checking=all' 'i686-bittersweet-linux' XEmacs 21.2-b35 "Nike" configured for `i686-bittersweet-linux'. Compilation / Installation: Source code location: /usr/local/src/PKG/woody/main/xemacs/xemacs Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -mcpu=k6 -march=k6 -ggdb -O3 Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. 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. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena 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. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: pgsql/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 raw Xlib to provide XIM support. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: ---------------------------------------------------------

1 participants
0 comments

Two questions re. PSGML validation issues 24 years, 3 months

Adrian Aichner

Hello Jerry! While implementing HTML document validation for our next-generation XEmacs website I have some questions about PSGML: 1. How can I access the DTD doctype of buffer after validating it (i.e. it has been parsed and all information should be available via sgml-dtd-info)? I have verified that sgml-dtd-info contains correct information after calling (sgml-parse-prolog) along the way. 2. How can I access the error message reported by (sgml-next-trouble-spot)? I tried using (if sgml-last-element (setq context (sgml-element-context-string sgml-last-element))) but sgml-last-element is nil even though an error occured. To be honest, it worked in a debugging session of XEmacs, but not in a freshly started one. I'd appreciate any help. Best regards, Adrian -- Adrian Aichner <adrian(a)xemacs.org>

1 participants
0 comments

A New Package 24 years, 3 months

Steve Youngs

I have a new package that I want to put into the XEmacs package system but I've come across a possible stumbling block. My package, which is an ICQ client for XEmacs, needs an external binary program to run. The external binary is a UDP to TCP bridge. Unfortunately, at the moment it will only run on Linux (x86)[1]. See the dilemma? These are the possible solutions that I've thought of... (1) include the package as is but clearly mark it "For Linux Only" (a temporary solution only) (2) remove the external binary from the package and make people download and install the external binary separately (similar to how Gnus uses sendmail)[2] (3) re-write the external binary as an 'emodule' There are bound to be pro's and con's for each of those 3 solutions and probably other solutions that I haven't thought of. That's where you come in. What are your thoughts, ideas, comments? Oh, and before you say "Andreas handles packages, ask him", it was Andreas who suggested I discuss it here. :) If you want to take a look at it... <http://users.ozlinx.com.au/~youngs_s/eicq/> Footnotes: [1] because that's what my system is and I don't have what's needed to port it to other platforms. [2] if this is the way I go I'll need some help in porting the external binary to other platforms. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---| | It's a funny thing about life; if you refuse to accept | | anything but the best, you very often get it | |-----------------------------<mailto:youngs_s＠ozlinx.com.au>---|

2 participants
1 comments

Re: A New Package 24 years, 3 months

Daniel Pittman

On 12 Aug 2000, Steve Youngs <youngs_s(a)ozlinx.com.au> wrote: [...] > My package, which is an ICQ client for XEmacs, needs an external > binary program to run. The external binary is a UDP to TCP bridge. > Unfortunately, at the moment it will only run on Linux (x86)[1]. *blink* Er, this may seem like a silly suggestion, but... have you considered adding the needed UDP support to xemacs, rather than using the external binary? Daniel -- Fortune rarely accompanies anyone to the door. -- Balthasar Gracian

1 participants
0 comments

Re: 21.2.24 Crashes! 24 years, 3 months

Gunnar Evermann

Shenghuo ZHU <zsh(a)cs.rochester.edu> writes: > When I run this code (a simplified version), XEmacs crashes. The > problem is the text property. > > (defun test-decode (word) > (let ((i -1) (s (substring word 0)) v) > (while (< (incf i) (length s)) > (if (eq (setq v (aref s i)) ? ) nil > (aset s i (+ 128 v)))) > s)) > > (let ((s "~{<:Ky2;S{#,NpJ)l6HK!#~}")) > (put-text-property 0 (length s) 'face 'bold s) > (setq s (test-decode s)) > (decode-coding-string s 'cn-gb-2312)) A simple test case for this is: (let ((s "ab")) (put-text-property 0 (length s) 'face 'bold s) (aset s 0 128) s) what happens is this: - set_string_char() is called to set the first character. - The new char needs two bytes, therefore resize_string ( pos=0, delta=1) is called. - in resize_string() space is made and the string length is set to 3 - adjust_extents(from=-1, to=3, amount=1) is called - since extents use memind's the starting point of the extent is adjusted from 0 to 1. Now it points into the middle of the character, resulting in the crash later on. I think the semantics of resize_string are slightly under-specified: /* Resize the string S so that DELTA bytes can be inserted starting at POS. [...] */ It is not clear whether we insert new characters or just need more space for the existing character. In the former case we need to adjust extents with start=pos in the latter we mustn't. resize_string also has problems if the string is shrunk as extents might have endpoints to the right of the new string end and therefore won't get adjusted. Any suggestions? Gunnar

2 participants
1 comments

[RFC] xemacsweb/News vs. xemacsweb/Release 24 years, 3 months

Adrian Aichner

Hi All! I am in the process of adding some information about recent releases to the xemacsweb module. One thing I am not clear on at all if the overall design of what should go into the News vs. the Release sub directory. There is some replication between the two. None is easily accessible from the homepage. I'd suggest to add "Release" under the "Getting XEmacs" header in xemacsweb/template.html. This will make it accessible from anywhere on the site. Furthermore, since "News" is a very relative thing, I propose to discontinue that directory (or at least not add to it further) and instead just keep adding short bits to the top of xemacsweb/index.content under "XEmacs Community News" (e.g. links to details in the Release directory). How does that sound? Have I missed any major points in the overall site layout? I'll commit some patches along above lines. Please let me know your objections. I'm perfectly OK to change things again towards more consistency and simplicity. Best regards, Adrian -- Adrian Aichner <adrian(a)xemacs.org>

1 participants
0 comments

pdump and command line flags 24 years, 3 months

Gunnar Evermann

I don't know whether this is a know problem. In a pdump xemacs command line flags like '-debug_paths' don't work. If '-debug-paths' is present on the command line then the C variable debug_paths is set to 1. To make it accessible to lisp it is DEFVAR_BOOL'd, alas this also means it is dumped and thus restored when the dump file is loaded. A similar problems exists for '-no-early-packages' and '-no-autoloads'. Gunnar

1 participants
0 comments

make Extbyte be signed 24 years, 3 months

Ben Wing

Martin and I are [for once] in complete agreement that Extbyte should be just `char', not `unsigned char'. [Technically, just plain `char' could be unsigned, but whatever.] The reason for this is that it greatly simplifies dealing with library functions, which invariably declare their strings as `char'. In fact, this is the primary reason, I think, why we suppress many warnings about signed/unsigned matches. [though i may be confused here] I was very surprised, in fact, to find that Extbyte was unsigned char, and was sure that I had originally made it char, but I was mistaken. I imagine that I did it because chars are inherently dangerous to work with -- as was demonstrated clearly when I just made the change and rebuilt a Mule version, and got crashes. In fact, there were two bugs needed fixing, and in both cases GCC actually flagged them with a warning like "comparison is always true due to limited range of type". In both cases, the code itself was buggy; one had an Extbyte where it should have had Bufbyte, and the other was breaking the cardinal rule of format translation -- always do the translation at the very point you send data to the external library [or receive data from it], and never ever do any operations on the data in the external format. Assume black box. This second spot violated this, and the result was buggy code, which would have failed badly, e.g., if the externally-formatted code were JIS, which is used on some systems [esp. but not exclusively window systems]. When I fixed these two spots, I got a Mule that worked perfectly. So, I'd like to make Extbyte be signed. This is actually an extremely small patch, but with potentially big ramifications, so I'd like to do it after Martin puts out his next beta. [Martin???] The summary is: -- makes code that deals with the outside world cleaner due to lack of lots of now-unnecessary casts. -- we can enable full warning again. -- forces discipline on those who may tend to break the cardinal rule above about internal/external translation. -- sources of errors relating to the signed-ness [related to the previous point] are generally flagged in gcc. what do you guys think? i'm planning on putting this in shortly after Martin releases his next beta, barring major objections. Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/

3 participants
3 comments

what happened to update-elc.sh? 24 years, 3 months

Stephen J. Turnbull

And when? There's no ChangeLog! Disappearing files surely deserve a ChangeLog! -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
1 comments

21.2.35 crash on solaris 24 years, 3 months

Raymond Toy

I think I pressed C-x C-o to switch to another buffer when xemacs crashed. It printed out: Fatal error: assertion failed, file alloc.c, line 2487, GCLI_lh->type < lrecord_type_count but no lisp backtrace. The C backtrace is appended below. Ray #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa9924 in fatal_error_signal (sig=6) at emacs.c:514 #2 <signal handler called> #3 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #4 0xfeab92a4 in abort () from /usr/lib/libc.so.1 #5 0xac9f4 in assert_failed (file=0x9b7 <Address 0x9b7 out of bounds>, line=2503608, expr=0x2633b8 "GCLI_lh->type < lrecord_type_count") at emacs.c:3118 #6 0x6a778 in mark_object (obj=-4274976) at alloc.c:2487 #7 0x6c350 in garbage_collect_1 () at alloc.c:3459 #8 0xb4038 in Ffuncall (nargs=1, args=0xffbeb51c) at eval.c:3163 #9 0x7bc6c in execute_optimized_program (program=0xffbeb51c "", stack_depth=1, constants_data=0x82e710) at bytecode.c:745 #10 0x7b49c in funcall_compiled_function (fun=8392988, nargs=2, args=0xffbeb780) at bytecode.c:517 #11 0xb43e4 in Ffuncall (nargs=2, args=0xffbeb774) at eval.c:3249 #12 0x7bc6c in execute_optimized_program (program=0xffbeb774 "", stack_depth=2, constants_data=0x836710) at bytecode.c:745 #13 0x7b49c in funcall_compiled_function (fun=4046948, nargs=3, args=0xffbeb9d8) at bytecode.c:517 #14 0xb43e4 in Ffuncall (nargs=3, args=0xffbeb9d0) at eval.c:3249 #15 0xb54dc in call3 (fn=8464604, arg0=3358668, arg1=6458084, arg2=3246084) at eval.c:3898 #16 0x12b054 in Fexpand_file_name (name=6458084, default_directory=3246084) at fileio.c:767 #17 0xb4218 in Ffuncall (nargs=2, args=0xffbebba8) at eval.c:3214 #18 0xb4b00 in Fapply (nargs=2, args=0xffbebd50) at eval.c:3486 #19 0xb4398 in Ffuncall (nargs=2, args=0xffbebd4c) at eval.c:3235 #20 0x7bc6c in execute_optimized_program (program=0xffbebd4c "", stack_depth=2, constants_data=0x836610) at bytecode.c:745 #21 0x7b49c in funcall_compiled_function (fun=4046948, nargs=3, args=0xffbebfb0) at bytecode.c:517 #22 0xb43e4 in Ffuncall (nargs=3, args=0xffbebfa8) at eval.c:3249 #23 0xb54dc in call3 (fn=8464796, arg0=3358668, arg1=6458084, arg2=3246084) at eval.c:3898 #24 0x12b054 in Fexpand_file_name (name=6458084, default_directory=3246084) at fileio.c:767 #25 0xc373c in lock_file (fn=6458084) at filelock.c:316 #26 0x12fd94 in Fwrite_region_internal (start=3, end=8191, filename=8003412, append=3246084, visit=3246108, lockname=6458084, codesys=5630720) at fileio.c:3192 #27 0xb42bc in Ffuncall (nargs=7, args=0xffbec434) at eval.c:3214 #28 0x7bc6c in execute_optimized_program (program=0xffbec434 "", stack_depth=7, constants_data=0x55e410) at bytecode.c:745 #29 0x7b49c in funcall_compiled_function (fun=5605348, nargs=7, args=0xffbec6c0) at bytecode.c:517 #30 0xb43e4 in Ffuncall (nargs=7, args=0xffbec6a0) at eval.c:3249 #31 0xb4b00 in Fapply (nargs=2, args=0xffbec860) at eval.c:3486 #32 0xb4398 in Ffuncall (nargs=2, args=0xffbec85c) at eval.c:3235 #33 0x7bc6c in execute_optimized_program (program=0xffbec85c "", stack_depth=2, constants_data=0x836710) at bytecode.c:745 #34 0x7b49c in funcall_compiled_function (fun=4046948, nargs=8, args=0xffbecac0) at bytecode.c:517 #35 0xb43e4 in Ffuncall (nargs=8, args=0xffbecab8) at eval.c:3249 #36 0xb56b0 in call8 (fn=8464604, arg0=3361372, arg1=3, arg2=8191, arg3=8003412, arg4=3246084, arg5=3246108, arg6=6458084, arg7=5630720) at eval.c:4002 #37 0x12fa44 in Fwrite_region_internal (start=3, end=8191, filename=8003412, append=3246084, visit=3246108, lockname=6458084, codesys=5630720) at fileio.c:3171 #38 0xb42bc in Ffuncall (nargs=7, args=0xffbece1c) at eval.c:3214 #39 0x7bc6c in execute_optimized_program (program=0xffbece1c "", stack_depth=7, constants_data=0x55e410) at bytecode.c:745 #40 0x7b49c in funcall_compiled_function (fun=5605348, nargs=7, args=0xffbed0a8) at bytecode.c:517 #41 0xb43e4 in Ffuncall (nargs=7, args=0xffbed088) at eval.c:3249 #42 0xb4b00 in Fapply (nargs=2, args=0xffbed248) at eval.c:3486 #43 0xb4398 in Ffuncall (nargs=2, args=0xffbed244) at eval.c:3235 #44 0x7bc6c in execute_optimized_program (program=0xffbed244 "", stack_depth=2, constants_data=0x836610) at bytecode.c:745 #45 0x7b49c in funcall_compiled_function (fun=4046948, nargs=8, args=0xffbed4a8) at bytecode.c:517 #46 0xb43e4 in Ffuncall (nargs=8, args=0xffbed4a0) at eval.c:3249 #47 0xb56b0 in call8 (fn=8464796, arg0=3361372, arg1=3, arg2=8191, arg3=8003412, arg4=3246084, arg5=3246108, arg6=6458084, arg7=5630720) at eval.c:4002 #48 0x12fa44 in Fwrite_region_internal (start=3, end=8191, filename=8003412, append=3246084, visit=3246108, lockname=6458084, codesys=5630720) at fileio.c:3171 #49 0xb42bc in Ffuncall (nargs=7, args=0xffbed804) at eval.c:3214 #50 0x7bc6c in execute_optimized_program (program=0xffbed804 "", stack_depth=7, constants_data=0x55e410) at bytecode.c:745 #51 0x7b49c in funcall_compiled_function (fun=5605348, nargs=6, args=0xffbeda90) at bytecode.c:517 #52 0xb43e4 in Ffuncall (nargs=6, args=0xffbeda74) at eval.c:3249 #53 0x7bc6c in execute_optimized_program (program=0xffbeda74 "", stack_depth=6, constants_data=0x4f92d0) at bytecode.c:745 #54 0x7b49c in funcall_compiled_function (fun=5261988, nargs=2, args=0xffbedce8) at bytecode.c:517 #55 0xb43e4 in Ffuncall (nargs=2, args=0xffbedcdc) at eval.c:3249 #56 0x7bc6c in execute_optimized_program (program=0xffbedcdc "", stack_depth=2, constants_data=0x4f8310) at bytecode.c:745 #57 0x7b49c in funcall_compiled_function (fun=5262072, nargs=0, args=0xffbedf48) at bytecode.c:517 #58 0xb43e4 in Ffuncall (nargs=0, args=0xffbedf44) at eval.c:3249 #59 0x7bc6c in execute_optimized_program (program=0xffbedf44 "", stack_depth=0, constants_data=0x4f8410) at bytecode.c:745 #60 0x7b49c in funcall_compiled_function (fun=5262044, nargs=0, args=0xffbee1b0) at bytecode.c:517 #61 0xb43e4 in Ffuncall (nargs=0, args=0xffbee1ac) at eval.c:3249 #62 0x7bc6c in execute_optimized_program (program=0xffbee1ac "", stack_depth=0, constants_data=0x500710) at bytecode.c:745 #63 0x7b49c in funcall_compiled_function (fun=5261932, nargs=1, args=0xffbee410) at bytecode.c:517 #64 0xb43e4 in Ffuncall (nargs=1, args=0xffbee408) at eval.c:3249 #65 0x82374 in Fcall_interactively (function=4920932, record_flag=3246084, keys=3246084) at callint.c:946 #66 0xb2b6c in Fcommand_execute (cmd=4920932, record=3246084, keys=3246084) at eval.c:2652 #67 0x10f450 in execute_command_event (command_builder=0x659680, event=7443828) at event-stream.c:3838 #68 0x10fea0 in Fdispatch_event (event=7443828) at event-stream.c:4157 #69 0x8c304 in Fcommand_loop_1 () at cmdloop.c:579 #70 0x8c044 in command_loop_1 (dummy=6618880) at cmdloop.c:494 #71 0xb00b4 in condition_case_1 (handlers=3246180, bfun=0x8bff8 <command_loop_1>, barg=3246084, hfun=0x8c4e4 <cmd_error>, harg=3246084) at eval.c:1640 #72 0x8c5f4 in command_loop_2 (dummy=3246084) at cmdloop.c:256 #73 0xafc24 in internal_catch (tag=3328196, func=0x8c5a8 <command_loop_2>, arg=3246084, threw=0x0) at eval.c:1306 #74 0x8b940 in initial_command_loop (load_me=574888) at cmdloop.c:305 #75 0xab64c in xemacs_21_2_b35_sparc_sun_solaris2_7 (argc=1, argv=0xffbeed74, envp=0xffbeed7c, restart=0) at emacs.c:2155 #76 0xabe70 in main (argc=1, argv=0xffbeed74, envp=0xffbeed7c) at emacs.c:2584

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