October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Hans-Guenter Weigand

Olivier Galibert, <galibert(a)pobox.com> wrote: > >Since I can't cvs diff at a reasonable speed and cvs update'ing in my >trees take ages, I'd like to be able to mirror (readonly of course) >the xemacs cvs repository. Is there cvsupd or something like that >around there? The FreeBSD and OpenBSD projects use ctm to distribute updates for the source and even the cvs repository. Ctm is reliable and well tested. It makes a file called 'delta', which contains the changes in a directory tree since its last run, gzip's it and mails it out, preferrably to a mailing list. Run by cron daily it is sort of "set up and forget", as long as diskspace is sufficient. :) The only thing that needs to be done manually, is to supply a new snapshot tar.gz-file of the ctm target directory every few month. It is needed by new users to bootstrap. After a new user subscribed to the ctm-list and received the first delta, he would ftp the snapshot file and the delta files made between the one he had in the mail and this snapshot. If the cvs repository is distributed by ctm, people can use cvs locally with all its features, without need for a leased line. This is optimal for (us) poor modem users... Ctm is written in C, not in Modula as CVSup. >Actually, it would be fun to automagically trigger the mirror on >Steve's "Subject: .*XEmacs.*released.*" mails to xemacs-announce :-) It is a good idea to mail out the log messages of the cvs commits to a mailing list. People can track the development easily, and know when to update their local sources. See - http://www.openbsd.org/ctm.html - The FreeBSD Handbook for more. -hgw

4 participants
5 comments

Re: Link error in 21.2-b2/NT 26 years, 1 month

Raymond Toy

>>>>> "Stefan" == Stefan Tilkov <stilcom(a)gmx.net> writes: Stefan> Thanks to all who replied! I used Sean's stubs, added my own for readlink() Stefan> and symlink(), implemented rindex() and index() and managed to compile and Stefan> link everything. Surely NT has strchr and strrchr? Use that instead of index and rindex, respectively. Ray

1 participants
0 comments

Re: 21.2 isearch keymap bug/changed behavior 26 years, 1 month

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > It appears to stem from this change: > > 1998-09-22 Hrvoje Niksic <hniksic(a)srce.hr> > > * isearch-mode.el (isearch-mode): Use overriding-local-map to set > the keymap, not minor-mode-map-alist. > (isearch-done): Restore overriding-local-map. > > What's happening is in Gnus summary mode I used to be able to > isearch for a group and then hit M-g to fetch new mail in it. In > 21.2 this instead runs the unbound (in Gnus) `goto-line' command. > > I prefer the 21.0 behavior. Yup; this is a bug I'll look into fixing. At the time I made this change, isearch mode looked like it could handle this kind of situation. Hmm. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Oh lord won't you buy me a color TV...

1 participants
0 comments

Problems compiling XEmacs under Solaris 2.5 26 years, 1 month

Chris Tessone

