January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: "Symbol X has different size in shared object" bug reappears 24 years, 10 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > On non-Linux platforms, we build XEmacs using a runpath that is > computed from the link path. [...] > I've generally felt that we should be doing this even on platforms > like Linux where /etc/ld.so.conf gives us the runtime library search > path. However, Steve was strong in his insistence that we don't > specify a run-path via -R, and that we let /etc/ld.so.conf win out. I agree with your view -- in fact, I was the one who bitched about the problem under Solaris which I used at the time. However, Steve's technical argument against this method was that Linux makes use of ld.so.conf to ensure old versions of executables for libraries that need them. This way a libc5 program "knows" that old libraries are in a "libc5-compat" directory. If we hardcode the runtime library path into the executable, we lose that capability, don't we?

4 participants
4 comments

Re: [Crash] segv, key_matches_specifier_p, popup menu in Gnus/Tm 24 years, 10 months

Karl M. Hegbloom

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> karlheg(a)bittersweet.inetarena.com (Karl M. Hegbloom) writes: >> When I sent a SIGINT, with the top submenu open, it blonked, >> popped down just the submenu, and printed an error message >> about wto, character-p, the name of the menu item. (It's the >> same error I get when I try to use keyboard shortcuts for >> menus. Did I report that one yet? I cannot recall.) Jan> Does typing C-g help (instead of the SIGINT)? The popup menu Jan> lisp interface is fairly ugly, so it could be that the lisp Jan> code behind the menu is not catching things correctly. I Jan> fixed a few such bugs before. I am trying to distinguish that Jan> case from a real hang in the C part. C-g did nothing, that's why I resorted to sending a SIGINT.

1 participants
0 comments

dialogs not OK yet 24 years, 10 months

Giacomo Boffi

latest cvs, configured with --with-xaw=3d, when i enter a dialog box sometimes i receive a (generalized) random char in the minibuffer, that looks like a prefix, e.g., "up -" i have debug-on-error raised, but no error was signalled i checked the "*Help: lossage*" buffer, too, to find that the spourios character were not transcribed there here it is my "Installation", ciao ------------------------------------------------------------------------ uname -a: Linux boffi95.stru.polimi.it 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown ./configure '--with-athena=3d' '--error-checking=none' XEmacs 21.2-b26 "Millenium" configured for `i586-pc-linux'. Where should the build process find the source code? /home/jim/src/xemacs What installation prefix should install use? /usr/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 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? yes 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: Xaw3d Athena header include path: X11/Xaw3d 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 Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena native widgets. Using Athena 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.

1 participants
0 comments

New Sumo Tarballs of packages uploaded 24 years, 10 months

Andreas Jaeger

I've uploaded a number of new packages and corresponding tarballs to ftp.xemacs.org/pub/xemacs/packages. Major updates: - texinfo synch with Emacs 20.5 - calendar synch with Emacs 20.5. - reftex version 4.10 - new package idlwave for IDL mode Minor updates: - bugfix for egg-its when inputing from the modeline. - small mule-base problem fixed (mule-debug isn't included but leaked into autoloads) - TUTORIAL.ja has been removed from mule-base, the core contains the version already. - moved mailheader from package gnus to package mail-lib for usage of Gnus 5.8.x. - fixed a Y2K bug in vc - Added kfm support to browse-url (package mail-lib) - Fix bookmark-completing-read (package edit-utils) - documentation update for read-passwd (package xemacs-base) - timezone now handles year 69 as 1969 (package xemacs-base) - set-annotation-glyph was fixed (package xemacs-base) - fixed type of add-log-current-defun-function (package xemacs-base) - moved regexp-opt from package xemacs-devel to xemacs-base. This fixes a bug where e.g. make-mode needed xemacs-devel. The uploaded packages are: - texinfo-1.17-pkg.tar.gz - calendar-1.14-pkg.tar.gz - reftex-1.16-pkg.tar.gz - egg-its-1.22-pkg.tar.gz - mule-base-1.34-pkg.tar.gz - mail-lib-1.27-pkg.tar.gz - vc-1.21-pkg.tar.gz - edit-utils-1.43-pkg.tar.gz - gnus-1.44-pkg.tar.gz - xemacs-base-1.35-pkg.tar.gz - idlwave-1.0-pkg.tar.gz - xemacs-devel-1.25-pkg.tar.gz The tarballs are named: xemacs-mule-sumo-2000-01-15.tar.gz xemacs-sumo-2000-01-15.tar.gz and contain: xemacs-mule-sumo: Packages only needed if you're using Mule. xemacs-sumo: All other packages. What is _not_ in there (yet): - New version of cperl-mode (volunteer needed) - pgml 1.2.x (volunteer needed) - vcursor.el - Gnus 5.8.x (wait for higher .x?/Volunteer needed) - Your favorite package that you always use your own copy from FSF 20.4/20.5/pre-releease for instead of our version (volunteer needed) - AucTex 9.9 (Soren Dayton volunteered) - latest ilisp (server unavailable/volunteer need) - de roe. Feel free to send patches to update these to xemacs-patches(a)xemacs.org. Andreas P.S. I've sent an announcement out a few hours ago that I didn't upload the Sumos. This announcement supercedes the previous one since I've found time to make the tarballs. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Status of xemacs packages (2000-01-14) 24 years, 10 months

Andreas Jaeger

>>>>> Jan Vroonhof writes: Jan> Andreas Jaeger <aj(a)suse.de> writes: >> I can release tomorrow new packages - but will only do if they are ok. >> So far I've received only one report of a failure (appended below). I >> would appreciate if somebody could look into it and send a patch asap. Jan> Sorry. I don't have the time (preparing CV's and all that). However Jan> the global-flyspell-mode feature is depreciated by the flyspell Jan> maintainer. So maybe it is better to just revert the patch. I've reverted the patch for now with a comment and ask others to look into this. I've released the current packages now without that patch. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Tabs property fix 24 years, 10 months

Andy Piper

This patch fixes the problem where under athena the tabs font wouldn't get updated for the current frame. This is also my first e-mail sent from my Linux home system !! Offtopic: After a while my mouse seems to become very unresponsive. Has anyone seen this under Linux? Does anyone have any suggestions. andy 2000-01-15 Andy Piper <andy(a)xemacs.org> * lwlib-Xlw.c (lw_update_one_widget): make sure global properties gets set. Index: lwlib-Xlw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xlw.c,v retrieving revision 1.7.2.5 diff -u -r1.7.2.5 lwlib-Xlw.c --- lwlib-Xlw.c 1999/12/07 23:11:58 1.7.2.5 +++ lwlib-Xlw.c 2000/01/15 13:36:38 ＠＠ -536,6 +536,9 ＠＠ widget_value* val, Boolean deep_p) { WidgetClass class = XtClass (widget); + /* Update up global arg values. */ + if (val->args && val->args->nargs) + XtSetValues (widget, val->args->args, val->args->nargs); if (0) ;

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 10 months

Andreas Jaeger

>>>>> Martin Buchholz writes: > On non-Linux platforms, we build XEmacs using a runpath that is > computed from the link path. For example, we do this while linking: > -L/usr/local/lib -L/usr/ccs/lib > -Xlinker -R/usr/dt/lib:/usr/openwin/lib > -L/usr/dt/lib -L/usr/openwin/lib > (Note that there are no shared libs in /usr/local/lib or /usr/ccs/lib...) > On Solaris, this is essential, because the default runpath contains > only /usr/lib and not /usr/openwin/lib, so we could never build an > X-capable XEmacs. > I've generally felt that we should be doing this even on platforms > like Linux where /etc/ld.so.conf gives us the runtime library search > path. However, Steve was strong in his insistence that we don't > specify a run-path via -R, and that we let /etc/ld.so.conf win out. > I've never understood Steve's opinion on this, and claim that it's led > in part to the current Xaw3d disaster. > If we do the same thing on Linux, and link like this: > -L /usr/X11R6/lib -R /usr/X11R6/lib -L /usr/lib -R /usr/lib Just one note: /usr/lib and /lib are searched by default by the dynamic linker, it always look's there [1] > (syntax might differ) we would be guaranteed not to get surprised by a AFAIK -Wl,--rpath=/usr/X11R6/lib. > rogue Xaw.so which is actually a Xaw3d library, because our link path > and our run path would be the same. We can still lose if the system > is upgraded or the binary is transported to another system, but that > problem exists on every system. We should try it at least for those paths the user specifies as special Linkpath. Andreas Footnotes: [1] If you configured glibc with --prefix=/usr which is done with every distribution. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: 21.2.26 Gutter crash on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 09:38 AM 1/14/00 -0500, Raymond Toy wrote: >> Andy> Thanks for the good report Ray. I have an idea as to what is Andy> going on here, Andy> but I'm not sure how to fix it. Can you try running with the Andy> attached patch Andy> to see if it occurs again. >> >> Patch applied. Although I turned off gutters, I'll enable them again >> and let you know if anymore crashes happen. Andy> BTW the crash is happening when the previous tab gets unhilghted. If you Andy> knew what the previous top tab was it would help. Unfortunately not. I clicked on the tab, there was some disk activity that I thought was swapping so I went to do something else, and sometime later, I noticed my VM window was gone. :-( If this happens again, I'll try to remember what the tabs were. Would it be possible to get this info easily out of the core file? Ray

2 participants
1 comments

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

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > 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. I understand that code -- the plain `message' had the same problem, and I fixed it, with phone help from Ben. Basically the problem is that `error' repeatedly updates the echo area, which has at least two bad consequences. The code in question is in print_error_message(), the "Default method" part, the `while (!NILP (tail)) { ... }' part. The two bad consequences are: * print_internal() is called with STREAM, which is in this case the echo area. The echo area is updated immediately due to its nature. It would be nice if that code could somehow delay the echo area update. * The garbage collections you see are due to `append-message' (called by echo_area_append()) trying to keep the top of the message-stack in sync with the contents of the "*Echo Area*" buffer. So what happens is that these strings are created in succession: "t" "t: " "t: t" "t: t, " "t: t, t" ... When this happens many times with each string longer than the last one, it turns into a GC frenzy. This is all explained in my comment in print_prepare(). The fix that addresses both problem is to avoid direct printing to minibuffer altogether: instead, the code prints into a temporary resizing buffer stream. When the printing is done, the stream contents are dumped into minibuffer. This is how all high-level printing functions work -- except for Fdisplay_error. Given that the infrastructure (kludge) for doing this already exists in print_prepare(), the only fix needed is for print_error_message() to call print_prepare(). For me, this patch fixes the problem -- the printing is fast with 1000-element, 10000-element, etc. lists. Please let me know if it works for you. 2000-01-14 Hrvoje Niksic <hniksic(a)iskon.hr> * print.c (print_error_message): Call print_prepare(). --- src/print.c.orig Fri Jan 14 09:27:59 2000 +++ src/print.c Fri Jan 14 09:38:38 2000 ＠＠ -627,8 +627,13 ＠＠ { int first = 1; int speccount = specpdl_depth (); + Lisp_Object frame = Qnil; + struct gcpro gcpro1; + GCPRO1 (stream); specbind (Qprint_message_label, Qerror); + stream = print_prepare (stream, &frame); + tail = Fcdr (error_object); if (EQ (type, Qerror)) { ＠＠ -650,6 +655,8 ＠＠ tail = Fcdr (tail); first = 0; } + print_finish (stream, frame); + UNGCPRO; unbind_to (speccount, Qnil); return; /* not reached */

2 participants
1 comments

modeline hscroll 24 years, 10 months

Didier Verna

Hi, and happy new year to all ! I've just committed a patch to 21.2 that (re)implements the modeline horizontal scrolling facility. The lisp interface to the feature is composed of two functions: [set-]modeline-hscroll. One remaining issue is a possible user interface to the feature. Just to remind you of the discussion we had some time ago: I'd originally enabled clicking on the modeline and dragging it horizontally to scroll it. There were a debate on the sense the modeline should scroll: - the team who sees it as dragging the modeline itself: moving the mouse left shoud move the text left, - the team who sees it as dragging the viewport, or giving the direction text should appear (a la gv): moving the mouse left should move the text right. Obvioulsy, it is also possible to let people choose, to add arrows at both ends of the modeline (but the debate on the scrolling sense will still occur), and finally, people objected that it is not very practical to scroll the modeline with the mouse, as it also might resize the window if you move the mouse vertically. My current feeling is that simple key bindings should do it :-) Here's what I have right now in my init.el. We could provide similar functions in modeline.el. (global-set-key [(shift left)] (lambda () (interactive) (let ((w (selected-window))) (set-modeline-hscroll w (- (modeline-hscroll w) 1))))) (global-set-key [(shift right)] (lambda () (interactive) (let ((w (selected-window))) (set-modeline-hscroll w (+ (modeline-hscroll w) 1))))) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

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