HDTenEightyP/NetNews huggingface dataset:
From: dplakos@nswc-wo.nswc.navy.mil (Daniel Plakosh)
Subject: 2-D concave polygons with > 255 vertices
Organization: Naval Surface Warfare Center
Date: Fri, 9 Oct 1992 15:29:51 GMT


  I am looking for source code (or executable) that will take a 2-D
concave polygon that has more than  6000 vertices and break it up
into smaller polygons with less than 255 vertices for display on a
SGI 440/VGX. I have a concave polygon scan conversion routine but
wish to rotate the polygon in a 3D space.


    Thanks

Daniel Plakosh

dplakos@nswc-wo.navy.mil
 

Newsgroups: comp.sys.sgi
From: jonathan@vort.cuc.ab.ca (Jonathan Levine)
Subject: Need information on old(er) 4D
Distribution: na
Date: Tue, 06 Oct 1992 23:14:54 GMT

I've just come into possession of an old(er) 4D system, and need to obtain
some information on it.  First, it was sold to me as a 4D/70, but the name
plate on the box (and the serial # plate) says CS/12.  What does this mean?

As this system is a server, it has no graphics.  The boards installed are:
IP4 R2000 CPU; Interphase V/ESDI 3201 disk controller; CMC ENP-10
Ethernet.  What boards comprise a graphics set for this box, and in which
slots should everything reside?

Also, to give me a better feel for the earlier 4D machines, might anyone be
able to supply me, by fax or photocopy, with a periodic table from this
era and/or any other sales literature/configuration bumph?

Any help truly appreciated.

Jonathan

-- 
Jonathan Levine (voice) 403-686-0473 | Digital Alternatives      (Calgary AB)
                (fax)   403-686-1254 | Virtual  Universe         (Calgary AB)
uucp:        jonathan@vort.cuc.ab.ca | Survival Research Laboratories (SF CA)

Newsgroups: comp.sys.sgi
From: bobg@rains.wpd.sgi.com (Bob Green)
Subject: Re: Gotcha - 3.10 compilers, inst, and 4.0.x
Reply-To: bobg@rains.wpd.sgi.com (Bob Green)
Organization: sgi
Date: Mon, 12 Oct 92 16:50:19 GMT

In article <1992Oct11.095000.25185@comp.bioz.unibas.ch>, doelz@comp.bioz.unibas.ch (Reinhard Doelz) writes: 
|> Just to add, it is impossible to upgrade 4.0.4 with 4.0.5.  on an indigo.
|> You need to go back to 4.0.1 with removing the maint and resinstalling it. 
|> Let me emphasize that this is a shame, and definitively differs from the 
|> good reputation SGI has in other areas. Being at a site where most SGI 
|> sysops are non-trained staff, I am very conderned about this development!
|> -- 
|> +----------------------------------+-------------------------------------+
|> |    Dr. Reinhard Doelz            | RFC     doelz@urz.unibas.ch         |
|> |      Biocomputing                | DECNET  20579::48130::doelz         |
|> |Biozentrum der Universitaet       | X25     022846211142036::doelz      |
|> |   Klingelbergstrasse 70          | FAX     x41 61 261- 6760 or 267- 2078     
|> |     CH 4056 Basel                | TEL     x41 61 267- 2076 or 2247    |   
|> +------------- bioftp.unibas.ch is the SWISS EMBnet node ----------------+
|>                -----------------------------------------

Please explain.  The 4.0.5 software is designed to be installed over any
previous 4.0.x installation.  It was tested pretty thoroughly.  What did
not work for you?

Thanks,
Bob Green
Newsgroups: comp.sys.sgi
From: jeremy@classic.asd.sgi.com (Jeremy Higdon)
Subject: Re: Questions: Delay write and semaphore
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 13 Oct 1992 22:35:59 GMT

In article <1992Oct13.140730.2296@vixvax.mgi.com>, ying@vixvax.mgi.com writes:
> Hi,
> 
> Can anyone help me to better understand how delay write to disk on the
> Indigo works?  Would I still be able to read from disk when delay write
> is happening?  If so, how much time is given to the delay write and how
> much time is given to my program's read?  Is there a way to adjust the
> time slices?
> 
> I have a program that is doing a lot of writing to disk.  I also have
> another program that reads from disk.  When the delay write is finally
> writing to disk, my read seems to be stopped.  The indigo is running
> IRIX release 4.0.1 and has a R3000 processor.

That's because of disk sorting.  A one-way sort is used to minimize
seek and latency.  With delayed writes, you may get a flurry of
contiguous writes which will be completed before you can continue
reading.

jeremy
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: chown and symbolic links
Date: 7 Oct 92 23:17:01 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <32939@adm.brl.mil>, blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB) writes:
> 
>      Recently our system administrator changed all our user ids, this was so
> each user would have the same id on all machines.  He used chown -R to change
> the uid on each users home directory.  Everything seemed ok, however, when I
> was doing a long listing of a directory, I notice that the ownership of NONE
> of the symoblic links had changed.  We couldn't find any way of changing the
> ownership of symbolic links.  Is this a bug, or a feature?!  I CAN delete the
> symbolic links and then recreate them, but, I have quite a few of them and
> would prefer a better way.  Thanks.


