March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: `scroll-up-command' still broken in 21.2 under AIX 24 years, 8 months

Michael Sperber

>>>>> "Markus" == altmark <altmark(a)de.ibm.com> writes: Markus> I still have that very annoying scrolling misbehaviour in 21.2 that I Markus> reported a while ago: Markus> http://www.xemacs.org/list-archives/xemacs-beta/199911/msg00262.html Markus> Unfortunately, there has been almost no response and I haven't found any Markus> solution for this - `scroll-up' hasn't worked for me in any beta since Markus> 21.2.19 under AIX 4.3.2, although it's ok on Linux. I assume there aren't Markus> too many guys out there on AIX, but am I the only one seeing this? If no, Markus> perhaps there's really something broken; if yes, what am I doing wrong? Markus> (`scroll-down' works and neither configuring `--with-scrollbars=athena' nor Markus> '--with-scrollbars=no' helps here). I don't see it. Does the problem show up with 21.1? With the 21.1 binary kit? You're running X11.base.lib>=4.3.2.5, right? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Fully featured pdump installation support 24 years, 8 months

Martin Buchholz

>>>>> "JV" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >> xemacs -dumped-data=my.dmp JV> Where does "redump on package install" fit in this scenario (note that JV> the user and the package installer are typically not the same person). JV> Preferably with the "don't modify the binary" reduction. Currently, because the packages have been separated out, the xemacs binary doesn't depend on the packages at all. This is actually one of the nicest things about the package system. When packages are upgraded, the xemacsen that work with those packages won't be updated in general, and there may be multiple such xemacsen (typically --with-mule, --without-mule, stable, bleeding-edge, gui, non-gui, etc...) So I recommend against `redump on package install', at least for now. There should be other ways of making package autoload loading at startup faster. If a user has built their own dumped data which includes elisp from packages, they will have to redump. And you can't automate this.

1 participants
0 comments

[CRASH] 21.2.31 GC bug? 24 years, 8 months

Yoshiki Hayashi

I forgot to send this yesterday. I was using SKK. It seems I hit C-SPC when it crashed. I don't think I did something special. I cannot reproduce this. When the crash occured, xemacs/src/CVS/Entries says: /ChangeLog/1.154.2.480/Fri Mar 3 07:24:57 2000//Trelease-21-2 uname -a: Linux buck 2.2.14 #3 Fri Feb 18 04:41:21 JST 2000 i686 unknown ./configure '--prefix=/opt/local' '--with-mule' XEmacs 21.2-b31 "Iris" configured for `i686-pc-linux'. Where should the build process find the source code? /src/xemacs What installation prefix should install use? /opt/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? no What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Athena library to link: Xaw Athena header include path: X11/Xaw Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Enlightened Sound Daemon (ESD). Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in dynamic shared object module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- Yoshiki Hayashi

2 participants
1 comments

Re: A real database for Emacs 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > SL Baur <steve(a)beopen.com> writes: > > > > 1. Can we have this as a module pleeeze? > > > > Is the module code stable now? > > Yes. ? Since when? The module code has _never_ ever been stable, nor has it ever been used for anything other than testing. The modules have been broken (and in some cases fixed later) by many changes some of which are still ongoing, like the portable dumper.

1 participants
0 comments

Re: XEmacs slows down like hell 24 years, 8 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> It's certainly possible that our lisp allocation bookkeeping is Martin> somehow broken. However... Martin> It is clear that the cost of one gc should be proportional to the Martin> amount of lisp storage allocated. If many elisp libraries are loaded, Martin> then there will be more lisp storage in the form of bytecode Martin> functions. But if a huge amount of lisp storage is allocated and Martin> subsequently freed, gc should not be much slower afterwards. Are you telling me GC may account for >50% of the running time of XEmacs? (Of course, the benchmark I posted is biased towards GC, but a slowdown of 2 feels about right.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: XEmacs slows down like hell 24 years, 8 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: MS> :-) Also, we really want a moving GC, so we need more GCPRO information. Martin> Unclear. It is _traditionally_ thought that a compacting collector Martin> wins. For a dissenting opinion, read Martin> http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html Yeah, well, note the precondition he's listing: Hans> It is however our experience that in single-threaded Hans> environments with moderately long-lived objects garbage Hans> collection time generally dominates allocation time, even with Hans> noncontiguous free memory. This is true for most pure C and C++ programs where allocation is painful and therefore rare. Not so for Lisp and other more dynamic environments. For a dissenting oppinion on *that*, along with some hard data to back it up against Boehm's collector, see: http://www.cs.cornell.edu/talc/papers/mcc-ismm-abstract.html Martin> Practically, I think it's too difficult to do a moving collector for Martin> XEmacs. Too many gc bugs to track down! You are welcome to prove me Martin> wrong, but be prepared to fix all the gc bugs yourself. This is a two-sided coin: A copying GC also gives you debugging tools you can't have with non-copying GC. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Intent to implement Emacs 20 find-file-literally 24 years, 8 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> It will work without the EFS part. It would be OK to sync things with Jan> a new EFS release, but 7 months is a bit too much of delay. I know, I know. I *have* started rolling on the next release, at least. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: A real database for Emacs 24 years, 8 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > I suggest taking a look at the DBI interface in Perl and Python. > DBI has been quite successful - there's even been a recent book > published on it. Our DB interface should be agnostic about the > precise database being connected to. We have a namespace problem there. Both Perl and Python solve this using OOP. We could do something similar using a generic API like our database stuff does. But it may not be easy. Also, there are philosophical differences between Perl and Python DBI's. I'll write about it in a later message.

1 participants
0 comments

Re: [CRASH] 21.2.31 GC bug? 24 years, 8 months

Hrvoje Niksic

Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: > I was using SKK. It seems I hit C-SPC when it crashed. I don't > think I did something special. I cannot reproduce this. > (gdb) set height 0 > (gdb) bt > #0 0x403e3911 in kill () from /lib/libc.so.6 > #1 0x808f01d in fatal_error_signal (sig=11) at emacs.c:272 > #2 0x403e3848 in sigaction () from /lib/libc.so.6 > #3 0x808bc3f in mark_hash_table (obj=141090416) at elhash.c:212 > #4 0x8054872 in mark_object (obj=141090416) at alloc.c:2519 > #5 0x808bc4b in mark_hash_table (obj=137160128) at elhash.c:213 > #6 0x8054872 in mark_object (obj=137160128) at alloc.c:2519 ... The reason for the crash is not apparent to me. At first it looked like a stack overflow caused by infinite recursion, but analysis of the stack trace shows that there is no infinite recursion, because there are no duplicates.

1 participants
0 comments

Re: Make gutter redisplay less aggressive 24 years, 8 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > >The window-change-related flicker is still there. The worst > >offenders are still: > > > >* Frame change, using the WM. > > > >* Window change, using C-TAB. > > > >* Gnus. Many things in Gnus. For instance, displaying an article, > > scrolling down by page (SPC in the summary buffer), scrolling down > > by line (RET in the summary buffer), etc. > > I think these are related to the output code. Is there anything you can do? I guess the frame and window change flicker could be ignored, but the Gnus flicker makes buffer tabs unbearable.

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