December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: CVS hosed? tests/automated/base64-tests.el is gone! 24 years, 4 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Otherwise why don't we just remove the existing file and add a fresh > > copy? > > I tried that. It didn't work. Did you make sure your removed it any reference to the original file from your local repository as well? Did you do a fresh checkout after the file was removed from CVS? Jan

1 participants
0 comments

Re: CVS hosed? tests/automated/base64-tests.el is gone! 24 years, 4 months

Hrvoje Niksic

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > > > After Martin's fix for the Fmapconcat crashes I wanted to reenable the > > > test in base64-tests.el which Hrvoje had disabled some time ago, > > > > I haven't it. > > I was referring to the following: > > (when nil > ;; This code crashes XEmacs! This requires further investigation. > ;; I'm running Linux, and for me, XEmacs crashes in > ;; Fmapconcat()->mapcar1(), after a GC that thrashes the stack. > ;; Raymond Toy reports a similar crash under Solaris. > (loop for (raw encoded) in bt-test-strings do > ... The code does not look that way in my version. As with most memory corruption problems, the crashes came and went as *they* saw fit. My version goes like this: (when t ;; This code crashes some versions of XEmacs 21.2! This requires ;; further investigation. I (hniksic) am running Linux, and for me, ;; XEmacs used to crash in Fmapconcat()->mapcar1(), after a GC that ;; thrashes the stack. Raymond Toy reported a similar crash under ;; Solaris. I can no longer repeat the bug, so I cannot fix it now. (loop for (raw encoded) in bt-test-strings do ... > > The base64-tests file has been broken in the repository for a long > > time, and I'm still waiting for someone to fix it. The problem was > > that that file used to have a raw-zero character embedded in it, > > which CVS apparently doesn't grok. Even worse, I can't find a way > > to fix the situation, even after having removed the offending > > character. > > Wouldn't directly hacking the RCS file help? It would, but I don't think I'm supposed to do that. Given that I know next to nothing about RCS, I definitely don't think I'm the right person for the job. > Otherwise why don't we just remove the existing file and add a fresh > copy? I tried that. It didn't work. > > If you want, I'll mail you a working copy of the file. > > thanks. I have one, back from the time when you first added it. But the file got updated several times. Here is my latest version:

1 participants
0 comments

Re: CVS hosed? tests/automated/base64-tests.el is gone! 24 years, 4 months

Gunnar Evermann

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > After Martin's fix for the Fmapconcat crashes I wanted to reenable the > > test in base64-tests.el which Hrvoje had disabled some time ago, > > I haven't it. I was referring to the following: (when nil ;; This code crashes XEmacs! This requires further investigation. ;; I'm running Linux, and for me, XEmacs crashes in ;; Fmapconcat()->mapcar1(), after a GC that thrashes the stack. ;; Raymond Toy reports a similar crash under Solaris. (loop for (raw encoded) in bt-test-strings do ... > The base64-tests file has been broken in the repository for a long > time, and I'm still waiting for someone to fix it. The problem was > that that file used to have a raw-zero character embedded in it, > which CVS apparently doesn't grok. Even worse, I can't find a way to > fix the situation, even after having removed the offending > character. Wouldn't directly hacking the RCS file help? Otherwise why don't we just remove the existing file and add a fresh copy? > If you want, I'll mail you a working copy of the file. thanks. I have one, back from the time when you first added it. Gunnar

1 participants
0 comments

Re: check process state before accessing coding_stream (fix PR#1061) 24 years, 4 months

Gunnar Evermann

[ I've reduced the CC: list slightly, so that Jan doesn't get 3 copies of this :-) ] Ben Wing <ben(a)666.com> writes: > >There is one use of PROCESS_LIVE_P left (in process_send_signal) > > When a process is printed, so is its name, so why wouldn't it be printed here? Oh, good point. I'll use CHECK_LIVE_PROCESS there as well and apply the patch to cvs. > If you want to be more adventurous, I'd suggest some more general > changes to make these type errors clearer. I've always hated these. > For example: > > Wrong type: wanted an event, got a vector: [down-button 2] > > Wrong type: wanted a live process, got a dead one: #<process ...> cool. I've always found the errors pretty unhelpful. I'll implement this. Thanks for the suggestion! > 3. BLUE SKY ALERT: What would be even better would be if the error > would also print something about what function it's in, but > that's harder. I'll have a look at this. Gunnar

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 4 months

William M. Perry

Ben Wing <ben(a)666.com> writes: > But how *useful* are these things? In particular, are they more important > than badly-needed fixes to the installation/documentation/UI? Definitely not as important as the installation/documentation as it stands right now, but I see the modules as the natural progression for ease of installation / package convenience. I'm not 100% sure where UI stands on my hitlist for 21.2. :) I'd personally love to have the time to hack a font model that doesn't suck for it, but I won't have the time. :( -bill p.

1 participants
0 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 4 months

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > From a practical standpoint, I just don't see why modules are important > at all. Reducing library dependencies of the binaries for instance. Adding library bindings later (Sysadmin/distributor "forgot" ldap support?) Not problem, just compile the module. Jan

2 participants
1 comments

Re: CVS hosed? tests/automated/base64-tests.el is gone! 24 years, 4 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > I think the files are all in the `Attic' since none of these files are > present in 21.1.8, i.e. the CVS HEAD. > > It seems that base64-tests.el,v-SAVE has been simply renamed in the > repository, which seems to be a no-no. Wasn't this the file that made CVS go over the top because it (accidently) contains binary stuff but isn't checked in as such. I'm fairly sure Steve moved it away for a reason. Jan

1 participants
0 comments

Re: New packages released 24 years, 4 months

Jan Vroonhof

Soren Dayton <dayton(a)overx.com> writes: > The following message is a courtesy copy of an article > that has been posted to comp.emacs.xemacs as well. You really should report this to Michael Kifer. > This reminds me of something that happened to me when I used > mailcrypt... It was related to font lock in some way. > Signaling: (wrong-type-argument extent-live-p #<destroyed extent>) > viper-overlay-put(#<destroyed extent> face nil) I have idea why the extent gets destroyed at the moment. Does this help as a stop gap measure diff -u /scratch/vroonhof/cvs/xemacs-20/gcc-2.95/xemacs-packages/lisp/viper/viper-util.el~ /scratch/vroonhof/cvs/xemacs-20/gcc-2.95/xemacs-packages/lisp/viper/viper-util.el --- /scratch/vroonhof/cvs/xemacs-20/gcc-2.95/xemacs-packages/lisp/viper/viper-util.el~ Sun Dec 19 11:21:31 1999 +++ /scratch/vroonhof/cvs/xemacs-20/gcc-2.95/xemacs-packages/lisp/viper/viper-util.el Sun Dec 19 11:21:31 1999 ＠＠ -70,7 +70,7 ＠＠ (fset 'viper-overlay-start (symbol-function 'extent-start-position)) (fset 'viper-overlay-end (symbol-function 'extent-end-position)) (fset 'viper-overlay-put (symbol-function 'set-extent-property)) - (fset 'viper-overlay-p (symbol-function 'extentp)) + (fset 'viper-overlay-p (symbol-function 'extent-live-p)) (fset 'viper-overlay-get (symbol-function 'extent-property)) (fset 'viper-move-overlay (symbol-function 'set-extent-endpoints)) (if (viper-window-display-p) Jan

1 participants
0 comments

CVS hosed? tests/automated/base64-tests.el is gone! 24 years, 4 months

Gunnar Evermann

After Martin´s fix for the Fmapconcat crashes I wanted to reenable the test in base64-tests.el which Hrvoje had disabled some time ago, but something is broken with the repository.I think I have had this problem before... a cvs stat in tests/automated gives: cvs server: conflict: base64-tests.el is modified but no longer in the repository =================================================================== File: base64-tests.el Status: Unresolved Conflict Working revision: 1.1.2.3 Repository revision: No revision control file Sticky Tag: release-21-2 - MISSING from RCS file! Sticky Date: (none) Sticky Options: (none) and looking at the cvsweb thingie at cvs.xemacs.org the file indeed seems to be missing! All the other tests are in the Attic (presumably because they are not in the HEAD (21.1) release). Can anybody with a real account on the machine check? Gunnar

2 participants
1 comments

Re: Modules (was: Re: How about a feature freeze) 24 years, 4 months

Hrvoje Niksic

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > I'm interested in moving eldap.c to a module. What's the status of > the module support ? Is it ready for such a thing ? I think it is, but I'm not sure. It's especially questionable how modules stand wrt the portable dumper. > And most of all where can I find the documentation (I haven't > searched yet), which docstrings/info files should I read ? See `Emodules' node in the top-level Info directory.

2 participants
1 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