HDTenEightyP/NetNews huggingface dataset:
From: Jamie Zawinski <jwz@lucid.com>
Subject: Re: AT&T sues BSDI
Organization: Lucid, Inc., Menlo Park, CA
	<MIB.92Jul21111729@geech.gnu.ai.mit.edu>
	<1992Jul22.155655.1596@wobble.uucp>
	<BRUNER.92Jul22161235@sp15.csrd.uiuc.edu>
Distribution: na
X-Windows: Flawed beyond belief.
Date: 22 Jul 92 15:23:27

In article <BRUNER.92Jul22161235@sp15.csrd.uiuc.edu> bruner@sp15.csrd.uiuc.edu (John Bruner) wrote:
>> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>>> It's worth noting that one of the grounds of the suit is that BSDI's
>>> phone numebr was advertised originally as 1-800-ITS-UNIX.
[...]
> In this particular case, an advertisement that states "it's UNIX" in
> describing BSDI's telephone number is clearly a violation of USL's
> trademark.

Gee, I thought they were talking about the Incompatible Timesharing System...

	-- Jamie
Newsgroups: gnu.misc.discuss
From: composer@world.std.com (Jeff Kellem)
Subject: Re: Unix Review of GCC
Reply-To: composer@Beyond.Dreams.ORG
Organization: Beyond Dreams
Date: Thu, 30 Jul 1992 16:28:06 GMT

patrick@ERC.MsState.Edu writes:
 > I haven't seen the review yet, but it sounds pretty weak.
 > Anyone have their address so we can write letters
 > (snail or e-mail)?
 > (After we have read the review, of course....)

The e-mail address for the UNIX REVIEW editors is: editor@ureview.com
It's listed at the bottom of the table of contents page.  FYI...

			-jeff

Jeff Kellem
Internet: composer@Beyond.Dreams.ORG
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: gnu.misc.discuss
Subject: Re: What is LPF position on AT&T v. BSDI?
Date: 26 Jul 92 14:05:03 GMT
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Jul24.020023.10999@algor2.algorists.com> jeffrey@algor2.algorists.com (Jeffrey Kegler) writes:
>Specific questions:
>
>2) I assume the LPF has no opinion on the matter of whether BSDI can
>use 800-ITS-UNIX as its phone number.  Is this right?

This is a dead issue. BSDI agreed back in April to stop using this
number.

I can't speak for the LPF either (I've been meaning to join for I
don't know how long, but haven't got round to it yet, though this
business is going to speed things up), but I tend to agree that it's
not LPF's charter to take sides in battles between commercial
companies. A side effect of this dispute, however, is much more
sinister: AT&T claims that, if you have been exposed to UNIX source
code, you can't develop any related product which is not in some way
UNIX-tainted and thus requires a UNIX license. This is effectively a
career-limiting action. Since nearly every computer science student
has been exposed to UNIX sources in some form, the effect of a
precedent here could be monumental, and would definitely stand in no
relationship to the real importance of the code.

-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers are mangled - reply to grog%lemis@Germany.EU.net
From: composer@world.std.com (Jeff Kellem)
Newsgroups: gnu.misc.discuss
Subject: Re: Rating of gcc in Unix Review
Date: 30 Jul 92 16:38:13 GMT
Reply-To: composer@Beyond.Dreams.ORG
Organization: Beyond Dreams

brendan@cs.widener.edu (Brendan Kehoe) writes:
 > This month's issue of Unix Review compares four C compilers (MetaWare,
 > GCC, Sun's unbundled C, and Lucid C).  They really trash GCC, giving
 > it F's on Installation because it's distributed as source, and "N/A"
 > on documentation, claiming it includes none.  (They define
 > documentation as printed and bound books, not electronic, apparently;
 > at least to the extent that Sun's Answerbook will fall under the
 > umbrella.)  In the area of overall performance, they claim MetaWare
 > and Lucid lead the pack, with GCC behind Sun's unbundled C.  Hmm.

The overall review (from what I originally skimmed) was not a great
review.  I suppose I should make some time to read the article in
its entirety to send comments to the editors.

