August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[Failure] 21.0 "Danish Landrace" XEmacs Lucid on i686-pc-cygwin32 27 years

Michael Hill

>From tarballs. `make' fails here: Loading /binary/xemacs-21.0-b52/src/../lisp/update-elc.el... Loading very-early-lisp... (2152) Loading find-paths.el... (13900) Loading packages.el... (23256) Loading setup-paths.el... (5444) Loading dump-paths.el... (0) Wrong type argument : stringp , nil rm -f ../lib-src/DOC; \ EMACSBOOTSTRAPLOADPATH="/binary/xemacs-21.0-b52/src/../lisp/:/binary/xem acs-21.0-b52" ./temacs -batch -l /binary/xemacs-21.0-b52/src/../lisp/make-docfile.el -- \ -o ../lib-src/DOC -d /binary/xemacs-21.0-b52/src -i ../lib-src/../site-packages \ abbrev.c alloc.c blocktype.c buffer.c bytecode.c callint.c callproc.c casefiddle.c casetab.c chartab.c cmdloop.c cmds.c console.c console-stream.c data.c device.c dired.c doc.c doprnt.c dynarr.c editfns.c elhash.c emacs.c eval.c events.c ntplay.c unexcw.c scrollbar-msw.c menubar-msw.c toolbar-msw.c dialog-msw.c console-msw.c device-msw.c event-msw.c frame-msw.c objects-msw.c select-msw.c redisplay-msw.c glyphs-msw.c dgif_lib.c gif_io.c menubar.c scrollbar.c dialog.c toolbar.c gui.c menubar-x.c scrollbar-x.c dialog-x.c toolbar-x.c gui-x.c file-coding.c inline.c console-tty.c device-tty.c event-tty.c frame-tty.c objects-tty.c redisplay-tty.c cm.c terminfo.c event-unixoid.c database.c process-unix.c event-stream.c extents.c faces.c fileio.c filemode.c floatfns.c fns.c font-lock.c frame.c general.c getloadavg.c glyphs.c glyphs-eimage.c hash.c imgproc.c indent.c insdel.c intl.c keymap.c line-number.c lread.c lstream.c macros.c marker.c md5.c minibuf.c objects.c opaque.c print.c process.c profile.c pure.c rangetab.c redisplay.c redisplay-output.c regex.c search.c sheap.c signal.c sound.c specifier.c strftime.c symbols.c syntax.c sysdep.c undo.c balloon_help.c balloon-x.c console-x.c device-x.c event-Xt.c frame-x.c glyphs-x.c objects-x.c redisplay-x.c xgccache.c xselect.c widget.c window.c Loading /binary/xemacs-21.0-b52/src/../lisp/make-docfile.el... Loading very-early-lisp... (2152) Loading find-paths.el... (13900) Loading packages.el... (23220) Loading setup-paths.el... (5444) Loading dump-paths.el... (0) Loading /binary/xemacs-21.0-b52/src/../lisp/dumped-lisp.el... (108) Spawning make-docfile ... Spawning make-docfile ...done EMACSBOOTSTRAPLOADPATH="/binary/xemacs-21.0-b52/src/../lisp/:/binary/xem acs-21.0-b52" ./temacs -batch -l /binary/xemacs-21.0-b52/src/../lisp/loadup.el dump Loading /binary/xemacs-21.0-b52/src/../lisp/loadup.el... Using load-path (/binary/xemacs-21.0-b52/src/../lisp/ /binary/xemacs-21.0-b52) Loading very-early-lisp... (2152) Loading /binary/xemacs-21.0-b52/src/../lisp/dumped-lisp.el... (160) Loading /binary/xemacs-21.0-b52/lisp/backquote.elc... (2924) Loading /binary/xemacs-21.0-b52/lisp/bytecomp-runtime.elc... (4664) Loading /binary/xemacs-21.0-b52/Installation.el... (36) Loading /binary/xemacs-21.0-b52/lisp/find-paths.elc... (5592) Loading /binary/xemacs-21.0-b52/lisp/packages.elc... (9972) Loading /binary/xemacs-21.0-b52/lisp/setup-paths.elc... (2924) Loading /binary/xemacs-21.0-b52/lisp/dump-paths.elc... (0) Load file subr: not found Fatal error during load, aborting make[1]: [xemacs] Error 1 (ignored) make[1]: *** [xemacs] Error 1 make: *** [src] Error 2

1 participants
0 comments

font lock faces ugly 27 years

Neal D. Becker

This is the first time I've tried 21.0. I use a white background, which I think is very common. Using defaults for all of font lock faces, I think font lock is *ugly* compared to 20.4 defaults. All the red4 looks brown. blue4 looks noncommittal. green4 is ugly. steelblue is ugly. Why the change from 20.4 defaults? Those settings looked just fine here, I never had any inclination to change them. The 21.0 settings look piss-poor here.

1 participants
0 comments

Re: b52 build failure w/union 27 years

SL Baur

Apply the patch I posted. nbecker <nbecker(a)fred.net> writes in xemacs-beta(a)xemacs.org: > i686-pc-linux-gnu --union: > eval.c: In function `Fcommand_execute': > eval.c:2565: warning: implicit declaration of function `Frun_hooks' > eval.c:2565: incompatible types in return > eval.c: At top level: > eval.c:3615: warning: type mismatch with previous implicit declaration > eval.c:2565: warning: previous implicit declaration of `Frun_hooks' > eval.c:3615: warning: `Frun_hooks' was previously implicitly declared to return `int' > make[1]: *** [eval.o] Error 1

