HDTenEightyP/NetNews huggingface dataset:
From: giddings@whitewater.chem.wisc.edu (Michael Giddings)
Subject: Newsgrazer doesn't work
Organization: Physical Sciences Lab, UW-Madison
Date: Fri, 6 Nov 92 08:19:29 GMT

Newsgrazer will only work on one of our machines.  There is a central nntp  
server in the building which the preferences are set to point to, but when  
run on two of the machines, newsgrazer consistently comes up with "no new  
articles".  But things work fine when run on our cube (all the computers  
were given access to the news server).  Newsgrazer is set up exactly the  
same on each of the machines as far as I can tell. 

Does anyone have some idea of what differences between systems could cause  
this?

--
Michael Giddings                   | DNA sequencing technologies 
giddings@whitewater.chem.wisc.edu  | Artificial Intelligence
giddings@cs.wisc.edu               | Sciences NeXT User Group founder
            |---------\-----------/|\------------/---------|
Newsgroups: comp.sys.next.software
From: jag@seguente.ximage.com (Jagdish Narasimhan)
Subject: Wanted MOUSY EMACS on the NeXT...
Reply-To: jag@ximage.com
Organization: /Net/ximage/users/jag/.organization
Date: Tue, 10 Nov 1992 23:36:02 GMT

The title sayeth all...I do have emacs but unfortunately without the
mouse support...please respond to my e-mail addresss, as i sometimes
forget to catch up on the news...

Jag
Newsgroups: comp.sys.next.software
From: nwc@blackbox.cc.columbia.edu (Nick Christopher)
Subject: Sound Converter (GISO) for NS3.0
Organization: Columbia University
Date: Sun, 8 Nov 1992 15:41:16 GMT

GISO.app fpr NeXTSTEP 3.0 is now available at:

	sonata.cc.purdue.edu:/pub/next/submissions/GISOfor3.0.compressed

GISO for NeXTSTEP 3.0

What's GISO? GISO provides an easy way to convert sounds to and from
different sound formats and also preview NeXT sounds. 

GISO is actually just a wrapper for sox. 

What's sox? Sox is a filter program with the ability to convert in and out of
many (all that I know of) sound formats. It will move in and out of .au, .aiff,
.voc, .hcom, .wav and any raw format you can describe with its parameters.  Its
interface is very complicated and so that is why I wrote GISO.

To build it just type "make install".

*** New in Version 3.0:

	- Compiles without errors under NS3.0

	- Responds to double click of self describing sound file formats.
		- i.e. responds to .snd, .au, .voc, .wav
		
*** New in Version 2.1:

	- Newest version of sox used. New sox handles .wav files cleanly and has
	some new filters (See man page).
	
	- Uses Subprocess Object now to run sox in (Subprocess was originally a
	NeXT example that has been touched up some).
	
	This means

		- No more spining disk during conversions.

		- Conversions can be aborted.

	- Small interface clean ups.


\n


			Ronin Consulting
Nicholas W. Christopher			 Nick_Christopher@gun.com
From: greg@brooks.async.vt.edu (Greg Foliente)
Newsgroups: comp.sys.next.software,comp.sys.next.misc
Subject: NCSA Scientific Visualization Software (Requests)
Date: 5 Nov 92 23:06:15 GMT
Reply-To: greg@brooks.async.vt.edu OR pol2@vtvm1.cc.vt.edu
Followup-To: comp.sys.next.software

%   From: greg@brooks.async.vt.edu (Greg Foliente)
%   when can we get NCSA visualization software for the NeXT?
%
%If we knew there was enough demand for our programs to run on the
%NeXT, and if we got some funding and machines, we would consider it.
%(I would personally prefer developing for the NeXT.)
%
%So if this is what you want, flood me with mail and I will forward it
%to the proper individuals.  Get the README.BROCHURE from
%ftp.ncsa.uiuc.edu for a description of what we offer.
%
%liberte@ncsa.uiuc.edu  
%(217) 244-0785
%
%Daniel LaLiberte
%National Center for Supercomputing Applications
%152 Computing Appliations Building
%605 East Springfield Avenue
%Champaign, IL 61820

