HDTenEightyP/NetNews huggingface dataset:
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: switch to a buffer not shown in all screens ?
Organization: Nat'l Center for Supercomputing Applications
Date: Wed, 7 Oct 1992 20:04:51 GMT

   Did anyone write a function to switch to a buffer which is closest to the 
   top of buffer stack and not displayed in all existing screens ?

No, but I wrote one once to switch to a buffer in a screen that lies
under all other screens except for the screen containing a window that
held a buffer that was below the original buffer in the buffer stack,
unless the window was in a screen that was currently iconified and the
buffer was unmodified but above any other buffer that was contained in
more than one window in the buffer stack, in which case I looped
through the screen list looking for windows holding buffers that were
in windows that were iconified but raised over all other screens
holding windows with buffers that were shown in multiple windows with
buffers that were only in one screen.

Marc

--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu
Newsgroups: gnu.epoch.misc
From: jct%se33@se01.wg2.waii.COM (Jim Thompson)
Subject: Re: Standard tricks with epoch?
Reply-To: thompson@wg2.waii.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:50:05 GMT

You write:

> If Hilit or Litebrite is in an anonymous ftp site, can you please post the address.
> Alternatively, can you package and post it to the net. I'm sure a lot of people
> will be interested. 
> 
> I've a request similar to the original poster. I'm coming to epoch after being
> a power vi user. My attempts at learning the Ctrl-Meta etc. key bindings have
> been frustrating in the past.

I'd have posted the site addresses if I'd had them handy.
Unfortunately, they're filed on a machine I can't access from here...

