December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Using mktemp for temporary files 24 years, 11 months

Karl M. Hegbloom

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Oops.. I forgot that on the linux machine I was one we use Jan> the Redhat CVS package. It uses mktemp too (which won't work Jan> on Solaris). Jan> There are some writeups on how to do this portably. The Jan> debian folk have one, I'l try finding it Jan> [time passes] It's `tempfile', and is in the `debianutils' package.

1 participants
0 comments

Re: Is it ok to release packages? 24 years, 11 months

Jan Vroonhof

<rejoice> Yes! </rejouce> Jan

1 participants
0 comments

Re: Mule redisplay crash 24 years, 11 months

Mike Fabian

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > Mike Fabian <fabian(a)mpia-hd.mpg.de> writes: > > > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > > A quick fix for the crash would be adding a call to > > > ensure_face_cachel_contains_charset() at the relevant place in > > > x_output_string like this: > > > > [...patch...] > > > > Wonderful! This cures the frequent crashes I experienced while using > > lookup.el. Last weekend I managed to reproduce these crashes, but > > wasn't yet able to narrow it down to a small bit of sample code. > > Oh, are these the crashes you reported to crashes(a)xemacs.org (Sorry > don't have the PR# handy)? I thought we had fixed that by checking for > dead processes? No, these are unrelated. The only thing these two types of crashes had in common is that I experienced both wile using lookup.el. I can verify that the one with the dead processes is fixed by your patch which checks for dead processes. The other type of crash during using lookup.el was the one which crashed after `split-window', shortly after inserting Japanese. This was extremely annoying, as it was very frequent. Last Sunday I was finally able to reproduce it, but it was very late and I was to stupid to narrow it down small bit of sample code. After applying your patch it went away. I tried it on Linux and Solaris 2.5 and lookup.el hasn't crashed since. > > The last function shown on the lisp backtraces was always > > `split-window' shortly after some Japanese characters had been > > inserted. > > > > Therefore when I saw Gunnars patch appear on this list, I guessed this > > might fix my problem, and indeed it did. > > Uhm, it wasn't really meant as a serious patch, more as a help in > diagnosing the problem. As you are apparently running an xemacs with > it, does it cause a massive slowdown or any other obvious changes? I don't notice any obvious slowdown nor any other obvious changes. Can I help to measure the slowdown somehow? What sort of thing should be measured? Mike

1 participants
0 comments

Re: Mule redisplay crash 24 years, 11 months

Gunnar Evermann

Mike Fabian <fabian(a)mpia-hd.mpg.de> writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > A quick fix for the crash would be adding a call to > > ensure_face_cachel_contains_charset() at the relevant place in > > x_output_string like this: > > [...patch...] > > Wonderful! This cures the frequent crashes I experienced while using > lookup.el. Last weekend I managed to reproduce these crashes, but > wasn't yet able to narrow it down to a small bit of sample code. Oh, are these the crashes you reported to crashes(a)xemacs.org (Sorry don't have the PR# handy)? I thought we had fixed that by checking for dead processes? > The last function shown on the lisp backtraces was always > `split-window' shortly after some Japanese characters had been > inserted. > > Therefore when I saw Gunnars patch appear on this list, I guessed this > might fix my problem, and indeed it did. Uhm, it wasn't really meant as a serious patch, more as a help in diagnosing the problem. As you are apparently running an xemacs with it, does it cause a massive slowdown or any other obvious changes? Gunnar

1 participants
0 comments

Re: More ESD ./configure bogosity 24 years, 11 months

Raymond Toy

>>>>> "Daniel" == Daniel Pittman <daniel(a)danann.net> writes: Daniel> On Tue, 14 Dec 1999, Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp> Daniel> wrote: >>>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >> Jan> This makes it coexist a lot better with old style Jan> open("/dev/dsp") programs on Linux and thus makes it possible Jan> to enable it by default without annoying users. >> >> Oh, is _that_ what Daniel meant by mixing? Daniel> Er, no. The NAS I have does not block /dev/dsp, but that's a Debian Daniel> patch to the thing. Er, no. It's been a part of NAS (or some very old patch for NAS, that was never incorporated) for quite a while; you just had to know what option to use to enable it. I've been using that for several years now. Ray

1 participants
0 comments

Re: Mule redisplay crash 24 years, 11 months

Mike Fabian

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > loading the following in a vanilla Mule XEmacs will trigger a crash. > > (defun delete-and-split () > (interactive) > (delete-other-windows) > (split-window)) > (split-window-vertically) > (insert "$B$,(B") > (backward-char) > (redraw-frame) > (delete-and-split) [...] > A quick fix for the crash would be adding a call to > ensure_face_cachel_contains_charset() at the relevant place in > x_output_string like this: [...patch...] > This works but is kindof expensive to do, as x_output_string is called > very very often :-) > > Maybe our Mule and redisplay experts can try to come up with something > more clever... Wonderful! This cures the frequent crashes I experienced while using lookup.el. Last weekend I managed to reproduce these crashes, but wasn't yet able to narrow it down to a small bit of sample code. The last function shown on the lisp backtraces was always `split-window' shortly after some Japanese characters had been inserted. Therefore when I saw Gunnars patch appear on this list, I guessed this might fix my problem, and indeed it did. Thank you very much! Mike