There! If you are interested or know of others who might, please spread  
the word and "flood" Daniel with e-mail requests.

--
.................................................................
Greg Foliente                   NeXTmail: greg@brooks.async.vt.edu 
Virginia Tech, Blacksburg, VA                 pol2@vtvm1.cc.vt.edu
.................................................................
Newsgroups: comp.sys.next.software
From: paul@seer.demon.co.uk (Paul Lynch)
Subject: Re: nbuf=64/128 theory
Organization: P & L Systems
Date: Sun, 8 Nov 1992 22:09:56 GMT

In article <1992Nov8.130418.19237@wam.umd.edu> gaia@wam.umd.edu (L.  
Anathea Brooks) writes:
> 
> I've changed my boot params using nbuf=128 or rather 
> nbu=128 because of 12 character limit.
> 
> Now, I know this will speed up long compilations, perhaps
> various sorts of number crunching. BUT is there any advantage 
> or speed gain in workaday world? I notice none, and wonder if 
> the memory used by the buffer might be better used as just 
> plain old memory. 

Are you running 3.0?  If so, you should see a noticeable speed  
improvement, particularly when scrolling text windows (such as in Edit)

Also, are you sure that you typed it in correctly.  If so, the first  
messages in a verbose boot should confirm the number of buffers in use.   
The only indication that you get of an incorrect parmeter is that the  
number of buffers reported is 16.

Paul
-- 
Paul Lynch
P & L Systems                   (NeXTmail) paul@seer.demon.co.uk
Tel: (0494)671501                      paull@cix.compulink.co.uk
Fax: (0494)680228                       76711.451@compuserve.com
Newsgroups: comp.sys.next.software
From: ntomczak@vega.math.ualberta.ca (N Tomczak-Jaegermann)
Subject: Re: TeX disk space inefficiencies. (save ~2 meg)
Organization: University Of Alberta, Edmonton Canada
Date: Sat, 7 Nov 1992 22:12:29 GMT

fermat@fermat.dartmouth.edu (Michael Glenn) writes:

>After installing amstex and amslatex on my NeXT, I discovered several  
>additional files that were not needed.  Namely duplicate copies of files  
>that could easily be replaced with symbolic links.

>In /usr/lib/tex/formats:

>splain.fmt == slitex.fmt (576k)
>lplain.fmt == latex.fmt  (496k)
>plain.fmt  == tex.fmt    (288k)

>In /usr/bin:

>latex  == tex (184k)
>slitex == tex (184k)
>virtex == tex (184k)

>/usr/bin/tex apparently looks at what command line command was used to  
>execute it to determine which .fmt file is loaded in.

>I've removed latex, slitex, virtex, splain.fmt, lplain.fmt, and plain.fmt,  
>and replaced them with symbolic links, a total savings of 1912k, almost 2  
>meg!

All these 'extra' files were hard links.  You managed to replace
them with symbolic links actually using for this slightly more
disk space then before.

They are there because of way TeX is configured on Unix.  If you
call it as 'latex' it executes 'virtex' with a format file 'latex.fmt'.
Similar deal is with other formats (you may make your own).
A default format is 'plain.fmt'.  Names like 'plain.fmt', 'lplain.fmt'
and so on are needed for compatibility with other installations.

If you search for savings in disk space in your TeX font installation
look rather at bitmap images of fonts in /usr/lib/tex/fonts/pk.
For example, if you have only 400dpi printer you may throw away
from your disk all 300pk fonts and their magnifications.   This will
cut disk usage considerably.  More radical step consist of throwing
away all pk's and generating fonts (NeXT TeX is doing that
automatically) only when they are needed.  After a while you will end
up only with bitmaps for fonts YOU are using.  Since this takes time
you may want to initialize the whole process running through TeX
as an overnight batch job a set of "typical" - for your installation -
texts and continuing from that point.

Other method consist of replacing all bitmap fonts with their PostScript
equivalents from Y&Y.

   Michal Jaegermann
   ntomczak@vega.math.ualberta.ca
