August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Michael Sperber

>>>>> "Robert" == Robert Pluim <rpluim(a)bigfoot.com> writes: Robert> Jan Vroonhof writes: >> Robert Pluim <rpluim(a)bigfoot.com> writes: >> >> > Here's a (possibly insane) suggestion: rather than dumping, why don't >> > we compile the lisp files to C? We could then make select portions >> > dynamically loadable, and remove all that unportable dumping code. >> >> This was Kyle's original plan. Robert> I thought Kyle's plan was to write out a C _representation_ of the Robert> parsed lisp, not to actually compile the lisp code to C? (I may be Robert> misremembering here). This also has serious drawbacks, namely that you'd have to create a giant data structure initializer. Most current C compilers seem to have at least quadratic run-time in the size of initializers, which will force you to chop up the heap data structure into a gazillion separate objects. Richard Kelsey and Brian Carlstrom did that once for Scheme 48. It works, but creating and compiling an image takes forever. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

No gutter visible under AIX / X11 25 years, 3 months

ALTMARK＠de.ibm.com

I've tested the gutter on XEmacs under NT (21.2-b19, which I got from ftp.ese-metz.fr/pub/xemacs/win32) and think it's really cool, so I wanted to have it also on the XEmacs running on my AIX (4.3.2) box (also 21.2-b19, which I built myself from the tarballs). Unfortunately *no* gutter at all is visible, although the "Visible" button under "Options->Gutter Apperarance" is on. (In addition to that, I don't see the function `buffers-tab-selection-function' on AIX, but it exists on NT.) Is this a known problem? Or no problem at all and I'm doing something wrong? (e.g. do I have to specify additional parameters with configure or something similar?) TIA for any hint! Markus --- Markus Alt IBM Laboratory Boeblingen, Germany

2 participants
1 comments

Re: xemacs udp patch 25 years, 3 months

Jan Vroonhof

Stephen Tse <stephent(a)sfu.ca> writes: > Should I send the package to xemacs-patch, or is package now truly > independently of xemacs such that I just have to upload to a certian > ftp area? The latter. When XEmacs 21.2 is released we can think about putting it in the official package list, but currently we cannot because the packages have to work with 21.1. Be sure to send the link to the ftp area to webmaster(a)xemacs.org Jan

1 participants
0 comments

Re: xemacs udp patch 25 years, 3 months

Stephen Tse

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: (I guess we should post followups in xemacs-beta.) > > If I know nothing about making packaging, can my send my library to > > somewhere and then someone nice will package it for me? > > I thought I already sent you a packaged version of eicq? Yes. I'll update it soon for internal udp support and encryption module. (I put encryption routine in external c module and use `load-module'.) Should I send the package to xemacs-patch, or is package now truly independently of xemacs such that I just have to upload to a certian ftp area? - stephen

1 participants
0 comments

Re: No gutter visible under AIX / X11 25 years, 3 months

Jan Vroonhof

ALTMARK(a)de.ibm.com writes: > Is this a known problem? Or no problem at all and I'm doing something > wrong? (e.g. do I have to specify additional parameters with configure or > something similar?) Maybe configure has decided that you cannot have widget support for some reason? Check the "Installation" file. Jan

1 participants
0 comments

Re: XEmacs doing its own C backtraces 25 years, 3 months

William M. Perry

Ulrich Drepper <drepper(a)cygnus.com> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > But does it work? :) I thought this would be nifty to use in our server, > > and I just tried it. I just threw in this code in the midst of it > > processing a connection: > > > > { > > void *array[250]; > > int n = backtrace(array,250); > > > > backtrace_symbols_fd(array,n,fileno(stderr)); > > } > > > > All I got was: > > > > [0x805d3f7] > > [0x805c21e] > > [0x805c994] > > [0x805c9fc] > > [0x805b40a] > > /lib/libc.so.6(__libc_start_main+0xeb)[0x401cfcb3] > > [0x8051ab1] > > Which is the correct information. Do you know how program loading works? > An ELF file has parts which are loaded and those which are not. And > debugging info is never loaded. Therefore the backtrace functions have > no access to the function names etc. > > But if you look at the catchsegv script coming with glibc 2.1 you'll > see how to get the missing informaiton. Ah, I did not know catchsegv existed... that looks much better. Thanks for the info. -Bill P.

1 participants
0 comments

Re: [Jan Vroonhof <vroonhof@math.ethz.ch>] Re: constantly crashing in Gnus 25 years, 3 months

Ulrich Drepper

Me again, I've applied the patch Jan sent me and this seems to work. I had no crash because of this problem. At least I think so since now I get a different crash. I'll sent a report to the bug list in a few minutes. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 participants
0 comments

Re: XEmacs doing its own C backtraces 25 years, 3 months

Ulrich Drepper