1 participants
0 comments

b52 strangeness 27 years

Neal D. Becker

Just fooling around with b52, I tried tools/directory/get email. When prompted for protocol, I hit ? for completions. After a long time I got a list of I don't know what, every symbol known to emacs?

1 participants
0 comments

b52 build failure w/union 27 years

Neal D. Becker

i686-pc-linux-gnu --union: eval.c: In function `Fcommand_execute': eval.c:2565: warning: implicit declaration of function `Frun_hooks' eval.c:2565: incompatible types in return eval.c: At top level: eval.c:3615: warning: type mismatch with previous implicit declaration eval.c:2565: warning: previous implicit declaration of `Frun_hooks' eval.c:3615: warning: `Frun_hooks' was previously implicitly declared to return `int' make[1]: *** [eval.o] Error 1

1 participants
0 comments

libpng! 27 years

Neal D. Becker

I'm trying to build on i686-pc-linux-gnu RH5.1. It seems I need libpng-1.0.2. OK, I built libpng-1.0.2 modifying the makefile to build share lib via libtool. What to call the soname? I'm assuming that libpng-1.0.2 is not binary compatible with 1.0.1. On RH5.1 libpng-1.0.2 is called libpng-2.1.0 (I think that was actually my doing when I put it into libgr, IIRC). So I'm calling libpng-1.0.2 libpng-3.0.0. What do you think?

1 participants
0 comments