EFS symbolic links have always been different from FFS (a.k.a. UFS)
symbolic links in that chown only affects the target of the link and
not the link itself.

We always thought that made good sense because the permission bits,
group and owner on a symbolic link are useless.  Deleting and renaming
of symbolic links (like files but unlike directories) is entirely
controlled by the permission bits, group, and owner of the directory or
directories containing the symbolic links.

In other words, at this time you cannot change symbolic links, but that
should not matter.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.sys.sgi
From: "alan kennedy" <alan.kennedy@canrem.com>
Subject: cs12 info
Reply-To: "alan kennedy" <alan.kennedy@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 10 Oct 92 14:26:51 EST

to: jonathan@vort.cuc.ab.ca

Jonathan:

I also have a CS12 a.k.a. 4D60 and can probably give you all the info
you need. I'm an animator, not a technician, so it may take a little
longer, but I have a good working knowlege of SGI boxes.

Alan Kennedy - alan.kennedy@canrem.com
The Image Group
Toronto, Ontario
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.sys.sgi
From: srfergu@rufus.erenj.com (Scott Ferguson)
Subject: Test
Organization: Exxon Research & Engineering Co.
Date: Fri, 9 Oct 1992 16:50:49 GMT

This is a test. Sorry......
--
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: How to recorve /unix file
Date: 8 Oct 92 01:39:35 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Oct6.202800.1@evax0.eng.fsu.edu> super@evax0.eng.fsu.edu writes:
|    I got a problem with my SGI about sending a mail. I accidently deleted
| the file /unix. So when I try to send a mail by typing "mail", I simply 
| got the following error message:
| 
| libmld: ldopen:cannot open /unix
| 
| As I knew, the executive file libmld.a is located in /usr/lib, what does the
| extertion .a  mean ?  How can I recorve the file /unix (How can I create /unix
| file). 

*Before* you reboot, reset, or anything else, do this:
	/etc/autoconfig -f
	mv /unix.install /unix
(the latter shouldn't normally be done, as it may make umounts
fail during shutdown, and is done by the shutdown code automatically,
but in this case, the kernel should be identical, and there is
no reason to reboot.

(If you are running 3.3, use /etc/init.d/autoconfig without the -f).

I'd recommend not running as root though, so this kind of accident
doesn't happen again, with worse consequences...
--
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: Indigo/r4k -- better machine, crummier monitor
Date: 8 Oct 92 19:47:59 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Oct8.140658.29788@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes:

| In article <qqa2no0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
| >It isn't just QA, it is partly driven by prices the marketing people
| >want to achieve.  The process is affected by a surprisingly large
| >part of the company, not all of whom understand the ramifications,
| >or at least, don't think the change is enough to matter.  Sometimes, 
| >from rev to rev, the changes don't look bad, but when you look
| >over the whole series of changes, it can be pretty depressing.
| 
| Does SGI want to be the best "graphics" company in the world or not?

Speaking only for myself, my perception is that you get a different
answer from different parts of the company.  At the low end, I have
seen decisions made that seem to indicate that we want to be the
best graphics company *for a given price point*.  It turns out the
monitors contribute a fairly high percentage of the system price
at the low end.  To repeat, these are my opinions, official policy
may differ.

(For those of you may wonder about my more frequent disclaimers lately,
no, nobody is clamping down on me, I just seem to be saying more
things that could be rather controversial lately ;), so I'm being
a bit more careful!)
--
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: Hacking Back To The Stone Ages
Date: 10 Oct 92 07:57:17 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <5262@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:
| But what about the development environment?
| 
| (accom): foobar.c, line 5098: accom: Internal:   Switch table overflow.
|    Cannot continue compilation.  The current size was specified as or
|    defaulted to -Wf,-Ng500 giving a table size of 500.  Recompile giving
|    a command line option to increase the table size.
|    Example option giving a larger table: -Wf,-XNg1000
| 
| Didn't these so-called dynamically sized structures go away when we
| discovered realloc() ...?

