HDTenEightyP/NetNews huggingface dataset:
From: rfinch@water.ca.gov (Ralph Finch)
Newsgroups: comp.sys.sgi
Subject: FAQ? How to compile GNU Emacs?
Date: 30 Jul 92 22:25:29 GMT
Distribution: na
Organization: Calif. Dept. of Water Resources

OK, sorry to ask this, which must be a FAQ, but:::

What tricks are there for compiling GNU Emacs on an Iris Indigo?  A
simple-minded edit of the config.h file with s-irix4-0.h and
m-iris4d.h didn't work (version 18.57).

I know something about Emacs.  I know nothing about SGI machines,
having used Suns for years.  I am stuck with the job of getting Emacs
running on this machine which will not even be mine :-(

--
Ralph Finch			916-653-8268
rfinch@water.ca.gov		...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWR
From: tohanson@gonzo.lerc.nasa.gov (Jeff Hanson)
Newsgroups: comp.sys.sgi
Subject: Re: Reality Engine performance
Date: 23 Jul 92 16:43:03 GMT
Organization: NASA Lewis Research Center

In general I agree with Martin.  Scientific visualization in general,
and CFD visualization in particular are polygon bound and not texture
bound.  We don't use the bitplanes we have now, so the extra ones
in the RealityEngines aren't going to do us any good.  Here is what
I think a good ViSC machine would be -

1. As high a polygon rate as possible.
2. As much screen resolution as possible.  This is important for highly
   detailed grids and for seeing things that differ widely in size in
   physical space coordinates.
3. Antialiasing for lines and polygons.  The VGX Accumulation Buffer is
   a good example of this since it is progressive.  That is, you get
   maximum responsiveness when interactive (moving) and you get a better
   picture when you stop.
4. Double buffer for 24 bit (or higher) color with 12 bit colormaps available.

I'll be a SIGGRAPH next week so if anyone wants to discuss this, look for me. 
-- 
---------------------------------------------------------------------------
 Jeff Hanson - Scientific Graphics Programmer and Workstation Administrator
 Sverdrup Technology, NASA Lewis Research Center Group
 NASA Lewis Research Center, MS 86-4, Cleveland, Ohio 44135
 Telephone - (216) 433-2284  Fax - (216) 433-2182
 tohanson@gonzo.lerc.nasa.gov	-   ViSC: Better Science Through Pictures
Newsgroups: comp.sys.sgi
From: tarun@psyclops.psyc.queensu.ca (Tarun Kripalani)
Subject: BYU format
Organization: Dept. Of Psychology,  Queen's University,  Kingston
Date: Thu, 23 Jul 1992 16:27:13 GMT

I have recently heard something about a BYU format for image 
data. However, I don't know of a source. Has anyone out 
there have any experience with it? How does one use it?
TIA.
-- 

Tarun Kripalani (of Wounded Knee and now Wounded Shoulder)
e-mail:   tarun@psyclops.psyc.queensu.ca
Dept. of Psychology, Queen's University,
Kingston, Ontario.
Newsgroups: comp.sys.sgi
From: bryan@pi.eai.iastate.edu (Bryan Manske)
Subject: Re: Need help with /usr/etc/lpd...
Reply-To: bryan@pi.UUCP (Bryan Manske)
Organization: EAI, Iowa State University, Ames, IA
Distribution: na
Date: Wed, 22 Jul 1992 17:02:39 GMT

In article <1992Jul22.160433.10081@news.iastate.edu> write:
>
>...and DOS machines over ethernet.
>
>Vitals on the whole mess:
>
>-Personal Iris 4D/35 running 4.0.1
>-NCSA TELNET ~ CLARKSON UNIVERSITY TCP PACKAGE  (CUTCP/CUTE) (for DOS)
>-A fleet of various SGI rendering monsters already properly printing
> via network printer connection to the PI using lp.
>-One slightly frazzled individual (Me) trying to keep all of these
> wonderful toys working and playing well with each other.

I forgot to ask if SGI supports the Berkeley Line Printer protocol.
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^           

This is perhaps my sticking point. Yes?

>Thanks. AGAIN.

Bryan


-- 
Bryan Manske  (515) 296-9908        . Images of sorrow,
Engineering Animation, Inc.         . pictures of delight,
bryan@pi.eai.iastate.edu            . things that go to make up a life...
#include <caveat_opinion.h>         . 
#include <standard_disclaimer.h>    . 	         Home by the Sea, Genesis
From: frank@marvin.contex.com (Frank Perdicaro)
Newsgroups: comp.sys.sgi
Subject: Re: Turbo Graphic board swap?
Date: 28 Jul 92 15:19:10 GMT
Organization: Xyvision Design Systems

In article <1529ebINNr4c@agate.berkeley.edu> dasilva@mies.ced.berkeley.edu (Ruieta Da Silva) writes:
>Does anyone know how to take a turbo graphics option board from
>one 25TG and put it in another 25? I hear that there are some
>resistors to cut, etc. Also how would you pull it out?
>
>Thanks,
>
>Deanan

Contrary to Dave O's note, some early PIs do not have the required,
soldered on tapped standoffs on the main graphics board and thus
cannot get a turbo upgrade without a swap of the graphics board.  This
is unlikely, but has happened more than once to me.

Also, there are combinations of prom, operating system, and turbo
graphics revisions that cause the bottom line of the screen to flicker
wildly in double buffer mode.  This too is unlikely, but happened to
me -- got my own revision of IRIX to fix this.

In general, though, its a straigh forward swap.  Just be sure not to
bend those ( many many ) pins, and not to break those resistor packs 
while removing the RE chip.
-- 
	 Frank E Perdicaro, Systems Admin, etc.		Xyvision Color Systems
      Legalize guns, drugs and cash...today.		101 Edgewater Drive
   inhouse: frank@marvin, x5572				Wakefield MA
outhouse: frank@contex.com, 617-245-4100x5572		018801285
From: gray@celia.UUCP (Steve Gray)
Newsgroups: comp.sys.sgi
Subject: ELAN graphics problem
Date: 22 Jul 92 21:55:17 GMT
Reply-To: celia!gray@usc.edu (Steve Gray)
Organization: Rhythm & Hues, Inc., Hollywood


I am having a problem running an application which used to work fine on a
Crimson with GR2-Elan graphics.

One of the things that happens (sometimes... the rest of the time I get
horrible flashing stuff when trying to draw in the overlay planes) is the
window manager (and graphics subsystem?) crashes.  I get these messages
in the SYSLOG:

Jul 22 13:13:26 max unix: GR2FIFOHandler: TIMEOUT (FIFO still not below low water mark)!
Jul 22 13:13:26 max unix: MG1WAIT: mg1 status reg:0xFFFF16B8
Jul 22 13:13:26 max unix:
Jul 22 13:13:26 max unix: WARNING: Graphics error: GE PC = 0x1E3
Jul 22 13:13:26 max unix:


Can anybody suggest what I might be doing that is now not allowed?  Or is this
a bug in the Elan graphics?

Thanks!


P.S.  I don't want to put a call into the TAC until I've put a reasonable
      ammount of effort into it myself... so I don't end up being too much
      of a pest!
From: sundar@fiber-one.ai.mit.edu (Sundar Narasimhan)
Newsgroups: comp.sys.sgi
Subject: even faster graphics
Date: 21 Jul 92 16:26:04 GMT
Reply-To: sundar@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory

I have an application that currently renders using the standard
GL bgnpolygon().. endpolygon() calls with lights/shading. 
I'd like to find out ways of speeding this up (I have LOTS of polygons).
I'd like to know 

a. what speed up is possible going to graphical objects?
b. is there a way of storing and restoring computed images that
   is faster?

Thanks.
From: senseman@ricky.brainlab.utsa.edu (David M. Senseman)
Newsgroups: comp.sys.sgi
Subject: IDL -- Anyone Familar With It?
Date: 27 Jul 92 02:56:09 GMT
Organization: University of Texas at San Antonio

A colleague of mine recently received an Indigo and wanted to
start writing data analysis programs using a fairly portable
and high-level language. The data involves optical measurements
of nerve cell activity in simple invertebrate brains (ganglia).
On a suggestion, he has started using IDL (Independent Data Language?)
and seems pleased with it so far.

I'm not familar with IDL, so I would appreciate hearing anything
good or bad about the product. How similar or different is it from
SGI's Explorer or Inventor products? Since it appears to be X (Motif?)
based, could one use IDL with OpenGL or is that still an open question ;-)
How much overhead does IDL extract from the system? My colleague
would like to generate real-time animations and my concern is that
IDL might slow things down much more than writing code in straight gl.