As for saying that GCC performed slower than Sun's unbundled C
compiler..  since they were testing GCC 1.40 and probably on a SPARC,
then that makes sense.  GCC pre-2.x did perform slower than the Sun C
compiler, at times.  They mention that they didn't think the new
release may "improve performance times", based on their tests.  What
they didn't realize is that with GCC 2.x, there were definite speed
improvements on the SPARC (taking advantage of register windows, etc).

And, one of these days, people will learn that online documentation is
valuable, useable, and still documentation.  :)

 > Really strange, their approach with the testing.

Yep.. the review did seem a little odd.

				-jeff

Jeff Kellem
Internet: composer@Beyond.Dreams.ORG
Newsgroups: gnu.misc.discuss
From: saroff@uf.msc.edu (Stephen Saroff)
Subject: Mg and Jove
Reply-To: saroff@msc.edu
Organization: AHPCRC, Minnesota Supercomputer Center
Date: Tue, 28 Jul 1992 15:58:35 GMT


I'd like to know people's opinions about MG (micro gnu emas) and Jove
(Jonathan's Own Version of Emacs).

For a quick emacs substitute, what are the pros and cons.  Can either run
as a true x client?  I understand there are several versions of MG,
what are the differences, and which is the "best."


Thanks.

-- 
+------------------------------------------------------------------------+
Stephen Saroff <saroff@msc.edu>                 o o  The Bear who Swims      
Minnesota Supercomputer Center                  (_)_____o      
1200 Washington Ave. S                       ~~~~(______)~~~~~~~~~~
Minneapolis, MN 5514 <612/626-1854>              oo    oo 

Newsgroups: gnu.misc.discuss
From: tpc@bnr.ca (Thomas P. Chmara)
Subject: gnuMake 3.62 -- problems interworking with makedepend
Keywords: gnumake intermediate-files makedepend
Reply-To: tpc@bnr.ca
Organization: Bell-Northern Research Ltd.
Date: Thu, 30 Jul 92 19:43:50 GMT

I've been working with gnumake 3.62 for a few months now, and have found only
one problem which materially affects how I use the tool..  When trying to
incorporate dependencies on header files, I found that intermediate files were
no longer deleted on completion.  I am building into libraries:

library: $(MACH_HDRS) \
	$(foreach file, $(addsuffix .o, $(basename $(MACH_SRCS))), \
		../libbase.a($(file)))

The source files are local to the directory, or in a CVS1.0** repository whose
location is identified using VPATH.  I found that if I included the extra
dependencies generated by makedepend, the .c and .o files were not deleted.
If I didn't have the extra dependencies, the .c and .o files are successfully
deleted after the archive entry is updated.
I am working on a HP9000/345 running HP-UX 8.0, for what that's worth.

Has anyone had success with makedepend or its ilk in combination with gnuMake
3.62?  Any ideas where to start looking?  Is there a mailing list for gnuMake?

	---tpc---

**yes, yes, I know...we're going to CVS1.3 RSN...
-- 
I am sole owner of the above opinions. These opinions are furnished without
warranty or liability expressed or implied.  Your mileage may vary.
-----------------------------------------------------------------------------
Tom Chmara, P.Eng.|  INTERNET:  tpc@x400gate.bnr.ca	|  Fone:  (613)765-2925
BNR Ltd.	  |  					|  FAX:   (613)763-2626
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: gnu.misc.discuss
Subject: Re: Rating of gcc in Unix Review
Keywords: Unix Review C Compiler test rate evaluate gcc GNU 1.40 2.0
Date: 30 Jul 92 21:59:53 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <1992Jul29.231411.27588@chpc.utexas.edu> jonathan@chpc.utexas.edu (Jonathan Thornburg) writes:
>Note that Unix Review tested gcc 1.40, *not* the new gcc 2.0.
>This may account for their finding that gcc generated worse code
>than Sun's C.

I agree with this (i.e., all that I know indicates that gcc 2.0 is a
better compiler than gcc 1.40), BUT, be careful to match FCS with FCS
and beta-test with beta-test.  Also, don't discount the possibility
that Sun's C compiler might generally be faster.  We're not stupid
here, after all -- if we couldn't turn out better compilers (in the
opinion of some number of compiler customers), we'd all go do
something else.

