HDTenEightyP/NetNews huggingface dataset:
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: (none)
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu
Date: Thu, 1 Oct 1992 13:32:06 GMT

ydavid@dxcern.cern.ch (Yann David) writes:

>I am currently in the process of learning C++ and I have some difficulty 
>using static class variables (when compiling my .C files with gcc).
>It seems that the linker does not recognize those static variables.
>
>  #include <stream.h>

****> Use <iostream.h>; <stream.h> is only for backwards compatability.

>  class MyClass
>  {	static int a=0;

****> Change this to 
	static int a;	// no initialization

>    public:
>	void incA();
>  };

****> and add the following:
   int MyClass::a = 0;	// initialization goes here

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: gnu.gcc.help
From: jml12@cunixa.cc.columbia.edu (Jonathan M Lennox)
Subject: Re: (none)
Reply-To: jml12@cunixa.cc.columbia.edu (Jonathan M Lennox)
Organization: Columbia University
Distribution: gnu
Date: Mon, 28 Sep 1992 04:14:55 GMT

In article <9209252005.AA02289@mole.gnu.ai.mit.edu> rms@gnu.ai.mit.edu (Richard Stallman) writes:
>I plan to keep supporting GCC version 1, aiming for reliable
>compilation of correct programs, until version 2 is no longer
>considered beta test.

  Which reminds me of a question I've been meaning to ask--what is the
criterion for considering gcc 2 to be out of beta test?  Surely "when
all the bugs are gone" is not reasonable, but what will the threshhold
be?

Jonathan Lennox
jml12@cunixa.cc.columbia.edu
Newsgroups: gnu.gcc.help
From: gsk@marble.COM (Geoffrey S. Knauth)
Subject: (never mind) getting typedef name
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 13:09:01 GMT

I found it in dbxout.c:

	    /* Output typedef name.  */
	    fprintf (asmfile, "%s \"%s:", ASM_STABS_OP,
		     IDENTIFIER_POINTER (DECL_NAME (decl)));
Newsgroups: gnu.gcc.help
From: ruck@zeta.ee.ufl.edu (John R Ruckstuhl Jr)
Subject: glibc-1.05, can't install (was glibc-1.05, can't make test -- gas?)
Organization: EE Dept at UF
Date: Sat, 3 Oct 92 19:13:09 GMT

A copy of this text has been sent to bug-glibc@prep.ai.mit.edu 


> I'm installing glibc-1.05 on a sun4c running SunOS 4.1.1
> I'm using gcc-2.2.2 and make-3.62

> > How to Install the GNU C Library
> >    Installation of the GNU C library is relatively simple.

> I configured like:
>     $ ./configure sparc-sun-sunos4.1.1 --with-gnu-ld \
>     --prefix=/usr/local --exec_prefix=/usr/local

> I make'd successfully.

(questions and discussion regarding difficulties with "make test" elided)


So I install like:
     $ make install

and get two errors (ouch):
(1)
    mkdir zoneinfo
    zic -d zoneinfo -L leapseconds africa
    zic: illegal option -- L
    zic: usage is zic [ -s ] [ -v ] [ -l localtime ] [ -p posixrules ] [ -d directory ] 
            [ filename ... ]
    make[1]: *** [zoneinfo/Egypt] Error 1
    rm  zoneinfo/make[1]: unlink: zoneinfo/: Invalid argument

and after installing some protocols header files,
(2)
    install arpa/inet.h /usr/local/include/arpa/inet.h
    install arpa/ftp.h /usr/local/include/arpa/ftp.h
    install protocols/timed.h /usr/local/include/protocols/timed.h
    install protocols/talkd.h /usr/local/include/protocols/talkd.h
    install protocols/rwhod.h /usr/local/include/protocols/rwhod.h
    install protocols/routed.h /usr/local/include/protocols/routed.h
    make: *** [subdir_install] Error 1

and the install terminates at that point.

Regarding (1):  zic is being used non-portably, and, argument to the
remove is missing its terminating null character?

