HDTenEightyP/NetNews huggingface dataset:
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: tempnam(3S) bug, possibly on all MIPS
Newsgroups: comp.sys.sgi,comp.sys.sgi.bugs,comp.unix.ultrix
Organization: University of California, Irvine
Date: 24 Dec 92 05:46:04 GMT

In article <1992Dec24.011451.497@pixar.com> aaa@pixar.com (Tony Apodaca) writes:
>In an article, murphy@ufp.dco.dec.com (Rick Murphy) writes:
>>Looking at errno after calling a library routine that hasn't failed isn't
>>a useful thing to do. The call succeeded - you've got no reason to go looking
>>at errno.
>
>	This is not really the point.  The point is that a smart programmer
>checks errno after every system call.

Yes, it is the point.  Here's an excerpt from the Ultrix errno(2) man
page:

     The errno external variable is set when an error occurs in a system
     call.  You can use the value stored in errno to obtain a more detailed
     description of the error than is given in the system call's return
     value.  The errno variable is not cleared on successful system calls, so
     you should check its value only when an error is reported.

The Sun intro(2) man page says essentially the same thing.

>errno had
>been set as a side-effect of tmpnam() in a different module in a different
>file hundreds of lines of code ago.  This is totally unexpected (and
>I might add totally undocumented) behavior, and it is a pain in the butt.

It is documented, as noted above.


Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926
From: R5321GAB@vm.univie.ac.at
Subject: Backup script
Organization: University of Vienna
Date: Sat, 2 Jan 1993 01:07:42 GMT

Help!
    Hello all, I need a quick and nifty script. I am too pressed for time
to figure this out on my own, and my scripting abilities aren't what they
used to be. I need something that will backup everything in a certain
directory every five hours to the internal DAT drive and then remove all
files with a .pic extension in that directory. I need this *really* soon
as the drive is almost full and I have a lot of rendering to do before the
diploma commision comes and demands to see work. I am on the verge of a
nervous breakdown as it is. AAghhhh!
    Sorry for the outbreak, but with a thesis and an animation due in three
weeks, I am sure you all can understand I am a bit nuts. Thanks in advance!

Patrick Maun
Hochschule fuer Angewandte Kunst
Vienna, Austria
R5321GAB@AWIUNI11.BITNET
From: CDSCHULZ@iftpus.physik.uni-stuttgart.de (C._D._Schulz)
Newsgroups: comp.sys.sgi
Subject: Audio signal processing
Date: 23 Dec 92 16:46:11 GMT
Organization: University of Stuttgart, FRG(Inst.f. Theor. Phys. u. Synergetik)
X-News-Reader: VMS NEWS 1.20

Hi !

I wanna do some audio signal processing on
an Indigo. Is there any neat software available 
like sampler, real-time sound processing like
filters, echo etc.
Where could i get info on how to use the DSP ?

Unpatiantly waiting

C-D
Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: NTP Time?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 3 Jan 1993 00:55:57 GMT

In article <C08w41.65J@rahul.net>, jonathan@rahul.net (Jonathan Heiliger) writes:
> 
>     I recently FTPed the NTP time server software and have tried compiling it 
> on my SGI running IRIX 4.0.5  However...with no luck.  Has anyone gotten this 
> to compile, or can suggest an alternate time package?  Thanks.


The NTP version of NTP from sgigate.sgi.com should work fine.  The
"Information Services" people within SGI use it a lot.

There are also "timeslave" and "timed" shipped standard as part of
IRIX.

`xntpd` or `timeslave` can be used to synchronize the clock of one
machine to an external standard, such as machine on the Internet with a
good NTP connections, a radio receiver, or (with timeslave) just some
other machine offering standard TCP services that has a trusted clock.
Then `timed` can be used to synchronize a passle of IRIR's to the first
machine.  This is how the several thousand machines in the Silicon
Graphics network are synchronized.

`timed` is shipped installed and turned on by default so that an
ethernet (or other LAN) of IRIS's have synchronized clocks "out of the
box."

It all works just fine, provided your external source is not crazy.
Just now our WWV receiver is reporting a time and date that is exactly
24 hours wrong.  When you primary standard goes crazy, there's not much
you can do.