From: millier@inttech.com (Marc Millier)
Newsgroups: comp.sys.next.software
Subject: Converting AutoCAD files to something for the NeXT...
Date: 7 Nov 92 00:05:56 GMT
Article-I.D.: inttech.1992Nov7.000556.7518
Organization: Interactive Technology, Inc. - Beaverton OR

Help!

We are looking for import/export filters-tools-utilities for 
AutoCad DXF files - on the NeXT (obviously).  The application is 
for a GIS/LIS to import map data and turn it into eps or tiff so 
it can be dressed up for presentation.  The data will come off of
the network (from Sun sparcs running ARC/INFO).

It would be even better to have ARC/INFO or ARC/VIEW on the NeXT, but
we do what we can.  Does anybody know if ESRI has any plans in that
direction?

Thanks in advance
-Marc

----------------------------------------------------------------------------
Marc Millier                                        Senior Software Engineer
Interactive Technology, Inc.             UI Product Development & Consulting
The NeXT Value Added Dealer for Oregon
voice:  +1-503-644-0111                                fax:  +1-503-644-8494
Internet: millier@inttech.com        UUCP: ...!{onion|uunet}!inttech!millier
Snail Mail: 9610 SW Sunshine Ct #700, Beaverton, OR 97005 		  
Newsgroups: comp.sys.next.software
From: serge@princeton.EDU (Serge J. Goldstein)
Subject: speaking on the next
Originator: news@nimaster
Keywords: speak talk sound 
Organization: Princeton University
Date: Mon, 9 Nov 1992 21:46:38 GMT



I'm looking for some (free?) software that will speak ascii text on the Next.   
I've seen "saystring" on the archives, but I was hoping to find something that  
doesn't require us to build soundfiles for every word.  Thanks,
Serge J. Goldstein

Newsgroups: comp.sys.next.software
From: marcel@opal.cs.tu-berlin.de (Marcel Weiher)
Subject: Re: TeX disk space inefficiencies. (save ~2 meg)
Organization: Techn. University of Berlin, Germany
Date: Sat, 7 Nov 1992 22:51:24 GMT

fermat@fermat.dartmouth.edu (Michael Glenn) writes:


>My second attempt at posting this.  Dunno if this is old news, but...

Too bad you succeeded :-)

>After installing amstex and amslatex on my NeXT, I discovered several  
>additional files that were not needed.  Namely duplicate copies of files  
>that could easily be replaced with symbolic links.

[... gives example of tex,latex, slitex ...]

>/usr/bin/tex apparently looks at what command line command was used to  
>execute it to determine which .fmt file is loaded in.

It does.

>I've removed latex, slitex, virtex, splain.fmt, lplain.fmt, and plain.fmt,  
>and replaced them with symbolic links, a total savings of 1912k, almost 2  
>meg!

Oh the joys of UNIX!  In the original distribution they are HARD LINKS,
meaning several directory entries referring to the same inode (actual
file data).  How about a good introductory UNIX text?  :-)

Marcel
Newsgroups: comp.sys.next.software
Subject: Re: Telephone Message DELIVERY / Answer Center
From: scott@nic.gac.edu (Scott Hess)
Date: 12 Nov 92 00:09:33
Organization: Gustavus Adolphus College
In-reply-to: gcolello@biosphere.Stanford.EDU's message of Wed, 11 Nov 92 21:18:55 GMTLines: 51

In article <1992Nov11.211855.6278@leland.Stanford.EDU>,
	gcolello@biosphere.Stanford.EDU (Greg Colello) writes:
>I work for the Green Party of California. We have faced a problem
>that I'm sure many underfunded groups encounter: internal communications
>(ie.  delivering messages inexpensively to our local members).
>
>I figure the only solution is the telephone, since an unlimited
>local calls line can be had for $15/month; while US Mail can run
>$hundreds/month. Now comes the rub. A simple dial-up a central
>number and listen to the recorded message (like movie theatres)
>doesn't work, because a lot of people simply don't make the call.
>On the other hand many people are willing to receive a recorded
>message called to their phone.  Especially if it's at a certain
>hour and their message machine will intercept it. Delivering messages
>by phone is too hard and unreliable for human beings to do (as in
>a "human phone banking/tree" system).

