August 2000 - XEmacs-Beta - XEmacs Mailing List Archives

progress gauge weirdness 23 years, 7 months

Jeff Miller

cvs updated the latest beta about an hour ago... no i have a vm session going, and at one point the progress gauge came up (fontifying) now I'm left with some odd remnants of the gauge as shown in the attachment this is redhat linux 6.1, pretty much just did a ./configure Jeff

4 participants
12 comments

Widget design [was: Should --with-widgets be the default?] 23 years, 7 months

Stephen J. Turnbull

Moved to -beta because this is general design discussion. >>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 07:36 PM 8/23/00 +0900, Stephen J. Turnbull wrote: >> xemacs -vanilla followed by repeated `C-x 2's allows me >> to produce as many tab control widgets as I want, all >> instantiated for the *scratch* buffer. That can't be right. >> Nor do they go away when I start coalescing the windows. Andy> No that *is* correct. See [*] below. Andy> You are creating lots of different domains (windows) and Andy> there has to be a control for each. If you go back to one Andy> window and garbage collect they should go away eventually. This was not true under the pre-(sel.patch) setup, and I banged on that for quite a while. The only thing that ever made them go away was destroying the whole frame. They now go away immediately (with http://www.xemacs.org/list-archives/xemacs-patches/ ... ach, not there yet, look for Andy's patches dated 8/23 and subjects "Re: new dialogs: bug" and "Re: Tab selection crash fix ... NOT!! \"Houston, we, uh, crashed.\"") ***** [*] You are defining "correct" as "works as designed." That is important, of course, but I think that the design is making a lot of assumptions that probably will turn out to be not true for some applications. This will result in more bugs in the future. Above you _equate_ domains to windows. But for the tab control, that's wrong. The domain most relevant to a tab control is a set of buffers. It is true that most of the time the buffer-set to window correspondence is one-to-one and pretty stable. Furthermore, the most likely application (and the one currently implemented) for the tab control is to switch among buffers in a set in a given window. So for the buffer tabs application, this assumption is plausible. But it's wasteful; I don't see any reason at all why a frame should have more than one buffer tabs widget when only one will ever be displayed at a time. It seems to me that from the point of view of Emacs a glyph is really a three-level object. The top level is a specifier, ie, a mapping from domains to instantiation methods. The middle level is the instantiation method for a given domain. The bottom level is the on-screen realization. For a character glyph, the top layers are trivial (ignoring the complexity of faces). For each domain, the instantiation method is to pass the character on. So in the domain, you simply pass the character to the display. The display looks up the bitmap in a font, and blits it to the screen. No computation and no caches needed for handling this kind of glyph. (The display is a black box, I am deliberately abstracting from it here.) For a pixmap glyph from a PNG file, things are somewhat more complex. The top level basically has to decide whether the domain handles pixmaps or not. If it does, it passes the file name to the instantiation method. The method then does some expensive i/o, decodes the pixmap in memory, and passes the pixmap to the display, which then blits it to the screen. Here, the i/o and decoding are expensive, as is passing the pixmap itself (in X11 anyway, as this may involve a fairly large network transaction). So there are two opportunities for caching here, one at the display level, and one of the decoded pixmap. AFAIK we actually have the X server cache the pixmap, and when this image is gc-ed, we call XFreePixmap on the pixmap. Now, we could do exactly the same thing with a widget glyph. No? However, we do want to be more efficient than that. First, let's define a `widget glyph' to be a glyph from the point of view of XEmacs. It is a Lisp object. On the other hand, a `ws-widget' is a toolkit object. There are three differences between widget glyphs and image glyphs that I can see. (1) The entity that handles the ws-widget for us is the toolkit, rather than the display server for the pixmap. Just a different level of black box. (2) ws-widgets are "alive". This means that, unlike pixmaps, we can't just paint over their displayed image; we need to keep track of whether a ws-widget is supposed to be displayed or not, and deactivate is if not. (Of course, we should and do clean up pixmaps too. Otherwise you get those obnoxious birdturds like when font metrics are hosed. But pixmaps don't eat CPU and cause flicker and all that ugliness.) As far as I can see this has no direct implications for caching. (3) A ws-widget is, from our point of view, its own screen image. That means that a widget glyph that is displayed in multiple places in the same domain needs to use multiple ws-widgets. By contrast, we can XCopyArea (or its equivalent for other WSes) an X Pixmap freely. (4) ws-widgets are much heavier objects than even pixmaps. So we would like to avoid creating and destroying them. The question is "how many do we need?" The answer is, typically, "as many as are being displayed at one time in the window system parent." (3) means we need at least that many. But we usually don't need any more, because widgets can be moved about and their features changed as necessary. (3) and (4) together imply that free'd ws-widgets ought to be cached. But they should be cached by the object that determines the restrictions on moving them. In general, this is the window system parent, or, actually the Lisp object that manages that object. (I guess they could even be reparented, but that's a can of worms I'd rather not open. Although I guess if we want to embed an instance of say xanim in an XEmacs buffer, we would need to do exactly that.) In this case, the Emacs frame, not the Emacs window. Of course, if there are other expensive operations to conduct on ws-widgets that would be entailed by using the same ws-widget in multiple domains, the caching strategy should take that into account. But I can't see any that would be forced simply by having two different Emacs windows in the same Emacs frame. In particular, for both the progress gauge and the buffers tab control, they live in the gutter, which is part of the frame, not any particular window. It seems to me that what should happen is that you create a (Lisp) buffers tab control, it instantiates a (ws-widget) tab control for the frame in the gutter, with callbacks to change buffers when it is activated. The same operation should install a Lisp function on some `buffer-configuration-change-hook' which informs the ws-widget about the new set of relevant buffers and the active one. The Lisp tab control object maintains enough state to reinitialize the ws-widget tab control when the Lisp object wants to display itself. I don't see any reason for the tab widget, either the Lisp object or the ws-widget, to know or care about the Emacs window configuration. BTW, some things I find disconcerting about the current behavior: (1) If two buffers in the same mode are displayed simultaneously in the same frame, then using the tab to switch buffers switches windows, not buffers in the current window. This behavior makes sense for the keystroke equivalent, but if I'm moving the mouse anyway click-to- focus makes more sense than using the tab control. If I use the tab control I expect the buffer to end up in the top window. (2) Splitting windows horizontally does _not_ increase the number of tab controls (but seems to work fine). Coalesing horizontally split windows doesn't decrease the number of tab controls, either. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
3 comments

