January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

[BUG] Unexterminable "Load .emacs" item 24 years, 5 months

Kirill 'Big K' Katsnelson

Start xemacs -q Click on "Load .emacs" (after my previous patch which fixes it) Ok, .emacs is loaded and the menu item is gone Open any file, or get help on any function, or open a completion buffer, or whatever which creates a buffer, and... Welcome "Load .emacs" back! Although, you can click on it in any new buffer, and it is deleted after .emacs is reloaded. From this buffer only, of course. It looks like the item is deleted from the buffer local menu. Ideas? Big K

1 participants
0 comments

[BUG] Overconsing(?) when signaling with long lists 24 years, 5 months

Kirill 'Big K' Katsnelson

Try this. Expand minibuffer so that it is a few lines long. Execute (signal-error 'error (make-list 1000 t)) For me, the list of t's is printed into the minibuffer as if it was a plain old 1200 baud terminal, then XEmacs stalls for ~3 sec, with GC cursor(?) flashing every second, 3-4 times. Increasing the length from 1000 to 1500 makes this happen 6-8 times. The relation seems to be quadratic or worse. (message "%s" (make-list 10000 t)) works flawlessly. I'll look into this, but if somebody sees something obvious... Big K

1 participants
0 comments

Re: check process state before accessing coding_stream (fix PR#1061) 24 years, 5 months

Gunnar Evermann

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes: > > 1999-12-18 Gunnar Evermann <ge204(a)eng.cam.ac.uk> > > > > * process.h (PROCESS_LIVE_P): Modify to take a Lisp_Process > > instead of a Lisp_Object as argument to make it consistent with > > the other LIVE_P macros. > > (CHECK_LIVE_PROCESS): New macro. > What's the status of this patch? AFAIK, it isn't applied to > 21.2. yes, that's correct. I didn't get around to applying it before I went home for Christmas. I'll apply it this weekend. Sorry. Gunnar

1 participants
0 comments

Re: Relocating allocator on Linux 24 years, 5 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > It seems that our relocating allocator attempts to do what Doug Lea > > malloc() already does. > > IIRC both our current collectors are older versions of the allocator > that Doug Lea's allocator replaced in libg++/glibc. Using the Doug > Lea version should normally be preferred I think.. It already is. AFAIK dlmalloc is used by default on Linux. The change was made when minimal tagbits were created. That's why minimal tagbits are chosen by default on Linux. > > The system-provided mmap-based allocation seems a better idea in > > XEmacs because it's performed for *all* large allocations (large > > vectors, strings, frob blocks etc.) rather than only for buffers, > > as our ralloc does. > > Shouldn't we be using ralloc for frob blocks anyway? It is my understanding that there are safety issues which make ralloc unsafe for anything but buffer text. But these issues might be restricted to non-mmap version of the allocator. I don't know. > > Does this mean we ought to turn off relalloc on Linux for 21.2? > > I don't know. My problem would be the fact that the triggering is > based on allocation size.. Yes, and that's a feature. mmap()-based allocation would be way too slow for small allocations. > What happens if you alloc+free > > - 1000, 1K strings > - 1000, 1k buffers > - 1 MB worth of cons cells. 1000 1k buffers is probably contrived. However, 1000 1k strings would be relocated by the compactor, and the cons cells would be allocated in frob blocks. Which means the memory will be released after GC. But why not test it? 1) Evaluate: ;; 100,000 cons-cells is about 1M (prog1 nil (setq a (make-list 100000 ?a))) 2) Evaluate: (setq a nil) (garbage-collect) The sizes are: 8876 5656 (1) 9956 6748 (2) 8932 5728 Apparently the memory is reclaimed. The string test has failed, and I don't think I can really explain it. If I read alloc.c correctly, strings smaller than 8K should be "small strings", and all of these are supposed to fit that category. It seems they were nevertheless exempt from compacting/freeing. No idea why. The biggest problem with frob blocks in our GC is that no relocation or compacting is done. This means that if only one cons-cell in a frob block remains in use, the whole frob block can't be freed. This was not the case in your example. > I am not sure either the current system or dlmalloc works in this > case. It seems to. > Along the same lines I have been wondering whether the frobblock > size shouldn't be upped? How much is it now? 1000 conses? The no-relocation problem described above makes me uneasy about making it larger.

1 participants
0 comments

fill-region-as-paragraph / mule / pdump / please help 24 years, 5 months

Olivier Galibert

I'm stumped. fill-region-as-paragraph works perfectly (afaik) when not using pdump or not using mule. Only pdump+mule is broken. While I can mostly follow the lisp code when featurep 'mule returns nil, I'm overweirded when the kinsoku junk comes into play. Could someone more knowledgeable about lisp point me to the subr/variable/whatever that does not behave the way it should so that I can trace the problem at the C level? OG.

3 participants
3 comments

enlightments anybody ? 24 years, 5 months

Andy Piper

Forwarded to xemacs-beta because I'm not sure OG reads xemacs-nt andy >To: xemacs-nt(a)xemacs.org >Subject: enlightments anybody ? >From: Fabrice Popineau <Fabrice.Popineau(a)supelec.fr> >Date: 13 Jan 2000 15:23:56 +0100 >Lines: 11 >User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.2 (Millenium) >Sender: owner-xemacs-nt(a)xemacs.org >X-Mailing-List: <xemacs-nt(a)xemacs.org> > >Hi, > >I'm looking into the portable dumper, following Andy's advice. But I >can't find much explanations on what it is doing and what I can expect >from it. Up to now, it compiles, but fails to dump. How is the dumping >step handled ? Is unexec still used ? > >On another topic, are the modules used actually by anybody ? > >-- >Fabrice Popineau > > > -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
1 comments

Re: Relocating allocator on Linux 24 years, 5 months

Andreas Jaeger

Just one note: I've forwarded your email to Wolfram who develops the malloc implementation in glibc that's used on Hrvoje's system. Please CC him in further discussions on this topic, he might give us some help. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Color fix 24 years, 5 months

Andy Piper

This makes sure background color changes get propagated to widgets. andy 2000-01-13 Andy Piper <andy(a)xemacs.org> * glyphs-x.c (update_widget_face): Make sure we update the widget background as well as foreground. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: Relocating allocator on Linux 24 years, 5 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > It seems that our relocating allocator attempts to do what Doug Lea > malloc() already does. IIRC both our current collectors are older versions of the allocator that Doug Lea's allocator replaced in libg++/glibc. Using the Doug Lea version should normally be preferred I think.. > The system-provided mmap-based allocation > seems a better idea in XEmacs because it's performed for *all* large > allocations (large vectors, strings, frob blocks etc.) rather than > only for buffers, as our ralloc does. Shouldn't we be using ralloc for frob blocks anyway? > Does this mean we ought to turn off relalloc on Linux for 21.2? I don't know. My problem would be the fact that the triggering is based on allocation size.. What happens if you alloc+free - 1000, 1K strings - 1000, 1k buffers - 1 MB worth of cons cells. I am not sure either the current system or dlmalloc works in this case. Along the same lines I have been wondering whether the frobblock size shouldn't be upped? Jan

1 participants
0 comments

Another xemacs 21.2.26 crash on Solaris 2.7 24 years, 5 months

Raymond Toy

This happened when I wasn't doing anything in my xemacs running just VM/GNUS. I was reading a mail message, switched to some other FVWM virtual window and was looking at that when my xemacs just disappeared. Here's the lisp backtrace: Lisp backtrace follows. I snipped the list of newgroups because it there were so many listed. process-send-string(#<network connection "nntpd" ("nntp" . "cnn.exu") state:exit> "LIST ACTIVE alt.sci \n") # bind (process string process command address port buffer wait-for callback decode wait-for strings count received last-point nntp-inhibit-erase command) # (unwind-protect ...) # bind (server groups) nntp-retrieve-groups([snip] "cnn.exu") # bind (gnus-command-method groups) gnus-retrieve-groups([snip] (nntp "cnn.exu")) # bind (newsrc gmethod groups info mesg where method) # (unwind-protect ...) # bind (methods list-type not-native force) gnus-read-active-file() # bind (gnus-inhibit-demon arg) gnus-group-get-new-news(nil) # bind (command-debug-status) call-interactively(gnus-group-get-new-news) # (condition-case ... . error) # (catch top-level ...) The C backtrace is: #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa7638 in fatal_error_signal (sig=6) at emacs.c:276 #2 <signal handler called> #3 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #4 0xfeab92a4 in abort () from /usr/lib/libc.so.1 #5 0xaa548 in assert_failed (file=0x26c678 "lstream.h", line=33, expr=0x26c688 "RECORD_TYPEP (obj, &lrecord_lstream)") at emacs.c:2825 #6 0xfe3fc in unix_send_process (proc=29391488, lstream=0x78ee00) at lstream.h:33 #7 0x199858 in send_process (proc=29391488, relocatable=2945268, nonrelocatable=0x0, start=0, len=1040912) at process.c:982 #8 0x199e74 in Fprocess_send_string (process=29391488, string=24548628, from=3106820, to=3106820) at process.c:1112 #9 0xb1efc in Ffuncall (nargs=-1, args=0xffbedb24) at eval.c:3175 #10 0x78ef4 in execute_optimized_program (program=0xffbedb24 "", stack_depth=2, constants_data=0xde6210) at bytecode.c:743 #11 0x786bc in funcall_compiled_function (fun=14597696, nargs=2, args=0xffbedd90) at bytecode.c:519 #12 0xb20ac in Ffuncall (nargs=2, args=0xffbedd84) at eval.c:3210 #13 0x78ef4 in execute_optimized_program (program=0xffbedd84 "", stack_depth=2, constants_data=0xcebe10) at bytecode.c:743 #14 0x786bc in funcall_compiled_function (fun=13542304, nargs=2, args=0xffbedfe0) at bytecode.c:519 #15 0xb20ac in Ffuncall (nargs=2, args=0xffbedfd4) at eval.c:3210 #16 0x78ef4 in execute_optimized_program (program=0xffbedfd4 "", stack_depth=2, constants_data=0xd3de10) at bytecode.c:743 #17 0x786bc in funcall_compiled_function (fun=13412044, nargs=0, args=0xffbee230) at bytecode.c:519 #18 0xb20ac in Ffuncall (nargs=0, args=0xffbee22c) at eval.c:3210 #19 0x78ef4 in execute_optimized_program (program=0xffbee22c "", stack_depth=0, constants_data=0xe00290) at bytecode.c:743 #20 0x786bc in funcall_compiled_function (fun=14726720, nargs=1, args=0xffbee480) at bytecode.c:519 #21 0xb20ac in Ffuncall (nargs=1, args=0xffbee478) at eval.c:3210 #22 0x7f8bc in Fcall_interactively (function=8477348, record_flag=3106820, keys=3106820) at callint.c:946 #23 0xb05d0 in Fcommand_execute (cmd=8477348, record=3106820, keys=3106820) at eval.c:2613 #24 0x1080c4 in execute_command_event (command_builder=0x639a80, event=28657128) at event-stream.c:4332 #25 0x108bf0 in Fdispatch_event (event=28657128) at event-stream.c:4643 #26 0x89988 in Fcommand_loop_1 () at cmdloop.c:575 #27 0x896d4 in command_loop_1 (dummy=3106820) at cmdloop.c:490 #28 0xadb34 in condition_case_1 (handlers=2890752, bfun=0x89670 <command_loop_1>, barg=3106820, hfun=0x89b5c <cmd_error>, harg=3106820) at eval.c:1629 #29 0x89c6c in command_loop_2 (dummy=3106820) at cmdloop.c:252 #30 0xad680 in internal_catch (tag=3189076, func=0x89c20 <command_loop_2>, arg=3106820, threw=0x0) at eval.c:1304 #31 0x88ee8 in initial_command_loop (load_me=564256) at cmdloop.c:301 #32 0xa922c in xemacs_21_2_b26_sparc_sun_solaris2_7 (argc=4, argv=0xffbeeddc, envp=0xffbeedf0, restart=0) at emacs.c:1898 #33 0xa9a64 in main (argc=4, argv=0xffbeeddc, envp=0xffbeedf0) at emacs.c:2323 Ray

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