April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Applying patches using patch-xemacs.sh ? 25 years, 7 months

Holger Schauer

Hi ! Please, excuse my ignorance, but how does one apply patches to the current xemacs-directory ? After reading patch-xemacs.sh I came to the conclusion that in my case "./patch-xemacs.sh xemacs-21.0.66 ." would do it (with the patch correctly named) but the patch failed - it couldn't determine the file to patch. So, I gunzip'ed the patch, and did a patch -p1 < patch and obtained the same result: for each file patch would ask me which file to patch :-( The filenames used in the patches all follow the pattern "XEmacs/xemacs/<filename>" i.e. CHANGES-beta as <filename>. Well, XEmacs/xemacs does not exist here (I'm using src/xemacs-<version>), so how can I apply such a patch ? TIA, Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- "Welche Linux-Distribution soll ich nehmen?" -- Aus "Wie starte ich einen Endlosthread ?", Teil 1171

1 participants
0 comments

Re: cc-mode problem... 25 years, 7 months

Dmitry Yaitskov

Eric Knudstrup <eknuds(a)extremenetworks.com> wrote: > I am running XEmacs 21.2 under Windows NT, and it seems like every time I > open a new C file it resets c-basic-offset. > This is version 5.25 of CC Mode. > Is there something I'm probably doing wrong? I have the following in my .emacs: (setq-default c-basic-offset 4) But, I also have it as a part in different c-styles that I'm using. If you only use one c-style the above should be enough I think. -- Cheers, -Dima.

1 participants
0 comments

Problems with auto-show 25 years, 7 months

Alastair Burt

I have lost track of what all the XEmacs mailing lists are for. Here is a bug report. I hope I have sent it to the right list. The auto-show mode that does automatic horizontal scrolling has problems with toolbars. Running the following code with "xemacs -q" shows the problem: (progn (insert "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890") (set-specifier right-toolbar-width 40 'global) (set-specifier right-toolbar '(nil) 'global nil)) When you move around the buffer scrolling takes place even though it is not necessary because the lines are not truncated. The problem lies in the function auto-show-truncationp. It seems part of a general problem in XEmacs since toolbars, glyphs and variable-width characters were introduced: doing calculations with numbers of characters when you really need pixel values to do it right. --- Alastair P.S. This problem occurs because I use the right hand side for mode local toolbars and keep the top toolbar for the global functions. Is this not a better way of better way of doing things?

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Jan Vroonhof

Enrico Scholz <enrico.scholz(a)wirtschaft.tu-chemnitz.de> writes: > > [...] > > fcntl(11, F_GETOWN) = 0 > > getpid() = 2285 > > fcntl(11, F_SETOWN, 2285) = 0 > > ioctl(11, 0x7, 0xbfffef38) = -1 EINVAL (Invalid argument) > > ioctl(11, 0x6, 0x4) = -1 EINVAL (Invalid argument) > > > > This seems suspect to me.... It does look suspiciously like > > > > ioctl (filedesc, I_GETSIG, &events); > > ioctl (filedesc, I_SETSIG, events | S_INPUT); > > > > from sysdep.c > > That's right. Could you patch sysdep.c such that it doens't use these ioctl's but instead uses one of the other methods. Searching some manpage on the net seems to indicate FIOASYNC should work, Jan P.S. The solaris manpages talk about streams and stuff so that is probably not a good idea.

1 participants
0 comments

display glitch in 21.2.13 25 years, 7 months

Giacomo Boffi

after exiting the mine game (hmm, i was testing XEmacs) the frame was not properly redisplayed - a white (white is mines' default bg color) strip is left in the bottom i don't know if this is relevant, but i set my default background (sort of pale beige) via X properties and not through emacs lisp the glitch is reproducible for me i experienced something analogous when i tried to change the default background for particular modes (thank you colin for the suggestion) (add-hook 'c-mode-common-hook '(lambda () (set-face-background 'default "HotPink" (current-buffer)))) killing a 'bg-colorized' buffer, i was left with a strip of the new color in the bottom of the frame, iff the bottom of the frame was empty (no text, i mean) i don't know if the obvious generalization holds true in all cases ciao ------------------------------------------------------------------------ XEmacs 21.2 "Demeter" [Lucid] (i586-pc-linux) of Fri Mar 12 1999 on boffi95.stru.polimi.it

1 participants
0 comments

Re: strange insertion in the mail headers 25 years, 7 months

Jason R Mastaler

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Known crockage. If the first line in the body of a message > begins with whitespace, majordomo slurps that lines and some > number of others into the headers. Sucks. Since we're > freeloaders at xemacs.org, I can only suggest that you not > start your messages with whitespace. I looked into this and it seems this problem[1] was fixed in a later version of Majordomo than the one we have running. Sometime this weekend I'll either upgrade the Majordomo or apply a patch I found in the majordomo-workers archives to fix this. Footnotes: 1. <http://www.hpc.uh.edu/majordomo-workers/9702/msg00054.html> provides a pretty good explanation of the problem.

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Enrico Scholz

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > [...] > See my comments below... on the suspect ioctls. I still think it > could be some symbolversioning problem. The main change glibc 2.1 > made was in the FILE * structure. In this case the open() call is > done by the X libraries (which I assume were not recompiled with > glibc 2.1), but XEmacs is doing the F_SETSIG stuff which is only > supported if you opened the file with the new open. No, my XFree86 and the other packages XEmacs depends on are compiled with glibc2.1. > Or maybe it is something else altogether (it would be interesting to > find out if these two failing ioctl's (see below) are indeed the code > in request_sigio_on_device. Yes, they happen in this function. > Maybe you can set a breakpoint on that function to see which settings > XEmacs does? The only interesting variable there is "struct device *d", which is -------------------------------------- (gdb) p *d $1 = {header = {lheader = {implementation = 0x82df1c0}, next = 0x84469f0, uid = 8726, free = 0}, devmeths = 0x83435a0, name = 137776084, connection = 137775668, canon_connection = 137776036, frame_list = 137512588, console = 138652128, selected_frame = 137512588, frame_with_focus_real = 137512588, frame_with_focus_for_hooks = 137512588, frame_that_ought_to_have_focus = 137512588, device_class = 137512588, user_defined_tags = 137512588, color_instance_cache = 138701616, font_instance_cache = 138701688, image_instance_cache = 138702104, device_data = 0x8446e58, buffers_changed = 0, clip_changed = 0, extents_changed = 0, faces_changed = 0, frame_changed = 0, glyphs_changed = 0, subwindows_changed = 0, icon_changed = 0, menubar_changed = 0, modeline_changed = 0, point_changed = 0, size_changed = 0, toolbar_changed = 0, windows_changed = 0, windows_structure_changed = 0, locked = 0, pixel_to_glyph_cache = { valid = 0, frame = 0x0, low_x_coord = 0, high_x_coord = 0, col = 0, obj_x = 0, low_y_coord = 0, high_y_coord = 0, row = 0, obj_y = 0, w = 0x0, bufpos = 0, closest = 0, modeline_closest = 0, obj1 = 137512588, obj2 = 137512588, retval = 0}, baud_rate = 38400, on_console_p = 0, connected_to_nas_p = 0, infd = 11, outfd = 11, old_fcntl_owner = 0} (gdb) p *(struct x_device *)d->device_data $2 = {display = 0x83f0218, being_deleted = 0, Xt_app_shell = 0x84a2e40, gc_cache = 0x0, visual = 0x838b8a0, depth = 16, device_cmap = 33, gray_pixmap = 0, Xatom_WM_PROTOCOLS = 0, Xatom_WM_DELETE_WINDOW = 0, Xatom_WM_SAVE_YOURSELF = 0, Xatom_WM_TAKE_FOCUS = 0, Xatom_WM_STATE = 0, Xatom_CLIPBOARD = 0, Xatom_TIMESTAMP = 0, Xatom_TEXT = 0, Xatom_DELETE = 0, Xatom_MULTIPLE = 0, Xatom_INCR = 0, Xatom_EMACS_TMP = 0, Xatom_TARGETS = 0, Xatom_NULL = 0, Xatom_ATOM_PAIR = 0, Xatom_COMPOUND_TEXT = 0, Xatom_FOUNDRY = 0, Xatom_FAMILY_NAME = 0, Xatom_WEIGHT_NAME = 0, Xatom_SLANT = 0, Xatom_SETWIDTH_NAME = 0, Xatom_ADD_STYLE_NAME = 0, Xatom_PIXEL_SIZE = 0, Xatom_POINT_SIZE = 0, Xatom_RESOLUTION_X = 0, Xatom_RESOLUTION_Y = 0, Xatom_SPACING = 0, Xatom_AVERAGE_WIDTH = 0, Xatom_CHARSET_REGISTRY = 0, Xatom_CHARSET_ENCODING = 0, MetaMask = 64, HyperMask = 0, SuperMask = 32, AltMask = 8, ModeMask = 0, lock_interpretation = 65509, x_modifier_keymap = 0x8498050, x_keysym_map = 0x84b4f90, x_keysym_map_min_code = 8, x_keysym_map_max_code = 134, x_keysym_map_keysyms_per_code = 3, x_keysym_map_hash_table = 139154824, WM_COMMAND_frame = 137512588, mouse_timestamp = 0, global_mouse_timestamp = 0, last_server_timestamp = 0, need_to_add_mask = 0, down_mask = 0, last_downkey = 0 '\000', release_time = 0} --------------------------------------- The backtrace of a (slightly modified) xemacs is: (gdb) bt #0 0x40403021 in __kill () #1 0x40402c6a in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4040451b in abort () at ../sysdeps/generic/abort.c:88 #3 0x8088f35 in assert_failed (file=0x820af1e "sysdep.c", line=1021, expr=0x820af60 "ioctl (filedesc, I_GETSIG, &events)!=-1") at emacs.c:2649 #4 0x81745e4 in request_sigio_on_device (d=0x845c600) at sysdep.c:1021 #5 0x8174bca in init_one_device (d=0x845c600) at sysdep.c:1709 #6 0x817a3bc in x_init_device (d=0x845c600, props=137512588) at device-x.c:726 #7 0x8076fe7 in Fmake_device (type=137614668, connection=137512588, props=137512588) at device.c:581 #8 0x808f4ee in Ffuncall (nargs=3, args=0xbfffefcc) at eval.c:3189 #9 [...] > Then we can compare this with a glibc 2.0 build. It would be interesting to know if all glibc2.1 build's are concerned, or if it happens just under certain circumstances. > > Here is your trace, annotated by me. I am learning by doing here so > please correct me if I am writing gibberish. The X-signal-stuff is a closed book for me :) Do you know a good documentation/manual which handles with it? About which Solaris manpage are you speaking below? > [...] > fcntl(11, F_GETOWN) = 0 > getpid() = 2285 > fcntl(11, F_SETOWN, 2285) = 0 > ioctl(11, 0x7, 0xbfffef38) = -1 EINVAL (Invalid argument) > ioctl(11, 0x6, 0x4) = -1 EINVAL (Invalid argument) > > This seems suspect to me.... It does look suspiciously like > > ioctl (filedesc, I_GETSIG, &events); > ioctl (filedesc, I_SETSIG, events | S_INPUT); > > from sysdep.c That's right. > (The solaris manpage says this what you need to do > there to get a signal on input). Could you grep the glibc2.1 include > files to compare the definition of I_GETSIG, I_SETSIG, S_INPUT with > 0x7, 0x6, and 0x4 ? Yes, the I_xxx #define's have the values above. If you are interested in a precompiled device-x.c and sysdep.c, you can find them at http://www.tu-chemnitz.de/~ensc/xemacs/ . Enrico -- eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de talk: ensc(a)ultra.csn.tu-chemnitz.de

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Jan Vroonhof

Enrico Scholz <enrico.scholz(a)wirtschaft.tu-chemnitz.de> writes: > I can not find anything about setting signals in the X11 strace. See my comments below... on the suspect ioctls. I still think it could be some symbolversioning problem. The main change glibc 2.1 made was in the FILE * structure. In this case the open() call is done by the X libraries (which I assume were not recompiled with glibc 2.1), but XEmacs is doing the F_SETSIG stuff which is only supported if you opened the file with the new open. Or maybe it is something else altogether (it would be interesting to find out if these two failing ioctl's (see below) are indeed the code in request_sigio_on_device. Maybe you can set a breakpoint on that function to see which settings XEmacs does? Then we can compare this with a glibc 2.0 build. Here is your trace, annotated by me. I am learning by doing here so please correct me if I am writing gibberish. execve("/usr/bin/xemacs", ["xemacs", "-vanilla", "-eval", "(call-process \"sleep\" nil nil nil \"3\")"], [/* 41 vars */]) = 0 brk(0) = 0x839e000 [... init code] socket(PF_UNIX, SOCK_STREAM, 0) = 11 uname({sys="Linux", node="ultra.csn.tu-chemnitz.de", ...}) = 0 uname({sys="Linux", node="ultra.csn.tu-chemnitz.de", ...}) = 0 connect(11, {sun_family=AF_UNIX, sun_path="/tmp/.X11-unix/X0"}, 19) = 0 [open up the X connection...] uname({sys="Linux", node="ultra.csn.tu-chemnitz.de", ...}) = 0 fcntl(11, F_SETFD, FD_CLOEXEC) = 0 access("/home/ensc/.Xauthority", R_OK) = 0 open("/home/ensc/.Xauthority", O_RDONLY) = 12 [...] close(12) = 0 [..] write(11, "\20\1\6\0\20\0\0\0SCREEN_RESOURC"..., 24) = 24 read(11, "\1\0\10\0\0\0\0\0T\0\0\0\0\0\0\0"..., 32) = 32 write(11, "\24\0\6\0%\0\0\0T\0\0\0\37\0\0\0"..., 24) = 24 [..] read(11, "\1\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 read(11, "\1\2=\0\4\0\0\0\270\317P\10\0\0\0"..., 32) = 32 readv(11, [{"2>B\0%m＠qM\0t\0suN\0", 16}, {"", 0}], 2) = 16 fcntl(11, F_GETOWN) = 0 getpid() = 2285 fcntl(11, F_SETOWN, 2285) = 0 ioctl(11, 0x7, 0xbfffef38) = -1 EINVAL (Invalid argument) ioctl(11, 0x6, 0x4) = -1 EINVAL (Invalid argument) This seems suspect to me.... It does look suspiciously like ioctl (filedesc, I_GETSIG, &events); ioctl (filedesc, I_SETSIG, events | S_INPUT); from sysdep.c (The solaris manpage says this what you need to do there to get a signal on input). Could you grep the glibc2.1 include files to compare the definition of I_GETSIG, I_SETSIG, S_INPUT with 0x7, 0x6, and 0x4 ? [...] write(11, "-\0\17\0\t\0\200\5/\0AR-*-courie"..., 68) = 68 getdents(12, /* 0 entries */, 3933) = 0 close(12) = 0 stat("/bin/sleep", {st_mode=0, st_size=0, ...}) = 0 access("/bin/sleep", X_OK) = 0 open("/dev/null", O_RDONLY) = 12 pipe([13, 14]) = 0 fork() = 2286 close(14) = 0 close(12) = 0 close(14) = -1 EBADF (Bad file descriptor) lseek(13, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) read(13, "", 512) = 0 --- SIGCHLD (Der Kind-Prozeß ist beendet) --- write(10, "\0", 1) = 1

1 participants
0 comments

Re: Behaviour of call-process 25 years, 7 months

Enrico Scholz

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > [...] > For some reason it is not generating a signal for input on the X > device. Maybe something subtle changed here. (We need straces from > opening the X device and/or the setting of the signal handlers). Ok, you can find the tracefiles and the config.h at http://www.tu-chemnitz.de/~ensc/xemacs/. I can not find anything about setting signals in the X11 strace. Enrico -- eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de talk: ensc(a)ultra.csn.tu-chemnitz.de

1 participants
0 comments

"Russian" Mule crash in 21.0.67 25 years, 7 months

Jan Vroonhof

xemacs-21.0.67 -batch -vanilla -l crashkoi.el With crashkoi.el (with-current-buffer (get-buffer-create "crash") (erase-buffer) (insert " \207 ") (decode-coding-region (point-min) (point-max) 'koi8-r) (goto-char (point-max)) (re-search-backward "^-") ) [This came from a message on linux-kernel claiming it was koi8-r charset encoding, but it was really ascii with a few of those funny \207 Windows Ansi quotes in some cited text.] Starting program: /scratch/vroonhof/cvs/xemacs-20/src/xemacs -batch -vanilla -l crashkoi.el Fatal error: assertion failed, file regex.c, line 4105, __dcptr__ - __dcptr2__ == REP_BYTES_BY_FIRST_BYTE (*__dcptr2__) (no debugging symbols found)...(no debugging symbols found)... [..] (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGABRT, Aborted. 0xef074340 in _kill () (gdb) where #0 0xef074340 in _kill () #1 0xef03a59c in abort () #2 0x2c8a88 in re_search_2 () #3 0x2d35c4 in search_buffer () #4 0x2d29b4 in search_command () #5 0x2d5290 in Fre_search_backward () #6 0xe3fd8 in Feval () #7 0xd4934 in Fprogn () #8 0xbf458 in Fsave_current_buffer () #9 0xe3a0c in Feval () #10 0xe4444 in Feval () #11 0x267760 in readevalloop () #12 0x265d74 in Fload_internal () #13 0xe5290 in funcall_recording_as () #14 0x7b60c in Fbyte_code () #15 0xea2ec in funcall_lambda () #16 0xe57b8 in funcall_recording_as () #17 0x7b60c in Fbyte_code () #18 0xea2ec in funcall_lambda () #19 0xe57b8 in funcall_recording_as () #20 0x7b60c in Fbyte_code () #21 0xea2ec in funcall_lambda () #22 0xe57b8 in funcall_recording_as () #23 0x7b60c in Fbyte_code () #24 0xea2ec in funcall_lambda () #25 0xe57b8 in funcall_recording_as () #26 0x7b60c in Fbyte_code () #27 0xea2ec in funcall_lambda () #28 0xe7cb4 in apply_lambda () #29 0xe43a0 in Feval () #30 0xd97a4 in condition_case_1 () #31 0x972c0 in top_level_1 () #32 0xd89c8 in internal_catch () #33 0x97418 in initial_command_loop () #34 0xcdb1c in xemacs_21_0_b66_sparc_sun_solaris2_5_1 () Lisp backtrace follows: re-search-backward("^-") # (unwind-protect ...) (save-current-buffer (set-buffer (get-buffer-create "crash")) (erase-buffer) (insert " � ") (decode-coding-region (point-min) (point-max) (quote koi8-r)) (goto-char (point-max)) (re-search-backward "^-")) ) (with-current-buffer (get-buffer-create "crash") (erase-buffer) (insert " � ") (decode-coding-region (point-min) (point-max) (quote koi8-r)) (goto-char (point-max)) (re-search-backward "^-")) ) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("/scratch/vroonhof/cvs/xemacs-20/crashkoi.el" nil t nil undecided) # bind (path handler filename nosuffix nomessage noerror file) load("/scratch/vroonhof/cvs/xemacs-20/crashkoi.el" nil t) # bind (file arg) command-line-do-load("-l") # bind (dir file-count line end-of-options first-file-buffer file-p arg tem) command-line-1() # bind (command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Program received signal SIGABRT, Aborted. 0xef074340 in _kill () uname -a: SunOS bolzano 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1 /configure '--prefix=/scratch/vroonhof/xe205' '--with-gcc=no' '--site-prefixes=/u/scratch/vroonhof/jpeg6a:/u/scratch/jvsoft/:/u/scratch/jvsoft/canna:/usr/local' '--with-workshop=no' '-with-site-lisp' '--with-mule=yes' '--extra-verbose' XEmacs 21.0-b66 "20 minutes to Nikko" configured for `sparc-sun-solaris2.5.1'. Where should the build process find the source code? /scratch/vroonhof/cvs/xemacs-20 What installation prefix should install use? /scratch/vroonhof/xe205 What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? cc -v -xO4 Should XEmacs use the GNU version of malloc? yes 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/dt/include /usr/local/X11/include Where do we find X Windows libraries? /usr/dt/lib /usr/local/X11/lib Additional prefixes: /u/scratch/vroonhof/jpeg6a /u/scratch/jvsoft/ /u/scratch/jvsoft/canna /usr/local Runtime library search path: /u/scratch/jvsoft//lib:/usr/local/lib:/usr/dt/lib:/usr/local/X11/lib:/opt/SUNWdt/lib Compiling in support for XAUTH. Compiling in support for XPM images. -------------------------------------------------------------------- WARNING: Compiling without PNG image support. Reason: PNG library version and header file don't match! WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) -------------------------------------------------------------------- Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for X-Face message headers. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for ToolTalk. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. 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

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