Vernon Schryver,  vjs@sgi.com
From: surna@vigyan.iisc.ernet.in
Newsgroups: comp.sys.sgi
Subject: Re:  Good greif...
Date: 30 Dec 92 16:05:54 GMT

dear sir, who the hell are you?
From: frank@marvin.contex.com (Frank Perdicaro)
Newsgroups: comp.sys.sgi
Subject: Re: Indigo Graphics and Z-Buffering
Date: 22 Dec 92 14:34:32 GMT
Organization: Xyvision Design Systems

In article <tnl0lm0@zola.esd.sgi.com> peterb@perturb.esd.sgi.com (Peter Birch) writes:
>[discussion about z-buffering on XS, and how OpenGL will provide a software
>z-buffering mechanism for XS]
>
>In article <3201@contex.contex.com>, frank@marvin.contex.com writes:
>> Regarding zbuffering, I have wondered about this also, and suspected
>
>Your post is very misleading, and deserves some clarification:
>
Yes, my post was misleading.

I did not mean to dump on the engineering folks at SGI, I realize how
hard you work.  I was pointing out that things are decided upon for
good reasons, but somtimes that information does not make it to the
end user. 

I have spoken with no less than 20 people that have been suprised or
angered at some of the things I mentioned.  Somehow the marketing
information did not make it out with the engineering information ( as
is very common in technical sales ) and SGI is as a company not
pointing out this phenomenon well.  This is not suprising, for
marketing people do not say "it goes slower if you spend more money"
very well.  This is an ongoing mistake.

The incontrovertable evidence that it is a mistake is the volume of
people that keep running into it, and being suprised.

In general, keep up the good work, but make sure it gets to market
correctly and clearly.

-- 
	 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
Xref: sparky comp.sys.sgi:18334 comp.sys.sgi.bugs:45 comp.unix.ultrix:9077
From: mjr@TIS.COM (Marcus J. Ranum)
Newsgroups: comp.sys.sgi,comp.sys.sgi.bugs,comp.unix.ultrix
Subject: Re: tempnam(3S) bug, possibly on all MIPS
Date: 24 Dec 92 18:30:11 GMT
Reply-To: mjr@TIS.COM
Followup-To: comp.sys.sgi
Organization: Trusted Informations Systems, Inc.

aaa@pixar.com (Tony Apodaca) writes:

>	The point is that a smart programmer
>checks errno after every system call.

	The *wise* programmer checks the approriate return value of the
system call, and if it returns a value indicating an error, then the errno
value is used.

	Consider the following:

	int	fd;
	fd = open("foo",O_RDWR|O_CREAT,0600);
	if(errno != 0)
		perror("foo");


	Versus:

	int	fd;
	if((fd = open("foo",O_RDWR|O_CREAT,0600)) < 0)
		perror("foo");

	Now, the manual page on open(2) states explicitly:

RETURN VALUE
     The value -1 is returned if an error  occurs,  and  external
     variable  errno  is  set to indicate the cause of the error.

	There's a good reason for writing your code this way. You are
using the return value from the function, rather than a global value
which can get stepped on by something unusual you don't know about.
This means that your code doesn't have to care about what is a system
call versus what is a library routine. Do you care? I don't. I just
want to know if it didn't work right. Then I want to know why.

	I believe that you can also run into problems if you have
a signal handler that gets invoked, and resets errno in the period
between your successful system call and your test for success. It's
easier to just treat the system calls like a function call, and
look at its return value. If you somehow think that using errno
rather than having to declare a local to capture the return value is
an optimization, you're mistaken.

mjr.
From: dittrich@carson.u.washington.edu (Dave Dittrich)
Newsgroups: comp.sys.sgi
Subject: Re: corpses in /etc/utmp??
Date: 22 Dec 92 18:28:18 GMT
Article-I.D.: u.1992Dec22.182818.1427
Organization: University of Washington

callahan@vax.oxford.ac.uk writes:

>I have noticed some bizarre behavior on several machines running
>4.0.5.   Entries hang around in /etc/utmp, causing 'who' and 'finger'
>to give incorrect information.

