August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: (set-specifier minimum-line-ascent 30 (current-buffer)) 26 years

Jan Vroonhof

Stef Epardaud <stef(a)lunatech.com> writes: > Use `window-height' to get consistent results in geometry > calculations. > Use `window-displayed-height' to get the actual number of lines > currently displayed in a window. > > and it says that it is not taking the line-ascent at all, in > window-height. > and window-displayed-height does return the correct amount of lines, > taking the line-ascent into account. > > is that a non-bug ? The reason that window-displayed-height actually counts the number of lines so it always right. However the reason they normally differ is that on XEmacs where you can have several different kind of glyphs and face, all lines can differ in height. window-displayed-height takes that into account, and thus the result can change if you are viewing a different part of the buffer. However window-height simply assumes a "standard line height" (namely the height of the default face in that locale). Using this call: default_face_height_and_width (window, &defheight, &defwidth); Thus it can and will be "wrong", but the result doesn't depend on where you are in the buffer, i.e. it is more consistent. The problem is that default_face_height_and_width doesn't take minimum-line-ascent/descent into account but it probably should. So either 1. The "standard line height" shouldn't depend on the buffer/window. Then current default_face_height_and_width shouldn't take into account the window locale either. 2. Like it is now the "standard line height" does depend on buffer/window, but then it should take minimum-line-ascent/descent into account. Jan

3 participants
2 comments

Re: XEmacs doing its own C backtraces 26 years

Ulrich Drepper

SL Baur <steve(a)xemacs.org> writes: > I was not suggesting it was, nor was I referring at all to your > implementation, but rather to how I've seen XEmacs behave when it is > about to go down in flames. Well, you have to overwrite one very specific word in the address space, that's the only possibility. This is the only piece of data the functions depend on. None of the used functions uses malloc() or other dangerous functions. I know about the problems with wild running programs and the functions are designed for these cases. I think it is worthwhile looking into this since, as initially mentioned, the C backtrace currently possible is useless. -- ---------------. 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 26 years

SL Baur

Ulrich Drepper <drepper(a)cygnus.com> writes in xemacs-beta(a)xemacs.org: > 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: ... > I would say that seeing these functions crashing is highly unlikely > unless the memory the libc uses gets clobbered. That's a very likely possibility. > It is not a simple minded implementation. I was not suggesting it was, nor was I referring at all to your implementation, but rather to how I've seen XEmacs behave when it is about to go down in flames. XEmacs does quite a lot when a fatal error occurs and it is not uncommon that a second fatal error occurs when it is trying to clean up from the first one. In general I want to aim towards simplifying the fatal error code because as you point out, no matter how carefully you code, you can still be defeated if your memory gets clobbered.

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 26 years

SL Baur

William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: ... > You might try using unexsol2.o instead of unexsol2-6.o as well. I've had > nothing but problems on my 2.6 box, but I assumed it was because it is a > sparcbook with all sorts of odd libraries getting loaded at link time. My problems started yesterday. Three days ago, everything was fine. I use "strange" libraries like XFree86 X libraries and that has been working just fine.

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 26 years

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: ... >> It's a longshot, but you might want to try editing src/unexsol2-6.c >> (I assume you're using Solaris 2.6) and change line 33 from: >> if (dldump (0, new_name, RTLD_MEMORY) != 0) >> to: >> if (dldump (old_name, new_name, RTLD_MEMORY) != 0) > O.K. I will try this and report back. It didn't work. I made that change, did a `./config.status --recheck; make clean; make' and got this: Dumping under the name xemacs unexec(): dldump(/usr/local/devel/miho-optimized/src/xemacs): ld.so.1: ./temacs: fatal: /usr/local/devel/miho-optimized/src/temacs: can't find file make[1]: [xemacs] Error 1 (ignored) Testing for Lisp shadows ... make[1]: ./xemacs: Command not found

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 26 years

William M. Perry

