February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Jan Vroonhof

Richard Zatorski <Richard.Zatorski(a)eng.sun.com> writes: > When I start up a second gnuserver on my workstation, I get the > message: > gnuserv process exited; restart with M-x gnuserv-start You cannot run 2 gnuserv's so this is exactly what should be happening. Am I misunderstanding you somewhere? Jan

2 participants
1 comments

Re: [pcl-cvs] I've got 2.9.7 working, and packages. 24 years, 3 months

Karl M. Hegbloom

>>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: Charles> More pcl-cvs lossage: typing "e" to re-examine files results in the message: Charles> `nil' is not applicable to any of the selected files. Charles> I don't think we should release the package in its current state. Noted also.

1 participants
0 comments

Re: [pcl-cvs] I've got 2.9.7 working, and packages. 24 years, 3 months

Karl M. Hegbloom

>>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: Charles> Karl M. Hegbloom writes: >> >> I have not tried to merge anything at all from the XEmacs version of >> `pcl-cvs'. This is straight from upstream with only the >> modifications it required to make it work in XEmacs. Charles> Congratulations on getting this working. I spent half of yesterday on Charles> the same task. I have a patch to pcl-cvs.el which eliminates the need Charles> for easy-mmode.el, which (IIRC) last time this was discussed on the Charles> list, we agreed would be better not to drag into the XEmacs packages. Charles> See, e.g. Charles> http://www.xemacs.org/list-archives/xemacs-beta/199908/msg00701.html Charles> http://www.xemacs.org/list-archives/xemacs-beta/199908/msg00706.html Charles> http://www.xemacs.org/list-archives/xemacs-beta/199908/msg00816.html Charles> I suggest we patch pcl-cvs.el to not use this; I have the patch. I'll grab it this afternoon when I get back from looking for work. Charles> As far as diff-mode, I suggest that we add it to our pcl-cvs package. Ok, I'll do that too. I can give you writes to my repository if you like. Send me an ssh key and I'll set it up. Charles> The reason I didn't announce this yesterday is that I was still Charles> testing it and found that some of the features didn't seem to work Charles> correctly. Same thing. `s' gives an error; looks like it's trying to use `,' as a variable someplace. I was too tired to track it down last night. Charles> I'm looking forward to downloading your version and testing that, I'm Charles> very interested to see what changes you made (beyond, I assume, fixing Charles> the mapconcat 'identity to mapconcat 'int-to-string in a few places). I haven't done much with it yet and have not read the code either. I'll have to set aside some time for this. I wish I could get some income from it. I need another $200 a month to get all my bills paid.

1 participants
0 comments

Re: gutter display 24 years, 3 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >apologies (mainly to Andy, I guess) if these are known issues with > >current gutter code, but wanted to report in case they aren't > > Wierd. I'll see if I can reproduce. FWIW. I see these all the time too. I just though they were of the "known problem" category. Jan

5 participants
5 comments

[pcl-cvs] I've got 2.9.7 working, and packages. 24 years, 3 months

Karl M. Hegbloom

I have not tried to merge anything at all from the XEmacs version of `pcl-cvs'. This is straight from upstream with only the modifications it required to make it work in XEmacs. One thing in particular - `diff-mode.el' was useing `compilation-shell-minor-mode', which we do not have. I wonder if it's worth bringing in? I just blapped off the `-shell' part, and it seems to work fine. bindist packages are at: <URL:ftp://bittersweet.inetarena.com/pub/XEmacs> cvsweb is at: <URL:http://bittersweet.inetarena.com/cgi-bin/cvsweb/local-packages> anoncvs is at: export CVSROOT=:pserver:anoncvs＠bittersweet.inetarena.com:/usr/local/cvsroot cvs login <no password - I encrypted the empty string> cvs checkout local-packages The `site-config' stuff is only really meant for my machine and one at school; maybe it's interesting and useable elsewhere, maybe it's not. The `add-hooks' hack is neat... You'll perhaps want to add `turn-on-font-lock' to `diff-mode', `cvs-log-mode' and `cvs-status-mode'. Very pretty on white, but not with the default grey background. `gnuplot' mode is worth a look at if you use `gnuplot' much. Please don't post this all over the Internet; I'm on the other end of a 256k DSL line... It's NOT a huge public FTP site. Everyone in the xemacs-beta lists is welcome to it though. I'm glad to share. Yous will have to decide what all of this belongs in the cvs.xemacs.org repository. We can rsync or whatever it takes. `pcl-cvs' requires `diff-mode' and `easy-mmode'. I have those in a package called "local-xemacs-devel" for now. It's not a great name for it, but it works. My `Local.rules' and `XEmacs.rules' will be of interest to those who want to run live CVS checkouts of `xemacs-packages' with a `local-packages' also. I configure the package-path to point first at $xe/Local-Packages, then in $xe/Packages. My site-init stuff sets up a load path with the ~/.xemacs/xemacs-packages stuff on it, so a user can shadow things if they like. Time to get some work done now... ;-)

2 participants
3 comments

gnuserv 24 years, 3 months