>For instance, I am, right now, the only person logged on to this machine,
>but 'who' lists two other users, taking up 4 pseudo-ttys.  I think
>something is failing to remove /etc/utmp entries when people log off/
>close windows.

>I observe this phenomenon on four separate machines.

>So, some questions
>1) Does anyone else suffer from this problem?

Yes.  We have the same problem here on our 16 RPCs running 4.0.5.  Problem started
to appear after upgrade to 4.0.5, so I suspect something got broken in this version.

>3) If so, is there a patch or something from SGI to fix it?

I'm looking for the fix too!  Anyone from SGI able to duplicate this?  If not, get
in touch with me and I will supply you with whatever info you need to find the
problem.
Newsgroups: comp.sys.sgi
From: gleicher@CS.CMU.EDU (Michael Gleicher)
Subject: what happens to big color values?
Originator: gleicher@HOSTESS.GRAPHICS.CS.CMU.EDU
Organization: CMU Graphics Group
Distribution: comp
Date: Tue, 29 Dec 1992 02:51:43 GMT


When lighting calculations are taking place, what happens when color values
are > 1?

I'm computing the lighting "manually" in a program as well as displaying it on
the screen. For points whose RGB value is computed > 1, I'm not seeing the
expected results. For instance, what I compute as an RGB value of
(1.5,1.4,.9), I'd expect to appear nearly white (since I expected the values >
1 to be truncated), but it appears yellow.
The things which could be happening are:
	1) truncation (this is what I expected, but doesn't seem to be the
		case) 
	2) normalization (eg: make the vector be unit magnitude)
	3) divide by the largest element
	4) something else

If someone could fill me in, I'd be most grateful.

Mike

10 days before the siggraph deadline.... do you know where your pixels are?
-- 
Michael Lee Gleicher				gleicher@cs.cmu.edu
		ski bum, graphics hacker, and SCS PhD student
Carnegie Mellon University, Pittsburgh, PA 15213-3891	(412) 268-6243 (school)
Newsgroups: comp.sys.sgi
From: R5321GAB@vm.univie.ac.at
Subject: Help!Syquest help needed!
Organization: University of Vienna
Date: Sun, 3 Jan 1993 17:53:51 GMT

Hello all,
     I need help installing a SCSI Syquest compatible 44MB drive to an
Indigo. Is this possible? I normally use this drive on my Macintosh, but
I need to render things and have no room on the Indigo's internal. Could
some kind soul out there step me through this? I looked through the device
drivers and didn't see anything to do with cartridge drives. Is it possible
to just "mount" the drive? If so, how? Ugh, why can't Unix be as simple
as using a Mac, or at least a NeXT. I speak Unix, but not that well. I can
program C so don't worry about getting technical on me. I just have little
(read "none whatsoever") experience hooking up drives to Unix machines.
Thanks for any help in advance!

Patrick Maun
Vienna, Austria
R5321GAB@AWIUNI11.BITNET
R5321GAB@AWIUNI11.EDVZ.UNIVIE.AC.AT

Newsgroups: comp.sys.sgi
From: hughes@msi-i5.msi.umn.edu (Matt Hughes)
Subject: Re: Looking for 'BOB' (Brick of Bytes) software
Organization: University of Minnesota
Date: Wed, 23 Dec 1992 15:29:26 GMT

Dick_Jackson@ibd.nrc.ca (Dick Jackson) writes:

>Dear readers,

>I've tried to dig up the reference again, but to no avail.  Could someone
>point me to the
>software for volume visualization known as 'BOB', I believe it's from U.
>of Minnesota.  I
>apologize for the request, as I know it passed through here just a few
>weeks ago.

Surely.  It's on ftp.arc.umn.edu (really pi1.arc.umn.edu) and is
contained in a larger release known as gvl.tar.Z.  The gvl stands
for graphics and visualization lab or something like that.  There
are some other tools that go with it including a colormap editor
and some movie playing tools.

It is UofMN work, under contract with the U.S. Army. Very good software.

