HDTenEightyP/NetNews huggingface dataset:
From: kurt@cashew.asd.sgi.com (Kurt Akeley)
Newsgroups: comp.sys.sgi.graphics
Subject: Re: Perspective
Date: 30 Dec 1992 18:19:11 GMT
Organization: Silicon Graphics, Inc.
Distribution: world
NNTP-Posting-Host: cashew.asd.sgi.com

-- 

I believe this is how the perspective matrix is computed:

	cot(fov/2)
	----------	0	0	0
	 aspect


	    0	    cot(fov/2)	0	0


			    near+far
	    0		0   --------	-1
			    near-far


			    2.far.near
	    0		0   ----------	0
			     near-far


Clipping is then done to:

	-w < x < w
	-w < y < w
	-w < z < w

-- Kurt Akeley	    kurt@sgi.com  (415) 390-3612  M/S 7U-550
Newsgroups: comp.sys.sgi
From: ag@nextcube.in-berlin.de (Andreas Gradert)
Subject: SGI-Express in Germany
Organization: Privat
Date: Sat, 02 Jan 1993 01:46:25 GMT

olson@anchor.esd.sgi.com (Dave Olson) writes:

> Most SGI hardware and software can be telephone ordered through SGI
> Express through an 800 number (which I know is a problem for Europe),
> but I don't know if they handle upgrade kits (I suspect not).  The
> number is 1-800-800-7441.  I don't even know if they will handle 
> international orders, perhaps Stan or one of the other folks more familiar
> with the policies can correct me on this.

There is a 800-like number in Germany, too. Call 0130-811011, thats SGI-Express
in Munich.

Very friendly guys!
-- 
Andreas Gradert | fon  +49 30 6923946 | email ag@nextcube.in-berlin.de
Bluecherstr. 15 | fax  +49 30 8825421 |   andreas@unlisys.in-berlin.de
D1000 Berlin 61 | leave INtel OUTside |  unido!fub!unlisys!nextcube!ag
Newsgroups: comp.sys.sgi
From: Bruce@Pixar.com (Bruce Perens)
Subject: tempnam() and errno non-bug
Organization: Pixar -- Point Richmond, California
Date: Thu, 24 Dec 1992 20:12:59 GMT

In article <1992Dec24.011451.497@pixar.com> aaa@pixar.com (Tony Apodaca)  
writes:
[Regarding tempnam() setting errno even though tempnam() has not failed.]
> It *is* a bug, in the
> following sense: the man pages explicitly state that errno is set if a
> system call gets an error, but is untouched otherwise.  I think library
> utility functions fall into the "otherwise" category, don't you?

I don't agree that it's a bug.

Library functions are allowed to make system calls, thus library functions
may set errno when the system calls fail. This is
the case with tempnam() - it uses a system call to check if the name
it has created exists in /tmp. If the system call succeeds, the name
exists and tmpnam() picks another name and uses the system call to
check it. Thus, the system call must fail before tempnam() returns.

The cautious programmer always checks the return value of a system call
for a failure indication, and never looks at errno except immediately
after a system call has returned indicating an error. The value of errno
is un-defined at any other time if you are using library functions, since
those library functions may make system calls as they please, and those
system calls may fail.

Most Unix programmers stumble over this at some point.
It's certainly non-intuitive. A more modern design would use something
other than a global variable for errors - perhaps the C++ "exception"
facility will help here.
					Bruce Perens
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Hard drives...
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 31 Dec 92 04:49:35 GMT

In <34844@adm.brl.mil> sgi.com!pdi!shoshana@BRL.MIL (Shoshana Abrass) writes:
|   I've answered dave extensively offline, but I thought this
|   needed to be posted:
| 
|   In <u8sjk9c@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
| >  As you have seldom given any details in your postings about 
| >  the problems, except for ones that point with > 99.9% certainty 
| >  to cabling or termination problems, it would be hard for me 
| >  to guess just what problems you are talking about, or what 
| >  the causes of them are. 
| 
|   I'm not asking you to "guess" or fix our problems - I'm merely 
|   saying that we do have them.  We've been having them for the
|   past three years and probably before that. For much of that
|   time we were on full or basic support, and no SGI field engineer
|   or hotline person has been able to eliminate the problems in 
|   spite of having all the details and hands-on access.
| 
|   I'll leave it to you to argue whether that reflects more on 
|   the SGI support staff or the state of the SCSI. The fact is that 
|   I remain a dissatisfied customer.