Re: -no-autoloads broken in 21.2.35 --pdump 23 years, 7 months

Gunnar Evermann

"Stephen J. Turnbull" <stephen(a)xemacs.org> writes: > bash-2.04$ src/xemacs -no-autoloads -batch -eval "(princ (featurep 'lisp-autoloads))" > t > bash-2.04$ I reported this some time ago and explained the cause. See message <87k8dna3ma.fsf(a)eng.cam.ac.uk> on xemacs-beta. I was hoping Olvier could come up with a fix. Gunnar

2 participants
2 comments

Re: Fix SunOS 4.1.4 build problems 23 years, 7 months

Matt Curtin

>>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: Charles> Who on Earth is still using R4? Who on Earth is still using SunOS 4.1.4? :-) -- Matt Curtin cmcurtin(a)interhack.net http://www.interhack.net/people/cmcurtin/

1 participants
0 comments

Fix SunOS 4.1.4 build problems 23 years, 7 months

Charles G Waldman

Martin Buchholz writes: > Not for 21.1. > > * configure.in: with_widgets is incompatible with X11 R4. Geez, it's a long time since I worked with a SunOS 4.1.[34] system, but as I recall they came with at least X11R5. Who on Earth is still using R4?

2 participants
1 comments

configure changes (shared libs)? 23 years, 7 months

John A. Turner

