XEmacs 21.4.0 "Solid Vapor" is released.
23 years, 7 months
Stephen J. Turnbull
Stephen J. Turnbull
* Xemacs 21.4.0 "Solid Vapor" is released.
Xemacs 21.4.0 contains a large number of improvements and extensions
to the current stable version, XEmacs 21.1.14, and continues the
policy of maintaining compatibility with the mainline GNU Emacs in the
Lisp programming language and packages. XEmacs 21.4.0 includes two
major new features:
o "Native widgets" are supported on windowing platforms ("plain"
X11, Motif, MS Windows, and GTK+). GUI components, as simple as
buttons or as complex as a MS Windows file selector, can be
incorporated in XEmacs user interfaces. The programming interface
treats them as a subtype of the primitive Lisp glyph type, the
fundamental API for handling images and displaying text in XEmacs.
o The GTK+ toolkit is supported for X11. This includes the GNOME
widget set and the advanced GUI design toolkit, libglade. GTK+ is
considered experimental in the 21.4 series, and will not be built
in by default. It is not yet fully integrated with the "native
widget" support, and improvements are constrained to minimize
impact on the rest of XEmacs. GTK+ is quite functional, but still
unstable, and developers interested in working on GTK+ support
probably should concentrate on the development series (version 21.5).
A few examples of other significant new features include:
o Extended database support, including improvements to the LDAP and
Berkeley DB support, and new wrappers for Postgresql and Berkeley
DB version 3.
o Support for EsounD.
o Better support for MS Windows, including printer support and a new
"net installer". Standard Windows-style installers (Wise and
Installshield) are planned for integration in 21.4.x updates.
For more information about user-visible changes, see etc/NEWS (the
definitive source), and the release page,
http://www.xemacs.org/Releases/Public-21.2/.
For general information about XEmacs, the developers, and the user
community, see our home page,
http://www.xemacs.org/.
* XEmacs 21.4.0 is "gamma" software.
Besides the usual "no warranty" disclaimer (see etc/WARRANTY, sections
10 and 11), we are now experimenting with a level of stability
intermediate between "beta" and "stable", dubbed "gamma". At this
point all the developers and most of our beta testers trust the 21.4
code base with all their editing needs. However, we recognize that
(a) these users are not fully representative of the user community,
(b) there is a "point oh" effect, and (c) there have been personnel
changes (not least, an inexperienced release manager). For all these
reasons, for users who absolutely must minimize risk, we continue to
recommend the 21.1 series.
However, almost users will get very high reliability from XEmacs 21.4,
and in return, access to many new features and improved functionality.
No new destabilizing code will be added; each release in the 21.4
series should be strictly more stable and bug-free than the preceding
one. We also recommend the 21.4 series to distribution packagers
(such as Linux distributions and the open source BSD "ports" or
"packages" maintainers) for their "testing" and "development"
distributions.
Since this is a new format, we don't have much directly relevant
experience. However, experience with past releases suggests that we
can hope to promote XEmacs 21.4 to "stable" status after about 6
weeks.
* Getting XEmacs 21.4.0
XEmacs 21.4.0 is available in source form, including pre-compiled
"core" Lisp libraries and pre-built Info files, from ftp.xemacs.org
and mirrors (http://www.xemacs.org/Download/index.html#mirror_index).
See
http://www.xemacs.org/Download/
for general information about downloading XEmacs. (It will be updated
to reflect the latest information about 21.4.0 shortly; our Webmaster
is taking a well-earned vacation.) For those wedded to their old
command-line FTP client, the following URLs may be useful:
ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.0.tar.gz
or build the Lisp and Info from source, saving download time, with
ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.0-src.tar.gz
In either case, you need the "packaged Lisp" for more than the most
basic functionality. You may use packages previously installed for
use with XEmacs 21.1 or later without change. For new installations,
the "SUMO" distribution of (almost) all packaged Lisp is available as
ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz
ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz
The latter should be installed only if you are building XEmacs with
the MULE multilingual support; it contains Lisp files that cannot be
correctly loaded by a unibyte XEmacs. See README.packages.
XEmacs 21.4.0 is also available via anonymous CVS. To get the latest
in the 21.4 series, check out (or update) with the "release-21-4"
tag. This should be sufficient for almost all users; from now on
patches will be carefully screened to ensure that every release is
more stable than the last. If for some reason you specifically want
the "point oh" release, use the "r21-4-0" tag.
See http://cvs.xemacs.org/ for general instructions on getting XEmacs
via anonymous CVS.
Binary kits are not available at this time, except for the MS Windows
platform. The "netinstaller" is available as
ftp://ftp.xemacs.org/pub/xemacs/windows/setup.exe
ftp://ftp.xemacs.org/pub/xemacs/windows/setup.ini
and will automatically fetch binaries and Lisp packages, and set up
your system. Since the netinstaller uses prebuilt binaries, it lags
the source release by a few days.
We are considering providing binary kits for important platforms that
lack independent distributors (a la the Linux "distributions" or the
FreeBSD "ports" maintainers) for at least some releases once 21.4 is
accepted as "stable". Volunteers should contact the Release Manager,
"Stephen Turnbull" <stephen(a)xemacs.org>, and let me know what
platforms you can build for.
* Important notice for CVS users:
The CVS Repository structure has been rationalized thanks to Michael
Sperber. The development code is now on the trunk. There are several
active branches, each with per-release tags of the form "r21-4-0"
(major-minor-patchlevel), and a branch tag which always gives the tip:
Branch Branch tag Release tag
Development trunk (21.5): none r21-5-xx
"Gamma" branch (21.4): release-21-4 r21-2-xx
Stable branch (21.1): release-21-1 r21-1-xx
The trunk has a special "moving" release tag, "r21-5-latest-beta".
This is updated with each release to reflect the most recent beta
release. (The Beta Release Maintainer makes some effort to ensure
that beta releases at least build; there is no way to make such a
guarantee for the tip of the trunk in our development model.)
N.B. Until a 21.5 beta is released, the trunk will show a version of
21.2.46 "Urania", because that is the last beta in the series. (cvs
diff'ing the trunk against Urania will show some differences, but
version.sh hasn't changed yet.) "r21-5-latest-beta" was initialized
to reflect this state of affairs.
There is no "moving" release tag for stable versions; just use "-r
release-21-1" if you need the current release of version 21.1, and "-r
release-21-4" for 21.4.
To update an existing CVS checkout to the trunk (development), use the
-A flag to cvs update, or simply cvs checkout with no -r flag. To
checkout or update to one of the other branches, use the -r flag with
the appropriate branch tag. http://cvs.xemacs.org/ has more
information. It is in the process of being updated, so some
information about tags may be inaccurate for a few days.
* Apologies
The targeted release date of March 1 was too aggressive, resulting in
6 weeks' delay. We hope you find it worth the wait.
No, I'm not using the latest and greatest XEmacs to write this. Next
time....
--
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."
- 1 participants
- 0 comments
Teensy tiny motif dialogs
23 years, 7 months
eric dahlman
eric dahlman
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 (beta46) "Urania" [Lucid] (sparc-sun-solaris2.8) of Tue Apr 10 2001 on sibelius
configured using `configure --prefix=/s/chopin/d/proj/meps/common'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
Confirmation dialogs take a few seconds to appear and when they do
they are something like 2x2 pixels. I have to resize them with my
window manager (Window Maker ver 0.20.0) to be able to hit the
buttons.
The bad news is that this only happens after some amount of use and I
have not been able to identify a trigger. Also I don't know if it
happens with -vanilla since I can't stand to use any emacs in its
uncustomized state for long enough to check. ;-)
-Eric
Recent keystrokes:
t e r SPC t o SPC 2 SPC a n d ESC TAB SPC ESC q right
right right right right right right right right right
g down down RET - E r i c up up ESC q button1 button1up
SPC C-c C-c button1 button1up button2 button2up button1
button1up button2 button2up button2 button2up button1
button1up C-g button2 button2up button2 button2up button2
button2up button2 button2up button2 button2up button1
button1up button2 button2up button2 button2up button1
button1up button1 button1up misc-user button1 button1up
button1 button1up button2 button2up button1 button1up
button2 button2up button1 button1up button1 button1up
misc-user button1 button1up button1 button1up misc-user
misc-user
Recent messages (most recent first):
Loading emacsbug...done
Loading emacsbug...
(No changes need to be saved)
No more unread newsgroups
No gnus is bad news
Checking new news...done
Opening nndraft server...
Checking new news...
No new newsgroups
Generating the cache active file...done
- 2 participants
- 1 comments
Re: tty problems cause only 4 characters to appear on screen at once! (PR#1638)
23 years, 7 months
Gunnar Evermann
Gunnar Evermann
any ideas anyone?
Gunnar
mcrogan(a)purdue.edu writes:
> When using XEmacs-21.2.46 (although I have had this occur on other
> versions, including non-beta), and sometimes after sending a message in
> VM (for example; in fact, the problem may occur at other times), I get
> that the XEmacs session I am running under a tty becomes entirely
> unusable. It consists of several characters on the screen. Right now
> it is:
>
> R\
> **
>
> Where the *'s signify blank characters, but in reverse video. I can
> still enter keystrokes in this tty, but the display never gets better.
> Now, since I am running `gnuclient' on other tty's, the session in other
> windows stays perfectly usable. Note that the tty that begins showing
> the small number of characters is not a `gnuclient' window, but is the
> original XEmacs window.
>
> The problem occurs seemingly at random, and only some of the time, but I
> have noticed in particular that it is likely to occur when I send a
> message in VM. After it would have returned to the summary page, it
> gives this unreadable screen.
>
> The problem is that I have no idea on how to debug this problem. If I
> knew what to do, it might be easy to debug, but I do not know where to
> start or how to provide more information. The very XEmacs (via
> `gnuclient') session that I am running now has this strange tty
> behaviour.
>
> Any ideas on what to do next would be greatly helpful.
>
> $ cat Installation
> uname -a: Linux localhost 2.4.0 #6 Sat Jan 27 09:39:26 EST 2001 i686 unknown
>
> ./configure '--prefix=/usr/local/beta' '--exec-prefix=/usr/local/beta' '--with-scrollbars=athena' '--with-athena=3d' '--with-dialogs=athena' '--with-widgets=athena' '--external-widget' '--with-png' '--without-gpm' '--with-jpeg' '--with-xpm' '--with-tiff' '--with-xface' '--with-sound=native,esd' '--with-database=berkdb' '--mail-locking=flock' '--with-pop' '--with-modules' '--with-site-lisp=yes' '--with-site-modules=yes' '--pdump' '--with-mule' '--debug' '--error-checking=all' '--memory-usage-stats' '--with-purify' '--rel-alloc' '--with-debug-malloc' '--with-clash-detection' '--extra-verbose' '--with-netinstall'
>
>
> XEmacs 21.2-b46 "Urania" configured for `i686-pc-linux'.
>
>
> Compilation / Installation:
> Source code location: /usr/local/src/XEmacs/xemacs-21.2.46
> Installation prefix: /usr/local/beta
> Operating system description file: `s/linux.h'
> Machine description file: `m/intel386.h'
> Compiler: gcc -O3 -g3 -mpentiumpro
> Relocating allocator for buffers: yes
> GNU version of malloc: no
> - User chose not to use GNU allocators.
>
> Window System:
> Compiling in support for the X window system:
> - X Windows headers location: /usr/X11R6/include
> - X Windows libraries location: /usr/X11R6/lib
> - Handling WM_COMMAND properly.
> Compiling in support for the Athena widget set:
> - Athena headers location: X11/Xaw3d
> - Athena library to link: Xaw3d
> Using Lucid menubars.
> Using Athena scrollbars.
> Using Athena dialog boxes.
> Using Athena native widgets.
>
> TTY:
> Compiling in support for ncurses.
>
> Images:
> Compiling in support for GIF images (builtin).
> Compiling in support for XPM images.
> Compiling in support for PNG images.
> Compiling in support for JPEG images.
> Compiling in support for TIFF images.
> Compiling in support for X-Face message headers.
>
> Sound:
> Compiling in support for sound (native).
> Compiling in support for NAS (network audio system).
> Compiling in support for ESD (Enlightened Sound Daemon).
>
> Databases:
> Compiling in support for Berkeley database.
> Compiling in support for LDAP.
> Compiling in support for PostgreSQL.
> - Using PostgreSQL header file: postgresql/libpq-fe.h
>
> Internationalization:
> Compiling in support for Mule (multi-lingual Emacs).
> Compiling in support for XIM (X11R5+ I18N input method).
> - Using raw Xlib to provide XIM support.
> Compiling in support for the WNN input method on Mule.
> - Using WNN version 6.
>
> Mail:
> Compiling in support for POP mail retrieval.
> Compiling in support for "flock" mail spool file locking method.
>
> Other Features:
> Compiling in support for dynamic shared object modules.
> Using the new portable dumper.
> Compiling in support for extra debugging code.
> 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: ---------------------------------------------------------
>
>
- 1 participants
- 0 comments
HELP! [un]request_sigio_on_device() fubar'd on Linux
23 years, 7 months
Gunnar Evermann
Gunnar Evermann
I could really use some advice from people who know a bit about Unix
APIs and Linux in particular (Martin? Jan? Ben?). Sorry for the
long-winded explanation, please bear with me.
The unrequest_sigio_on_device function is completely broken on Linux
AFAICT.
We have the following in sysdep.c:
----------------------------------------------------------------------
request_sigio_on_device (struct device *d)
{
int filedesc = DEVICE_INFD (d);
#if defined (I_SETSIG) && !defined(HPUX10) && !defined(LINUX)
{
int events=0;
ioctl (filedesc, I_GETSIG, &events);
ioctl (filedesc, I_SETSIG, events | S_INPUT);
}
#elif defined (FASYNC)
fcntl (filedesc, F_SETFL, fcntl (filedesc, F_GETFL, 0) | FASYNC);
[...]
unrequest_sigio_on_device (struct device *d)
{
int filedesc = DEVICE_INFD (d);
#if defined (I_SETSIG) && !defined(HPUX10)
{
int events=0;
ioctl (filedesc, I_GETSIG, &events);
ioctl (filedesc, I_SETSIG, events & ~S_INPUT);
}
#elif defined (FASYNC)
fcntl (filedesc, F_SETFL, fcntl (filedesc, F_GETFL, 0) & ~FASYNC);
----------------------------------------------------------------------
On Linux (on most variants I have seen) both I_SETSIG and FASYNC are
defined. Thus in request_sigio() we use the ioctl and in
unrequest_sigio() we use the fcntl. Surely, this is wrong?
I think Jan had a patch for 21.1 that added the !defined(LINUX) to
unrequest_sigio as well, so that we used fcntl in both cases. This
might be a good thing, since when we use the ioctl what actually
happens (according to strace) is:
ioctl(6, CDROMVOLCTRL, 0xbfffea84) = -1 EINVAL (Invalid argument)
ioctl(6, CDROMEJECT, 0) = -1 EINVAL (Invalid argument)
this is clearly rubbish. (Aside: shouldn't we check the return value of
ioctl() anyway?). So, what happens in the current code is that we never
manage to disable SIGIOs.
OK, so when I "fix" this (causing fcntl to be used in both cases)
another problems surfaces. The code that tries to check for C-g to
interrupt system-calls fails under X (I tried to debug
x_check_for_quit_char() but C-g never appeared in the X event queue --
no idea why). The result is that things like
(open-network-stream "bug" nil "10.0.0.42" 42)
cannot be interrupted and will hang xemacs permanently (this was
pointed out by Simon Josefsson last year and is IMHO the major bug in
21.1).
Why do we need to wrap the connect() call inside open-network-stream
in slow_down_interrupts/speed_up_interrupts anyway? The current code
where SIGIOs get delivered and interrupt connect() seems to work fine.
Any help with this is very much appreciated.
Gunnar
P.S.: This is mostly a repost of
http://list-archive.xemacs.org/xemacs-beta/200011/msg00035.html
to which nobody replied :-(
- 2 participants
- 2 comments
Re: XEmacs 21.2.47 "Zephir" is released
23 years, 7 months
Markus Alt
Markus Alt
"XEmacs 21.4 Release Manager" wrote:
>
> XEmacs 21.2.47 "Zephir" is released.
>
> The CVS tag for the release is r21-2-47 (or the "moving tag"
> r21-2-latest-beta). Tarballs are available in the usual place
> ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2. There are no PGP
> signatures for this release.
>
> 21.2.47 "Zephir" contains a few changes to 21.2.46 "Urania". See the
> individual ChangeLogs for details.
>
> However, its primary purpose is practice for me in creating a
> distribution, uploading it, and announcing it, preparatory to the
> release of 21.4.0. If you have time, I would appreciate it if a few
> people would verify that the tarballs can be downloaded, the CVS tags
> can be used for checkout, and that the resulting source trees can be
> built.
FWIW, after downloading xemacs-21.2.46-21.2.47.patch.gz and trying to
apply it to my existing 21.2.46 build tree (which also was extracted
from the tarballs), I get the following:
root＠altmark: xemacs-21.2 (15) # applypatch -check -verbose
/download/xemacs/xemacs-21.2/xemacs-21.2.46-21.2.47.patch
Validate input.
ApplyPatch kit apparently okay.
Verify source directory.
Verify error: file ./src/s/windows95.h is missing.
Verify error: file ./src/s/msdos.h is missing.
Verify error: file ./src/mule-mcpath.h is missing.
Verify error: file ./src/mule-mcpath.c is missing.
Verify error: file ./src/m/s390.h is missing.
Verify error: file ./src/input-method-xfs.c is missing.
Verify error: file ./src/gdbinit is missing.
Verify error: file ./src/dbxrc is missing.
Verify error: file ./src/alloc.h is missing.
Verify error: file ./nt/runemacs.c is missing.
Verify error: file ./nt/inc/unistd.h is missing.
Verify error: file ./nt/inc/sys/time.h is missing.
Verify error: file ./nt/inc/sys/socket.h is missing.
Verify error: file ./nt/inc/sys/param.h is missing.
Verify error: file ./nt/inc/sys/ioctl.h is missing.
Verify error: file ./nt/inc/sys/file.h is missing.
Verify error: file ./nt/inc/sys/dir.h is missing.
Verify error: file ./nt/inc/pwd.h is missing.
Verify error: file ./nt/inc/netinet/in.h is missing.
Verify error: file ./nt/inc/netdb.h is missing.
Verify error: file ./nt/inc/arpa/inet.h is missing.
Verify error: file ./nt/Todo is missing.
Verify error: file ./nt/Makefile.cygwin is missing.
Verify error: file ./netinstall/iniparse.c is missing.
Verify error: file ./netinstall/inilex.c is missing.
Verify error: file ./lisp/winnt.el is missing.
Verify error: file ./lisp/cleantree.el is missing.
Verify error: file ./lib-src/update-elc.sh is missing.
Verify error: file ./lib-src/run.rc is missing.
Verify error: file ./lib-src/run.h is missing.
Verify error: file ./lib-src/run.c is missing.
Verify error: file ./etc/sample.emacs is missing.
Verify error: file ./etc/photos/jasonm.png is missing.
Verify error: file ./etc/photos/jason.png is missing.
Verify error: directory ./nt/inc/sys must be removed, but does not
exist.
Verify error: directory ./nt/inc/netinet must be removed, but does not
exist.
Verify error: directory ./nt/inc/arpa must be removed, but does not
exist.
Verify error: directory ./nt/inc must be removed, but does not exist.
Apparently this is not the expected source directory, aborting.
Use "--force" to override this.
I haven't tried the xemacs-21.2.47.tar.gz tarball yet as I don't like
the idea of pulling approx. 10 MB over a 56k line ... (Perhaps I will do
on Tuesday at work, but I guess I'd rather build 21.4.0 then.)
However, running applypatch with the "--force" option and building works
fine. Here's the output of `describe-installation':
uname -a: Linux altmark 2.2.18 #7 Thu Mar 8 22:37:05 CET 2001 i686
unknown
./configure '--cflags=-O3' '--debug=no' '--error-checking=none'
'--with-athena=3d'
XEmacs 21.2-b46 "Urania" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /build/xemacs/xemacs-21.2
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O3
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11/include
- X Windows libraries location: /usr/X11/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Looking forward to 21.4!
Markus
- 2 participants
- 2 comments
Is DOC arch indep or byte order dependant?
23 years, 7 months
Karl M. Hegbloom
Karl M. Hegbloom
I'm wondering if the DOC file is byte order dependant or if it can be
placed into a cross architecture shareable location?
- 2 participants
- 1 comments
Which branch is the latest one ?
23 years, 7 months
Fabrice Popineau
Fabrice Popineau
I'm a bit lost. I would like to get the latest cvs code. Should I
update against no tag (to get the trunk, developpement code) or
against r21-2-47 ? Or is it the same ?
Thanks,
--
Fabrice Popineau
- 3 participants
- 8 comments
Hard Crash when using font-lock-mode on large buffers
23 years, 7 months
Andreas Fuchs
Andreas Fuchs
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 (beta46) "Urania" [Lucid] (i686-pc-linux, Mule) of Thu Apr 12 2001 on dahaIM.dyndns.org
configured using `configure --prefix=/usr/local/xemacs --with-athena=next --with-menubars=lucid --with-scrollbars=athena --with-dialogs=athena --with-widgets=athena --with-sound=esd --with-mule --error-checking=none'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
When I open (say) a larger lisp file with font-lock turned on, it
loads, and emacs crashes hard, after displaying the "fontifying
buffer..." progress bar. (I have xemacs-base 1.51 installed, says
pui-list-packages.)
I saw it happen on larger mail messages (like the bug-report message),
on large lisp files, java files using jde, etc.
The lisp and C backtrace I have attached are BTs from opening a .el
file, which is also attached.
Lisp backtrace follows:
dispatch-non-command-events()
# (condition-case ... . ((nil)))
progress-feedback-dispatch-non-command-events()
# bind (tmsg top frame value message label)
append-progress-feedback(font-lock "Fontifying misc.el..." 0 nil)
# bind (frame value message label)
display-progress-feedback(font-lock "Fontifying misc.el..." 0)
# bind (str)
# (unwind-protect ...)
# bind (args value fmt label)
progress-feedback-with-label(font-lock "Fontifying %s..." 0 "misc.el")
# bind (maybe-loudly end beg)
font-lock-default-unfontify-region(1 22108 t)
# bind (loudly end beg)
font-lock-unfontify-region(1 22108 t)
# bind (was-on font-lock-verbose font-lock-message-threshold aborted)
# (unwind-protect ...)
font-lock-default-fontify-buffer()
# bind (font-lock-verbose)
font-lock-fontify-buffer()
# bind (on-p maximum-size arg)
font-lock-mode(1)
turn-on-font-lock()
# bind (explicit-defaults)
font-lock-set-defaults()
run-hooks(font-lock-set-defaults)
# bind (nomodes after-find-file-from-revert-buffer noauto warn error)
after-find-file(nil t)
byte-code("..." [buffer-file-number number truename buffer-file-truename buf buffer-file-name set-buffer-major-mode erase-buffer nil (byte-code «Â Ã\"ªÄÃ\"Â" [rawfile filename insert-file-contents-literally t insert-file-contents] 3) ((file-error ...)) abbreviate-file-name file-name-directory make-local-variable backup-inhibited t after-find-file find-file-use-truenames default-directory backup-enable-predicate rawfile error nowarn] 3)
# (condition-case ... . ((t (byte-code "!Ã ＠ A\"" ... 3))))
# (unwind-protect ...)
# bind (error number truename buf rawfile nowarn filename)
find-file-noselect("~/.xemacs/misc.el")
# bind (codesys filename)
find-file("~/.xemacs/misc.el" nil)
# bind (command-debug-status)
call-interactively(find-file)
# (condition-case ... . error)
# (catch top-level ...)
zsh: segmentation fault (core dumped) xemacs
--------------------------------------------------
C Backtrace follows:
#0 0x40339801 in kill () from /lib/libc.so.6
#1 0x80b2a93 in fatal_error_signal (sig=11) at emacs.c:535
#2 0x40339738 in sigaction () from /lib/libc.so.6
#3 0x81c4fe3 in GaugeExpose (w=0x8834a08, event=0xbfffda3c, region=0x852b2d0)
at xlwgauge.c:425
#4 0x400fd915 in _XtEventInitialize () from /usr/X11R6/lib/libXt.so.6
#5 0x400fd5fb in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#6 0x400fd344 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#7 0x400fdcfe in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
#8 0x400fe068 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#9 0x401089c0 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#10 0x819d8b0 in emacs_Xt_event_pending_p (user_p=0) at event-Xt.c:2907
#11 0x80f62e5 in Fdispatch_non_command_events () at event-stream.c:438
#12 0x80b91aa in Feval (form=138988696) at eval.c:3331
#13 0x80b69d1 in condition_case_3 (bodyform=138988696, var=136649524,
handlers=138988660) at eval.c:1651
#14 0x8092acd in execute_rare_opcode (stack_ptr=0xbfffdd70,
program_ptr=0x883a08c "\207", opcode=Bcondition_case) at bytecode.c:1271
#15 0x809207b in execute_optimized_program (program=0x883a088 "ÀÁÂ\217\207",
stack_depth=3, constants_data=0x83f2f28) at bytecode.c:656
#16 0x8091eef in funcall_compiled_function (fun=138885752, nargs=0,
args=0xbfffde9c) at bytecode.c:515
#17 0x80b9cc7 in Ffuncall (nargs=1, args=0xbfffde98) at eval.c:3563
#18 0x80921e7 in execute_optimized_program (
program=0x87fc3a8 "\r¬\004Æ \025\n＠\211\031A\036\020\b\t＠a«%\t\f¡\210\016\020\fk«\020Ç\016\021È\013#\210ÉÊ\r!!\210ª\aË\f\013\r#\210Ì \210ª\r\b\fB\nB\022Ë\f\013\r#\210Í \210\013Îa\004Ï\b!*\207 as \231", stack_depth=5,
constants_data=0x83f2f48) at bytecode.c:746
#19 0x8091eef in funcall_compiled_function (fun=138885780, nargs=4,
args=0xbfffdfdc) at bytecode.c:515
#20 0x80b9cc7 in Ffuncall (nargs=5, args=0xbfffdfd8) at eval.c:3563
#21 0x80921e7 in execute_optimized_program (
program=0x881b2d8 "\fÅa«\aÆ\n\t\013#\207ÇÈ\013\"«\004\b«\026É\n\t\fÊa«\004˪\aÌ\fÍ¥Î\"P\013#\207Ï\n\t\f\013$\207;", stack_depth=6,
constants_data=0x83f3140) at bytecode.c:746
#22 0x8091eef in funcall_compiled_function (fun=138885864, nargs=3,
args=0xbfffe11c) at bytecode.c:515
#23 0x80b9cc7 in Ffuncall (nargs=4, args=0xbfffe118) at eval.c:3563
#24 0x80921e7 in execute_optimized_program (
program=0x8854ce0 "\212\013¬\f\n¬\tÅÆ\tÅ\"\210ª\017ÇÈ\013\n#\034É\t\f\b#\210\f))\207\bl\235&\bt\216\204\b＠", stack_depth=4, constants_data=0x83f31d8)
at bytecode.c:746
#25 0x8091eef in funcall_compiled_function (fun=138885976, nargs=4,
args=0xbfffe25c) at bytecode.c:515
#26 0x80b9cc7 in Ffuncall (nargs=5, args=0xbfffe258) at eval.c:3563
#27 0x80921e7 in execute_optimized_program (
program=0x87fc340 "\t«\024\b«\021\r\013Z\016\022Y«\tÆÇÈÉÊ $\210Ë Ì\211Í\211\036\023\036\024\036\025\036\026\032\013\r\035\034Î\f\rÏÍ$\210Î\f\rÇÍ$\210\016\027«\bÎ\f\rÐÍ$\210*\n?\bË \004ÑÍ!-\207backi", stack_depth=5,
constants_data=0x85cbc28) at bytecode.c:746
#28 0x8091eef in funcall_compiled_function (fun=140670664, nargs=3,
args=0xbfffe39c) at bytecode.c:515
#29 0x80b9cc7 in Ffuncall (nargs=4, args=0xbfffe398) at eval.c:3563
#30 0x80921e7 in execute_optimized_program (
program=0x87fc320 "\013\n\t\b#\207rn", stack_depth=4,
constants_data=0x862e470) at bytecode.c:746
#31 0x8091eef in funcall_compiled_function (fun=140670552, nargs=3,
args=0xbfffe4dc) at bytecode.c:515
#32 0x80b9cc7 in Ffuncall (nargs=4, args=0xbfffe4d8) at eval.c:3563
#33 0x80921e7 in execute_optimized_program (
program=0x87fc2c8 "\214~\210\n\r®\002tÆÇ\034\031\035\211\e¬\005ÂÈ!\210ÉedÊ#\210ÇËÌ\217\210\013¬\bÇ\030ÂÆ!\210)ÍÀ!ÊL\210\f«\f\r«\tÎÏÐÑÒ $\210,ÓÔ!)\207!",
stack_depth=6, constants_data=0x85c86e0) at bytecode.c:746
#34 0x8091eef in funcall_compiled_function (fun=140670580, nargs=0,
args=0xbfffe61c) at bytecode.c:515
#35 0x80b9cc7 in Ffuncall (nargs=1, args=0xbfffe618) at eval.c:3563
#36 0x80921e7 in execute_optimized_program (
program=0x881e540 "\t®\002t\031\b )\207", stack_depth=1,
constants_data=0x862dc30) at bytecode.c:746
#37 0x8091eef in funcall_compiled_function (fun=140670468, nargs=0,
args=0xbfffe74c) at bytecode.c:515
#38 0x80b9cc7 in Ffuncall (nargs=1, args=0xbfffe748) at eval.c:3563
#39 0x80921e7 in execute_optimized_program (
program=0x8808390 "\t«\bÆ\t!ÇVª\003\b?\f:¬\004\fª\013\016!\f·®\004È\f·A\e\035\016\"¬\tÉ ÇHÊa«\003Ë\025É Ìk«\003Ë\025\r«\023ÍÎ!\210ÏÎÐËÈ$\210ÏÑÒ\"\210ª\rÓÎÐÈ#\210Ë\211\026#\026$ÔÀ!\rL\210\r«'Õ \210Ö×!\210\n¬/\013«\aØ \013X«\006Ù \210ª!\016%«\035ÚÛÜÝÉ $\210ª\023\n«\rË\022Þed\"\210ß \210ª\004ß \210à *\207",
stack_depth=6, constants_data=0x8623340) at bytecode.c:746
#40 0x8091eef in funcall_compiled_function (fun=140670272, nargs=1,
args=0xbfffe88c) at bytecode.c:515
#41 0x80b9cc7 in Ffuncall (nargs=2, args=0xbfffe888) at eval.c:3563
#42 0x80921e7 in execute_optimized_program (program=0x86e9a80 "ÀÁ!\207)",
stack_depth=2, constants_data=0x862daa8) at bytecode.c:746
#43 0x8091eef in funcall_compiled_function (fun=140670300, nargs=0,
args=0xbfffe9bc) at bytecode.c:515
#44 0x80b9cc7 in Ffuncall (nargs=1, args=0xbfffe9b8) at eval.c:3563
#45 0x80921e7 in execute_optimized_program (
program=0x87631a0 "ÆÇ!\031\f«\a\r\013s?ª\004\r\ns\013È\t!\006\b\003É \207these\ny", stack_depth=2, constants_data=0x8470968) at bytecode.c:746
#46 0x8091eef in funcall_compiled_function (fun=139221436, nargs=0,
args=0xbfffec30) at bytecode.c:515
#47 0x80b9cc7 in Ffuncall (nargs=1, args=0xbfffec2c) at eval.c:3563
#48 0x80bac42 in run_hook_with_args_in_buffer (buf=0x881e378, nargs=1,
args=0xbfffec2c, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4020
#49 0x80be88a in run_hook_with_args (nargs=1, args=0xbfffec2c,
cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4033
#50 0x80c03a1 in Frun_hooks (nargs=1, args=0xbfffec2c) at eval.c:3887
#51 0x80b9bff in Ffuncall (nargs=2, args=0xbfffec28) at eval.c:3549
#52 0x80921e7 in execute_optimized_program (
program=0x8769fe8 "Æ\r!?\024\b\204\203", stack_depth=5,
constants_data=0x8333818) at bytecode.c:746
#53 0x8091eef in funcall_compiled_function (fun=138430516, nargs=2,
args=0xbfffed6c) at bytecode.c:515
#54 0x80b9cc7 in Ffuncall (nargs=3, args=0xbfffed68) at eval.c:3563
#55 0x80921e7 in execute_optimized_program (
program=0xbfffedb4 "Æ\f!\210\fq\210Ç \210ÈÉÊ\217\210\013¬\003\n\023\t\020\016\021«\005Ë\r!\025Ì\r!\026\022\016\023\r!¬\bÍÎ!\210Ï\026\016\016\024¬\013Ð\016\025\016\026?\"\210p\024È\207\034\e%\b\220g\"\b\214îÿ¿\027\233\013\b|mz\b\034\e%\b", stack_depth=3, constants_data=0x8333650) at bytecode.c:746
#56 0x8094351 in Fbyte_code (instructions=138443284, constants=137573952,
stack_depth=7) at bytecode.c:2403
#57 0x80b91d2 in Feval (form=137569020) at eval.c:3331
#58 0x80b69d1 in condition_case_3 (bodyform=137569020, var=136770116,
handlers=137573060) at eval.c:1651
#59 0x8092acd in execute_rare_opcode (stack_ptr=0xbffff120,
program_ptr=0x87626ec "\210)\f,\207ree9", opcode=Bcondition_case)
at bytecode.c:1271
#60 0x809207b in execute_optimized_program (
program=0x8762610 "ÆÇ\r!!\025È\r!«\035ÉÊ!«\023\016+«\017Ê\013«\bÆË\r!!ª\002\r!\207ÌÍ\r\"\207Î\r!\034ÆË\r!!\032ÏÐ\n!\233\036,Ñ\036\f\f«\035\016-¬\004\013«\026\t¬\023\212\fq\210\b\r\230¬\tÒÓ\r\b\016.$\210)\f«w\t¬\177Ô\f!¬zÕ\r!¬\bÌÖ\r\"\210ªn×\f!¬\034ØÙ\215«\027r\fq\210ÒÚ\r\"\210ÛÜ\211\"\210ÒÝ\r\"\210)ªNÞß\r!à\f!\230«\025á×\f!«\006âã!ª\004âä!ß\r!\"ª\026á×\f!«\006âå!ª\004âæ!ß\r!à\f!#!«\030r"...,
stack_depth=6, constants_data=0x83336e8) at bytecode.c:656
#61 0x8091eef in funcall_compiled_function (fun=138430488, nargs=1,
args=0xbffff260) at bytecode.c:515
#62 0x80b9cc7 in Ffuncall (nargs=2, args=0xbffff25c) at eval.c:3563
#63 0x80921e7 in execute_optimized_program (
program=0x881b7e8 "\n«\fÃ\n!\030ÄÅ\t!!)\207ÄÅ\t!!\207\021", stack_depth=3,
constants_data=0x83fb280) at bytecode.c:746
#64 0x8091eef in funcall_compiled_function (fun=138430096, nargs=2,
args=0xbffff398) at bytecode.c:515
#65 0x80b9cc7 in Ffuncall (nargs=3, args=0xbffff394) at eval.c:3563
#66 0x80963d9 in Fcall_interactively (function=137677340,
record_flag=136649500, keys=136649500) at callint.c:940
#67 0x80b87ac in Fcommand_execute (cmd=137677340, record_flag=136649500,
keys=136649500) at eval.c:2970
#68 0x80f8105 in execute_command_event (command_builder=0x854d460,
event=141066448) at event-stream.c:3834
#69 0x80f86fe in Fdispatch_event (event=141066448) at event-stream.c:4165
#70 0x809ca40 in Fcommand_loop_1 () at cmdloop.c:583
#71 0x809cc9d in command_loop_1 (dummy=136649500) at cmdloop.c:494
#72 0x80bf49e in condition_case_1 (handlers=136649596,
bfun=0x809cc84 <command_loop_1>, barg=136649500,
hfun=0x809cd0c <cmd_error>, harg=136649500) at eval.c:1651
#73 0x809cdff in command_loop_2 (dummy=136649500) at cmdloop.c:256
#74 0x80bf36c in internal_catch (tag=136725884,
func=0x809cdc0 <command_loop_2>, arg=136649500, threw=0x0) at eval.c:1317
#75 0x809c78f in initial_command_loop (load_me=136649500) at cmdloop.c:305
#76 0x80b38de in xemacs_21_2_b46_i686_pc_linux () at emacs.c:2344
#77 0x80b5642 in main () at emacs.c:2773
#78 0x4032a16b in __libc_start_main () from /lib/libc.so.6
This is the lisp file where XEmacs crashed repeatedly (yeah, it is one
of Robin's):
Recent keystrokes:
C-x 1 misc-user misc-user
Recent messages (most recent first):
Loading gnus-xmas...done
Loading gnus-xmas...
Loading gnus-ems...
Loading mail-extr...done
Loading mail-extr...
Loading message...done
Loading message...
Loading emacsbug...done
Loading emacsbug...
Getting list of fonts from server... done.
Thanks,
--
Andreas Fuchs, <asf(a)acm.org>, <d96001(a)htlwrn.ac.at>, antifuchs
- 1 participants
- 0 comments
gnuserv
23 years, 7 months
Gunnar Evermann
Gunnar Evermann
I've received a bug report about gnuserv. This referrs to the
stand-alone gnuserv maintained by Martin Schwenke, who forwarded this
to xemacsbugs as it is our code.
> I've tried to create port of gnuserv-3.12.1 for FreeBSD and have meet
> two problems:
>
> 1) gnuserv creates unix socket with wrong name
> /tmp/gsrvdir*/gsr. Here patch to fix this problem:
>
> --- gnuserv.c~ Thu Jan 25 13:41:48 2001
> +++ gnuserv.c Sat Feb 10 18:00:44 2001
> ＠＠ -790,7 +790,7 ＠＠
> + strlen (server.sun_path) + 1);
> server.sun_len = bindlen;
> #else
> - bindlen = strlen (server.sun_path) + sizeof (server.sun_family);
> + bindlen = strlen (server.sun_path) + 1 + sizeof (server.sun_family);
> #endif
>
> if (bind(ls,(struct sockaddr *)&server,bindlen) < 0)
The code in question is:
,----
| #ifdef HAVE_SOCKADDR_SUN_LEN
| /* See W. R. Stevens "Advanced Programming in the Unix Environment"
| p. 502 */
| bindlen = (sizeof (server.sun_len) + sizeof (server.sun_family)
| + strlen (server.sun_path) + 1);
| server.sun_len = bindlen;
| #else
| bindlen = strlen (server.sun_path) + sizeof (server.sun_family);
| #endif
|
| if (bind(ls,(struct sockaddr *)&server,bindlen) < 0)
| {
`----
I don't have the Stevens handy. Does anybody know whether the length
should include the string terminating 0 or not?
I have never seen /tmp/gsrvdir*/gsr on Linux or Solaris. Could
somebody check on FreeBSD?
Gunnar
- 1 participants
- 0 comments
Re: XEmacs 21.2.47 "Zephir" is released
23 years, 7 months
Markus Alt
Markus Alt
Oops, sorry, the latter was the wrong build report (the one for
21.2.46). Here's the correct one, although looking pretty much the same.
uname -a: Linux altmark 2.2.18 #7 Thu Mar 8 22:37:05 CET 2001 i686
unknown
./configure '--cflags=-O3' '--debug=no' '--error-checking=none'
'--with-athena=3d'
XEmacs 21.2.47 "Zephir" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /build/xemacs/xemacs-21.2
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -O3
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11/include
- X Windows libraries location: /usr/X11/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Markus
- 1 participants
- 0 comments