December 2000 - XEmacs-Beta - XEmacs Mailing List Archives

21.1, 21.2: HOWTO create a package Texinfo 23 years, 4 months

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 23 years, 4 months

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 23 years, 4 months

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 23 years, 4 months

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? 23 years, 4 months

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 23 years, 4 months

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

End of Year Specials on HME Equipment 23 years, 4 months

The Rapid Group

1 participants
0 comments

Aufully flickering push-buttons 23 years, 4 months

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 23 years, 4 months

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 23 years, 4 months

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

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