Caution:  Don't try the program for 1 hour, and then give up on it
because you don't have it figured out yet.  Your patiences will be
rewarded.
-- 
Matthew V. Hughes - MN Supercomputer Institute  Graphics Support Coordinator
Minnesota Supercomputer Center, Inc.            Phone Number: (612) 626-1765
1200 Washington Avenue South                    hughes@msc.edu
Minneapolis, MN 55415                           hughes@msi.umn.edu
Newsgroups: comp.sys.sgi
From: aj3u@larch.cs.virginia.edu (Asim Jalis)
Subject: How Accurate Is The System Clock
Organization: University of Virginia, Charlottesville, VA 22903
Distribution: comp
Date: Tue, 22 Dec 1992 20:37:48 GMT

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.
From: sgi.com!pdi!shoshana@BRL.MIL (Shoshana Abrass)
Newsgroups: comp.sys.sgi
Subject: Re: Hard drives...
Date: 31 Dec 92 01:32:11 GMT


  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.

  -shoshana
   shoshana@pdi.com
   Shoshana Abrass
   Pacific Data Images, Sunnyvale, CA
Newsgroups: comp.sys.sgi
From: aj3u@larch.cs.virginia.edu (Asim Jalis)
Subject: Re: How Accurate Is The System Clock
Organization: University of Virginia, Charlottesville, VA 22903
	<1992Dec23.194149.27172@odin.corp.sgi.com>
	<tvl10pk@rhyolite.wpd.sgi.com> <1hb1a8INNr7m@darkstar.UCSC.EDU>
Date: Fri, 25 Dec 1992 01:31:37 GMT

I am the person who originally asked the timing question.  Thanks
to all the people who have responded.  Unfortunately, I am not
sure I have found the complete answer to my question.  People
have not addressed the multi-process environment, concentrating
only on the accuracy of the physical clock.

What I am concerned about is not the accuracy of the clock, so
much as the length of the delay between calling the time function
and getting a response.  This delay could be produced if the
scheduler unschedules my process before the clock daemon has
responded to its query, or it could be produced if the clock
daemon was woken when the clock interrupt occurred because the
cpu was doing something else that was important, or for some
other reason arising out of the multi-process environment.

Testing could be used to get a general idea of how large this
delay can be.  However, I want to get more confidence about this.

(1) Do the specifications of the operating system provide some
kind of a guarantee about timing accuracy in its multi-process
environment?  (2) Is the code of the operating system public
domain? (3) If not, then is the scheduler's design similar enough
to Unix so that Unix sources can be studied for an answer to my
problem.

Any help much appreciated.


Asim Jalis.
From: chip@inter.interzone.ch (Marc Liyanage)
Newsgroups: comp.sys.sgi
Subject: Re: Frustrated with SGI support..
Date: 2 Jan 93 12:07:38 GMT
Reply-To: chip@interzone.ch
Organization: Interzone Switzerland
X-Mailer: uAccess - Macintosh Release: 1.5v4


In article <C075t4.Ivp@news.cso.uiuc.edu> (comp.sys.sgi), ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
 I think that with the Indigos and all the massive effort spent in their
> video&audio , SGI is entering a new era.  the machines are very
> attractive for home and are serious competitors of high-end PC's
> and Macs.  in fact, we all know they are much better! 

Very true; I just bought a Mac Quadra but if it were a little easier
to get an Indigo I would have saved a few more pennies to buy one.

> but on the other hand, the maintainance policy seems
> to discourage the folks willing to take one at home.
> at this point, such people are likely to be students or professional
> who already used SGIs at work.

Right; If I had one, I wouldn't have to worry about days or
even weeks of system downtime. It would just be my private
machine at home, no critical projects running on it.
I also wouldn't mind fiddling around with things to get them work.

> the situation is particularly dramatic in europe!
> i am now in the US, and will be back in Italy in one year, and
> I am *very* tempted to carry an Indigo with me  (of course, there
> is no way I could buy one in Italy, far too expensive).

I wouldn't dream of buying one here in Switzerland. Far too expensive.
If it were somehow possible to buy one from the US the way I do with
Mac stuff, I'd be very happy. 