This is a problem many organizations have, including telemarketing
organizations.  And, your idea is a good idea.  That's the problem
- the idea is _too_ good for telemarketing organizations.  Automated
calling machines of the sort you describe are illegal in many states
because it makes things too easy for those annoying telemarketers
to just feed databases of numbers to computers and let them loose
calling people.  A computer is _loads_ cheaper than a bank of
operators.

This isn't to say that such legislation is highly prevalent.  All
I know is that this is how things work in Minnesota.  Even then,
there _may_ be loopholes for certain situations.  For instance, in
your situation you could have people give you written permission
to have the computer call them and leave messages, which means that
you've removed the major complaint about such systems (the harrassment
sort of concerns).  But, the lucrative bucks would be in selling
such systems to telemarketers, who'd be paying thousands of dollars
for them whereas I suspect your underfunded group will not be
willing to pay.  And the package _is_ almost exactly the same
(precisely, anything that does what you want done could also be
used for automated telemarketing stuff).

[Note that the above applies only to _calling_ machines.  You can
set up automated answering machines to your heart's content, and
it's not a problem - people can easily choose not to call the
machine if they don't like it.  But, if the machine is calling
_you_, then it can be a problem ...]

Later,
--
scott hess <shess@ssesco.com>     <I will not spin the turtle -Bart Simpson>
12901 Upton Avenue South, #326  Burnsville, MN 55337 (612) 895-1208 Anytime!
  * ... like a big church choir with all it's members' mouths wide open, *
               * singing silence   -Blood Music, Greg Bear *
Newsgroups: comp.sys.next.software
From: paul@seer.demon.co.uk (Paul Lynch)
Subject: Re: System 2.2 d/n write/format DOS floppies!
Organization: P & L Systems
Date: Sun, 8 Nov 1992 22:14:40 GMT

In article <1992Nov8.180850.6211@news2.cis.umn.edu>  
walt@molbio.cbs.umn.edu (Walter Sauerbier) writes:
> Our new color NeXTstation ha great problems writing to MS-DOS formatted 
> floppies.  Even if this subject has been beaten to death already, it is
> a very current, very real unsolved problem for us.  
> 
> Problems:
> 1) You can't initialize an unformatted disk to MS-DOS format unless you
>   (deviously) first insert an MS-DOS disk, select it, then manually  
eject
>   that disk and supplant it with your unformatted one.  I am  
uncomfortable 
>   with this because it's like unmounting/mounting a filesystem without  
Mach's
>   knowledge.  Can this cause any harm?
> 2) 1.44MB MS-DOS floppie (formatted on an MS-DOS machine) are often un-
>   writeable.  When I try to copy to them, I get an "Invalid Argument"  
error
>   in the process inspector! The disk write-protect is not the problem;  
so
>   what the hell IS*?
> 3) 'Successfully' formatting MS-DOS diskettes, and writing files to them 
>   often yields diskettes that appear EMPTY to MS-DOS machines.  I am  
writing
>   filenames in the proper MS-DOS format (xxxxxxxx.xxx).  


1) Congratulations on finding a way to do this.  I couldn't.

2)  This is a "well-known" bug with 2.2, and only with 2.2.  2.1 and 3.0  
are both better.  Interestingly enough, you could copy long filenames to  
MS-DOS floppies with 2.1, and they would be case-converted and truncated  
to fit.  With 3.0, you must first rename your files to be lower case and  
fit within the DOS 8.3 limits.  If anyone knows how to beat this, I would  
be very grateful.

3) There were several similar problems with 2.1 and 2.2; all I can say  
about 3.0 is that they seem less frequent so far.

