April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Gunnar Evermann

"Jérôme Lacoste" <lacostej(a)oslo.geco-prakla.slb.com> writes: > In XEmacs 21.0 "20 minutes to Nikko" [Lucid] (sparc-sun-solaris2.6) > #3 0xef6b63d4 in DragMotionProto () > #4 0xef6b6984 in FinishAction () > #5 0xef3a687c in HandleActions () > #6 0xef3a6fb8 in HandleSimpleState () > #7 0xef3a76b0 in _XtTranslateEvent () > #8 0xef37cf60 in XtDispatchEventToWidget () > #9 0xef37db9c in _XtDefaultDispatcher () > #10 0xef37de44 in XtDispatchEvent () > #11 0xef38bc54 in XtAppProcessEvent () > #12 0x139a68 in emacs_Xt_event_pending_p (user_p=1) at event-Xt.c:2585 > #13 0x9bd3c in detect_input_pending () at event-stream.c:945 There a quite a few reports of crashes like this with 20.4. I get this on solaris2.6 in 20.4 when I click three times button1 to select a line and then (without moving the mouse) click button2 to yank the selection. I seem to remember having seen this ages ago, but only on xemacsen compiled with support for CDE. Does the 'DragMotionProto' in the backtrace refer to DnD? Oliver, any ideas? Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: Compile Failure in Latest CVS Sources for 21.2 25 years

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: ... > That would be weird, because I was able to compile correctly (with > union type, even), and `cvs diff' says that I should be in sync with > the repository. Actually, that's not true. If you haven't done a `cvs update', a `cvs diff' isn't going to reveal changes that others have committed. The 21.2 source tree is definitely fucked up. gcc -c -mpentiumpro -O6 -fno-exceptions -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include abbrev.c lisp.h: In function `TRUE_LIST_P': In file included from abbrev.c:35: lisp.h:917: warning: comparison of distinct pointer types lacks a cast chartab.h: In function `CHAR_TABLE_NON_ASCII_VALUE_UNSAFE': In file included from syntax.h:26, from abbrev.c:40: chartab.h:145: warning: comparison of distinct pointer types lacks a cast abbrev.c: In function `abbrev_oblookup': abbrev.c:186: warning: comparison of distinct pointer types lacks a cast abbrev.c:238: warning: comparison of distinct pointer types lacks a cast abbrev.c: In function `Fexpand_abbrev': abbrev.c:298: warning: comparison of distinct pointer types lacks a cast abbrev.c:335: warning: comparison of distinct pointer types lacks a cast gcc -c -mpentiumpro -O6 -fno-exceptions -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include alloc.c lisp.h: In function `TRUE_LIST_P': In file included from alloc.c:43: lisp.h:917: warning: comparison of distinct pointer types lacks a cast chartab.h: In function `CHAR_TABLE_NON_ASCII_VALUE_UNSAFE': In file included from alloc.c:48: chartab.h:145: warning: comparison of distinct pointer types lacks a cast alloc.c: In function `cons_equal': alloc.c:968: warning: comparison of distinct pointer types lacks a cast alloc.c:968: warning: comparison of distinct pointer types lacks a cast alloc.c: At top level: alloc.c:974: conflicting types for `lrecord_cons' lisp.h:637: previous declaration of `lrecord_cons' alloc.c: In function `make_float': alloc.c:1124: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: At top level: alloc.c:1173: conflicting types for `lrecord_vector' lisp.h:1035: previous declaration of `lrecord_vector' alloc.c: In function `make_bit_vector_internal': alloc.c:1354: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `make_compiled_function': alloc.c:1458: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `Fmake_byte_code': alloc.c:1513: warning: comparison of distinct pointer types lacks a cast alloc.c:1528: warning: comparison of distinct pointer types lacks a cast alloc.c:1533: warning: comparison of distinct pointer types lacks a cast alloc.c: In function `Fmake_symbol': alloc.c:1602: warning: comparison of distinct pointer types lacks a cast alloc.c:1605: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `allocate_extent': alloc.c:1629: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `allocate_event': alloc.c:1659: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `Fmake_marker': alloc.c:1682: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `noseeum_make_marker': alloc.c:1699: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c: In function `mark_string': alloc.c:1737: warning: passing arg 2 of `gc_record_type_p' from incompatible pointer type alloc.c: At top level: alloc.c:1750: conflicting types for `lrecord_string' lisp.h:966: previous declaration of `lrecord_string' alloc.c:2248: conflicting types for `lrecord_lcrecord_list' lisp.h:1479: previous declaration of `lrecord_lcrecord_list' alloc.c: In function `garbage_collect_1': alloc.c:3328: warning: comparison of distinct pointer types lacks a cast alloc.c:3330: warning: comparison of distinct pointer types lacks a cast alloc.c: In function `object_dead_p': alloc.c:3681: warning: comparison of distinct pointer types lacks a cast alloc.c:3682: warning: comparison of distinct pointer types lacks a cast alloc.c:3683: warning: comparison of distinct pointer types lacks a cast alloc.c:3684: warning: comparison of distinct pointer types lacks a cast alloc.c:3685: warning: comparison of distinct pointer types lacks a cast alloc.c:3686: warning: comparison of distinct pointer types lacks a cast alloc.c:3687: warning: comparison of distinct pointer types lacks a cast alloc.c: In function `init_alloc_once_early': alloc.c:3846: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c:3847: request for member `lrecord_type_index' in something not a structure or union alloc.c:3852: warning: passing arg 1 of `lrecord_type_index' from incompatible pointer type alloc.c:3853: request for member `lrecord_type_index' in something not a structure or union make[1]: *** [alloc.o] Error 1 make[1]: Leaving directory `/devel/xemacs/xemacs-21.2/src' make: *** [src] Error 2 uname -a: Linux demeter.xemacs.org 2.2.5 #2 SMP Sat Apr 3 13:06:18 JST 1999 i686 unknown ./configure '--cflags=-mpentiumpro -O6 -fno-exceptions' '--error-checking=none' '--debug=no' '--with-mule=yes' '--with-dialogs=athena3d' '--with-scrollbars=athena3d' '--use-union-type=no' '--with-xim=xlib' '--with-xfs' '--mail-locking=file' '--extra-verbose=no' XEmacs 21.2-b13 "Demeter" configured for `i686-pc-linux'. Where should the build process find the source code? /devel/xemacs/xemacs-21.2 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 -mpentiumpro -O6 -fno-exceptions 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/X11/include Where do we find X Windows libraries? /usr/X11/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 support for X-Face message headers. 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 Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for proper session-management. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files.