Regarding (2):  did the installation really just terminate in the
middle, with no explanation, or is this the normal termination point and 
the error reported here is just an exit message reflecting error (1).


By the way,
The making of the libraries (prior to installation) requires the make'r
to have . on the path, because some of the things executed during a
build don't have path-qualified names.
This isn't too difficult to figure out after seeing the failed make, but
ideally this shouldn't happen.


Thanks for your help.
Best regards,
ruck

John R. Ruckstuhl, Jr.                  ruck@alpha.ee.ufl.edu
Dept of Electrical Engineering          ruck@cis.ufl.edu, uflorida!ruck
University of Florida                   ruck%sphere@cis.ufl.edu, sphere!ruck
-- 
John R. Ruckstuhl, Jr.                  ruck@alpha.ee.ufl.edu
Dept of Electrical Engineering          ruck@cis.ufl.edu, uflorida!ruck
University of Florida                   ruck%sphere@cis.ufl.edu, sphere!ruck
Newsgroups: gnu.gcc.help
From: ydavid@dxcern.cern.ch (Yann David)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 11:25:52 GMT

From ydavid@dxds01.cern.ch Thu Oct  1 10:19:41 1992
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
	id AA26973; Thu, 1 Oct 92 10:19:59 +0100
Received: by dxds01.cern.ch (5.57/Ultrix3.0-C)
	id AA10785; Thu, 1 Oct 92 10:19:26 +0100
Date: Thu, 1 Oct 92 10:19:26 +0100
From: ydavid@dxds01.cern.ch (David Yann)
Message-Id: <9210010919.AA10785@dxds01.cern.ch>
To: ydavid@dxcern.cern.ch
Status: R

		Hi there !


I am currently in the process of learning C++ and I have some difficulty 
using static class variables (when compiling my .C files with gcc).
It seems that the linker does not recognize those static variables.
For example, the following program:


  // Some difficulty using static class variables (& functions)

  #include <stream.h>

  class MyClass
  {	static int a=0;
    public:
	void incA();
  };

  void MyClass::incA()
  {	a+=1;
	cout<<a;
  }


  main()
  {	MyClass ex;
	ex.incA();
	ex.incA();
  }


comes up with the following message:

  ld:
  Undefined:
  _7MyClass$a
  collect: /usr/bin/ld returned 1 exit status

which I don't understand.

Thank you in advance for your help!

Yann DAVID, student at CERN.


NB: I work on a DEC workstation, under ULTRIX.

Xref: sparky gnu.gcc.help:2216 comp.robotics:1924
From: nanders@plains.NoDak.edu (Noel Anderson)
Newsgroups: gnu.gcc.help,comp.robotics
Subject: Re: gcc cross compiler for the 6811?
Date: 30 Sep 92 12:38:57 GMT
Article-I.D.: plains.20813
Organization: North Dakota Higher Education Computing Network

In article <1992Sep28.191208.10169@ulowell.ulowell.edu> jrichard@cs.ulowell.edu (John 'MacGyver' Richardson) writes:

>	While searching though the config .h files I noticed 
>there is code for 680x0 CPUs.  Would it be hard to convert gcc to the
>6811 from a 68000 (I assume it would be a 'scaling down' of addressing
>modes)?
 
There is no GCC port to the 6811 that I am aware of.  There are some major
architectural differences between the 68xxx and 68yy families which make
such a port non-trivial.  You've noted the reduction in addressing modes,
but not specifically the lack of indexed mode off the stack pointer.  There
are some gymnastics involved in working with parameters passed on the stack
when such a mode is missing.  These gymnasitics negatively impact performance.

A second major difference difference is the register set model.  The 68xxx
family has 8 32-bit data registers and 8 32-bit address registers.  The
68yy family has a 16 bit accumulator (or non-simultaneously two 8 bit
accumulators) and two index registers.  The 68HC16 has two 16 bit accumulators
and three index registers.  The 68xxx family registers nicely support
temporary values from expression evaluation, frame pointers, array element
address calculation, and structure field offsets.  One runs out of registers
to do all this nicely on the 68yy family - especially if all these have to
be done in the same source code statement.