Hi. I've been attempting to compile XEmacs under Solaris 2.5. Here are the commands I used to compile it: $ tar -zxf xemacs-21.0.tar.gz && tar -zxf xemacs-21.0-elc.tar.gz && tar -zxf xemacs-21.0-info.tar.gz $ cd xemacs-21.0 $ ./configure --prefix="/imsa" --external-widget --without-gpm --with-workshop --with-site-lisp --debug $ make Make dies with some errors after xemacs is compiled and it tries to run xemacs. Here is the lisp backtrace: # (catch #<INTERNAL EMACS BUG (opaque, size=4) 0x256ba0> ...) # (unwind-protect ...) # (unwind-protect ...) kill-emacs(1) # bind (error debug-issue-ebola-notices) batch-byte-compile() # bind (arg) command-line-do-funcall("-f") # 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 ...) xargs: /home/tessone/tmp/xemacs-21.0/src/xemacs: terminated by signal 6 make: *** [all-elc] Error 125 And here is the output from GDB: #0 0xef2b4610 in _kill () #1 0x46f3c in fatal_error_signal (sig=6) at emacs.c:262 #2 <signal handler called> #3 0xef2b4610 in _kill () #4 0xef27963c in abort () #5 0x46e94 in assert_failed (file=0x14ae00 "elhash.c", line=436, expr=0x14aed8 "gc_in_progress") at emacs.c:2608 #6 0x4230c in Fgethash (key=17, hashtable=2665024, default_=539099852) at elhash.c:436 #7 0xa8010 in image_instantiate (specifier=2285568, matchspec=539099852, domain=539561984, instantiator=-2144882800, depth=17) at glyphs.c:2103 #8 0x4aa34 in primitive_funcall (fn=0xa7d48 <image_instantiate>, nargs=5, args=0xefffd2f8) at eval.c:2862 #9 0x507b8 in call_with_suspended_errors_1 (opaque_arg=2452256) at eval.c:2060 #10 0x49308 in call_with_suspended_errors (fun=0xa7d48 <image_instantiate>, retval=539099852, class=-1608042740, errb=ERROR_ME_NOT, nargs=5) at eval.c:1328 #11 0xf770c in specifier_instance_from_inst_list (specifier=539514112, matchspec=539099852, domain=539561984, inst_list=1076382860, errb=ERROR_ME_WARN, no_quit=1, depth=1) at specifier.c:2384 #12 0xf7c0c in specifier_instance (specifier=539514112, matchspec=539099852, domain=539561984, errb=ERROR_ME_WARN, no_quit=0, no_fallback=0, depth=1) at specifier.c:2521 ---Type <return> to continue, or q <return> to quit--- #13 0xf8078 in recompute_all_cached_specifiers_in_window (w=0x291000) at specifier.c:2741 #14 0x1269a0 in Fset_window_buffer (window=539561984, buffer=539460096) at window.c:3171 #15 0x9f7f4 in delete_frame_internal (f=0x28c400, force=-1608142844, called_from_delete_device=1, from_io_error=268435455) at frame.c:1506 #16 0x374c0 in delete_device_internal (d=0x28bd00, force=2641700, called_from_delete_console=268435455, from_io_error=0) at device.c:781 #17 0x2f3b0 in delete_console_internal (con=0x285180, force=1076383460, called_from_kill_emacs=268435455, from_io_error=0) at console.c:674 #18 0x460f4 in Fkill_emacs (arg=1) at emacs.c:2187 #19 0x4bb6c in funcall_recording_as (recorded_as=-1608057820, nargs=1, args=0xefffdbb0) at eval.c:3197 #20 0x4fdc0 in Ffuncall (nargs=2, args=0xefffdbb0) at eval.c:3238 #21 0x26278 in Fbyte_code (bytestr=1614246840, vector=-2143973248, maxdepth=2285568) at bytecode.c:416 #22 0x4cd8c in funcall_lambda (fun=540494052, nargs=0, arg_vector=0xefffdf44) at eval.c:3597 #23 0x4bde0 in funcall_recording_as (recorded_as=-1607411228, nargs=0, args=0xefffdf40) at eval.c:3214 #24 0x4fdc0 in Ffuncall (nargs=1, args=0xefffdf40) at eval.c:3238 #25 0x26278 in Fbyte_code (bytestr=1612529092, vector=-2145567268, maxdepth=2285568) at bytecode.c:416 ---Type <return> to continue, or q <return> to quit--- str=1612529092, vector=-2145567268, maxdepth=2285568) at bytecode.c:416 ---Type <return> to continue, or q <return> to quit--- #26 0x4cd8c in funcall_lambda (fun=538787304, nargs=1, arg_vector=0xefffe68c) at eval.c:3597 #27 0x4bde0 in funcall_recording_as (recorded_as=-1607589692, nargs=1, args=0xefffe688) at eval.c:3214 #28 0x4fdc0 in Ffuncall (nargs=2, args=0xefffe688) at eval.c:3238 #29 0x26278 in Fbyte_code (bytestr=1612535164, vector=-2145560956, maxdepth=2285568) at bytecode.c:416 #30 0x4cd8c in funcall_lambda (fun=538794024, nargs=0, arg_vector=0xefffeb8c) at eval.c:3597 #31 0x4bde0 in funcall_recording_as (recorded_as=-1607589092, nargs=0, args=0xefffeb88) at eval.c:3214 #32 0x4fdc0 in Ffuncall (nargs=1, args=0xefffeb88) at eval.c:3238 #33 0x26278 in Fbyte_code (bytestr=1612532916, vector=-2145563356, maxdepth=2285568) at bytecode.c:416 #34 0x4cd8c in funcall_lambda (fun=538791400, nargs=0, arg_vector=0xeffff194) at eval.c:3597 #35 0x4bde0 in funcall_recording_as (recorded_as=-1607589308, nargs=0, args=0xeffff190) at eval.c:3214 #36 0x4fdc0 in Ffuncall (nargs=1, args=0xeffff190) at eval.c:3238 #37 0x26278 in Fbyte_code (bytestr=1612530996, vector=-2145565208, maxdepth=2285568) at bytecode.c:416 #38 0x4cd8c in funcall_lambda (fun=538789804, nargs=0, arg_vector=0xeffff358) at eval.c:3597 ---Type <return> to continue, or q <return> to quit--- #39 0x4c790 in apply_lambda (fun=538789804, numargs=0, unevalled_args=-1608142844) at eval.c:3501 #40 0x4b48c in Feval (form=1076516972) at eval.c:3085 #41 0x488c4 in condition_case_1 (handlers=-1608142748, bfun=0x4aad0 <Feval>, barg=1076516972, hfun=0x2d8c8 <cmd_error>, harg=-1608142844) at eval.c:1653 #42 0x2d954 in top_level_1 (dummy=-1608142844) at cmdloop.c:206 #43 0x4fad0 in internal_catch (tag=-1608065172, func=0x2d91c <top_level_1>, arg=-1608142844, threw=0x0) at eval.c:1328 #44 0x2cf50 in initial_command_loop (load_me=186652) at cmdloop.c:285 #45 0x459e0 in xemacs_21_0_sparc_sun_solaris2_5 (argc=6, argv=0xeffffa24, envp=0xeffffa40, restart=0) at emacs.c:1705 #46 0x47124 in main (argc=0, argv=0xeffffa24, envp=0xeffffa40) at emacs.c:2122 (gdb) -- Chris Tessone tessone(a)fnal.gov tessone(a)imsa.edu PH/sendmail SNPC System Administration Perl/Shell All you need is Perl, love. Perl is all you need. http://www.imsa.edu/~tessone/

