HDTenEightyP/NetNews huggingface dataset:
From: S.Marshall@sequent.cc.HUll.ac.UK (Simon Marshall)
Subject: Problems building epoch-4.0, anyone help (Sequent)?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 18:01:12 GMT

	Hi all, I'm trying to make epoch-4.0 to replace 3.2 on our system,
    but unfortunately I've run into a problem that I can't solve.  Please
    could anyone out there let me in on a solution?!  If you post a response
    (thanx), please also *email* to me too, as my access to USENET has gone
    flaky for the moment, and I am not on the epoch mailing list...

	The problem occurs when I try to build in ./src.  This is on a
    Sequent Symmetry S81 running DYNIX V3.0.17.10.  To get near compiling, I
    had to do the following:

	In config.h:

#include "config/s-bsd4-2.h"
#include "config/m-sequent.h"

	Create the file ./src/../memory.h which #includes memory.h which is
    part of the att universe on our Sequent.  This is to include memcpy() et
    al.  It does not exist in /usr/include.  Include the library libc.a from
    the att universe when linking.  This is to link in memcpy() et al. which
    are not in /usr/lib.  This gets rid of almost all the error messages
    about memcpy() etc. not being around:

#define C_DEBUG_SWITCH -I.. -traditional
#define C_OPTIMIZE_SWITCH
#define LIBS_SYSTEM /usr/att/lib/libc.a 

	I use gcc-2.1 as the Sequent cc is dumb & compains thus:

cc -c -I.. -Demacs     crt0.c
cc -I.. -Demacs      -c window.c -o window.o
cc: -o would overwrite window.o
make[1]: *** [window.o] Error 8

	for each of the source files.  When linking, however, the linker
    complains about one last symbol not being defined.  It does not seem
    down to my inclusion & linking with the att universe, as not including
    and linking also gives this error, and I can't find it anywhere, anyhow:

		:
		:
gcc -I.. -traditional	    -Demacs	-c malloc.c -o malloc.o
ld  -X  -o temacs crt0.o window.o term.o x11term.o x11fns.o xevent.o screen.o xdefault.o xresource.o property.o selection.o xutil.o mouse.o button.o xdispepoch.o dispepoch.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o fns.o print.o lread.o abbrev.o syntax.o unexec.o mocklisp.o bytecode.o process.o callproc.o  doprnt.o lastfile.o m

alloc.o   -lX11    /usr/att/lib/libc.a    -lc 
emacs.o: Undefined symbol ___main referenced from text segment

	I can't find this symbol anywhere.  If it matters, I've not built
    ASCII emacs (why the name ASCII?!).  Has anyone else come across this?
    Many thanx in advance.

	Simon. 