2 participants
1 comments

Re: new 21.2? 25 years

Colin Rafferty

Jan Vroonhof writes: > Colin Rafferty <craffert(a)ms.com> writes: >> More specifically, does it remove purespace altogher? Cool hack. I >> never was sure what we needed it for, since it is for sharing static >> data between processes, and most OSs are smart about COW. > I used to think that too, but Kyle enlightened me. Kyle has a way of doing that to people. Kyle's done it for me a couple of times -- usually accompanying a rejected patch. > Read up on the archive. The GC needs to mark all objects that can > refer to other objects and thus it modifies the pages and you loose on > COW. Even strings can point to other objects because they can have > properties. (Not sure whether there is actually code that does that). How about static strings? For example, imagine I had a string at file scope defined like this: const char * const DocString = "....."; If it is only used in the C part, would it get marked? -- Colin

1 participants
0 comments

Re: symbol->obarray and Vpure_uninterned_symbol_table 25 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Since we no longer have pure space, Vpure_uninterned_symbol_table is > no longer needed. Sorry, but isn't this still needed? We do not have pure space now but isn't that temporary? If the portable dumper is ready don't we have read-only objects again and thus the need for Vpure_uninterned_symbol_table or generalized equivalent to store the symbols these read-only objects refer to? Jan

1 participants
0 comments

Re: new 21.2? 25 years

Jan Vroonhof

Colin Rafferty <craffert(a)ms.com> writes: > Has there been a 21.2 commit to CVS, but not announcement on > xemacs-beta? Yes. > More specifically, does it remove purespace altogher? Cool hack. I > never was sure what we needed it for, since it is for sharing static > data between processes, and most OSs are smart about COW. I used to think that too, but Kyle enlightened me. Read up on the archive. The GC needs to mark all objects that can refer to other objects and thus it modifies the pages and you loose on COW. Even strings can point to other objects because they can have properties. (Not sure whether there is actually code that does that). Jan

1 participants
0 comments

Byte-code interpreter error in latest 21.2 25 years

Robert Pluim

