May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Michael Harnois

In Gnus, with 21-2-b32. To get this error I: 1) start Gnus 2) move to a group 3) 1 <RET> to bring up the last message only 4) F to followup, but -- note -- without opening the message first -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org "It's not what we don't know that hurts us, it's what we know for certain that just ain't so." -- Mark Twain

3 participants
2 comments

XEmacs doesn't report core dumps 24 years, 7 months

Hrvoje Niksic

I've noticed that XEmacs never reports when a process started with M-! coredumps. For instance, try: M-! perl -e 'kill SEGV, $$' (Shell command failed with no output) OTOH, if I append `&' to the command to make it run in the background, I get: --- working directory: /home/hniksic/ % perl -e 'kill SEGV, $$' Segmentation fault (core dumped) 13:57:35 Is this a bug or a feature?

1 participants
0 comments

Re: Build: testing for lisp shadows dumps core 24 years, 7 months

Jan Vroonhof

giacomo boffi <giacomo.boffi(a)polimi.it> writes: > temacs had already dumped xemacs --- i have no c backtrace to show > you, as make wipes clean the executable after the failure Yes. This is very very annoying. I think you can use make fastdump to produce a real executable. > string-match("\$^\\(RCS\\|CVS\\|SCCS\$$\\)\\|\$^\\(etc\\|info\\|lisp\\|lib-src\\|bin\\|pkginfo\$$\\)" "etc") > # bind (raw-entries reverse-dirs directory path exclude-regexp max-depth directories) What is you max stack size?. Crashes like this are often stack related. Jan

3 participants
2 comments

[crash] --with-mule=no --with-file-coding seg fault during lisp shadow check 24 years, 7 months

Karl M. Hegbloom

I'm getting a segv when it goes to find the lisp shadows. This happens with both the HEAD and last beta "release" versions. The stack trace is different though... In both cases, I configured like: <URL:http://bittersweet.inetarena.com/xemacs-beta-Installation> The HEAD crash looks like this: <URL:http://bittersweet.inetarena.com/xemacs-beta-crashes-during-shadow-ch...> And the "stable" tagged version's stack dump looks like this: <URL:http://bittersweet.inetarena.com/xemacs-crashes-during-shadow-check.t...> If I build `--with-mule', it works fine.

2 participants
1 comments

Please fix these compile warnings/errors 24 years, 7 months

Martin Buchholz

I don't know who introduced these, but I assume it was either Ben or Andy or Katsumi. /xemacs/ws/dev/src/emacs.c: In function `assert_failed': /xemacs/ws/dev/src/emacs.c:3072: warning: function declared `noreturn' has a `return' statement /xemacs/ws/dev/src/emacs.c:3118: warning: `noreturn' function does return /xemacs/ws/dev/src/redisplay-tty.c: In function `reset_tty_modes': /xemacs/ws/dev/src/redisplay-tty.c:890: warning: passing arg 1 of `tty_frame_output_end' from incompatible pointer type /xemacs/ws/dev/src/redisplay-tty.c: In function `tty_redisplay_shutdown': /xemacs/ws/dev/src/redisplay-tty.c:917: warning: passing arg 1 of `tty_frame_output_end' from incompatible pointer type The above looks like a crasher. Katsumi, this looks like a type error in your patch... Please help. /xemacs/ws/dev/src/glyphs-x.c: In function `x_finalize_image_instance': /xemacs/ws/dev/src/glyphs-x.c:415: warning: implicit declaration of function `ungcpro_popup_callbacks' "/net/lasker/xemacs/ws/dev/src/glyphs.c", line 1955: warning: initializer does not fit or is out of range: -1 "/net/lasker/xemacs/ws/dev/src/glyphs.c", line 1956: warning: initializer does not fit or is out of range: -1 Regarding the above, note that an unsigned int is being assigned ~0, which will change its value. Then it might be compared with ~0, which might not give you what you want, depending on promotion rules and such. I strongly suggest making IMAGE_UNSPECIFIED_GEOMETRY below a small non-negative integer. What's the justification for making it ~0??? enum image_instance_geometry { IMAGE_GEOMETRY, IMAGE_DESIRED_GEOMETRY, IMAGE_MIN_GEOMETRY, IMAGE_MAX_GEOMETRY, IMAGE_UNSPECIFIED_GEOMETRY = ~0 }; I further suggest that in the code that triggers this warning in glyphs.c unsigned int dwidth = IMAGE_UNSPECIFIED_GEOMETRY, dheight = IMAGE_UNSPECIFIED_GEOMETRY; that this should read something like this: enum image_instance_geometry dwidth = IMAGE_UNSPECIFIED_GEOMETRY; enum image_instance_geometry dheight = IMAGE_UNSPECIFIED_GEOMETRY; for type correctness. There are probably more places in the code where such changes should be considered. grep for IMAGE_.[A-Z_]+GEOMETRY. Martin