A third difference is instruction set regularity and orthogonality.  Not
all 68yy operations work with all operand types and addressing modes.
Multiplication and division are particularly poor in this respect.

I'd be interested in seeing comments from other people that have studied
code generation from HLLs for the 68yy family....



-- 
Noel W. Anderson                   nanders@plains.nodak.edu (Internet)
Asst Prof, Computer Engineering         "I speak for myself, not NDSU"
EE Dept, North Dakota State University         nanders@plains (BITNET)
Newsgroups: gnu.gcc.help
From: lazarus@leland.Stanford.EDU (Howard Wang)
Subject: gcc 2.2.2 and shared libs on HP-UX 8.07
Keywords: gcc, HP-UX, shared libs
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 2 Oct 92 19:09:39 GMT

Does anyone know how to get the GNU ld to use the shared
libraries under HP-UX 2.2.2.  Now it doesn't seem to
recognize the libXX.sl libraries and instead uses and links
in the libXX.a versions.  Unfortunately the -lsb (starbase)
library only exists in shared form on our system as one
might guess from the following:

>ld: Can't find library for -lsb
>collect: /bin/ld returned 1 exit status


And if one can't use gld to use shared libraries, how does one
the the native HP ld to link the .o files produced by gcc?

I resolved the unresolved code __main problem by linking in the -lgcc
(libgcc.a) library,
( >/bin/ld: Unsatisfied symbols:
  > __main (code)  )

but when I try to run the executable, I get

>/lib/dld.sl: Unresolved symbol: main (code)  from /lib/libc.sl

some diagnostics:

>nm rovshell | grep main
>main                |     19024|extern|code   |$CODE$
>__main              |    195016|extern|code   |$CODE$


Any help would be appreciated,

Thanks

Howard
waho@orca.mbari.org
From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
Newsgroups: gnu.gcc.help
Subject: Need help! URGENT!
Date: 5 Oct 92 20:39:00 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering


The following may well be FAQs but since I couldn't find it (yet)
I will have to put them here.

(All is relevant to gcc for OS/2 btw)

When I call gcc *.c I get a long list of parsing errors, however
when calling gcc <all files explicitly> everything is fine. Is
there an explanation for this behaviour? It looks like the former
call gets gcc to use c++ style in spite of .c extensions.

How exaclty should ld be invoked? When I compile a single file fi
like gcc program.c -o program.exe, I get an executable; when
I do gcc -c program.c, ld -o program.exe program.o I get undefined
symbols like __main, _printf, __fill, __flush. I have the
library_path=d:/lib/emx set. (Tried both forward and backward slash)
Basically what I want to know is, is there more detailed info
on the usage of ld?

Hoping you can help me out...
Thanks, Erik


-- 
Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)
Newsgroups: gnu.gcc.help
From: davids@bohra.cpg.oz.au (David Schulz)
Subject: Porting gcc to an ARIX 825
Keywords: arix gcc
Organization: Computer Power Software
Date: Wed, 7 Oct 1992 02:37:49 GMT


I would like to hear from anyone who has ported gcc to an Arix 825
(68020).  Any help appreciated.

Please reply to davids@bohra.cpg.oz.au.


Thanks in advance,

David.
-- 

------------------------------------------------------------------------------
David Schulz                                            davids@bohra.cpg.oz.au
------------------------------------------------------------------------------
From: beckerd@handel.cs.unc.edu (David Becker)
Newsgroups: gnu.gcc.help
Subject: gcc includes
Summary: conflict with glibc includes
Date: 29 Sep 92 02:25:15 GMT
Organization: The University of North Carolina at Chapel Hill

Several of the glibc includes are identical to the includes files that
come with gcc, like limits.h, stddef.h and so on.  They conflict -- so
much for standards.  So who is more correct?

In the case of stddef.h, there is no problem if the glibc version is
included before the gcc version but not vice versa.  Since cccp wants to
include the gcc versions first in its default dir search, this conflict
arises.

