October 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: outstanding issues, "dired" in the Subject header 24 years, 4 months

Adrian Aichner

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes: APA> has this in Makefile: APA> VERSION = 1.18 APA> AUTHOR_VERSION = 1.19 APA> MAINTAINER = Mike Sperber <sperber(a)informatik.uni-tuebingen.de> Michael> I don't do VERSION :-) Michael> Anyway, just check the ChangeLog to see if you've got the Michael> latest. Please send me whatever you do do. >From which CVS repository should I update to which release tag? Best regards, Adrian Michael> -- Michael> Cheers =8-} Chipsy Michael> Friede, Völkerverständigung und überhaupt blabla -- Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org

1 participants
0 comments

Re: outstanding issues, "dired" in the Subject header 24 years, 4 months

Michael Sperber

>>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes: APA> has this in Makefile: APA> VERSION = 1.18 APA> AUTHOR_VERSION = 1.19 APA> MAINTAINER = Mike Sperber <sperber(a)informatik.uni-tuebingen.de> I don't do VERSION :-) Anyway, just check the ChangeLog to see if you've got the latest. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: building xemacs-packages on unix 24 years, 4 months

Gunnar Evermann

Adrian Aichner <adrian(a)xemacs.org> writes: > thanks for your tests and pointing out the problem in the firrst place! I felt a bit sily for complaining, when I found out that it only takes a minute on a bigger machine :-( > My only computer is a PentiumII-266MHz laptop. Ok, but still just running some rm's in a hudred directories shouldn't take over half an hour (as you reported). Do you think that is a Windows specific problem? > Also, Local.rules is definitely the right place to configure the type > of XEmacs used. I don't think it's worth going thru the trouble to > determine the XEmacs configuration dynamically. > > So, I would like to commit following patch today: looks good to me. thanks for the fix. Gunnar

1 participants
0 comments

Re: cvs update broken for cvs.sourceforge.net:/cvsroot/xemacs 24 years, 4 months

Adrian Aichner

>>>>> "Steve" == Steve Youngs <youngs(a)xemacs.org> writes: Steve> * Adrian Aichner <adrian(a)xemacs.org> writes: >> I just submitted this support request for xemacs on sourceforge: >> cvs update >> even cvs update -n q >> has stopped working within the last 24h. >> Here's what I get now: >> bash-2.04$ cvs update >> ? 2000-10-14P2000-10-15.txt >> ? compilation >> ? logs >> ? URL2relPath.pl >> ? URLabs2rel.pl >> ? Architecting-XEmacs/index.content.shape >> ? Architecting-XEmacs/index.html-pre-normalize >> ? Architecting-XEmacs/init-files.html.new >> ? Documentation/index.html.manual >> ? Install/it >> ? genpage/gp.err >> ? genpage/layout2 >> ? genpage/www >> cvs server: Updating . >> cvs server: failed to create lock directory in repository `/cvsroot/xemacs/xemac >> sweb': Permission denied >> cvs server: failed to obtain dir lock in repository `/cvsroot/xemacs/xemacsweb' >> cvs [server aborted]: read lock failed - giving up >> bash-2.04$ >> bash-2.04$ date -u >> Wed Oct 18 22:55:15 2000 >> bash-2.04$ Steve> Just tried it, I get the same thing... Hi Steve, All, I was able to commit again to the SF repository yesterday at > From: "Adrian P. Aichner" <adriana(a)users.sourceforge.net> > Subject: [Xemacs-checkins] by adriana in 'xemacsweb template-de.html,1.2,1.3 template.html,1.19,1.20 ChangeLog,1.29,1.30' > To: xemacs-checkins(a)lists.sourceforge.net > Date: Thu, 19 Oct 2000 13:08:46 -0700 > Message-Id: <200010192008.NAA31790(a)slayer.i.sourceforge.net> Thought I should let yall know. Adrian Steve> ,---- Steve> | cvs server: Updating . Steve> | cvs server: failed to create lock directory in repository \ Steve> | `/cvsroot/xemacs/ Steve> | xemacsweb': Permission denied Steve> | cvs server: failed to obtain dir lock in repository \ Steve> | `/cvsroot/xemacs/xemacsweb' Steve> | cvs [server aborted]: read lock failed - giving up Steve> `---- Steve> But it works fine for my sourceforge copy of my eicq package... Steve> ,----[ cvs update ] Steve> | cvs server: Updating . Steve> | cvs server: Updating etc Steve> | cvs server: Updating etc/eicq Steve> `---- Steve> -- Steve> |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| Steve> | XEmacs - It's not just an editor... | Steve> | It's a way of life. | Steve> |----------------------------------<mailto:youngs＠xemacs.org>---| -- Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org

1 participants
0 comments

Re: building xemacs-packages on unix 24 years, 4 months

Adrian Aichner

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> Adrian Aichner <adrian(a)xemacs.org> writes: >> Gunnar, can you please give me execution-time numbers for a top-level >> make clean >> with and without following patch? Gunnar> Hm, I've just tried this on a real machine (Dual PII/550 + Gunnar> 1GB RAM) with an optimised 21.1.9 build and it was pretty Gunnar> fast either way... Gunnar> 63.23user 11.93system 1:20.22elapsed 93%CPU Gunnar> (0avgtext+0avgdata 0maxresident)k Gunnar> 2.06user 1.42system 0:04.15elapsed 83%CPU Gunnar> (0avgtext+0avgdata 0maxresident)k Gunnar> I guess it was only really slow on my laptop (PIII/450 Gunnar> 64MB) because it ran out of memory for caching. I am gonna Gunnar> buy some more memory right now... Gunnar, thanks for your tests and pointing out the problem in the firrst place! My only computer is a PentiumII-266MHz laptop. Also, Local.rules is definitely the right place to configure the type of XEmacs used. I don't think it's worth going thru the trouble to determine the XEmacs configuration dynamically. So, I would like to commit following patch today: xemacs-packages\ChangeLog: 2000-10-20 Adrian Aichner <adrian(a)xemacs.org> * Local.rules.template (XEMACS_NATIVE_NT): Configuration variable moved here from XEmacs.rules. * XEmacs.rules: Don't run XEmacs to determine system-type. xemacs-packages patch: cd d:\tmp\xemacs-packages\ cvs diff -l Compilation started at Fri Oct 20 14:42:40 2000 +0200 (W. Europe Daylight Time) ? bindist-2.err ? cvs-update-lock.err ? distclean.err ? XEmacs-Adrian.rules ? xemacs-packages-make-clean.err cvs server: Diffing . Index: Local.rules.template =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-packages/Local.rules.template,v retrieving revision 1.2 diff -u -r1.2 Local.rules.template --- Local.rules.template 2000/06/04 10:22:02 1.2 +++ Local.rules.template 2000/10/20 12:47:49 ＠＠ -35,7 +35,27 ＠＠ # Path to XEmacs to use for byte compilation. # +# APA: Double-quote path to protect possibly embedded SPACEs on WindowsNT. XEMACS = xemacs + +# APA: XEmacs native NT currently (2000-06-23) has shortcomings we +# need to temporarily work around. +# Following test, which would be performed by every makefile +# including XEmacs.rules, slows down the make process terribly +# according to +# +# From: Gunnar Evermann <ge204(a)eng.cam.ac.uk> +# Subject: building xemacs-pacakges on unix +# To: XEmacs Developers <xemacs-beta(a)xemacs.org> +# Date: 14 Oct 2000 12:28:44 +0100 +# +# XEMACS_NATIVE_NT = \ +# $(shell $(XEMACS) $(VANILLA) -batch \ +# -eval "(princ (eq system-type 'windows-nt))") +# +# Therefore this has become a make variable instead: +# +XEMACS_NATIVE_NT = # See: Makefile and XEmacs.rules to see how $(XEMACS_STAGING), # $(MULE_STAGING), and $(STAGING) are used. Index: XEmacs.rules =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-packages/XEmacs.rules,v retrieving revision 1.21 diff -u -r1.21 XEmacs.rules --- XEmacs.rules 2000/08/24 17:13:19 1.21 +++ XEmacs.rules 2000/10/20 12:47:49 ＠＠ -34,12 +34,6 ＠＠ # Ensure vanilla locale when building override LANG := C -# APA: XEmacs native NT currently (2000-06-23) has shortcomings we -# need to temporarily work around. -XEMACS_NATIVE_NT = \ -$(shell $(XEMACS) $(VANILLA) -batch \ --eval "(princ (eq system-type 'windows-nt))") - # Only in rare cases will you need to override this ifeq ($(AUTOLOAD_PATH),) AUTOLOAD_PATH = . Compilation exited abnormally with code 1 at Fri Oct 20 14:42:47 >> It still takes ages for me on NT, and it even rhymes! >> make XEMACS_NATIVE_NT=t clean >> Compilation started at Wed Oct 18 00:07:25 2000 +0200 (W. Europe Daylight Time) >> >> Compilation finished at Wed Oct 18 00:45:16 Gunnar> ouch, this sounds about like my laptop... Gunnar> Gunnar -- Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org

1 participants
0 comments

Re: outstanding issues, "dired" in the Subject header 24 years, 4 months

Adrian Aichner

>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Hello Michael, could you please consider http://www.xemacs.org/list-archives/xemacs-patches/199908/msg00033.html for inclusion into your upcoming dired release? See also http://www.xemacs.org/list-archives/xemacs-beta/200004/msg00013.html I am willing to test the new version before release. Best regards, Adrian >>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: >>> "John" == John A Turner <turner(a)blueskystudios.com>: John> http://www.xemacs.org/list-archives/xemacs-beta/200002/msg00139.html >>> Michael Sperber: >>> >>> This one whizzed by me because it was not sent to efs-bug (and doesn't >>> have "dired" in the Subject header). If you could resubmit via M-x >>> dired-report-bug, I'd be grateful. Charles> I sent a patch for this to xemacs-patches, Charles> turner＠blueskystudios Michael> I merely wanted to point out the correct destination for the *bug Michael> report* for John's benefit. Michael> The patch has actually long been applied to my workspace. Thanks again! Michael> -- Michael> Cheers =8-} Mike Michael> Friede, Völkerverständigung und überhaupt blabla -- Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org

1 participants
0 comments

Re: outstanding issues, "dired" in the Subject header 24 years, 4 months

Michael Sperber

>>>>> "Charles" == Charles G Waldman <cgw(a)fnal.gov> writes: >> "John" == John A Turner <turner(a)blueskystudios.com>: John> http://www.xemacs.org/list-archives/xemacs-beta/200002/msg00139.html >> Michael Sperber: >> >> This one whizzed by me because it was not sent to efs-bug (and doesn't >> have "dired" in the Subject header). If you could resubmit via M-x >> dired-report-bug, I'd be grateful. Charles> I sent a patch for this to xemacs-patches, Charles> turner＠blueskystudios I merely wanted to point out the correct destination for the *bug report* for John's benefit. The patch has actually long been applied to my workspace. Thanks again! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: outstanding issues 24 years, 4 months

Raymond Toy

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> Raymond Toy <toy(a)rtp.ericsson.se> writes: >> Yes. The reason I think it's a gcc problem is that start1 is set to >> BUF_BEGV(curent_buffer) = 1 in Fwrite_region_internal. However, at >> some later point it magically gets changed to 8388xxxx in the call to >> make_lisp_buffer_stream. A peek at the code shows that start1 is only >> set in a few places and none of them can do this. Gunnar> In my experience you can't trust the values of variables reported by Gunnar> gdb (incl. backtraces) unless you compiled with -g and without Gunnar> optimisation. Agreed. However when I say it's 8388xxxx, that's the value of the parameter in the routine make_lisp_buffer_stream which was initialized from start1, and that should be valid, right? Gunnar> It's supposed to be. Ray, could you try compiling with gcc but with Gunnar> less aggressive optimisation (say -O1 instead of -O3)? I tried recompiling fileio (I think) without -O. I still got crashes, but I'm not 100% sure if I was running the new version or the old. I am pretty sure that I'm running the Sun CC version now, and that seems stable. I do know for a fact that 2.95.x, x < 2, was not capable of building a temacs that could create an xemacs, so I stayed with 2.7.2.2 for a long time. Ray

1 participants
0 comments

Re: outstanding issues 24 years, 4 months

Gunnar Evermann

Raymond Toy <toy(a)rtp.ericsson.se> writes: > Yes. The reason I think it's a gcc problem is that start1 is set to > BUF_BEGV(curent_buffer) = 1 in Fwrite_region_internal. However, at > some later point it magically gets changed to 8388xxxx in the call to > make_lisp_buffer_stream. A peek at the code shows that start1 is only > set in a few places and none of them can do this. In my experience you can't trust the values of variables reported by gdb (incl. backtraces) unless you compiled with -g and without optimisation. Gunnar

1 participants
0 comments

Re: outstanding issues 24 years, 4 months

Gunnar Evermann

Hrvoje Niksic <hniksic(a)arsdigita.com> writes: > Raymond Toy <toy(a)rtp.ericsson.se> writes: > > > o xemacs crashes for me quite often in either gc or > > make_lisp_buffer_stream. (Already reported). I have a sneaking > > suspicion that it's a gcc 2.95.2 problem. After recompiling with > > Sun CC 5.0, I haven't run into it today in the last few hours, > > whereas it was happening as often as every 30 minutes with gcc > > 2.95.2. I'll have to try with gcc 2.7.2.2 too. Perhaps a note in > > the PROBLEMS file? > > Maybe, maybe not. Remember that it could also be a memory corruption > bug, and those can go away when you change *anything* -- and come back > to haunt you a year later. > > Is gcc 2.95.2 a stable release of Gcc? It's supposed to be. Ray, could you try compiling with gcc but with less aggressive optimisation (say -O1 instead of -O3)? Gunnar

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