Always initialize DEFVAR_LISP variables (was Re: Core dump in Benadir)
26 years, 4 months
SL Baur
SL Baur
Here's a sledgehammer test to detect stuff like this in the future (no
doubt there's room for optimzation, this is slow and pure brute force):
(mapatoms
(lambda (symbol)
(cond
((boundp symbol)
(prin1 (symbol-name symbol)) (terpri)
(prin1 (symbol-value symbol)) (terpri))
((fboundp symbol) (symbol-function symbol))
(t nil))))
1998-07-27 SL Baur <steve(a)altair.xemacs.org>
* keymap.c (vars_of_keymap): Initialize Vkey_translation_map and
Vvertical_divider_map.
Index: src/keymap.c
===================================================================
RCS file: /usr/local/xemacs/xemacs-20.0/src/keymap.c,v
retrieving revision 1.27
diff -u -r1.27 keymap.c
--- src/keymap.c 1998/05/16 05:07:06 1.27
+++ src/keymap.c 1998/07/28 03:38:38
＠＠ -4325,10 +4325,12 ＠＠
This keymap works like `function-key-map', but comes after that,
and applies even for keys that have ordinary bindings.
*/ );
+ Vkey_translation_map = Qnil;
DEFVAR_LISP ("vertical-divider-map", &Vvertical_divider_map /*
Keymap which handles mouse clicks over vertical dividers.
*/ );
+ Vvertical_divider_map = Qnil;
DEFVAR_INT ("keymap-tick", &keymap_tick /*
Incremented for each change to any keymap.
- 1 participants
- 0 comments
Re: [PATCH] Re: Core dump in Benadir
26 years, 4 months
SL Baur
SL Baur
This patch is broken :-( don't apply it. A correct one was just
posted to xemacs-patches. The CVS tree will be updated later tonight
or tomorrow.
SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
> 1998-07-27 SL Baur <steve(a)altair.xemacs.org>
> * mule-canna.c (vars_of_mule_canna): Initialize every symbol to
> Qnil or 0, none were initialized prior to this change.
- 1 participants
- 0 comments
Re: Core dump in Benadir
26 years, 4 months
SL Baur
SL Baur
Carsten Leonhardt <leo(a)arioch.oche.de> writes:
> That doesn't seem to be the case.
Dang! There's another unitialized built-in somewhere ...
$ src/xemacs -vanilla
Fatal error (11).
...
prin1-to-string(zsh: 20904 segmentation fault (core dumped) src/xemacs -vanilla
uname -a: Linux altair.xemacs.org 2.0.34 #1 Wed Jun 3 23:15:41 PDT 1998 i586
/home/xemacs/xemacs-20.0/configure '--with-gnu-make' '--srcdir=/home/xemacs/xemacs-20.0' '--cflags=-g' '--error-checking=all' '--debug=yes' '--use-union-type' '--without-x11' '--with-gpm=no' '--with-database=no' '--with-sound=no'
XEmacs 21.0 "Corsican" configured for `i586-pc-linux'.
Where should the build process find the source code? /home/xemacs/xemacs-20.0
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
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? none
Compiling in support for ncurses.
Compiling in DLL support.
movemail will use "dot-locking" for locking mail spool files.
Using the union type for Lisp_Objects.
Using Lisp_Objects with minimal tagbits.
Compiling in extra code for debugging.
Compiling in code for checking XEmacs memory usage.
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
elisp reader: REQUEST
26 years, 4 months
David Bakhash
David Bakhash
The following message is a courtesy copy of an article
that has been posted to comp.emacs.xemacs as well.
REQUEST:
Someone mentioned that one of the problems with the (X)Emacs Lisp
reader is that you can't do reader macros (as far as I know).
Specifically, there was mention of how elisp doesnt' recognize this to
be a vector:
#(1 2 3 4 5)
I think, first of all, that this should be interpreted as such. Even
more so, I think that reader macros should be allowed in elisp, such
that something like this would work:
(defmacro defdelim (left right param-list &body body)
"Define a new LISP delimiter!"
`(ddfn ,left ,right #'(lambda ,param-list ,＠body)))
(let ((rpar (get-macro-character #\))))
(defun ddfn (left right fn)
(set-macro-character right rpar)
(set-macro-character left
#'(lambda (stream char1 char2)
(declare (ignore char1 char2))
(apply fn
(read-delimited-list right stream t))))))
(defdelim #\[ #\] (&rest args)
`(vector ,＠args))
i.e. the functions `set-macro-character' and other reader functions
should be included. What do people think? This would be excellent
because then XEmacs would be an even better editor--it could more
easily be made to ``read'' various formats of files.
dave
- 1 participants
- 0 comments
Re: Any (brave :-) mew users?
26 years, 4 months
SL Baur
SL Baur
mh-e in XEmacs is Chuck's baby. These changes are O.K. with me, but I
gave up on mh-e long, long ago.
It would be most useful if the glimpse code is as modular as possible
so it can be used with Gnus nnml. That's pretty much the last feature
in exmh not in Gnus I miss.
The /etc/passwd completion should be integrated outside of mail
modes (IMO). I am finding it increasingly irritating that I can
type `~us[TAB]' and have it expanded to `~username/' in the shell,
but XEmacs beeps.
Darryl Okahata <darrylo(a)sr.hp.com> writes:
> SL Baur <steve(a)vmailer.xemacs.org> wrote:
>> Hrvoje Niksic <hniksic(a)srce.hr> writes:
>>
>> >> > What is ``mew''? "Messaging in an Emacs world" doesn't really tell
>> >> > much.
>>
>> It is a mail reader that evolved from a programmer's distaste for the
>> lack of development on mh-e.
> I've got a ton of local changes/modifications to mh-e. I've got no
> plans to submit them to the mh-e maintainer (as I don't have the time to
> get the legal paperwork done), but I could submit them to
> xemacs-patches. Would anyone be interested in the following?
> * Significant performance improvements by intelligent caching of folder
> contents (scans).
> * Automatic generation of folder names when refiling messages, based
> upon email addresses. For example, messages from "jdoe(a)foo.bar.com"
> get a default folder name of "jdoe". Optional elisp functions can be
> written to return default folder names, if the existing features are
> insufficient. [ Other people have written similar features for mh-e,
> but I believe my version has been around the longest, although poorly
> publicized. ]
> * Automatic alias completion, based upon MH aliases, sendmail aliases,
> and /etc/passwd. When entering email addresses at the "To:" prompt,
> the TAB key can be used to do email address completion. [ Other
> people have written similar features for mh-e, but I believe my
> version has been around the longest, although poorly publicized. ]
> * Automatic email address harvesting, for automatic email alias
> generation. Whenever a message is viewed, the sender's name/address
> can be automatically added to an internal database. The name/address
> is then available for alias completion. Harvesting can be done upon
> all folders, selected folders, or all folders but specified ones.
> Inspired by exmh (but, for some inexplicable reason, exmh doesn't make
> the address easily accessible for use in specifying "To:" & "cc:"
> addresses).
> * Update mode line to turn off the "new mail" icon after doing an "inc".
> * Optional ability to visit new MH folders in new frames. Visiting an
> existing, but iconified, MH folder causes the frame to be
> un-iconified.
> * Optional ability to quit mh-e by iconifying the mh-e frame, instead of
> killing the mh-e buffers.
> * Enhanced signature file processing. An optional elisp function can be
> specified to return a signature. This is useful for writing a
> function that scans the draft to determine an appropriate signature.
> I'm still hacking on my local mh-e. The next big feature that I'm going
> to add is an exmh-like interface to glimpse (this is a killer feature in
> exmh).
> However, the one possible downside to my changes is that the mh-e
> maintainer asked me to NOT begin any of my new mh-e functions with the
> "mh-" prefix. For example, mh-e functions start with "mh-" (e.g.,
> "mh-get-new-mail"). The maintainer asked me to not use the "mh-"
> prefix, and so all of my changes have a "y-mh-" prefix, which makes the
> code look odd, as functions begin with either "mh-" or "y-mh".
- 2 participants
- 1 comments
How do I build/bootstrap XEmacs+Mule from CVS sources
26 years, 4 months
Lonhyn T. Jasinskyj
Lonhyn T. Jasinskyj
I have checked out both xemacs-20 and xemacs-packages from the CVS
repository and am having problems building a latest-and-greatest
version with Mule turned on. What is the "correct" way to have the
basic packages (including Mule) installed when building for the first
time if you have checked out both the packages and the source from the
CVS tree?
The first sign of trouble is:
--------------------
EMACSBOOTSTRAPLOADPATH="/usr/local/src/xemacs-cvs/xemacs-20/src/../lisp/:/usr/lo
cal/src/xemacs-cvs/xemacs-20" ./temacs -batch -l /usr/local/src/xemacs-cvs/xemac
s-20/src/../lisp/update-elc.el
Loading /usr/local/src/xemacs-cvs/xemacs-20/src/../lisp/update-elc.el...
Loading very-early-lisp... (2152)
Loading find-paths.el... (13620)
Loading packages.el... (22724)
Loading setup-paths.el... (5444)
Loading dump-paths.el... (0)
Loading /usr/local/src/xemacs-cvs/xemacs-20/src/../lisp/dumped-lisp.el... (108)
"Error: Library file mule-charset not found"
--------------------
What is the canonical way that one should point things at the Mule package
when running configure?
I generally have things laid out as follows:
/usr/local/src/
xemacs-cvs/
xemacs-20/...
xemacs-packages/...
--------------------
and my configure is as follows:
./configure \
--cflags='-g -O2 -fno-strength-reduce -fno-caller-saves' \
--site-prefixes=/usr/pkg \
--with-gcc --debug --gung-ho \
--with-mule --with-xim=xlib \
--package-path='~/.xemacs::/usr/local/lib/xemacs-21-b50/mule-packages:/usr/local/lib/xemacs/mule-packages:/usr/local/lib/xemacs-21-b50/packages:/usr/local/lib/xemacs/packages:/usr/local/src/xemacs-cvs/xemacs-packages/mule:/usr/local/src/xemacs-cvs/xemacs-packages/mule-base:usr/local/src/xemacs-cvs/xemacs-packages'
No matter what I do it would seem that EMACSBOOTSTRAPLOADPATH (E20H?)
is not adequate to get to what I need. It seems that I need the .elc
files before everything else (because of dumped-lisp.el)? In addition
to that E20H is set to $lispdir:$blddir so it seems that this is not
the way it is intended to be done.
Help, what am I not seeing here? I would very much like to have a process
to build XEmacs from the CVS sources without anything else, even if it
takes additional grinding (i.e. non-Mule followed by Mule). I seem to
currently have a chicken and egg problem. I know that parts of this
have been discussed before but nothing I have dug up seems to apply here
(or, more likely, I am too thick-headed to see the solution).
mudd
(aka lonnie)
- 1 participants
- 0 comments
Re: Core dump in Benadir
26 years, 4 months
Carsten Leonhardt
Carsten Leonhardt
>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes:
sb> It's Mule related.
That doesn't seem to be the case. I now built several XEmacsen. My
initial report came from one compiled with Mule, egcc. I then tried
gcc without optimization, and without Mule, without union-type and so
on, until I built the one below (and the core dump is still with me).
sb> Hmm. Maybe I should try a Mule build without minimal tagbits.
I'm building one of those now, too.
[A few minutes later]
Yes, the same configuration as below, but without minimal tagbits
doesn't dump core.
[A few minutes earlier again]
BTW, when gdb gives me that:
"find_solib: Can't read pathname for load map: Input/output error"
should I worry?
HTH,
leo
Here my latest build:
uname -a: Linux elric 2.0.34 #4 Mon Jun 8 13:47:43 CEST 1998 i586 unknown
../xemacs-test/configure '--srcdir=/home/xemacs/xemacs-test' '--cflags=-g' '--debug' '--error-checking=all' '--use-union-type' '--without-x11' '--with-gpm=no' '--with-database=no' '--with-sound=no'
XEmacs 21.0 "Benadir" configured for `i586-pc-linux'.
Where should the build process find the source code? /home/xemacs/xemacs-test
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
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? none
Compiling in support for ncurses.
Compiling in DLL support.
movemail will use "dot-locking" for locking mail spool files.
Using the union type for Lisp_Objects.
Using Lisp_Objects with minimal tagbits.
Compiling in extra code for debugging.
Compiling in code for checking XEmacs memory usage.
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: ---------------------------------------------------------
$ ldd xemacs
libdl.so.2 => /lib/libdl.so.2 (0x4000f000)
libncurses.so.3.4 => /lib/libncurses.so.3.4 (0x40012000)
libm.so.6 => /lib/libm.so.6 (0x40057000)
libc.so.6 => /lib/libc.so.6 (0x40070000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Debian claims this is glibc 2.0.7pre3 and ncurses 1.9.9g.
lrwxrwxrwx 1 root root 14 Jun 10 13:21 /lib/libdl.so.2 -> libdl-2.0.7.so
-rw-r--r-- 1 root root 241972 May 25 16:22 /lib/libncurses.so.3.4
lrwxrwxrwx 1 root root 13 Jun 10 13:21 /lib/libm.so.6 -> libm-2.0.7.so
lrwxrwxrwx 1 root root 13 Jun 10 13:21 /lib/libc.so.6 -> libc-2.0.7.so
lrwxrwxrwx 1 root root 11 Jun 10 13:21 /lib/ld-linux.so.2 -> ld-2.0.7.so
$ gcc --version
2.7.2.3
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu"...
Core was generated by `/home/xemacs/test1/src/xemacs -vanilla'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error
#0 0x8141cbc in print_internal (obj={gu = {type = Lisp_Type_Record, val = 0},
s = {bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0, i = 0,
v = 0x0, cv = 0x0}, printcharfun={gu = {type = Lisp_Type_Record,
val = 34290013}, s = {bits = 0, val = 68580026}, u = {bits = 0,
val = 68580026}, ui = 137160052, i = 137160052, v = 0x82ce574,
cv = 0x82ce574}, escapeflag=1)
at /home/xemacs/xemacs-test/src/print.c:1061
1061 if (CONSP (obj) || VECTORP (obj) || COMPILED_FUNCTIONP (obj))
(gdb) bt
#0 0x8141cbc in print_internal (obj={gu = {type = Lisp_Type_Record, val = 0},
s = {bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0, i = 0,
v = 0x0, cv = 0x0}, printcharfun={gu = {type = Lisp_Type_Record,
val = 34290013}, s = {bits = 0, val = 68580026}, u = {bits = 0,
val = 68580026}, ui = 137160052, i = 137160052, v = 0x82ce574,
cv = 0x82ce574}, escapeflag=1)
at /home/xemacs/xemacs-test/src/print.c:1061
#1 0x8140800 in Fprin1 (object={gu = {type = Lisp_Type_Record, val = 0}, s = {
bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0, i = 0, v = 0x0,
cv = 0x0}, stream={gu = {type = Lisp_Type_Record, val = 34290013}, s = {
bits = 0, val = 68580026}, u = {bits = 0, val = 68580026},
ui = 137160052, i = 137160052, v = 0x82ce574, cv = 0x82ce574})
at /home/xemacs/xemacs-test/src/print.c:506
#2 0x80bac0a in Fbacktrace (stream={gu = {type = Lisp_Type_Record,
val = 34290013}, s = {bits = 0, val = 68580026}, u = {bits = 0,
val = 68580026}, ui = 137160052, i = 137160052, v = 0x82ce574,
cv = 0x82ce574}, detailed={gu = {type = Lisp_Type_Record,
val = 34263224}, s = {bits = 0, val = 68526448}, u = {bits = 0,
val = 68526448}, ui = 137052896, i = 137052896, v = 0x82b42e0,
cv = 0x82b42e0}) at /home/xemacs/xemacs-test/src/eval.c:4936
#3 0x80ac606 in fatal_error_signal (sig=11)
at /home/xemacs/xemacs-test/src/emacs.c:245
#4 0xbfffe490 in ?? ()
#5 0x814091d in Fprin1_to_string (object={gu = {type = Lisp_Type_Record,
val = 0}, s = {bits = 0, val = 0}, u = {bits = 0, val = 0}, ui = 0,
i = 0, v = 0x0, cv = 0x0}, noescape={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}) at /home/xemacs/xemacs-test/src/print.c:531
#6 0x80b6591 in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34289971}, s = {bits = 0,
val = 68579942}, u = {bits = 0, val = 68579942}, ui = 137159884,
i = 137159884, v = 0x82ce4cc, cv = 0x82ce4cc}, nargs=1, args=0xbfffe708)
at /home/xemacs/xemacs-test/src/eval.c:3193
#7 0x80b6c0b in Ffuncall (nargs=2, args=0xbfffe708)
at /home/xemacs/xemacs-test/src/eval.c:3238
#8 0x8082307 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record,
val = 34525993}, s = {bits = 0, val = 69051986}, u = {bits = 0,
val = 69051986}, ui = 138103972, i = 138103972, v = 0x83b4ca4,
cv = 0x83b4ca4}, vector={gu = {type = Lisp_Type_Record, val = 34517042},
s = {bits = 0, val = 69034084}, u = {bits = 0, val = 69034084},
ui = 138068168, i = 138068168, v = 0x83ac0c8, cv = 0x83ac0c8}, maxdepth={
gu = {type = Lisp_Type_Int_Even, val = 3}, s = {bits = 1, val = 6}, u = {
bits = 1, val = 6}, ui = 13, i = 13, v = 0xd, cv = 0xd})
at /home/xemacs/xemacs-test/src/bytecode.c:416
#9 0x80b7d5b in funcall_lambda (fun={gu = {type = Lisp_Type_Record,
val = 34522932}, s = {bits = 0, val = 69045864}, u = {bits = 0,
val = 69045864}, ui = 138091728, i = 138091728, v = 0x83b1cd0,
cv = 0x83b1cd0}, nargs=3, arg_vector=0xbfffead8)
at /home/xemacs/xemacs-test/src/eval.c:3597
#10 0x80b6a5c in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34479367}, s = {bits = 0,
val = 68958734}, u = {bits = 0, val = 68958734}, ui = 137917468,
i = 137917468, v = 0x838741c, cv = 0x838741c}, nargs=3, args=0xbfffead4)
at /home/xemacs/xemacs-test/src/eval.c:3200
#11 0x80b6c0b in Ffuncall (nargs=4, args=0xbfffead4)
at /home/xemacs/xemacs-test/src/eval.c:3238
#12 0x8082307 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record,
val = 34525731}, s = {bits = 0, val = 69051462}, u = {bits = 0,
val = 69051462}, ui = 138102924, i = 138102924, v = 0x83b488c,
cv = 0x83b488c}, vector={gu = {type = Lisp_Type_Record, val = 34516968},
s = {bits = 0, val = 69033936}, u = {bits = 0, val = 69033936},
ui = 138067872, i = 138067872, v = 0x83abfa0, cv = 0x83abfa0}, maxdepth={
gu = {type = Lisp_Type_Int_Even, val = 2}, s = {bits = 1, val = 4}, u = {
bits = 1, val = 4}, ui = 9, i = 9, v = 0x9, cv = 0x9})
at /home/xemacs/xemacs-test/src/bytecode.c:416
#13 0x80b7d5b in funcall_lambda (fun={gu = {type = Lisp_Type_Record,
val = 34522904}, s = {bits = 0, val = 69045808}, u = {bits = 0,
val = 69045808}, ui = 138091616, i = 138091616, v = 0x83b1c60,
cv = 0x83b1c60}, nargs=1, arg_vector=0xbfffedc8)
at /home/xemacs/xemacs-test/src/eval.c:3597
#14 0x80b6a5c in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34522904}, s = {bits = 0,
val = 69045808}, u = {bits = 0, val = 69045808}, ui = 138091616,
i = 138091616, v = 0x83b1c60, cv = 0x83b1c60}, nargs=1, args=0xbfffedc4)
at /home/xemacs/xemacs-test/src/eval.c:3200
#15 0x80b6c0b in Ffuncall (nargs=2, args=0xbfffedc4)
at /home/xemacs/xemacs-test/src/eval.c:3238
#16 0x80b85aa in call1 (fn={gu = {type = Lisp_Type_Record, val = 34522904},
s = {bits = 0, val = 69045808}, u = {bits = 0, val = 69045808},
ui = 138091616, i = 138091616, v = 0x83b1c60, cv = 0x83b1c60}, arg0={
gu = {type = Lisp_Type_Record, val = 34294427}, s = {bits = 0,
val = 68588854}, u = {bits = 0, val = 68588854}, ui = 137177708,
i = 137177708, v = 0x82d2a6c, cv = 0x82d2a6c})
at /home/xemacs/xemacs-test/src/eval.c:3921
#17 0x81842b9 in mapatoms_1 (sym={gu = {type = Lisp_Type_Record,
val = 34294427}, s = {bits = 0, val = 68588854}, u = {bits = 0,
val = 68588854}, ui = 137177708, i = 137177708, v = 0x82d2a6c,
cv = 0x82d2a6c}, arg=0xbfffee34)
at /home/xemacs/xemacs-test/src/symbols.c:408
#18 0x81841ad in map_obarray (obarray={gu = {type = Lisp_Type_Record,
val = 34263730}, s = {bits = 0, val = 68527460}, u = {bits = 0,
val = 68527460}, ui = 137054920, i = 137054920, v = 0x82b4ac8,
cv = 0x82b4ac8}, fn=0x81842a0 <mapatoms_1>, arg=0xbfffee34)
at /home/xemacs/xemacs-test/src/symbols.c:395
#19 0x818430c in Fmapatoms (function={gu = {type = Lisp_Type_Record,
val = 34522904}, s = {bits = 0, val = 69045808}, u = {bits = 0,
val = 69045808}, ui = 138091616, i = 138091616, v = 0x83b1c60,
cv = 0x83b1c60}, obarray={gu = {type = Lisp_Type_Record,
val = 34263730}, s = {bits = 0, val = 68527460}, u = {bits = 0,
val = 68527460}, ui = 137054920, i = 137054920, v = 0x82b4ac8,
cv = 0x82b4ac8}) at /home/xemacs/xemacs-test/src/symbols.c:422
#20 0x80b6591 in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34291868}, s = {bits = 0,
val = 68583736}, u = {bits = 0, val = 68583736}, ui = 137167472,
i = 137167472, v = 0x82d0270, cv = 0x82d0270}, nargs=1, args=0xbfffef38)
at /home/xemacs/xemacs-test/src/eval.c:3193
#21 0x80b6c0b in Ffuncall (nargs=2, args=0xbfffef38)
at /home/xemacs/xemacs-test/src/eval.c:3238
#22 0x8082307 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record,
val = 34525691}, s = {bits = 0, val = 69051382}, u = {bits = 0,
val = 69051382}, ui = 138102764, i = 138102764, v = 0x83b47ec,
cv = 0x83b47ec}, vector={gu = {type = Lisp_Type_Record, val = 34516990},
s = {bits = 0, val = 69033980}, u = {bits = 0, val = 69033980},
ui = 138067960, i = 138067960, v = 0x83abff8, cv = 0x83abff8}, maxdepth={
gu = {type = Lisp_Type_Int_Even, val = 2}, s = {bits = 1, val = 4}, u = {
bits = 1, val = 4}, ui = 9, i = 9, v = 0x9, cv = 0x9})
at /home/xemacs/xemacs-test/src/bytecode.c:416
#23 0x80b7d5b in funcall_lambda (fun={gu = {type = Lisp_Type_Record,
val = 34522911}, s = {bits = 0, val = 69045822}, u = {bits = 0,
val = 69045822}, ui = 138091644, i = 138091644, v = 0x83b1c7c,
cv = 0x83b1c7c}, nargs=2, arg_vector=0xbffff224)
at /home/xemacs/xemacs-test/src/eval.c:3597
#24 0x80b6a5c in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34442856}, s = {bits = 0,
val = 68885712}, u = {bits = 0, val = 68885712}, ui = 137771424,
i = 137771424, v = 0x83639a0, cv = 0x83639a0}, nargs=2, args=0xbffff220)
at /home/xemacs/xemacs-test/src/eval.c:3200
#25 0x80b6c0b in Ffuncall (nargs=3, args=0xbffff220)
at /home/xemacs/xemacs-test/src/eval.c:3238
#26 0x80884ce in Fcall_interactively (function={gu = {type = Lisp_Type_Record,
val = 34442856}, s = {bits = 0, val = 68885712}, u = {bits = 0,
val = 68885712}, ui = 137771424, i = 137771424, v = 0x83639a0,
cv = 0x83639a0}, record_flag={gu = {type = Lisp_Type_Record,
val = 34263224}, s = {bits = 0, val = 68526448}, u = {bits = 0,
val = 68526448}, ui = 137052896, i = 137052896, v = 0x82b42e0,
cv = 0x82b42e0}, keys={gu = {type = Lisp_Type_Record, val = 34263217},
s = {bits = 0, val = 68526434}, u = {bits = 0, val = 68526434},
ui = 137052868, i = 137052868, v = 0x82b42c4, cv = 0x82b42c4})
at /home/xemacs/xemacs-test/src/callint.c:935
#27 0x80b4875 in Fcommand_execute (cmd={gu = {type = Lisp_Type_Record,
val = 34442856}, s = {bits = 0, val = 68885712}, u = {bits = 0,
val = 68885712}, ui = 137771424, i = 137771424, v = 0x83639a0,
cv = 0x83639a0}, record={gu = {type = Lisp_Type_Record, val = 34263224},
s = {bits = 0, val = 68526448}, u = {bits = 0, val = 68526448},
ui = 137052896, i = 137052896, v = 0x82b42e0, cv = 0x82b42e0}, keys={
gu = {type = Lisp_Type_Record, val = 34263217}, s = {bits = 0,
val = 68526434}, u = {bits = 0, val = 68526434}, ui = 137052868,
i = 137052868, v = 0x82b42c4, cv = 0x82b42c4})
at /home/xemacs/xemacs-test/src/eval.c:2584
#28 0x80b65b5 in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34284237}, s = {bits = 0,
val = 68568474}, u = {bits = 0, val = 68568474}, ui = 137136948,
i = 137136948, v = 0x82c8b34, cv = 0x82c8b34}, nargs=2, args=0xbffff5e8)
at /home/xemacs/xemacs-test/src/eval.c:3193
#29 0x80b6c0b in Ffuncall (nargs=3, args=0xbffff5e8)
at /home/xemacs/xemacs-test/src/eval.c:3238
#30 0x8082307 in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record,
val = 34103063}, s = {bits = 0, val = 68206126}, u = {bits = 0,
val = 68206126}, ui = 136412252, i = 136412252, v = 0x8217c5c,
cv = 0x8217c5c}, vector={gu = {type = Lisp_Type_Record, val = 34103103},
s = {bits = 0, val = 68206206}, u = {bits = 0, val = 68206206},
ui = 136412412, i = 136412412, v = 0x8217cfc, cv = 0x8217cfc}, maxdepth={
gu = {type = Lisp_Type_Int_Even, val = 4}, s = {bits = 1, val = 8}, u = {
bits = 1, val = 8}, ui = 17, i = 17, v = 0x11, cv = 0x11})
at /home/xemacs/xemacs-test/src/bytecode.c:416
#31 0x80b7d5b in funcall_lambda (fun={gu = {type = Lisp_Type_Record,
val = 34103184}, s = {bits = 0, val = 68206368}, u = {bits = 0,
val = 68206368}, ui = 136412736, i = 136412736, v = 0x8217e40,
cv = 0x8217e40}, nargs=1, arg_vector=0xbffff8e4)
at /home/xemacs/xemacs-test/src/eval.c:3597
#32 0x80b6a5c in funcall_recording_as (recorded_as={gu = {
type = Lisp_Type_Record, val = 34348835}, s = {bits = 0,
val = 68697670}, u = {bits = 0, val = 68697670}, ui = 137395340,
i = 137395340, v = 0x8307c8c, cv = 0x8307c8c}, nargs=1, args=0xbffff8e0)
at /home/xemacs/xemacs-test/src/eval.c:3200
#33 0x80b6c0b in Ffuncall (nargs=2, args=0xbffff8e0)
at /home/xemacs/xemacs-test/src/eval.c:3238
#34 0x80884ce in Fcall_interactively (function={gu = {type = Lisp_Type_Record,
val = 34348835}, s = {bits = 0, val = 68697670}, u = {bits = 0,
val = 68697670}, ui = 137395340, i = 137395340, v = 0x8307c8c,
cv = 0x8307c8c}, record_flag={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}, keys={gu = {type = Lisp_Type_Record, val = 34263217},
s = {bits = 0, val = 68526434}, u = {bits = 0, val = 68526434},
ui = 137052868, i = 137052868, v = 0x82b42c4, cv = 0x82b42c4})
at /home/xemacs/xemacs-test/src/callint.c:935
#35 0x80b4875 in Fcommand_execute (cmd={gu = {type = Lisp_Type_Record,
val = 34348835}, s = {bits = 0, val = 68697670}, u = {bits = 0,
val = 68697670}, ui = 137395340, i = 137395340, v = 0x8307c8c,
cv = 0x8307c8c}, record={gu = {type = Lisp_Type_Record, val = 34263217},
s = {bits = 0, val = 68526434}, u = {bits = 0, val = 68526434},
ui = 137052868, i = 137052868, v = 0x82b42c4, cv = 0x82b42c4}, keys={
gu = {type = Lisp_Type_Record, val = 34263217}, s = {bits = 0,
val = 68526434}, u = {bits = 0, val = 68526434}, ui = 137052868,
i = 137052868, v = 0x82b42c4, cv = 0x82b42c4})
at /home/xemacs/xemacs-test/src/eval.c:2584
#36 0x80d918e in execute_command_event (command_builder=0x836ac18, event={
gu = {type = Lisp_Type_Record, val = 34481779}, s = {bits = 0,
val = 68963558}, u = {bits = 0, val = 68963558}, ui = 137927116,
i = 137927116, v = 0x83899cc, cv = 0x83899cc})
at /home/xemacs/xemacs-test/src/event-stream.c:4346
#37 0x80d992d in Fdispatch_event (event={gu = {type = Lisp_Type_Record,
val = 34481757}, s = {bits = 0, val = 68963514}, u = {bits = 0,
val = 68963514}, ui = 137927028, i = 137927028, v = 0x8389974,
cv = 0x8389974}) at /home/xemacs/xemacs-test/src/event-stream.c:4637
#38 0x808e503 in Fcommand_loop_1 ()
at /home/xemacs/xemacs-test/src/cmdloop.c:579
#39 0x808e266 in command_loop_1 (dummy={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}) at /home/xemacs/xemacs-test/src/cmdloop.c:494
#40 0x80b2ba5 in condition_case_1 (handlers={gu = {type = Lisp_Type_Record,
val = 34263245}, s = {bits = 0, val = 68526490}, u = {bits = 0,
val = 68526490}, ui = 137052980, i = 137052980, v = 0x82b4334,
cv = 0x82b4334}, bfun=0x808e240 <command_loop_1>, barg={gu = {
type = Lisp_Type_Record, val = 34263217}, s = {bits = 0,
val = 68526434}, u = {bits = 0, val = 68526434}, ui = 137052868,
i = 137052868, v = 0x82b42c4, cv = 0x82b42c4},
hfun=0x808d960 <cmd_error>, harg={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}) at /home/xemacs/xemacs-test/src/eval.c:1653
#41 0x808daaf in command_loop_3 ()
at /home/xemacs/xemacs-test/src/cmdloop.c:256
#42 0x808daec in command_loop_2 (dummy={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}) at /home/xemacs/xemacs-test/src/cmdloop.c:267
#43 0x80b2690 in internal_catch (tag={gu = {type = Lisp_Type_Record,
val = 34281796}, s = {bits = 0, val = 68563592}, u = {bits = 0,
val = 68563592}, ui = 137127184, i = 137127184, v = 0x82c6510,
cv = 0x82c6510}, func=0x808dae0 <command_loop_2>, arg={gu = {
type = Lisp_Type_Record, val = 34263217}, s = {bits = 0,
val = 68526434}, u = {bits = 0, val = 68526434}, ui = 137052868,
i = 137052868, v = 0x82b42c4, cv = 0x82b42c4}, threw=0x0)
at /home/xemacs/xemacs-test/src/eval.c:1328
#44 0x808dd6e in initial_command_loop (load_me={gu = {type = Lisp_Type_Record,
val = 34263217}, s = {bits = 0, val = 68526434}, u = {bits = 0,
val = 68526434}, ui = 137052868, i = 137052868, v = 0x82b42c4,
cv = 0x82b42c4}) at /home/xemacs/xemacs-test/src/cmdloop.c:305
#45 0x80ad708 in xemacs_21_0_i586_pc_linux (argc=2, argv=0xbffffdbc,
envp=0xbffffdc8, restart=0) at /home/xemacs/xemacs-test/src/emacs.c:1702
#46 0x80ae3e0 in main (argc=2, argv=0xbffffdbc, envp=0xbffffdc8)
at /home/xemacs/xemacs-test/src/emacs.c:2119
(gdb)
- 1 participants
- 0 comments
[PATCH] Re: Core dump in Benadir
26 years, 4 months
SL Baur
SL Baur
Marcus Thiessel <thiessel(a)hpbbse.bbn.hp.com> writes in xemacs-beta(a)xemacs.org:
> Yep, I can tried every combination if neccessay. Just give me the
> pointers where to find the same versions of Canna and Wnn(6) you are
> using.
Canna is the interesting one. I haven't tested Wnn4 and Wnn6 doesn't
appear to make a difference. [Newsflash ... the patch I just made to
mule-canna.c cures the crash for me].
You can get Canna from ftp://ftp.xemacs.org/pub/xemacs/aux/.
I'm using a hacked Canna 3.5b2.
> BTW, for testing I will switch to my 10.20 box which much faster but
> didn't crash as well.
I'm not submitting this patch to xemacs-patches yet. Please test it
if your XEmacs/Mule is crashing.
Note to Ben: Yes, I know all of the integer variables are misnamed
with the `V' prefix, I'm deciding whether I have time to mess with
renaming all of them.
1998-07-27 SL Baur <steve(a)altair.xemacs.org>
* mule-canna.c (vars_of_mule_canna): Initialize every symbol to
Qnil or 0, none were initialized prior to this change.
Index: src/mule-canna.c
===================================================================
RCS file: /usr/local/xemacs/xemacs-20.0/src/mule-canna.c,v
retrieving revision 1.11
diff -u -r1.11 mule-canna.c
--- src/mule-canna.c 1998/03/31 20:11:58 1.11
+++ src/mule-canna.c 1998/07/27 22:05:39
＠＠ -1052,464 +1052,721 ＠＠
DEFVAR_LISP ("canna-kakutei-string", &Vcanna_kakutei_string /*
*/ );
+ Vcanna_kakutei_string = Qnil;
+
DEFVAR_LISP ("canna-kakutei-yomi", &Vcanna_kakutei_yomi /*
*/ );
+ Vcanna_kakutei_yomi = Qnil;
+
DEFVAR_LISP ("canna-kakutei-romaji", &Vcanna_kakutei_romaji /*
*/ );
+ Vcanna_kakutei_romaji = Qnil;
+
DEFVAR_LISP ("canna-henkan-string", &Vcanna_henkan_string /*
*/ );
+ Vcanna_henkan_string = Qnil;
+
DEFVAR_INT ("canna-henkan-length", &Vcanna_henkan_length /*
*/ );
+ Vcanna_henkan_length = 0;
+
DEFVAR_INT ("canna-henkan-revpos", &Vcanna_henkan_revPos /*
*/ );
+ Vcanna_henkan_revPos = 0;
+
DEFVAR_INT ("canna-henkan-revlen", &Vcanna_henkan_revLen /*
*/ );
+ Vcanna_henkan_revLen = 0;
+
DEFVAR_LISP ("canna-ichiran-string", &Vcanna_ichiran_string /*
*/ );
+ Vcanna_ichiran_string = Qnil;
+
DEFVAR_INT ("canna-ichiran-length", &Vcanna_ichiran_length /*
*/ );
+ Vcanna_ichiran_length = 0;
+
DEFVAR_INT ("canna-ichiran-revpos", &Vcanna_ichiran_revPos /*
*/ );
+ Vcanna_ichiran_revPos = 0;
+
DEFVAR_INT ("canna-ichiran-revlen", &Vcanna_ichiran_revLen /*
*/ );
+ Vcanna_ichiran_revLen = 0;
+
DEFVAR_LISP ("canna-mode-string", &Vcanna_mode_string /*
*/ );
+ Vcanna_mode_string = Qnil;
DEFVAR_BOOL ("canna-empty-info", &Vcanna_empty_info /*
For canna
*/ );
+ Vcanna_empty_info = 0;
+
DEFVAR_BOOL ("canna-through-info", &Vcanna_through_info /*
For canna
*/ );
+ Vcanna_through_info = 0;
+
DEFVAR_BOOL ("canna-underline", &Vcanna_underline /*
For canna
*/ );
+ Vcanna_underline = 0;
+
DEFVAR_BOOL ("canna-inhibit-hankakukana", &Vcanna_inhibit_hankakukana /*
For canna
*/ );
+ Vcanna_inhibit_hankakukana = 0;
DEFVAR_INT ("canna-mode-alpha-mode", &Vcanna_mode_AlphaMode /*
*/ );
+ Vcanna_mode_AlphaMode = 0;
+
DEFVAR_INT ("canna-mode-empty-mode", &Vcanna_mode_EmptyMode /*
*/ );
+ Vcanna_mode_EmptyMode = 0;
+
DEFVAR_INT ("canna-mode-kigo-mode", &Vcanna_mode_KigoMode /*
*/ );
+ Vcanna_mode_KigoMode = 0;
+
DEFVAR_INT ("canna-mode-yomi-mode", &Vcanna_mode_YomiMode /*
*/ );
+ Vcanna_mode_YomiMode = 0;
+
DEFVAR_INT ("canna-mode-jishu-mode", &Vcanna_mode_JishuMode /*
*/ );
+ Vcanna_mode_JishuMode = 0;
+
DEFVAR_INT ("canna-mode-tankouho-mode", &Vcanna_mode_TankouhoMode /*
*/ );
+ Vcanna_mode_TankouhoMode = 0;
+
DEFVAR_INT ("canna-mode-ichiran-mode", &Vcanna_mode_IchiranMode /*
*/ );
+ Vcanna_mode_IchiranMode = 0;
+
DEFVAR_INT ("canna-mode-yes-no-mode", &Vcanna_mode_YesNoMode /*
*/ );
+ Vcanna_mode_YesNoMode = 0;
+
DEFVAR_INT ("canna-mode-on-off-mode", &Vcanna_mode_OnOffMode /*
*/ );
+ Vcanna_mode_OnOffMode = 0;
+
#ifdef CANNA_MODE_AdjustBunsetsuMode
DEFVAR_INT ("canna-mode-adjust-bunsetsu-mode",
&Vcanna_mode_AdjustBunsetsuMode /*
*/ );
+ Vcanna_mode_AdjustBunsetsuMode = 0;
#endif
#ifdef CANNA_MODE_ChikujiYomiMode
DEFVAR_INT ("canna-mode-chikuji-yomi-mode", &Vcanna_mode_ChikujiYomiMode /*
*/ );
+ Vcanna_mode_ChikujiYomiMode = 0;
+
DEFVAR_INT ("canna-mode-chikuji-bunsetsu-mode",
&Vcanna_mode_ChikujiTanMode /*
*/ );
+ Vcanna_mode_ChikujiTanMode = 0;
#endif
DEFVAR_INT ("canna-mode-henkan-mode", &Vcanna_mode_HenkanMode /*
*/ );
+ Vcanna_mode_HenkanMode = 0;
+
#ifdef CANNA_MODE_HenkanNyuryokuMode
DEFVAR_INT ("canna-mode-henkan-nyuuryoku-mode",
&Vcanna_mode_HenkanNyuryokuMode /*
*/ );
+ Vcanna_mode_HenkanNyuryokuMode = 0;
#endif
#ifdef CANNA_MODE_ZenHiraHenkanMode
DEFVAR_INT ("canna-mode-zen-hira-henkan-mode",
&Vcanna_mode_ZenHiraHenkanMode /*
*/ );
+ Vcanna_mode_ZenHiraHenkanMode = 0;
#ifdef CANNA_MODE_HanHiraHenkanMode
DEFVAR_INT ("canna-mode-han-hira-henkan-mode",
&Vcanna_mode_HanHiraHenkanMode /*
*/ );
+ Vcanna_mode_HanHiraHenkanMode = 0;
#endif
DEFVAR_INT ("canna-mode-zen-kata-henkan-mode",
&Vcanna_mode_ZenKataHenkanMode /*
*/ );
+ Vcanna_mode_ZenKataHenkanMode = 0;
+
DEFVAR_INT ("canna-mode-han-kata-henkan-mode",
&Vcanna_mode_HanKataHenkanMode /*
*/ );
+ Vcanna_mode_HanKataHenkanMode = 0;
+
DEFVAR_INT ("canna-mode-zen-alpha-henkan-mode",
&Vcanna_mode_ZenAlphaHenkanMode /*
*/ );
+ Vcanna_mode_ZenAlphaHenkanMode = 0;
+
DEFVAR_INT ("canna-mode-han-alpha-henkan-mode",
&Vcanna_mode_HanAlphaHenkanMode /*
*/ );
+ Vcanna_mode_HanAlphaHenkanMode = 0;
#endif
DEFVAR_INT ("canna-mode-zen-hira-kakutei-mode",
&Vcanna_mode_ZenHiraKakuteiMode /*
*/ );
+ Vcanna_mode_ZenHiraKakuteiMode = 0;
#ifdef CANNA_MODE_HanHiraKakuteiMode
DEFVAR_INT ("canna-mode-han-hira-kakutei-mode",
&Vcanna_mode_HanHiraKakuteiMode /*
*/ );
+ Vcanna_mode_HanHiraKakuteiMode = 0;
#endif
DEFVAR_INT ("canna-mode-zen-kata-kakutei-mode",
&Vcanna_mode_ZenKataKakuteiMode /*
*/ );
+ Vcanna_mode_ZenKataKakuteiMode = 0;
+
DEFVAR_INT ("canna-mode-han-kata-kakutei-mode",
&Vcanna_mode_HanKataKakuteiMode /*
*/ );
+ Vcanna_mode_HanKataKakuteiMode = 0;
+
DEFVAR_INT ("canna-mode-zen-alpha-kakutei-mode",
&Vcanna_mode_ZenAlphaKakuteiMode /*
*/ );
+ Vcanna_mode_ZenAlphaKakuteiMode = 0;
+
DEFVAR_INT ("canna-mode-han-alpha-kakutei-mode",
&Vcanna_mode_HanAlphaKakuteiMode /*
*/ );
+ Vcanna_mode_HanAlphaKakuteiMode = 0;
+
DEFVAR_INT ("canna-mode-hex-mode", &Vcanna_mode_HexMode /*
*/ );
+ Vcanna_mode_HexMode = 0;
+
DEFVAR_INT ("canna-mode-bushu-mode", &Vcanna_mode_BushuMode /*
*/ );
+ Vcanna_mode_BushuMode = 0;
+
DEFVAR_INT ("canna-mode-extend-mode", &Vcanna_mode_ExtendMode /*
*/ );
+ Vcanna_mode_ExtendMode = 0;
+
DEFVAR_INT ("canna-mode-russian-mode", &Vcanna_mode_RussianMode /*
*/ );
+ Vcanna_mode_RussianMode = 0;
+
DEFVAR_INT ("canna-mode-greek-mode", &Vcanna_mode_GreekMode /*
*/ );
+ Vcanna_mode_GreekMode = 0;
+
DEFVAR_INT ("canna-mode-line-mode", &Vcanna_mode_LineMode /*
*/ );
+ Vcanna_mode_LineMode = 0;
+
DEFVAR_INT ("canna-mode-changing-server-mode",
&Vcanna_mode_ChangingServerMode /*
*/ );
+ Vcanna_mode_ChangingServerMode = 0;
+
DEFVAR_INT ("canna-mode-henkan-method-mode",
&Vcanna_mode_HenkanMethodMode /*
*/ );
+ Vcanna_mode_HenkanMethodMode = 0;
+
DEFVAR_INT ("canna-mode-delete-dic-mode", &Vcanna_mode_DeleteDicMode /*
*/ );
+ Vcanna_mode_DeleteDicMode = 0;
+
DEFVAR_INT ("canna-mode-touroku-mode", &Vcanna_mode_TourokuMode /*
*/ );
+ Vcanna_mode_TourokuMode = 0;
+
DEFVAR_INT ("canna-mode-touroku-empty-mode",
&Vcanna_mode_TourokuEmptyMode /*
*/ );
+ Vcanna_mode_TourokuEmptyMode = 0;
+
DEFVAR_INT ("canna-mode-touroku-hinshi-mode",
&Vcanna_mode_TourokuHinshiMode /*
*/ );
+ Vcanna_mode_TourokuHinshiMode = 0;
+
DEFVAR_INT ("canna-mode-touroku-dic-mode", &Vcanna_mode_TourokuDicMode /*
*/ );
+ Vcanna_mode_TourokuDicMode = 0;
+
DEFVAR_INT ("canna-mode-quoted-insert-mode",
&Vcanna_mode_QuotedInsertMode /*
*/ );
+ Vcanna_mode_QuotedInsertMode = 0;
+
DEFVAR_INT ("canna-mode-bubun-muhenkan-mode",
&Vcanna_mode_BubunMuhenkanMode /*
*/ );
+ Vcanna_mode_BubunMuhenkanMode = 0;
+
DEFVAR_INT ("canna-mode-mount-dic-mode", &Vcanna_mode_MountDicMode /*
*/ );
+ Vcanna_mode_MountDicMode = 0;
DEFVAR_INT ("canna-func-self-insert", &Vcanna_fn_SelfInsert /*
*/ );
+ Vcanna_fn_SelfInsert = 0;
+
DEFVAR_INT ("canna-func-functional-insert", &Vcanna_fn_FunctionalInsert /*
*/ );
+ Vcanna_fn_FunctionalInsert = 0;
+
DEFVAR_INT ("canna-func-quoted-insert", &Vcanna_fn_QuotedInsert /*
*/ );
+ Vcanna_fn_QuotedInsert = 0;
+
DEFVAR_INT ("canna-func-japanese-mode", &Vcanna_fn_JapaneseMode /*
*/ );
+ Vcanna_fn_JapaneseMode = 0;
+
DEFVAR_INT ("canna-func-alpha-mode", &Vcanna_fn_AlphaMode /*
*/ );
+ Vcanna_fn_AlphaMode = 0;
+
DEFVAR_INT ("canna-func-henkan-nyuryoku-mode",
&Vcanna_fn_HenkanNyuryokuMode /*
*/ );
+ Vcanna_fn_HenkanNyuryokuMode = 0;
+
DEFVAR_INT ("canna-func-forward", &Vcanna_fn_Forward /*
*/ );
+ Vcanna_fn_Forward = 0;
+
DEFVAR_INT ("canna-func-backward", &Vcanna_fn_Backward /*
*/ );
+ Vcanna_fn_Backward = 0;
+
DEFVAR_INT ("canna-func-next", &Vcanna_fn_Next /*
*/ );
+ Vcanna_fn_Next = 0;
+
DEFVAR_INT ("canna-func-previous", &Vcanna_fn_Prev /*
*/ );
+ Vcanna_fn_Prev = 0;
+
DEFVAR_INT ("canna-func-beginning-of-line", &Vcanna_fn_BeginningOfLine /*
*/ );
+ Vcanna_fn_BeginningOfLine = 0;
+
DEFVAR_INT ("canna-func-end-of-line", &Vcanna_fn_EndOfLine /*
*/ );
+ Vcanna_fn_EndOfLine = 0;
+
DEFVAR_INT ("canna-func-delete-next", &Vcanna_fn_DeleteNext /*
*/ );
+ Vcanna_fn_DeleteNext = 0;
+
DEFVAR_INT ("canna-func-delete_previous", &Vcanna_fn_DeletePrevious /*
*/ );
+ Vcanna_fn_DeletePrevious = 0;
+
DEFVAR_INT ("canna-func-kill-to-end-of-line", &Vcanna_fn_KillToEndOfLine /*
*/ );
+ Vcanna_fn_KillToEndOfLine = 0;
+
DEFVAR_INT ("canna-func-henkan", &Vcanna_fn_Henkan /*
*/ );
+ Vcanna_fn_Henkan = 0;
+
DEFVAR_INT ("canna-func-kakutei", &Vcanna_fn_Kakutei /*
*/ );
+ Vcanna_fn_Kakutei = 0;
+
DEFVAR_INT ("canna-func-extend", &Vcanna_fn_Extend /*
*/ );
+ Vcanna_fn_Extend = 0;
+
DEFVAR_INT ("canna-func-shrink", &Vcanna_fn_Shrink /*
*/ );
+ Vcanna_fn_Shrink = 0;
+
#ifdef CANNA_FN_AdjustBunsetsu
DEFVAR_INT ("canna-func-adjust-bunsetsu", &Vcanna_fn_AdjustBunsetsu /*
*/ );
+ Vcanna_fn_AdjustBunsetsu = 0;
#endif
DEFVAR_INT ("canna-func-quit", &Vcanna_fn_Quit /*
*/ );
+ Vcanna_fn_Quit = 0;
+
DEFVAR_INT ("canna-func-convert-as-hex", &Vcanna_fn_ConvertAsHex /*
*/ );
+ Vcanna_fn_ConvertAsHex = 0;
+
DEFVAR_INT ("canna-func-convert-as-bushu", &Vcanna_fn_ConvertAsBushu /*
*/ );
+ Vcanna_fn_ConvertAsBushu = 0;
+
DEFVAR_INT ("canna-func-kouho-ichiran", &Vcanna_fn_KouhoIchiran /*
*/ );
+ Vcanna_fn_KouhoIchiran = 0;
+
DEFVAR_INT ("canna-func-bubun-muhenkan", &Vcanna_fn_BubunMuhenkan /*
*/ );
+ Vcanna_fn_BubunMuhenkan = 0;
+
DEFVAR_INT ("canna-func-zenkaku", &Vcanna_fn_Zenkaku /*
*/ );
+ Vcanna_fn_Zenkaku = 0;
+
DEFVAR_INT ("canna-func-hankaku", &Vcanna_fn_Hankaku /*
*/ );
+ Vcanna_fn_Hankaku = 0;
+
DEFVAR_INT ("canna-func-to-upper", &Vcanna_fn_ToUpper /*
*/ );
+ Vcanna_fn_ToUpper = 0;
+
DEFVAR_INT ("canna-func-capitalize", &Vcanna_fn_Capitalize /*
*/ );
+ Vcanna_fn_Capitalize = 0;
+
DEFVAR_INT ("canna-func-to-lower", &Vcanna_fn_ToLower /*
*/ );
+ Vcanna_fn_ToLower = 0;
+
DEFVAR_INT ("canna-func-hiragana", &Vcanna_fn_Hiragana /*
*/ );
+ Vcanna_fn_Hiragana = 0;
+
DEFVAR_INT ("canna-func-katakana", &Vcanna_fn_Katakana /*
*/ );
+ Vcanna_fn_Katakana = 0;
+
DEFVAR_INT ("canna-func-romaji", &Vcanna_fn_Romaji /*
*/ );
+ Vcanna_fn_Romaji = 0;
+
#ifdef CANNA_FN_BaseHiragana
DEFVAR_INT ("canna-func-base-hiragana", &Vcanna_fn_BaseHiragana /*
*/ );
+ Vcanna_fn_BaseHiragana = 0;
+
DEFVAR_INT ("canna-func-base-katakana", &Vcanna_fn_BaseKatakana /*
*/ );
+ Vcanna_fn_BaseKatakana = 0;
+
DEFVAR_INT ("canna-func-base-eisu", &Vcanna_fn_BaseEisu /*
*/ );
+ Vcanna_fn_BaseEisu = 0;
+
DEFVAR_INT ("canna-func-base-zenkaku", &Vcanna_fn_BaseZenkaku /*
*/ );
+ Vcanna_fn_BaseZenkaku = 0;
+
DEFVAR_INT ("canna-func-base-hankaku", &Vcanna_fn_BaseHankaku /*
*/ );
+ Vcanna_fn_BaseHankaku = 0;
+
DEFVAR_INT ("canna-func-base-kana", &Vcanna_fn_BaseKana /*
*/ );
+ Vcanna_fn_BaseKana = 0;
+
DEFVAR_INT ("canna-func-base-kakutei", &Vcanna_fn_BaseKakutei /*
*/ );
+ Vcanna_fn_BaseKakutei = 0;
+
DEFVAR_INT ("canna-func-base-henkan", &Vcanna_fn_BaseHenkan /*
*/ );
+ Vcanna_fn_BaseHenkan = 0;
+
DEFVAR_INT ("canna-func-base-hiragana-katakana-toggle",
&Vcanna_fn_BaseHiraKataToggle /*
*/ );
+ Vcanna_fn_BaseHiraKataToggle = 0;
+
DEFVAR_INT ("canna-func-base-zenkaku-hankaku-toggle",
&Vcanna_fn_BaseZenHanToggle /*
*/ );
+ Vcanna_fn_BaseZenHanToggle = 0;
+
DEFVAR_INT ("canna-func-base-kana-eisu-toggle",
&Vcanna_fn_BaseKanaEisuToggle /*
*/ );
+ Vcanna_fn_BaseKanaEisuToggle = 0;
+
DEFVAR_INT ("canna-func-base-kakutei-henkan-toggle",
&Vcanna_fn_BaseKakuteiHenkanToggle /*
*/ );
+ Vcanna_fn_BaseKakuteiHenkanToggle = 0;
+
DEFVAR_INT ("canna-func-base-rotate-forward",
&Vcanna_fn_BaseRotateForward /*
*/ );
+ Vcanna_fn_BaseRotateForward = 0;
+
DEFVAR_INT ("canna-func-base-rotate-backward",
&Vcanna_fn_BaseRotateBackward /*
*/ );
+ Vcanna_fn_BaseRotateBackward = 0;
+
#endif
DEFVAR_INT ("canna-func-extend-mode", &Vcanna_fn_ExtendMode /*
*/ );
+ Vcanna_fn_ExtendMode = 0;
+
DEFVAR_INT ("canna-func-touroku", &Vcanna_fn_Touroku /*
*/ );
+ Vcanna_fn_Touroku = 0;
+
DEFVAR_INT ("canna-func-hex-mode", &Vcanna_fn_HexMode /*
*/ );
+ Vcanna_fn_HexMode = 0;
+
DEFVAR_INT ("canna-func-bushu-mode", &Vcanna_fn_BushuMode /*
*/ );
+ Vcanna_fn_BushuMode = 0;
+
DEFVAR_INT ("canna-func-kigo-mode", &Vcanna_fn_KigouMode /*
*/ );
+ Vcanna_fn_KigouMode = 0;
+
#ifdef CANNA_FN_Mark
DEFVAR_INT ("canna-func-mark", &Vcanna_fn_Mark /*
*/ );
+ Vcanna_fn_Mark = 0;
#endif
#ifdef CANNA_FN_TemporalMode
DEFVAR_INT ("canna-func-temporal-mode", &Vcanna_fn_TemporalMode /*
*/ );
+ Vcanna_fn_TemporalMode = 0;
#endif
DEFVAR_INT ("canna-key-nfer", &Vcanna_key_Nfer /*
*/ );
+ Vcanna_key_Nfer = 0;
+
DEFVAR_INT ("canna-key-xfer", &Vcanna_key_Xfer /*
*/ );
+ Vcanna_key_Xfer = 0;
+
DEFVAR_INT ("canna-key-up", &Vcanna_key_Up /*
*/ );
+ Vcanna_key_Up = 0;
+
DEFVAR_INT ("canna-key-left", &Vcanna_key_Left /*
*/ );
+ Vcanna_key_Left = 0;
+
DEFVAR_INT ("canna-key-right", &Vcanna_key_Right /*
*/ );
+ Vcanna_key_Right = 0;
+
DEFVAR_INT ("canna-key-down", &Vcanna_key_Down /*
*/ );
+ Vcanna_key_Down = 0;
+
DEFVAR_INT ("canna-key-insert", &Vcanna_key_Insert /*
*/ );
+ Vcanna_key_Insert = 0;
+
DEFVAR_INT ("canna-key-rollup", &Vcanna_key_Rollup /*
*/ );
+ Vcanna_key_Rollup = 0;
+
DEFVAR_INT ("canna-key-rolldown", &Vcanna_key_Rolldown /*
*/ );
+ Vcanna_key_Rolldown = 0;
+
DEFVAR_INT ("canna-key-home", &Vcanna_key_Home /*
*/ );
+ Vcanna_key_Home = 0;
+
DEFVAR_INT ("canna-key-help", &Vcanna_key_Help /*
*/ );
+ Vcanna_key_Help = 0;
+
DEFVAR_INT ("canna-key-kp-key", &Vcanna_key_KP_Key /*
*/ );
+ Vcanna_key_KP_Key = 0;
+
DEFVAR_INT ("canna-key-shift-nfer", &Vcanna_key_Shift_Nfer /*
*/ );
+ Vcanna_key_Shift_Nfer = 0;
+
DEFVAR_INT ("canna-key-shift-xfer", &Vcanna_key_Shift_Xfer /*
*/ );
+ Vcanna_key_Shift_Xfer = 0;
+
DEFVAR_INT ("canna-key-shift-up", &Vcanna_key_Shift_Up /*
*/ );
+ Vcanna_key_Shift_Up = 0;
+
DEFVAR_INT ("canna-key-shift-left", &Vcanna_key_Shift_Left /*
*/ );
+ Vcanna_key_Shift_Left = 0;
+
DEFVAR_INT ("canna-key-shift-right", &Vcanna_key_Shift_Right /*
*/ );
+ Vcanna_key_Shift_Right = 0;
+
DEFVAR_INT ("canna-key-shift-down", &Vcanna_key_Shift_Down /*
*/ );
+ Vcanna_key_Shift_Down = 0;
+
DEFVAR_INT ("canna-key-control-nfer", &Vcanna_key_Cntrl_Nfer /*
*/ );
+ Vcanna_key_Cntrl_Nfer = 0;
+
DEFVAR_INT ("canna-key-control-xfer", &Vcanna_key_Cntrl_Xfer /*
*/ );
+ Vcanna_key_Cntrl_Xfer = 0;
+
DEFVAR_INT ("canna-key-control-up", &Vcanna_key_Cntrl_Up /*
*/ );
+ Vcanna_key_Cntrl_Up = 0;
+
DEFVAR_INT ("canna-key-control-left", &Vcanna_key_Cntrl_Left /*
*/ );
+ Vcanna_key_Cntrl_Left = 0;
+
DEFVAR_INT ("canna-key-control-right", &Vcanna_key_Cntrl_Right /*
*/ );
+ Vcanna_key_Cntrl_Right = 0;
+
DEFVAR_INT ("canna-key-control-down", &Vcanna_key_Cntrl_Down /*
*/ );
+ Vcanna_key_Cntrl_Down = 0;
Fprovide(intern("CANNA"));
}
- 2 participants
- 3 comments
Re: Other packaging issues I've been slapped in the face with
26 years, 4 months
Michael Sperber
Michael Sperber
>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes:
APA> [1 <text/plain; US-ASCII (7bit)>]
>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes:
sb> Footnotes:
sb> [1] Michael, when is the next update of EFS scheduled?
Michael> Just prior to the 21.0 release, and I had the exact same issues in
Michael> mind as you. All changes I've been accumulating have been pretty
Michael> minor, so I've been hesitant cutting another release before it became
Michael> necessary..
APA> Hello Michael,
APA> will this update of EFS include/exceed the EFS patches to make it work
APA> on Windows NT? [ forwarded message ]
Well, guys, I guess I'll look into the issue, but it's kind of hard to
do this when you send patches to a mailing list I don't read instead
of the EFS lists, as documented in the manual and available via M-x
efs-report-bug. (I knew that there was an issue with NT, and
specifically asked to be sent a more detailed account, but never got
any.)
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 2 participants
- 1 comments
Re: Core dump in Benadir
26 years, 4 months
SL Baur
SL Baur
SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
> Can you try building with one of Canna or Wnn and see if that
> provokes a crash?
Canna will be the most productive. If I build without Canna, the
crash goes away.
Looking at mule-canna.c it appears that some of the variables may be
unitialized.
- 1 participants
- 0 comments