August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Michael Sperber

>>>>> "Robert" == Robert Pluim <rpluim(a)bigfoot.com> writes: Robert> Faster execution of the core lisp code? This is unlikely with Emacs Lisp, as you'd still spend exactly the same time looking up identifier bindings etc. etc. However, Martin may have overlooked some gross inefficiencies in the Lisp engine which a compiler hacker might uncover in the course of writing the thing. Still, the optimizations would probably apply just as well to the current interpreter. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > I personally don't like this solution. It assumes you have mmap and surely > also has the problem that native windows suffers from that the memory has > to be mapped back in at a specific address. This causes dll conflicts in > windows. No, the idea is (I think) to do a "linking" fase where the adresses are remapped. Jan

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Jan Vroonhof

Robert Pluim <rpluim(a)bigfoot.com> writes: > I thought Kyle's plan was to write out a C _representation_ of the > parsed lisp, not to actually compile the lisp code to C? (I may be > misremembering here). No you are right. Jan

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Michael Sperber

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 10:19 AM 8/19/99 +0200, Michael Sperber [Mr. Preprocessor] wrote: >>>>>>> "mt" == Marcus Thiessel <marcus(a)xemacs.org> writes: >> mt> SL Baur writes: >> >>>> I now suspect dumping. I hate dumping, I hate it, I hate it, I hate >>>> it, I hate it. Why must we do something so stupid? >> mt> The question is what are the alternatives? Are there any at all? >> >> Absolutely. I don't know about Kyle's and Olivier's plans in details, >> but as long as you have precise memory management (hint, hint ...) you >> can just dump out a heap image and mmap it back in. This can even be >> done in such a way as to create architecture-independent heap images. >> I wrote code to do that for Scheme 48 which should show up in one of >> the next releases. Andy> I personally don't like this solution. It assumes you have mmap and surely Andy> also has the problem that native windows suffers from that the memory has Andy> to be mapped back in at a specific address. This causes dll conflicts in Andy> windows. Neither is true. The worst that can happen is that you actually have to read the heap image, which means that this portion of memory (unless there's something other than mmap which allows you to fiddle with the pager) cannot be shared between concurrent invocations of XEmacs. Also, as long as you have precise memory management, you can relocate. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Well, now we know where half of Steve's bloat came from! > > Seriously, what denominator did you have in mind for that 50%? In recent 21.2's the lrecord header overhead is sizeof(long). That means the size of a cons cell goes from 2*sizeof(long) to 3*sizeof(long). (it used to be even more). Jan

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Michael Sperber

>>>>> "mt" == Marcus Thiessel <marcus(a)xemacs.org> writes: mt> SL Baur writes: >> I now suspect dumping. I hate dumping, I hate it, I hate it, I hate >> it, I hate it. Why must we do something so stupid? mt> The question is what are the alternatives? Are there any at all? Absolutely. I don't know about Kyle's and Olivier's plans in details, but as long as you have precise memory management (hint, hint ...) you can just dump out a heap image and mmap it back in. This can even be done in such a way as to create architecture-independent heap images. I wrote code to do that for Scheme 48 which should show up in one of the next releases. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

Michael Sperber

>>>>> "Robert" == Robert Pluim <rpluim(a)bigfoot.com> writes: Robert> SL Baur writes: >> I now suspect dumping. I hate dumping, I hate it, I hate it, I hate >> it, I hate it. Why must we do something so stupid? Robert> Here's a (possibly insane) suggestion: rather than dumping, why don't Robert> we compile the lisp files to C? We could then make select portions Robert> dynamically loadable, and remove all that unportable dumping code. This would not solve the problem: The dumped image does not just contain code, it contains a good amount of state as well. Robert> Does this sound feasible, or have I been getting too little sleep Robert> lately? It's feasible, but it would probably not get you much benefit. Besides, I doubt there's anyone around to actually do it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: XEmacs has just (more than) doubled in size 25 years, 3 months

SL Baur

Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: > Andy Piper <andy(a)xemacs.org> wrote: >> At 05:05 PM 8/18/99 +0900, SL Baur wrote: >> >Comparative output from size is: >> >$ size src/xemacs* >> > text data bss dec hex filename >> >2384350 3030336 0 5414686 529f1e src/xemacs >> >2063120 3035984 0 5099104 4dce60 src/xemacs.RUNNING >> >> These numbers don't add up do they? I blame gcc :) > As these sizes are comparable, but the file sizes aren't, I'd > suspect the compiler/linker for bloating the debugging info (which > generally aren't symbols, and aren't part of the nm output). I now suspect dumping. I hate dumping, I hate it, I hate it, I hate it, I hate it. Why must we do something so stupid? > Perhaps something is adding duplicate debugging info. I've seen > this happen in a non-gcc compiler, with no apparent symptoms other > than a bloated file size; the executable worked, debuggers worked, > but the file size was bloated. Compare: $ ll src/xemacs* -rwxrwxrwx 1 steve 23688 8691296 Aug 19 10:33 src/xemacs -rwxrwxrwx 1 steve 23688 18546704 Aug 18 14:51 src/xemacs.BLOATED -rwxrwxrwx 1 steve 23688 8690616 Aug 16 15:01 src/xemacs.RUNNING These are all cvs snapshots from minutes before the timestamp. The difference between the Aug 18 binary and the Aug 19 binary is that I just ran `cvs update; ./config.status --recheck; make clean; make' a few minutes ago. What does this message mean? And why did I get an XEmacs anyway? Dumping under the name xemacs unexec(): dldump(/usr/local/devel/miho-optimized/src/xemacs): ld.so.1: ./temacs: fatal: /usr/local/devel/miho-optimized/src/xemacs: unknown dynamic entry: 1879048176

4 participants
3 comments

core dumped 25 years, 3 months

Alexey V. Barancev

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 "Demeter" [Lucid] (i686-unknown-linux) of Thu May 6 1999 on dallas.kazbek.ispras.ru configured using `configure i686-unknown-linux' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: 1. XEmacs was started with command xemacs -unmapped -f gnuserv-start & gnuclient 2. In client window Gnus started with command M-x gnus 3. Working with Gnus in summary buffer 'Space' clicked and XEmacs dumped core with message Fatal error: assertion failed, file insdel.c, line 1117, ( retval) >= BI_BUF_BEG (buf) && retval <= BI_BUF_Z (buf) Fatal error (6). ... Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) 4. gdb backtrace Core was generated by `xemacs -unmapped -f gnuserv-start'. Program terminated with signal 6, Aborted. ... #0 0x4024c811 in __kill () (gdb) where #0 0x4024c811 in __kill () #1 0x8086e31 in fatal_error_signal (sig=6) at emacs.c:269 #2 <signal handler called> #3 0x4024c811 in __kill () #4 0x4024d84f in abort () at ../sysdeps/generic/abort.c:83 #5 0x8086d98 in fatal_error_signal (sig=136183130) at emacs.c:2649 #6 0x810b1b6 in bufpos_to_bytind (buf=0x8afa6b0, x=25) at insdel.c:1117 #7 0x80ca267 in report_extent_modification (buffer=145729200, start=1, end=25, inside=0x82da02c, afterp=1) at extents.c:2275 #8 0x8107be0 in signal_after_change (buf=0x8afa6b0, start=1, orig_end=1, new_end=25) at insdel.c:2298 #9 0x8108dc7 in buffer_insert_string_1 (buf=0x8afa6b0, pos=1, nonreloc=0xbffff5b8 "423 Bad article number\r\n\002", reloc=137381116, offset=0, length=24, flags=0) at insdel.c:2571 #10 0x810b7ab in buffer_insert_raw_string_1 (buf=0x8afa6b0, pos=-1, nonreloc=0xbffff5b8 "423 Bad article number\r\n\002", length=24, flags=0) at insdel.c:2591 #11 0x812b51c in read_process_output (proc=144288224) at process.c:906 #12 0x80bc216 in execute_internal_event (event=139668864) at event-stream.c:2962 #13 0x80bf6f3 in Fdispatch_event (event=139668864) at event-stream.c:4689 #14 0x806c6f9 in Fcommand_loop_1 () at cmdloop.c:578 #15 0x806c931 in command_loop_1 (dummy=137381116) at cmdloop.c:493 #16 0x8089a0b in condition_case_1 (handlers=137381228, bfun=0x806c8e6 <command_loop_1>, barg=137381116, hfun=0x806c985 <cmd_error>, harg=137381116) at eval.c:1640 #17 0x806ca52 in command_loop_2 (dummy=137381116) at cmdloop.c:255 #18 0x8090550 in internal_catch (tag=137455852, func=0x806ca20 <command_loop_2>, arg=137381116, threw=0x0) at eval.c:1315 #19 0x806bd85 in initial_command_loop (load_me=137381116) at cmdloop.c:304 #20 0x8085320 in sort_args (argc=4, argv=0xbffffcdc) at emacs.c:1736 #21 0x8085a44 in Fkill_emacs (arg=4) at emacs.c:2165 Recent keystrokes: misc-user Recent messages (most recent first): Parsing /localhome/alexey/.mailrc... Loading filladapt...done Loading filladapt... Loading emacsbug...done Loading emacsbug... Loading gnuserv...done Loading gnuserv... Paren mode is paren Loading gnus-xmas...done Loading gnus-xmas...

1 participants
0 comments

Re: Latest 21.2 fails under Solaris 2.5.1/X11R5 25 years, 3 months

Andy Piper

At 12:14 PM 8/18/99 -0700, Damon Lipparelli wrote: >Starting with the earliest gutter changes, I haven't been able to either >build or run XEmacs under Solaris 2.5.1 and X11R5. If I re-configure and >build under Solaris 2.6 and X11R6, things are fine. > >After the build completed, I ran "src/xemacs -q". An XEmacs window popped >up, but disappeared quickly. The attached was spewed out in the xterm I ran >in. > >Is X11R5 (or Solaris 2.5.1) outdated? Is anyone else seeing problems with >this configuration? The backtrace looks bizarre. What does a stacktrace give you? It has to be a widget problem but I don't see why. Why has the infinite spin gone away? Please try configuring with full error checking and without workshop support. If this doesn't work try turning off widget support. Can you try something other than gcc 2.95? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

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 August 1999