> BUT, I know what the support is in Italy (similar to Germany, it seems), 
> and I know I will be into financial troubles pretty soon.  So i am
> still holding my purchase decision.  
 
> European branches of SGI (if you are listening...): don't you think that 
> if you reduce prices and start being friendly with the home users, 
> the increase in sales can be sufficient to increase your revenue, even 
> if the revenue per machine sold is less? 

Exactly; as I said: If it were a little easier to get one just as
a personal workstation I would certainly have bought one. 
The way it is now, I'm kind of scared of the complicated way
sales are handled.
I've been a fan of the Indigo ever since I first saw it in some
computer magazine.


-Marc


___________________________________________________________________
Marc Liyanage                    chip@interzone.ch
                                 CH-9552 Bronschhofen,  Switzerland 
                                 47 29 17 N / 009 03 41 E / ALT 578
                                 +41 73 22 1196
Newsgroups: comp.sys.sgi
From: kasinath@research.nj.nec.com (Kasinath Anupindi)
Subject: Re: Frustrated with SGI support..
Originator: kasinath@ariadne
Reply-To: kasinath@research.nj.nec.com
Organization: NEC Research Institute
Date: Thu, 31 Dec 92 13:29:39 GMT


In article <34842@adm.brl.mil>, andersen@marvin.ama.ttu.edu (Kim Andersen) writes:
|> 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.

I will agree with you.
-- 
		           Kasinath Anupindi
                  Computer Systems & Network Administration
      NEC Research Inst. Inc.,  4 Independence Way,  Princeton, NJ 08540 
  Inet: kasinath@research.nj.nec.com  PHONE:(609) 951-2567   FAX: (609) 951-2481
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: CDROM Problems
Date: 24 Dec 92 05:25:42 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1h65bnINN2q7@tamsun.tamu.edu> n303bn@tamsun.tamu.edu (Jason Rosson) writes:

|   I've got a problem with a CDROM and an Indigo Elan.  The drive is a
|  Texel DM-3024 Internal drive, it's SCSI-2 compatible.  My kernel got
|  corrupted and I'm trying to reinstall IRIX 4.0.4, the only one I've
|  presently got.  I hit <Esc> to perform system maintenance.  Then
|  use option 2 : Install System Software.  At this point the
|  problem occurs :

You almost certainly won't be able to use the drive for installation.
It won't default to 512 byte logical blocks, which older proms, 
including r3k indigo require (similar to Sun).  Indigo can handle
the fact that it identifies itself as a CD-ROM, older PROMs require
that it like and identify itself as a hard disk.

Similarly, since we could only test a couple of CD-ROM drives for
ISO-9660 and the cdplayer, so it probably won't work there either
(we check the inquiry string for Sony or Toshiba).

Sorry...
--
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
Newsgroups: comp.sys.sgi
From: ag@nextcube.in-berlin.de (Andreas Gradert)
Subject: Re: games for INDIGO?
Organization: Home of IRIS ...
Date: Wed, 23 Dec 1992 21:30:18 GMT

PREINERT@CIPVAX.BIOLAN.UNI-KOELN.DE (Peter Reinert) writes:

> Hello netters,
> sorry for the childish question:
> Are there any games running on INDIGOS?
> I'm particulary interested in Dungeon Games.
> Please reply directly via e-mail.
> Many thanks in advance!
> Merry christmas and a happy new year!
> 			Peter Reinert

No, no, no! Please reply here, too. I need it for my indiGAMEBoY!
With pleasure and zbuffers,

Merry Xmas to all.
-- 
Andreas Gradert | fon +49 30 6923946 | email ag@nextcube.in-berlin.de
D1000 Berlin 61 | fax +49 30 8825421 |   andreas@unlisys.in-berlin.de
From: archer@elysium.esd.sgi.com (Archer Sully)
Newsgroups: comp.sys.sgi
Subject: Re: How Accurate Is The System Clock
Date: 23 Dec 92 19:41:49 GMT
Distribution: comp
Organization: Silicon Graphics, Inc.  Mountain View, CA

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.

-- archer
Newsgroups: comp.sys.sgi