December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 25 years, 11 months

Norbert Koch

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > >>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > Kyle> Adrian Aichner writes: > >> Following line which tries to use a pointer glyph as a text annotation > >> crashes both XEmacs-21.0-b59 and XEmacs-21.2-b5. They vanish without > >> a single line of good-bye. > >> > >> (make-annotation gc-pointer-glyph nil 'text) > > Kyle> Repeated attempts with 21.0.60 fail to reproduce the problem > Kyle> here, using i386-unknown-bsdi2.0 on a tty or under X. Please > Kyle> send a C stacktrace. Hi Adrian, > How do I obtain it correctly? > > XEmacs crashes without offering to enter the debugger under WindowsNT, > which she normally would. have you tried running XEmacs from the debugger? I know this is slow as hell ... but if you know the right way to reproduce the error, your pain won't last for long :-) If I'm not mistaken, this should at least give you a callstack. > Anybody else seeing this? No version at hand, sorry. Cheers, norbert. -- I want you to organize my PASTRY trays... my TEA-TINS are gleaming in formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me --

1 participants
0 comments

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 25 years, 11 months

Hrvoje Niksic

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Kyle> Repeated attempts with 21.0.60 fail to reproduce the problem > Kyle> here, using i386-unknown-bsdi2.0 on a tty or under X. Please > Kyle> send a C stacktrace. > > How do I obtain it correctly? > > XEmacs crashes without offering to enter the debugger under > WindowsNT, which she normally would. Why don't you run XEmacs under a debugger and look at where it is exiting?

1 participants
0 comments

