January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

the culprit is zmacs-regions 24 years, 10 months

T. V. Raman

found the problem --or at least its cause --(mark) in xemacs returns nil even if the mark is set. Emacspeak examines the mark value for all kinds of things --especially to indicate to the user what the is being deleted etc --

1 participants
0 comments

mark in xemacs with emacspeak loaded 24 years, 10 months

T. V. Raman

This is a follow-up to my previous message --I tried xemacs without emacspeak loaded and there is no problem with the mark. However I'm confused as to what I could be doing in the emacspeak code that is deactivating the mark. With emacspeak loaded, if I: Hit C-spc to set the mark, cursor over by even one character and hit M-= to see how many chars there are in the region I get a mark not active message. Running with debug-on-error set to t does not help --since the backtrace only shows "the mark is not active now" -- Best Regards, --raman Email: raman(a)cs.cornell.edu WWW: http://cs.cornell.edu/home/raman/ PGP: http://cs.cornell.edu/home/raman/raman.asc

1 participants
0 comments

Re: /etc/ld.so.conf handling doesn't work for me 24 years, 10 months

Jan Vroonhof

"Daniel Pittman" <daniel(a)danann.net> writes: > > Why do you need an X app? Won't something like > > Ah. Using dlopen() will only detect the mismatch on platforms that > support that interface. If it's going into configure I would prefer to > have something more portable. I am betting that all platforms that allow the user so much control over the linking environments so as to confuse the test that you already do also support dlopen() Jan

1 participants
0 comments

Re: [BUG] Tremendous memory leak 24 years, 10 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Open the scratch scratch buffer, evaluate stuff below > and monitor xemacs virtual memory (committed, private) size. > My numbers are below. > > Start, Mem. usage = 8M > (make-string 10000000 ?A) ->> 18M > ; After ~1s, the string displayed in the minibuffer ->> 55M > (garbage-collect) ->> 55M ... > Please test this under different platforms. On Linux XEmacs increases from 8.9M memory consumption to 28.5M (the 20M increase is probably related to minibuffer printing.) No matter how many times I repeat the operation with different letters, memory consumption remains 28.5M with small variations. So I guess it doesn't leak over here.

1 participants
0 comments

Re: [BUG] Tremendous memory leak 24 years, 10 months

Hrvoje Niksic

Darryl Okahata <darrylo(a)sr.hp.com> writes: > Umm, could this be a case of the message-log just keeping copies of > the HUGE messages? That can be eliminated using: (prog1 nil (make-string ...)) That's what I use in my test cases.

1 participants
0 comments

Re: Current (late night 01/24) CVS hosed in lwlib on AIX 4.3 24 years, 10 months

Michael Sperber

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks(a)vt.edu> writes: Valdis> On Mon, 24 Jan 2000 21:58:24 PST, Martin Buchholz said: VK> Seems to expand that X11 into the actual directory name. VK> I'm surprised that #including a directory works, this is PROBABLY VK> an IBM bug. >> >> I think so. Our code is weird, but legal C. Valdis> If somebody cites me chapter&verse of a standard saying this is Valdis> required to work, I'll bug-report it. I don't have ANSI, but K&R2 has this on page 231: Finally, a directive of the form #include token-sequence not matching one of the previous forms in interpreted by expanding a token sequence as for normal text; [...], and it is then treated as previously described. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: New packages and tarballs uploaded 24 years, 10 months

Andreas Jaeger

>>>>> Damon Lipparelli writes: Damon> Andreas, Damon> The new version of texinfo (1.18) isn't there. I forgot to move it:-(. It's at the announced place now. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Current (late night 01/24) CVS hosed in lwlib on AIX 4.3 24 years, 10 months

Valdis Kl=?iso8859-4?Q?=BA?=tnieks