Should the glibc files with the same name as the gcc includes be
considered more correct and just replace them?  Or is there some
interdepency (which I suspect for limits.h).


-- 
		``So you put 2 and 2 together and came up with 22?''
					``Yes!''
David Becker beckerd@cs.unc.edu			- Northern Exposure
Newsgroups: gnu.smalltalk.bug
From: tcm@moscom.COM (Tom Maszerowski)
Subject: Error in STIX (t.st)
Summary: Demo won't create display
Organization: Moscom Corp., Pittsford NY
Distribution: gnu
Date: Mon, 28 Sep 1992 15:48:53 GMT

I just got around to build STIX into mst, but running it produces:

Smalltalk 1.1.1 Ready

Processing t.st

Execution begins...
4406 byte codes executed
which took 0.51457 seconds, giving 85624.890685 bytecodes/sec
1068 cache hits, 28 misses 0.974453 hit ratio
returned value is nil

Execution begins...
write byte: Bad file number
write byte: Bad file number
write word: Bad file number
write word: Bad file number
write word: Bad file number
write word: Bad file number
write word: Bad file number
read byte: Bad file number
nil error: Failed to create display

UndefinedObject>>#executeStatements
UndefinedObject>>nil
120 byte codes executed
which took 0.19937 seconds, giving 6018.959723 bytecodes/sec
9 cache hits, 17 misses 0.346154 hit ratio
returned value is nil

Execution begins...

I've been away from Smalltalk and mst for a while, so if this is a FAQ
please excuse me.

CONFIGURATION:

CPU: sun 670MP
OS: SUN/OS 4.1.2
GCC: 2.2.2
MST: 1.1.1
X: X11R4

Tom
-----

-- 
Tom Maszerowski    tcm@moscom.com   
                   {rit,tropix,ur-valhalla}!moscom!tcm
                   DoD #1957 (1987 BMW K75s) BMWMOA #59113


Newsgroups: gnu.smalltalk.bug
From: Steven.Byrne@eng.SUn.COM (Steve Byrne)
Subject: Error in STIX (t.st)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 17:19:54 GMT

Tom Maszerowski writes:
 > I just got around to build STIX into mst, but running it produces:
 > 
 > Smalltalk 1.1.1 Ready
 > 
 > Processing t.st
 > 
 > Execution begins...
 > 4406 byte codes executed
 > which took 0.51457 seconds, giving 85624.890685 bytecodes/sec
 > 1068 cache hits, 28 misses 0.974453 hit ratio
 > returned value is nil
 > 
 > Execution begins...
 > write byte: Bad file number
 > write byte: Bad file number
 > write word: Bad file number
 > write word: Bad file number
 > write word: Bad file number
 > write word: Bad file number
 > write word: Bad file number
 > read byte: Bad file number
 > nil error: Failed to create display

This is the key -- I suspect you need to xhost + your own machine to defeat the
X authorization checking.  I have a hack for dealing with screen access control
in 1.2, but I haven't backported it to 1.1.1.

 > UndefinedObject>>#executeStatements
 > UndefinedObject>>nil
 > 120 byte codes executed
 > which took 0.19937 seconds, giving 6018.959723 bytecodes/sec
 > 9 cache hits, 17 misses 0.346154 hit ratio
 > returned value is nil
 > 
 > Execution begins...
 > 
 > I've been away from Smalltalk and mst for a while, so if this is a FAQ
 > please excuse me.
 > 
 > CONFIGURATION:
 > 
 > CPU: sun 670MP
 > OS: SUN/OS 4.1.2
 > GCC: 2.2.2
 > MST: 1.1.1
 > X: X11R4

Excellent!!!  All the info I need (and more).

Steve

Newsgroups: gnu.smalltalk.bug
From: vpcsc4@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Need help taking advantage of st.el's interactive support
Organization: San Francisco State University
Distribution: gnu
Date: Sat, 3 Oct 1992 07:01:13 GMT

Does anyone have  supplemental documentation on how to
use the interactive smalltalk commands such as
smalltalk-doit, smalltalk-compile, and smalltalk-snapshot?