They aren't really dynamically allocated in the sense you mean.
They are statically allocated at init time.  Chock it up to
old designs.  At least you *can* use larger tables.  I've used
all too many compilers where you were hosed if the tables overflowed.

Someday, there will be a new compiler (really new, that is, not just
modified in places)...
--
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: gmt@mosquito.cis.ufl.edu (Gary McTaggart)
Newsgroups: comp.sys.sgi
Subject: email address for a sales rep?
Date: 7 Oct 92 10:47:15 GMT
Organization: Univ. of Florida CIS Dept.

Could someone send me an email address for a sales representative or if
there is a sales rep reading this, could you give me some information about
the Workshop package?

Thanks,
Gary McTaggart
From: huhman@iscsvax.uni.edu
Newsgroups: comp.sys.sgi
Subject: re: IP12 client nfs slow
Date: 14 Oct 92 07:44:47 GMT
Article-I.D.: iscsvax.1992Oct14.124448.7636
Organization: University of Northern Iowa

In article <32952@adm.brl.mil>, andersen@marvin.ama.ttu.edu (Kim Andersen) writes:
> In article <1992Oct6.073123.15209@crow.omni.co.jp> Timothy Richards 
> <trich@crow.omni.co.jp> writes:
> 
>> The results seem to show that nfs is very slow from the IP12
>> machines.  The measurements were taken when the network usage
>> was very low.

I agree.  Our 8 IP12 machines have terrible NFS performance.
> 
> There is a known bug in 4.0.1 which doesn't handle the IP12 ethernet chip
> properly (or something).  Compile and run this program in background as root.
> Your nfs performance should increase at least tenfold.
> 
> This problem is supposed to be fixed in 4.0.5.

I put 4.0.5b on one machine with less than 10% performance improvement.  Has
anyone else seem a 10 fold improvement?  Should I still be putting this patch
on?  Thanks,
Stan
319 292 8687
Newsgroups: comp.sys.sgi
From: emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van)
Subject: Summary: FILE *yyin=stdin; not ANSI-C??
Organization: University of Twente
Date: Sat, 10 Oct 1992 22:02:26 GMT

In my original posting i wrote:
>The following looks to me perfectly legal ANSI-C code.
># include <stdio.h>
>FILE *yyin = {stdin}, *yyout = {stdout};

You netters, thanks for all the comment i got, here's a summary:
I got some comment on the braces, but they make no difference and are
not illegal (mind you, i have not checked, but a variable is an aray of
length 1?).
An other point is that the standard does not require stdin, stdout and
stderr to be constants (ANSI 4.9.1).
In fact someone from Silicon Graphics told me they are not in the cc
version i am using.
Therefor the solution should be to use:
  FILE *yyin;
  yyin = stdin;
However, there is on problem. I dit not think the initialization
construct up myself, but it was generated by LEX/YACC a long time ago.
Maybe i should try what the current version of LEX/YACC generates and
regenerate from the original LEX/YACC code.
-- 
Pieter van Emmerik                    | Phone:  +31-74-464231
HDS info management                   | FAX:    +31-74-464110
P.O.box 23                            | E-mail: emmerik@utwente.nl
7550 AA  Hengelo, The Netherlands     |         hp4nl!utrcu1!emmerik
From: jeremy@classic.asd.sgi.com (Jeremy Higdon)
Newsgroups: comp.sys.sgi
Subject: Re: Bug in SGI's malloc?
Date: 8 Oct 92 20:35:10 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Oct8.173404.24957@sol.ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
> In article <1b1kggINNp0d@perm.geologie.uni-freiburg.de> achim@perm.geologie.uni-freiburg.de (Achim Staerk) writes:
> >
> >We are running a couple of SGI's with IRIX 4.0.2:
> >
> >How can it be, that C's malloc allocates memory up to the datasize
> >limit defined in the csh (which is 524288 kbytes) and doesn't care
> >about physical limitations ?
> >
> >Malloc should return a NULL pointer when physical memory is exceeded!!
> 
> No, it "should" return a NULL pointer when physical+swap has been exceeded.
> 
> This is a FAQ in this newsgroup, and has been rehashed many times.  I
> agree with the poster, except for the caveat in my last paragraph;  be 
> that as it may, there is a kernel mod that can be effected to make SGI's 
> malloc() behave "normally."  SGI considers the actual behavior to be
> a feature, not a bug.