1 participants
0 comments

Re: NAS support in XEmacs 24 years, 11 months

Raymond Toy

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Ray> There's nas 1.3 out now. Someone did pick up nas, but the mailing Ray> list has been relatively quiet. Martin> It's very well hidden. I couldn't find it. Martin> Any web pointers to the new NAS? Here's my link: http://home.rmi.net/~jon/nas.html, this includes the mailing list archives. I have not yet tried out the latest version, because the version I have works just fine. :-) On my list of things to do someday.... Martin> Well, `configure --with-nas' works, right? Yes; it was wishful thinking on my part that nas could be autodetected. Martin> Raymond, because you *really* care, I did some more work on NAS. Martin> I succeeded in building it on Solaris, but not on Linux. It basically Martin> requires a guru to build and install the software. [valid gripes removed] Martin> This is actually also an indictment of X11 in general. Martin> autoconf/configure is really ugly, but it does work. I believe someone is trying to get NAS to build via autoconf. Martin> Note that the NAS header files are not C++-compatible, since they Martin> don't use full prototypes, which is a no-no for modern libraries. I'll look into ansifying the header files, if the maintainer is interested in such things. Martin> NAS needs a maintainer. There is one. Or are you talking about NAS in XEmacs? If so, that was supposed to be me. Martin> But just to prove that I do occasionally listen to my Martin> users, here is a new NAS patch with autodetecting Martin> configure support and warning fixes: I appreciate your fixes very much. Martin> (Oh, and Raymond, I expect you to actually use this...) Of course. Squeaky wheel gets the grease, so I'd better keep using that wheel. Thanks, Ray

1 participants
0 comments

Latest tabs changes leave XEmacs completely broken. 24 years, 11 months

Martin Buchholz

Beta testers, please do not update to the latest version from CVS. When I start up the latest XEmacs from CVS, a black frame is on the screen for 20 seconds or so, and then it crashes. It seems very likely that Andy's changes of today caused the problem. Andy, could you back out your change if you can't figure out what's going on fairly quickly, so that people can at least use CVS? gdb gives an enormous backtrace with thousands of stack frames that starts like this: #0 TabLayout (tw=0x855c750, wid=91, hgt=23, reply_height=0x0, query_only=0) at /xemacs/ws/dev/lwlib/xlwtabs.c:1676 #1 0x81eec8d in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:545 #2 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #3 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #4 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #5 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #6 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #7 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #8 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #9 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #10 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #11 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #12 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #13 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #14 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #15 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 #16 0x81eee17 in TabsExpose (w=0x855c750, event=0x0, region=0x0) at /xemacs/ws/dev/lwlib/xlwtabs.c:591 #17 0x81eedd8 in TabsResize (w=0x855c750) at /xemacs/ws/dev/lwlib/xlwtabs.c:573 Martin

2 participants
1 comments

Another tabs fix 24 years, 11 months

Andy Piper

Ed, The tabs do not pick up changed fonts when done via XtSetValues, this is because the GCs need to be recalculated. This patch fixes this (although doesn't explain why I still can't get font setting to work properly). andy 1999-12-14 Andy Piper <andy(a)xemacs.org> * xlwtabs.c (TabsSetValues): re-allocate GCs if font has changed. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Is it ok to release packages? 24 years, 11 months

Andreas Jaeger

I didn't follow all discussions on the xemacs list closely - but I didn't get any real bug report regarding the packages. Is there any showstopper? If I don't hear anything I'm releasing the packages tonight (local time). If anybody finds a problem with any package after the release, I can release a new version soon. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

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 1999