December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Jareth Hein

I will be gone from the 19th of December till the 5th of January. If you need to get a hold of me (like "Aaugh! The CVS tree's in flames!" <grin>), please send me mail to jhod(a)gol.com (I can read that from the states...) Season's greetings to you all. -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

21.0-b60 missing tm files 27 years

Raymond Toy

I just noticed that 21.0-b60 is missing the tm files like tm-au, tm-file, tm-html, etc. They existed in b57 but not in b59 or b60. Are they found somewhere else now? Ray

2 participants
1 comments

Re: 21.0-b60 missing tm files 27 years

Christoph Wedler

>>>>>"RT" == Raymond Toy <toy(a)rtp.ericsson.se> writes: RT> I just noticed that 21.0-b60 is missing the tm files like tm-au, RT> tm-file, tm-html, etc. RT> They existed in b57 but not in b59 or b60. RT> Are they found somewhere else now? In the tm package, i.e., lib/xemacs/xemacs-packages/lib-src after having installed the newest tm package. - Christoph

1 participants
0 comments

xemacs-fag.info (What is the status of Asian-language support...) 27 years

Kenichi Handa

Dear Sirs, I'm a member of Mule developing team. I found this paragraph in emacs-faq.info (XEmacs 20.4). ------------------------------------------------------------ As the fundings on Mule have stopped, Mule part of XEmacs is currently looking for a full-time maintainer. If you can provide help here, or are willing to fund the work, please mail to <xemacs-beta(a)xemacs.org>. ------------------------------------------------------------ But, "the fundings on Mule have stopped" is very misleading. Our project is still funded well, and keep active work while cooperating with FSF (and Mr. Stallman). Now "Mule" stands for Multilingual Environment on Emacs. Could you please correct the statement so that People don't think that the mainstream development of Mule is also stopped? --- Ken'ichi HANDA handa(a)etl.go.jp

1 participants
0 comments

[Failure] 21.0.60 on FreeBSD 2.2.7 27 years

Yuichi Yoda

Built from fresh tarballs and SUMO(xemacs-sumo-1998-12-09.tar.gz) but while building I got Segmentation fault as follows: gcc -O3 -g -Wall -Wno-switch -fno-caller-saves -L/usr/local/lib -Xlinker -R/usr/local/lib:/usr/X11R6/lib -L/usr/X11R6/lib -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 unexfreebsd.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o gui.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o mule-coding.o file-coding.o input-method-xlib.o mule-wnnfns.o mule-canna.o realpath.o inline.o linuxplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o tparam.o event-unixoid.o database.o sysdll.o dll.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 getloadavg.o glyphs.o glyphs-eimage.o hash.o imgproc.o indent.o insdel.o in! tl! .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 pure.o rangetab.o redisplay.o redisplay-output.o regex.o search.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o xgccache.o xselect.o widget.o window.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 -lXm -lcanna -lRKC -lwnn -lcompface -ltiff -lpng -ljpeg -lz -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ltermcap -lcrypt -lkvm -lm -lutil -lxpg4 EMACSBOOTSTRAPLOADPATH="/local/src/tmp/xemacs-21.0.60/src/../lisp/:/local/src/tmp/xemacs-21.0.60" ./temacs -batch -l /local/src/tmp/xemacs-21.0.60/src/../lisp/update-elc.el Segmentation fault - core dumped gmake[1]: *** [update-elc.stamp] Error 139 gmake[1]: Leaving directory `/local/src/tmp/xemacs-21.0.60/src' gmake: *** [src] Error 2 faith: {29} gdb ./temacs temacs.core GDB is free software and you are welcome to 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. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... Core was generated by `temacs'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x20263080. #0 0x187de7 in intern (str=0x68005c3b <Address 0x68005c3b out of bounds>) at symbols.c:154 154 Bytecount len = strlen (str); (gdb) bt #0 0x187de7 in intern (str=0x68005c3b <Address 0x68005c3b out of bounds>) at symbols.c:154 #1 0x18e284 in defsubr (subr=0x250fbc) at symbols.c:3221 #2 0x2a38 in syms_of_abbrev () at abbrev.c:407 #3 0x4cfff in xemacs_21_0_b60_i386_unknown_freebsd2_2_7 (argc=4, argv=0xefbfd604, envp=0xefbfd618, restart=0) at emacs.c:865 #4 0x4e067 in main (argc=4, argv=0xefbfd604, envp=0xefbfd618) at emacs.c:2060 (gdb) Is there anyone can help me? Thank you, // Yuichi Yoda

3 participants
5 comments

Package Installation Breakage? 27 years