Thanks :)


-- 
"Is this the party to   |  David M. Senseman  (senseman@lonestar.utsa.edu)
 whom I am speaking?"   |  Brain Research Laboratory
          --Ernestine   |  The University of Texas at San Antonio
Newsgroups: comp.sys.sgi
From: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
Subject: Re: Getting GL to X terminals
Reply-To: ercolessi@uimrl7.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Mon, 27 Jul 1992 18:03:11 GMT

In article <31546@adm.brl.mil>, andersen@marvin.ama.ttu.edu (Kim Andersen) writes:
|>In article <1992Jul22.230358.3686@microunity.com>, jsw@microunity.com
|>(Jeff Weinstein) writes:
|>>
|>> I think what would be really useful in this discussion is explanation
|>> from customers as to how they expect to use GL rendering to X
|>> terminals.
|>>
|>I have several IRISes.  I have more than several researchers who need
|>to use these machines for molecular modeling.  I have many academic-
|>domain LARGE programs for molecular modeling.  I cannot even begin to
|>convert these from GL-code to X-code.  If I could run these programs 
|>UNCHANGED on X-terminals (yes, I know it would be slow), every one of
|>our researchers could have his own X-terminal to work on, rather than
|>waiting in line for an IRIS.

I have GL codes that do 2D graphics.  They were written in GL essentially
because development time is much less than using X for people (like me)
not familiar with X protocols etc., and because a good GL engine can
comfortably animate them at ~10 frames/sec
The possibility to run them on X terminals would be very welcome,
and in this case speed would be a real issue only when animation is
involved.  