Re: [CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 25 years, 11 months

Adrian Aichner

>>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> Adrian Aichner writes: >> Following line which tries to use a pointer glyph as a text annotation >> crashes both XEmacs-21.0-b59 and XEmacs-21.2-b5. They vanish without >> a single line of good-bye. >> >> (make-annotation gc-pointer-glyph nil 'text) Kyle> Repeated attempts with 21.0.60 fail to reproduce the problem Kyle> here, using i386-unknown-bsdi2.0 on a tty or under X. Please Kyle> send a C stacktrace. How do I obtain it correctly? XEmacs crashes without offering to enter the debugger under WindowsNT, which she normally would. Anybody else seeing this? Adrian

1 participants
0 comments

Re: compiles suffix (*.elc) 25 years, 11 months

Didier Verna

Sam Steingold writes: Sam> Now that the compiled formats of Emacs and XEmacs are officially Sam> incompatible, i.e., one cannot load files compiled with the other, we Sam> have a problem with sharing site-lisp directories. Sam> It would be nice if both emacsen refused to load files compiled with the Sam> other emacs - that would solve some problems. It would be even nicer if Sam> they used different compiled suffixes (e.g., .elx instead of .elc), which Sam> would permit sharing site-lisp directories once again. When the first XEmacs 21 is out, the site-lisp directory will be mostly obsolete and people urged to use the package directories instead. This should be enough to distinguish both elcs. IMHO, application maintainers should then consider GNU Emacs and XEmacs as 2 different Emacsen, which means installing elisp files in 2 different places and compiling them differently. Obviously, this doesn't solve the problem of using both Emacsen with an XEmacs prior to 21, but still, the problem is solved (in 21) by using a different directory structure. For the same reason, it don't think changing the extension would be usefull, while I'm not against it. I agree with Kyle that if someone has to change, it's us. -- / / _ _ 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

Status of 21.2.5 25 years, 11 months

Martin Buchholz

The CVS sources have applied to them all the patches from me that fix serious problems in that release. I believe Andy applied applicable patches from others that relate to running on Windows. I was hoping to get 21.2.6 out this weekend, but that won't happen. In the meantime, I'm still begging for folks using Windows to try to track down the remaining instability problems there that I currently can't debug. Although Windows needs some more work, on Unix, 21.2.5, with two patches already in CVS, seems rather stable. Martin

1 participants
0 comments

Re: alpha-linux build failure 25 years, 11 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Hrvoje Niksic writes: > > Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > > > Why wait for XEmacs to crash? We should make configure flat out > > > refuse to build XEmacs using egcs-1.1. After seeing people report > > > the gcc-2.7 -fcaller-saves induced crash over and over again, I > > > think we should refuse to build using broken compilers unless we > > > have a fix in place. > > > > Well. Uhm. I think that's a bit too harsh. I don't like configure > > bombing out on me unless there's a *really* good reason for that. > > This isn't a good reason?! Can configure really know that the binary will come out corrupt? What if I specify `--cflags=-g'? What if I specify `-O' (as opposed to `-O2')? Bombing out during configure is very harsh because, unlike `make', there is no convenient way to fix the problem and "resume" the configuration -- you have to start over. Bombing in configure should be a last resort, not a standard practice. > If configure can't build a binary that will work reliably _to the > best of our knowledge_ then it should stop. If we want to offer the > user a --use-broken-compiler option then that's fine--- how else > will the problems get debugged. But using a known broken compiler > should not be a default action. I think we should use the compiler the user specified. If we think there is a problem with that, bitch and moan -- but don't bomb out. > > Warnings would be fine, though. > > configure spews a long series of messages. A warning will be lost > in all that. I think the warnings at the end are nicely visible. > I build XEmacs like this > > ./configure; make > > and then go do something else while it grinds. If we expect people > to pay attention to the warnings, either configure has to generate > much less output or configure has to abort, so that the user is > forced to read the message and take some action. Most users separate the `configure' and `make' steps, I hope. Also, non-beta XEmacsen spew much less configure output.

2 participants
1 comments

[CRASH] Incorrect (make-annotation ...) vaporizes XEmacsen 21.[02] 25 years, 11 months

Adrian Aichner

Following line which tries to use a pointer glyph as a text annotation crashes both XEmacs-21.0-b59 and XEmacs-21.2-b5. They vanish without a single line of good-bye. (make-annotation gc-pointer-glyph nil 'text) The built-in function `set-extent-begin-glyph' at line 161 of annotations.el (set-extent-begin-glyph new-annotation glyph layout)) is where it happens in lisp-land. I don't know whether this is Windows-specific. Adrian

2 participants
1 comments

Re: alpha-linux build failure 25 years, 11 months

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: > SL Baur writes: ... >> We probably need to add a warning about egcs-1.1 somewhere in >> PROBLEMS. [done] > Why wait for XEmacs to crash? We should make configure flat out > refuse to build XEmacs using egcs-1.1. I strongly disagree. It's not completely broken. I didn't have any XEmacs-related problems with egcs-1.1, nor am I having any problems with egcs-1.1.1.

2 participants
1 comments

Re: alpha-linux build failure 25 years, 11 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: > ... > > configure spews a long series of messages. A warning will be > > lost in all that. > > I agree. I've always thought the defaulting of configure output to > verbose makes the problem worse if anything. It's verbose only in beta XEmacsen. Beta testers should know what they are doing. > > I build XEmacs like this > > > ./configure; make > > Fascinating. Configure has so many bogus defaults for my system I > can't do that and get an XEmacs I wish to run. Maybe you run a strange system? I have fought teeth and nail to get Martin to include reasonable defaults for my (quite typical Solaris) system, and this is mostly the case now. Of course, I still use a bunch of configure options for the strange things *I* want to do, but the defaults are AFAIK sane.

1 participants
0 comments

Re: alpha-linux build failure 25 years, 11 months

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: ... > configure spews a long series of messages. A warning will be > lost in all that. I agree. I've always thought the defaulting of configure output to verbose makes the problem worse if anything. > I build XEmacs like this > ./configure; make Fascinating. Configure has so many bogus defaults for my system I can't do that and get an XEmacs I wish to run. > and then go do something else while it grinds. If we expect people > to pay attention to the warnings, either configure has to generate much > less output or configure has to abort, so that the user is forced > to read the message and take some action. We probably need a quiet option that only prints out fatal error messages. It really depends on the speed of the machine you're building XEmacs on. I've been really annoyed at spending 20 minutes configuring XEmacs on a slow Sparc only to find it chose the wrong options and on a fast machine it doesn't matter.

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 December 1998