(I'd ask to see your benchmarks on which gcc beats Sun's cc, but since
I'm not certain I could return the favor (and it IS a favor) you
shouldn't bother unless it particularly suits your mood.)

David Chase
Sun
From: marshall@ll.mit.edu (Hunter Marshall)
Newsgroups: gnu.misc.discuss
Subject: Re: Unix Review of GCC
Date: 30 Jul 92 03:22:05 GMT
Organization: MIT Lincoln Laboratory

I just read the review. It is virtually contentless. While part of me
thinks a letter campaign is in order, most of me thinks "big deal".

I could site some specifics, but it hardly seems worth it. 
I would like to know the VERSION they tested.

Let's not waste time on it.

Truly, one would be better served by reflection on the state of journalism
(hi-tech or not) in the US today, not to mention the embarassing spectacle
being made of the Olympics (at least on television).

	hunter
From: dc@stars.gsfc.nasa.gov (Dave Cottingham)
Newsgroups: gnu.misc.discuss
Subject: Re: Rating of gcc in Unix Review
Date: 29 Jul 92 22:37:00 GMT
Reply-To: dc@cobi.gsfc.nasa.gov
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1

In article <156eo7INN6d3@betty.cs.widener.edu>, brendan@cs.widener.edu (Brendan Kehoe) writes...
>This month's issue of Unix Review compares four C compilers (MetaWare,
>GCC, Sun's unbundled C, and Lucid C).  They really trash GCC,...
> 
>Really strange, their approach with the testing.

I don't regularly read the Unix Review, but my impression from the odd
issue I have read is that it, like many computing periodicals, is
targeted at the computer illiterate.  Given that, the approach is not
so strange.  I think a typical CI would find it excessively challenging
to compile the compiler or to figure out how to read texinfo documentation.
For them, I think GCC as it comes off of prep is not a good choice.
After all, the FSF was never intended as a hand-holding organization.
AS someone else already pointed out, a GCC distribution from Cygnus
would have been a better choice.

I wonder how they came up with the performance figures.  I have not myself
benched GCC against any of the named compilers; I don't know if they are
available for my Decstation.  However, I do know that GCC 2.0 produces
marginally faster code than the DEC (mips) compiler.  I wonder if this
article, like too many I've seen, ignored the speed of the resulting code
and concentrated only on how long the compilation took?  Sometimes it
seems that these publications, in order to better serve their computer
illiterate audience, feel they should hire computer illiterate writers.

I will look forward to the Unix Review article trashing the Hurd.

 - Dave Cottingham
   dc@cobi.gsfc.nasa.gov
From: jclark@src.honeywell.com (Jeff Clark)
Newsgroups: gnu.misc.discuss
Subject: Re: COOKIES
Date: 31 Jul 92 17:57:51 GMT
Organization: Honeywell Systems & Research Center

In article <pv@byu.edu> gritton@alaska.et.byu.edu (Jamie Gritton) writes:

Jamie> The COOKIES file included in the emacs distribution is ridiculous.

Maybe so, but the cookies are delicious!

Jeff Clark
---------------------------------------------------------------------------
Engineers make the pie grow larger; lawyers only decide how to carve it up.
---------------------------------------------------------------------------
Computer Systems / Software Technology	 Internet: jclark@src.honeywell.com
Honeywell Systems and Research Center	 UUCPnet:  jclark@srcsip.UUCP
3660 Technology Drive        MN65-2100	 PHONEnet: (612) 782-7347
Minneapolis, MN 55418-1006         USA	 FAXnet:   (612) 782-7438
---------------------------------------------------------------------------
DISCLAIMER: If you think I speak for my employer, you need serious help ...
From: johnw@cbmvax.commodore.com (John Wiederhirn - CATS)
Newsgroups: gnu.misc.discuss
Subject: 3B2 as GNU System target
Date: 26 Jul 92 23:13:13 GMT
Organization: Commodore, West Chester, PA

Are there any plans to provide the full GNU system (or the parts as they
become available) for the AT&T 3B2 series?  Currently, while some of them
can be compiled on the 3B2, the lack of binary support seems to prevent
using (for example) the entire GCC and bintools package.

I'm asking because I'm considering a 3B2 purchase, but without support
from AT&T, GNU support seemed like a good question to ask...


-- 
==========================================================================
       John Wiederhirn - Commodore Applications & Technical Support
         {uunet,rutgers}!cbmvax!johnw  johnw@cbmvax.commodore.com

      DISCLAIMER:  Any opinions within leased from Opinions-R-Us(tm)
==========================================================================
From: calyx.corp@mixcom.mixcom.com (calyx.corp)
Newsgroups: gnu.misc.discuss
Subject: Forcing keywords, MR's in RCS?
Date: 21 Jul 92 21:01:33 GMT
Article-I.D.: mixcom.1992Jul21.210133.17013
Distribution: usa
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.

Our site is considering converting our massive, ancient SCCS archive to
RCS (and possibly using CVS, too).  Two big reasons we want to move to RCS
are the binary file archiving support, and symbolic release tagging.

However, two nice features that we are moving to now with SCCS (before we
decide whether to convert to RCS) are the feature to require ID keywords
by setting the "i" flag in the "s." file, and requiring/validating MR's
(Modification Requests) by setting the "v" flag.  While we could certainly
just add klugy a front end to the RCS ci command, we would like something
enforced by the RCS commands themselves, to prevent people from circumenting
the front end.

I've looked through the RCS man pages, and there doesn't appear to be
any built-in features for enforcing/validating keywords and symbolic tags.
We really need this level of enforcement to maintain integrity for a
problem tracking database that will interface with the revision-controlled
files.

The "sccs2rcs" shellscript that comes with the RCS distribution effectively
discards the i and v flags in an s. file.  Isn't there any RCS equivalent?

Nels Olsen
-- 
calyx.corp@mixcom.com
Newsgroups: gnu.misc.discuss
From: sbhatia@mary.fordham.edu (SABU)
Subject: GNUPLOT
Organization: Fordham University
News-Software: VAX/VMS VNEWS 1.41    
Date: Sat, 25 Jul 1992 03:57:00 GMT
X-Posted-From: mary.fordham.edu
X-Posted-Through: sol.ctr.columbia.edu

Hi,

   I would like to know thw environments under which GNUPLOT is
available. Specifically I am interested in VAX/VMS and DOS or DOS/MS-WINDOWS
also VAX/VMS running decwindows.

thanks,

sabu

////////////////////////////////////////////////////////////////////////
/   Internet:  SBHATIA@mary.fordham.edu                                /
/   BITnet:    SBHATIA@FORDMULC                                        /
/                                                                      /
/                                                                      /
////////////////////////////////////////////////////////////////////////
From: dodd@mycenae.cchem (Lawrence R. Dodd)
Newsgroups: gnu.misc.discuss
Subject: Re: COOKIES
Date: 31 Jul 92 15:20:37 GMT
Reply-To: dodd@mycenae.cchem.berkeley.edu
Organization: Dept of Chemical Engineering, UC Berkeley, CA, USA
NNTP-Posting-Host: mycenae.cchem.berkeley.edu
In-reply-to: gritton@alaska.et.byu.edu's message of Fri, 31 Jul 92 09:27:12 MDT


>>>>> On Fri, 31 Jul 92 09:27:12 MDT, gritton@alaska.et.byu.edu (Jamie Gritton) said:

  Jamie>    The COOKIES file included in the emacs distribution is ridiculous.
  Jamie> Before Mrs. Fields was well-known, this legend was circulating around
  Jamie> about Neimann-Marcus (sp?). This obviously legendary tale doesn't
  Jamie> belong in emacs. (Many other files in the etc directory don't either,
  Jamie> but they're mostly innocous.

I agree completely.  I have removed most of the propaganda from my etc and
left only the file essential to running emacs and the COPYING and DISTRIB
files.  For instance, is ../etc/sex.6 really necessary?

My $0.02.
Newsgroups: gnu.misc.discuss
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Subject: Re: GNU Coding Standards
Organization: Free Software Foundation, Cambridge, MA
Date: Wed, 22 Jul 1992 15:48:13 GMT

In article <s_ebach.711808386@wega.rz.uni-ulm.de> s_ebach@wega.rz.uni-ulm.de (Bernd Ebach) writes:

   Where could I get a copy of the GNU Coding Standards?

For all such requests, send mail to gnu@prep.ai.mit.edu.

--
Michael I. Bushnell             |		Benedictus qui venit
+1 617 625 4518 (H)            -+-                       in
+1 617 253 8568 (W)             |                      Nomine
mib@gnu.ai.mit.edu              |                      Domini
Newsgroups: gnu.misc.discuss
From: david@campfire.stl.mo.US (David J Camp)
Subject: help with unexec
Reply-To: "David J Camp" <campfire!david@wupost.wustl.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 18:22:41 GMT

On Tue, 28 Jul 1992 08:30:26 GMT, "Graham Matthews" <graham@maths.su.oz.au> wrote:
> (David Nicodemus) writes:
> >I am looking for a way to force a program out of execution, and save 
> >an image of the program that can be restarted from the same point at 
> >a later time. 
> >
> >If anyone has anyone has information on finding this value, or on the
> >whole idea in general any help would be much appreciated.
> 
> I would be most interested in this too - can people post replies
> rather than email them.

There may be a way to force it to dump core.  I am not sure how to
restart it though.  -David-

# david%campfire@wupost.wustl.edu    ^     David J. Camp                #
# wupost.wustl.edu!campfire!david  < * >   +1 314 382 0584              #
# campfire!david@wupost.wustl.edu    v     "God loves material things." #
#         I am a member of the League for Programming Freedom.          #
From: purtill@idacrd.UUCP (Mark Purtill)
Newsgroups: gnu.misc.discuss
Subject: Coherent?
Date: 24 Jul 92 14:22:32 GMT
Organization: idacrd, princeton, nj


	Speaking of "what ever happened to", a while back it seems to
me there was some talk about the Coherent people (Mark Williams
company?) trying to enforce some very silly patent.  Were they
actually doing so, and if so are they still?

^.-.^ Mark Purtill, purtill@ccr-p.ida.org; uunet!idacrd!purtill. (609)497-0526.
((")) \@_: IDA/CCR-P, Thanet Road, Princeton NJ 08540;           (609)924-4600.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.misc.discuss
Subject: Re: GCC licensing issues.
Date: 22 Jul 92 19:48:31 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul22.172509.15151@cimage.com> andyh@cimage.com (Andy Hore) writes:
>The problem I have is this. I've been using gcc to compile a program
>that is to be sold commercially, and I don't want to infringe any
>copyrite issues the GNU. I read the COPYRITE.lib file that came with
>gcc-2.2.2  and thought that it implied that linking with libgcc would
>mean that I would infringe on copyrite laws. Is this correct thinking
>or not? If so, do you have any idea how I can resolve this problem,
>short of getting a new compiler?

>   I'm not currently linking with the GNU libc replacement, if that
>makes any difference.

Yes, this makes a difference.

libgcc1.c and libgcc2.c (the only sources for -lgcc) contain the following:

/* As a special exception, if you link this library with files
   compiled with GCC to produce an executable, this does not cause
   the resulting executable to be covered by the GNU General Public License.
   This exception does not however invalidate any other reasons why
   the executable file might be covered by the GNU General Public License.  */

The consequence is that if the only Gnu library you are including is
-lgcc, the GPL does not affect your code in any way.

If you use the GNU libc or libg++, you are subject to a weaker license
known as the LGPL.  (Gnu Library General Public License).  This permits
you to keep your own code proprietary; however, you must distribute your
application in linkable form (for example, with .o files and a Makefile)
with full sources to the Gnu libraries that you use.  (I suppose that it
would be legal, though unfriendly, to do an ld -r that links all of your
code into one big .o file and ship that along with the libraries).

If you use any code covered by the GPL rather than the LGPL (for example,
the bison parser skeleton, or part of Gnu Emacs, or some such), you are
covered by the GPL -- you either must put all of your code under the GPL
or else you have no permission to use the Gnu code.

What I'm giving you here are the basics; consult a lawyer for tricky
boundary cases.





--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.misc.discuss
From: neeri@iis.ethz.ch (Matthias Neeracher)
Subject: Re: AT&T sues BSDI
Organization: Integrated Systems Laboratory, ETH, Zurich
	<1992Jul20.211451.3051@algor2.algorists.com>
	<MIB.92Jul21111729@geech.gnu.ai.mit.edu>
Date: Wed, 22 Jul 1992 09:17:30 GMT

In article <MIB.92Jul21111729@geech.gnu.ai.mit.edu> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>It's worth noting that one of the grounds of the suit is that BSDI's
>phone numebr was advertised originally as 1-800-ITS-UNIX.  That's
>pretty clearly trademark infringment.

So when is MIT going to sue BSDI for infringement of the ITS trademark ? :-)

Matthias
From: gritton@alaska.et.byu.edu (Jamie Gritton)
Newsgroups: gnu.misc.discuss
Subject: COOKIES
Date: 31 Jul 92 15:27:12 GMT
Reply-To: gritton@byu.edu
Organization: Brigham Young University, Provo UT USA


   The COOKIES file included in the emacs distribution is ridiculous.
Before Mrs. Fields was well-known, this legend was circulating around
about Neimann-Marcus (sp?). This obviously legendary tale doesn't
belong in emacs. (Many other files in the etc directory don't either,
but they're mostly innocous.
--
James Gritton - gritton@byu.edu - I disclaim
From: yee@mipgsun.mipg.upenn.edu (Conway Yee)
Newsgroups: gnu.misc.discuss
Subject: Re: What's in a name?
Date: 28 Jul 92 00:27:35 GMT
Organization: University of Pennsylvania

paulf@w6yx.Stanford.EDU (Paul Flaherty) writes:
>
>Well, my Reed - Solomon error correcting coder is now out of beta, and the
>only remaining issue is:
>
>What to call it?
>
>I had originally proposed "rs", in keeping with Unix tradition of short,
>clipped names.  Critics have replied that this is too short, and that
>something like "ecc-encode" and "ecc-decode", though that seems to be
>pretty long and awkward.  As an interim, I'm using "rscode" with flags
>to indicate the desired operation.
>
>Sooooo...since Gnu's Not Unix, what will the command name philosophy be?

Well, if this is a poll, here is my $0.02

You wrote it, you get to call it absolutely anything you want.

Personally, I like "rs".  Long names give me typing cramps.  Easier to
remember but hell to type.




-- 
411 Blockley Hall      |                    Conway Yee, N2JWQ
418 Service Drive      | yee@ming.mipg.upenn.edu    (preferred)
Philadelphia, PA 19104 | cy5@cunixa.cc.columbia.edu (forwarded to above)
(215) 662-6780         |
Newsgroups: gnu.misc.discuss
From: rv@cs.brown.edu (rodrigo vanegas)
Subject: Re: GNU finger
Organization: Dept. of Computer Science, Brown University
	<BrqB4M.KpH@immd4.informatik.uni-erlangen.de>
	<Brspxt.19o@immd4.informatik.uni-erlangen.de>
Date: Wed, 22 Jul 1992 18:51:43 GMT

In article <Brspxt.19o@immd4.informatik.uni-erlangen.de>, ehmeier@immd4.informatik.uni-erlangen.de (Erich Meier) writes:

> ...
> Therefore I implemented the cfinger-"protocol" on top of Sun's RPC
> mechanism.  That makes finger much more reliable and faster, too.  I
> also fixed a few bugs and made extentions to GNU finger.  For
> coordinating my changes with the GNU finger developers, I tried to
> communi- cate with the author and failed. So maybe I'll release my
> own version.

> If you're interested in my version, drop me a line.

THIS is the meaning of free software!  it's great to see the process
working *smile*.  yay GNU!

rodrigo_vanegas@brown.edu