Moreover, in my particular case to go in front of the Iris implies
an intercontinental flight ...
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
ercolessi@uimrl7.mrl.uiuc.edu           |   furio@sissa.it
From: karlton@fudge.asd.sgi.com (Phil Karlton)
Newsgroups: comp.sys.sgi
Subject: Re: Need help getting GL over net to Macx
Date: 23 Jul 92 23:48:20 GMT
Reply-To: karlton@sgi.com
Organization: Silicon Graphics, ASD


  In article <gln.711904030@brutus>, gln@iti.org (Glen Niebur) writes:

    Granted SGI should have probably opened up the dgl protocol before
    now.  Even IBM doesn't have dgl yet, even though they have gl.  I
    think many companies will implement dgl and gl now that they have a
    chance, and then the X consortium will be compelled to follow.

I'd like to clear up an apparent misconception. SGI is not widely licensing
the current dgl protocol. That protocol is net generally useful; for
one the code for the dgld (the daemon that interprets the protocol) is
not licensed at all. Dgl does support remote rendering when the display
machine is an SGI platform but that is as far as it goes.

The OpenGL GLX protocol is generably licensable and works using the
standard X extension mechanisms. The speicification and client side
implementation is available with any level of OpenGL licensing.

    > They want you to WAIT until everyone (or I guess anyone) implements
    > the proposed GL extensions to X.  Which is fine, whenever that
    > happens, and even then, what about the 300,000,000 or so X-Terms
    > which we users ALREADY own?