after many successful builds of 21.2 betas on Irix, I'm suddenly having probs during configure basically, it stalls here: checking how to build dynamic libraries for mips-sgi-irix6.5 checking how to produce PIC code... none checking if C compiler can produce shared libraries... even worse, when I C-c out of it, it leaves behind a seemingly unkillable process (even kill -9 as root!): denmark 7# ps -ef | grep cmplrs | grep -v grep turner 4326 1 0 19:12:46 pts/4 0:00 /usr/bin/../../usr/lib32/cmplrs/ld32 -DEFAULT:abi=n32:isa=mips4:proc=r10k -shar denmark 8# kill -9 4326 denmark 9# ps -ef | grep cmplrs | grep -v grep turner 4326 1 0 19:12:46 pts/4 0:00 /usr/bin/../../usr/lib32/cmplrs/ld32 -DEFAULT:abi=n32:isa=mips4:proc=r10k -shar and although this process doesn't seem to be using CPU, the load shoots to 1 and stays there frustratingly, cvs log on configure shows this as the last change: ---------------------------- revision 1.140 date: 2000/08/04 02:49:54; author: vins; state: Exp; lines: +84 -80 Re-worked NAS fix. zmacs-region-stays documentation update. Martin's patch to save errno when reporting fork errors. ---------------------------- and I know I updated and built since then (not more than a week ago) - so does that mean there's been some change to the compilers or OS on my machine (I'm going to check into that), or are there changes other than to configure that could be responsible? fwiw, my configure line looks like this: ./configure \ --verbose \ --prefix=/u/turner/Tools \ --exec-prefix=/u/turner/Tools/IRIX \ --package-path=/u/turner/Tools/lib/xemacs \ --site-includes=/u/turner/Tools/IRIX/include \ --site-libraries=/u/turner/Tools/IRIX/lib \ --debug=no \ --error-checking=none \ --cflags="-g -O2 -mabi=n32" -- John A. Turner, Ph.D. Senior Research Associate Blue Sky Studios, 44 S. Broadway, White Plains, NY 10601 http://www.blueskystudios.com/ (914) 259-6319

2 participants
2 comments

gtk-xemacs wedged 23 years, 7 months

Neal D. Becker

After using gnuclient to connect with no windows to my running gtk-xemacs, hitting a couple of C-G caused a wedge, eating CPU. gdb says: (gdb) where #0 0x4061fad4 in __libc_read () from /lib/libc.so.6 #1 0x406691ec in __DTOR_END__ () from /lib/libc.so.6 #2 0x405ce951 in _IO_new_file_underflow (fp=0x406678c0) at fileops.c:385 #3 0x405d08a1 in _IO_default_uflow (fp=0x406678c0) at genops.c:371 #4 0x405cfd0c in __uflow (fp=0x406678c0) at genops.c:328 #5 0x405cd066 in _IO_getc (fp=0x406678c0) at getc.c:39 #6 0x81454e4 in interrupt_signal (sig=2) at /usr/local/src/gtk-xemacs/src/signal.c:427 #7 <signal handler called> #8 0x807db7c in compact_string_chars () at /usr/local/src/gtk-xemacs/src/alloc.c:4062 #9 0x807e89b in garbage_collect_1 () at /usr/local/src/gtk-xemacs/src/alloc.c:4260 #10 0x80a533f in funcall_recording_as (recorded_as=137118144, nargs=2, args=0xbffff7e4) at /usr/local/src/gtk-xemacs/src/eval.c:3114 #11 0x80a8b72 in call1 (fn=137118144, arg0=137025980) at /usr/local/src/gtk-xemacs/src/eval.c:3238 #12 0x80dfb8c in execute_internal_event (event=149995376) at /usr/local/src/gtk-xemacs/src/event-stream.c:2953 #13 0x80e157d in Fdispatch_event (event=149995376) at /usr/local/src/gtk-xemacs/src/event-stream.c:4690 #14 0x808d192 in Fcommand_loop_1 () at /usr/local/src/gtk-xemacs/src/cmdloop.c:579 ---Type <return> to continue, or q <return> to quit--- #15 0x808d395 in command_loop_1 (dummy=137025980) at /usr/local/src/gtk-xemacs/src/cmdloop.c:494 #16 0x80a9692 in condition_case_1 (handlers=137026092, bfun=0x808d37c <command_loop_1>, barg=137025980, hfun=0x808d408 <cmd_error>, harg=137025980) at /usr/local/src/gtk-xemacs/src/eval.c:1653 #17 0x808d4e1 in command_loop_2 (dummy=137025980) at /usr/local/src/gtk-xemacs/src/cmdloop.c:256 #18 0x80a9560 in internal_catch (tag=137100268, func=0x808d4bc <command_loop_2>, arg=137025980, threw=0x0) at /usr/local/src/gtk-xemacs/src/eval.c:1328 #19 0x808ce9e in initial_command_loop (load_me=137025980) at /usr/local/src/gtk-xemacs/src/cmdloop.c:305 #20 0x80a0a8d in xemacs_21_1_11_i686_pc_linux () at /usr/local/src/gtk-xemacs/src/emacs.c:1797 #21 0x80a2264 in main (argc=1, argv=0xbffffc04, envp=0xbffffc0c) at /usr/local/src/gtk-xemacs/src/emacs.c:2214 #22 0x405919cb in __libc_start_main (main=0x80a215c <main>, argc=1, argv=0xbffffc04, init=0x8078444 <_init>, fini=0x81621b8 <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffbfc) at ../sysdeps/generic/libc-start.c:92 (gdb) It almost looks from this that it should just be waiting for input, but it's eating 97% CPU.

1 participants
0 comments

Re: Xemacs 21.1.12 build problems 23 years, 7 months

Alexandre Oliva

On Aug 13, 2000, Gunnar Evermann <ge204(a)eng.cam.ac.uk> wrote: > many thanks for your report and the patch. Unfortunately, it seems that the patch was not enough for XEmacs 21.1.12 to work reliably on HP-UX 10.20. It still crashes too often while byte-compiling random stuff: Fatal error: assertion failed, file event-tty.c, line 145, c > You might want to send such reports to xemacs-beta(a)xemacs.org in the > future. This will reach the developers more reliably. Thanks, I'll try to keep it in mind :-) > xemacs(a)xemacs.org is gatewayed to comp.emacs.xemacs and is mostly used > for user queries, mostly from users who are rather clueless. This does > definitely not apply to you! :-) :-) Thanks, > I've forwarde your two messages for now. I'll try to test a build on > HPUX10.20 (building vanilla 21.1.9 worked fine) Yep, I think 21.1.10 used to work fine too. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva(a){cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me

2 participants
1 comments

Re: ["Epstein, Evan" <EEpstein@NOVATELECOM.com>] building and installing xemacs 23 years, 7 months

John S. J. Anderson

(Keeping xemacs-beta in the loop as I'm not sure this is a correct answer.) Steve Youngs <youngs(a)xemacs.org> writes: > I don't know the first thing about Solaris, wouldn't know it if I fell > over it. Anybody here able to help this guy out? > > From: "Epstein, Evan" <EEpstein(a)NOVATELECOM.com> > To: "'webmaster(a)xemacs.org'" <webmaster(a)xemacs.org> > Subject: building and installing xemacs > Date: Wed Aug 30 14:39:30 2000 -0400 > > I tried to install xemacs on my system. I am running Solaris 8 on a ultra > 60 > I followed the instructions with 1 difference, I do not have root priveleges > and I invoked configure with the --prefix option giving it a directory. > > This results in an execuatable of xemacs with a dull grey screen, > strange looking buttons and some unstable behavior. > > Do I need to do somthing to install it as a regular user? Assuming you did follow through and install the packages, everything should be working. When I built XEmacs on Solaris, I had to play with configure a bit to get it to find all the libraries. I bet if you check the output of ./configure, you'll find that the XPM library didn't get located. Make sure you give all the needed include and library paths, and see if that fixes the problem. john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ <URL:http://www.xemacs.org> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

1 participants
0 comments

xemacs.spec 23 years, 7 months

Charles G Waldman

Who has the `.spec' file for building an RPM distribution of XEmacs? I know we've distributed RPM's in the past. Shouldn't it really be part of the xemacs sources, in etc or somewhere? Like the Windows installer stuff?

3 participants
2 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 2000