font-lock and autoload is broken
23 years, 9 months
Steve Youngs
Steve Youngs
Currently, I have to use an old version of font-lock.el and a locally
patched version of autoload.el just to get through my day.
Without the old font-lock.el XEmacs just sits there eating up the CPU
whenever it tries to fontify anything. It doesn't crash, but nothing
can be done until after repeated C-g's.
And I can't build the packages with the current autoload.el. I get an
"Unbalanced Parentheses" error when trying to create auto-autoloads.
I'm pretty sure that both of these things are related to Matt Tucker's
recent syntax-table tom-foolery (no offense Matt, I'm angry at my
computer, not you).
Matt, could you please, please fix this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
- 5 participants
- 16 comments
base64-encode-region
23 years, 9 months
Steve Youngs
Steve Youngs
I've been discussing with Kyle a problem with VM and
base64-encode-region. He had this to say:
,----
| Steve Youngs writes:
| > |--==> "KJ" == Kyle Jones <kyle_jones(a)wonderworks.com> writes:
| >
| > KJ> OK, so much for my fix. I'll make a new one in 6.91.
| >
| > OK. Is there anything that 6.90 users can do in the meantime as a
| > work around?
|
| Well, you folks could make your base64-encode-region compatible with
| the FSF Emacs version. You'll find that mailer writers will want
| the third arg anyway to do B-encoding.
`----
Could somebody please look into this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
- 6 participants
- 11 comments
21.2.44@Solaris8 & tab bar
23 years, 9 months
Marco Walther
Marco Walther
Hi,
I've got the latest beta sources today (cvs gtk-xemacs-21-2). I was
able to build both (with & without GTK support) in my environment.
But I've found one problem which shows up differently in both but I
believe it's related:
The `tab bar' (what's the right term for this ?) seems to have some
problems.
In the GTK version it's most of the time located under (not below) the
toolbar. When I change buffers I'm sometimes able to see the tabs
before the toolbar gets updated.
In the !GTK version the tab bar is there most of the time except when
I iconify the Frame and later deiconify it. Than the tab bar is gone
until I change buffers. Than it's there again
Thanks,
-- Marco Walther
---------------------------------------------------------------------------
> XEmacs Build Report generated by emacs-version
> 21.2 (beta44) "Thalia" XEmacs Lucid
> with system-configuration
> sparc-sun-solaris2.8
> follows:
> Contents of /reddisk1/marco/xemacs/xemacs-beta/xemacs-21.2/Installation:
> (Output from most recent run of ./configure)
uname -a: SunOS jena 5.8 Generic sun4u sparc
./configure '--prefix=/export/home/marcow/usr/local' '--site-includes=/export/home/marcow/usr/local/include' '--site-libraries=/export/home/marcow/usr/local/lib' '--with-gtk=no'
XEmacs 21.2-b44 "Thalia" configured for `sparc-sun-solaris2.8'.
Compilation / Installation:
Source code location: /reddisk1/marco/xemacs/xemacs-beta/xemacs-21.2
Installation prefix: /export/home/marcow/usr/local
Additional header files: /export/home/marcow/usr/local/include
Additional libraries: /export/home/marcow/usr/local/lib
Runtime library search path: /usr/ccs/lib:/export/home/marcow/usr/local/lib:/usr/dt/lib:/usr/openwin/lib
Operating system description file: `s/sol2.h'
Machine description file: `m/sparc.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wpointer-arith
Relocating allocator for buffers: yes
GNU version of malloc: yes
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/dt/include /usr/openwin/include
- X Windows libraries location: /usr/dt/lib /usr/openwin/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Compiling in support for ESD (Enlightened Sound Daemon).
Databases:
Compiling in support for Berkeley database.
Compiling in support for GNU DBM.
Compiling in support for LDAP.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for ToolTalk.
Compiling in support for dynamic shared object modules.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
- 1 participants
- 0 comments
some screwiness in package build
23 years, 9 months
Jeff Miller
Jeff Miller
I've done a cvs update of xemacs and the packages tonight. Building
the packages for the first time in a long time.
Using non-mule xemacs, once I hit the xemacs-base package, I keep
getting an error about during make bindist (i've done make autoloads first)
xemacs -vanilla -batch \
-l package-info -f batch-update-package-info \
'1.49' /pics/pics/packages/xemacs-packages/../Packages/xemacs-base-1.49-pkg.tar.gz \
'' \
'' 'XEmacs Development Team <xemacs-beta(a)xemacs.org>' 'libs'
Symbol's function definition is void: xemacs-base
xemacs exiting
.
make[2]: *** [package-info] Error 255
make[2]: Leaving directory `/pics/pics/packages/xemacs-packages/libs/xemacs-base'
make[1]: *** [xemacs-base/bindist.target] Error 2
make[1]: Leaving directory `/pics/pics/packages/xemacs-packages/libs'
make: *** [libs/bindist.target] Error 2
I can get around this IF i remove the package-info file from the
xemacs directory. If I do "make bindist" again, the build will
continue along untile fsf-compat, and then die with a similar error.
if i remove that package-info, then it just dies on the xemacs-base
build again.
the only way i can get it to got through completely is to remove all
package-info files before each "make bindist". Somehow, this just
doesn't seem right. Am i just missing a crucial step somplace?
Jeff
- 1 participants
- 0 comments
Re: xemacs installation
23 years, 9 months
Vin Shelton
Vin Shelton
Martin recently submitted a patch for the problem of building under
OSF5, so you should be able to build 21.1 from the latest CVS sources (see
cvs.xemacs.org for details of how to access CVS). Or, you could apply
this patch, run autoconf and try again:
--- /usr/local/src/xemacs-21.1.14/configure.in Fri Jan 12 22:07:32 2001
+++ /home/acs/cvsroot/xemacs-21.1/configure.in Thu Feb 8 21:28:38 2001
＠＠ -1063,7 +1063,7 ＠＠
*-dec-osf1.2 | *-dec-osf1* ) opsys=decosf1-2 ;;
*-dec-osf3.[[2-9]] ) opsys=decosf3-2 ;;
*-dec-osf3* ) opsys=decosf3-1 ;;
- *-dec-osf4* ) opsys=decosf4-0 ;;
+ *-dec-osf[[4-9]]* ) opsys=decosf4-0 ;;
dnl DEC Ultrix
*-*-ultrix[[0-3]].* | *-*-ultrix4.0* ) opsys=bsd4-2 ;;
＠＠ -2740,7 +2740,8 ＠＠
if test -z "$with_xpm"; then
AC_MSG_CHECKING(for Xpm - no older than 3.4f)
xe_check_libs=-lXpm
- AC_TRY_RUN([#include <X11/xpm.h>
+ AC_TRY_RUN([#define XPM_NUMBERS
+#include <X11/xpm.h>
int main(int c, char **v) {
return c == 1 ? 0 :
XpmIncludeVersion != XpmLibraryVersion() ? 1 :
＠＠ -2768,6 +2769,9 ＠＠
AC_MSG_RESULT($with_xpm)
fi
if test "$with_xpm" = "yes"; then
+ dnl #### This code assumes that if AC_CHECK_LIB fails,
+ dnl #### then it will succeed if FOR_MSW is defined,
+ dnl #### but doesn't actually verify this assumption.
AC_DEFINE(HAVE_XPM)
XE_PREPEND(-lXpm, libs_x)
AC_MSG_CHECKING(for \"FOR_MSW\" xpm)
Let me know if this works for you.
- vin
Dylan Righi <drighi(a)OCE.ORST.EDU> writes:
> Hello....
>
> Two questions related to attempting to install Xemacs.
> My computer was recently upgraded (the bastards!) and as a result the
> version of Xemacs I had installed wouldn't run, so I thought it might be a
> good time to upgrade Xemacs. The computer is a Compaq alpha running
> OSF1v5.0
>
> But downloading the xemacs-21.1.13 source code and attempting to configure
> tells me:
>
> checking host system type... alphaev6-dec-osf5.0
> checking whether ln -s works... yes
> checking the configuration name
> configure: XEmacs hasn't been ported to `alphaev6-dec-osf5.0' systems.
> configure: Check `etc/MACHINES' for recognized configuration names.
>
> OK, fair enough.
>
>
> I also have access to an older alpha that still has OSF1/v4.0 and thought
> I could try installing on that machine. There, it makes it through the
> config, and a large part of make, but trips with the error:
>
> emacs.c:2770: `EMACS_MAJOR_VERSION' undeclared (first use in this
> function)
> emacs.c:2770: (Each undeclared identifier is reported only once
> emacs.c:2770: for each function it appears in.)
> emacs.c:2778: `EMACS_MINOR_VERSION' undeclared (first use in this
> function)
> make[1]: *** [emacs.o] Error 1
> make[1]: Leaving directory `/home/pisco/usr3/drighi/xemacs-21.1.13/src'
> make: *** [src] Error 2
>
> Any pointers on fixes for this?
>
>
> I also tried downloading the binaries. Running
> bin/alpha-dec-osf4.0/xemacs results in:
> allocate_nearest_color returned 0!!!
> allocate_nearest_color returned 0!!!
> Warning: Cannot allocate colormap entry for "Gray80"
> allocate_nearest_color returned 0!!!
> allocate_nearest_color returned 0!!!
> Help! x_get_gc got a bogus fg value! fg = #<INTERNAL EMACS BUG
> (symbol-value-forward type 13) 0x14012c590>
> Fatal error (11).
>
>
> I would appreciate any help. Thanks.
> -Dylan
> --
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dylan Righi drighi(a)oce.orst.edu
> Oceanic and Atmospheric Sciences
> Oregon State University
> 104 Ocean Admin Bldg voice: 541 737-5751
> Corvallis, OR 97331-5503 fax: 541 737-2064
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- 1 participants
- 0 comments
[Dylan Righi <drighi@OCE.ORST.EDU>] xemacs installation
23 years, 9 months
Adrian Aichner
Adrian Aichner
Anybody here willing to get back to Dylan on his problems?
Best regards,
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
- 1 participants
- 0 comments
21.4 Release postponed to March 15
23 years, 9 months
Stephen J. Turnbull
Stephen J. Turnbull
Due to personal circumstances, day job, and poor personal time
management, I've badly missed the deadline for the last major status
report (originally scheduled for February 15) before the 21.4 release.
Since I won't get it finished for a day or so yet, this entails a
delay in the release.
My apologies for the delay.
The new release target is March 15, 2001.
As far as I know, there are no development problems warranting a
delay. In the last couple of days, Martin Buchholz provided two
patches and Matt Tucker a third that took care of the three
showstoppers I know of offhand. However, my knowledge at the moment
is not as complete and accurate as it should be. (Management holding
up the developers ... sound familiar?) I need to put out a status
report, and get the developers' responses, with some lead time before
the release.
Bill Perry is still committing stuff to the separate GTK branch.
Pending a status report from him on the merge and my investigation of
the build reports, I still hope to propose merging that code back to
the release branch. So it is important to continue building
--with-gtk=no and submit build reports on all platforms (not just
GTK-capable ones).
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
- 1 participants
- 0 comments
CORE in gnus during reply
23 years, 9 months
Norbert Koch
Norbert Koch
Hi!
I was trying to remove a region in gnus when seeing this "behaviour":
"XEmacs 21.2 (beta44) \"Thalia\" [Lucid] (i386-unknown-freebsd3.3,
Mule) of Tue Feb 20 2001 on lamia.LF.net"
This includes Matt's recent patches.
Lisp-Trace
call-interactively(kill-region)
# (condition-case ... . error)
# (catch top-level ...)
Abort trap (core dumped)
C-Trace
#0 0x185653d0 in kill () from /usr/lib/libc.so.3
(gdb) where
#0 0x185653d0 in kill () from /usr/lib/libc.so.3
#1 0x80c77c3 in fatal_error_signal (sig=6) at emacs.c:535
#2 0xbfbfdfdc in ?? ()
#3 0x80cabda in assert_failed (file=0x830cd06 "lisp.h", line=1397,
expr=0x830ce60 "RECORD_TYPEP (obj, lrecord_type_marker)") at emacs.c:3214
#4 0x81abcd7 in marker_position (marker={gu = {type = Lisp_Type_Int_Even,
val = 35564375}, s = {bits = 1, val = 71128750}, u = {bits = 1,
val = 71128750}, ui = 142257501, i = 142257501, v = 0x87aad5d,
cv = 0x87aad5d}) at lisp.h:1397
#5 0x80a49e4 in Fcall_interactively (function={gu = {type = Lisp_Type_Record,
val = 102227456}, s = {bits = 0, val = 204454912}, u = {bits = 0,
val = 204454912}, ui = 408909824, i = 408909824, v = 0x185f7800,
cv = 0x185f7800}, record_flag={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}, keys={gu = {type = Lisp_Type_Record, val = 102242654},
s = {bits = 0, val = 204485308}, u = {bits = 0, val = 204485308},
ui = 408970616, i = 408970616, v = 0x18606578, cv = 0x18606578})
at callint.c:936
#6 0x80cfabd in Fcommand_execute (cmd={gu = {type = Lisp_Type_Record,
val = 102227456}, s = {bits = 0, val = 204454912}, u = {bits = 0,
val = 204454912}, ui = 408909824, i = 408909824, v = 0x185f7800,
cv = 0x185f7800}, record_flag={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}, keys={gu = {type = Lisp_Type_Record, val = 102242654},
s = {bits = 0, val = 204485308}, u = {bits = 0, val = 204485308},
ui = 408970616, i = 408970616, v = 0x18606578, cv = 0x18606578})
at eval.c:2970
#7 0x812de09 in execute_command_event (command_builder=0x84cd440, event={
gu = {type = Lisp_Type_Record, val = 34886918}, s = {bits = 0,
val = 69773836}, u = {bits = 0, val = 69773836}, ui = 139547672,
i = 139547672, v = 0x8515418, cv = 0x8515418}) at event-stream.c:3834
#8 0x812ea2d in Fdispatch_event (event={gu = {type = Lisp_Type_Record,
val = 34886918}, s = {bits = 0, val = 69773836}, u = {bits = 0,
val = 69773836}, ui = 139547672, i = 139547672, v = 0x8515418,
cv = 0x8515418}) at event-stream.c:4165
#9 0x80ae6fd in Fcommand_loop_1 () at cmdloop.c:583
#10 0x80ae9a2 in command_loop_1 (dummy={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}) at cmdloop.c:494
#11 0x80d6efa in condition_case_1 (handlers={gu = {type = Lisp_Type_Record,
val = 102242558}, s = {bits = 0, val = 204485116}, u = {bits = 0,
val = 204485116}, ui = 408970232, i = 408970232, v = 0x186063f8,
cv = 0x186063f8}, bfun=0x80ae964 <command_loop_1>, barg={gu = {
type = Lisp_Type_Record, val = 102242654}, s = {bits = 0,
val = 204485308}, u = {bits = 0, val = 204485308}, ui = 408970616,
i = 408970616, v = 0x18606578, cv = 0x18606578},
hfun=0x80aea14 <cmd_error>, harg={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}) at eval.c:1651
#12 0x80aeb0f in command_loop_2 (dummy={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}) at cmdloop.c:256
#13 0x80d6dfc in internal_catch (tag={gu = {type = Lisp_Type_Record,
val = 102194036}, s = {bits = 0, val = 204388072}, u = {bits = 0,
val = 204388072}, ui = 408776144, i = 408776144, v = 0x185d6dd0,
cv = 0x185d6dd0}, func=0x80aead0 <command_loop_2>, arg={gu = {
type = Lisp_Type_Record, val = 102242654}, s = {bits = 0,
val = 204485308}, u = {bits = 0, val = 204485308}, ui = 408970616,
i = 408970616, v = 0x18606578, cv = 0x18606578}, threw=0x0)
at eval.c:1317
#14 0x80adf67 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record,
val = 102242654}, s = {bits = 0, val = 204485308}, u = {bits = 0,
val = 204485308}, ui = 408970616, i = 408970616, v = 0x18606578,
cv = 0x18606578}) at cmdloop.c:305
#15 0x80c8d21 in xemacs_21_2_b44_i386_unknown_freebsd3_3 (argc=4,
argv=0xbfbfd680, envp=0xbfbfd694, restart=0) at emacs.c:2253
#16 0x80cadfe in main (argc=4, argv=0xbfbfd680, envp=0xbfbfd694)
at emacs.c:2620
norbert.
- 5 participants
- 8 comments
Dump while making bindist on packages
23 years, 9 months
Norbert Koch
Norbert Koch
Hi!
make bindist currently has a hard landing:
gmake[3]: Entering directory `/usr/local/users/support/nk/cvs/xemacs-packages/co
mm/tm/texi'
xemacs -batch -q -no-site-file tm-ja.texi \
-eval '(unless (featurep (quote mule)) (kill-emacs 0))' \
-l texinfmt -f texinfo-format-buffer \
-eval '(setq file-coding-system (quote iso-2022-7))' \
-eval '(save-buffer 0)'
Formatting Info file...
Formatting Info file: tm-ja.info
Converting tm-ja.texi to Info format...
Removing trailing whitespace from Info buffer...
Formatting: tm 7.100 Manual~~~~~~ ...
Formatting: tm ~~~~ ...
Formatting: ~~ ...
Formatting: 7bit ... Fatal error: assertion failed, file insdel.c, line 1122, VA
LID_BYTIND_P (buf, x)
gmake[3]: *** [tm-ja.info] Abort trap (core dumped)
gmake[3]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m/tm/texi'
gmake[2]: *** [texi] Error 2
gmake[2]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m/tm'
gmake[1]: *** [tm/bindist.target] Error 2
gmake[1]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m'
gmake: *** [comm/bindist.target] Error 2
xemacs expands to
"XEmacs 21.2 (beta44) \"Thalia\" [Lucid] (i386-unknown-freebsd3.3,
Mule) of Sun Feb 18 2001 on lamia.LF.net"
The c-trace is
#0 0x1856b3d0 in kill () from /usr/lib/libc.so.3
#1 0x1859f728 in abort () from /usr/lib/libc.so.3
#2 0x80c977a in assert_failed (file=0x82eaa51 "insdel.c", line=1122,
expr=0x82ea44f "VALID_BYTIND_P (buf, x)") at emacs.c:3214
#3 0x8190d52 in bytind_to_bufpos (buf=0x8464200, x=203) at insdel.c:1122
#4 0x81dbeaa in re_match_2 (bufp=0x83f55b4,
string1=0x857116f "\222¤·\222¤«\222¤·\222¡¢7bit \222¤Ç\222¤¢\222¤ì\222¤Ð\222¤É\222¤ó\222¤Ê data \222¤Ç\222¤â\222ÎÉ\222¤¤\222¤È\222¤Ï\222¤¤\222¤¨\222¤Ê\222¤¤\222¡£\222¤Ê\222¤¼\222¤Ê\222¤é\222¡¢\222£±\222¹Ô\222¤Î", size1=101,
string2=0x85718ab "\222Ĺ\222¤µ\222¤¬\222¤¢\222¤Þ\222¤ê\222¤Ë\222Ĺ\222¤¤\222¤È\222¡¢MTA \222¤Ï\222¤½\222¤Î message \222¤ò\222ž\222Á÷\222¤¹\222¤ë\222¤³\222¤È\222¤¬\222¤Ç\222¤\222¤Ê\222¤¤\222¤«\222¤é\222¤Ç\n\222¤¢\222¤ë\222¡£\222¤Á\222¤Ê\222¤ß\222¤Ë\222¡¢RFC 821 (*Note RFC 821::) \222¤Ï\222£±\222¹Ô\222¤Ï\222²þ\222¹Ô\222ʸ\222»ú\222¤ò\222½ü\222¤¤\222¤Æ 998\nbyte \222°Ê"..., size2=406,
pos=202, regs=0x83f6bf4, stop=507) at regex.c:4327
#5 0x81e1c8c in looking_at_1 (string={gu = {type = Lisp_Type_Record,
val = 102480089}, s = {bits = 0, val = 204960178}, u = {bits = 0,
val = 204960178}, ui = 409920356, i = 409920356, v = 0x186ee364,
cv = 0x186ee364}, buf=0x8464200, posix=0) at search.c:320
#6 0x81e8462 in Flooking_at (regexp={gu = {type = Lisp_Type_Record,
val = 102480089}, s = {bits = 0, val = 204960178}, u = {bits = 0,
val = 204960178}, ui = 409920356, i = 409920356, v = 0x186ee364,
cv = 0x186ee364}, buffer={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at search.c:352
#7 0x80cfdea in Ffuncall (nargs=2, args=0xbfbfc450) at eval.c:3528
#8 0x809d79e in execute_optimized_program (
program=0x8530410 "\016B«\r\016BÆa¬\a`\016BB\026B\r\013^b\210\r\013]\023ÇÈw\210`È\036C\036EÉy\210`\025\013b\210`\rV«%`SfÊa«\036\016C«\022\016J«\bË`SÌ\"¬\aÍÎ!\210ªàÏu\210Æ\026CªØ`\023\016C¬\n\013\016EV«\004Ð \210\016Eb\210*\013`V\205\006\003\n¬\004Ñ \022\f\034Ò\r\013Æ#\210\214\rb\210Éy\210`\013}\210\n¬\032\rb\210m\204Ü\002l¬\013Ó Ô W«\004Õ \210Îy\210ªë\016J«\aÖ\rd×#\210\nØs¬\bÓ Ô W«\004Õ \210\rb\210\f\r\fÙk?\a"..., stack_depth=7, constants_data=0x18695208)
at bytecode.c:746
#9 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102497123}, s = {bits = 0,
val = 204994246}, u = {bits = 0, val = 204994246}, ui = 409988492,
i = 409988492, v = 0x186fed8c, cv = 0x186fed8c}, nargs=3,
args=0xbfbfc5b4) at bytecode.c:518
#10 0x80cfee5 in Ffuncall (nargs=4, args=0xbfbfc5b0) at eval.c:3563
#11 0x809d79e in execute_optimized_program (
program=0x8428710 "\r«\013\rÆ\035\211\030\f!*®)`\031\212Ç \210n¬\005ÈÉ!\210`Ê \210`\e\032\tb\210\016\r«\bË\013\n\f#ª\006Ì\013\n\f#,\207\bchapter \016\t",
stack_depth=5, constants_data=0x1868f4d8) at bytecode.c:746
#12 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102494743}, s = {bits = 0,
val = 204989486}, u = {bits = 0, val = 204989486}, ui = 409978972,
i = 409978972, v = 0x186fc85c, cv = 0x186fc85c}, nargs=1,
args=0xbfbfc714) at bytecode.c:518
#13 0x80cfee5 in Ffuncall (nargs=2, args=0xbfbfc710) at eval.c:3563
#14 0x809d79e in execute_optimized_program (
program=0x8428f90 "Æ \210Ç \eÈÉ!\210ÊË!«\004Ìy\210\212Éy\210ÊÍ!)«\rÉy\210`Ìy\210`|\210ª\031\nÎk¬\024\tÏV¬\017`ÐÑw\210`|\210Ò\nÓ\"c\210ÈÌ!\210Éy\210Ñ\177\210\r\030\rÔP\035\f\036\027\fÔP\034Õ\216ÖÑ!\210-\013b)\207", stack_depth=3,
constants_data=0x84d9a90) at bytecode.c:746
#15 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34857374}, s = {bits = 0,
val = 69714748}, u = {bits = 0, val = 69714748}, ui = 139429496,
i = 139429496, v = 0x84f8678, cv = 0x84f8678}, nargs=0, args=0xbfbfc864)
at bytecode.c:518
#16 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfc860) at eval.c:3563
#17 0x809d79e in execute_optimized_program (
program=0x852a810 "Æed\"\210eb\210ÇÈÉÊ#\203Ü", stack_depth=5,
constants_data=0x852f810) at bytecode.c:746
#18 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901652}, s = {bits = 0,
val = 69803304}, u = {bits = 0, val = 69803304}, ui = 139606608,
i = 139606608, v = 0x8523a50, cv = 0x8523a50}, nargs=0, args=0xbfbfc9c4)
at bytecode.c:518
#19 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfc9c0) at eval.c:3563
#20 0x809d79e in execute_optimized_program (
program=0x8464410 "Æ", '\211' <repeats 14 times>, "ÇÆ\211\bp\016?\0367\035\0368\034\036＠\036A\036B\036C\0369\036:\036;\036<\036=\036>\036D\036E\036F\e\036G\036H\032Æ\211\026I\026J\212eb\210ÈÉÆÊ#¬\005ËÌ!\210`\023Í \024)Î\f!\210Ï \210Ð \210ÑÒ\f\"\210ÓÔ\f!!\022\0168\020Õ\016K!\210Ö\r!\210Ñ×Ø\r!\"\210eb\210\212ÑÙ!\210ÚÛÆÊ#«\tÜÝÆ\211#\210ªò)ÚÞÆÊ#«E`\023\0167Í P\031ßÞ!\210`\212ày\210`)|\210Ñá\t\"\210\212\214``â\t!A＠\\}\210eb\210Ú"..., stack_depth=22, constants_data=0x853cc10)
at bytecode.c:746
#21 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901624}, s = {bits = 0,
val = 69803248}, u = {bits = 0, val = 69803248}, ui = 139606496,
i = 139606496, v = 0x85239e0, cv = 0x85239e0}, nargs=0, args=0xbfbfcb64)
at bytecode.c:518
#22 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfcb60) at eval.c:3563
#23 0x809d79e in execute_optimized_program (
program=0x84f7090 "Â\031Ã\t!\210~\210Ä \210Å \210\b¬\020Æ ÇV«\nÃÈ\211\021!\210É \210Ã\tt«\004ʪ\002ËP!)\207lin\apO\b", stack_depth=3,
constants_data=0x84f7c90) at bytecode.c:746
#24 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901603}, s = {bits = 0,
val = 69803206}, u = {bits = 0, val = 69803206}, ui = 139606412,
i = 139606412, v = 0x852398c, cv = 0x852398c}, nargs=0, args=0xbfbfccb4)
at bytecode.c:518
#25 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfccb0) at eval.c:3563
#26 0x809d79e in execute_optimized_program (
program=0x847c690 "Á\b\211A\020＠! \207w`\030DØS\b\026ÀG\b\200êL\bR\005",
stack_depth=3, constants_data=0x18685bac) at bytecode.c:746
#27 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491705}, s = {bits = 0,
val = 204983410}, u = {bits = 0, val = 204983410}, ui = 409966820,
i = 409966820, v = 0x186f98e4, cv = 0x186f98e4}, nargs=1,
args=0xbfbfce04) at bytecode.c:518
#28 0x80cfee5 in Ffuncall (nargs=2, args=0xbfbfce00) at eval.c:3563
#29 0x809d79e in execute_optimized_program (
program=0x84fa110 "\n¬＠\016!?\205Ñ", stack_depth=7,
constants_data=0x18684218) at bytecode.c:746
#30 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491040}, s = {bits = 0,
val = 204982080}, u = {bits = 0, val = 204982080}, ui = 409964160,
i = 409964160, v = 0x186f8e80, cv = 0x186f8e80}, nargs=0,
args=0xbfbfcf64) at bytecode.c:518
#31 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfcf60) at eval.c:3563
#32 0x809d79e in execute_optimized_program (
program=0x8445c90 "\013A\035ÆÇ\032\031È\r!\025ÉÊ!«\004Ë \210\f«\016\b¬\013ÌÍÎ\f!ÏQ! \210Ð \210*Ñ \210Ò \210rÓÔ!q\210Õ \210Ö×!\210\016\036Øa«\005\016\037 \210)Ù Úa«\bÀ ¬\004Û \210Ü \210×\026 À \004ÝÇ!)\207", stack_depth=4,
constants_data=0x18684b68) at bytecode.c:746
#33 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491236}, s = {bits = 0,
val = 204982472}, u = {bits = 0, val = 204982472}, ui = 409964944,
i = 409964944, v = 0x186f9190, cv = 0x186f9190}, nargs=0,
args=0xbfbfd0c4) at bytecode.c:518
#34 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfd0c0) at eval.c:3563
#35 0x809d79e in execute_optimized_program (
program=0x8435510 "\t«\005ÆÇ!\207È\021É \211\034«\025\fG\rGW«\016Ê\r!Ê\f!k«\005Ë\f!\025)Ì\r!\025Í \210Î \210\013®\aÏÐ!\002È\eÑ\016#\016$\"\022\013«\tÒÓÔ\n\"Õ\"\210\n¬\004Ö \210×\n\016%\b\016&\013%\210Ø \210)\016!¬\022\016\"«\016ÙÚÛ\016'!\016\"\"ÜÈ#\210\016!¬\023\b¬\006Ý\016(!\210Ý\016)!\210Ý\016*!\210Þ\216ß \210)\016+\003à \207O8859-1\niso8859-15/XLC_LOCALE\tde_LI.ISO8859-15\niso"...,
stack_depth=7, constants_data=0x18685298) at bytecode.c:746
#36 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491453}, s = {bits = 0,
val = 204982906}, u = {bits = 0, val = 204982906}, ui = 409965812,
i = 409965812, v = 0x186f94f4, cv = 0x186f94f4}, nargs=0,
args=0xbfbfd19c) at bytecode.c:518
#37 0x80cf6cb in Feval (form={gu = {type = Lisp_Type_Record, val = 102271649},
s = {bits = 0, val = 204543298}, u = {bits = 0, val = 204543298},
ui = 409086596, i = 409086596, v = 0x18622a84, cv = 0x18622a84})
at eval.c:3388
#38 0x80d5a9a in condition_case_1 (handlers={gu = {type = Lisp_Type_Record,
val = 102248666}, s = {bits = 0, val = 204497332}, u = {bits = 0,
val = 204497332}, ui = 408994664, i = 408994664, v = 0x1860c368,
cv = 0x1860c368}, bfun=0x80ceb50 <Feval>, barg={gu = {
type = Lisp_Type_Record, val = 102271649}, s = {bits = 0,
val = 204543298}, u = {bits = 0, val = 204543298}, ui = 409086596,
i = 409086596, v = 0x18622a84, cv = 0x18622a84},
hfun=0x80ad5b4 <cmd_error>, harg={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at eval.c:1651
#39 0x80ad640 in top_level_1 (dummy={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at cmdloop.c:206
#40 0x80d599c in internal_catch (tag={gu = {type = Lisp_Type_Record,
val = 102200162}, s = {bits = 0, val = 204400324}, u = {bits = 0,
val = 204400324}, ui = 408800648, i = 408800648, v = 0x185dcd88,
cv = 0x185dcd88}, func=0x80ad610 <top_level_1>, arg={gu = {
type = Lisp_Type_Record, val = 102248762}, s = {bits = 0,
val = 204497524}, u = {bits = 0, val = 204497524}, ui = 408995048,
i = 408995048, v = 0x1860c4e8, cv = 0x1860c4e8}, threw=0x0)
at eval.c:1317
#41 0x80ac867 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at cmdloop.c:285
#42 0x80c78c1 in xemacs_21_2_b44_i386_unknown_freebsd3_3 (argc=15,
argv=0xbfbfd4f0, envp=0xbfbfd530, restart=0) at emacs.c:2253
#43 0x80c999e in main (argc=15, argv=0xbfbfd4f0, envp=0xbfbfd530)
at emacs.c:2620
norbert.
- 4 participants
- 7 comments
Error in make check
23 years, 9 months
Norbert Koch
Norbert Koch
Hi!
Current CVS version, including Matt's patch described in message
<77100000.982725397＠benzene>, gives me the following output in make
test:
Testing /usr/users/support/nk/cvs/xemacs/tests/automated/syntax-tests.el...
Unexpected error (void-function c-mode) while executing interpreted code.
Test suite execution aborted.
Unexpected error (void-function c-mode) while executing byte-compiled code.
Test suite execution aborted.
norbert.
- 2 participants
- 1 comments