SL Baur <steve(a)xemacs.org> writes: > Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: > > > SL Baur <steve(a)xemacs.org> wrote: > >> What does this message mean? And why did I get an XEmacs anyway? > >> > >> Dumping under the name xemacs > >> unexec(): dldump(/usr/local/devel/miho-optimized/src/xemacs): ld.so.1: ./tema > >> cs: fatal: /usr/local/devel/miho-optimized/src/xemacs: unknown dynamic entry: > >> 1879048176 > > > Dunno. Is XEmacs playing with argv[0]? > > Please define `playing with'. We depend upon argv[0] at run-time to > be the full path to the `xemacs' binary and use that information as a > starting basis for finding our run-time directories. > > > It's a longshot, but you might want to try editing src/unexsol2-6.c > > (I assume you're using Solaris 2.6) and change line 33 from: > > > if (dldump (0, new_name, RTLD_MEMORY) != 0) > > > to: > > > if (dldump (old_name, new_name, RTLD_MEMORY) != 0) > > O.K. I will try this and report back. You might try using unexsol2.o instead of unexsol2-6.o as well. I've had nothing but problems on my 2.6 box, but I assumed it was because it is a sparcbook with all sorts of odd libraries getting loaded at link time. -bp Index: sol2.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/s/sol2.h,v retrieving revision 1.10 diff -c -w -r1.10 sol2.h *** sol2.h 1998/02/26 06:04:23 1.10 --- sol2.h 1999/08/19 03:29:07 *************** *** 87,93 **** #if OS_RELEASE < 56 #define UNEXEC "unexsol2.o" #else ! #define UNEXEC "unexsol2-6.o" #endif #else /* C_CODE */ --- 87,93 ---- #if OS_RELEASE < 56 #define UNEXEC "unexsol2.o" #else ! #define UNEXEC "unexsol2.o" #endif #else /* C_CODE */

1 participants
0 comments

Re: XEmacs doing its own C backtraces 26 years

Ulrich Drepper

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. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 participants
0 comments

HTML documentation not finished; I'll be offline a few days 26 years

Matt Curtin

I was unable to finish the HTML documentation and I will be pretty much offline for a few days. I grabbed the 21.1.4 distribution and made an initial pass over the texinfo files. What I have is at http://www.cis.ohio-state.edu/~cmcurtin/xemacs-doc/. If we're in a hurry to get these done, someone else might want to do the deed, or take what I have done so far and make it publishable. If no one else has done so by Tuesday morning (EDT), I'll finish the job then. -- Matt Curtin cmcurtin(a)interhack.net http://www.interhack.net/people/cmcurtin/

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 26 years

SL Baur

Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> wrote: >> What does this message mean? And why did I get an XEmacs anyway? >> >> Dumping under the name xemacs >> unexec(): dldump(/usr/local/devel/miho-optimized/src/xemacs): ld.so.1: ./tema >> cs: fatal: /usr/local/devel/miho-optimized/src/xemacs: unknown dynamic entry: >> 1879048176 > Dunno. Is XEmacs playing with argv[0]? Please define `playing with'. We depend upon argv[0] at run-time to be the full path to the `xemacs' binary and use that information as a starting basis for finding our run-time directories. > It's a longshot, but you might want to try editing src/unexsol2-6.c > (I assume you're using Solaris 2.6) and change line 33 from: > if (dldump (0, new_name, RTLD_MEMORY) != 0) > to: > if (dldump (old_name, new_name, RTLD_MEMORY) != 0) O.K. I will try this and report back.

1 participants
0 comments

Re: XEmacs doing its own C backtraces 26 years

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: >> What you could do, perhaps, is to generate a C backtrace yourself in >> the functions catching the signals. This will not be very portable >> but I've added in glibc 2.1 a function to do just that. There is also >> some code using this to generate backtraces in signal handlers. > Nice idea, even if only works using glibc 2.1 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.

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