January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: rssh.el interactions with ange-ftp/efs 25 years, 10 months

Matt Curtin

Richard Stallman <rms(a)gnu.org> writes: > At the same time, I try to avoid undermining CVS in favor of > ClearCase, which Emacs support for ClearCase would do. If I am understanding you properly, then, the issue is: How do we add cryptographic functionality to Emacs without removing the impetus to create a free SSH-like tool? It seems to me that this is not a question for Emacs. A free replacement for ssh would do well to mimic ssh's command-line interface. This would solve both the problem of tying Emacs to non-free foundations and allow programs besides Emacs to simply plug-in an SSH replacement, should they choose to do so. Is this not true? Or is the concern that if people are able to easily transfer files from system to system via SSH via Emacs that progress on a free replacement would stop? -- Matt Curtin cmcurtin(a)interhack.net http://www.interhack.net/people/cmcurtin/

1 participants
0 comments

21.2-b8 "Artemis" failure with RH5.2 ? 25 years, 10 months

N J Doye

Flame me to death if I'm being stupid or if I missed this thread over Xmas, but 21.2 beta 8 failed to compile at home under RedHat 5.2 (with the supplied kernel, etc - pretty much still "out of the box" - I only upgraded last week). I've checked at http://www.xemacs.org/list-archives/xemacs-build-reports/9901 but nothing really seems to match it. make[1]: Entering directory `/home/ccsnjd/src/xemacs/xemacs-21.2.8/src' EMACSBOOTSTRAPLOADPATH="/home/ccsnjd/src/xemacs/xemacs-21.2.8/src/../lisp/:/home/ccsnjd/src/xemacs/xemacs-21.2.8" ./temacs -batch -l /home/ccsnjd/src/xemacs/xemacs-21.2.8/src/../lisp/update-elc.el Loading /home/ccsnjd/src/xemacs/xemacs-21.2.8/src/../lisp/update-elc.el... Loading very-early-lisp... (2124) Loading find-paths.el... (13900) Loading packages.el... (24336) Loading setup-paths.el... (5480) Loading dump-paths.el... (0) Loading /home/ccsnjd/src/xemacs/xemacs-21.2.8/src/../lisp/dumped-lisp.el... (136) Loading /usr/local/lib/xemacs/packages/lisp/efs/dumped-lisp.el... (0) make[1]: Leaving directory `/home/ccsnjd/src/xemacs/xemacs-21.2.8/src' MAKE='make' EMACS='./src/xemacs' sh /home/ccsnjd/src/xemacs/xemacs-21.2.8/lib-src/update-elc.sh (using ./src/xemacs) Recompiling in /home/ccsnjd/src/xemacs/xemacs-21.2.8 with /home/ccsnjd/src/xemacs/xemacs-21.2.8/src/xemacs... Autoloading failed to define function batch-remove-old-elc xemacs exiting. make: *** [all-elc] Error 255 [ccsnjd＠pangur-ban xemacs-21.2.8]$ uname -a Linux pangur-ban.dev.niss.ac.uk 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 i586 unknown

1 participants
0 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Many of the recent performance changes included replacing Fsetcar() > Hrvoje> and Fsetcdr() with XCAR/XCDR on the left side of an > Hrvoje> assignment. > > This is also bad for another reason---if we ever want to put in a > write barrier to support faster GC, we'll have to change things back > to Fsetcar/cdr. I won't change things back to Fsetcar/cdr because they introduce needless error checking (the point of XCAR/XCDR is that we *know* we're accessing conses), but I think I'll introduce XSETCAR/XSETCDR macros with no loss of speed.

2 participants
1 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> I won't change things back to Fsetcar/cdr because they introduce Hrvoje> needless error checking (the point of XCAR/XCDR is that we *know* Hrvoje> we're accessing conses), but I think I'll introduce XSETCAR/XSETCDR Hrvoje> macros with no loss of speed. That does the trick as well. I'll get to this, eventually. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Many of the recent performance changes included replacing Fsetcar() Hrvoje> and Fsetcdr() with XCAR/XCDR on the left side of an Hrvoje> assignment. This is also bad for another reason---if we ever want to put in a write barrier to support faster GC, we'll have to change things back to Fsetcar/cdr. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Pending delete mode 25 years, 10 months

Philip Aston

Hrvoje Niksic writes: > Philip Aston <philipa(a)parallax.co.uk> writes: > > > I installed 21.0 last week and have been banging my head against > > this for a while. Could be just package-new-world-order-newbie > > problems, I wondered whether you can help. > > > > The question is: "Where has pending delete mode gone? Shouldn't it > > be part of the xemacs-base package?" > > I don't know. Try asking at xemacs-beta(a)xemacs.org. >

2 participants
2 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 10 months

Hrvoje Niksic

Richard Stallman <rms(a)gnu.org> writes: > Whether you like it or not, people are using ssh because it fulfils > their need, a need they consider very important. > > Whether I like it or not, most people don't agree with the goals of > the GNU Project. (... importance of saying no ...) This is a non-sequitur, but I see where it's leading to. You cut the most important part of what I said, and it wasn't by chance that you cut it. By disallowing your users to use ssh from GNU Emacs, you are doing a disservice to your users and, ultimately, to GNU. If you don't provide ssh support, others will, and you will lose a foothold in the community. Even when the free ssh replacement is done, the foothold might not be regained. But this is your choice, and I will not criticize it any more. Fortunately, the GPL allows the users to choose. I don't think the XEmacs project will follow your line of reasoning -- usefulness to the users comes first, politics comes second.