Paul
-- 
Paul Lynch
P & L Systems                   (NeXTmail) paul@seer.demon.co.uk
Tel: (0494)671501                      paull@cix.compulink.co.uk
Fax: (0494)680228                       76711.451@compuserve.com
Newsgroups: comp.sys.next.software
From: pfkeb@kaon.SLAC.Stanford.EDU (Paul F. Kunz)
Subject: Re: Faster 3.0 on Color Machine via dwrite
Organization: Stanford Linear Accelerator Center
Date: Sun, 8 Nov 1992 04:22:10 GMT

In article <5795@rosie.NeXT.COM> aozer@next.com (Ali Ozer) writes:

   One final note... Flushing 2-bit windows with alpha to a 12-bit screen is
   rather slow, and I believe this is what causes Frame to run real slow
   on a NSC when the window depths are limited. If you don't limit the
   depth, Frame's windows become 12-bits (with alpha), and in that case the
   flush is much faster.

   Ali, Ali_Ozer@NeXT.com


I don't limit the depth (at least I did nothing to limit it), but
FrameMaker runs real slow on my NSC after it is launched.  To speed it
up, I change some characters to Red, then back to black, thus,
according to Ali's explaination, promotes the windows to 12 bits.
Is there an easier way?









--
Paul F. Kunz	pfkeb@slac.stanford.edu (NeXT mail ok)
Stanford Linear Accelerator Center, Stanford University
Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587
From: lones@lones.mit.edu (Lones A. Smith)
Subject: CLIPBOARD app for the NeXT???
Organization: Massachvsetts Institvte of Technology
Date: Wed, 11 Nov 1992 17:15:27 GMT

Hi,
     Is there a simple app for the NeXT that acts as a Mac-style clipboard  
to post simple messages to oneself?

--
Lones A. Smith
Department of Economics
MIT E52-252C
Cambridge MA 02139
v-mail: (617) 253-0914
e-mail: lones@lones.mit.edu  (NeXT mail or the garden variety stuff)
Newsgroups: comp.sys.next.software
From: wmagro@uiuc.edu (William Magro)
Subject: Re: Why is NewsGrazer so slow?
Organization: University of Illinois at Urbana
Date: Wed, 11 Nov 1992 21:02:58 GMT

In article <19110@ucdavis.ucdavis.edu> stuarts@jeeves.ucdavis.edu (Stuart  
Staniford-Chen) writes:
>
>I have started using NewsGrazer lately.  It's lovely to use, except that  
>it's so darned slow.  I can understand that things like fetching articles
>from the nntp server would be slow.  However, just hitting a menu option  
>to get a submenu takes 5 to 10 seconds.  Editing this post is agony  
>because it is so slow to update the window.  It cannot keep up with my  
>typing and loses a lot of what I input.  
Hmm.  I use news grazer on a similar setup to yours (16M ram, 25MHz  
68040), and I don't have any problems with speed.  Perhaps your machine is  
thrashing because you are using too much swap space?  Just a thought.

--
William Magro                                       NeXTMail welcome
wmagro@uiuc.edu
Newsgroups: comp.sys.next.software
From: gcolello@biosphere.Stanford.EDU (Greg Colello)
Subject: Telephone Message DELIVERY / Answer Center
Organization: DSO, Stanford University
Date: Wed, 11 Nov 92 21:18:55 GMT

I work for the Green Party of California. We have faced a problem that I'm  
sure many underfunded groups encounter: internal communications (ie.  
delivering messages inexpensively to our local members).

I figure the only solution is the telephone, since an unlimited local  
calls line can be had for $15/month; while US Mail can run  
$hundreds/month. Now comes the rub. A simple dial-up a central number and  
listen to the recorded message (like movie theatres) doesn't work, because  
a lot of people simply don't make the call. On the other hand many people  
are willing to receive a recorded message called to their phone.  
Especially if it's at a certain hour and their message machine will  
intercept it. Delivering messages by phone is too hard and unreliable for  
human beings to do (as in a "human phone banking/tree" system).