The AIX xlc 3.6.6 compiler does *NOT* like the INCLUDE_GLUE hackery on a #include. The following test case demonstrates: cd lwlib/ cat > z9.c << EOF #include "config.h" ATHENA_INCLUDE(foobar.h) #include ATHENA_INCLUDE(foobar.h) EOF xlc -E -I. -I/usr/local/include z9.c | tail produces on stderr: "z9.c", line 3.11: 1506-341 (S) #include header must be ended before the end of the line. "z9.c", line 3.10: 1506-234 (E) Expecting a new-line character on #include directive. and on stdout: #line 11 "./../src/s/aix4.h" struct ether_addr; struct sockaddr_dl; #line 2 "z9.c" <X11/Xaw/foobar.h> #line 1 "/usr/local/include/X11" >R.>Q..>Sxpm.h>Tbpmplus.h Seems to expand that X11 into the actual directory name. I'm surprised that #including a directory works, this is PROBABLY an IBM bug. /Valdis

2 participants
2 comments

crash on linux using 21.2-b27 24 years, 10 months

Bob Smart

Compiled xemacs is http://www.ted.cmis.csiro.au/~smart/xemacs-21.2-b27 and core file is http://www.ted.cmis.csiro.au/~smart/core. I was editing an erlang file (www.erlang.org) using their .elc. I had the same file open in two windows. recover-session requires dired? send bug report is greyed out. Bob (gdb) where #0 0x402c8111 in __kill () #1 0x8084c21 in fatal_error_signal (sig=11) at emacs.c:278 #2 <signal handler called> #3 0x401dca5e in _Xi18n_lock () #4 0x81ac567 in TabsUnhighlight (w=0x84a3a18, event=0xbffff440, params=0x0, num_params=0x40132294) at xlwtabs.c:1221 #5 0x40123e8d in HandleActions () #6 0x40124342 in HandleSimpleState () #7 0x40124851 in _XtTranslateEvent () #8 0x401019f7 in XtDispatchEventToWidget () #9 0x40102406 in _XtDefaultDispatcher () #10 0x40102873 in XtDispatchEvent () #11 0x4010db8f in XtAppProcessEvent () #12 0x81763c0 in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:2602 #13 0x80b510e in detect_input_pending () at event-stream.c:507 #14 0x80b6d5d in Fnext_event (event=141399092, prompt=136653876) at event-stream.c:2064 #15 0x806af69 in Fcommand_loop_1 () at cmdloop.c:566 #16 0x806b1ad in command_loop_1 (dummy=136653876) at cmdloop.c:490 #17 0x808e5bc in condition_case_1 (handlers=136653972, bfun=0x806b168 <command_loop_1>, barg=136653876, hfun=0x806a370 <cmd_error>, harg=136653876) at eval.c:1629 #18 0x806b28c in command_loop_2 (dummy=136653876) at cmdloop.c:252 #19 0x808e49f in internal_catch (tag=136727828, func=0x806b254 <command_loop_2>, arg=136653876, threw=0x0) at eval.c:1304 #20 0x806a7a4 in initial_command_loop (load_me=136653876) at cmdloop.c:301 #21 0x80831c2 in xemacs_21_2_b27_i686_pc_linux () at emacs.c:1906 #22 0x8084e0f in main () at emacs.c:2331 #23 0x402c1cb3 in __libc_start_main (main=0x8084d10 <main>, argc=20, argv=0xbffff924, init=0x804dc78 <_init>, fini=0x81ae394 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff91c) at ../sysdeps/generic/libc-start.c:78 (gdb) --=-=-=--

1 participants
0 comments

Re: /etc/ld.so.conf handling doesn't work for me 24 years, 10 months

Daniel Pittman

On 24 Jan 2000, Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote: > Daniel Pittman <daniel(a)danann.net> writes: > >> I tried to come up with a good configure-time test but don't know X >> much at all, yet. Not to write a new application for configure to >> test, anyway.[1] > > Why do you need an X app? Won't something like Ah. Using dlopen() will only detect the mismatch on platforms that support that interface. If it's going into configure I would prefer to have something more portable. I can implement this pretty quickly though and will do so in the not too distant future, assuming free time to do so. Daniel -- Any government that is big enough to give to us everything we want, is big enough to take from us everything we have! -- Gerald Ford

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