1 participants
0 comments

New packages get installed in xemacs-packages/man 26 years, 1 month

Mark Burton

Hi, Sorry if this has already come up, but I have only just started to subscribe to xemacs-beta. Using 21.2-b3 I have been trying out the fine network package retrieval & installation stuff and found that new packages were getting installed in /usr/local/xemacs/lib/xemacs/xemacs-packages/man ??? late-packages was being set to: ("/usr/local/xemacs/lib/xemacs/xemacs-packages/" "/usr/local/xemacs/lib/xemacs/xemacs-packages/man") Adding 'man' into packages-special-base-regexp cured the problem. (defvar packages-special-base-regexp "^\$etc\\|info\\|lisp\\|lib-src\\|bin\\|pkginfo\\|man\$$" "Special subdirectories of packages.") Strangely, the 'man' part was in the packages.el supplied with the last xemacs 21.0, why was it taken out I wonder. While I'm here, I have noticed that (with xemacs 21.?) the minibuffer doesn't seem to scroll horizontally correctly. For example, when using find-file and the file path name (after completion) is longer than the minibuffer C-e doesn't make the end of the file name visible. Is this a bug or do I need to adjust some setting? Thanks, Mark

1 participants
1 comments

Re: cvs mirroring 26 years, 1 month

SL Baur

Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: > I also have no idea as to the implications of libc5 vs libc6. Whatever you choose, make sure it uses libc6 aka GNU libc. All of the most recent distributions use it, so it shouldn't particularly be a problem. The two are not binary compatible (hence the .so major version number change). All new code should work with GNU libc and usage and support of libc5 is vanishing.

1 participants
0 comments

New tar RPMS 26 years, 1 month

W. Reilly Cooley, Esq.

Hello! I just uploaded a patched version of GNU tar to support bzip2 compression. I also compiled with pgcc-2.90.29 with options '-O6 -mpentium'. Ideally, the new version should show up in the appropriate places on Red Hat's FTP server soon, as tar-1.12-3.src.rpm and tar-1.12-3.i386.rpm. (It would be nice if the incoming package monitor would recognize *.[456]68.rpm, but it seems to only delete them. Wil -- W. Reilly Cooley Naked Ape Consulting wcooley(a)nakedape.ml.org http://nakedape.ml.org Internet Meta-Resources ------> http://nakedape.ml.org/links/ "All the Net you need to be a Geek" -- To unsubscribe: mail -s unsubscribe redhat-announce-list-request(a)redhat.com < /dev/null

1 participants
0 comments

Re: Switching window for buttons 26 years, 1 month

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I agree with whoever observed that it is obnoxious for the widget > buttons to switch to the window when pressing the button. I've never > noticed it before because I've mostly used widget buttons with > Customize, where this is not a big problem. This patch should fix it > for XEmacs. > > Please don't apply the patch until wmperry confirms that it doesn't > break W3. The length is due to reindentation. I see no reason this should break emacs/w3, other than the current window will be replaced with whatever URL you just clicked on though. A little odd. I haven't actually had a chance to test this though - my w3 time is ridiculously short. :( -bill p.

1 participants
0 comments

Re: cvs mirroring 26 years, 1 month

SL Baur

Darryl Okahata <darrylo(a)sr.hp.com> writes in xemacs-beta(a)xemacs.org: > Hans-Guenter Weigand <hgweigand(a)wiesbaden.netsurf.de> wrote: >> The FreeBSD and OpenBSD projects use ctm to distribute updates for the >> source and even the cvs repository. Ctm is reliable and well tested. It > If possible, the FreeBSD folks recommend that CVSup be used; ctm is > available, but CVSup is the recommended way to go (it was originally > developed for FreeBSD). Like ctm, CVSup is reliable and well tested. > CVSup is VERY nice. Really. I'll have to see if I can help Steve > get it running. If you wish to do this, I'll send you the patches I made to get it to compile and link (but not run :-() with glibc-2.0.7. > [ Bleah. Can anyone recommend a good, cheap Linux? ] :-)

2 participants
1 comments

21.2 isearch keymap bug/changed behavior 26 years, 1 month

SL Baur

It appears to stem from this change: 1998-09-22 Hrvoje Niksic <hniksic(a)srce.hr> * isearch-mode.el (isearch-mode): Use overriding-local-map to set the keymap, not minor-mode-map-alist. (isearch-done): Restore overriding-local-map. What's happening is in Gnus summary mode I used to be able to isearch for a group and then hit M-g to fetch new mail in it. In 21.2 this instead runs the unbound (in Gnus) `goto-line' command. I prefer the 21.0 behavior.

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 October 1998