Thus what is needed is a computerized phone message delivery system that  
can also take incoming calls and play the same message (for those people  
who don't want their privacy intruded by computerized message delivery).

This system must minimally be able to:

1. Record a voice message. Obviously human voice recording is a minimum.  
However, being able to type in a message and have the computer generate a  
GOOD voice synthesis would be realy useful. This is because most people  
find recording a message an intimidating experience requiring many "takes"  
to get it right.

2. Take a list of phone numbers. Be able to recognize numbers outside the  
local free calling area and reject them.

3. Have an optional time/date-range field to go with the telephone number  
to custom control message delivery at specific time/date-ranges (the  
message subscriber's choice).

4. Be able to take at least two phone lines. One for incoming and one for  
outgoing calls.

5. Have a touch-tone menu up front that allows the user to choose between  
hearing the latest announcement/news, leaving a long message, or leaving a  
short message (telephone number changes or subscribe/unsubscribe for the  
auto message delivery subsystem).

6. A fairly sophisticated analyzer in the message delivery subsystem to  
detect whether the message has been delivered reliably or not. I suspect  
this is the tough part.

-----------------------------------------------------------------
Man, a software package like the above should have tremendous sales  
potential. Does it exist on the Next already? Most local groups (like  
ours) have somebody with a Next (like me). So the software would be the  
only major exspense (wouldn't it?).

-----------------------------------------------------------------
Greg Colello
Carnegie Institution, Department of Plant Biology
Stanford University
gcolello@biosphere.stanford.edu
Newsgroups: comp.sys.next.software
From: walt@molbio.cbs.umn.edu (Walter Sauerbier)
Subject: System 2.2 d/n write/format DOS floppies!
Summary: I seek the capacity to format/write to DOS floppies!
Keywords: DOS, Floppies
Organization: University of Minnesota
X-Newsreader: Tin 1.1 PL5
Date: Sun, 8 Nov 1992 18:08:50 GMT

Our new color NeXTstation ha great problems writing to MS-DOS formatted 
floppies.  Even if this subject has been beaten to death already, it is
a very current, very real unsolved problem for us.  

Problems:
1) You can't initialize an unformatted disk to MS-DOS format unless you
  (deviously) first insert an MS-DOS disk, select it, then manually eject
  that disk and supplant it with your unformatted one.  I am uncomfortable 
  with this because it's like unmounting/mounting a filesystem without Mach's
  knowledge.  Can this cause any harm?
2) 1.44MB MS-DOS floppie (formatted on an MS-DOS machine) are often un-
  writeable.  When I try to copy to them, I get an "Invalid Argument" error
  in the process inspector! The disk write-protect is not the problem; so
  what the hell IS*?
3) 'Successfully' formatting MS-DOS diskettes, and writing files to them 
  often yields diskettes that appear EMPTY to MS-DOS machines.  I am writing
  filenames in the proper MS-DOS format (xxxxxxxx.xxx).  

It's hard to remain calm (and avoid ending every sentence with an indignant
string of exclamation marks) when confronted with this kind of random func- 
tionality; so I ask:
  
Is this a hardware or a software problem?  
Is there an upgrate/utility that can consistently deal with MS-DOS floppies?  
Are there utilities that can read/write Macintosh or Amiga diskettes?

			-Mucho obliged
			Arnim Sauerbier
			Institute of Human Genetics
From: shmuli@techunix.technion.ac.il (Shmuel Browns)
Newsgroups: comp.sys.next.software
Subject: X Window client binaries?
Date: 10 Nov 92 08:22:07 GMT
Organization: Technion, Israel Institute of Technology


    I've had quite a number of enquiries from people here at the university
about running X Windows on a NeXT. I have demoed co-Xist for them but would
like to be able to show them other examples of X clients. Has anyone compiled
sample X clients for the NeXT and be willing to make them available? (I'd do
it myself but I only have the co-Xist demo so far).
    Thanks,
       Shmuel
       Shmuel
 ---
Shmuel Browns, NeXT, Macintosh & Unix Technical Support
  Director YIN - Israel NeXT user group
  INTERNET: shmuli@shum.cc.huji.ac.il  FAX: by arrangement
  VOICE: +972-2-610785   SNAIL: 24 Hazefira, Jerusalem 93102 ISRAEL
Newsgroups: comp.sys.next.software