As do the people who requested it.  My understanding is that there are
some folks out there who have huge processes that want to do a quick fork
and exec.  With traditional memory accounting, they would have to have
enough memory for double the process size, even though the forked process
was only going to exec something small.  Other folks had huge sparse
matrices that took a lot of virtual memory, but actually used very
little physical memory.

If you want to have all virtual memory backed by phycical memory + swap,
then you can set availsmem_accounting in /usr/sysgen/master.d/kernel
and rebuild your kernel.

jeremy
Newsgroups: comp.sys.sgi
From: sarang@hyperion.wustl.edu (Sarang Joshi)
Subject: SGI Flight Simulator.
Reply-To: sarang@hyperion.wustl.edu (Sarang Joshi)
Organization: Washington University, St. Louis MO
Date: Wed, 7 Oct 1992 22:04:03 GMT

This is regarding the SGI Flight Simulator. We we would appreciate if any one
has the source code available. If it's not in PD where can we get the details
of the format used for the Broadcast UDP packets as we would like to
interface it with our own programs. We would also appreciate if some one has
the Airshow file format. By the way dose any one have airplane geometries in
FLIP or other standard format?

Thanks in advance

Sarang
sarang@hyperion.wustl.edu
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: Local network slowdowns
Date: 15 Oct 92 04:07:04 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Oct14.191005.5551@cs.wayne.edu>, atems@igor.physics.wayne.edu (Dale Atems) writes:
> We have 3 R3K Indigos, a 4D/440, and 2 R4K Indigos on a network. We
> have noticed a problem affecting 2 of the R3K Indigos and the 440 that
> occurs very seldom, but is very troublesome when it does:
> network-dependent functions on the affected machines slow to a crawl,
> but the problem seems to be one-way. That is, telnet *to* one of the
> affected machines connects immediately but takes over half a minute to
> return with a login prompt. rlogin takes about the same time. However,
> telnet or rlogin out *from* one of those machines to one that is not
> affected doesn't take any longer than normal. Mail behaves similarly:
> affected machines are quick to send, slow to receive. The problem
> usually disappears spontaneously after an hour or so, and doesn't
> coincide with periods of high network traffic.
> 
> Another case that occurred just today: all of these machines were
> rebooted at about the same time. On one of the machines, which mounts a
> nfs volume exported by another, mount reported that the server was not
> responding and timed out, but eventually did mount the volume.
> 
> The thing that distinguishes the affected machines from those that
> aren't is apparently that the affected machines are all running NFS.
> However, the 440, which *is* affected, doesn't actually mount or
> export any NFS volumes.  We are considering opening a TAC call but
> can't reproduce the problem reliably, so we are reluctant. Has anybody
> observed anything similar, or might the experts have any ideas as to
> what we are doing wrong?
> 
> BTW, of the affected Indigos, the NFS server is running 4.0 and the
> client is at 4.0.5A. The 4D/440 is running 4.0 also.


Without poking around on the machines themselves, it is impossible
to reliably diagnose the problem.

However, my guess is that something is broken in the network.
Bad transcievers.  Excessively long cables.  Violations of
any of the familiar rules, from using "coax drop cables" with thinnet
to SQE messing up mux boxes.

My second guess is that the a NIS server is broken.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.sys.sgi
From: gof@casbah.acns.nwu.edu (Gerald Fountain)
Subject: What's the diff: Indigo vs. Crimson?
Organization: Northwestern University, Evanston Illinois.
Date: Fri, 16 Oct 1992 03:05:47 GMT

