21.1, 21.2: HOWTO create a package Texinfo
25 years
Stephen J. Turnbull
Stephen J. Turnbull
Vin: this should be added to 21.1, too.
I have written a very short introduction to creating Lisp packages. I
have chosen to place it in the XEmacs manual rather than the Lisp
Reference, because packaging is fundamentally a sysadmin kind of task
rather than Lisp programming. I think a lot of people who use an
unpackaged Lisp library would be able, and happy, to package it if the
upstream maintainer won't (or has disappeared).
Comments?
Index: man/ChangeLog
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/man/ChangeLog,v
retrieving revision 1.57.2.147
diff -u -U0 -r1.57.2.147 ChangeLog
--- ChangeLog 2000/11/29 08:27:26 1.57.2.147
+++ ChangeLog 2000/11/29 12:37:57
＠＠ 0,0 +1,4 ＠＠
+2000-11-29 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * xemacs/packages.texi (Creating Packages): new node.
+
Index: man/xemacs/packages.texi
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/man/xemacs/packages.texi,v
retrieving revision 1.1.2.12
diff -u -r1.1.2.12 packages.texi
--- packages.texi 2000/11/29 08:27:45 1.1.2.12
+++ packages.texi 2000/11/29 12:38:56
＠＠ -19,6 +19,7 ＠＠
* Package Terminology:: Understanding different kinds of packages.
* Using Packages:: How to install and use packages.
* Building Packages:: Building packages from sources.
+* Creating Packages:: The basics.
* Available Packages:: A brief, out-of-date, directory of packaged LISP.
＠end menu
＠＠ -339,7 +340,7 ＠＠
＠end enumerate
-＠node Building Packages, Available Packages, Using Packages, Packages
+＠node Building Packages, Creating Packages, Using Packages, Packages
＠comment node-name, next, previous, up
Source packages are available from the ＠file{packages/source-packages}
＠＠ -381,7 +382,7 ＠＠
of TeXinfo documentation if present.
＠item srckit
-Usually aliased to ＠code{make srckit-std}. This does a ＠code{make
+Usually aliased to ＠code{srckit-std}. This does a ＠code{make
distclean} and creates a package source tarball in the staging
directory. This is generally only of use for package maintainers.
＠＠ -402,7 +403,132 ＠＠
＠end table
-＠node Available Packages, , Building Packages, Packages
+＠node Creating Packages, Available Packages, Building Packages, Packages
+＠comment node-name, next, previous, up
+
+Creating a package from an existing Lisp library is not very difficult.
+
+In addition to the Lisp libraries themselves, you need a
+(a)file{package-info.in} file and a simple ＠file{Makefile}. The rest is
+done by ＠file{XEmacs.rules}, part of the packaging system
+infrastructure.
+
+(a)file{package-info.in} contains a single Lisp form like this:
+
+＠example
+(name ; your package's name
+ (standards-version 1.1
+ version VERSION
+ author-version AUTHOR_VERSION
+ date DATE
+ build-date BUILD_DATE
+ maintainer MAINTAINER
+ distribution xemacs ; change to "mule" if MULE is needed
+ priority high
+ category CATEGORY
+ dump nil
+ description "description" ; a one-line description string
+ filename FILENAME
+ md5sum MD5SUM
+ size SIZE
+ provides (feature1 feature2) ; one for every `provides' form
+ requires (REQUIRES)
+ type regular
+))
+＠end example
+
+You must fill in the four commented lines. The value of ＠code{name} is
+the name of your package as an unquoted symbol. Normally it is the name
+of the main Lisp file or principal feature provided. The allowed values
+for distribution are ＠code{xemacs} and ＠code{mule}. Write them as
+unquoted symbols. The ＠code{description} is a quoted Lisp string; use
+the usual conventions. The value for ＠code{provides} is a list of
+feature symbols (written unquoted). All of the features provided by
+libraries in your package should be elements of this list. Implementing
+an automatic method for generating the ＠file{provides} line is
+desirable, but as yet undone.
+
+The variables in upper-case are references to variables set in the
+＠file{Makefile} or automatically generated. Do not change them; they
+are automatically filled in by the build process.
+
+The remaining lines refer to implementation constants
+(＠code{standards-version}), or features that are unimplemented or have
+been removed (＠code{priority} and ＠code{dump}). The ＠code{type} line is
+not normally relevant to external maintainers; the alternate value is
+＠code{single-file}, which refers to packages consed up out of a number
+of single-file libraries that are more or less thematically related. An
+example is ＠code{prog-modes}. Single-file packages are basically for
+administrative convenience, and new packages should generally be created
+as regular packages.
+
+The ＠file{Makefile} is quite stylized. The idea is similar to an
+＠file{Imakefile} or an ＠code{automake} file: the complexity is hidden in
+generic rules files, in this case the ＠file{XEmacs.rules} include file
+in the top directory of the packages hierarchy. Although a number of
+facilities are available for complex libraries, most simple packages'
+＠file{Makefile}s contain a copyright notice, a few variable definitions,
+an include for ＠file{XEmacs.rules}, and a couple of standard targets.
+
+The first few ＠code{make} variables defined are ＠code{VERSION},
+＠code{AUTHOR_VERSION}, ＠code{MAINTAINER}, ＠code{PACKAGE},
+＠code{PKG_TYPE}, ＠code{REQUIRES}, and ＠code{CATEGORY}. All but one were
+described in the description of ＠file{package-info.in}. The last is an
+admistrative grouping. Current categories include ＠code{comm},
+＠code{games}, ＠code{libs}, ＠code{mule}, ＠code{oa}, ＠code{os},
+＠code{prog}, and ＠code{wp}. ＠ref{Available Packages}, for a list of
+categories.
+
+Next, define the variable ＠code{ELCS}. This contains the list of the
+byte-compiled Lisp files used by the package. These files and their
+(a)file{.el} versions will be included in the binary package. If there
+are other files (such as extra Lisp sources or an upstream
+＠file{Makefile}) that are normally placed in the installed Lisp
+directory, but not byte-compiled, they can be listed as the value of
+＠code{EXTRA_SOURCES}.
+
+The include is simply
+＠example
+include ../../XEmacs.rules
+＠end example
+
+The standard targets follow. These are
+
+＠example
+all:: $(ELCS) auto-autoloads.elc
+
+srckit: srckit-alias
+
+binkit: binkit-alias
+＠end example
+
+Other targets (such as Texinfo sources) may need to be added as
+dependencies for the ＠code{all} target. Dependencies for ＠code{srckit}
+and ＠code{binkit} (that is, values for ＠var{srckit-alias} and
+＠var{binkit-alias}) are defined in ＠file{XEmacs.rules}. The most useful
+of these values are given in the following table.
+
+＠table ＠var
+＠item srckit-alias
+Usually set to ＠code{srckit-std}.
+
+＠item binkit-alias
+May be set to ＠code{binkit-sourceonly}, ＠code{binkit-sourceinfo},
+＠code{binkit-sourcedata}, or
+＠code{binkit-sourcedatainfo}. ＠code{sourceonly} indicates there is
+nothing to install in a data directory or info directory.
+＠code{sourceinfo} indicates that source and info files are to be
+installed. ＠code{sourcedata} indicates that source and etc (data) files
+are to be installed. ＠code{sourcedatainfo} indicates source, etc
+(data), and info files are to be installed.
+＠end table
+
+Data files include things like pixmaps for a package-specific toolbar,
+and are normally installed in ＠file{etc/＠var{PACKAGE_NAME}}. A few
+packages have needs beyond the basic templates. See ＠file{XEmacs.rules}
+or a future revision of this manual for details.
+
+＠node Available Packages, , Creating Packages, Packages
＠comment node-name, next, previous, up
This section is surely out-of-date. If you're sure that XEmacs is
--
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
- 1 comments
patch request for 21.1.13
25 years
Isaac Hollander
Isaac Hollander
Last year I submitted a patch to the main Makefile.in to make tar a macro.
http://www.xemacs.org/list-archives/xemacs-patches/199911/msg00061.html
Jan adapted the patch to Makefile.in.in and applied it to 21.2.x.
Would it be possible to add this patch to 21.1.13? It would make my job
of maintaining xemacs builds on several different unix variants much
easier, since I can then override the system tar with GNU tar with the
options I need (specifically -h)
Thanks
Isaac
- 2 participants
- 1 comments
Killing ispell process under cygwin-xemacs
25 years
Dr. Volker Zell
Dr. Volker Zell
Hi
When interrupting a running ispell process under
XEmacs 21.2 (beta38) "Peisino,Ak(B" [Lucid] (i686-pc-cygwin) of Sun Dec 17 2000 on VZELL
I get the following message:
kill (327, 9) failed: No such process
But the running ispell process had the exact same process id. Anyway the killing works.
Can someone running the cygwin version of xemacs check this behaviour.
I cannot reproduce this behaviour with Xemacs-21.1.12.there I got "Ispell process killed".
System: WinNT 4.0/SP3 - 196 MB Ram
Cygwin 1.1.6
- everything mounted binary,
- CYGWIN = tty title binmode ntea nontsec
Ciao
Volker
- 1 participants
- 0 comments
Re: [crash,xemacs_21_2_b36_i686_bittersweet_linux] Dumped core reloading byte-code
25 years
Karl M. Hegbloom
Karl M. Hegbloom
>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes:
SY> |--==> "Karl" == Karl M Hegbloom <karlheg(a)bittersweet.inetarena.com> writes:
Karl> I had just patched up the copy of dired that I am currently using
Karl> (with the patches I mailed earlier), and rebuilt it. I used `dired'
Karl> `L' to load the newly rebuilt "dired.elc", and it crashed and dumped
Karl> core. Do you need any more information? I will save the core file
Karl> and a copy of this binary.
SY> So I won't forward your patch on to the dired maintainer. At least
SY> not until you get to the bottom of this problem. :-)
I CC'd him anyway... and besides, I don't think the patch is the
culprit. I use dired every day, and XEmacs works fine. That crash
was a fluke; it only happened once.
--
mailto: Karl M. Hegbloom <karlheg(a)debian.org>
http://people.debian.org/~karlheg/
( <-- These are full-on slotskis. --> )
This is only a semi-colon --> ;
- 1 participants
- 0 comments
[comp.emacs.xemacs] Why packages cannot be deleted from user's own subdirectory?
25 years
Vin Shelton
Vin Shelton
This looks like OK to me, but I don't put packages under .xemacs.
Comments?
- vin
- 1 participants
- 2 comments
Problems with alloca on Alpha Linux with Compaq cc
25 years
Falk Hueffner
Falk Hueffner
Hi,
with xemacs-21.2 CVS from October 12 and Compaq C V6.2-504 I get
[...]
checking for working alloca.h... no
checking for alloca... no
Defining C_ALLOCA
checking whether alloca needs Cray hooks... no
checking stack direction for C alloca... -1
Defining STACK_DIRECTION = -1
xemacs will be linked with "alloca.o"
[...]
The reason is that ccc won't find alloca when linking if passed
"-std1", which is added by xemacs configure. (ccc picks up gcc's
alloca.h, but the alloca.h check wants to link, too, so it fails.)
Then when building one gets lots of warnings:
ccc -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src -I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1 /usr/local/src/xemacs-21.2-10.12/lib-src/wakeup.c -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o wakeup
cc: Warning: /usr/include/alloca.h, line 33: In this declaration, the type of the function "alloca", declared in a system header file, is not compatible with the earlier declaration of "alloca" at line number 43 in file ../src/config.h. (funcredeclext1)
extern __ptr_t alloca __P ((size_t __size));
---------------^
(__ptr_t is a #define for void *, while config.h declares the return
value as char *)
Finally, it fails:
ccc -c -O3 -Demacs -I. -I../src -I/usr/local/src/xemacs-21.2-10.12/lib-src -I/usr/local/src/xemacs-21.2-10.12/src -DHAVE_CONFIG_H -std1 /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c
cc: Error: /usr/local/src/xemacs-21.2-10.12/lib-src/../src/alloca.c, line 191: In this declaration, the type of "alloca" is not compatible with the type of a previous declaration of "alloca" at line number 43 in file ../src/config.h. (notcompat)
alloca (size)
^
because alloca.c declares alloca as returning "pointer", which is
typedefed to void *.
Now I wonder how to fix this best; one could for example:
* remove -std1 from the ccc flags
* use something like
#if defined(__DECC) && defined(__linux__)
# include <machine/builtins.h>
# define alloca __ALLOCA
#endif
which also works with -std1
* consistentialize xemacs' declarations; regex.c also wants to declare
alloca as returning char *.
And if anybody feels a bit bored, here are a few interesting warnings:
cc: Warning: miscplay.c, line 384: In this statement, the expression "*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char ...)(src++)))/2)" modifies the variable "src" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 405: In this statement, the expression "*dest++=(unsigned char)(((int)*((signed char ...)(src++))+(int)*((signed char ...)(src++)))/2)^0X0000000000000080" modifies the variable "src" more than once without an intervening sequence point. This behavior is undefined. (undefvarmod)
*dest++ = (unsigned char)(((int)*((signed char *)(src++)) +
----^
cc: Warning: miscplay.c, line 496: In this statement, the expression "*p++=ulaw_dsp[*p]" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ulaw_dsp[*p];
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression "*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: miscplay.c, line 570: In this statement, the expression "*p++=((*p&0X00000000000000FF)<<8)|(*p>>8)" modifies "p", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined. (undefvarfetch)
*p++ = ((*p & 0x00ff) << 8) | (*p >> 8);
----^
cc: Warning: regex.c, line 5627: This statement uses the type "union declared without a tag" to reference the same storage location as the statement at line number 5627 in file regex.c, which uses the type "long". This does not conform to the ANSI aliasing rules. (badansialias)
POP_FAILURE_POINT (d, p,
----------^
cc: Warning: regex.c, line 5312: This statement uses the type "union declared without a tag" to reference the same storage location as the statement at line number 5312 in file regex.c, which uses the type "long". This does not conform to the ANSI aliasing rules. (badansialias)
POP_FAILURE_POINT (sdummy, pdummy,
------------^
Falk
- 3 participants
- 4 comments
Aufully flickering push-buttons
25 years
Nickolay Pakoulin
Nickolay Pakoulin
It seems that `push-button' widget flickers when displayed on the frame
border and is followed by text. To reproduce:
(progn
(require 'wid-edit)
(pop-to-buffer "TMP")
(erase-buffer)
(widget-insert (make-string 50 ?\ ) "Flickering button: ")
(set-frame-property (selected-frame) 'width 72)
(widget-create 'push-button :tag "Flicker"
:help-echo "Sometimes flickers"
:action '(lambda (&rest args) (kill-buffer "TMP")))
;; Without this dot it does not flicker
(widget-insert "."))
It happens with beta-38 on both linux with both motif and athena widgets.
On Windows 2000 the above written code results in two buttons -- one on the
first line and the second on the second.
Nick.
- 1 participants
- 0 comments
Goodbye
25 years
Andreas Jaeger
Andreas Jaeger
I've committed the appended patch as my last patch. Steve is handling
the packages fine and my free time is getting more and more limited.
I don't think I'll contribute any more to XEmacs (at least not in the
near future and not regularly) and therefore step down as member of
the XEmacs review board.
Btw. I've removed my ssh keys from the key rings at
cvs.xemacs.org/ftp.xemacs.org and will unsubscribe from the mailing
lists soon.
I hope you have a lot of fun with XEmacs and look forward to the best
Emacs ever: XEmacs 21.2 ;-)
All the best,
Andreas
2000-12-15 Andreas Jaeger <aj(a)suse.de>
* about.el (about-maintainer-info): Update my entry.
Index: lisp/about.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/about.el,v
retrieving revision 1.27.2.17
diff -u -r1.27.2.17 about.el
--- about.el 2000/02/17 06:30:14 1.27.2.17
+++ about.el 2000/12/15 14:38:10
＠＠ -990,9 +990,6 ＠＠
(widget-insert ".\n"))
(aj
(widget-insert "\
-In the XEmacs team I'm responsible for the packages which means mainly
-applying patches and packaging the packages.
-
I'm a software developer working for the SuSE Labs of the Linux
distributor SuSE. My main task is to improve the GNU C library.")
(widget-insert ".\n"))
--
Andreas Jaeger
SuSE Labs aj(a)suse.de
private aj(a)arthur.inka.de
http://www.suse.de/~aj
- 1 participants
- 0 comments
21.1.12 crash in DGifSlurp
25 years
Isaac Hollander
Isaac Hollander
I was merrily reading my mail with vm, using w3 to render HTML, when
xemacs keeled over. Unfortunately I couldn't reproduce the crash, but I
have the core. Stack trace and Installation follow: I'm not familiar
with the XEmacs gif code, I can't find any crashes in DGifSlurp in the
archives. The offending line appears to be
do {
===> if (AddExtensionBlock(sp, ExtData[0], ExtData+1) == GIF_ERROR)
GifInternError(GifFile, D_GIF_ERR_NOT_ENOUGH_MEM);
DGifGetExtensionNext(GifFile, &ExtData);
} while (ExtData != NULL);
If there's anything else I can do to narrow this down, please let me
know; meanwhile I'll try to make it happen again (and maybe I'll build
xemacs with -g...)
Thanks
Isaac
#0 0x4030dd21 in __kill () from /lib/libc.so.6
#1 0x809de81 in fatal_error_signal (sig=11) at emacs.c:263
#2 <signal handler called>
#3 0x80ab3e5 in DGifSlurp (GifFile=0x8c18c08) at dgif_lib.c:757
#4 0x80eae57 in gif_instantiate (image_instance=144626968,
instantiator=143722728, pointer_fg=136811764, pointer_bg=136811764,
dest_mask=47, domain=140933280) at glyphs-eimage.c:663
#5 0x80e73b0 in image_instantiate (specifier=143950976, matchspec=136605516,
domain=140933280, instantiator=143722728, depth=3) at glyphs.c:516
#6 0x80a03f0 in primitive_funcall (fn=0x80e7034 <image_instantiate>, nargs=5,
args=0xbfffa7c8) at eval.c:2862
#7 0x809fa6b in call_with_suspended_errors (
fun=0x80e7034 <image_instantiate>, retval=136605516, class=136911928,
errb=ERROR_ME, nargs=5) at eval.c:2137
#8 0x8125c61 in specifier_instance_from_inst_list (specifier=143950976,
matchspec=136605516, domain=140933280, inst_list=143374876, errb=ERROR_ME,
no_quit=0, depth=3) at specifier.c:2385
#9 0x8125efc in specifier_instance (specifier=143950976, matchspec=136605516,
domain=140933280, errb=ERROR_ME, no_quit=0, no_fallback=0, depth=1)
at specifier.c:2501
#10 0x8126054 in Fspecifier_instance (specifier=143950976, domain=136811764,
default_=136811764, no_fallback=136811764) at specifier.c:2591
#11 0x80a11be in funcall_recording_as (recorded_as=136925752, nargs=1,
args=0xbfffa9c8) at eval.c:3193
#12 0x80a518d in Ffuncall (nargs=2, args=0xbfffa9c8) at eval.c:3238
#13 0x8084b46 in Fbyte_code (bytestr=140981452, vector=141740408, maxdepth=7)
at bytecode.c:416
#14 0x80a0c6d in Feval (form=141797584) at eval.c:3063
#15 0x809f22d in condition_case_3 (bodyform=141797584, var=136811764,
handlers=141797500) at eval.c:1653
#16 0x8084fd3 in Fbyte_code (bytestr=140976932, vector=141881344, maxdepth=61)
at bytecode.c:576
#17 0x80a1ee1 in funcall_lambda (fun=141842144, nargs=1, arg_vector=0xbfffb65c)
at eval.c:3597
#18 0x80a13ce in funcall_recording_as (recorded_as=142089376, nargs=1,
args=0xbfffb658) at eval.c:3214
#19 0x80a518d in Ffuncall (nargs=2, args=0xbfffb658) at eval.c:3238
#20 0x8084b46 in Fbyte_code (bytestr=140978644, vector=141576856, maxdepth=11)
at bytecode.c:416
#21 0x80a1ee1 in funcall_lambda (fun=141841976, nargs=1, arg_vector=0xbfffb7e0)
at eval.c:3597
#22 0x80a13ce in funcall_recording_as (recorded_as=142089264, nargs=1,
args=0xbfffb7dc) at eval.c:3214
#23 0x80a18dc in Fapply (nargs=3, args=0xbfffb7dc) at eval.c:3238
#24 0x81488f4 in Fwidget_apply (nargs=2, args=0xbfffb914) at widget.c:107
#25 0x80a1288 in funcall_recording_as (recorded_as=136929136, nargs=2,
args=0xbfffb910) at eval.c:3197
#26 0x80a518d in Ffuncall (nargs=3, args=0xbfffb910) at eval.c:3238
#27 0x8084b46 in Fbyte_code (bytestr=140978372, vector=141576920, maxdepth=11)
at bytecode.c:416
#28 0x80a1ee1 in funcall_lambda (fun=141842004, nargs=2, arg_vector=0xbfffba90)
at eval.c:3597
#29 0x80a13ce in funcall_recording_as (recorded_as=142089208, nargs=2,
args=0xbfffba8c) at eval.c:3214
#30 0x80a18dc in Fapply (nargs=3, args=0xbfffba8c) at eval.c:3238
#31 0x81488f4 in Fwidget_apply (nargs=3, args=0xbfffbb50) at widget.c:107
#32 0x80a1288 in funcall_recording_as (recorded_as=136929136, nargs=3,
args=0xbfffbb4c) at eval.c:3197
#33 0x80a518d in Ffuncall (nargs=4, args=0xbfffbb4c) at eval.c:3238
#34 0x8084b46 in Fbyte_code (bytestr=141190916, vector=142099064, maxdepth=15)
at bytecode.c:416
#35 0x80a1ee1 in funcall_lambda (fun=142113632, nargs=2, arg_vector=0xbfffbc20)
at eval.c:3597
#36 0x80a1abd in apply_lambda (fun=142113632, numargs=2,
unevalled_args=136811764) at eval.c:3501
#37 0x80a0dac in Feval (form=142277424) at eval.c:3085
#38 0x809f22d in condition_case_3 (bodyform=142277424, var=136811764,
handlers=142277364) at eval.c:1653
#39 0x8084fd3 in Fbyte_code (bytestr=141251900, vector=142281832, maxdepth=7)
at bytecode.c:576
#40 0x80a0c6d in Feval (form=142277640) at eval.c:3063
#41 0x80a51ca in Fprogn (args=142277184) at eval.c:758
#42 0x8084f6c in Fbyte_code (bytestr=141252284, vector=142281976, maxdepth=5)
at bytecode.c:554
#43 0x80a1ee1 in funcall_lambda (fun=142232224, nargs=2, arg_vector=0xbfffc4f8)
at eval.c:3597
#44 0x80a13ce in funcall_recording_as (recorded_as=138227744, nargs=2,
args=0xbfffc4f4) at eval.c:3214
#45 0x80a518d in Ffuncall (nargs=3, args=0xbfffc4f4) at eval.c:3238
#46 0x8084b46 in Fbyte_code (bytestr=140447428, vector=140790464, maxdepth=11)
at bytecode.c:416
#47 0x80a0c6d in Feval (form=140697936) at eval.c:3063
#48 0x809f22d in condition_case_3 (bodyform=140697936, var=137183592,
handlers=140697624) at eval.c:1653
#49 0x8084fd3 in Fbyte_code (bytestr=140447604, vector=140790640, maxdepth=7)
at bytecode.c:576
#50 0x80a1ee1 in funcall_lambda (fun=140501592, nargs=1, arg_vector=0xbfffc930)
at eval.c:3597
#51 0x80a13ce in funcall_recording_as (recorded_as=140261924, nargs=1,
args=0xbfffc92c) at eval.c:3214
#52 0x80a518d in Ffuncall (nargs=2, args=0xbfffc92c) at eval.c:3238
#53 0x8084b46 in Fbyte_code (bytestr=140563172, vector=140790024, maxdepth=7)
at bytecode.c:416
#54 0x80a0c6d in Feval (form=140698320) at eval.c:3063
#55 0x809f22d in condition_case_3 (bodyform=140698320, var=136811764,
handlers=140705796) at eval.c:1653
#56 0x8084fd3 in Fbyte_code (bytestr=140564148, vector=140790144, maxdepth=13)
at bytecode.c:576
#57 0x80a1ee1 in funcall_lambda (fun=140501508, nargs=1, arg_vector=0xbfffd684)
at eval.c:3597
#58 0x80a13ce in funcall_recording_as (recorded_as=140251588, nargs=1,
args=0xbfffd680) at eval.c:3214
#59 0x80a518d in Ffuncall (nargs=2, args=0xbfffd680) at eval.c:3238
#60 0x8084b46 in Fbyte_code (bytestr=140553108, vector=140789656, maxdepth=13)
at bytecode.c:416
#61 0x80a1ee1 in funcall_lambda (fun=140501480, nargs=0, arg_vector=0xbfffd750)
at eval.c:3597
#62 0x80a1abd in apply_lambda (fun=140501480, numargs=0,
unevalled_args=136811764) at eval.c:3501
#63 0x80a0dac in Feval (form=140962420) at eval.c:3085
#64 0x809f22d in condition_case_3 (bodyform=140962420, var=136909956,
handlers=140962336) at eval.c:1653
#65 0x8084fd3 in Fbyte_code (bytestr=140977156, vector=140979208, maxdepth=13)
at bytecode.c:576
#66 0x80a1ee1 in funcall_lambda (fun=140966404, nargs=0, arg_vector=0xbfffe37c)
at eval.c:3597
#67 0x80a13ce in funcall_recording_as (recorded_as=140295984, nargs=0,
args=0xbfffe378) at eval.c:3214
#68 0x80a518d in Ffuncall (nargs=1, args=0xbfffe378) at eval.c:3238
#69 0x8084b46 in Fbyte_code (bytestr=140965068, vector=140978864, maxdepth=11)
at bytecode.c:416
#70 0x80a1ee1 in funcall_lambda (fun=140966376, nargs=0, arg_vector=0xbfffe580)
at eval.c:3597
#71 0x80a13ce in funcall_recording_as (recorded_as=139952360, nargs=0,
args=0xbfffe57c) at eval.c:3214
#72 0x80a518d in Ffuncall (nargs=1, args=0xbfffe57c) at eval.c:3238
#73 0x8084b46 in Fbyte_code (bytestr=142534572, vector=141597496, maxdepth=5)
at bytecode.c:416
#74 0x80a1ee1 in funcall_lambda (fun=143300320, nargs=1, arg_vector=0xbfffe6ac)
at eval.c:3597
#75 0x80a13ce in funcall_recording_as (recorded_as=143300320, nargs=1,
args=0xbfffe6a8) at eval.c:3214
#76 0x80a437b in call1 (fn=143300320, arg0=143238428) at eval.c:3238
#77 0x812d304 in mapatoms_1 (sym=143238428, arg=0xbfffe700) at symbols.c:404
#78 0x81296ed in Fmapatoms (function=143300320, obarray=144059344)
at symbols.c:391
#79 0x80a1288 in funcall_recording_as (recorded_as=136927276, nargs=2,
args=0xbffff2bc) at eval.c:3197
#80 0x80a518d in Ffuncall (nargs=3, args=0xbffff2bc) at eval.c:3238
#81 0x8084b46 in Fbyte_code (bytestr=142529652, vector=143886272,
maxdepth=15)
at bytecode.c:416
#82 0x80a1ee1 in funcall_lambda (fun=143300348, nargs=0, arg_vector=0xbffff41c)
at eval.c:3597
#83 0x80a13ce in funcall_recording_as (recorded_as=143300348, nargs=0,
args=0xbffff418) at eval.c:3214
#84 0x80a42ec in apply1 (fn=143300348, arg=136811764) at eval.c:3238
#85 0x8086042 in Fcall_interactively (function=139828056,
record_flag=136811764, keys=136811764) at callint.c:397
#86 0x80a00c8 in Fcommand_execute (cmd=139828056, record=136811764,
keys=136811764) at eval.c:2584
#87 0x80c1d12 in execute_command_event (command_builder=0x8399c48,
event=141845536) at event-stream.c:4346
#88 0x80c23d5 in Fdispatch_event (event=141845536) at event-stream.c:4685
#89 0x808ab6a in Fcommand_loop_1 () at cmdloop.c:579
#90 0x808ad2a in command_loop_1 (dummy=136811764) at cmdloop.c:494
#91 0x80a4e6b in condition_case_1 (handlers=136811876,
bfun=0x808ad14 <command_loop_1>, barg=136811764,
hfun=0x808a670 <cmd_error>, harg=136811764) at eval.c:1653
#92 0x808adfe in command_loop_2 (dummy=136811764) at cmdloop.c:256
#93 0x80a4d4f in internal_catch (tag=136886136,
func=0x808adcc <command_loop_2>, arg=136811764, threw=0x0) at eval.c:1328
#94 0x808a8ac in initial_command_loop (load_me=136811764) at cmdloop.c:305
#95 0x809ccc1 in xemacs_21_1_12_i686_pc_linux () at emacs.c:1720
#96 0x809e17d in main (argc=3, argv=0xbffff904, envp=0xbffff914)
at emacs.c:2137
#97 0x403079cb in __libc_start_main (main=0x809e078 <main>, argc=3,
argv=0xbffff904, init=0x80776c4 <_init>, fini=0x815ffe4 <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff8fc)
at ../sysdeps/generic/libc-start.c:92
uname -a: Linux yitzchak 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
./configure
XEmacs 21.1.12 "Channel Islands" configured for `i686-pc-linux'.
Where should the build process find the source code? /usr/local/src/xemacs-21.1.12
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
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 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 session-management.
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Compiling in DLL support.
movemail will use "dot-locking" for locking mail spool files.
Using Lisp_Objects with minimal tagbits.
- 1 participants
- 0 comments