6 participants
10 comments

Latest shlib support breaks 21.2 25 years, 10 months

Martin Buchholz

configure seems to think the -Wl,-Bexport flag will work on Solaris with Sun cc. This needs to be fixed. 21.2.8 builds for me on Solaris, but the latest CVS sources do not. JKJ, please fix. We need to be able to support any compiler on any system. An additional comment: Because XEmacs rewrites so many of the macros shipped with autoconf, I rejected the idea of providing an aclocal.m4 in a past configure hacking project. make[1]: Entering directory `/export/host/mulelab/mulework/xemacs/martin/x/build/solaris/mos/src' /net/etlsolon/export/opt/SUNWspro/bin/cc -v -fast -xO5 -L/usr/local/lib -L/usr/ccs/lib -xildoff -R/usr/local/lib:/usr/dt/lib -L/usr/dt/lib -L/usr/local/lib -Wl,-Bexport -o temacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o unexsol2.o tooltalk.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o mule-coding.o file-coding.o input-method-xlib.o mule-wnnfns.o sunplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o getloadavg.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o balloon_help.o balloon-x.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o xgccache.o xselect.o widget.o window.o lastfile.o gmalloc.o vm-limit.o ralloc.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lwnn -lXaw -lpng -ljpeg -lz -lXpm -ltt -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -lgdbm -lcurses /usr/demo/SOUND/lib/libaudio.a -lintl -lkvm -lkstat -lm -lsocket -lnsl -lelf -lgen -ldl ld: fatal: option -B has illegal argument `export' ld: fatal: Flags processing errors make[1]: *** [temacs] Error 1 My configure line is: ==> /work1/home/martin/x/ws/dev/configure --extra-verbose --with-gnu-make --package-path=~/.xemacs:/usr/users/martin/x/packages/:/usr/users/martin/x/mule-packages/ --site-prefixes=/usr/local '--compiler=/net/etlsolon/export/opt/SUNWspro/bin/cc -v' --error-checking=none --debug=no --memory-usage-stats=no --use-union-type=no --with-mule --with-pop --with-dragndrop=no --use-minimal-tagbits=no --use-indexed-lrecord-implementation=no '--cflags=-fast -xO5' --prefix=/usr/users/martin/x/inst --exec-prefix=/usr/users/martin/x/inst/solaris

1 participants
0 comments

Re: Packages and Building XEmacs from CVS 25 years, 10 months

SL Baur

Alastair Burt <burt(a)dfki.de> writes: > Dear beta mailing listers, > I am still having trouble trying to build XEmacs 20.1 from CVS. I would > prefer to build from CVS, because eventually I would like to add x-symbol > to CVS tree. > I configure like this: > ./configure --prefix=/home/burt/lib/xemacs --with-mule--package-path="~/.xemacs::/home/burt/lib/xemacs/lib/xemacs/mule-packages:/home/burt/lib/xemacs/lib/xemacs/xemacs-packages" The easiest way to do this is to take advantage of the fact that a local package hierarchy will override the compiled-in package path. You basically need to create a minimal package hierarchy somewhere and then symlink it in the top-level XEmacs source directory. I've put a tarball of my current set of build-from-scripts on the FTP site: ftp://ftp.xemacs.org/pub/xemacs/beta/build-scripts.tar.gz They assume that you have a directory structure that contains both CVS'ed XEmacs core sources and package sources in the same directory and are oriented towards building things for distribution, but they will show you the procedure for building (almost[1]) totally from scratch. Footnotes: [1] You need an existing bytecompiled copy of the mule-base package for the first phase, but it gets re-bytecompiled from current sources later on.

1 participants
0 comments

Re: fast-lock-cache-name causes error 25 years, 10 months

Enrico Scholz

Colin Rafferty <craffert(a)ms.com> writes: > Enrico Scholz writes: > > > if "buffer-file-name" in fast-lock.el:529, v3.11.01 is nil (I don't > > know why it happens, but it happens) "expand-file-name" will be called > > with nil which causes an error. > > There is a comment in the code that mentions that crypt++ can cause > this to happen. However, since I don't use fast-lock, I am not > competent to fix the code. This error isn't limited to crypt++ only. It can be caused by the following steps: 1. Turn on Options/Syntax Hightlighting/Lazy+Caching 2. Press the Help button in the toolbar 3. Select the xemacs node + press enter 4. Press "q" in the help frame 5. Switch to the remaining help window (why does it exists still?) 6. Try C-x C-k > > However, since you are using a post-20.4 XEmacs, you may want to > switch to using lazy-shot instead of fast-lock. It doesn't save .flc > files, and it works very well. > > (add-hook 'font-lock-mode-hook 'turn-on-lazy-shot) The error disappeared when I removed "(set fast-lock-mode t nil (fast-lock))". Enrico -- eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de talk: ensc(a)ultra.csn.tu-chemnitz.de

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