I don't believe that there are 300,000,000 existing X terminals. However
most X terminals can be used in a mode where the X server is downloaded
to the terminal when it is powered on. (Some, admittedly, only work with
proms in the X server. Of course, those can't even be upgraded to newer
versions of the X server when they are made available from MIT.) If your
terminal manufacturer has licensed OpenGL, then your downloaded server
will implement the GLX extension.

    You could just get a the new X server from MIT and you would be on
    your way.

Even if MIT were to get the university license ($500, I believe) for
OpenGL, it would not be free to redistribute sources.

In article <1992Jul23.172114.20820@CSD-NewsHost.Stanford.EDU>,
		philip@ziggy.stanford.edu (Philip Machanick) writes:

    One thing that would be really useful - being able to run programs
    like the zip editor and edge (though I imagine the easier solution
    would be to rewrite them for X).

SGI sells a very nice debugger that uses X for its rendering.

    Also, though generating complex images in real time including
    animation may not be practical, it would be useful to be able to
    read showcase documentation on an X screen (even if the occasional
    picture may take a long time to render).

There is a chance that Showcase may be ported to an X based toolkit.
(No promises implied.) 3D images would probably not be available for
viewing in the document if the server did not have the GLX extension.

PK
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: "inst" setting owner=9999
Date: 27 Jul 92 19:28:48 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <GREENDOG.92Jul26222935@max.physics.sunysb.edu> greendog@max.physics.sunysb.edu (Michael D Fischer) writes:

| I've just tried to re-install my diskless share tree with "clinst" and
| inst seems to be making most files owned by 9999 and group 9999!  I am
| running 4.0.1, and did this just two weeks ago and it worked fine!
| Any idea what could cause this??  Some of the files are "root/sys" but
| most are "9999/9999" when I do an "ls -l".

inst sets files mode 9999 when it can't find the UID (they are
stored as strings in the *.idb files, not numbers) that matches
the owner in the idb file.  Sounds like  you have a problem
with your password file on the server, or perhaps an NIS
problem, although all those users should be local (non-NIS).

The most common user name this happens with is 4Dgifts for
people who haven't merged the passwd file after upgrading
to 4.0.1.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: VME differences between 4D/20 & 4D/35?
Date: 29 Jul 92 22:46:05 GMT
Distribution: na
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Jul29.151301.25998@eagle.lerc.nasa.gov> fsset@bach.lerc.nasa.gov (Scott Townsend) writes:
| I have a machine here that was recently upgraded from a 4D/20 running 3.3.(2?)
| to a 4D/35 running 4.0.1.  It has a Bit3 VME-VME adaptor in it used to
| connect to an external VME bus.
| 
| Prior to the upgrade things had been running fine.  I'm now experiencing
| fairly odd behaviour which might be related to the VME implementation
| in the 4D/35.  "Odd behaviour" includes things like write(2) returning -1
| _and_ setting errno to -1 (fixed by using memcpy from VME to local buffer
| and then writing the local buffer to the socket), SIGBUS on valid VME
| addresses in an almost repeatable fashion, etc.

Any VME drivers you had running under 3.3 need to be rebuilt to run under 4.0.
If all the boards are just memory mapped, with no VME driver at all, there
shouldn't be a problem.  The IP6 and IP12 VME addresses are all in the
same ranges.

| Is there anyone out there who could tell me what (if anything) has changed
| in the VME implementation, or could point me to documentation?
| 
| NOTE: there's no kernel driver code in question here, the VME adaptor merely
|       supplies a window into the remote VME bus via a suitable mmap() call.
|       Ordinary user-level code then uses the window to do reads & writes
|       of remote memory.  The remote system does NOT access the Iris or pass
|       any interrupts to it.