*I* think it reflects the fact that you have mostly 3rd party
disks, and are expecting SGI to support you (based on our
email).  Our stated policy is that we will work on systems
with 3rd party drives, and may even try to help on problems
with those drives, but that if we think the problem is in
your 3rd party drive, memory, or whatever, that you need to
go to the 3rd party supplier for help.  After all, that is what
you do with any other system that I know of.  Certainly Apple
won't try to support every 3rd party peripheral that you hook
up to a Mac, you go to whoever you bought it from, or the mfgr's
technical support folks.

Again, I suggest that you spend some time talking to Parity
about your problems.

You can't expect us to put out a lot of effort on stuff that
we don't test and support, and don't even make money off of;
at least our support folks (TAC, and FE's) make some initial
effort to look at problems with the 3rd party stuff installed!
We go that far because we want you to be happy with our systems
and buy more, but you are expecting us to go unreasonably far
on 3rd party problems.

--
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: kong@ece.ucdavis.edu (Timothy Kong)
Newsgroups: comp.sys.sgi
Subject: pixie
Date: 28 Dec 92 23:30:20 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Originator: kong@madrone.eecs.ucdavis.edu

Hello, I am trying to use the profiling tool pixie to generate program
traces.  My version of pixie currently can't do this, but I understand
that a newer version can.  Can anyone point me to the proper ftp site?

Timothy Kong
kong@eecs.ucdavis.edu
Newsgroups: comp.sys.sgi
From: fish@daacdev1.stx.com
Subject: can you use 4.0.5 cdromd on 4.0.1 system???
Organization: Goddard Space Flight Center
Date: Tue, 22 Dec 1992 19:41:53 GMT

i can't upgrade to 4.0.5 right now for various reasons but
need to get the fixed cdromd - can i just pull cdromd from
another machine with 4.0.5A and run it on my 4.0.1 machine???

		fish
--
John R. Vanderpool                INTERNET: fish@daacdev1.stx.com
NASA/GSFC                         VOX: 301-513-1683                
Hughes/STX Corporation            FAX: 301-513-1608
all this science, i don't understand; its just my job 5 days a week - rocket man
From: philip@concave.cs.wits.ac.za (Philip Machanick)
Newsgroups: comp.sys.sgi
Subject: Re: Frustrated with SGI support..
Date: 30 Dec 92 09:41:10 GMT
Organization: Computer Science Dept, Wits University
X-Xxdate: Wed, 30 Dec 92 11:33:11 GMT
X-Useragent: Nuntius v1.1.1d12

In article <1992Dec29.204858.17847@Princeton.EDU> Brett Borowski,
brett@surfpix.princeton.edu writes:
>Does my company get lousy service because it's so small?  Am I the only
>one who gets lousy service?  It seems to me, that unless you pay for
>phone support, the only thing SGI wants to know about are purchase
>orders.

I don't really need software support but I'd like to be able to buy
an upgrade - just a CD, not the whole package - at a modest price when
I judge the timing to be right. It seems there is no such option: you
have to buy the complete OS or go on support. Definitely not a small
user-friendly organization. (Rivals like Sun and NeXT can do this
so I don't see what the big problem is.)
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965
From: gavin@krypton.asd.sgi.com (Gavin Bell)
Newsgroups: comp.sys.sgi
Subject: Re: 3D Manipulator?
Date: 23 Dec 1992 18:29:18 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA
NNTP-Posting-Host: krypton.asd.sgi.com

In <BzpwEo.KzM.1@cs.cmu.edu> gleicher@CS.CMU.EDU (Michael Gleicher) writes:
>Chances are, you'll just implement a
>virtual trackball. It's easy from either the Chen paper or from the Shoemake
>paper.

Great references!

If you are going to implement a virtual trackball, there is free code
at:

/usr/people/4Dgifts/examples/trackball

It is the trackball interface used by the 'powerflip' demo.

--
--gavin     (gavin@sgi.com,  (415)390-1024)
Newsgroups: comp.sys.sgi
From: penev@venezia (Penio Penev)
Subject: Re: problems with xpsview 1.2
Organization: Rockefeller University
Date: Thu, 24 Dec 1992 06:00:32 GMT
X-Newsreader: TIN [version 1.1 PL6]
Reply-To: penev@venezia.rockefeller.edu
X-Posted-From: venezia.rockefeller.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

lim@cs.umass.edu wrote:
: 
: Occasionally, when I startup xpsview, my screen freezes and the machine does a
: soft reboot (on its own). Has anyone else experienced this? I'm using xpsview
: 1.2 on a 340GTX with 4.0.4. Thanks in advance.
: 

We have xpsview 1.2 and 1.2.1. 1.2 is rather unstable (especially on
resizing) 1.2.1 is a little bit better. It doesn't crash, but You have
to reopen the file to see the resized version (I guess only when
enlagring).


Another unintuitive feature is that it shows the file as if it would
be output on a laser printer, instead of using the 8-bit (or whatever)
depth of the display and generate grayscales. This may well be a
setting of the DPS, of cource.

-- Penio.
From: andersen@marvin.ama.ttu.edu (Kim Andersen)
Newsgroups: comp.sys.sgi
Subject: Re: Frustrated with SGI support..
Date: 30 Dec 92 23:56:04 GMT

I have several SGI systems, all different models.  I was very happy with
the hotline service the first couple years - they were very speedy and
knowledgable.  HOWEVER, response time has increased dramatically (coupled
with a seeming decrease in competence) over the past year and a half.
Ever since 4.0.X was released.  Now I don't bother to call the hotline
anymore because on the rare occasion that I get a return call, they have
no clue anyway.

Sorry, guys, but that's my experience.


Kim Andersen                 |  It's only ones and zeroes.
Harrington Cancer Center     |  The wonder is that
andersen@marvin.ama.ttu.edu  |  it does anything at all.  -- anonymous
From: travis@mips.com (Mike Travis)
Newsgroups: comp.sys.sgi
Subject: Re: Launch program at boot time??
Date: 31 Dec 1992 20:14:51 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA
NNTP-Posting-Host: lawrence-b1-psd-hw.esd.sgi.com

In article <u8rt1eo@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <C02z23.1os@iat.holonet.net> cmumford@iat.holonet.net (Chris Mumford) writes:
>
>| Does anyone know how to launch a program at boot time.  This would be
>| valuable for a turn-key system where the power button is pressed and the
>| system comes right up into the simulation.
>
>Create an account whose .xsession and/or .sgisgession 
>runs the programs you want with the resources you want,
>and then setup the system to autologin as that 'user'
>(via system manager, or just put the account name in 
>/etc/autologin).  This won't work if the user 'logs out',
>but it does work on bootup.
>--
>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

Another possibility is to launch the program from /etc/inittab.  See
init(1M) and inittab(4).
-- 
mike (travis@sgi.com)           (415) 390-2121            fax: (415) 390-6159
Silicon Graphics, 2011 N. Shoreline Blvd, MS 1L-945, Mtn. View, CA 94039-7311
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Mouse Interrupts
Date: 1 Jan 93 18:43:35 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

By the way, 'comp' is *not* a valid distribution.  If your news
software inserted it automatically, you should get your news admin
to update their software.  I've removed the Distribution header.

In <AJ3U.93Jan1103135@larch.cs.virginia.edu> aj3u@larch.cs.virginia.edu (Asim Jalis) writes:
| 1. What mechanism does IRIX use to determine if a mouse button
| has been pressed?  I assume it uses interrupts but I am not sure.

Yes, it is interrupt driven.  On all current machines, the mouse
and keyboard use the same DUART chips as the regular serial ports,
and the same low level driver.

| 2. How much time does it take between a mouse button being
| pressed and a user program running in non-preemptable mode (i.e.
| with a highest non-degrading priority) being informed about it if
| it is using qtest() to constantly check the status of the event
| queue.

The question is unanswerable as asked.  If you are on an MP machine,
and dedicate a processor to your process, I think the guarantee is
within 400 usecs.  On a single processor machine, the worst case
will probably be a few milliseconds.  Typical times will probably
be much less (on the single processor machine).  Note that mouse
events got through the X server, so the answer also partly depends
on how much memory you have, since if parts of the server (or your
program, for that  matter) get paged out, you obviously increase
the latency.

| 3. Is there another way to find out the status of the mouse, or
| to set up some kind of a signal that would interrupt the program
| if the mouse button is pressed, that is presumably faster than
| using qtest()?  And there is such a way, then how much time does
| it take between a mouse press and the program being informed
| about it?

Well, you could just queue the mouse button, and then block with
qread(); at least you won't be doing as much polling and eating
up CPU time.  Other than that, no, their really isn't much you
can do to reduce the time to you getting the event.

| 
| 4. If the information required by questions (2) and (3) is
| unknown then how can I determine it?  I have been thinking about
| a possible software solution, but I have not been able to come up
| with anything satisfactory.

Measure it.  Put an analyzer on the mouse port, and then have your
program write a character to one of the serial ports when it gets the
event, and use that as your second trigger.  Yes, that adds a few more
variables, but you should be able to get a decent average, and 'worst
case' value that way.
--
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: beyer@bflsgu.fl.bs.dlr.de (Ralf Beyer DLR)
Newsgroups: comp.sys.sgi
Subject: MSGGET(2) system limits
Date: 30 Dec 92 16:16:18 GMT


Hi,

the MSGGET(2) man page on the system message queue says that

	"Msq_qbytes is set equal to the system limit"

What is this system limit ? How can I modify it ?

I looked into /usr/include/limits.h and did not discover anything
which appears relevant to me.

Thanks for any help and best regards.

Ralf Beyer

----------------------------------------------------------------------
Ralf Beyer
German Aerospace Research Establishment (DLR), Institute for Flight
Guidance, Flughafen, D-3300 Braunschweig, Fed. Rep. of Germany
Internet: beyer@bflsgu.fl.bs.dlr.de (EARN/BITNET: fl17@dlrvmbs.bitnet) 
----------------------------------------------------------------------
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: How Accurate Is The System Clock
Date: 23 Dec 92 22:01:36 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Dec23.194149.27172@odin.corp.sgi.com>, archer@elysium.esd.sgi.com (Archer Sully) writes:
> In <AJ3U.92Dec22153748@larch.cs.virginia.edu> aj3u@larch.cs.virginia.edu (Asim Jalis) writes:
> 
> *I am writing some programs on the SGI that requires millisecond
> *timing accuracy.  How accurate is the clock on these machines?
> *with the daemons and the multi-process environment.  If someone
> *has references for timing measurements or some ideas about how
> *such timing can be achieved, I would really appreciate hearing
> *from them.
> *
> *Responses can be communicated to me through e-mail.
> *
> *
> *
> *Asim Jalis.
> 
> fast itimers are rumored to be micro-second accurate.


There are several different meanings for "accuracy" when applied to
timers or time, including:
    -resolution
    -frequency stability
    -frequency accuracy
    -monotonicity (i.e. always increasing, even when being adjusted)

The normal resolution of the IRIX system clock is 10 milliseconds.  "Fast
timers" have resolutions on the order of 1 millisecond (I think the
exact value depends on the model of IRIS.)

See `man ftimer`.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.sys.sgi
From: cmumford@iat.holonet.net (Chris Mumford)
Subject: RE: Paradigm Flight Sim
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Tue, 29 Dec 1992 04:09:04 GMT

Currently the F18 simulator is something that we put together to
demonstrate the capabilities of the reality engine. You really have to use
it with a multiprocessor RE to have any fun on it.  It uses our new gaming
architecture called VEGA which is locked to a particular machine so we
can't easily send it out in demo form.

We recently upgraded the simulator to utilitize real-time reflective
memory cards for 1 to 16 machines to play eachother on a net. Who knows,
maybe it will work itself into some high end game some day.

I have to admit, it's really hard to get any work done with that game
waiting to be played.

Chris
Newsgroups: comp.sys.sgi
From: cmumford@iat.holonet.net (Chris Mumford)
Subject: Booting w/o keyboard
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Tue, 29 Dec 1992 04:18:58 GMT

How do I boot a 310VGX without a keyboard plugged in?
From: zoltan@a.chem.upenn.edu (Zoltan Kanyo)
Newsgroups: comp.sys.sgi
Subject: memory for indigo r4000
Date: 21 Dec 92 18:38:02 GMT
Distribution: comp.sys.sgi
Organization: University of Pennsylvania

Hello,
I know this has been gone over before, but things change with
time/experience.  I am looking to increase the memory for several
indigo r4000's and wanted to know if anyone has had any good 
experiences with third-party suppliers.  
Thanks much
zoltan kanyo
From: mmcohen@cats.ucsc.edu (Michael M Cohen)
Newsgroups: comp.sys.sgi
Subject: Re: How Accurate Is The System Clock
Date: 24 Dec 1992 00:47:04 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


In article <tvl10pk@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Dec23.194149.27172@odin.corp.sgi.com>, archer@elysium.esd.sgi.com (Archer Sully) writes:
>> In <AJ3U.92Dec22153748@larch.cs.virginia.edu> aj3u@larch.cs.virginia.edu (Asim Jalis) writes:
>> 
>> *I am writing some programs on the SGI that requires millisecond
>> *timing accuracy.  How accurate is the clock on these machines?

If you have an IO3 board there is another timer with
submillisecond cycles. Here is some code I use....
call cy_setup before use.
cy_start sets beginning point
cy_timer will wait for specified usec
cy_read returns usec sinc beginning

============================
#include <sys/types.h>
#include <sys/syssgi.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <limits.h>

volatile unsigned int* counter;         /* Pointer to IO3 counter */
#define MICROSECS_PER_PICOSEC 1.0e-6
unsigned long counterTickPicoSecs;
unsigned int* counterAddr;
int mmemfd;
unsigned int previousCounter;
unsigned int currentCounter;

cy_setup()
{
    int i;

    counterAddr = (unsigned*)syssgi(SGI_QUERY_CYCLECNTR, &counterTickPicoSecs);
    mmemfd = open("/dev/mmem", O_RDONLY, 0);
    counter = mmap(0, sizeof(*counter), PROT_READ, MAP_PRIVATE, mmemfd,
                (unsigned)counterAddr);
}

cy_start()
{
    previousCounter = *counter;      /* reads current value from mmapped */
}

int cy_read()
{
double cy_ticks; int cy_usec;

    currentCounter = *counter;      /* reads current value from mmapped */
    cy_ticks = (currentCounter >= previousCounter) ?
               currentCounter - previousCounter :
               currentCounter + UINT_MAX - previousCounter;
    cy_usec = cy_ticks * counterTickPicoSecs * MICROSECS_PER_PICOSEC;
    return(cy_usec);
}

cy_timer(cyt)
int cyt;
{
        cy_start();
        while(cy_read() < cyt){};
}
-- 

======================================================================
=   Dr. Michael M. Cohen                   mmcohen@dewi.ucsc.edu     = 
=   Program in Experimental Psychology     mmcohen@fuzzy.ucsc.edu    =
=   433 Clark Kerr Hall                    408-459-2655 LAB          = 
=   University of California - Santa Cruz  408-459-2700 MSGS         = 
=   Santa Cruz, CA 95064                   408-459-3519 FAX          = 
======================================================================
From: chuckb@stein.u.washington.edu (Charles Bass)
Newsgroups: comp.sys.sgi
Subject: Re: Frustrated with SGI support..
Date: 30 Dec 1992 21:56:57 GMT
Organization: University of Washington
NNTP-Posting-Host: stein.u.washington.edu

I've been working for two years on SGI equipment and have
experienced the entire range of service quality. I've had night
mares (several months to get a critical OS upgrade because our
dials/buttons wouldn't work) and I've had people bend over
backwards to make things work (next day service to replace a bad
video board).

In general I haven't been ecstatic with the service I've gotten
from the hotline.  However, the support that I've seen and
experienced on the net has been excellent.  The sgi people that
monitor questions on the net (Olsen, Davis, Schryver et al) have
done an EXCELLENT job.  They answer graphics, OS, editor,
network, printer, and NFS questions to name a few.

chuckb
From: fred@poly2.nist.gov (Frederick R. Phelan Jr.)
Newsgroups: comp.sys.sgi
Subject: Re: Frustrated with SGI support..
Date: 30 Dec 92 22:59:24 GMT

In article <1ht5v9INN8s1@shelley.u.washington.edu>, chuckb@stein.u.washington.edu (Charles Bass) writes:
|> I've been working for two years on SGI equipment and have
|> experienced the entire range of service quality. I've had night
|> mares (several months to get a critical OS upgrade because our
|> dials/buttons wouldn't work) and I've had people bend over
|> backwards to make things work (next day service to replace a bad
|> video board).
|> 
|> In general I haven't been ecstatic with the service I've gotten
|> from the hotline.  However, the support that I've seen and
|> experienced on the net has been excellent.  The sgi people that
|> monitor questions on the net (Olsen, Davis, Schryver et al) have
|> done an EXCELLENT job.  They answer graphics, OS, editor,
|> network, printer, and NFS questions to name a few.
|> 
|> chuckb

I'm surprised to hear flames about SGI support (not in this post but others).
We have had nothing but EXCELLENT support be it the TAC, FE service, salesmen 
or net help.  The TAC is definately slower than the rest, but always reliable.
But, I think you've got to be realistic and allow for that to some degree since
probably most of them are working on more than one call at a time.


---
Fred Phelan
fred@poly2.nist.gov
/*___________________________________________________
   ____ __  ___  __    ___       ___        ___ 
  /__  /_/ /__  / /   /__/ /__/ /__   /    /__/ /\  /  
 /    / ( /__  /_/   /    /  / /___  /___ /  / /  \/
___________________________________________________*/
Newsgroups: comp.sys.sgi