Re: [Crash] gnuclient -nw 27 years

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > > Glynn Clements <glynn(a)sensei.co.uk> writes: > >> Using `gnuclient -nw <filename>' kills XEmacs, but only when started > >> from the WM. If it is started from an xterm or the console, it works > >> fine. > > Why should we care? When I tried this I got (with olvwm on Linux > linked with libc6 and libgpm): I think you are misunderstanding Glynn, or I am. I think he starts XEmacs from his WM but is running gnuclient in an xterm. Jan This second case where it matter whether XEmacs is started from the WM or otherwise, I cannot figure out why it should make a differnce. The other guys bug is even more weird but reprodable (if XEmacs is started from mwm, (gnuserv-start) is in .emacs THEN (and only then) XEmacs does not see second request to edit files (although gnuserv writes it on STDOUT, XEmacs never calls the process filter), using gnuclient -batch twice works.). It is so complicated that I agreed with him to wait for 21.0 in the hope that all the process and stream fixups magically fix it. Anybody have a clue about what is typically different between a WM environment and say a shell in Xterm? (Note the unix environment is more-or-less the same in each case)

2 participants
1 comments

Python script to update binary packages 27 years

Charles G Waldman

For what it's worth, here's a little Python script I use to keep my local package repository up to date. Martin posted something similar recently, but it was in Perl, to which I have a slight allergy. Run it in the same directory that your *.pkg.tar.gz files live. There are a few configuration variables at the very top that you can change. Hopefully it's pretty self-explanatory. #!/usr/local/bin/python # user-configurable variables FTP_SERVER="ftp.xemacs.org" PACKAGE_DIR="/pub/xemacs/beta/xemacs-21.0/packages/binary-packages" fetch_all = 0 # if fetch_all is nonzero, we get all packages on the server. # Otherwise we only update the packages which are already present in the # current directory. verbose = 1 # end of user-configurable variables import os, string from ftplib import FTP def newer(a,b): # args are 2-tuples containing (major, minor) version number if a[0]>b[0]: return 1 elif a[1]>b[1]: return 1 else: return 0 ## parselist takes an "ls"-type listing of XEmacs packages and returns ## a dictionary, where the key is basename of the package, and the ## value is a 3-tuple of the form ## (version-major, version-minor,filename) def parselist(listing): dict={} for f in listing: words = string.split(f,'-') if words[-1] != 'pkg.tar.gz': if verbose: print "skipping", f continue version = string.split(words[-2],'.') name = string.join(words[:-2],'-') if name in dict.keys(): if not newer(version, dict[name]): if verbose: print f, 'is not newer than', dict[name][2] continue dict[name] = (version[0],version[1],f) if verbose: print name, version[0],version[1] return dict if verbose: print "Local packages" local = parselist(os.listdir(".")) ftp = FTP(FTP_SERVER) ftp.login() ftp.cwd(PACKAGE_DIR) if verbose: print "Remote packages:" remote=parselist(ftp.nlst()) ##callback function for ftp.retrbinary openfile = None def storeit(data): if openfile: openfile.write(data) if fetch_all: packages = remote.keys() else: packages = local.keys() for key in packages: if newer(remote[key],local[key]): name = remote[key][2] if verbose: print "fetching", name openfile = open(name,"w") ftp.retrbinary('RETR '+name, storeit, 1024) openfile.close() os.unlink(local[key][2])

1 participants
0 comments

Re: Bugs, bugs, bugs -- help! 27 years

William M. Perry

Raymond Toy <toy(a)rtp.ericsson.se> writes: > >>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > >>>>> "Kevin" == Kevin Oberman <oberman(a)es.net> writes: > Kevin> I also think efs REALLY needs to be included in the base > Kevin> distribution! > > Jan> Package get really needs to use http by default as stripped-down > Jan> url-http is a lot more lightweight then efs and can therefore be put > Jan> in the base distribution. (MS has refused making an efs-light for this > Jan> purpose, for good reason). > > I think this is very important. Setting up efs is not always easy, > especially if you're behind a firewall[1]. But almost all companies have > an http proxy to let people go out and get stuff. > > Right now I have to manually ftp packages, so I just usually end up > ftp'ing the entire packages directory because it's too much work to > update just the packages I want. We could either strip down url-http, or start writing some of this in C. :) I'm game either way. I've had zero time for working on Emacs/W3 the last few months though. -Bill P.

1 participants
0 comments

[21.2] gnuserv doesn't exit when xemacs exits 27 years

giacomo boffi

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 "Aeolus" [Lucid] (i586-pc-linux) of Tue Aug 11 1998 on boffi95.stru.polimi.it Please describe exactly what actions triggered the bug and the precise symptoms of the bug: 1. let my WM (gwm) start xemacs like this xemacs -f gnuserv-start 2. exit xemacs 3. observe a gnuserv process that eats up to 95% of cpu 4. starting again xemacs i'm not able to get a new gnuserv process, and gnuclient doesn't work anymore if i do 'xemacs -f gnuserv-start' from the command line, point 3 doesn't happen: exiting xemacs kills the gnuserv process Recent keystrokes: misc-user Recent messages (most recent first): Loading bbdb... Parsing /home/jim/.mailrc... done Parsing /home/jim/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Loading gnuserv...done Loading gnuserv... Loading efs-cu...done

1 participants
0 comments

2025

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