I wouldn't want to post hilit.el; it's not *huge*, but I still wouldn't
want to send it to the whole distribution.
--
   _     Jim Thompson           |  Western Geophysical
 _| ~-   thompson@wg2.waii.com  |  Exploration Products
 \,  _}  jimt@sugar.neosoft.com |  3600 Briarpark
   \(    (713) 964-6213         |  Houston, TX 77042
Newsgroups: gnu.epoch.misc
From: uri@watson.ibm.com
Subject: Epoch-4.2 problem (help!)
Reply-To: uri@watson.ibm.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 23:07:23 GMT

Hello,
	I like Epoch very much, and if you could help
	me to get rid of this [strange] bug - I'll be
	really happy (:-).

	Epoch-4.2 (got from ftp.uu.net), no additional
	patches applied (just am not aware of any :-).

	AIX/ESA (aka OSF/1) on IBM-390 Mainframe.
	Metaware High-C R2.4q compiler (almost
	ANSI). Epoch is configured for BSD4_3,
	so I'm giving "-D_BSD -DBSD_INCLUDES" compiler
	flags, plus "-g" of course.

	The problem is: "dired" doesn't work, and either
	returns empty buffer (saying "done", as if A.O.K),
	or (more seldom, on bigger directories) it just
	hangs up... Finally "ls" process gets into "Idle"
	state, while Epoch is sleeping...

	When I try "ESC-|" to run something on a region,
	that program doesn't get any input...

	But I can do "M-x shell", and this works correctly
	and consistently. Shell buffer seems to be fully
	operational.

	I'm willing to pursue this problem, if you could
	guide me. I do want to get Epoch up'n'running,
	especially since this seems to be the only
	problem I'm having with it now: it does
	get up, it can edit files, etc...

	Help please!!! Thanks!!
--
Regards,
Uri         uri@watson.ibm.com      scifi!angmar!uri 	N2RIU
-----------
<Disclamer>

Newsgroups: gnu.epoch.misc
From: kaplan@cs.uiuc.edu (Simon Kaplan)
Subject: Epoch under Solaris
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 04:45:47 GMT

If anyone has *actually* gotten epoch to RUN under solaris, I would
*really, really* like to hear from you, and get patches etc.

Thanks a bunch,
Simon Kaplan
From: hsg@cs.duke.edu (Henry Greenside)
Newsgroups: gnu.epoch.misc
Subject: Standard tricks with epoch?
Date: 8 Oct 92 18:06:34 GMT
Distribution: gnu.epoch.misc
Organization: Duke University CS Dept., Durham, NC


Epoch was recently installed on my RS/6000 and I am
having a hard time hard time figuring out how people
actually use the extra features that Epoch provides
(there are no devoted Epoch users here). The TeXinfo
information is too much a reference book. I have been a
fairly heavy and enthusiastic user of emacs to date.

Can someone summarize for me the ways in which they use
Epoch to be more productive? Can they give me examples
of dotfiles that they use?

	Thanks,

	Henry
From: jct%se33@se01.wg2.waii.COM (Jim Thompson)
Newsgroups: gnu.epoch.misc
Subject: Re: Which to use Epoch or Lucid Emacs?
Date: 16 Oct 92 18:49:57 GMT
Article-I.D.: se33.9210161849.AA02388
Reply-To: thompson@wg2.waii.com
Distribution: gnu
Organization: GNUs Not Usenet

Dan writes:
> Lucid Emacs:
> 
> Epoch:
> 
>     In my experience, buggier.  Occasional crashes.  More frequent
>     redisplay glitches, e.g. in the bottom-most modeline of a screen.
>     Occational hangs.  Please don't get the idea that this makes it
>     unuseable, I used it as my standard editor for over two years
>     (and many versions) before switching.

Which version of Epoch are you comparing here?  My experience with the
most recent (4.2) has been that it is essentially bug-free--only the
occasional display glitch and, once in a blue moon, a core dump (but no
more than plain ol' emacs 18.58).

I would suggest to the original poster that Epoch is the least painful
way to gain a more X-friendly Emacs--the upgrade from Emacs 18.58 is a
novacaine hit.  Lucid, on the other hand was much harder to install and
run; save the real pain for GNU Emacs 19.  Epoch comfortably fills the
niche between it and GNU Emacs 18.xx.

Jim
--
   _     Jim Thompson           |  Western Geophysical
 _| ~-   thompson@wg2.waii.com  |  Exploration Products
 \,  _}  jimt@sugar.neosoft.com |  3600 Briarpark
   \(    (713) 964-6213         |  Houston, TX 77042
Newsgroups: gnu.epoch.misc
From: dvg@di.ufpe.br (Denis do Vace Gadelha)
Subject: out
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:54:18 GMT

I would like to unsubscribe from this list, it is overflowing my mail
Newsgroups: gnu.epoch.misc
From: kniveton@zeus.swindon.rtsg.mot.COM (Andy Kniveton)
Subject: Please delete me from the mailing list
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 07:32:26 GMT

Hi,

Could you please delete me from the list !

Andy.
--
  _ _ /|        Andy Kniveton,  Tel No  +44 793 545349
  \'o.O'        Motorola Ltd,   Fax No  +44 793 541228
  =(___)=       16 Euro Way,    E-mail  kniveton@zeus.swindon.rtsg.mot.com
     U          Blagrove, Swindon,      kniveton@mot.com
                England, SN5 8YQ.       uunet!motcid!zeus!kniveton

Has anyone heard the rumors concerning HP's new portable 700 series machine ?

I hear that it is small enough to fit in your pocket and is code named Trouser
snake !
                                -- Brian Kelly
Newsgroups: gnu.epoch.misc
From: sriram@tcs.com (Sriram Srinivasah)
Subject: Re: Standard tricks with epoch?
Organization: Teknekron Communications, Inc
Distribution: gnu
Date: Fri, 9 Oct 1992 15:35:34 GMT


|> Two things come to mind.  First, Epoch makes it much easier to customize
|> key bindings, especially for function keys, than does xemacs.  See the
|> function epoch::rebind-key.  (I have a file that describes how to take
|> advantage of Epoch's key-binding abilities, but the sample code in it is
|> specific to Sun-4 keyboards.  I'll send this file to you if you like.)
|> 
|> Second is Epoch's ability to apply multiple styles (fonts and colors) to
|> the same buffer.  I have epoch set up to display my C++ comments in bold
|> font, and the module headers in dark blue--similar settings for other
|> types of buffers.  There are two similar packages to do this; I use
|> Hilit, and can send you a copy if you need it.  The other is called
|> LiteBrite; Marc Andreessen (marca@ncsa.uiuc.edu) wrote it and can
|> probably send you a copy.
|> 
|> All in all Epoch is terrific;  Emacs 19 (IF we ever see it) is going to
|> have to be damn good to beat Epoch.
|> 
|> Jim
|> --
|>    _     Jim Thompson           |  Western Geophysical
|>  _| ~-   thompson@wg2.waii.com  |  Exploration Products
|>  \,  _}  jimt@sugar.neosoft.com |  3600 Briarpark
|>    \(    (713) 964-6213         |  Houston, TX 77042

Jim,

If Hilit or Litebrite is in an anonymous ftp site, can you please post the address.
Alternatively, can you package and post it to the net. I'm sure a lot of people
will be interested. 

I've a request similar to the original poster. I'm coming to epoch after being
a power vi user. My attempts at learning the Ctrl-Meta etc. key bindings have
been frustrating in the past.

Sriram
(sriram@tcs.com)
From: estutes@thelocker.corp.sgi.com (Earl Stutes)
Newsgroups: gnu.epoch.misc
Subject: Re: Standard tricks with epoch?
Date: 9 Oct 92 19:12:39 GMT
	<1992Oct9.153534.18971@tcsi.com>
Distribution: gnu
Organization: /usr/people/estutes/.organization


	>>I've a request similar to the original poster. I'm coming to epoch after being
	>>a power vi user. My attempts at learning the Ctrl-Meta etc. key bindings have
	>>been frustrating in the past.


"power vi user" is an oxymoron.

=eas=
--
=eas=

Earl A. Stutes
Software Consultant.		408 448 1089 voice 
P.O. Box 35567			408 228 8932 car
Monte Sereno, CA 95030-5567	408 631 6937 pager
Newsgroups: gnu.epoch.misc
From: carroll@cs.uiuc.edu (Alan M. Carroll)
Subject: Epoch as WM
Organization: Technophiles Inc. - Engineers with Attitude
Date: Wed, 7 Oct 1992 16:53:06 GMT

In article <JWZ.92Oct6210542@thalidomide.cs.cmu.edu>, Jamie Zawinski <jwz@cs.cmu.edu> writes:
> Clearly the right thing would be to add a minimal number of WM primitives
> to the emacs C code, and start your window manager as "emacs -q -l wm.elc".

I must strongly disagree with this. It's hard enough to handle the X
events Epoch already deals with. It'd be a nightmare to add real WM
capabilities.

I think that the GWM approach, while perhaps not the best in
implementation, is the superior solution in the long term. What you
can already do is communicate in a high-bandwith way with GWM from
Epoch and make requests of the window manager. Building such
communication facilities into the WM makes these capabilities
available to any client that wants them. This is the general scheme
used in CB and we've found it to work quite well.

-- 
Alan M. Carroll          "Weren't there yams involved, too?" - J. Ockerbloom
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan
Newsgroups: gnu.epoch.misc
From: mahesh@amnese.eng.uab.edu (B.G. Mahesh)
Subject: I can't use the same .emacs for epoch and emacs
Originator: mahesh@amnese.eng.uab.edu
Reply-To: mahesh@evb.com
Organization: SETT, Inc.
Distribution: usa
Date: Wed, 14 Oct 1992 17:44:21 GMT

hi

I have installed epoch 4.x on my Solbourne. I can't
use the .emacs of epoch for emacs (epoch -nw). When I
try to use emacs itays "Error in init file".
Is there a way to solve this problem?

Please respond by email only.

thanks


-- 
B.G. MAHESH                           | Email : mahesh@evb.com
Software Engineer                     |         
SETT Inc. (Affiliated to EVB Software Engineering, Inc.)
Frederick MD
From: tomw@orac.asd.sgi.com (Tom Weinstein)
Newsgroups: gnu.epoch.misc
Subject: Re: Standard tricks with epoch?
Date: 9 Oct 92 23:55:01
Organization: Silicon Graphics Inc.
Distribution: gnu
Reply-To: tomw@asd.sgi.com
NNTP-Posting-Host: orac.asd.sgi.com
In-reply-to: jct%se33@se01.wg2.waii.COM's message of 9 Oct 92 20:50:05 GMT

In article <9210092050.AA08353@se33.wg2.waii.com>, jct%se33@se01.wg2.waii.COM (Jim Thompson) writes:
> You write:

>> If Hilit or Litebrite is in an anonymous ftp site, can you please
>> post the address.  Alternatively, can you package and post it to the
>> net. I'm sure a lot of people will be interested.

> I'd have posted the site addresses if I'd had them handy.
> Unfortunately, they're filed on a machine I can't access from here...

You can find hilite, highlite, and lightbrite in the elisp archive.

ftp to archive.cis.ohio-state.edu and look in
pub/gnu/emacs/elisp-archive/epoch.

--
Love is a conveyor belt of   |   Tom Weinstein  tomw@orac.esd.sgi.com
warmth  -- Jackie Chan       |                  tomw@bears.ucsb.edu
Newsgroups: gnu.epoch.misc,news.answers
From: Jamie Zawinski <jwz@lucid.com>
Subject: Re: Epoch as WM
Organization: Lucid, Inc., Menlo Park, CA
	<JWZ.92Oct6210542@thalidomide.cs.cmu.edu>
	<1992Oct7.165306.29274@m.cs.uiuc.edu>
X-Windows: Sometimes you fill a vacuum and it still sucks.
Date: Thu, 8 Oct 92 06:06:32 GMT

In article <1992Oct7.165306.29274@m.cs.uiuc.edu> carroll@cs.uiuc.edu (Alan M. Carroll) wrote:
> In article <JWZ.92Oct6210542@thalidomide.cs.cmu.edu>, Jamie Zawinski <jwz@cs.cmu.edu> writes:
>> Clearly the right thing would be to add a minimal number of WM primitives
>> to the emacs C code, and start your window manager as "emacs -q -l wm.elc".
> 
> I must strongly disagree with this. It's hard enough to handle the X
> events Epoch already deals with. It'd be a nightmare to add real WM
> capabilities.

Well, I was mostly joking (mostly.)  If it's harder to handle events in Epoch
than in GWM, then that just means that GWM has a better design for event
handling, right?  They're both lisps.

The reason I think that such a thing could be reasonable is that emacs-lisp
is pretty close to common lisp, reasonably efficient for simple things, and
comes with a pretty good development environment.  And, in emacs, most of the
work is done.  I think that writing a new lisp (with a brand new idiosyncratic
syntax, no less) was a pretty big mistake.

> I think that the GWM approach, while perhaps not the best in implementation,
> is the superior solution in the long term. What you can already do is
> communicate in a high-bandwith way with GWM from Epoch and make requests of
> the window manager.

I'm just talking about a customizable, extensible window manager.  (I think
that the way that one can offload the work of popping up menus, etc to the
window manager is a bad idea, but that's a different matter.)

	-- Jamie
Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: bash and AIX
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 16 Oct 1992 05:46:55 GMT

> 	I am trying to compile bash 1.12, for AIX 3.2 on an RS6000, and
> I keep getting the errors shown below.  I am using gcc 2.2.2, and have
> tried both gnu make and IBM's make.  I even tried IBM's cc.  They all
> produce problems.  I even tried with both the fixed include files and
> without them when using gcc.  The below output was from gnu make and
> gcc.  Any help would be appreciated. 

Change the lines in general.h that declare index and rindex to read

#if !defined (__STDC__) && !defined (index)
extern char *index (), *rindex ();
#endif

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: bothner@cygnus.com
Subject: Re: Problems and workarounds on the Convex
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 14:41:07 GMT

Convex /usr/include/stdio.h defines:

    typedef struct {
      int __offset[2];
    } fpos_t;

Unfortunately, it is not possible for streambuf.h to use the
correct type for fpos_t in this situation, without getting
it from stdio.h - and I don't want to #include <stdio.h>
in general, for name-space reasons.

A clean solution requires some surgery:
stdio.h and streambuf.h must get fpos_t (or something
like struct __fpos_t) from the same include file - and
that include file is *not* allowed to define extraneous names!

So there is no simple, clean, correct solution.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.bash.bug
From: bekker@eltn.utwente.NL (H.G. Bekker)
Subject: 'bug' bash 1.12
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 14:36:32 GMT

Hi,

Strictly speaking this is not a bug. I am trying to install bash-1.12 on a
486 PC running SCO UNIX 3.2.2. The makefile figures out (correctly) that I
have SCO UNIX running on a i386 (shouldn't be a problem) and tries to compile
the file y.tab.c. After a couple of warnings in .lib/readline/readline.h and
parse.y the tool /usr/bin/cvtomf gives a fatal error: too many modules.

Which modules are being converted by cvtomf? Can I do it by hand?

regards

H.
H.G. Bekker
University of Twente, The Netherlands

Newsgroups: gnu.g++.bug
From: tiller@solace.me.uiuc.edu (Mike Tiller)
Subject: Segmentation Fault
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 06:39:45 GMT

The following code although erroneous should trigger an error not a segmentation
fault.  This brings me to an additional point...would it be possible to add a 
debugging flag to g++ and gcc so you can find out what line they are one when
they die this most horrible kind of death.  Most of the time it is an error that
compiler can't digest and would be easily recognizable.  In other words, most of
the time it is something I could fix...If I only knew where it was.

template<class T>
class	Array
{
	int	size;
};

enum	Source { Scalar, Array, Function };

Thanks

Michael Tiller
University of Illinois (Urbana-Champaign)

Newsgroups: gnu.g++.bug
From: h.b.furuseth@usit.uio.NO
Subject: Strange error message from g++-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 12:45:37 GMT

I see no `&' in the class below, though I'm sure g++ could use one
internally:

% g++ -S x.cc
x.cc: In method `void  foo::bar (int)':
x.cc:6: invalid lvalue in unary `&'
% cat x.cc
struct foo {
   int i;
   
   void bar ( int i )
   {
      foo::i = i;
   }
};


Hallvard

Newsgroups: gnu.g++.bug
From: h.b.furuseth@usit.uio.NO
Subject: delete[] on g++-1.42
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 15:47:46 GMT

It would be nice if `g++-1.42 -Wall' either accepted `delete[] x;' or
did not warn about `delete[size] x;'.


Hallvard

Newsgroups: gnu.g++.bug
From: jimc@math.ucla.edu
Subject: Explicit call of pure virtual function sneaks past
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 08:28:15 GMT

// g++ v2.2.2 for Sun-Sparc-SunOS v4.1.1
// Explicit call of pure virtual function compiles (shouldn't?) and
// code bombs (should use virtual table?)

#include <iostream.h>

struct base {
    virtual void mbrfunc() = 0;
};

struct derived : public base {
    void mbrfunc() 
	{ cout << "derived::mbrfunc\n"; }
};

int main() {
    derived d;
    d.mbrfunc();		// prints derived::mbrfunc, correctly
    d.base::mbrfunc();		// prints ABORT (should not compile)
}

James F. Carter        Voice 310 825 2897	FAX 310 206 6673
UCLA-Mathnet;  6221 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90024-1555
Internet: jimc@math.ucla.edu            BITNET: jimc%math.ucla.edu@INTERBIT
UUCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc

Newsgroups: gnu.g++.bug
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Subject: No bug. Was: gcc 2.2.2 (C++)
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Mon, 12 Oct 1992 22:40:41 GMT

mano@arch04.acri.FR (S Manoharan) writes:

>Static members of user defined-type generate link-time errors.
That is because they must be defined outside of the class (possibly
initialized as well) at least once in addition to being declared
inside the class. This is in ARM and confusing to every beginner
with static members. Puzzled me as well, but is standard C++.

Newsgroups: gnu.g++.bug
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: new bug: (none)
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Fri, 9 Oct 1992 18:29:47 GMT

werner@ast1.uibk.ac.at (  Werner Benger     ) writes:

> There seems to be another bug in the GNU C++ 2.2.2 Compiler:
> If a constant reference is created, the value of the original variable
> is copied once to a different place where the reference points to.
> Therefore the reference value is not affected when the variable is changed.
> In the following example the output should be: 
>	   19 5 7 11        instead of       19 19 19 19
If you want to declare a constant pointer to an int, you have to
declare int & const y;
Although this is pretty pointless, because references cannot be
changed after initialization anyhow. But you decalred a reference
to a constant integer. Since you gave a non-constant integer as
an argument, C++ converted to a constant integer by making a copy.
This is perfectly legal. If you want a reference to the CHANGING
integer, declare it without const. 
The other `error' is to be reported to a different list, I believe.
> The same error occurs when "int" is changed to "double".
> While debugging, I detected also an mistake ( is it a mistake ?)
> in <iostream.h> :
>            ostream&operator<<(ostream&,void*) 
>  should be changed into
>            ostream&operator<<(ostream&,const void*) 
>  since the content of a pointer been printed out is not changed 
>  ( at least it should not ).  With the current version a warning message
>  is produced when compiling the program below.

>#include <iostream.h>

>int x=19;

>main()
>{
>const int&y=x;

>	cout << y << " ";
>	x=5;	cout << y << " ";
>	x=7;	cout << y << " ";
>	x=11;	cout << y << " ";
>	cout << &x << "   " << &y << '\n';
>	return 0;
>}







Newsgroups: gnu.g++.bug
From: karsten@pegasus.inf-technik.th-ilmenau.de (Karsten Pahnke)
Subject: ostream operator << /*
Organization: TH Ilmenau/MSS, Germany
Distribution: gnu
Date: Thu, 8 Oct 1992 13:00:54 GMT

Hallo,

it seems to be there is an error in g++ 2.2.2

it is not possible to implement global(not friend)
ostream operators for template classes

the following is a shorthand example of the problem

i thank for your efforts

Karsten

karsten@Inf-Technik.TH-Ilmenau.DE

-----------------------------------------------------------
*/

#include <iostream.h>

template <class T>
class Array {
	T* _arr;
	int _len;
public:
	Array(int len) { _arr = new T[_len = len]; }
	int	len() const { return _len; }
	T&	operator[](int i) {return _arr[i]; }
	void	print(ostream& s) const 
	{
		for ( int i = 0; i < _len; i++ ) {
			s << _arr[i] << " ";
		}
	}

	/* version 1 works properly, but friend is not necesssary */
	/* thats why version 2 */
	/*
	friend ostream& operator<<(ostream& s, const Array& a) 
	{ a.print(s); return s; }
	*/
};

/* works properly */
template <class T>
inline int empty(const Array<T>& a)
{
	return (a.len() == 0);
}

/* version 2 works with cfront, but not with gnu */
/*
/space/localtmp/gnu/bin/g++  -B/space/localtmp/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.2.2/
-I/space/local/gnu/lib/g++-include -g -DPRECOND -DYYDEBUG -DDEBUG \
-I/home/usr/omsi/work/inc \
        -c comp_out.cc
comp_out.cc: In function `int  main ()':
comp_out.cc:42: warning: dbx info for template class methods not yet supported
/space/localtmp/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
*** Error code 1
make: Fatal error: Command failed for target `comp_out.o'
*/

template <class T>
inline ostream& operator<<(ostream& s, const Array<T>& a)
{
	a.print(s); return s;
}

main()
{
	Array<int> a(10);
	cerr << empty(a) << endl;
	cerr << a << endl;
} 


-- 

 -----------------------------------------------------------
| Dipl.-Ing. Karsten Pahnke     | Telefon : 0037 672 691167 | 
| Technische Hochschule Ilmenau |           0037 672 691168 |       
| PSF 327, O-6300 Ilmenau       | Telefax : 0037 672 691517 | 
|-----------------------------------------------------------| 
| E-Mail : Pahnke@Inf-Technik.TH-Ilmenau.DE                 |
 -----------------------------------------------------------


Newsgroups: gnu.g++.bug