wmperry(a)aventail.com (William M. Perry) writes: > But does it work? :) I thought this would be nifty to use in our server, > and I just tried it. I just threw in this code in the midst of it > processing a connection: > > { > void *array[250]; > int n = backtrace(array,250); > > backtrace_symbols_fd(array,n,fileno(stderr)); > } > > All I got was: > > [0x805d3f7] > [0x805c21e] > [0x805c994] > [0x805c9fc] > [0x805b40a] > /lib/libc.so.6(__libc_start_main+0xeb)[0x401cfcb3] > [0x8051ab1] Which is the correct information. Do you know how program loading works? An ELF file has parts which are loaded and those which are not. And debugging info is never loaded. Therefore the backtrace functions have no access to the function names etc. But if you look at the catchsegv script coming with glibc 2.1 you'll see how to get the missing informaiton. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 participants
0 comments

Problems with text-modes/folding.el and XEmacs 21 25 years, 3 months

stefan.becker＠nokia.com

Package: text-modes Version: 1.21 ELisp file: text-modes/folding.el Version : X.x Feb 12 1998 [Jari 2.30] (from the change history) [ Jari & Anders: I'm not sure if you are still maintaining folding.el ] There seems to be a problem with the folding mode and XEmacs 21.1 (I have tried .4 and .6). When you try to goto a line inside a sub-fold with a nesting level 2 or higher you get the following error message: wrong type argument: sequencep, 2 instead of entering the fold with an updated "2Fld", "3Fld", ... mode-line. If the buffer has been "unfolded" (Show whole buffer) then the goto works but of course it only enters the first fold nesting level. When I start XEmacs 20.4, load & evaluate folding.el from text-modes 1.21 (it doesn't come with 20.4), everything works fine, that is XEmacs enters the folds and shows "2Fld", "3Fld" and so on. You can try to reproduce this bug with the folding.el file: c-x c-f /usr/local/lib/xemacs/xemacs-packages/lisp/text-modes/folding.el M-x folding-mode -> Folds buffer M-g 2928 or you can try with the following small C program and try to go to line 10: ---------------------------------- Cut Here ------------------------- /* {{{ fold1 */ Inside fold1 /* {{{ fold1.1 */ Inside fold1.1 /* {{{ fold1.1.1 */ fold1.1.1 /* }}} */ /* }}} */ Again inside fold1 /* }}} */ /* {{{ fold2 */ fold2 /* }}} */ /* {{{ fold3 */ fold3 /* }}} */ ---------------------------------- Cut Here -------------------------- Maybe this has something to do with the error messages from XEmacs when you try to byte-compile folding.el: ------------------------ Cut Here ------------------------------- bosw27:text-modes> xemacs -batch -no-site-file -no-init-file -eval '(setq load-path (cons "." load-path))' -f batch-byte-compile folding.el Compiling /appl/pdtools/common/lib/xemacs/xemacs-packages/lisp/text-modes/folding.el.. . Loading overlay... ** folding.el: Info, Ignore [X]Emacs specific missing event-/posn- functions calls While compiling the end of the data in file /appl/pdtools/common/lib/xemacs/xemacs-packages/lisp/text-modes/folding.el: ** The following functions are not known to be defined: event-start, posn-window, posn-col-row, hs-discard-overlays Wrote /appl/pdtools/common/lib/xemacs/xemacs-packages/lisp/text-modes/folding.elc Done ------------------------ Cut Here ------------------------------- I'm no emacs-lisp expert so I have no idea what the error could be... Regards, Stefan --- Stefan Becker Technical Expert SW, NMP/STP R&D Center Bochum E-Mail: Stefan.Becker(a)nokia.com Office: +49-(0)234-984-4672 FAX: +49-(0)234-984-3601 GSM : +49-(0)172-2704283

1 participants
0 comments

Re: XEmacs doing its own C backtraces 25 years, 3 months

William M. Perry

Ulrich Drepper <drepper(a)cygnus.com> writes: > SL Baur <steve(a)xemacs.org> writes: > > > I don't know about that. There used to be code in XEmacs to > > self-generate a C stack backtrace in Solaris. I took it out because > > it had a tendency to crash in the middle of printing the backtrace. > > The code I have in glibc does not have this problem. There are three > functions: > > backtrace() to get the values > > backtrace_symbols() to convert it into symbols > or > backtrace_symbols_fd() to immediately write the result to > an file descriptor > > > > I would say that seeing these functions crashing is highly unlikely > unless the memory the libc uses gets clobbered. It is not a simple > minded implementation. But does it work? :) I thought this would be nifty to use in our server, and I just tried it. I just threw in this code in the midst of it processing a connection: { void *array[250]; int n = backtrace(array,250); backtrace_symbols_fd(array,n,fileno(stderr)); } All I got was: [0x805d3f7] [0x805c21e] [0x805c994] [0x805c9fc] [0x805b40a] /lib/libc.so.6(__libc_start_main+0xeb)[0x401cfcb3] [0x8051ab1] This is with debugging server, and according to file: /usr/local/aventail/bin/socks5: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped This is on linux (RH 6.0 based install) and glibc 2.1.1. Any clue what could be causing it not to find the symbols? -Bill P.

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 1999