_______________________________________________________________________________
Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK
  "Football isn't about life and death.  It's more important than that." Bill
Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley
Newsgroups: gnu.epoch.misc
From: ckd@eff.org (Christopher Davis)
Subject: Re: 'gnuserv' package
Organization: Electronic Frontier Foundation Tech Central
Distribution: gnu
Date: Wed, 1 Apr 1992 18:01:31 GMT

 Donald> == Donald I. Hunter <donaldh@cs.hw.ac.uk> 

 ckd> Andy Norman's 'gnuserv' package makes for great epoch menus within
 ckd> twm (for those of us who don't use gwm)...

 Donald> Sound's GREAT. Where can I ftp it from?

Um.  Yeah.  Sorry about that.  I'm getting too used to having archie
always at my beck and call for these things.

I don't actually remember where I got it from; I might have pulled it
off USENET some time ago (the machine I originally used it on has gone
to the scrap heap ;-).

Here are some spots.

archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/packages/gnuserv.shar
ftp.uu.net:/languages/elisp/packages/gnuserv.shar.Z
puffin.doc.ic.ac.uk:/gnu/EmacsBits/elisp-archive/packages/gnuserv.shar.Z
gmdzi.gmd.de:/gnu/gnuserv.tar.Z

puffin's probably your best bet ;-)
--
Christopher Davis <ckd@eff.org> |    ECONOMIC OBSERVATIONS DEPARTMENT
System Manager & Postmaster     |  "There's always something going out of
Electronic Frontier Foundation  |      business in Central Square."
+1 617 864 0665  NIC: [CKD1]    |   -Rita Marie Rouvalis <rita@eff.org>
Newsgroups: gnu.epoch.misc
From: dunwoody@r2d2.gnu (Craig Dunwoody)
Subject: epoch 4.0.1 display corruption (Very Bad Thing)
Organization: Silicon Graphics, Inc.
Distribution: gnu
Date: Thu, 9 Apr 1992 20:31:37 GMT


I just loaded epoch 4.0.1 (which as I understand it is the latest,
official-release version) on my Silicon Graphics 4D/70GT running IRIX 4.0.1.

I've been seeing display corruption problems.  When I visit a file,
move the cursor down a few lines, and insert a character, a character
after the insertion point will disappear.  At this point, merely
moving the cursor back and forth along the line will cause characters in the
line to appear and disappear.  This is Very Bad -- I've never seen anything
like this with epoch before.

M-x recenter restores the display to correctness, so the problem is not with
the underlying text data structure.  I don't think it's a font problem either
(I'm using *sony*120*, which is a normal-sized, fixed-width font); epoch
doesn't seem confused about where the character boundaries are.

The annoying thing is, it's not repeatable.  The corruption only happens
"some of the time".  Perhaps it's some internal buffer-boundary condition?
Doing heavy editing, I'll typically see corruption about ten times a day.

This appears to be a regression from epoch 4.0 beta (b3?), which I
built and ran previously with the exact same hardware, compiler, OS
version, X server, .emacs file, screen layout, etc. (I always use
exactly two 80x62 epoch windows, side by side).  I never saw any
display corruption with 4.0 beta or earlier.

Either this is an SGI compiler, OS, or X bug that is being triggered
by something that changed from epoch 4.0b3 to epoch 4.0.1, or it is a
regression in epoch itself.

If anyone else has seen this problem on SGI or other platforms, I'd appreciate
hearing from you.

Craig Dunwoody
dunwoody@sgi.com
(415) 962-3635
--
Craig Dunwoody
dunwoody@sgi.com
(415) 962-3635
Newsgroups: gnu.epoch.misc
From: peterf@olivine.csis.dit.csiro.au (Peter A Fletcher)
Subject: Painful epoch-4.0p0 bugs
Organization: /users/peterf/.organization
Date: Tue, 7 Apr 1992 23:47:17 GMT

Hello!

    Epoch 4.0 has several painful bugs in it which make using it
almost painful enough to go back to epoch-3.2.  I have built epoch-4
for both the Suns and the Decstations at my site, but I only use the
Decstation version.

    The first two bugs are easy to duplicate.  When running as usual
in minibuffer-per-window mode (with -nm flag) with at least two epoch
screens, do the following:

   - begin a command such as find-file-other-screen, leaving the prompt in the minibuffer.

   - Move the mouse to another screen, and the minibuffer prompt will follow it into this screen.  

   - Move the mouse again back to the original screen, and click to put the cursor into it
     (the prompt doesn't follow automatically, which is a small bug in itself)

   - Use C-x o to return to the minibuffer

   - Complete the find-file-other-screen command

    The find-file-other-screen works fine, but the focusing is now
stuffed; if you move the mouse to another screen, the cursor simply
moves into the minibuffer of the previous screen.  It is possible to
click in screens to move the cursor to them, but the only way to
return to a reasonable state of affairs is by killing epoch and
starting again.  This combination of circumstances may sound extremely
rare, but it happens to me about once a day, even when I'm trying to
remember not to cause it.

    A still nastier bug lies in store if you have lots of windows open
and decide to soldier on; eventually in unpredictable circumstances
(quitting a file and closing a screen is one example), epoch will
start to ring the bell continuously, making it near impossible to kill
on the Decstation because X comes to almost a complete halt.

    A completely unrelated bug also makes life hard.  I'm the only
person using my workstation, so I leave it logged in all the time with
epoch running.  I usually have four epochs running at once for various
reasons, and when I come in in the morning there is usually one that
has locked up; refreshing works, the cursor fills and empties when the
mouse enters and leaves the window, but everything else is frozen; the
time is stuck on 2:15 am, none of the keys work, the mouse does not
click.

    Sorry I can't be more specific about where epoch dies, because
gdb won't let me attach on a Decstation.

-peter.
--
Peter Fletcher,            Internet : peterf@csis.dit.csiro.au
PhD Student                Physical : CSIRO Division of Information Technology,
Phone    : +61-6-2750914              ANU, Acton, Canberra ACT AUSTRALIA
-------------------------------------------------------------------------------
Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: An annoying feature of file completion, perhaps?
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 06:01:49 GMT

>   | on a completely unrelated note, when I use bash on top of csh using
>   | 
>   | bash -login
>   | 
>   | I get couple of copies of
>   | 
>   | setenv: command not found
>   | 
>   | As far as I can tell, it complains but has no problems.
>   | Could someone explain why this happens? Thanks.

Your diagnosis was on the mark, but there's a simpler cure:

setenv()
{
	export $1="$2"
}

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: trost@reed.edu (Bill Trost)
Subject: Re: An annoying feature of file completion, perhaps?
Organization: Reed College
Distribution: gnu
Date: Tue, 7 Apr 1992 18:44:31 GMT

In article <1992Apr5.020147.1089@physics.ucla.edu> aoki@physics.ucla.edu (ken aoki) writes:

   When I type

   $ cat foo | sed -n '/^[TAB]

   it will not tab. I believe it is trying hard to file complete.

In article <ABREU.92Apr5184709@ionie.inria.fr> abreu@ionie.inria.fr (Salvador Abreu) responds:

   don't use TAB when you don't want completion, use M-TAB (ESC-TAB if
   you lack a Meta key). it'll insert a plain TAB character.

Or, better yet, modify your .inputrc so that file-completion is bound
to some other key (like M-i), and make the tab key insert what it's
SUPPOSED to insert.

grumble mucking with my keys....grumble grumble....
--
Bill Trost <trost@reed.edu>   Space is nature's way of keeping everything from
Reed College Systems Manager  happening all together.


Newsgroups: gnu.bash.bug
From: eskilb@hrp.NO (Eskil Brun)
Subject: An annoying feature of file completion, perhaps?
Reply-To: Eskil.Brun@hrp.no
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 06:36:00 GMT

  | From: aoki@physics.ucla.edu (ken aoki)
  | Date: Sun, 5 Apr 92 02:01:47 GMT
  | 
  | I run bash-1.12.1 on 
  | 
  |   NeXT Station NextStep2.0 
  |   sparc IPX SunOS 4.1.1
  |   DECstation500/200 Ultrix4.0
  | 
  | When I type
  | 
  | $ cat foo | sed -n '/^[TAB]
  | 
  | it will not tab. I believe it is trying hard to file complete.
  | (btw, ^ is unnecessary for this to happen, of course.) 
  | this happens when I am trying to
  | look for lines beginning with tabs in pipes, for instance. 
  | 
  | I like the file completion feature, but in some cases I want it not
  | to turn on.....
  | I am sorry if this is a well discussed problem.  
  | 
  | ---------------------------------------------------------

I usually do as in emacs(1), I type Ctrl-Q TAB. Like you, I want bash
to complete filenames most of the time. Every time I need a TAB
character, I quote it with Ctrl-Q.

  | on a completely unrelated note, when I use bash on top of csh using
  | 
  | bash -login
  | 
  | I get couple of copies of
  | 
  | setenv: command not found
  | 
  | As far as I can tell, it complains but has no problems.
  | Could someone explain why this happens? Thanks.

Probably this is caused by tset(1) invoked from your .profile or the
system /etc/profile. (Most likely the latter since it occurs when you
use bash -login). tset(1) looks at the environment string SHELL to
find out what kinda shell your'e using. Then it prints commands for
csh(1) on the standard output. tset(1) is probably backquoted in
/etc/profile. 

There are ways to fix this. Set the SHELL environment variable in
/etc/profile. This is messy though. You should consult login(1),
su(1), and your bourne-shell-lookalike shells manual pages before
attempting this. We use bash(1), ksh(1) and sh(1) here, and setting
the correct value for SHELL is a mess. You could work around it and
save the old SHELL variable, set SHELL to /bin/sh, run tset(1) and
then just restore the old SHELL variable.

Or you could just ignore the problem. :-)

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Eskil Brun                     Internet Email: eskil.brun@hrp.no
 Systems Administrator          Phone: +47 9 183100
 OECD Halden Reactor Project    Fax: +47 9 183103
 Norway                         Surface Mail: P.O. Box 173, N-1751 Halden
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


Newsgroups: gnu.bash.bug
From: eskilb@hrp.NO (Eskil Brun)
Subject: An annoying feature of file completion, perhaps?
Reply-To: Eskil.Brun@hrp.no
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 15:36:00 GMT

  | Date: Tue, 7 Apr 1992 10:01:49 -0400
  | From: Chet Ramey <chet@odin.INS.CWRU.Edu>
  | 
  | >   | on a completely unrelated note, when I use bash on top of csh using
  | >   | 
  | >   | bash -login
  | >   | 
  | >   | I get couple of copies of
  | >   | 
  | >   | setenv: command not found
  | >   | 
  | >   | As far as I can tell, it complains but has no problems.
  | >   | Could someone explain why this happens? Thanks.
  | 
  | Your diagnosis was on the mark, but there's a simpler cure:
  | 
  | setenv()
  | {
  | 	   export $1="$2"
  | }
  | 

True. Thanx. 
Funny that never occurred to me. Good to know I still have a lot of
tricks to learn and enjoy.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Eskil Brun                     Internet Email: eskil.brun@hrp.no
 Systems Administrator          Phone: +47 9 183100
 OECD Halden Reactor Project    Fax: +47 9 183103
 Norway                         Surface Mail: P.O. Box 173, N-1751 Halden
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



Newsgroups: gnu.bash.bug
From: eyvind.ness@hrp.NO (Eyvind Ness)
Subject: Re: An annoying feature of file completion, perhaps?
Reply-To: Eyvind.Ness@hrp.no
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 07:29:00 GMT

  | Date: Wed, 8 April 92,  7:22 GMT
  | From: Eyvind Ness
  |
  | Example bash->csh (Correct!):
  | 
  |    dole(bash)$ env SHELL=/bin/bash csh
!!!                    SHELL=/bin/csh
  |    dole% tset -s
  |    set noglob;
  |    setenv TERM xterm ;
  |    unset noglob;
  |    Erase is Delete
  |    Kill is Ctrl-U

A little glitch in my example above. Sorry.

Eyvind.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Eyvind Ness                    Internet Email: Eyvind.Ness@HRP.No
 Research Scientist             Phone: +47 9 183100
 Control Room Systems Division  Fax: +47 9 187109
 OECD Halden Reactor Project    Surface Mail: P.O. Box 173, N-1751 Halden
 Norway
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 -Hvem er dummere enn en dum ire? En smart svenske. Knut Rockne

Newsgroups: gnu.bash.bug
From: abreu@ionie.inria.fr (Salvador Abreu)
Subject: Re: An annoying feature of file completion, perhaps?
Organization: INRIA - Rocquencourt, France
Distribution: gnu
Date: Wed, 8 Apr 1992 10:22:44 GMT

In article <ABREU.92Apr5184709@ionie.inria.fr> I write:

	[...]
> > When I type
> >
> > $ cat foo | sed -n '/^[TAB]
> >
> > it will not tab. I believe it is trying hard to file complete.
>
> don't use TAB when you don't want completion, use M-TAB (ESC-TAB if
> you lack a Meta key). it'll insert a plain TAB character.

Sorry, this *used* to be true in some older version of bash. It
doesn't do that any more in 1.12, use C-V TAB instead.

./salvador

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Error "references are not lvalues"?
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 06:32:49 GMT

This code:

class SubString : public NIHCL {
	char* sp;		// substring pointer 
        unsigned sl;		// substring length 
	String* st;		// String this is a SubString of
...
}

...
inline SubString::SubString(const String& s, unsigned pos, unsigned lgt)
{ 
	sp = &((String&)s).p[pos];
	sl = lgt;
	st = &(String&)s;
	checkSubStr();
}
...

generates the error

String.h: In method `SubString::SubString (const class String&, unsigned
int, unsigned int)':
In file included from Class.c:37:
String.h:227: references are not lvalues

I assume that this error comes from trying to take the address of s cast to
a String&.  This seems perfectly proper to me (and to Borland C++ 3.0);
since s is a reference type already, &(String&)s should return a String*
pointing to s.

What logic are you using to say that references are not lvalues?  The fact
that references ARE lvalues is the reason for returning type& from a
function rather than just type&.  I really don't understand the reasoning
behind this error.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  I think there is a bug in finish_file()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 19:46:30 GMT

This bug should be fixed in the next version of gcc.

> Date: Fri, 10 Apr 1992 22:04:15 -0500
> From: daney@mermaid.micro.umn.edu (Dave Daney)
> Message-Id: <199204110304.AA21383@mermaid.micro.umn.edu>
> To: bug-g++@prep.ai.mit.edu
> Subject: I think there is a bug in finish_file()

> Am I missing something?  Here is a file that I tried to compile with gcc 2.1
> --------------------<cut here>-------------------------------
> //
> //
> //  Why does this program cause cc1plus 2.1 to segmentation fault??
> //
> //

> class testclass {
>   int len;

> public:
>   int length() { return len; };
>   
>   testclass(int l) {len = l; };
> };


> testclass test = testclass(5);

> int main(int argc, char *argv[])
> {
>   int j = test.length();

>   return 0;
> }

> --------------------------------------<cut here>-------------------
> I compile like this:


> Reading specs from /usr/gnu/lib/gcc-lib/sparc/2.1/specs
> gcc version 2.1
>  /usr/gnu/lib/gcc-lib/sparc/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix bug.cc /usr/tmp/cca26668.i
> GNU CPP version 2.1 (sparc)
>  /usr/gnu/lib/gcc-lib/sparc/2.1/cc1plus /usr/tmp/cca26668.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca26668.s
> GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
> gcc: Internal compiler error: program cc1plus got fatal signal 11

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.1: errors in cp-decl.c, cp-parse.y
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Tue, 7 Apr 1992 03:03:45 GMT

There are some run-time errors in GCC 2.1, cp-decl.c, (detected with Saber-C).

In cp-decl.c, line 578, there is the field declaration
(in struct binding_level):

	#ifdef PARANOID
	    unsigned char depth;
	#endif

And in line 711 (function pop_binding_level), the sign of this unsigned
char is reversed:

	#ifdef PARANOID
	    level->depth *= -1;
	#endif

What should that be, a substraction (level->depth -= 1;)?

And shouldn't there be `#if PARANOID' instead of `#ifdef PARANOID'?
In cp-tree.h, line 26, PARANOID is set to 0:

	#ifndef PARANOID
	#define PARANOID 0
	#endif

There is a more serious error with the use of finish_decl (cp-decl.c,
line 5068).  The function is supposed to be passed four parameters.
The fourth parameter, `need_pop', tells whether obstacks should be
popped.  In ALL the calls to finish_decl from cp-parse.y, only three
parameters are passed.

--Gerald

Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: data member initialization wrongly accepted
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 19:26:10 GMT

The following code:
====================
class foo
{
public:
  int a = 0;
};

foo baz;
====================
not compile under Sun C++, with the error message:
====================
CC  test.cc:
"test.cc", line 2: error:  initializer for member a
1 error
====================

Looking through my C++ reference books, I cannot find anything to
indicate what the compiler should do with an attempt to initialize a
class data member within the class definition.  Nor can I find a
mention of this as a gnu extension in the documentation that
accompanies gcc 2.1.  Yet both g++ 1.40.3 and g++ 2.1 accept such
initializations without complaint.

Since my students attempt such initializations all the time and,
worse, sometimes the initializations achieve what the student
intended, I'd appreciate it if an upcoming version of GNU C++ flagged
this as an error.

BTW: The failure to warn occurs under GNU GCC 2.1, w/ Tiemann inf.
loop patches, and patches from Mike Stump for the Sabre detected bugs,
running on a SUN sparc2 running Sunos 4.1.  The same behavior occurred
under g++ 1.40.3.

Doug Moore
(dougm@cs.rice.edu)

Newsgroups: gnu.g++.bug
From: bothner@cygnus.com
Subject: Re: #pragma interface -- whose bug is it anyway?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 05:21:06 GMT

I'm afriad it's your bug.
#pragma interface must be used in conjunction with
#pragma implementation (see the g++ man page,
shipped with gcc-2.1).  And SplayBag.ccP *does*
have a #pragma implementation - you need to
link in a genclass'd version of it with your applicatioon.
	--Per

Newsgroups: gnu.g++.bug