December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Jan Vroonhof

Paul Krause <pkrause(a)ibelong.com> writes: > > It cares about the fact that (identity buffer-file-truename) is a > > sequence because it supposed to concat the results. > > OK. But since it is a sequence (a string), why does it think it isn't? buffer-file-truename is a symbol not a string. It is probably meant to pass the value of buffer-file-truename somewhere. Jan

2 participants
1 comments

Re: lpr.el sync 24 years, 6 months

Jan Vroonhof

Paul Krause <pkrause(a)ibelong.com> writes: > I get a bizarre error. Why does mapconcat care whether > buffer-file-truename is a sequence? As long as ("/p" > buffer-file-truename) is a sequence (and it is) everything should be > fine. > > Signaling: (wrong-type-argument sequencep buffer-file-truename) > mapconcat(identity ("/p" buffer-file-truename) " ") It cares about the fact that (identity buffer-file-truename) is a sequence because it supposed to concat the results. Jan

2 participants
1 comments

Re: unexelf on irix (kinda digest) 24 years, 6 months

Gunnar Evermann

Max Matveev <makc(a)sgi.com> writes: > Gunnar Evermann writes: > :> I have done test builds of XEmacs21.1.8cvs+Max's patch on two systems: > :> > :> IRIX64 ruby 6.2 06101031 IP28 mips with gcc 2.7.2.3 > :> IRIX truth 6.5 01221553 IP32 mips with MIPSpro 7.2.1 > :> > :> gory details: > :> > :> - the binary built on truth(6.5) works on ruby(6.2) > That's most supprising, unless you're using some other libc on Irix > with gcc. Normally, binaries, build on 6.5 would not run on 6.2 > because 6.5 libc has some symbols, which are not present in 6.2 libc. you are right of course. Actually it's the other way around :-) The binary built on ruby(6.2) with the -G0 hack runs on truth(6.5). Gunnar

1 participants
0 comments

Re: Running packages "in place" 24 years, 6 months

Didier Verna

Hrvoje Niksic wrote: > Yes, that might work. The reason I ask is that I'd like to apply (and > commit) patches to packages, and I'm not sure how to do that if I > can't test the changes I'm making. Personally, I have the CVS archive checked out, and the packages installed. When I'm hacking a package file, I do it on the /installed version/, and reload it (or simply the modified function) to check the result. Once I'm satisfied, I copy the file back to my cvs checked out version, rerun `make binkit STAGING=[site,mule or xemacs package dir]' to see if the compilation and reinstallation process goes well, check the work with a vanilla xemacs, and if it's ok, then I run a `cvs ci'. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

lpr.el sync 24 years, 6 months

Andy Piper

I think the latest version of lpr.el from the FSF should fix printing problems under windows. Could someone with the latest build and a printer try this out, and if it works I will cook up a patch. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
1 comments

Scanning FSF 20.5 for fixes.. 24 years, 6 months

Jan Vroonhof

Rumour has it FSF 20.5 contains a few (minor) Y2K fixes. It would be nice if somebody could so a scan of the Chanelogs what bugs they fixed (not just the Y2K ones). We don't have the embarrassing fix in timezone.el. Jan

1 participants
0 comments

Re: Running packages "in place" 24 years, 6 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > When changing a core Lisp or C file, I recompile it and see how XEmacs > > fares. With the packages, I apparently have to remake and reinstall > > the package. I'd like to automate that process, somehow. > > Note that if you can spare the diskspace then you can have the "make > install" phase of the packages Makefile copy the new files to the > package tree. There is no need to make tarballs. That's comforting! (No irony intended.) I was really scared I'd have to make a tarball after each change.

1 participants
0 comments

Re: Running packages "in place" 24 years, 6 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > When changing a core Lisp or C file, I recompile it and see how XEmacs > fares. With the packages, I apparently have to remake and reinstall > the package. I'd like to automate that process, somehow. Note that if you can spare the diskspace then you can have the "make install" phase of the packages Makefile copy the new files to the package tree. There is no need to make tarballs. The symbolic linking suggestion has two advantages. 1. It saves diskspace. 2. With the help of VC you actually go the correct file on M-x find-function. But then again, you probably knew that. Jan

1 participants
0 comments

Re: Running packages "in place" 24 years, 6 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > Now, I'd like to check out packages and use them in place, so that > > `cvs update' automatically updates the sources I actually use. Is > > that possible? If so, what do I need to do? The CVS packages > > contain apparently weird directories like `oa/', `os/', `comm/', > > etc. > > The layout is a pain. What you could do (I used this for Gnus) is > change the make install such that it doesn't copy but makes > symlinks. Yes, that might work. The reason I ask is that I'd like to apply (and commit) patches to packages, and I'm not sure how to do that if I can't test the changes I'm making. When changing a core Lisp or C file, I recompile it and see how XEmacs fares. With the packages, I apparently have to remake and reinstall the package. I'd like to automate that process, somehow.

1 participants
0 comments

Re: More ESD ./configure bogosity 24 years, 6 months

Raymond Toy

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: mb> How do people feel about this more comprehensible user mb> interface: mb> --with-nas-sound=yes|no (default autodetect) mb> --with-esd-sound=yes|no (default autodetect) mb> --with-native-sound=yes|no (default autodetect) Stephen> Bletch, but I could live with it. Stephen> I like the current format. But I would parse it as follows. Stephen> --with-sound takes an argument which is a comma-separated list. [snip] Stephen> Under this interpretation, Stephen> --with-sound=native,esd Stephen> gives the user what he expects, no matter what additional types of Stephen> sound we add. Specified as logic, it looks complex, but I think the Stephen> result is intuitive for the user. I like this method, it's pretty intuitive, and it's a lot less typing :-) I also like the auto option to include everything xemacs can find. Ray

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