But does it do things on the VME bus that might affect the 35?  That is,
does it use the VME interface for anything other than the slave accesses
from the 35?  If so, there could be some problems.  The actual hardware
VME interface in the 35 is completely redone from the 20, and it may be
more sensitive to strange VME bus states than the 20 (or less, it really
hasn't come up as an issue before for slave devices that are mmap'ed).
VME PIO is slightly faster on the 35 than on the 20/25.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: MIKE@scripps.edu (Mike Whittaker)
Newsgroups: comp.sys.sgi
Subject: rmt and VMS machines
Date: 22 Jul 92 18:14:22 GMT

I have a 4D/35 with an attached DAT drive for backups. I also have a
VMS machine running Multinet 3.1. Multinet provides rmt functions,
although VMS backup is not supported on 4mm drives. I was complaining to
TGV (multinet's company) about having to use this crummy TK50 drive for
backup when I had a DAT just sitting there, and they told me IRIX 4.0.5
*should* fix my problems, allowing VMS backup to work correctly with rmt.
Anybody able to comment? Thanks.

Mike Whittaker
Department of Cell Biology
The Scripps Research Institute
mike@scripps.edu

	Facts all come with points of view
	Facts don't do what I want them to
		Talking Heads
Newsgroups: comp.sys.sgi
From: andrey@cco.caltech.edu (Andre T. Yew)
Subject: Re: VGXT vs. Reality Engine
Organization: California Institute of Technology, Pasadena
Date: Thu, 23 Jul 1992 19:05:01 GMT

grege@chopin.asd.sgi.com (Greg Estes) writes:

>New texture mapping modes, including bicubic interpolation and
>	3D textures

	By 3D textures, do you mean bump-mapping or volume
textures (Perlin textures)?

--Andre

-- 
Andre Yew                             andrey@tybalt.caltech.edu (131.215.48.100)
From: casey@anchovy.wpd.sgi.com (Casey Schaufler)
Newsgroups: comp.sys.sgi
Subject: Re: shadow passwords on Indogo NEEDED NOW.
Date: 29 Jul 92 15:23:12 GMT
Reply-To: casey@anchovy.wpd.sgi.com (Casey Schaufler)
Organization: sgi

Shadow passwords will be available in an upcoming release.
No dates promised.

If you have real serious security problems, you might
consider Trusted IRIX/B, which is in evaluation at B1.
That may be swatting flies with a sledge hammer, though.

	-casey
Newsgroups: comp.sys.sgi
From: jrb@jrb.larc.nasa.gov (James R. Burley II)
Subject: Re: SGI sales
Organization: NASA Langley Research Center, Hampton, VA  USA
Date: Thu, 30 Jul 1992 20:38:53 GMT

In article <1992Jul30.131454.4880@news.yale.edu>, szewczak@neutron.chem.yale.edu (Alexander Szewczak) writes:
|> flash@austin.lockheed.com (James W. Melton) writes:
|> : The question is: is this normal procedure for SGI? Miss a quota and
|> : hit the road? Does this imply anything about SGI's current or
|> : future financial picture? I really need a local sales rep. We are
|> : in the midst of a pitched evangelism campaign and I can't do SGI's
|> : sales job for them. Calling some guy in California won't cut it.
|> : What is SGI's policy for local sales reps?
|> 
|> The question is, does SGI *have* a policy for local sales reps? Ours has to
|> be beaten about the head with bags of money before he'll even return calls,
|> even to groups who've purchased dozens of machines already. Don't even think
|> about getting info about chump-change things like CPU upgrades. Is there a
|> procedure for impeachment?
|> 

My guess is a call to the corporate office in Mt. View would "eliminate" the
problem. Our sales rep., Mr. Brian Hahn, has done an outstanding job of supplying
information even when there is no sale in it for him. Moral: there are good sales
reps and bad sales reps.....you've got the latter.

|> --
|> | Dave Schweisguth   Yale MB&B & Chemistry   Email: dcs@neutron.chem.yale.edu |
|> | Lab phone: 203-432-5208      Fax: 203-432-6144     Home phone: 203-624-3866 |

-- 
---------------------------------------------------------------------------
 James R. Burley II                         NASA Langley Research Center
 VOICE: 804-864-2008  FAX: 804-864-8294   MS 152E, Hampton, Va. 23665-5225     
---------------------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: bryan@pi.eai.iastate.edu (Bryan Manske)
Subject: Re: Audio Questions
Reply-To: bryan@pi.UUCP (Bryan Manske)
Organization: EAI, Iowa State University, Ames, IA
Distribution: na
Date: Sun, 26 Jul 1992 22:25:26 GMT

In article <1992Jul26.220045.8227@news.iastate.edu> bryan@pi.eai.iastate.edu (Bryan Manske) writes:
>In article <nobregg@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>>In <1992Jul25.163827.22304@news.iastate.edu> bryan@pi.eai.iastate.edu (Bryan Manske) writes:

[stuff deleted]

Okay, I've been reading some more.  I get it.  16 bits per channel on
the digital audio, etc,etc.


>Thanks Dave, Your a God.

EXPLANATION AND CORRECTION:

Statement: Dave is a God.  Explanation: I posted this on Saturday, I believe,
           and had his response in about an hour.  The fact that he is working
weekends, and crunching news at that, is incredible.
Now that's service.


Correction:  Most SGI-Netters certainly qualify for saint-hood if not
             god-hood.  I recieved several VERY USEFUL tidbits of
information.  (Okay, so I did find 1 particular item of use after rummaging
around in the manuals and man pages for over an hour and fifteen minutes.)
SINCERE THANKS TO ALL WHO REPLIED.


Suggestion:  For the love of sanity, Someone PLEASE compile a comprehesive
             index for the hardbound manual sets with each (major) system
             release.


Thanks All.

Bryan Manske

-- 
Bryan Manske  (515) 296-9908        . 
Engineering Animation, Inc.         .         "Programmer terminated
bryan@pi.eai.iastate.edu            .           at users request."
#include <caveat_opinion.h>         . 
#include <standard_disclaimer.h>    .                           Dave S.
Newsgroups: comp.sys.sgi
From: scotth@hoshi.corp.sgi.com (Scott Henry)
Subject: Re: question regarding uucp/(dialout/dialin modems) on SGI's
Organization: Silicon Graphics Inc, Mountain View, CA
Date: Thu, 30 Jul 1992 21:20:18 GMT


>>>>> In article <26028@life.ai.mit.edu>, sundar@fiber-one.ai.mit.edu (Sundar Narasimhan) writes:

sundar> Hi, I just set up outgoing uucp from our SGI machine running
sundar> IRIX 4.0.3.  This seems to work fine for outgoing calls, but
sundar> I'd like to receive incoming calls too. So, my question is: a.
sundar> Is there a script that automatically edits inittab to do the
sundar> right thing?  and reverts it to what it was once its done?
sundar> Ideally, I'd like the default mode to be with the getty
sundar> running ready to receive incoming calls. Then every hour or
sundar> so, the outgoing uucp called from cron turns the getty off,
sundar> and does its thing. Right now, I have to manually do this
sundar> which is a pain.

`man uugetty`. No need to edit inittab; uugetty, uucico, and cu all
inter-lock together.


sundar> b. Is there a way to send an initialization string to a modem
sundar> device from inittab/gettydefs? (with delays etc.)

/usr/lib/uucp/fix-telebit (and friends) does the base configuration of
the modem. The inittab entry I am using for UUCP and SLIP look like:

t8:23:respawn:/usr/lib/uucp/uugetty -Nrt15 -it25in,conn ttyf8 dx_19200
t9:23:respawn:/usr/lib/uucp/uugetty -Nrt15 -it16in,conn ttyf9 dx_38400

=-=-
--
 Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
 Networking Services,        / Help! My disclaimer is missing!
 Silicon Graphics, Inc      / GIGO *really* means: Garbage in, Gospel Out