Adrian Aichner

Hello All! Lately I have noticed that Options->Manage Packages->List & Install installs packages in odd places. I have done "Update Package Index" from xemacs.org before installing. Here is my `late-package-load-path' (buffer: *Group*, mode: Group) Variable: value: see below Load path for packages late in the load path. value: ("C:\\PROGRA~1\\XEMACS\\xemacs-packages\\lisp\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\lisp\\Sun\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\lisp\\ada\\" <lines deleted by Adrian> "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\lisp\\zenirc\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\man\\lisp\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\man\\lisp\\pcl-cvs\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\man\\lisp\\text-modes\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\pgnus-0.66\\lisp\\" "c:\\PROGRA~1\\XEMACS\\xemacs-packages\\pgnus-0.66\\lisp\\misc-games\\") Any obvious mistake on my part? Adrian -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 27 years

Didier Verna

William M Perry writes: William> I'll take a look at it for 21.2 or whatever the major hacking is William> happening on as soon as the holidays settle down a little. Wait for the soon-to-come new autoconf release too. -- / / _ _ 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: [CRASH] 21.2-b5 with Jonathan's gc crash fix applied 27 years

Hrvoje Niksic

Norbert Koch <n.koch(a)delta-ii.de> writes: > > I think the idea is to invoke the function immediately *before* > > the crash, not after it. If the crash is happening due to an > > assert or something like that, under Unix I'd put a breakpoint on > > assert_failed() and invoked debug_backtrace() from there. > > Dunno, perhaps a good idea would be to call the function before and > after the crash (perchance, there is an after :-). On Unix, you cannot do that. When the process SIGSEGV's and dies of it, you cannot call functions from the debugger (you can still examine the variable and stuff, but no function-calling.)

1 participants
0 comments

Re: [CRASH] 21.2-b5 with Jonathan's gc crash fix applied 27 years

Norbert Koch

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > > > >> I'm not sure I understand Jonathan's remark, but I guess he > > >> is thinking about the callstack, you can display in MS VC++. > > > > Hrvoje> No, I think debug_backtrace() is the C function that > > Hrvoje> spits out the Lisp backtrace. You get it by calling > > Hrvoje> `debug_backtrace()' from your favorite debugger, and > > Hrvoje> capturing the resulting output. > > > > Yep, Hrvoje, I found it in src\print.c. Now I have to figure out > > how to call it from within MickeySoft Developer Studio invoked upon > > the crash. > > > > I would be tahnkful for any advice. > > I think the idea is to invoke the function immediately *before* the > crash, not after it. If the crash is happening due to an assert or > something like that, under Unix I'd put a breakpoint on > assert_failed() and invoked debug_backtrace() from there. > Dunno, perhaps a good idea would be to call the function before and after the crash (perchance, there is an after :-). This way, you can check for any differences and gain information out of them. -- It's OBVIOUS.. The FURS never reached ISTANBUL.. You were an EXTRA in the REMAKE of ``TOPKAPI''.. Go home to your WIFE.. She's making FRENCH TOAST!

1 participants
0 comments

Re: XEmacs' autoconf weirdness (was Re: Spurious "file has changed on disk" warnings on Linux) 27 years

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Martin Buchholz <martin(a)xemacs.org> writes: > > > > > >>>>> "Bill" == William M Perry <wmperry(a)aventail.com> writes: > > > > > > Bill> But libtool will eventually migrate to being able to fully support > > > Bill> dlopen'able modules, so this could be used as the basis for some of the > > > Bill> module support. I know jean is working on getting libtool to work on sco > > > Bill> from some of the messages on the mailing list. :) > > > > > > Maybe in that case we should wait for libtool dlopen support before > > > libtoolizing XEmacs. > > > > libtool'izing XEmacs would be a separate task. We'd have to > > libtool'ize the modules as well, which is what would have to wait. > > Everybody: WHAT modules? The unwritten generations deserve a voice too! :) > The modules/ directory mostly contains very very obsolete versions of > pieces of XEmacs code. eldap.c is totally outdated. base64.c contains > code that appears to be based on an old version of Fmd5() from md5.c -- I > recognize it by having an enormous and needless number of streams for > conversion. I've reported this before, but to no avail (md5.c contains > code that shows how it should be done.) > > Also, someone [sorry, I can't recall the name] is working on rethinking > and rewriting the dlopen support to be really useful; what we have at > this point should be thought of as an alpha version. I've been way too busy to update the modules, much less a life lately. :( That's going to change though, or I'll get a new job. :) -Bill P.

1 participants
0 comments

2025

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 1998