Richard Zatorski

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta28) "Hermes" [Lucid] (sparc-sun-solaris2.6, Mule) of Mon Feb 7 2000 on ebola configured using `configure --prefix=/pkg/gnu --dynamic --with-gcc '--cflags=-O3 -mv8 -mtune=ultrasparc' --with-x --with-xpm --x-includes=/usr/openwin/include '--site-includes=/usr/dt/include /pkg/X11/include /pkg/local/include /pkg/local/include/db' --x-libraries=/usr/openwin/lib '--site-libraries=/usr/dt/lib /pkg/X11/lib /pkg/local/lib' --with-sound=native --with-database=berkdb,dbm --with-png --with-jpeg --infopath=/pkg/gnu/info:/pkg/local/info:/pkg/tetex/info --with-tooltalk=yes --with-cde=no --package-path=/pkg/gnu/lib/xemacs/packages --with-mule=yes --debug=no --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When I start up a second gnuserver on my workstation, I get the message: gnuserv process exited; restart with M-x gnuserv-start Doing what the message says just causes it to fail the same way repeatedly. BTW, In the past I've been able to create multiple servers on my workstation but I've never been able to conect to the port for each server. It always seemed that the last server proccess took over the communication port and the other server processes were just stranded. Recent keystrokes: misc-user misc-user Recent messages (most recent first): Parsing /home/razl/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading about...done Loading about... Gnuserv process exited; restart with `M-x gnuserv-start' Loading gnuserv...done Loading gnuserv...

1 participants
0 comments

Re: gutter display 24 years, 3 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > It always helps if people can give me reproducible test cases with xemacs > -vanilla. This what the gutter looks like after "xemacs -vanilla" Jan

1 participants
0 comments

ediff crash in latest snapshot 24 years, 3 months

John A. Turner

SGI Irix 6.5.6m gcc 2.95.2 updated and rebuilt this AM w/full error checking/debugging this is completely reproducible for me: 1. load 2 files into buffers 2. M-x ediff-buffers, RET, RET 3. mouse cursor is warped to ediff control frame 4. xemacs go boom *as soon as mouse is moved* (tried a couple of times and waited, but it never crashed until I touched the mouse) no lisp backtrace, but was running under gdb, so got this stack trace: #0 kill () at engine.c:648 #1 0x41531ac in raise () at iconv_converter.c:22087 the insight window shows: 0x40b04f0 <kill>: li $v0,1037 - 0x40b04f4 <kill+4>: syscall >>>>>>> 0x40b04f8 <kill+8>: bnez $a3,0x40b050c <kill+28> - 0x40b04fc <kill+12>: nop - 0x40b0500 <kill+16>: move $v0,$zero - 0x40b0504 <kill+20>: jr $ra - 0x40b0508 <kill+24>: nop - 0x40b050c <kill+28>: move $t8,$ra - 0x40b0510 <kill+32>: bal 0x40b0518 <kill+40> - 0x40b0514 <kill+36>: nop - 0x40b0518 <kill+40>: lui $t4,0x10 - 0x40b051c <kill+44>: daddiu $t4,$t4,10028 - 0x40b0520 <kill+48>: daddu $t4,$t4,$ra - 0x40b0524 <kill+52>: lw $t9,-27740($t4) - 0x40b0528 <kill+56>: move $ra,$t8 - 0x40b052c <kill+60>: jr $t9 - 0x40b0530 <kill+64>: nop -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 381-8400

1 participants
1 comments

Re: Lcrecords; Unix 98 macros; hash_table_hash 24 years, 3 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > Oh, well. Unfortunately, vendor header files tend to be a mess, and > it takes a few years for them to get properly fixed. I'm now sorry I > started down this path. Nevertheless, the idea of moving all feature > macro definitions into configure.in is sound. > > Please test this patch (don't forget to autoconf): ok, that works. Gunnar

1 participants
0 comments

Re: crash when using W3 24 years, 3 months

Hrvoje Niksic

"Manfred Bartz" <MBartz(a)xix.com> writes: > (gdb) where > #0 0x40251601 in kill () > #1 0x808d449 in fatal_error_signal (sig=11) at emacs.c:272 > #2 <signal handler called> > #3 0x813b021 in bufpos_to_bytind (buf=0x895a8b0, x=0) at insdel.c:1116 > #4 0x80f1764 in report_extent_modification (buffer=144025776, start=0, end=0, afterp=1) at extents.c:2272 > #5 0x813db40 in signal_after_change (buf=0x895a8b0, start=0, orig_end=32100, new_end=0) at insdel.c:2292 > #6 0x813eba5 in buffer_insert_string_1 (buf=0x895a8b0, pos=32100, > nonreloc=0xbfffee28 "..."..., reloc=136867036, offset=0, length=1024, flags=0) at insdel.c:2565 > #7 0x813ebe6 in buffer_insert_raw_string_1 (buf=0x895a8b0, pos=-1, > nonreloc=0xbfffee28 "..."..., length=1024, flags=0) at insdel.c:2585 Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > This supposed to be fixed.. in 21.2.27+ (I am not sure those > parameter values are correct). > > Hrvoje? This might be a different bug from the one I fixed. This crash comes from signal_after_change() being called with START==0, which triggers the assert in bufpos_to_bytind. Also, the backtrace seems weird -- I wonder if it comes from an optimized build? buffer_insert_raw_string_1() gets pos==-1, but buffer_insert_string_1 gets pos==32100. I don't see code in buffer_insert_raw_string_1() that handles that, but I suppose the optimizer could have done that. Now, the really strange thing is the call to signal_after_change(). In my copy of the code, it looks like this: signal_after_change (buf, pos, pos, pos + cclen); UNGCPRO; return cclen; } Notice that the first and the second argument are the same. In the backtrace, they're not. The only sense I can make out of it is that the crash doesn't come from that call to signal_after_change(). What could happen is that buffer_insert_string_1() calls prepare_to_modify_buffer(), which calls signal_before_change(), which can call cancel_multiple_change(), which calls signal_after_change(). The funcalls could be invisible due to optimizer having inlined them in the code -- this is possible because all of the functions involved are static. I'm not sure whether this theory holds water, because nothing in the backtrace seems to point to any code that calls begin_multiple_change. read_process_output() does play weird games with narrowing, though.

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