My path set up so st.el finds mst and
when I type "M-x mst" I get the desired two window 
set up. If anyone is really ambitous they might
I instruct mst to evaluate the last 10 lines of code
below.

Your help is greatly appreciated. By helping me you are
also helping about 10 other students who find this of interest.

Regards, Emmett vpcsc4@sfsuvax1.sfsu.edu

= = c u t  h e r e = =
Object subclass: #GraphNode
	instanceVariableNames:'neighbors'
	classVariableNames:''
	poolDictionaries:''
	category: nil.
	!


!GraphNode class methodsFor:'creation'!
new
	^super new initNeighbors	
!!

	
!GraphNode methodsFor: 'all'!
initNeighbors
	neighbors_Set new
!

neighbors
	^neighbors
!
 
addNeighbor: theNode
	neighbors add: theNode.
!

doWithNeighbors: aBlock
	^neighbors do: aBlock
!

= theNode
	self subclassResponsibility
!!

|m l o count|
l_ GraphNode new.
m_ GraphNode new.
o_ GraphNode new.
l addNeighbor: m.
l addNeighbor: o.
count_0.
(l doWithNeighbors: [count_count+1]).
count printNl!

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: confusing key binding in gdb-mode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 03:38:08 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

Control-L in gdb mode should not be rebound.  People develop a reflex
to hit C-l when the screen gets garbled; it's counterintuitive to
have it rearrange the windows on the screen.  It would be ok
for C-c C-l to do this.

Newsgroups: gnu.emacs.bug
From: hunter@work.nlm.nih.gov (Larry Hunter)
Subject: Back to top level
Organization: National Library of Medicine
Distribution: gnu
Date: Thu, 1 Oct 1992 21:40:01 GMT

Using emacs 18.57 on a Silicon Graphics running IRIX 4.0.4:

I rarely exit emacs, often keeping sessions going for many days at a time.  And
I edit large files pretty regularly.  Sometimes, usually when working on a
large file in an emacs that has been running for a long time, emacs gets into a
state where no matter what I do, I get a minibuffer message that says: "Back to
top level".  I can't save buffers, I can't exit; nothing.  All I can do is kill
the process (from outside) and hope that the autosave buffers aren't too out of
date, or I didn't have any important processes running.  

I can't put together a short way of recreating this problem, alas. Any idea
what causes it?  Any way I could get some warning or prevent it from happening?
Thanks for any suggestions....

				Larry
--
Lawrence Hunter, PhD.
National Library of Medicine
Bldg. 38A, MS-54
Bethesda. MD 20894
(301) 496-9300
(301) 496-0673 (fax)
hunter@nlm.nih.gov (internet)

Newsgroups: gnu.emacs.bug
From: sbo@vlsi.polymtl.ca (Stephane Boucher)
Subject: C-g puts emacs in an unstopable loop
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Sep 1992 20:25:35 GMT

if C-g is pressed, when in function y-or-n-p and inhibit-quit is
nil, emacs repeatedly beeps while asking for a correct key.

If inhibit-quit is t, then everything works as expected when C-g
is pressed.

The following code is an example that makes emacs go into an
unstopable loop if C-g is pressed: 

(let ((inhibit-quit t))
	(y-or-n-p "Question foobar "))

  ,                          ,                           ,
Stephane Boucher, ing. jr. | Ecole Polytechnique de Montreal
sbo@vlsi.polymtl.ca        | Tel: (514)340-5950
sbo@info.polymtl.ca        | Fax: (514)340-4078

Newsgroups: gnu.emacs.bug
From: kelsey@mdd.COMm.mot.COM (Joe Kelsey)
Subject: Re: PROBLEM: Emacs won't startup under X
Organization: Motorola, Mobile Data Division - Seattle, WA
Distribution: gnu
Date: Wed, 30 Sep 1992 14:35:55 GMT

In <9209280250.AA14854@hobbes.cert.org> paul@devon.lns.pa.US (Paul Sutcliffe Jr.) writes:

>This is with Emacs 18.58.

>    Hardware:	no-name 80486/33 ISA clone
>    Software:	ESIX 4.0.3a  (System V/386 Release 4 Version 3)
>		X11R4 as distributed with ESIX 4.0.3a
>		Using TWM as distributed with ESIX 4.0.3a

>I am running X from the system console; TCP/IP is not running, as
>there is no Ethernet hardware in the system.

>Problem:
>XIO:  fatal IO error 14 (Bad address) on X server "devon:0.0"
>      after 53 requests (18 known processed) with 0 events remaining.


I just spoke with the tech-support line for Esix (714-259-3000), and they said
that you *must* list your system in a valid running netowrk -- i.e., you must
install TCP/IP and then at least put your system name in the ``loopback''
entry in /etc/hosts.  Call tech support for more info.

/Joe

Newsgroups: gnu.emacs.bug
From: rmf@chopin.cs.columbia.edu (Robert M. Fuhrer)
Subject: Re: dired-rename-file
Organization: Computer Science Dept., Columbia Univ.
Distribution: gnu
Date: Mon, 28 Sep 1992 19:20:05 GMT

I have posted my dired extensions to gnu.emacs.sources. It includes the code
you want and several other useful things (like remembering the target dir so
that successive renames default to the same place)...
--

-- Bob

Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: auto-save
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 16:39:00 GMT

auto-save should be switched off when in view-mode.

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| (39)(50)593203   (voice)

Newsgroups: gnu.emacs.bug
From: cracraft@ai.mit.edu (Stuart Cracraft)
Subject: emacs on Solaris2.0 on Sun 4/60 (Sparc 1)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 18:31:47 GMT

There are problems with emacs 18.58 on Solaris 2.0.
Using the s-usg5-4.h and m-sparc.h description header
files, I was unable to get even the xmakefile created
from the ymakefile in src/.

Also, the cpp subdirectory does not build cccp since
the "PW" library no longer exists (though if this -lPW)
is removed from cpp/Makefile, it links it.

But the xmakefile in src/ expects the "ccom" pass of the
compiler to exist in /lib. It doesn't. This pass of the
compiler does not even exist in the distribution binary
library for the now unbundled Sparc-Compiler C version 2.0.

In short, if you have emacs running under Solaris 2.0,
please contact me.

	Stuart

Newsgroups: gnu.emacs.bug
From: ryanr@beethoven.cs.colostate.edu (richard ryan)
Subject: evi bug
Organization: Computer Science Department, Colorado State University
Distribution: gnu
Date: Sat, 3 Oct 1992 22:12:42 GMT

Hi,

I didn't know if this was an evi bug or not, but in evi I tried to delete
a suffix with "%s/\.mf//g" and it didn't work but when I tried it with
regular vi, it did.  When I use vi I delete strings with this kind of
command a lot.  Is there a way to do it with evi?  Also if it is a bug and
is fixed by now, where can I get a copy that has this problem fixed?

Thanks,
Richard.

Newsgroups: gnu.emacs.bug
From: RICHARD@ttt.kth.se
Subject: Re: Running EMACS(X-Windows version) on VMS
Organization: Department of TeleTransmission Theory
Distribution: gnu
Date: Fri, 2 Oct 1992 11:55:47 GMT

There is a set of patches available, which gives you DECWindows interface,
"normal" (i.e. as in UNIX) subprocessing, networking, ptys.

It is available by mail. Just send a message to fileserv@ttt.kth.se with
this line in the body:

	SEND EMACS-1858-PATCHES

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager       ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology         ! fax: int+46-8-791 76 54           !
! Department of Teletransmition Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden            !                                   !
!---------------------------------------------------------------------------!

Newsgroups: gnu.emacs.bug
From: andrea@sihp03.si.estec.esa.nl (Andrea TONI)
Subject: -- movemail --
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 13:46:43 GMT

Thanks for the script .. I'll let you know how it works !!

Ciao
Andrea

Newsgroups: gnu.emacs.bug