2 participants
2 comments

Re: Give IMAGE_NOTHING sane height, Re: [crash] latest 21.2 24 years, 7 months

Björn Torkelsson

Vin Shelton <acs(a)xemacs.org> writes: > This seems to fix my crash. And mine too (See the thread "yacr (yet another crash report)"). Thanks Jan for fixing this! /torkel

1 participants
0 comments

Re: Give IMAGE_NOTHING sane height, Re: [crash] latest 21.2 24 years, 7 months

Vin Shelton

This seems to fix my crash. - vin >>>>> On 22 May 2000 , Jan Vroonhof <vroonhof(a)math.ethz.ch> said: Jan> [Please replace xemacs-patches by xemacs-beta on the CC when discussing] Jan> The following patch fixes a crash if XEmacs is redisplaying an Jan> IMAGE_NOTHING instantiator. The problem is that because of the Jan> automatic layout stuff the size of a glyph is now initialized to Jan> ~~0. This set to the real value upon instantiation (except for Jan> IMAGE_NOTHING). In most cases IMAGE_NOTHING is special cases so Jan> this doesn't matter. I guess this is now longer the case (a Jan> result of the new IMAGE_TEXT handling?). Jan> I think it is a good idea to simply give the glyph a sane size Jan> always. Jan> This fixes the problem various people (Mike & Ben) have been Jan> seeing.

1 participants
0 comments

[crash] clicking outside a popup-menu causes assertion failure. 24 years, 7 months

Karl M. Hegbloom

If I use the far button to bring up a popup mode menu, then click outside the menu, XEmacs crashes: <URL:http://bittersweet.inetarena.com/xemacs-popup-menu-crash.typescript>

1 participants
0 comments

lisp/packages.el : Why not use `expand-file-name' rather than `concat'? 24 years, 7 months

Karl M. Hegbloom

Is there a reason why `concat' is used to form paths in "lisp/packages.el", rather than `expand-file-name'? -- Those who do not study Lisp are doomed to reimplement it - Poorly. A few months in the laboratory often saves several hours at the library. mailto:karlheg＠debian.org (Karl M. Hegbloom)

1 participants
0 comments

lisp/loadhist.el, user settings variables, and hook lists. 24 years, 7 months

Karl M. Hegbloom

When `unload-feature' is called, it unbinds all of the symbols provided by a package, and removes the feature symbol from the features list. When a `defvar' or `defcustom' variable symbol from a feature is `makunbound', does that remove values set by the user with `setq' or `customize'? If so, then this situation needs to be handled correctly by `unload-feature' somehow. I suppose that it also ought to handle unlinking DSO's as well. What about open processes or ports held by something in the feature? What other resources might be held that should be freed up? How can these things be accomplished? (YTMAWBK) This also implies that if a hook function is added to a hook as the function itself (using #') rather than as the symbol containing the function, it will remain in that hook list in it's original form. If the symbol whos function cell contains the function is put in the hook list instead, then it will refer to an autoload form. Therefore `add-hook' should always be called with a type `symbolp' for FUNCTION, rather than a type `functionp'. Is this correct? What about having an `unload-feature-hook'? When would it be run? I suppose that it obviously has to be run prior to unbinding the value and function cell of a symbol... Hmmm. Prior to unbinding any of them, not each time one is unbound. Has anyone ever tried to devise a package system for X?Emacs based on multiple obarrays? The idea has crossed my mind a number of times, but I have not thought it through very much. It would require changes to the evaluator, I think. What if an obarray had, like a keymap, a parent obarry? I suppose it would then need to have siblings as well... Hmmm. -- Those who do not study Lisp are doomed to reimplement it - Poorly. A few months in the laboratory often saves several hours at the library. mailto:karlheg＠debian.org (Karl M. Hegbloom)

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