I have been attempting to make some machine comparisons (mainly benchmark
data) and someone raised a question.  What is the difference between a Crimson
and an Indigo (both R4K)?  Someone stated that the Crimson was basically the
same machine in a bigger box and more expansion abilities (more slots and
bays).  Can someone straighten me out on the issue?

Thanks,

-- 
Jerry Fountain                       
Northwestern University                        gof@stokes.chem-eng.nwu.edu
Department of Chemical Engineering             (708) 491-3555 (Office)
2145 Sheridan Road, Evanston, IL  60208        (708) 491-3728 (FAX)
Newsgroups: comp.sys.sgi
From: taylorf@sweetpea.jsc.nasa.gov (Frank S. Taylor IV 283-4278)
Subject: Re: PLEASE!  read the group before asking questions.
Organization: McDonnell Douglas Space Systems Company
Date: Wed, 14 Oct 1992 12:30:15 GMT

In article <1992Oct13.200751.27379@cc.ic.ac.uk>, vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:
|> In article <r0s5rt0@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
|> - Recently there have been a series of requests for various pieces of
|> - information that have already been asked within the past few weeks.
|> .....
|> - 
|> - I know that we don't have an FAQ for the group, but still, please
|> - check the recent articles before asking again.
|> 
|> A FAQ would definitely help.
|> 
-- 
Let's not forget that there are plans to break this newsgroup up into
separate sections.  This should help alleviate some of the traffic in 
specific areas (I believe there was going to be a comp.sys.sgi.newusers
type group?).

Regardless, I believe a FAQ is definitely in order.  I would be willing to
help write some section of the FAQ.  Those of you who have offered to
organize the effort, please feel free to contact me.

----------------------------------------------------------------------------
Frank S. Taylor IV  -  McDonnell Douglas Space Systems Company
16055 Space Center Blvd., Houston, Tx  77062
(713) 283-4278 (Voice)  ||  (713) 283-4020 (Fax)
taylorf@sweetpea.jsc.nasa.gov
----------------------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: shenkin@still3.chem.columbia.edu (Peter Shenkin)
Subject: Re: Bug in SGI's malloc?
Organization: Dept. of Chem, Columbia U, New York
Date: Tue, 13 Oct 1992 19:00:27 GMT
X-Posted-From: still3.chem.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <Oct13.182113.66166@yuma.ACNS.ColoState.EDU>
 jamison@yuma.ACNS.ColoState.EDU (Jamie Gulden) writes:

>I don't mean to harp on this (well, maybe I do) but I do not
>agree with the default sgi malloc implementation.  However, I
>do agree with the guy who asks for a way to control it on a
>per process basis....

I have given this some more thought since my last posting;  I
appreciate the thoughtful responses of D.O. and others, and I was 
surprised to hear that other vendors are also beginning to do what 
SGI now does by default.

The worst part about the present system is that there is simply
no way, under the default behavior, that I can, even using a
complicated scheme, look for a swap problem and exit gracefully with
an explanatory warning.  For example, I considered the following:

	After malloc(), touch every page in the arena to reserve
	swap space; trap a signal and exit with an instructive message
	if problems arise.

However, the signal sent by the system is a KILL, which cannot be
trapped;  therefore there is no way to do this.  So the best I can
do is:

	Print a message to the effect:  "If <program-name> is killed
	by the system before the next output, you have insufficient
	memory+swap to run the job on this large a data set."

	Touch malloc pages.

	Print a message to the effect: "Whew -- you made it."

Furthermore, there is no way I can even detect at run time what
the behavior of the machine I am running on is -- or is there?

I fully accept that SGI's default behavior solves some problems.
Speaking more philosophically, (1) people who claim to need this
behavior to allocate sparse matrices, only parts of which are
actually accessed, should be shot;  they should be using sparse-
matrix storage techniques.  See the "Numerical Recipes" column
in the Jul/Aug "Computers in Physics" for references.  (2) what
was wrong with requiring people who suffered from the fork() problem
to use vfork(), which IRIX no longer supports?  In any case, the
whole problem points out real deficiency in the very concept of 
fork() as a general mechanism for spawning a new process -- and this
seems to me to be a real deficiency at the heart of UNIX.

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Columbia Univ.,  New York, NY 10027
(212)854-5143      shenkin@still3.chem.columbia.edu      shenkin@cunixf.BITNET
*********************** UNIX:  the wave of the present ***********************
Newsgroups: comp.sys.sgi