Hi, The latest version out of CVS didn't like my .emacs anymore. I've traced it down to (require eudc), but _only_ if I have my custom-declare-variables statement before it. With -debug-init, I get either: Signaling: (wrong-type-argument number-char-or-marker-p t) eudc-set-server("vb-mail1.corpemea.baynetworks.com" ph t) load-internal("~/.eudc-options" nil nil nil nil nil) load("~/.eudc-options") byte-code("..." [noninteractive locate-library eudc-options-file message "" featurep load infodock eudc-install-menu] 2) load-internal("eudc" nil t nil nil nil) load("eudc" nil t nil) require(eudc) load-internal("~/.emacs" t t t nil nil) load("~/.emacs" t t t) load-user-init-file("") load-init-file() command-line() normal-top-level() or Fatal error: assertion failed, file bytecode.c, line 1485, abort() Program received signal SIGABRT, Aborted. 0x4022c811 in __kill () (gdb) bt #0 0x4022c811 in __kill () #1 0x4022c63f in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4022d84f in abort () at ../sysdeps/generic/abort.c:83 #3 0x8087dab in assert_failed (file=0x81a33e3 "bytecode.c", line=1485, expr=0x81a33ee "abort()") at emacs.c:2639 #4 0x8062064 in execute_rare_opcode (stack_ptr=0xbfffe6bc, program_ptr=0x8616eae "d\b\001", opcode=179) at bytecode.c:1485 #5 0x8060f10 in execute_optimized_program (program=0x8616ea0 ",j*\b\005", stack_depth=4, constants_data=0x85fe1a4) at bytecode.c:664 #6 0x8060a7d in funcall_compiled_function (fun=140499364, nargs=3, args=0xbfffe758) at bytecode.c:530 #7 0x808d40e in Feval (form=140827140) at eval.c:3045 #8 0x8111e81 in readevalloop (readcharfun=140602856, sourcename=140520320, evalfun=0x808c7a8 <Feval>, printflag=0) at lread.c:1454 #9 0x8110533 in Fload_internal (file=140520320, no_error=136510188, nomessage=136510188, nosuffix=136510188, codesys=136510188, used_codesys=136510188) at lread.c:743 #10 0x808dc67 in Ffuncall (nargs=7, args=0xbfffea68) at eval.c:3189 #11 0x8061160 in execute_optimized_program ( program=0x82eebe8 "À\t\n\013\fÅ\211&\006\207", stack_depth=7, constants_data=0x8366ba4) at bytecode.c:754 #12 0x8060a7d in funcall_compiled_function (fun=137757844, nargs=1, args=0xbfffeb80) at bytecode.c:530 depending on exactly what I have in my .emacs. According to bytecomp.el, opcode 179 is not used, and neither it nor bytecode.c have changed recently in a way that could cause this (as far as I can see, but I don't know that much about XEmacs internals). I have it trapped in gdb at the moment, so any suggestions would be much appreciated. Thanks Robert --

1 participants
0 comments

new 21.2? 25 years

Colin Rafferty

Did I miss something? Has there been a 21.2 commit to CVS, but not announcement on xemacs-beta? More specifically, does it remove purespace altogher? Cool hack. I never was sure what we needed it for, since it is for sharing static data between processes, and most OSs are smart about COW. Anyway, the last set of messages I have, other than Vin's compilation problems, are the Perl discussion. -- Colin

1 participants
0 comments

21.0.67 -> 21.0 please ! 25 years

Jan Vroonhof

Since for some reason the release process seems to be stuck could we at least have a real 21.0 on the ftp site that doens't think it is a beta. Jan

1 participants
0 comments

Re: Compile Failure in Latest CVS Sources for 21.2 25 years

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > ... > > That would be weird, because I was able to compile correctly (with > > union type, even), and `cvs diff' says that I should be in sync with > > the repository. > > Actually, that's not true. If you haven't done a `cvs update', a > `cvs diff' isn't going to reveal changes that others have committed. I don't know about that, but I've now done a `cvs update', and I still don't get the errors. I have no idea what I'm doing differently. Maybe Olivier will have a clue.

1 participants
0 comments

Re: Compile Failure in Latest CVS Sources for 21.2 25 years

Hrvoje Niksic

Vin Shelton <acs(a)xemacs.org> writes: > The compile error occurs with no CFLAGS, as well. Perhaps not > everything is checked in to CVS correctly? That would be weird, because I was able to compile correctly (with union type, even), and `cvs diff' says that I should be in sync with the repository.

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 April 1999