Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02346; 27 Feb 90 13:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01904; 27 Feb 90 13:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01658; 27 Feb 90 13:00 EST Received: from relay.nswc.navy.mil by SMOKE.BRL.MIL id aa25411; 27 Feb 90 11:11 EST Date: Tue, 27 Feb 90 11:13:29 EST From: mberger@relay.nswc.navy.mil To: info-iris@BRL.MIL, uceng!trohling@iuvax.cs.indiana.edu Subject: Re: executable size Message-ID: <9002271111.aa25411@SMOKE.BRL.MIL> You can use the "strip" command which removes the symbol table and relocation bits. Using strip can reduce our executables by about a third.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07616; 27 Feb 90 18:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07575; 27 Feb 90 18:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07567; 27 Feb 90 18:33 EST Received: from ANCHOR.RUTGERS.EDU by SMOKE.BRL.MIL id aa04757; 27 Feb 90 17:20 EST Date: Tue, 27 Feb 90 13:47 EST From: Greg Hamm Subject: Help needed: Does anyone have a berkeley lpd running on Irix? To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <9002271720.aa04757@SMOKE.BRL.MIL> We're trying to get a few SGI's set up in a sea of VAX/VMS and bsd Unix boxes. Tying together printing services is one of the things we'd like to do, and the best way on the Unix side would seem to be to use the Berkeley 'lpd' scheme. However, this is not provided with Irix, and, so far, we've been unable to find anyone who has lpd up on an Iris. Can anybody out there help? All hints/tips/pointers will be appreciated; I'll summarize here if there are replies of interest. Thanks in advance, Greg - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gregory H. Hamm || Phone: (201)932-4864 Director, Molecular Biology Computing Lab || FAX: (201)932-5735 Waksman Institute/CABM || BITNET: hamm@biovax P.O. Box 759, Rutgers University || Internet: hamm@mbcl.rutgers.edu Piscataway, NJ 08855 * USA || - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09245; 28 Feb 90 0:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08785; 27 Feb 90 23:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08714; 27 Feb 90 23:41 EST Received: from Princeton.EDU by SMOKE.BRL.MIL id aa07172; 27 Feb 90 20:31 EST Received: from acm.Princeton.EDU by Princeton.EDU (5.58+++/2.29/mailrelay) id AA13743; Tue, 27 Feb 90 19:37:13 EST Received: from euterp.Princeton.EDU by acm.Princeton.EDU (5.61/1.98) id AA13056; Tue, 27 Feb 90 19:38:29 -0500 Received: by euterp.Princeton.EDU (5.52/1.95) id AA15898; Tue, 27 Feb 90 19:38:27 EST Date: Tue, 27 Feb 90 19:38:27 EST From: ams@acm.princeton.edu Message-Id: <9002280038.AA15898@euterp.Princeton.EDU> To: info-iris-request@vmb.brl.mil, info-iris@BRL.MIL Subject: Re: Help needed: Does anyone have a berkeley lpd running on Irix? I have got lpd on my irises, you will need to get the source for lpd from uunet.uu.net and the irix patches from bu.edu. The idea is simply grab the lpd source, apply the patch and voila, instant lpr. There is one problem, however, you cannot attacha printer directly to an iris. Also, I am having some problems forcing transcript to work. You can also wait for the next sgi release, which includes lpd. --ams p.s. I am not in my office right now, but I am reasonably certain the patches are at bu.edu. Let me know if you can't find them.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29812; 28 Feb 90 21:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29570; 28 Feb 90 21:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29559; 28 Feb 90 20:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29662; 28 Feb 90 18:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14068; Tue, 27 Feb 90 16:24:04 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 00:12:42 GMT From: Brian Sturgill Organization: University of Utah CS Dept Subject: Re: Intermittent Login Problems Message-Id: <1990Feb27.171242.7976@hellgate.utah.edu> References: <52878@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > We have a Iris 4D running 3.2.1 with: > It recently started behaving strangely - When trying to log in from the console, > the screen will go blank for a couple of minutes and then return to the login > prompt. The behavior seems random. The only unusual message that I could > find in SYSLOG was: > > Feb 21 14:41:22 panda grcond[10521]: In limbo > Feb 21 14:42:07 panda grcond[10521]: Tried and failed 3 times to download > graphics subsystem > > I asked our usual service person and the SGI hotline people and nobody had > seen this message before. > > Any ideas? The main idea I get is that it is odd that SGI does not know about this problem. ALL of our 4D/20's, and our 240GTX have this problem. Looking at our SYSLOGs shows that this occurs 4.51 times per machine per day. Often just before the limbo message we get: ... grcond[5015]: Child process /etc/gl/pandora exited with status 0 I do not know if the exact same mechanism is responsible, but we also had the graphics servers crash so frequently (leaving a very large /core) that I installed /core as a symlink to /dev/null. It seems odd that it is not occuring regularly at SGI on their machines. (Perhaps they have not upgraded to 3.2 yet?) Brian (Sorry if I sound grouchy, but I have been preparing a report about our problems with SGI machines for the last 2 days, and am quite annoyed about the number of problems we are having.)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29812; 28 Feb 90 21:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad29713; 28 Feb 90 21:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29637; 28 Feb 90 21:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00285; 28 Feb 90 19:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03874; Tue, 27 Feb 90 21:18:22 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 04:02:47 GMT From: Andrew Myers Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Intermittent Login Problems Message-Id: <4672@odin.SGI.COM> References: <52878@bu.edu.bu.edu>, <1990Feb27.171242.7976@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Feb27.171242.7976@hellgate.utah.edu> brian@cs.utah.edu (Brian Sturgill) writes: >> We have a Iris 4D running 3.2.1 with: >> prompt. The behavior seems random. The only unusual message that I could >> find in SYSLOG was: >> >> Feb 21 14:41:22 panda grcond[10521]: In limbo >> Feb 21 14:42:07 panda grcond[10521]: Tried and failed 3 times to download >> graphics subsystem >> >Often just before the limbo message we get: > > ... grcond[5015]: Child process /etc/gl/pandora exited with status 0 This message is perfectly normal, as is the limbo message. If your system starts failing to download microcode, I think you can get around it by logging in NOGRAPHICS, then logging out. This should reset the graphics more thoroughly than pandora can. I'm not sure how the state of the graphics gets corrupted in this way. Andrew   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00412; 28 Feb 90 22:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00293; 28 Feb 90 22:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29972; 28 Feb 90 21:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00712; 28 Feb 90 20:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25937; Tue, 27 Feb 90 11:59:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 17:36:14 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: meant to add a thanks Message-Id: <477@meritaus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sorry for another posting... I meant to append this to my earlier posting... I wanted to thank everyone who offered to ship me the TeX distribution. Chuck Adams of SGI in Dallas fulfilled my request in a couple of days (thanks again, Chuck). thanks again to everyone! -- dan haug ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan ``When all you have is a hammer, everything begins to look like a nail.''   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00412; 28 Feb 90 22:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id af00293; 28 Feb 90 22:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00205; 28 Feb 90 22:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01008; 28 Feb 90 20:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19314; Tue, 27 Feb 90 10:13:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 15:12:04 GMT From: Mark Galassi Organization: Institute for Theoretical Physics, SUNY at Stony Brook Subject: Re: NNTP / other news software Message-Id: <1990Feb27.151204.11533@max.sunysb.edu> References: <9002230726.aa00531@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002230726.aa00531@SMOKE.BRL.MIL> S090726@UMRVMA.UMR.EDU (Bob Funchess) writes: >Has anyone ported nntp or anything like it to the 4D platform? What >do the people in this newsgroup use to get their news? I have nntp/cnews/rn/rrn/all sorts of stuff running on an SGI 4D/220. I had some trouble, but not too much. I cannot remember any more what I did to get the various things to compile, but I mostly just tried the usual porting tricks. -- {These opinions are mine, and should be everybody else's :-)} Mark Galassi rosalia@dirac.sunysb.edu rosalia@mozart.UUCP rosalia@sunysbnp.BITNET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00412; 28 Feb 90 22:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag00293; 28 Feb 90 22:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00258; 28 Feb 90 22:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01266; 28 Feb 90 20:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14706; Tue, 27 Feb 90 09:07:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 17:02:33 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: Intermittent Login Problems Message-Id: <52878@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a Iris 4D running 3.2.1 with: 2 25 MHZ IP7 Processors FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 2.0 CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0 Data cache size: 64 Kbytes Instruction cache size: 64 Kbytes Main memory size: 16 Mbytes GT Graphics option installed Integral Ethernet controller Integral SCSI controller WD33C93 Disk drive: unit 2 on SCSI controller 0 Disk drive: unit 1 on SCSI controller 0 Tape drive: unit 7 on SCSI controller 0: QIC 150 It recently started behaving strangely - When trying to log in from the console, the screen will go blank for a couple of minutes and then return to the login prompt. The behavior seems random. The only unusual message that I could find in SYSLOG was: Feb 21 14:41:22 panda grcond[10521]: In limbo Feb 21 14:42:07 panda grcond[10521]: Tried and failed 3 times to download graphics subsystem I asked our usual service person and the SGI hotline people and nobody had seen this message before. Any ideas? -e ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00513; 28 Feb 90 22:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00293; 28 Feb 90 22:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29961; 28 Feb 90 21:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00531; 28 Feb 90 19:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00497; Tue, 27 Feb 90 13:03:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 17:51:25 GMT From: "Calvin H. Vu" Subject: Re: another f77 core dump Message-Id: <4609@odin.SGI.COM> References: <1010@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1010@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: >Another program which produces an f77 core dump. Yes, I know rules of use :-) > block data junk > common/junk/ a > end >Again the message: >Error on line 3 of test.f: junk cannot be a common block name >Fatal error in: /usr/lib/fcom - core dumped > Signal 139 Consider yourself lucky that you get an intelligible error message out before the coredump :-) :-). ANyway, this has been fixed in our next release. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >John H. Merritt # Yesterday I knew nothing, >Applied Research Corporation # Today I know that. >merritt@iris613.gsfc.nasa.gov # Calvin Vu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00513; 28 Feb 90 22:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00293; 28 Feb 90 22:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00155; 28 Feb 90 22:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00880; 28 Feb 90 20:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19956; Tue, 27 Feb 90 17:49:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 23:07:41 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: /dev/mmem 666 out of the box. Why? Message-Id: <4632@odin.SGI.COM> References: <13851@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /dev/mmem is the mapped device interface to /dev/mem - however the allowed set of mappings is determined by a table located in /usr/sysgen/master/mem - currently that contains only the sound chip and ecc memopry logging ram - neither of these is a security issue - though it is true that one user could interfere with another... The sound chip is mainly used to playing around with Chris Wagner   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08197; 1 Mar 90 10:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07701; 1 Mar 90 10:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07090; 1 Mar 90 9:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09594; 1 Mar 90 9:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20828; Tue, 27 Feb 90 10:35:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 16:18:28 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: NeWS windows and GL windows Message-Id: <476@meritaus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What is the relationship between NeWS windows and GL windows? When I call winopen(), the resulting window looks suspiciously similar to "framebuffer /new DefaultWindow send". Does the GL library create a NeWS window to coincide with the internal GL window? Or is it the other way around? I've looking through the documentation and haven't found this addressed anywhere. Did I miss it? If there exists a NeWS window instance that corresponds to the GL window, how can one access it (e.g. thru CPS, but how does one access the actual instance)? Can I change the value of DefaultWindow and expect subsequent winopen()'s to reflect this change? (e.g. suppose I want my GL windows to have scroll bars, and hence, use the ScrollWindow class). I need to be enlightened. Thanks... -- dan haug ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan ``When all you have is a hammer, everything begins to look like a nail.''   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01772; 2 Mar 90 16:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01534; 2 Mar 90 16:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01339; 2 Mar 90 16:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16513; 2 Mar 90 14:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09551; Fri, 2 Mar 90 11:25:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 21:57:21 GMT From: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!1k1mgm@tut.cis.ohio-state.edu Organization: University of Kansas Academic Computing Services Subject: Power Iris memory sources, please? Message-Id: <22373.25eaa363@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Apologies in advance.... I felt sure I saved last post (~2 mo. ago) concerning 3rd party sources for Power Iris [4D/2x0] memory. Now I can't find it. I could really use leads on such sources for proposal I'm writing. Mail is obviously best but please post, if you're willing, if mail doesn't seem to want to go through. Filled with anticipatory gratitude, I am, Christopher Gunn Molecular Graphics & Modeling Lab SPAN--KUPHSX::SYBYL Department of Medicinal Chemistry 913-864-4428 or -4495 University of Kansas, Lawrence, KS 66045   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15965; 28 Feb 90 10:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15199; 28 Feb 90 10:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14964; 28 Feb 90 9:53 EST Received: from gemini.arc.nasa.gov by SMOKE.BRL.MIL id aa16115; 28 Feb 90 9:11 EST Received: Wed, 28 Feb 90 06:13:46 PST by gemini.arc.nasa.gov (5.57/1.2) Received: Wed, 28 Feb 90 06:13:41 PST by gemini.arc.nasa.gov (5.57/1.2) From: "RICHARD P. SIMONIAN" Date: Wed, 28 Feb 90 06:01 PST Message-Id: To: INFO-IRIS@BRL.MIL Subject: RE2 Performance X-Lines: 11 Does anyone have statistics on how the RE2 chip affects performance on the Personal Iris? I'm particularly interested in X-windows performance. Rick Simonian Harris Space Systems Corp. rsimonian@nasamail.nasa.gov or... rsimonian%nasamail@ames.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18009; 28 Feb 90 11:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16710; 28 Feb 90 10:57 EST Received: from tbd.brl.mil by VMB.BRL.MIL id aa16611; 28 Feb 90 10:35 EST Date: Wed, 28 Feb 90 10:25:06 EST From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.MIL cc: brian@cs.utah.edu, gwyn@BRL.MIL Subject: preventing core dumps Organization: U.S. Army Ballistic Research Laboratory, APG, MD Message-ID: <9002281025.aa22228@TBD.BRL.MIL> Brian Sturgill wrote that he prevents IRIX from making core dumps by making a symbolic link for /core to /dev/null. I've been accomplishing the same by making a zero length core with mode 0. But I really wish the operating system designers would provide an environment variable $NO_CORE or the like that could be used to prevent core dumps. ...Glenn Randers-Pehrson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28999; 28 Feb 90 18:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28779; 28 Feb 90 17:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab28607; 28 Feb 90 17:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27983; 28 Feb 90 16:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29455; Wed, 28 Feb 90 12:32:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 19:43:15 GMT From: Fisher Organization: David Taylor Research Center, Carderock, MD Subject: Memory prices Message-Id: <1127@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have misplaced my list of third party memory suppliers for SGI workstations. Could someone E-mail them to me at scfisher@dtoa1.dt.navy.mil? Thanks steve   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29055; 28 Feb 90 18:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28495; 28 Feb 90 17:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28403; 28 Feb 90 17:07 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa20377; 28 Feb 90 11:29 EST Received: from relay2.cs.net by RELAY.CS.NET id aa17731; 28 Feb 90 10:26 EST Received: from gmr.com by RELAY.CS.NET id ad18637; 28 Feb 90 11:22 EST Date: Wed, 28 Feb 90 10:53 EST From: JORDAN%gmr.com@relay.cs.net Subject: ar - the archiver To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.mil" Message-ID: <9002281129.aa20377@SMOKE.BRL.MIL> Can someone give me any tips on using ar, or lead me to any books that might be able to help me. I am able to create a library, add objects, and update symbol tables (e.g. ar cr lib.a a.o b.o, or ar ts lib.a), BUT I would like the compilerr to recognize it via a flag; for example, the way it recognizes -Zg, or -lgl_s. Thanks for any help... tp mugabi-jordan gm systems engr ctr   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29173; 28 Feb 90 19:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28495; 28 Feb 90 17:22 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa28330; 28 Feb 90 17:03 EST Received: from cunyvm.cuny.edu by ADM.BRL.MIL id aa00190; 28 Feb 90 15:22 EST Received: from ITNVAX.CINECA.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0704; Wed, 28 Feb 90 11:59:15 EST Message-id: <2478@ITNVAX.CINECA.IT> Date: Wed, 28 FEB 90 17:45 N From: "VALTER V. CAVECCHIA - C.N.R. I-38050..." Reply-To: CAVECCHIA%ITNVAX.CINECA.IT%ICINECA2.BITNET@cunyvm.cuny.edu Comments: INFN.IT domain is equivalent to BITNET domain: INFNET; INFNET has been disestablished Dec 31, 1988 Subject: GIF Previewer for Personal Iris To: INFO-IRIS@BRL.MIL X-Original-To: info-iris@brl.mil, CAVECCHIA Does anyone know if ther exists a GIF (the graphics standard of Compuserve) previewer for the Personal Iris ? A public domain version would be very appreciate.... Thanks a lot to all --------------------------------------------------------------------------- | Valter V. Cavecchia | Bitnet: cavecchi@itncisca | | Centro di Fisica del C.N.R. | cavecchia@itnvax.cineca.it | | I-38050 Povo (TN) - Italy | Decnet: itnvax::cavecchia (37.65) | ---------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29713; 28 Feb 90 21:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29570; 28 Feb 90 21:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29568; 28 Feb 90 20:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29832; 28 Feb 90 18:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06689; Wed, 28 Feb 90 14:23:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 22:02:54 GMT From: Jim Disbrow Organization: NASA Ames-Dryden FRF, Edwards, CA Subject: tar, 3030 <=> sun Message-Id: <437@skipper.dfrf.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there some reason why a tar tape created on a 3030 series machine can't be read on a Sun 3/280? Is it just me, or has anyone else experienced difficulties. Blocking factors are the same, the 3030 tar seems to have 512 byte records that can't (according to the man page) be changed. the man page on the Sun doesn't say what byte record it uses, or how to change that either. Any help would be appreciated. Thanx a lot, Jim Disbrow work: 805/258-3417 internet: disbrow@skipper.dfrf.nasa.gov -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Brain. Brain. What is brain? -- Kara the Eymorg, "Spock's Brain," stardate 5432.3.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29713; 28 Feb 90 21:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29570; 28 Feb 90 21:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab29568; 28 Feb 90 20:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29835; 28 Feb 90 18:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06609; Wed, 28 Feb 90 14:21:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 21:29:25 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Help needed: Does anyone have a berkeley lpd running on Irix? Message-Id: <52216@sgi.sgi.com> References: <9002271720.aa04757@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A port of lpd is in the next IRIX release (called variously 3.3, Aspen or Birch; I don't know what the name will be in the "real world"). We don't really intend it as a general replacement for the lp spooler system, though; mainly to allow SGI machines to send requests to BSD print servers. The BSD code won't port directly to IRIX 3.2 for various compatibility reasons, though these could be worked around. I'd be inclined to wait for the official version, but if you are really in a hurry email me & I can give you some pointers. Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29812; 28 Feb 90 21:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29713; 28 Feb 90 21:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29627; 28 Feb 90 21:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00161; 28 Feb 90 19:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10889; Wed, 28 Feb 90 15:44:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 23:26:08 GMT From: "Roger B.A. Klorese" Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Re: tar, 3030 <=> sun Message-Id: <36538@mips.mips.COM> References: <437@skipper.dfrf.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <437@skipper.dfrf.nasa.gov> disbrow@skipper.dfrf.nasa.gov (Jim Disbrow) writes: >Is there some reason why a tar tape created on a 3030 series machine >can't be read on a Sun 3/280? Is it just me, or has anyone else >experienced difficulties. Blocking factors are the same, the 3030 tar >seems to have 512 byte records that can't (according to the man page) >be changed. the man page on the Sun doesn't say what byte record it >uses, or how to change that either. SGI systems write their tapes byte-swapped. You must do the following: dd if= conv=swab | tar xf - -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 MS 4-02 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I'm the NLA" "Two guys, one cart, fresh pasta... *you* figure it out." -- Suzanne Sugarbaker   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00293; 28 Feb 90 22:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29958; 28 Feb 90 22:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29902; 28 Feb 90 21:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28568; 28 Feb 90 17:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23999; Wed, 28 Feb 90 11:18:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 18:20:16 GMT From: Tom Mitchell Organization: Silicon Graphics Computer Systems, Mountain View CA. 94039 Subject: Re: PI Problems with rcp Message-Id: <4686@odin.SGI.COM> References: <9002220905.aa28986@VAT.BRL.MIL>, <51649@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <51649@sgi.sgi.com> brendan@illyria.wpd.sgi.com (Brendan Eich) writes: * In article <9002220905.aa28986@VAT.BRL.MIL>, jra@BRL.MIL ("John R. Anderson", VLD/ASB) writes: * > 1. The other day, I changed the net addresses on our PI's, and * > at the same time I happened to place a notice to the user's in /etc/motd. * > Afterwards, "rcp" no longer worked correctly. * The BSD rcp protocol is fragile: as the friendly manual page says in its * BUGS section: * * [Rcp is] confused by any output generated by commands in a .login, * .profile, or .cshrc file on the remote host. * Good stuff about 'cat'ing the motd. One other common hit on this same problem is with the shell prompt. It is useful to ALWAYS check to see it the prompt variable exists and then iff it exists set it to your liking. EXAMPLE for csh: if ($?prompt) set prompt = "csh--`hostname`[\!] " I learned this the hard way with the take option of BSD's tip program. What if one did: "if ($?prompt) cat /etc/motd"? Thomas P. Mitchell -- mitch@sgi.com "All things in moderation; including moderation."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00412; 28 Feb 90 22:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00293; 28 Feb 90 22:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00184; 28 Feb 90 22:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00962; 28 Feb 90 20:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22475; Wed, 28 Feb 90 10:57:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 17:49:40 GMT From: Tom Mitchell Organization: Silicon Graphics Computer Systems, Mountain View CA. 94039 Subject: Re: malloc question Message-Id: <4684@odin.SGI.COM> References: <9001181348.aa27967@ADM.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9001181348.aa27967@ADM.BRL.MIL> XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: * I've just found a behaviour in a program, that I don't understand. * .... Does it mean that free(...) frees the memory allocated by the * process for future use, but does not return the virtual memory? Yes. malloc is a memory allocator tool. It will sbreak from the system as needed. free() returns memory to the malloc library not to the system. Perhaps the best way to understand malloc is to look inside. As luck has it there is a 'public' malloc within Larry Wall's "perl" package. So unlike AT&T code which we cannot look under the hood at, here is malloc. As an aside lwall's configure scripts within perl are near AI in searching out the differences of one UNIX and another. They are worth looking at. Enjoy ======= snip ========= malloc from the public 'perl' of lwall. This code has its origns at BSD/CAltech etc. --- cut ---- #ifndef lint static char sccsid[] = "@(#)malloc.c 4.3 (Berkeley) 9/16/83"; #define RCHECK /* * malloc.c (Caltech) 2/21/82 * Chris Kingsley, kingsley@cit-20. * * This is a very fast storage allocator. It allocates blocks of a small * number of different sizes, and keeps free lists of each size. Blocks that * don't exactly fit are passed up to the next larger size. In this * implementation, the available sizes are 2^n-4 (or 2^n-12) bytes long. * This is designed for use in a program that uses vast quantities of memory, * but bombs when it runs out. */ #include "EXTERN.h" #include "perl.h" /* I don't much care whether these are defined in sys/types.h--LAW */ #define u_char unsigned char #define u_int unsigned int #define u_short unsigned short /* * The overhead on a block is at least 4 bytes. When free, this space * contains a pointer to the next free block, and the bottom two bits must * be zero. When in use, the first byte is set to MAGIC, and the second * byte is the size index. The remaining bytes are for alignment. * If range checking is enabled and the size of the block fits * in two bytes, then the top two bytes hold the size of the requested block * plus the range checking words, and the header word MINUS ONE. */ union overhead { union overhead *ov_next; /* when free */ struct { u_char ovu_magic; /* magic number */ u_char ovu_index; /* bucket # */ #ifdef RCHECK u_short ovu_size; /* actual block size */ u_int ovu_rmagic; /* range magic number */ #endif } ovu; #define ov_magic ovu.ovu_magic #define ov_index ovu.ovu_index #define ov_size ovu.ovu_size #define ov_rmagic ovu.ovu_rmagic }; #define MAGIC 0xff /* magic # on accounting info */ #define OLDMAGIC 0x7f /* same after a free() */ #define RMAGIC 0x55555555 /* magic # on range info */ #ifdef RCHECK #define RSLOP sizeof (u_int) #else #define RSLOP 0 #endif /* * nextf[i] is the pointer to the next free block of size 2^(i+3). The * smallest allocatable block is 8 bytes. The overhead information * precedes the data area returned to the user. */ #define NBUCKETS 30 static union overhead *nextf[NBUCKETS]; extern char *sbrk(); #ifdef MSTATS /* * nmalloc[i] is the difference between the number of mallocs and frees * for a given block size. */ static u_int nmalloc[NBUCKETS]; #include #endif #ifdef debug #define ASSERT(p) if (!(p)) botch("p"); else static botch(s) char *s; { printf("assertion botched: %s\n", s); abort(); } #else #define ASSERT(p) #endif char * malloc(nbytes) register unsigned nbytes; { register union overhead *p; register int bucket = 0; register unsigned shiftr; /* * Convert amount of memory requested into * closest block size stored in hash buckets * which satisfies request. Account for * space used per block for accounting. */ nbytes += sizeof (union overhead) + RSLOP; nbytes = (nbytes + 3) &~ 3; shiftr = (nbytes - 1) >> 2; /* apart from this loop, this is O(1) */ while (shiftr >>= 1) bucket++; /* * If nothing in hash bucket right now, * request more memory from the system. */ if (nextf[bucket] == NULL) morecore(bucket); if ((p = (union overhead *)nextf[bucket]) == NULL) return (NULL); /* remove from linked list */ if (*((int*)p) > 0x10000000) #ifndef I286 fprintf(stderr,"Corrupt malloc ptr 0x%x at 0x%x\n",*((int*)p),p); #else fprintf(stderr,"Corrupt malloc ptr 0x%lx at 0x%lx\n",*((int*)p),p); #endif nextf[bucket] = nextf[bucket]->ov_next; p->ov_magic = MAGIC; p->ov_index= bucket; #ifdef MSTATS nmalloc[bucket]++; #endif #ifdef RCHECK /* * Record allocated size of block and * bound space with magic numbers. */ if (nbytes <= 0x10000) p->ov_size = nbytes - 1; p->ov_rmagic = RMAGIC; *((u_int *)((caddr_t)p + nbytes - RSLOP)) = RMAGIC; #endif return ((char *)(p + 1)); } /* * Allocate more memory to the indicated bucket. */ static morecore(bucket) register int bucket; { register union overhead *op; register int rnu; /* 2^rnu bytes will be requested */ register int nblks; /* become nblks blocks of the desired size */ register int siz; if (nextf[bucket]) return; /* * Insure memory is allocated * on a page boundary. Should * make getpageize call? */ op = (union overhead *)sbrk(0); #ifndef I286 if ((int)op & 0x3ff) (void)sbrk(1024 - ((int)op & 0x3ff)); #else /* The sbrk(0) call on the I286 always returns the next segment */ #endif #ifndef I286 /* take 2k unless the block is bigger than that */ rnu = (bucket <= 8) ? 11 : bucket + 3; #else /* take 16k unless the block is bigger than that (80286s like large segments!) */ rnu = (bucket <= 11) ? 14 : bucket + 3; #endif nblks = 1 << (rnu - (bucket + 3)); /* how many blocks to get */ if (rnu < bucket) rnu = bucket; op = (union overhead *)sbrk(1 << rnu); /* no more room! */ if ((int)op == -1) return; /* * Round up to minimum allocation size boundary * and deduct from block count to reflect. */ #ifndef I286 if ((int)op & 7) { op = (union overhead *)(((int)op + 8) &~ 7); nblks--; } #else /* Again, this should always be ok on an 80286 */ #endif /* * Add new memory allocated to that on * free list for this hash bucket. */ nextf[bucket] = op; siz = 1 << (bucket + 3); while (--nblks > 0) { op->ov_next = (union overhead *)((caddr_t)op + siz); op = (union overhead *)((caddr_t)op + siz); } } free(cp) char *cp; { register int size; register union overhead *op; if (cp == NULL) return; op = (union overhead *)((caddr_t)cp - sizeof (union overhead)); #ifdef debug ASSERT(op->ov_magic == MAGIC); /* make sure it was in use */ #else if (op->ov_magic != MAGIC) { fprintf(stderr,"%s free() ignored\n", op->ov_magic == OLDMAGIC ? "Duplicate" : "Bad"); return; /* sanity */ } op->ov_magic = OLDMAGIC; #endif #ifdef RCHECK ASSERT(op->ov_rmagic == RMAGIC); if (op->ov_index <= 13) ASSERT(*(u_int *)((caddr_t)op + op->ov_size + 1 - RSLOP) == RMAGIC); #endif ASSERT(op->ov_index < NBUCKETS); size = op->ov_index; op->ov_next = nextf[size]; nextf[size] = op; #ifdef MSTATS nmalloc[size]--; #endif } /* * When a program attempts "storage compaction" as mentioned in the * old malloc man page, it realloc's an already freed block. Usually * this is the last block it freed; occasionally it might be farther * back. We have to search all the free lists for the block in order * to determine its bucket: 1st we make one pass thru the lists * checking only the first block in each; if that fails we search * ``reall_srchlen'' blocks in each list for a match (the variable * is extern so the caller can modify it). If that fails we just copy * however many bytes was given to realloc() and hope it's not huge. */ int reall_srchlen = 4; /* 4 should be plenty, -1 =>'s whole list */ char * realloc(cp, nbytes) char *cp; unsigned nbytes; { register u_int onb; union overhead *op; char *res; register int i; int was_alloced = 0; if (cp == NULL) return (malloc(nbytes)); op = (union overhead *)((caddr_t)cp - sizeof (union overhead)); if (op->ov_magic == MAGIC) { was_alloced++; i = op->ov_index; } else { /* * Already free, doing "compaction". * * Search for the old block of memory on the * free list. First, check the most common * case (last element free'd), then (this failing) * the last ``reall_srchlen'' items free'd. * If all lookups fail, then assume the size of * the memory block being realloc'd is the * smallest possible. */ if ((i = findbucket(op, 1)) < 0 && (i = findbucket(op, reall_srchlen)) < 0) i = 0; } onb = (1 << (i + 3)) - sizeof (*op) - RSLOP; /* avoid the copy if same size block */ if (was_alloced && nbytes <= onb && nbytes > (onb >> 1) - sizeof(*op) - RSLOP) return(cp); if ((res = malloc(nbytes)) == NULL) return (NULL); if (cp != res) /* common optimization */ (void)bcopy(cp, res, (int)((nbytes < onb) ? nbytes : onb)); if (was_alloced) free(cp); return (res); } /* * Search ``srchlen'' elements of each free list for a block whose * header starts at ``freep''. If srchlen is -1 search the whole list. * Return bucket number, or -1 if not found. */ static findbucket(freep, srchlen) union overhead *freep; int srchlen; { register union overhead *p; register int i, j; for (i = 0; i < NBUCKETS; i++) { j = 0; for (p = nextf[i]; p && j != srchlen; p = p->ov_next) { if (p == freep) return (i); j++; } } return (-1); } #ifdef MSTATS /* * mstats - print out statistics about malloc * * Prints two lines of numbers, one showing the length of the free list * for each size category, the second showing the number of mallocs - * frees for each size category. */ mstats(s) char *s; { register int i, j; register union overhead *p; int totfree = 0, totused = 0; fprintf(stderr, "Memory allocation statistics %s\nfree:\t", s); for (i = 0; i < NBUCKETS; i++) { for (j = 0, p = nextf[i]; p; p = p->ov_next, j++) ; fprintf(stderr, " %d", j); totfree += j * (1 << (i + 3)); } fprintf(stderr, "\nused:\t"); for (i = 0; i < NBUCKETS; i++) { fprintf(stderr, " %d", nmalloc[i]); totused += nmalloc[i] * (1 << (i + 3)); } fprintf(stderr, "\n\tTotal in use: %d, total free: %d\n", totused, totfree); } #endif #endif /* lint */ Thomas P. Mitchell -- mitch@sgi.com "All things in moderation; including moderation."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00749; 28 Feb 90 23:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00665; 28 Feb 90 23:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00660; 28 Feb 90 23:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29889; 28 Feb 90 19:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26949; Wed, 28 Feb 90 05:00:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 08:34:41 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Intermittent Login Problems Message-Id: <52084@sgi.sgi.com> References: <52878@bu.edu.bu.edu>, <1990Feb27.171242.7976@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Feb27.171242.7976@hellgate.utah.edu>, brian@cs.utah.edu (Brian Sturgill) writes: > > [. . .] The behavior seems random. The only unusual message that I could > > find in SYSLOG was: > > > > Feb 21 14:41:22 panda grcond[10521]: In limbo > > Feb 21 14:42:07 panda grcond[10521]: Tried and failed 3 times to download > > graphics subsystem > > > > I asked our usual service person and the SGI hotline people and nobody had > > seen this message before. > > The main idea I get is that it is odd that SGI does not know about this > problem. ALL of our 4D/20's, and our 240GTX have this problem. Do you get the "Tried and failed 3 times to download graphics subsystem" message on all of your 4D/20's, or only some? On your 240GTX? The reason I ask is because very different versions of the grcond program are shipped for different models, according to their graphics hardware, and >only the 240GTX version contains the "Tried and failed" message<. Has someone inadvertently copied the 240GTX's /etc/gl/grcond to a 4D/20? Or does the message you quote in fact occur only on your 240GTX? > Looking at our SYSLOGs shows that this occurs 4.51 times per machine per day. > Often just before the limbo message we get: > > ... grcond[5015]: Child process /etc/gl/pandora exited with status 0 This SYSLOG entry was intended to be informational (LOG_INFO) only, and does not necessarily indicate a problem. Logging successful exit status does not seem useful; perhaps this unduly alarming message should be eliminated. > I do not know if the exact same mechanism is responsible, but we also > had the graphics servers crash so frequently (leaving a very large /core) that > I installed /core as a symlink to /dev/null. The graphics server meaning /bin/news_server? Was there any SYSLOG message from news_server (rather than from grcond) at the time of the coredump? > It seems odd that it is not occuring regularly at SGI on their machines. > (Perhaps they have not upgraded to 3.2 yet?) We're running 3.2, 3.2.1, 3.2.2, and what will become 3.3 in engineering, on hundreds of Iris 4Ds. Generally, engineers install and run a release long before any customers see it. The only troubles I've had with news_server, grcond, and microcode have been during development, when I used mismatched versions. I've heard, but not seen, of GT/GTX microcode problems that occasionally result in SYSLOG messages and graphics crashes. I've had no such problems with my 4D/20 in more than a year; I've been running 3.2 for about six months. > Brian Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03370; 1 Mar 90 7:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03323; 1 Mar 90 7:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab03286; 1 Mar 90 6:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05197; 1 Mar 90 5:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16359; Wed, 28 Feb 90 17:08:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 01:00:29 GMT From: Boyd Knosp Organization: U of Iowa, Iowa City, IA Subject: f77 question/space saver Message-Id: <765@ns-mx.uiowa.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Why do I get this error using f77 on a 4D120GTX: Program x Implicit None Structure /test/ Character*80 text End Structure Record /test/ Myvar Integer*4 I Myvar.text="(Hello)" I=Index(Myvar.text,")") End %f77 x.f Error on line 16 of x.f: bad argument type to intrinsic index Note: The same thing happens with other intrinsic functions when I try to pass subrecords to them. If I assign to a temp var and pass the temp var to the fn instead, it compiles fine... f77 creates huge exectuables. I reduce size by linking with shared libs and 'strip'ing the labels out of them (once they're debugged). It is nice to note that the old unix dynamic memory allocation trick for FORTRAN works with the SGI compiler. Dynamically allocating large arrays also reduces f77 execuatble size. (I have the source code if anyone has need for dynamically allocated FORTRAN arrays) Randy Frank University of Iowa Image Analysis Facility randy@tessa.iaf.uiowa.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04206; 1 Mar 90 8:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03999; 1 Mar 90 8:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03755; 1 Mar 90 7:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06109; 1 Mar 90 6:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29749; Wed, 28 Feb 90 05:35:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 08:33:34 GMT From: Kian-Tat Lim Organization: California Institute of Technology, Pasadena, CA Subject: Re: Intermittent Login Problems Message-Id: <14025@cit-vax.Caltech.Edu> References: <52878@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We went around and around with SGI hotline personnel on this problem last month. It was actually reported in this newsgroup back in December. I finally managed to get a fix out of someone at SGI, but apparently the hotline people have yet to hear about it. The cause of the problem appears to be high CPU load producing timeouts when downloading the graphics microcode into the graphics processor. This supposedly only occurs on multiprocessor systems with at least one processor saturated (100% usage). Apparently SGI didn't really expect us to beat on these boxes... The fix (which you should be able to confirm by talking to Gretchen at the hotline or Momi, who apparently found the problem [sorry, I didn't get last names]) is to change the variable network_processor in file /usr/sysgen/master.d/kernel to 0 (zero) from its default value of 1 (one). You must then run lboot (I used lboot -t -v -d) and reboot with the new kernel. I suppose you might be able to adb the kernel if you were feeling lucky, but neither SGI, I imagine, nor I will sanction that. This fix has cured our problems so far, though we did have one other suspicious hang after the fix when physical memory was very low that has neither recurred nor been explained. -- Kian-Tat Lim (ktl@wagvax.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04396; 1 Mar 90 8:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04206; 1 Mar 90 8:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04171; 1 Mar 90 8:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06240; 1 Mar 90 7:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28850; Wed, 28 Feb 90 20:34:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 23:03:05 GMT From: "Calvin H. Vu" Subject: Re: executable size Message-Id: <4705@odin.SGI.COM> References: <9002271111.aa25411@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I planned to e-mail this to glennrp@brl.mil to respond to his question but since so many people seem to be unaware of this I will make a general posting instead. Here it goes: ---------------------------------------------------------------------- By defaults, f77 uses the libmpc.a library to allow multiprocessing system calls. This MP capability adds about 70K to the executable size as compared to the standard libc.a library. If you can use the shared C library you can cut another 30K from your executable. To use the standard libc.a library all you need to do is to replace the f77 driver with the cc driver i.e. use: (BTW, this will also make your executable runs marginally faster if you don't need MP Fortran) cc -g -G 0 *.o -lfgl -lgl_s instead of: f77 -g -G 0 *.o -lfgl -lgl_s To use the shared libc_s.a library, you need to include all Fortran runtime libraries before the -lc_s to make sure that all C systems calls will be resolved by using the shared library, not the libc.a library. In other words, use: cc -g -G 0 *.o -lfgl -lgl_s -lF77 -lI77 -lU77 -lisam -lm -lc_s The multiply-defined warnings you get when using -lc_s on the command line stems from the fact that those multiply-defined routines are resolved in libc_s.a but are also defined in libmpc.a. This should be O.K. unless you do want to use MP Fortran. In that case forget everything I said above and just use the default f77 driver. The additional 100K is the price you have to pay for this extra MP capability and you will need every bit of it (pun intended). Another major factor which makes Fortran executable size much bigger than C is the libisam.a library which adds over 100K to the size. Currently, this ISAM library is intertwined with the standard runtime I/O library (libI77.a) and will be dragged in even if you do not need ISAM capability. In future releases, we will remove this interdependency to reduce the size of the executable. And of course you can use 'strip' to make the executable even smaller. All in all, after everything is said AND DONE :-), the size of a simple 'hello world' program can probably be reduced from 310K to under 60K. Right now, if you apply all the tricks above you can reduce it to about 140K. Oh well, you never have a REAL Fortran program which is less than 1M anyway, so an extra 100K of overhead is nothing. Right ? Right ? Hmmm, I guess I can't take over Johny Carson's job yet :-). BTW, if you don't have the standard 4 gigabytes of disk space on your standard Unix system and are desperate enough to to go after the 100K+ added by libisam.a you can remove -lisam from the linker command line generated by 'f77 -v' and get a list of undefined references then use dummy procedures for all of them. This is royally painful, but as I said, if you are desperate ... Calvin Vu ----------------------------------------------------------------------- "Don't blame it on RISC. Just blame it on FORTRAN and Rio"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac07015; 1 Mar 90 10:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06287; 1 Mar 90 9:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06081; 1 Mar 90 9:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06265; 1 Mar 90 7:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28634; Wed, 28 Feb 90 20:31:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 22:44:59 GMT From: martin Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Intermittent Login Problems Message-Id: <4703@odin.SGI.COM> References: <52878@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <52878@bu.edu.bu.edu> eap@cs.bu.edu (Eric A. Pearce) writes: > > We have a Iris 4D running 3.2.1 with: > > 2 25 MHZ IP7 Processors > > It recently started behaving strangely - When trying to log in from the console, > the screen will go blank for a couple of minutes and then return to the login > prompt. The behavior seems random. The only unusual message that I could > find in SYSLOG was: > > Feb 21 14:41:22 panda grcond[10521]: In limbo > Feb 21 14:42:07 panda grcond[10521]: Tried and failed 3 times to download > graphics subsystem GTX's running 3.2 and 3.2.1 have this problem when there are jobs in the background. if you have support, call the hotline. if not a temporary fix follows. - edit file /usr/sysgen/master.d/kernel, - change line that reads: int network_processor = 1; to int network_processor = 0; - su to root and cd to /, - type lboot (this will build a new kernel called unix.new in the current directory), - mv unix unix.old, - mv unix.new unix, - sync, init 0, then restart the system. this is in the last issue of the PipeLine. Martin McDonald SGI Life is unpredictable. Eat dessert first.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07701; 1 Mar 90 10:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07015; 1 Mar 90 10:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06328; 1 Mar 90 9:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06581; 1 Mar 90 7:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08724; Wed, 28 Feb 90 07:37:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 15:31:44 GMT From: Sam Fulcomer Organization: Brown University Center for Fluid Mechanics Subject: Re: Help needed: Does anyone have a berkeley lpd running on Irix? Message-Id: <30930@brunix.UUCP> References: <9002271720.aa04757@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002271720.aa04757@SMOKE.BRL.MIL> HAMM@biovax.rutgers.edu (Greg Hamm) writes: >We're trying to get a few SGI's set up in a sea of VAX/VMS and bsd >Unix boxes. Tying together printing services is one of the things we'd >like to do, and the best way on the Unix side would seem to be to use >the Berkeley 'lpd' scheme. However, this is not provided with Irix, and, We have lpd and transcript running on our SGIs, however the tty code was sufficiently ugly that (since our PS host is a Sun) we didn't rewrite the local serial print stuff. It works more or less like a charm.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac07701; 1 Mar 90 10:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07015; 1 Mar 90 10:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06603; 1 Mar 90 9:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07500; 1 Mar 90 8:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28777; Wed, 28 Feb 90 20:33:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 22:53:10 GMT From: martin Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: kernel error messages Message-Id: <4704@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article liang@occlusal.rutgers.edu (Tajen Liang) writes: >We are having the following error messages in our personal iris. I am >wondering if there is any SGI user or SGI people know what the error >messages indicates. Any help/hint/pointer will be very appreciated. > >Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in > kernel: severity=2, getvaluator: 6344 there are valuators and there are buttons. getvaluator on a button, such as a mouse button, will generate this error. same for doing a setvaluator on a button. Martin McDonald SGI Life is unpredictable. Eat dessert first.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae07701; 1 Mar 90 10:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae07015; 1 Mar 90 10:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06741; 1 Mar 90 9:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09088; 1 Mar 90 8:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18984; Wed, 28 Feb 90 10:07:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 90 17:48:10 GMT From: Tajen Liang Organization: Rutgers Univ., New Brunswick, N.J. Subject: kernel error messages Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are having the following error messages in our personal iris. I am wondering if there is any SGI user or SGI people know what the error messages indicates. Any help/hint/pointer will be very appreciated. Feb 27 18:28:32 synapse.umdnj.edu grcond[6113]: Alive Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: aluator: 501 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 6344 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 3532 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 501 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 6344 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 501 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 6592 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 501 Feb 27 18:28:33 synapse.umdnj.edu grcond[6113]: CIO: ERROR #23 in kernel: severity=2, getvaluator: 6592 -Tajen Liang @ Rutgers University / UMDNJ-RWJMS   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20255; 2 Mar 90 2:36 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20166; 2 Mar 90 2:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20154; 2 Mar 90 2:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00434; 2 Mar 90 1:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27889; Thu, 1 Mar 90 22:21:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 00:17:05 GMT From: Stephen Kirby Organization: Mincom, Brisbane, Australia Subject: Re: executable size Message-Id: <299@mincom.OZ> References: <17280032@acf4.NYU.EDU>, <3747@uceng.UC.EDU>, <4566@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Subject: Shared library implentation problems. Mincom would like to be able to reduce the size of their executable files by utilizing shared libraries. There are a couple of restrictions which prevent us from making full use of shared libraries. Would you please find out if and when these problems will be addressed in IRIX. 1. A routine in a shared library cannot call a routine from another shared library. Even though it is documented on page 13-33 in the IRIS-4D Programmers Guide. ( the #objects noload directive.) 2. There are no shared libraries available for the fortran compiler. The fortran runtime library is not shared. 3. There is no facility to make our own shared libraries from our fortran routines. If the above restrictions were fixed we would be able to produce smaller executables and improve our development environment. MINCOM Pty Ltd Ph: (07) 3948000 1st Floor 109 Logan Road, 138 Juliette St, Woollongabba. Greenslopes 4120 BRISBANE BRISBANE Fax (07) 3942844 Stephen Kirby.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02349; 1 Mar 90 4:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02328; 1 Mar 90 4:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02318; 1 Mar 90 4:18 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa04265; 1 Mar 90 2:44 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 01 Mar 90 08:46:47+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 01 Mar 90 08:45:03+0100 Date: 01 Mar 90 08:45:03+0100 From: Reinhard Doelz To: info-iris@BRL.MIL Subject: Re: preventing core dumps Message-ID: <221*doelz@urz.unibas.ch> Talking about cores. NOCORE is okay, ... or even a parameter MAXCOREDUMPSIZE, because sometimes a small core is better than nothing, and testing routines it is annoying that your disk gets filled up with a core which might bother other processes. Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02748; 1 Mar 90 5:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02677; 1 Mar 90 5:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02649; 1 Mar 90 5:33 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa04173; 1 Mar 90 2:30 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 01 Mar 90 08:32:08+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 01 Mar 90 08:30:13+0100 Date: 01 Mar 90 08:30:13+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Message-ID: <220*doelz@urz.unibas.ch> Subject: RE: login problem. GREAT. I was reporting this problem to SGI in fall 1989, and they (ISO) told me thatothers encounter the same problem. I hacked a workaround which temporarily fixes the problem, because even 3.2.1. didn't fix it. The following is a repost of a message I sent to INFO-IRIS in december. Hope this helps... Reinhard =========================================== We are running a 120GTX OS 3.2.1. The program shown below runs on two processors. The graphics manager fails to start up and the graphics is unusable (No window manager). *DOCUMENTATION:* The /usr/adm/SYSLOG says (truncated, only significant lines shown) Dec 7 09:17:00 modl grcond[290]: CIO: IRIX System V Release 3.2 IP5 Version 10171414 Dec 7 09:17:00 modl grcond[290]: CIO: CPU 1 taking over time and accounting functions Dec 7 09:17:00 modl grcond[290]: CIO: gfx_wait_cx: context switch timed out Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: gm-2 (configured for IP5) 1.14+ Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: DEBUG_NOISE at 0x9806648C Dec 7 09:17:00 modl grcond[290]: CIO: Loading PP ucode Version: @(#) PEAPOD 1.2 pp microcode assembler - 6/20/87 Dec 7 09:17:00 modl grcond[290]: CIO: Sat Aug 19 19:10:21 1989 user unknown revision(1.123CLOVER2IP5GT) Dec 7 09:17:00 modl grcond[290]: CIO: tried and failed ... as reported. ... and therefore I conclude that the grcond is unable to start up. *WORKAROUND:* The IRIS is fully networked running nfs, 4DDN and TCP/IP thus eventually suffering from this. Therefore, I changed the kernel in /usr/sysgen/master.d to read the network on CPU0 as follows: 107c107 < #define NBUF 100 /* # buffers in disk buffer cache */ --- > #define NBUF 400 /* # buffers in disk buffer cache */ 215c215 < #define MAXSC 26 --- > #define MAXSC 30 353c353 < int network_processor = 1; --- > int network_processor = 0; modl [/usr/sysgen/master.d] % ... did an lboot and problem solved. *PROBLEM REPRODUCTION:* The fortran program causing the problem is a special application. However, a C program will do it as well. The following is a dummy routine which performs the crashes: real x(100,1000), y(100,1000) seed=123456 do 100 i=1,100 do 101 ii=1,1000 x(ii,i)=rand(seed) 101 continue 100 continue write (6,*)'ran done' do 200 i=1,100 do 201 ii=1,1000 y(ii,i)=sin(x(ii,i))*cos(x(ii,i)) y(ii,i)= * (y(ii,i)**1.003)**(1-(sin(x(ii,i))/1000)) do 202 iii=1,900 y(ii,i)= * y(ii,i)**(1-(sin(x(ii,i))/1000)) 202 continue 201 continue 200 continue stop end pfa concurrentizes the 200 do loop which gives a fully paralelly running program. *ALTERNATIVE WORKAROUND:* In order to avoid the kernel modification you could also log in from another (not the console) terminal, or even log in as root NOGRAPHICS, call the debugger saying dbx -p # ( # being the parallel job) which is equivalent to sending a schedctl call to this process. One could do it more elegantly by using a small C routine but I didn't bother about that. ************************************************************************ * Dr. Reinhard Doelz * SWITZERLAND * * Biocomputing * * * Biozentrum * doelz%urz.unibas.ch@relay.cs.net * * Klingelbergstrasse 70 * * * CH-4056 Basel * * ************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad07701; 1 Mar 90 10:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad07015; 1 Mar 90 10:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab06678; 1 Mar 90 9:46 EST Received: from phvax.smithkline.com by SMOKE.BRL.MIL id aa08662; 1 Mar 90 8:46 EST Received: from PHVAX.DECnet MAIL11D_V3 by smithkline.com (5.57/Ultrix2.4-C) id AA09507; Thu, 1 Mar 90 08:35:40 EST Date: Thu, 1 Mar 90 08:35:39 EST Message-Id: <9003011335.AA09507@smithkline.com> From: dixons%phvax.dnet@smithkline.com To: "info-iris@BRL.MIL %INET.dnet"@smithkline.com Subject: RE: login problem. I had the same problem of getting logged in on the console on a 4d240 when is had compute bound jobs running on all four processors. In contrast to the other recent postings, when I called the hot line about this, I was told that it was a known problem, that it would be fixed in 3.2.2 (which is "ship on fail") and I was given a workaround similar to that posted by Reinhard Doelz. That fixed the problem. However, when I first called the hotline, it was handled as a hardware problem and only when I noticed that the problem went away when the machine was not loaded did they pick up on the software problem. It seems to depend on whether or not the call is passed to a hardware or software person. Never the less, the hotline had the fix and I got it from them without much problem. Scott Dixon (dixons@smithkline.com)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15021; 1 Mar 90 16:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14834; 1 Mar 90 15:50 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa14742; 1 Mar 90 15:36 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa23592; 1 Mar 90 15:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21459; Thu, 1 Mar 90 12:03:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 05:50:10 GMT From: "Calvin H. Vu" Subject: Re: f77 question/space saver Message-Id: <4746@odin.SGI.COM> References: <765@ns-mx.uiowa.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <765@ns-mx.uiowa.edu> knosp@umaxc.weeg.uiowa.edu (Boyd Knosp) writes: >Why do I get this error using f77 on a 4D120GTX: > Program x > Implicit None > Structure /test/ > Character*80 text > End Structure > Record /test/ Myvar > Integer*4 I > Myvar.text="(Hello)" > I=Index(Myvar.text,")") > > End >%f77 x.f >Error on line 16 of x.f: bad argument type to intrinsic index >Note: The same thing happens with other intrinsic functions when I > try to pass subrecords to them. If I assign to a temp var > and pass the temp var to the fn instead, it compiles fine... There was a bug in the MIPS 1.31 release of the compiler regarding the use of record elements as arguments. This has been fixed in the MIPS 2.0 compiler which will be in our next release. >f77 creates huge exectuables. I reduce size by linking with shared >libs and 'strip'ing the labels out of them (once they're debugged). >It is nice to note that the old unix dynamic memory allocation trick >for FORTRAN works with the SGI compiler. Dynamically allocating large >arrays also reduces f77 execuatble size. (I have the source code if >anyone has need for dynamically allocated FORTRAN arrays) In the next release, we will have POINTER type so you can associate a pointer to a dynamically-allocated array. This will make dynamic array allocation much easier to do. >Randy Frank >University of Iowa Image Analysis Facility >randy@tessa.iaf.uiowa.edu Calvin Vu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15569; 1 Mar 90 16:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15240; 1 Mar 90 16:24 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa15067; 1 Mar 90 16:03 EST Received: from Icarus2.AE.MsState.Edu by ADM.BRL.MIL id aa25143; 1 Mar 90 15:41 EST Received: by Icarus2.AE.MsState.Edu (4.1/5.0s); id AA18640; Thu, 1 Mar 90 14:42:44 CST Date: Thu, 1 Mar 90 14:42:44 CST From: Larry Thorne Message-Id: <9003012042.AA18640@Icarus2.AE.MsState.Edu> To: info-iris@BRL.MIL Subject: Mountd keeps dying We have a 4D/70GT running IRIX 3.2. All was going fine until 4 days ago when the mount daemon (/usr/etc/rpc.mountd) starting dying. It seems to live until someone tries to mount or umount one of the SGI disks. A possible cause could be that we are mounting the SGI's disks on several more hosts now, and the SGI is in turn also remote mounting disks from all the same hosts (a sort of cross-mounting trick to make all file systems available system-wide). We have a Sun 4/280 & a Sun 4/260 and an Ardent Titan playing this trick with the SGI. Each of the three machines are remote mounting 2 of the SGI's filesystems and the SGI is remote mounting one filesystem from each of these other 3 machines. Also, another client of the 4/280 will occasionally remote mount one of the SGI filesystems, for backup/restore stuff, etc. Also, I'm having to use the -n option on rpc.mountd so that the Ardent isn't locked out of the game. Anyhow, is this the cause of rpc.mountd dying? Is there any way to get an error message from rpc.mountd before it dies? How can I tell what's causing all this? Do I need to start more nfsd processes? Any and all info will be greatly appreciated! Larry Thorne larryt@ae.msstate.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15569; 1 Mar 90 16:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15240; 1 Mar 90 16:24 EST Received: by VMB.BRL.MIL id af15072; 1 Mar 90 16:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13171; 1 Mar 90 13:51 EST Received: from sgi.com by SMOKE.BRL.MIL id aa14844; 1 Mar 90 11:35 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA26208; Thu, 1 Mar 90 08:36:08 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:nmr%nimr.mrc.ac.uk@cunyvm.cuny.edu id AA24115; Thu, 1 Mar 90 08:36:02 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA03572; Thu, 1 Mar 90 08:36:18 PST Message-Id: <9003011636.AA03572@forest.sgi.com> To: NMR Center Users Cc: info-iris@BRL.MIL Subject: Re: Well, How about it ? (68040) In-Reply-To: Your message of Mon, 26 Feb 90 09:30:20 +0000. <9002260930.AA25112@uk.ac.mrc.nimr> Date: Thu, 01 Mar 90 08:36:15 PST From: baskett%forest@sgi.com We have no current plans to upgrade Iris 3000/3100 systems with a 68040. Forest Baskett Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16244; 1 Mar 90 17:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16008; 1 Mar 90 17:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15831; 1 Mar 90 16:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18748; 1 Mar 90 13:40 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14086; Thu, 1 Mar 90 10:11:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 17:11:32 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: ar - the archiver Message-Id: <52318@sgi.sgi.com> References: <9002281129.aa20377@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002281129.aa20377@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: >Can someone give me any tips on using ar, or lead me to any books that >might be able to help me. > >I am able to create a library, add objects, and update symbol tables >(e.g. ar cr lib.a a.o b.o, or ar ts lib.a), BUT I would like the compilerr >to recognize it via a flag; for example, the way it recognizes -Zg, or -lgl_s. This is easily done. Say you name your archive libmy.a and have a copy temporarily in /myliblocation. su # need to be root for the cp to /usr/lib cp /myliblocation/libmy.a /usr/lib exit # no need to be root any more cc t.c -lmy #this works, since ld searches /usr/lib # alternatively: mkdir /usr/local/lib cp /myliblocation/libmy.a /usr/local/lib cc t.c -L/usr/local/lib -lmy # the -Lpath adds the path to the ld search list You'll find all this information via ``man ld'' As always, RTFM :-) Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16338; 1 Mar 90 17:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16008; 1 Mar 90 17:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15803; 1 Mar 90 16:47 EST Received: from [132.246.240.4] by SMOKE.BRL.MIL id aa17891; 1 Mar 90 13:12 EST Received: from VM.NRC.CA by VM.NRC.CA (IBM VM SMTP R1.2.1) with BSMTP id 9773; Thu, 01 Mar 90 12:55:58 EST Received: from NRCNET.NRC.CA by VM.NRC.CA (Mailer R2.05) with BSMTP id 9772; Thu, 01 Mar 90 12:55:34 EST Date: Thu, 1 Mar 90 11:43 EST From: Martin Serrer - Systems Analyst Subject: Xw, HP widgets on IRIS To: info-iris@BRL.MIL X-VMS-To: nrcnet::in%"info-iris@BRL.MIL" Message-ID: <9003011312.aa17891@SMOKE.BRL.MIL> Hi, Has anyone managed to install the Xw widget library on an IRIS. I am running IRIX 3.2 and I have the SGI X development environment. When I try to build the widget library, at the point where the file Manager.c is compiled I get the most helpful message... Fatal error in /usr/include/uopt - core dumped Signal 139 Isn't UNIX wonderful :-( What the %&%^#!@$@#^*& does one do at such a point. I apologize for the tone but I have been fighting with this code for 3 days and this is just the latest problem I've encountered. Martin +-----------------------------------------------------------------------------+ | Martin Serrer Systems Lab., Bldg. M3, Montreal Rd.| | 613-993-9442 (Bell) National Research Council of Canada,| | serrer@syslab.nrc.ca (BITNET) Ottawa, Ontario, Canada K1A-0R6 | +----------Software Rusts...------------------Rust never Sleeps...------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17109; 1 Mar 90 18:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17058; 1 Mar 90 18:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16965; 1 Mar 90 18:27 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24256; 1 Mar 90 16:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25061; Thu, 1 Mar 90 13:02:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 19:59:44 GMT From: John D Mccalpin Organization: College of Marine Studies, Univ. of Delaware Subject: Re: ar - the archiver Message-Id: <5798@udccvax1.acs.udel.EDU> References: <9002281129.aa20377@SMOKE.BRL.MIL>, <52318@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002281129.aa20377@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: >I am able to create a library, add objects, and update symbol tables >(e.g. ar cr lib.a a.o b.o, or ar ts lib.a), BUT I would like the compilerr >to recognize it via a flag; for example, the way it recognizes -Zg, or -lgl_s. In article <52318@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) replies: [example #1 deleted since it works fine....] ># alternatively: > cp /myliblocation/libmy.a /usr/local/lib > cc t.c -L/usr/local/lib -lmy # the -Lpath adds the path to the ld search list Some notes on this technique: (1) All of the SGI machines that I have used automagically search /usr/local/lib, so the -L/usr/local/lib option is not needed here. (2) The -L option does not work on the old 3000 series machines. (At least with the f77 command, since -L is preempted so that you can request a program listing.) -- John D. McCalpin - mccalpin@vax1.acs.udel.edu mccalpin@delocn.udel.edu mccalpin@scri1.scri.fsu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17415; 1 Mar 90 20:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17349; 1 Mar 90 20:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17302; 1 Mar 90 19:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26544; 1 Mar 90 18:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02780; Thu, 1 Mar 90 15:06:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 22:11:25 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: tar, 3030 <=> sun Message-Id: <52367@sgi.sgi.com> References: <437@skipper.dfrf.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <437@skipper.dfrf.nasa.gov>, disbrow@skipper.dfrf.nasa.gov (Jim Disbrow) writes: > Is there some reason why a tar tape created on a 3030 series machine > can't be read on a Sun 3/280? They're byte-swapped relative to each other. Just use dd on the reading machine to swap the bytes before feeding to tar. Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17415; 1 Mar 90 20:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17349; 1 Mar 90 20:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac17328; 1 Mar 90 19:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26643; 1 Mar 90 18:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02716; Thu, 1 Mar 90 15:05:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 17:58:29 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: RE2 Performance Message-Id: <4761@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Getting an RE2 is the best thing you can do to help your X performance on a Personal Iris. The RE2 has several advantages over the RE1: 1) Does logicop in hardware. That means that when you specify XOR we don't have to read the bits back, twiddle them on the host, then write them back to the graphics board. 2) Writing 8 bit deep images is much faster since the RE2 can unpack 4 pixels from a single 32bit words, whereas the RE1 had to have one pixel per word, no matter what. 3) The RE2 is faster than the RE1. You may not see a huge speedup with the RE2 with today's X server, but in the future we will be taking advantage of the RE2 in a much bigger way. If you are serious about running X you probably want an RE2. To find out which RE chip you have run the 'hinv' program. If if says 'Graphics Board: GR1.1' then you have an RE1, GR1.2 is an RE2. Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17415; 1 Mar 90 20:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17349; 1 Mar 90 20:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad17328; 1 Mar 90 19:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26645; 1 Mar 90 18:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02576; Thu, 1 Mar 90 15:03:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 17:30:22 GMT From: Robert Skinner Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: ar - the archiver Message-Id: <4757@odin.SGI.COM> References: <9002281129.aa20377@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002281129.aa20377@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > Can someone give me any tips on using ar, or lead me to any books that > might be able to help me. > > I am able to create a library, add objects, and update symbol tables > (e.g. ar cr lib.a a.o b.o, or ar ts lib.a), BUT I would like the compilerr > to recognize it via a flag; for example, the way it recognizes -Zg, or -lgl_s. > > Thanks for any help... > > tp mugabi-jordan Look at the -L option in the man page for 'ld'. It allows you to set the directories 'ld' will use to search for libraries you have named with -L. For example, you can name your library libmylib.a, put it in /usr/people/me/lib, and then have a link line that looks like cc ..... -L/usr/people/me/lib ... -lmylib (cc just calls ld to link.) This isn't much help for just one private library, but its great if you have several. The -Zg option is obsolete on 4D systems and should not be used. It is equivalent to using '-lgl -lm' in the link command. Besides, explicitly saying -lgl makes it easier to change to -lgl_s and back. Robert Skinner robert@sgi.com Whoa Homer, don't have a cow. - Bart Simpson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad17415; 1 Mar 90 20:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad17349; 1 Mar 90 20:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ae17328; 1 Mar 90 19:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26647; 1 Mar 90 18:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02634; Thu, 1 Mar 90 15:04:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 17:34:40 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: ar - the archiver Message-Id: <4759@odin.SGI.COM> References: <9002281129.aa20377@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002281129.aa20377@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > Can someone give me any tips on using ar, or lead me to any books that > might be able to help me. > > I am able to create a library, add objects, and update symbol tables > (e.g. ar cr lib.a a.o b.o, or ar ts lib.a), BUT I would like the compilerr > to recognize it via a flag; for example, the way it recognizes -Zg, or -lgl_s. > > Thanks for any help... > > tp mugabi-jordan > gm systems engr ctr When you specify a library using -l, the linker, ld, looks for the file as /lib/lib.a or as /usr/lib/lib.a. For instance, by specifying -lgl_s, you are actually getting /usr/lib/libgl_s.a. You can specify additional library search paths by using -L where is the directory containing your library (even . if you want). If you wanted to look up a libraries in /usr/local/lib, for instance, you could add to your cc or ld command line: -L/usr/local/lib -lmylib1 -lmylib2 and the libraries could actually be /usr/local/lib/libmylib1.a and /usr/local/lib/mylib2.a. See cc(1) and ld(1) for more details. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17858; 1 Mar 90 21:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17708; 1 Mar 90 21:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17620; 1 Mar 90 21:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26841; 1 Mar 90 19:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05360; Thu, 1 Mar 90 15:48:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 19:40:18 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: NeWS windows and GL windows Message-Id: <4772@odin.SGI.COM> References: <476@meritaus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <476@meritaus.UUCP>, dan@meritaus.UUCP (Daniel Haug) writes: > > What is the relationship between NeWS windows and GL windows? > When I call winopen(), the resulting window looks suspiciously > similar to "framebuffer /new DefaultWindow send". Does the > GL library create a NeWS window to coincide with the internal The GL library does something very like framebuffer /new MEXWindow send > If there exists a NeWS window instance that corresponds to the > GL window, how can one access it (e.g. thru CPS, but how does > one access the actual instance)? You can access it by using the PostScript function gfsend. The syntax you would use in a function you cdef in a cps file is: cdef foo(int gid) gid gfsend where gid is the value returned by winopen. You have to link the resulting program with -lcps and -lbsd and don't forget to ps_flush_PostScript() after calling your cdef'ed function. After the next x.y release you won't need -lbsd anymore. > Can I change the value of > DefaultWindow and expect subsequent winopen()'s to reflect this > change? (e.g. suppose I want my GL windows to have scroll bars, > and hence, use the ScrollWindow class). No. MEXWindow is explicitly a subclass of SGIWindow because there is a tight relationship between them. We knew that various other window subclasses that people might be using as "DefaultWindow" wouldn't work for MEXWindow. You have to change either the MEXWindow or the SGIWindow class to affect your gl windows. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17858; 1 Mar 90 21:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17708; 1 Mar 90 21:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17663; 1 Mar 90 21:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27072; 1 Mar 90 19:25 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07013; Thu, 1 Mar 90 16:16:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 21:01:36 GMT From: Thilaka Sumanaweera Organization: Stanford University Subject: Volume Rendering Tools Message-Id: <9684@portia.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL VOXVU is a volume rendering tool available on SUN workstations equipped with a TAAC board. Does anybody out there know if Silicon Grpahics has a similar tool available on personal IRIS-4D/2* ? Any pointer/ suggestion is welcome. Thilaka sumane@ibis.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad18415; 1 Mar 90 22:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18291; 1 Mar 90 21:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17929; 1 Mar 90 21:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26839; 1 Mar 90 19:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05251; Thu, 1 Mar 90 15:47:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 23:15:34 GMT From: "Robert E. Minsk" Organization: Georgia Institute of Technology Subject: -s falg on cc Message-Id: <6585@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A quick and simple question: I noticed in the makefile for 4Dgifts/iristools/imgtools that one of the CFLAGS was -s. The man page makes no mention of this flag. What does it do? -- Robert E. Minsk - Office of Computing Services | Save the whales... | ARPA: ccoprrm@prism.gatech.edu | Collect the whole set | uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccoprrm Georgia Institute of Technology, Atlanta Georgia, 30332   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18506; 1 Mar 90 22:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18415; 1 Mar 90 22:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18306; 1 Mar 90 21:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id ab27586; 1 Mar 90 20:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10321; Thu, 1 Mar 90 17:17:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 22:21:24 GMT From: Paul Jackson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: preventing core dumps Message-Id: <4781@odin.SGI.COM> References: <221*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <221*doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes: | Talking about cores. NOCORE is okay, | | ... or even a parameter MAXCOREDUMPSIZE, because sometimes a small | core is better than nothing, and testing routines it is annoying that | your disk gets filled up with a core which might bother other processes. Coming soon to a theater near you. The next IRIX major software release includes support for Berkeley style get and set rlimits, including "limit coredumpsize". By setting this limit large enough to include a process's stack, dbx will provide you a stack backtrace without you having to dump a Multi-Megabyte core of your data segment. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18506; 1 Mar 90 22:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18415; 1 Mar 90 22:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18348; 1 Mar 90 21:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27915; 1 Mar 90 21:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12558; Thu, 1 Mar 90 17:55:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 01:42:18 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: ar - the archiver Message-Id: <52410@sgi.sgi.com> References: <9002281129.aa20377@SMOKE.BRL.MIL>, <52318@sgi.sgi.com>, <5798@udccvax1.acs.udel.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <5798@udccvax1.acs.udel.EDU>, mccalpin@vax1.acs.udel.EDU (John D Mccalpin) writes: > In article <9002281129.aa20377@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: [stuff deleted] > Some notes on this technique: > (1) All of the SGI machines that I have used automagically search > /usr/local/lib, so the -L/usr/local/lib option is not needed here. Yes. John is right. 4D ld searches: /lib/ /usr/lib/cmplrs/cc(vers#) /usr/lib/ /usr/local/lib in that order (by default). We never create the /usr/lib/cmplrs directory. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac18506; 1 Mar 90 22:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac18415; 1 Mar 90 22:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18394; 1 Mar 90 21:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27970; 1 Mar 90 21:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14251; Thu, 1 Mar 90 18:21:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Mar 90 16:38:32 GMT From: "David Kamins @stardent" Organization: Stardent Computer, Newton MA Subject: RE: Comments on Stardent's AVS Message-Id: <1990Mar1.163832.440@Stardent.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The following is in response to the various conversations between Ian Hoyle, James Helman, Sam Fulcomer, and Tony Facca regarding Stardent's AVS: AVS provides end-user scientists and engineers with a rich set of visualization capabilities in a fully reconfigurable, extensible environment. It is not intended to compete with "custom, application specific, scientific visualization software" (James Helman), but rather to enable the scientist or engineer to achieve a fast and reliable solution to a broad range of visualization problems without programming. AVS is not a prototype - it is a fully supported product. Version 2.0 was distributed to all Stardent 2000 users, and will be distributed to all Stardent 1500 and Stardent 3000 users in about a month. AVS currently supports two rendering libraries, PHIGS+ and Dore. The "graphics independent level" (James Helman) has been a part of AVS since its original design. The recent port to Dore has substantiated the value of AVS' portable architecture - it was quick and painless. Stardent has not ported AVS to an Iris (re Tony Facca's mail). AVS Source code licenses are available only to Stardent customers and system vendors with whom we've entered into a contractual agreement. We have many exciting porting plans underway, although it is too early to make a general announcement about these. David Kamins (davek@stardent.com) Manager, Visualization Software Stardent Computer Inc. (Newton)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20255; 2 Mar 90 2:36 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20166; 2 Mar 90 2:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20158; 2 Mar 90 2:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00446; 2 Mar 90 1:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28048; Thu, 1 Mar 90 22:24:24 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 06:22:39 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: Xw, HP widgets on IRIS Message-Id: <90Mar2.012132est.6442@neat.cs.toronto.edu> References: <9003011312.aa17891@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL SERRER@NRCM3.NRC.CA (Martin Serrer - Systems Analyst) writes: > Has anyone managed to install the Xw widget library on an IRIS. I am running >IRIX 3.2 and I have the SGI X development environment. Yes, but not with the SGI X development environment. We built MIT X. MIT X.V11R4 comes with an sgi config file and a much fixed set of Xw widgets in contrib/toolkits/Xw. (WARNING: Do not try to use the Xw widgets in the MIT R3 source with the MIT R3 includes or libXt. It doesn't work, for reasons documented in the R3 doc/tutorials/r3widgets.ms document) > When I try to build the widget library, at the point where the file Manager.c >is compiled I get the most helpful message... >Fatal error in /usr/include/uopt - core dumped > Signal 139 /usr/include? /usr/lib/uopt is the MIPS optimizer, which dumps core on a few files in Xw when compiling with -O. (if it's any consolation, it did this on the DECstation 3100 as well) Compile with make -k then go back to Xw and use make CDEBUGFLAGS=-g to recompile the files that caused cc to dump core. Alternatively, you can opt for the lower performance, high correctness side of the world and compile everything without -O, which is what we did. (When compiling something the size of X, even looking through the output of the make to find errors is exhausting. And then there's programs that work when compiled without -O but die when compiled with -O, like contrib/clients/pbmplus/ppm/giftoppm.c) Perhaps someone from SGI/MIPS would care to compile all of X.V11R4 before Irix3.3 is released -- X makes a great compiler test suite. > Isn't UNIX wonderful :-( Yes.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25702; 2 Mar 90 10:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25173; 2 Mar 90 10:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25096; 2 Mar 90 10:13 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa04134; 2 Mar 90 7:57 EST Received: Fri, 2 Mar 90 07:59:50 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 2 Mar 90 07:59:50 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003021559.AA02118@aero4.larc.nasa.gov> To: nems!dtoa1!scfisher@mimsy.umd.edu Subject: Re: Memory prices Cc: info-iris@BRL.MIL Here is a list I have compiled from info-iris mail. I don't know how good or bad any of them are we haven't ordered anything yet. Sophistecated Circuits, Seattle (206) 547-4779 Memory for 4D 20's, $310/Mb (in late April '89) Impediment, Inc., 333 Duxbury, MA 02332, (617) 837-8877 Memory for 4D 20's, 1Mb simms, $90/Mb (early January '90) Memory for 4D 20's, 4Mb simms, $187.5/Mb (early January '90) Memory for 4D 200's $225/Mb (early January '90) (Have heard good things about this company, including 5 year replacement guarantee, not 90 days like some companies) ClearPoint, 35 Parkwood Drive, Hopkington,MA 07148, (800) 253-2778 (508) 435-2000 Memory for 4D 20's, $88/Mb (GSA pricing) (early January '90) 1Mb sims, $100/Meg (80Ns); 4Mb sims, $200/Meg (Life time warranty.) If anyone has any more names to add to the list please let me know. Also, please include an address or at least a phone number for the company. P.S. I was given another name of a company but no address or phone number, Helios. The person also gave me the name of a memory/ peripheral distributor they use; Northern California, CITA in Sacremento (916) 344-5558 they said CITA has good prices and service. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25702; 2 Mar 90 10:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25173; 2 Mar 90 10:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25105; 2 Mar 90 10:13 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa04224; 2 Mar 90 8:00 EST Received: Fri, 2 Mar 90 08:03:23 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 2 Mar 90 08:03:23 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003021603.AA02141@aero4.larc.nasa.gov> To: skipper!disbrow@ames.arc.nasa.gov Subject: Re: tar, 3030 <=> sun Cc: info-iris@BRL.MIL I have tried it before with no success. Someone said once that you needed to use dd I believe and some byte swapping. I tried their suggestion, but that didn't work either. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28459; 2 Mar 90 13:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28171; 2 Mar 90 12:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28113; 2 Mar 90 12:38 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa10498; 2 Mar 90 11:04 EST Received: Fri, 2 Mar 90 08:05:31 -0800 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Fri, 2 Mar 90 11:05:30 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Fri, 2 Mar 90 11:14:08 EST by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Fri, 2 Mar 90 11:14:08 EST From: Tony Facca Message-Id: <9003021614.AA28422@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: question about cmov/getcpos can someone please shed some light on the use of getcpos/cmov2i ? I have a routine which allows the user to enter character data from a graphics window. they type stuff from the keyboard, and it gets echoed back to the screen. the problem occurs when a backspace is encountered in an unconstrained window. here is a code section: keybd_input (buff) char *buff; { Screencoord xpos, ypos; char *p, ch_temp[2]; short dev, ch; int i=0; devices (OFF); qdevice (KEYBD); cmov2i (50,50); charstr ("enter string: "); p = buff; ch_temp[1] = '\0'; while ( dev = qread (&ch)) { if (dev == KEYBD) { if (ch == '\n' || ch == '\r') { break; } if (ch == '\b') { i--; if (i < 0) { i = 0; break; } ch_temp[0] = *--p; getcpos (&xpos, &ypos); xpos = xpos - strwidth(ch_temp); cmov2i (xpos, ypos); color (BLACK); charstr (ch_temp); color (WHITE); cmov2i (xpos, ypos); } else { *p++ = ch; ch_temp[0] = ch; charstr ( &buff[i++] ); } } } *p = '\0'; devices (ON); } if i precede the winopen() call (not part of this routine) with one to prefposition(0,XMAXSCREEN,0,YMAXSCREEN) then all is well, getcpos returns nice values and everyone is happy. if I let the user open an unconstrained window, the call to cmov2i(50,50) appears relative to the lower left corner of the user-defined window. however, the getcpos call returns something other than relative values and things get ugly. is this indeed the case, that cmov is relative and getcpos is not? is there a way to tell getcpos() to use relative coordinates? is there an altogether better way to accomplish this? -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29562; 2 Mar 90 14:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29356; 2 Mar 90 14:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab29350; 2 Mar 90 14:16 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12295; 2 Mar 90 12:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29507; Fri, 2 Mar 90 08:51:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 16:01:36 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: -s falg on cc Message-Id: <4806@odin.SGI.COM> References: <6585@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6585@hydra.gatech.EDU> ccoprrm@prism.gatech.EDU (Robert E. Minsk) writes: > > A quick and simple question: >I noticed in the makefile for 4Dgifts/iristools/imgtools that one of the >CFLAGS was -s. The man page makes no mention of this flag. What does it >do? > >-- >Robert E. Minsk - Office of Computing Services | Save the whales... | >ARPA: ccoprrm@prism.gatech.edu | Collect the whole set | >uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccoprrm >Georgia Institute of Technology, Atlanta Georgia, 30332 the "-s" flag derives from LD(1): -s Strip the symbolic information from the output object file. this will pare-down the size of yer final executable by a [potentially] significant amount. the "-s" flag seems to me to be primarily useful when yer generating yer final finished-version of the executable file yer making. at this point, since all symbolic info is now gone, there h'ain't much use re: any kind of debugging since any such minimal hooks still in the executable are now gone. (like if you generate a "Segmentation fault (core dumped)" and then try to do a dbx executable-name (dbx) where you won't be able to get the standard kind of line number/statement-it- failed-on feedback but instead will only see things like: warning: Has no symbol table -- very little is supported without it ) -- daveus rattus yer friendly neighborhood ratman KOYAANISQATSI ko.yan.nis.qatsi (from the Hopi Language) n. 1. crazy life. 2. life in turmoil. 3. life out of balance. 4. life disintegrating. 5. a state of life that calls for another way of living.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29930; 2 Mar 90 14:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29356; 2 Mar 90 14:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29343; 2 Mar 90 14:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12081; 2 Mar 90 12:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29527; Fri, 2 Mar 90 08:52:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 16:09:25 GMT From: Thant Tessman Organization: Silicon Graphics, Inc. Subject: Re: Volume Rendering Tools Message-Id: <4807@odin.SGI.COM> References: <9686@portia.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I already answered this on comp.graphics but in case others are interested: In article <9686@portia.Stanford.EDU>, sumane@portia.Stanford.EDU (Thilaka Sumanaweera) writes: > > VOXVU is a volume rendering tool available on SUN workstations > equipped with a TAAC board. Does anybody out there know if Silicon > Grpahics has a similar tool available on personal IRIS-4D/2* ? > > Thilaka > > sumane@ibis.stanford.edu Yes. VoxelLab comes with SGI boxes, and is a subset of VoxelView from Vital Images. thant   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29930; 2 Mar 90 14:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29356; 2 Mar 90 14:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29350; 2 Mar 90 14:16 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12286; 2 Mar 90 12:10 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29448; Fri, 2 Mar 90 08:51:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 16:25:36 GMT From: Jim Blue Organization: National Institute of Standards & Technology, Gaithersburg, MD Subject: IRIS Keyboard & etc. Message-Id: <2715@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Background: I am an experienced programmer and Unix user. I recently got my Personal Iris, and have been porting my own editor, since (IMHO) vi is brain-damaged. I have been active at RTFM, all 31 volumes (though most of them don't apply) but haven't found how to get the number of lines and columns inside a wsh. (getsize() gives the size in pixels, but not in lines and columns.) Since vi, among other programs knows how to do this, it must be possible. Appendix A.2 of the "Using the GL/DGL Interface" in the "4Sight Programmer's Guide lists the string supposedly returned by each key. I find that some work and some don't. For example, F1 really does return "ESC [ 001 q" (without the quotes and spaces), but F4 returns some garbage left over from an old "ls" command. After powering the machine down and up, F4 returns some other stuff (I don't know what). Alt C with the right Alt key returns the correct value, but not with the left Alt key. Is there more wisdom hidden in the FM, or must one be telepathic? Jim Blue National Institute of Standards and Technology disclaimer: The US Government doesn't know what I'm doing, and vice versa.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29930; 2 Mar 90 14:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29562; 2 Mar 90 14:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29402; 2 Mar 90 14:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12619; 2 Mar 90 12:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AB01730; Fri, 2 Mar 90 09:23:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 16:39:24 GMT From: "Bernard J. Duffy" Organization: University of Maryland, Baltimore County Subject: Re: PI Problems Message-Id: <2890@umbc3.UMBC.EDU> References: <2836@umbc3.UMBC.EDU>, <51830@sgi.sgi.com>, <17463@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17463@boulder.Colorado.EDU> hartzell@boulder.Colorado.EDU (George Hartzell) writes: >In article <51830@sgi.sgi.com>, brendan@illyria (Brendan Eich) writes: >>It seems xterm doesn't start a login shell (one with an initial "-" in >>its argv[0] basename). Only a login C-shell reads /etc/cshrc and .login, >>similarly for sh and /etc/profile & .profile. I don't know much about X; >>perhaps there's an xterm option for logging in (creating a login shell, >>updating /etc/utmp). ^^^^^^^^^^^^^^^^^^ - If this is the part where the user shows up in the output from the "who" command, then this is done as the default setup. In other words, the remote - into - xterm sessions show up as interactive terminal sessions. > >From the xterm man page on my MIPS: > -ls This option indicates that the shell that is started > in the xterm window be a login shell (i.e. the first > character of argv[0] will be a dash, indicating to > the shell that it should read the user's .login or > .profile). > >g. >George Hartzell (303) 492-4535 > MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 >hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell George / Brendan : Do you know of way to make all xterm-login sessions run as a login shell? My goal is to provide a consistent login sequence from all the "login", "rlogin", "telnet", and "xterm" sessions. I've been using some of the environment variables (like REMOTEHOST and DISPLAY), but they don't cover the exceptions well enough to get around the cases where /etc/cshrc doesn't get run. As a system administrate for new unix users, it is of great help to have a "system-wide" "cshrc" (/etc/cshrc) for all there logins. This way I can setup common system-wide aliases, umask-s, and terminal setups like the correct " stty erase " . The latter one is the biggest problem with Backspace and Delete characters in mix environments (unix: ATT/SGI - ^H, BSD/Ultrix - ^?, non-unix: VMS - ^? ). There might be a clean way around all of this if I could "bind" the back- space key on the SGI (PC-AT) keyboard to send the char 127 (Delete). Thanks for your responses, Bernie Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01534; 2 Mar 90 16:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01265; 2 Mar 90 16:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01149; 2 Mar 90 16:05 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa14018; 2 Mar 90 13:35 EST Received: Fri, 2 Mar 90 13:37:42 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 2 Mar 90 13:37:42 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003022137.AA03854@aero4.larc.nasa.gov> To: fsfacca@avelon.lerc.nasa.gov Subject: Re: Memory prices Cc: info-iris@BRL.MIL When I say 20's, I mean 4D/20 & 4D/25. They are both 20's, as apposed to 200's; i.e. 210, 220, 240, etc. Great news on the prices. ($76/Mb from Clearpoint) They just keep going down. SGI even cut their price for memory in half, now they charge only twice what everyone else charges, instead of four times. :-) -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02560; 2 Mar 90 18:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02244; 2 Mar 90 18:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02177; 2 Mar 90 17:45 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16252; 2 Mar 90 14:28 EST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2181; Fri, 02 Mar 90 14:18:47 EST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6552; Fri, 02 Mar 90 15:54:30 GMT Received: Via: UK.AC.MRC.NIMR; 2 MAR 90 15:53:57 GMT Via: uk.ac.mrc.nimr; Fri, 2 Mar 90 15:53:25 GMT Date: Fri, 2 Mar 90 15:53:25 GMT From: NMR Center Users Message-Id: <9003021553.AA11208@uk.ac.mrc.nimr> To: info-iris@BRL.MIL Hello, Can anyone out there help me? I have some protein structures that I would like to view using Quanta. Is there anyone in the Berlin area who has Quanta running on a SGI machine who would let me use their system ? Please WRITE to Cornelia Schroeder, Institut fuer Virologie, Bereich Medizin (Charite), Humboldt-Universitaet, Schumannstr. 20/21, DDR-Berlin 1040. phone - 2862362   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02560; 2 Mar 90 18:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02244; 2 Mar 90 18:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02199; 2 Mar 90 17:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16810; 2 Mar 90 14:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10294; Fri, 2 Mar 90 11:35:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 18:24:47 GMT From: "Gavin A. Bell" Subject: Re: Volume Rendering Tools Message-Id: <4817@odin.SGI.COM> References: <9686@portia.Stanford.EDU>, <4807@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4807@odin.SGI.COM> thant@horus.esd.sgi.com (Thant Tessman) writes: >Yes. VoxelLab comes with SGI boxes, and is a subset of >VoxelView from Vital Images. >thant Well, no. Silicon Graphics has licensed VoxelLab only on GT and GTX machines; it will not work on Personal Irises. I don't know the technical reasons why it doesn't work, and don't know if the licensing arrangement between SGI and Vital Images might change. --gavin DISCLAIMER: I am not an official spokesperson for SGI or Vital Images. --gavin (gavin@sgi.com, (415)335-1024)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad02560; 2 Mar 90 18:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad02244; 2 Mar 90 18:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02199; 2 Mar 90 17:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16870; 2 Mar 90 14:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10362; Fri, 2 Mar 90 11:36:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 18:56:58 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Mountd keeps dying Message-Id: <52495@sgi.sgi.com> References: <9003012042.AA18640@Icarus2.AE.MsState.Edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003012042.AA18640@Icarus2.AE.MsState.Edu>, larryt@AE.MSSTATE.EDU (Larry Thorne) writes: > ... > Anyhow, is this the cause of rpc.mountd dying? Is there any way to get > an error message from rpc.mountd before it dies? How can I tell what's > causing all this? Do I need to start more nfsd processes? > > Larry Thorne > larryt@ae.msstate.edu What is meant by "dying"? We run mountd as an inetd deamon, so that it should live only long enough to service one (or more recently a batch) of requests. There have been versions that lived until killed, but I don't think they were shipped. If you are seeing dying as in core files, it would be good to communicate with the Hotline. If you are seeing dying as in inetd or portmap not answering, that is another problem the Hotline should hear about. Nfsd has little to do with mounting. The `rpcinfo -p` command can be useful to see if portmap is running and knows that inetd is willing to start mountd. The `netstat -a` command can be used to see if inetd is in fact listening on the port that portmap thinks it is. Nfsstat can also be useful. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02699; 2 Mar 90 18:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02665; 2 Mar 90 18:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02644; 2 Mar 90 18:15 EST Received: from [132.246.240.4] by SMOKE.BRL.MIL id aa20087; 2 Mar 90 16:23 EST Received: from VM.NRC.CA by VM.NRC.CA (IBM VM SMTP R1.2.2MX) with BSMTP id 6390; Fri, 02 Mar 90 16:27:37 EST Received: from NRCNET.NRC.CA by VM.NRC.CA (Mailer R2.05) with BSMTP id 6388; Fri, 02 Mar 90 16:27:36 EST Date: Fri, 2 Mar 90 16:17 EST From: Martin Serrer - Systems Analyst Subject: X man To: info-iris@BRL.MIL X-VMS-To: NRCNET::IN%"info-iris@brl.mil" Message-ID: <9003021623.aa20087@SMOKE.BRL.MIL> Hi, I have come across references to an 'xman' utility. The man pages are there but the executable seems to be missing. I can't find it on my 3.2 tapes either. Is it just my tape that is missing this or has no-one got it?? Martin +-----------------------------------------------------------------------------+ | Martin Serrer Systems Lab., Bldg. M3, Montreal Rd.| | 613-993-9442 (Bell) National Research Council of Canada,| | serrer@syslab.nrc.ca (BITNET) Ottawa, Ontario, Canada K1A-0R6 | +----------Software Rusts...------------------Rust never Sleeps...------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03040; 2 Mar 90 20:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02957; 2 Mar 90 20:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02881; 2 Mar 90 20:00 EST Received: from umrvmb.umr.edu by SMOKE.BRL.MIL id aa20773; 2 Mar 90 17:15 EST Received: from blumiris.chem.umr.edu by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with TCP; Fri, 02 Mar 90 16:17:17 CST Received: by blumiris.chem.umr.edu (5.52/5.6) id AA27699; Fri, 2 Mar 90 16:16:54 CST Date: Fri, 2 Mar 90 16:16:54 CST From: "Robert B. Funchess" Posted-Date: Fri, 2 Mar 90 16:16:54 CST Message-Id: <9003022216.AA27699@blumiris.chem.umr.edu> To: info-iris@BRL.MIL Subject: Weird command flags A recent posting mentions that cc -s works but doesn't seem to be documented. We are running 3.1 rev D -- this may be fixed in 3.2 but I don't know -- in which the man page for install says that -c means "put the file here, iff it doesn't already exist". HOWEVER.... if I try to do this, install gives me its built in "dummy, this is the proper syntax" line, which DOESN'T mention a -c flag. Incidentally, the Irix install seems to be -- "enhanced" -- to the point of incompatibility with a lot of Makefiles. Then again, the Irix make seems to be "enhanced" to the point of incompatibility with a lot of Makefiles. Back to the point: there is an error in either the manual or the install command. Since I am trying to build TeX, there are one h*** of a lot of Makefiles to wade thru and change every instance of "install" to be Irix- compatible. Is it possible, in the next major release of Irix, be it 3.3 or 42 or sqrt(10), to include an "install" that works as promised? Or at least change the documentation? -- < Bob | bobf | Funchess > Stay alert! Trust no one! Keep your laser handy!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03492; 2 Mar 90 21:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03441; 2 Mar 90 21:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03327; 2 Mar 90 21:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22588; 2 Mar 90 18:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25370; Fri, 2 Mar 90 15:38:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 23:03:57 GMT From: Tom Wolf Organization: University of Utah CS Dept Subject: Fast Fourier Transforms and the GVX Message-Id: <1990Mar2.160357.10094@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In reading through the literature on the latest Graphics machines(I believe they are called GVX's), I see that they use Fast Fourier Transform chips in the graphics pipeline. As I have an application that requires thousand's of Fourier Transforms, I am curious as to whether you can use the FEEDBACK function to help crunch the FT's? Does anyone know if this is possible? Several of us have been trying to figure out what Fourier Transforms are used for in graphics processing? Any ideas? Thanks, Tom   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03713; 2 Mar 90 22:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03648; 2 Mar 90 22:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03591; 2 Mar 90 22:33 EST Received: from umrvmb.umr.edu by SMOKE.BRL.MIL id aa20810; 2 Mar 90 17:20 EST Received: from blumiris.chem.umr.edu by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with TCP; Fri, 02 Mar 90 16:21:51 CST Received: by blumiris.chem.umr.edu (5.52/5.6) id AA27705; Fri, 2 Mar 90 16:21:34 CST Date: Fri, 2 Mar 90 16:21:34 CST From: "Robert B. Funchess" Posted-Date: Fri, 2 Mar 90 16:21:34 CST Message-Id: <9003022221.AA27705@blumiris.chem.umr.edu> To: info-iris@BRL.MIL Subject: tar exchange Actually, we don't have a 3030, but I can verify that dd if=/dev/tape conv=swab | tar -xvf - will READ Sun tapes into an Iris 4D/20. The same command, with the device changed as appropriate, reads Iris tapes into an IBM 530, which leads me to believe that it is fairly general. Give it a try. The '-' after -xvf is in fact important, and easy to forget. -- < Bob | bobf | Funchess > Stay alert! Trust no one! Keep your laser handy!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04206; 3 Mar 90 0:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03946; 2 Mar 90 23:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03897; 2 Mar 90 23:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24808; 2 Mar 90 22:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08392; Fri, 2 Mar 90 19:22:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 90 01:04:47 GMT From: Tom Mitchell Organization: Silicon Graphics Computer Systems, Mountain View CA. 94039 Subject: Re: tar, 3030 <=> sun Message-Id: <4840@odin.SGI.COM> References: <437@skipper.dfrf.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <437@skipper.dfrf.nasa.gov> disbrow@skipper.dfrf.nasa.gov (Jim Disbrow) writes: * Is there some reason why a tar tape created on a 3030 series machine * can't be read on a Sun 3/280? Is it just me, or has anyone else Depending on how the tape controler and interface were built there may be a byte sex, byte order problem. There are two common flavors Big Endian and Little Endian. Things get strange when the procesor on the controler is not the same as the main processor. Anyhow, this is a common problem and 'dd' has an option (conv=swab) in it to help with the problem. Recently SGI as well as other UNIX vendors have been adding byte swap code directly to the tape device drivers. On 4D's look for /dev/tapens. Scan the man pages until this makes sense. dd if=/dev/tape conv=swab | tar tvf - Then try it. One other thing -- there are three common physical formats in tape land. Some tape devices can mix and match. Check the Sun's mt man page. You want to be using the sun QIC-24 flavor device. Also watch QIC-24 vs. QIC-150 devices. QIC-150 drives can read but not write QIC-24. Tis sort a one way trap for some. Thomas P. Mitchell -- mitch@sgi.com "All things in moderation; including moderation."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12074; 4 Mar 90 12:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12048; 4 Mar 90 12:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12040; 4 Mar 90 11:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08739; 4 Mar 90 11:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25486; Sun, 4 Mar 90 08:03:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 90 08:11:57 GMT From: "Lonhyn T. Jasinskyj" Organization: NASA Ames Research Center, Moffett Field, CA Subject: Flight, how to dogfight? Message-Id: <5084@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have been trying to dogfight in the flight simulator (under Irix 3.2) and am having problems (dogfighting, or trying to). I am befuddled on a couple of points: 1) Why do dog and shadow always crash telling me that I need an entry in /etc/services that I already have? (i.e. sgi-dogfight 5130/udp) 2) What is the difference between dog and shadow 3) Where is the documentation (besides the man page on flight), e.g. what is the -d option? I know what -h is. How does one specify the machine that one wants to fight? I am missing something obvious? Thanks, Lonnie -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Email to: lonhyn@ew01.nas.nasa.gov Human at: 415-604-3989 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05369; 3 Mar 90 4:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05322; 3 Mar 90 4:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05242; 3 Mar 90 4:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26670; 3 Mar 90 1:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19967; Fri, 2 Mar 90 22:41:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 90 06:31:19 GMT From: "Robert E. Minsk" Organization: Office of Computing Service - High Performace Computing Subject: follow up to -s flag Message-Id: <6631@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The reason the -s flag is not in the man page for cc is because it is a ld flag. Options that affect the linking and loading of files are passed by cc to ld, which is standard across most unix machines. I should of read the man page more carefully :-). This sort of ties in with the recent discussion about keeping executable sizes down, the -s option is same as the strip command - remove the symbol table from the executable. I would not do this until you feel the program is completely debuged or is being released. After the symbol table is removed debugers are almost totally useless. -- Robert E. Minsk - Office of Computing Services | Save the whales... | ARPA: ccoprrm@prism.gatech.edu | Collect the whole set | uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccoprrm Georgia Institute of Technology, Atlanta Georgia, 30332   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05369; 3 Mar 90 4:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05322; 3 Mar 90 4:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab05242; 3 Mar 90 4:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26683; 3 Mar 90 1:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20226; Fri, 2 Mar 90 22:45:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 90 06:21:40 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: piping binary files Message-Id: <3866@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL When I do this: zcat foo.dat | foo I get this response: sue: unformatted io not allowed apparent state: unit 5 named last format: list io lately reading sequential unformatted external IO Now, foo.dat.Z is a compressed unformatted binary file, and foo is reading from unit 5 like: READ(5) LPO,RPO,BPO,TPO Am I not allowed to pipe this type of data? If foo.dat.Z is a compressed ascii file, of course everything works fine. To remove any possibility that the fact things are compressed has anything to do with it, I uncompressed it and tried piping and I get the same error. I am trying to keep away from uncompressing the file to begin with and this has been a pretty good way of doing it - for compressed ascii files -. Is there a known fix or am I SOL? Tom Rohling trohling@uceng.uc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08359; 3 Mar 90 22:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08245; 3 Mar 90 21:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08203; 3 Mar 90 21:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02882; 3 Mar 90 18:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09733; Sat, 3 Mar 90 15:30:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 90 22:54:59 GMT From: David Beecher Organization: Plus Five Computer Services, St. Louis Subject: Device Driver Source for Silicon Graphics POWER system Message-Id: <3769@plus5.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is a plea for anyone out there who has source for a device driver that runs on the Silicon Graphics POWER series. I have a 240 system and am in the process of bringing up a commercially available disk farm (Maximum Strategy). I have had some success in talking to the device via memory mapping the register set of the device...but its a long way between that and a full blown device driver that supports DMA. My farm is a fairly simple device which has the capability of being a VME master. I'm sure that anything close would be extremely useful. As you all know its easier to modify something that exists than it is to start from the great void. I do have a copy of the new (and first) device driver manual from SGI. I would be VERY appreciative to any and all responses. Reasonable associated costs involved are no problem. You can email to this address or to beech@pet835.wustl.edu. Or feel free to give me a call: Dave Beecher Research Associate Division of Radiation Sciences 510 South Kingshighway St. Louis, Missouri 63144 (314)362-8459 or (314)362-7117 You can leave a message at either location. Thanks in advance.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10577; 4 Mar 90 3:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09631; 4 Mar 90 1:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09573; 4 Mar 90 1:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04905; 4 Mar 90 0:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27222; Sat, 3 Mar 90 21:03:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 04:31:47 GMT From: David Epstein Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Attaching SCSI drive to PI Message-Id: <1990Mar4.043147.26414@cs.umn.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone out there had a successful experiment attaching a third-party SCSI drive to a Personal Iris? The more details you can provide (manufacturers, suppliers, frustrations) the better. Thanks in advance.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11677; 4 Mar 90 8:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11631; 4 Mar 90 8:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11608; 4 Mar 90 7:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07231; 4 Mar 90 6:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14094; Sun, 4 Mar 90 03:21:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 11:10:08 GMT From: Chris Shaw Organization: University of Alberta, Edmonton, Canada Subject: Re: ar - the archiver Message-Id: <1990Mar4.111008.19335@cs.UAlberta.CA> References: <9002281129.aa20377@SMOKE.BRL.MIL>, <52318@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <52318@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: >This is easily done. Say you name your archive libmy.a and have a copy >temporarily in /myliblocation. > > su # need to be root for the cp to /usr/lib > cp /myliblocation/libmy.a /usr/lib > exit # no need to be root any more > cc t.c -lmy #this works, since ld searches /usr/lib >[ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] This works fine, although you might not want to become root every 3 weeks just to update the library. Use symbolic links, as follows. su cd /usr/lib # goto lib directory ln -s /myliblocation/libmy.a libmy.a # link to your library exit # now you don't have to do this again if libmy.a changes -- Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca Now with new, minty Internet flavour! CatchPhrase: Bogus as HELL !   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12116; 4 Mar 90 12:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11998; 4 Mar 90 11:27 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa11975; 4 Mar 90 11:14 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa12676; 4 Mar 90 10:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24685; Sun, 4 Mar 90 07:46:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 15:15:00 GMT From: "Adam W. Feigin" Organization: Pixel Pushers of America Subject: X11R4 xterm on 4d's Message-Id: <1530@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Well, I built X11R4 on our 4D's the other day. Everything went okay (well, almost -- you need to compile 'makedepend' with -g or else it core dumps) and most everything works, except for xterm. It complains that there's no available ptys (when, in fact, there are plenty). I'm pretty sure its attempting to open /dev/ptyp* (ala BSD) instead of /dev/ttyq* (in SGI land, and maybe all SYSV ??). I used the sgi.cf (thanks guys !), but I must be missing something obvious, since all of the other clients that I've tested work okay.... Anyone have any ideas and a fix ?? Thanks in advance. AWF -- Internet: adam@ncifcrf.gov Adam W. Feigin UUCP: {backbonz}!ncifcrf!adam Senior Systems Manager Mail: P.O. Box B, Bldg 430 National Cancer Institute-Supercomputer Center Frederick, MD 21701 Frederick Cancer Research Facility   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12325; 4 Mar 90 14:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12299; 4 Mar 90 14:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12268; 4 Mar 90 14:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09016; 4 Mar 90 12:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28783; Sun, 4 Mar 90 09:16:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 17:14:56 GMT From: Robert Lansdale Subject: How to kill tasks after a user abort? Message-Id: <1990Mar4.121456.14599@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have been running my 3d renderer successfully in parallel on our 4D/140 for several months now, but I have yet to get the ^C signal handling (SIGINT) to terminate the tasks gracefully. My renderer is set up so the user may abort the display process (which runs in parallel using tasks distributed with taskcreate()) by typing ^C, at which point the signal handler shuts the display code down and kills any stray tasks (I've noticed that random tasks get killed when SIGINT is seen - is this documented anywhere??). The signal handler then does a long jump back to the command line parser. The parent process is usually asleep while the tasks are running (it distributes work to the tasks and goes to sleep in a uspsema() statement). So how do I assure that the parent process gets woken and becomes the first process to enter the signal handler? I've (carefully) read through the signal man page several times and tried a number of variations of the SIGCLD signal catcher, but I still find that the parent process is getting stuck occansionally in the printf() routine when it is about to print that the display code is shutdown (printf() -> Psema() -> blockproc() ...). This printf() is part of the signal handling code. Any pointers would be most appreciated. Thanks. --> Rob Lansdale ---------------------------------------------------------------------------- Robert Lansdale - (416) 978-6619 Dynamic Graphics Project Internet: lansd@dgp.toronto.edu Computer Systems Research Institute UUCP: ..!uunet!dgp.toronto.edu!lansd University of Toronto Bitnet: lansd@dgp.utoronto Toronto, Ontario M5S 1A4, CANADA   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12413; 4 Mar 90 15:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab12299; 4 Mar 90 14:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12292; 4 Mar 90 14:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09247; 4 Mar 90 13:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01938; Sun, 4 Mar 90 10:20:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 18:05:54 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Flight, how to dogfight? Message-Id: <52663@sgi.sgi.com> References: <5084@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <5084@amelia.nas.nasa.gov>, lonhyn@ew01..nas.nasa.gov (Lonhyn T. Jasinskyj) writes: > I have been trying to dogfight in the flight simulator (under Irix 3.2) > and am having problems ... > 1) Why do dog and shadow always crash telling me that I need an > entry in /etc/services that I already have? (i.e. sgi-dogfight 5130/udp) > 2) ... It may be that YP has been turned on, which can be checked with `chkconifg yp`. If so, then the YP master database needs to have the sgi-dogfight entry. Please notice that the /etc/services we ship has the entry commented out, because that port number is not registratable. Future releases support dog with the new multicast stuff. You may have noticed that the first multicast address is reserved for the multicast forwarder and the second is for dog. This should mean that it will be possible to run dog without crashing quite so many obsolete computers. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13229; 4 Mar 90 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13170; 4 Mar 90 20:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13151; 4 Mar 90 19:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11221; 4 Mar 90 19:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18670; Sun, 4 Mar 90 15:47:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 90 23:40:37 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Weird command flags Message-Id: <52669@sgi.sgi.com> References: <9003022216.AA27699@blumiris.chem.umr.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003022216.AA27699@blumiris.chem.umr.edu>, bobf@BLUMIRIS.CHEM.UMR.EDU ("Robert B. Funchess") writes: > A recent posting mentions that cc -s works but doesn't seem to be documented. cc(1) begins its option documentation by noting "The following options are interpreted by cc. See ld(1) for load-time options." And ld(1) documents the -s option. > We are running 3.1 rev D -- this may be fixed in 3.2 but I don't know -- in > which the man page for install says that -c means "put the file here, iff it > doesn't already exist". HOWEVER.... if I try to do this, install gives me > its built in "dummy, this is the proper syntax" line, which DOESN'T mention > a -c flag. The -c option along with -i and -n were dropped from install in 3.1, but the install(1) man page was not updated. 3.2 includes a man page for /etc/install that reflects reality. > Incidentally, the Irix install seems to be -- "enhanced" -- to the point of > incompatibility with a lot of Makefiles. Then again, the Irix make seems to > be "enhanced" to the point of incompatibility with a lot of Makefiles. Could you name some of the make enhancements that are incompatible? SGI inherited some seldom-used features from MIPS (IPATH, DPATH), and we have added our own often-used features lately. But the features I'm aware of should not create incompatibilities, unless they preempt macro names (as IPATH and DPATH do). > Back to the point: there is an error in either the manual or the install > command. Since I am trying to build TeX, there are one h*** of a lot of > Makefiles to wade thru and change every instance of "install" to be Irix- > compatible. Is it possible that TeX's makefiles are using the BSD install command, which has a -c (copy) option? SGI dropped the SVR3 install -c option because it was confusingly useless. When installing from a makefile, the target file's existence does not mean it's the same as the (usually new) source file being installed. AT&T install -c would tend to install your TeX files at most once in a given tree. That's why I'm wondering whether TeX's makefiles are not in fact invoking BSD install -c. Brendan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17044; 5 Mar 90 9:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac16710; 5 Mar 90 8:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab16651; 5 Mar 90 8:36 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16077; 5 Mar 90 7:49 EST Received: from HEARN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0260; Mon, 05 Mar 90 07:49:51 EST Received: from SURFnet.NL by HEARN.BITNET (Mailer R2.03B) with BSMTP id 2195; Mon, 05 Mar 90 13:46:10 MET Received: from NLR.NL by SURFnet.NL; Mon, 5 Mar 90 09:04 MET Date: Mon, 5 Mar 90 09:05 MET From: FBUIJSEN%NLR.NL@cunyvm.cuny.edu Subject: RE: piping binary files To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <9003050749.aa16077@SMOKE.BRL.MIL> Tom Rohling writes: > When I do this: > > >zcat foo.dat | foo > > > I get this response: > > >sue: unformatted io not allowed >apparent state: unit 5 named My guess is that the problem is in the unit number: on IBM and like mainframe machines units 5, 6 and 7 have special meanings: unit 5 is, for example, standard designated to punch-card (!) input and unit 6 to printer output. Of course, punch card input cannot be unformatted :-). I am not sure whether this problem only occurs when you READ (*,*) somewhere in your program (the * means 5, you know). My personal solution is now not to touch units 5 and 6 in any program with a ten-foot pole. Frans Buijsen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18124; 5 Mar 90 9:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16710; 5 Mar 90 8:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16651; 5 Mar 90 8:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15985; 5 Mar 90 7:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28264; Mon, 5 Mar 90 04:33:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 10:16:18 GMT From: Bruce Karsh Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Fast Fourier Transforms and the GVX Message-Id: <52686@sgi.sgi.com> References: <1990Mar2.160357.10094@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar2.160357.10094@hellgate.utah.edu> twolf%ug.utah.edu@cs.utah.edu (Tom Wolf) writes: >Several of us have been trying to figure out what Fourier Transforms are used >for in graphics processing? Any ideas? Fourier transforms are used in image processing for a variety of reasons: 1) Fast convolution. "Convolution" is a big fancy word for "weighted moving average". In other words, each pixel value is replaced by the sum of the nearby pixels multiplied by a weighting factor. I.e., -- P'[i,j] = \ W[m,n] * P[i-m,j-n] / -- m,n Convolutions are used to blur images, sharpen images, enhance edges, and lots of other things. The image processing literature is full of info about this. The calculation of a convolution as a sum of products is computationally costly. Using the FFT method, described in almost any book on signal processing is often much more efficient. 2) Digital filtering. Digital filters are used for anti-aliasing images. The Fourier Transform is sometimes used to design these filters. 3) Image compression. Various schemes have been tried to reduce the number of bits required to store an image by Fourier transforming an image and not storing all of the coefficients. For instance, low frequency components and small components may be discarded. Of course, this degrades the image quality, but in some instances, it may be worth it. 4) Shift invariant representation. The magnitude of the Fourier components of an image does not change when the image is translated. (The phase of the components do, however). For this reason, Fourier transforms are sometimes used to match a possibly shifted image against a pattern image. If the magnitude of the coefficients aren't approximately equal then the image doesn't match the pattern. Any others?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18733; 5 Mar 90 10:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18124; 5 Mar 90 10:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18056; 5 Mar 90 9:49 EST Received: from gemini.arc.nasa.gov by SMOKE.BRL.MIL id aa17722; 5 Mar 90 8:38 EST Received: Mon, 5 Mar 90 05:41:22 PST by gemini.arc.nasa.gov (5.57/1.2) Received: Mon, 5 Mar 90 05:41:12 PST by gemini.arc.nasa.gov (5.57/1.2) From: "RICHARD P. SIMONIAN" Date: Mon, 5 Mar 90 05:30 PST Message-Id: To: INFO-IRIS@BRL.MIL Subject: Creating Workspace icons X-Lines: 15 Does anyone know of a tool, or a way to use an existing tool, to graphically create Workspace icons (in the .ftr files)? The manual we have talks about doing it by hand, but I can't believe there's not an easier way. Especially after looking at the ones created by SGI! Quickpaint may be a possibility, but it's unclear how to map the saved files into something that the ftr compiler would understand. BTW... we're using 4D/20s. Any help? Rick Simonian Harris Space Systems Corp. rsimonian@nasamail.nasa.gov or... rsimonian%nasamail@ames.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19297; 5 Mar 90 10:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18733; 5 Mar 90 10:30 EST Date: Mon, 5 Mar 90 10:13:29 EST From: Gary S. Moss (VLD/VMB) To: Robert Lansdale cc: info-iris@BRL.MIL Subject: Re: How to kill tasks after a user abort? Message-ID: <9003051013.aa18526@VMB.BRL.MIL> Rob Lansdale writes: < So how do I assure that the parent process gets woken and becomes < the first process to enter the signal handler? I've (carefully) read through < the signal man page several times and tried a number of variations of the < SIGCLD signal catcher, but I still find that the parent process is getting < stuck occansionally in the printf() routine when it is about to print that < the display code is shutdown (printf() -> Psema() -> blockproc() ...). This < printf() is part of the signal handling code. Never ever call printf() or any of the functions from a signal handler; unless perhaps that's the only usage of stdio in the program. It will lead to potentially weird and fatal behavior if the signal interrupts a stdio function, causing the signal handler to re-enter printf() while the buffering mechanism is not stable. Signal handlers should do as little as possible as far as calling library routines which maintain internal states which could be interrupted by the signal, malloc() is another good example. If possible, set a global variable from your handler which can be detected and acted on from the main runstream. This can be difficult, depending on the structure of your program, and therefore is best built into the design from the start.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22086; 5 Mar 90 12:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21509; 5 Mar 90 12:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21291; 5 Mar 90 12:27 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa25381; 5 Mar 90 12:05 EST Received: Mon, 5 Mar 90 12:07:49 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 5 Mar 90 12:07:49 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003052007.AA01844@aero4.larc.nasa.gov> To: amelia!ew01!lonhyn@ames.arc.nasa.gov Subject: Re: Flight, how to dogfight? Cc: info-iris@BRL.MIL 1) check /etc/services to make sure the entry for dogfight is not commented out. 2) shadow allows passive observation of the dog environment, it is documented in the 3000 manuals, but I couldn't find it in the 4D manual. 3) dog broadcasts to EVERYONE so if anyone is doing dog on your network you will join them. Dog FLOODS the network, so use it on small isolated networks, or it could cause a lot of problems. Someone a while back posted patches so you could fight only one other machine. There are also suppose to be some other similar patches. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22722; 5 Mar 90 13:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22447; 5 Mar 90 13:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22138; 5 Mar 90 12:58 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa24875; 5 Mar 90 11:44 EST Received: Mon, 5 Mar 90 11:45:32 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 5 Mar 90 11:45:32 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003051945.AA01738@aero4.larc.nasa.gov> To: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!1k1mgm@tut.cis.ohio-state.edu Subject: Re: Power Iris memory sources, please? Cc: info-iris@BRL.MIL Here is a list I have compiled from info-iris mail. I don't know how good or bad any of them are we haven't ordered anything yet. Sophistecated Circuits, Seattle (206) 547-4779 Memory for 4D 20's, $310/Mb (in late April '89) Impediment, Inc., 333 Duxbury, MA 02332, (617) 837-8877 Memory for 4D 20's, 1Mb simms, $90/Mb (early January '90) Memory for 4D 20's, 4Mb simms, $187.5/Mb (early January '90) Memory for 4D 200's $225/Mb (early January '90) (Have heard good things about this company, including 5 year replacement guarantee, not 90 days like some companies) ClearPoint, 35 Parkwood Drive, Hopkington,MA 07148, (800) 253-2778 (508) 435-2000 Memory for 4D 20's, $76/Mb (GSA pricing) (late February '90) 1Mb sims, $100/Meg (80Ns); 4Mb sims, $200/Meg (Life time warranty.) Helios? all I have is a name no address or phone number. If anyone has any more names to add to the list please let me know. Also, please include an address or at least a phone number for the company. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22953; 5 Mar 90 13:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab22086; 5 Mar 90 13:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22019; 5 Mar 90 12:54 EST Received: from sgi.com by SMOKE.BRL.MIL id aa25756; 5 Mar 90 12:26 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/900301.SGI) for info-iris@brl.mil id AA05859; Mon, 5 Mar 90 08:43:53 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:info-iris@brl.mil id AA21467; Mon, 5 Mar 90 08:43:42 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA14376; Mon, 5 Mar 90 08:43:39 PST Message-Id: <9003051643.AA14376@forest.sgi.com> To: info-iris@BRL.MIL Subject: Re: Fast Fourier Transforms and the GVX In-Reply-To: Your message of 02 Mar 90 23:03:57 +0000. <1990Mar2.160357.10094@hellgate.utah.edu> Date: Mon, 05 Mar 90 08:43:36 PST From: baskett%forest@sgi.com The new graphics subsystem is VGX, not GVX. It is also refered to by the product literature as PowerVision. It contains an "ImageVision Library" for FFT's, image rotations, warps, and convolutions directly in the graphics pipeline. It does not use FFT chips in the graphics pipeline; it uses special code in the geometry subsystem to apply its 128 mflops to image processing problems like FFT. As to what FFT's are used for in graphics processing, one perhaps needs to include image processing as part of graphics processing. The general trend in general purpose graphics workstations is to include more and more high performance graphics functionality in base systems thus making special purpose systems less often required. We are trying to participate in this trend. We believe the VGX has several new features that are examples of this trend, the imageVision library being one of them. Forest Baskett Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24812; 5 Mar 90 15:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24558; 5 Mar 90 15:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24530; 5 Mar 90 15:20 EST Received: from umrvmb.umr.edu by SMOKE.BRL.MIL id aa29370; 5 Mar 90 14:13 EST Received: from blumiris.chem.umr.edu by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with TCP; Mon, 05 Mar 90 13:15:08 CST Received: by blumiris.chem.umr.edu (5.52/5.6) id AA28827; Mon, 5 Mar 90 13:14:48 CST Date: Mon, 5 Mar 90 13:14:48 CST From: "Robert B. Funchess" Posted-Date: Mon, 5 Mar 90 13:14:48 CST Message-Id: <9003051914.AA28827@blumiris.chem.umr.edu> To: info-iris@BRL.MIL Subject: Make problems I finally figured out what was causing the Make problems, by comparing a Makefile from ~4Dgifts with the problem one. Apparently on some systems it is NOT necessary to explicitly specify SHELL=/bin/sh, that being taken as a given. Irix *seems* to require this, or at least it generally works if I include it. Unless of course I need the BSD-flavor install. The real problem is that there are (at least) two main kinds of unix and whatever it is that you need was written for the other one, no matter which one it is that you have. -- < Bob | bobf | Funchess > Stay alert! Trust no one! Keep your laser handy!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25138; 5 Mar 90 16:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab24812; 5 Mar 90 16:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24786; 5 Mar 90 15:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01880; 5 Mar 90 15:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24785; Mon, 5 Mar 90 12:14:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 18:46:14 GMT From: Robert Skinner Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Fast Fourier Transforms and the GVX Message-Id: <4875@odin.SGI.COM> References: <1990Mar2.160357.10094@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar2.160357.10094@hellgate.utah.edu>, twolf%ug.utah.edu@cs.utah.edu (Tom Wolf) writes: > In reading through the literature on the latest Graphics machines(I believe > they are called GVX's), I see that they use Fast Fourier Transform chips in > the graphics pipeline. > > As I have an application that requires thousand's of Fourier Transforms, > I am curious as to whether you can use the FEEDBACK function to help > crunch the FT's? Does anyone know if this is possible? > > > Several of us have been trying to figure out what Fourier Transforms are used > for in graphics processing? Any ideas? > > > > Thanks, > > Tom I assume you mean the GTX. caveat: someone else should be responding with the scoop on what hardware is in a GTX, not a new software engineer like me. But since they haven't, I'll try and provide correct information... The FFT is used in image processing, but not in normal graphics processing. The IRIS graphics hardware does not compute an FFT. I'm not aware of any chips that specifically perform the FFT, and I'm sure that there aren't any in the IRIS's. Some IRIS's (just the PIs, I think) have Digital Signal Processing chips in them. These DSP chips are often used to compute the FFT *in other products*, but they are just used as very fast processors in the PI. Robert Skinner robert@sgi.com Whoa Homer, don't have a cow. - Bart Simpson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25647; 5 Mar 90 17:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25532; 5 Mar 90 17:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25513; 5 Mar 90 16:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04140; 5 Mar 90 16:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29225; Mon, 5 Mar 90 13:24:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 20:55:14 GMT From: John Clayton Webster Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Flight, how to dogfight? Message-Id: References: <5084@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Lonhyn T. Jasinskyj writes: 2) What is the difference between dog and shadow I have never seen a man page for dog or flight. Don't feel left out. Well, I suppose I can save you some time with the second point, so here goes... Dog allows you to connect to prerecorded flights and/or record flights. I do not know if it allows you to connect to ongoing flights on other machines, because I haven't ever used or had access to more than one machine at a time. I believe it is just a flight option tho. dog -i -o . Layering recordings can make quite nice scenarios. I have built a good five or six nice and difficult enemy targets. You can select heads-up options as well. Shadow allows you to enter a flight as a viewer. You bop around from plane to plane at your whim looking at everything happening from any plane angle you desire. I use it to examine recordings I make with dog. I imagine it can be hooked up to a running flight fairly easily also. Hope this helps. Clay Webster   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26186; 5 Mar 90 18:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26094; 5 Mar 90 18:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26079; 5 Mar 90 18:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05751; 5 Mar 90 17:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04289; Mon, 5 Mar 90 14:41:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 22:41:47 GMT From: Marie desJardins Organization: University of California, Berkeley Subject: Running an X Terminal off of a 210 Message-Id: <34750@ucbvax.BERKELEY.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there any reason why I shouldn't be able to slap an X terminal onto a 4D/210GTX over Ethernet? Since only the application/Xlib fraction would be running on the SGI, there shouldn't be any problem with the funny X/NeWS hybrid system running on the SGI, correct? Also, if anyone out there is actually running this set-up, I'd like to hear from you on how smooth it was, what the network overhead is like, and whether you had any recommendation for specific X terminal vendors. Thanks muchly in advance! Please mail responses to: "marie@ernie.berkeley.edu"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26186; 5 Mar 90 18:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26094; 5 Mar 90 18:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26084; 5 Mar 90 18:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05849; 5 Mar 90 18:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04676; Mon, 5 Mar 90 14:48:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 22:48:04 GMT From: Marie desJardins Organization: University of California, Berkeley Subject: Optical disks on the SGI Message-Id: <34751@ucbvax.BERKELEY.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone out there put an optical disk drive onto an Iris, either the PI or the GTX? Information on experiences with either WORMs or Rewritables would be much appreciated, including hardware issues like cable adapters and software such as drivers and FS mods. Also, vendors and ballpark cost figures would be great. Please post responses to "marie@ernie.berkeley.edu"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29614; 6 Mar 90 3:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29585; 6 Mar 90 2:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29536; 6 Mar 90 2:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11608; 6 Mar 90 2:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04062; Mon, 5 Mar 90 23:07:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 04:58:02 GMT From: John Buchanan Organization: Imager, UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Exabyte drive (Non sgi supplied) Message-Id: <7016@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has any one managed to hook up a 3rd party exabyte drive to a sgi box? I just spend a whole day going through the documentation and I cannot seem to find the exact set of commands to issue. Since I am waiting for a cable I have been forced to hack with out touching the computer :-(, probably safer in the long run :-). My guess is that I simply set it up as a quarter inch drive and let the SCSI driver handle the rest. This is probably incorrect, but it seems like a good place to start. Does any one have any better advise? ========================================================================= | |===============================| | John Buchanan (juancho) | buchanan@cs.ubc.ca | | Imager Manager |===============================| | Imager | (604) 228-2218 | | Department of Computer Science |===============================| | University of British Columbia | Standard disclaimer | | Vancouver, BC, Canada | included in this | | | box, right here. | =========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01862; 7 Mar 90 14:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ah01096; 7 Mar 90 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ap00223; 7 Mar 90 13:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25634; 7 Mar 90 12:41 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25259; Tue, 6 Mar 90 14:30:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Mar 90 21:54:55 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: How to kill tasks after a user abort? Message-Id: <4888@odin.SGI.COM> References: <9003051013.aa18526@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003051013.aa18526@VMB.BRL.MIL>, moss@BRL.MIL ("Gary S. Moss", VLD/VMB) writes: > Rob Lansdale writes: > < So how do I assure that the parent process gets woken and becomes > < the first process to enter the signal handler? I've (carefully) read through > < the signal man page several times and tried a number of variations of the > < SIGCLD signal catcher, but I still find that the parent process is getting > < stuck occansionally in the printf() routine when it is about to print that > < the display code is shutdown (printf() -> Psema() -> blockproc() ...). This > < printf() is part of the signal handling code. > > Never ever call printf() or any of the functions from a signal > handler; unless perhaps that's the only usage of stdio in the program. It > will lead to potentially weird and fatal behavior if the signal interrupts > a stdio function, causing the signal handler to re-enter printf() while the > buffering mechanism is not stable. Signal handlers should do as little as > possible as far as calling library routines which maintain internal states > which could be interrupted by the signal, malloc() is another good example. > > If possible, set a global variable from your handler which can be detected > and acted on from the main runstream. This can be difficult, depending on > the structure of your program, and therefore is best built into the design > from the start. This is always good advice. In addition, since printf and friends are automatically being protected from multiple shared processes simultaneously accessing them, a signal can easily interrupt a printf, while it has the lock protecting the printf buffers. As for the more general question, using shared processes is no different than normal Unix processes - only the parent will get SIGCLD if a child dies, and the children will not get signaled if the parent dies (unless the parent is a process group leader). Since most applications writers seem to prefer that if the 'master' thread dies, that all its children/salve threads die, in an upcoming release we are adding a function that more tightly binds share group members together. As for SIGINT, which threads get the signal depends on what the disposition of the signal was when you did the sproc - at that point each slave gets its own copy (just like fork()) of the signal mask and disposition. Thus signal handling is not currently a shared resource... If you wish that the master/parent handle a signal differently than the slaves, then first set up the handler as you want the slaves to receive them, spawn the slaves, then in the parent change the handler to the one you want for just the parent... Chris Wagner (jwag@sgi.com)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29450; 6 Mar 90 2:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29328; 6 Mar 90 2:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab29300; 6 Mar 90 2:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11359; 6 Mar 90 1:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02905; Mon, 5 Mar 90 22:47:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 06:33:45 GMT From: Jeremy Webber Organization: Digital Arts Film and Television Subject: Wren VI drives on a Personal Iris Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are contemplating purchasing a Seagate (CDC) Wren VI drive to attach to a Personal Iris. Has anybody had successes or problems with this drive? Thanks, Jeremy Webber -- -- Jeremy Webber ACSnet: jeremy@chook.ua.oz Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au 60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430 Australia Papernet: +61 8 272 2774 (FAX)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29450; 6 Mar 90 2:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29328; 6 Mar 90 2:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac29300; 6 Mar 90 2:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11361; 6 Mar 90 1:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02622; Mon, 5 Mar 90 22:42:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 06:01:00 GMT From: George Seibel Organization: Computer Graphics Lab, UCSF Subject: Re: Fast Fourier Transforms and the GVX Message-Id: <13258@cgl.ucsf.EDU> References: <1990Mar2.160357.10094@hellgate.utah.edu>, <9003051643.AA14376@forest.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003051643.AA14376@forest.sgi.com> baskett%forest@SGI.COM writes: ]The new graphics subsystem is VGX, not GVX. It is also refered to by ]the product literature as PowerVision. It contains an "ImageVision ]Library" for FFT's, image rotations, warps, and convolutions directly ]in the graphics pipeline. It does not use FFT chips in the graphics ]pipeline; it uses special code in the geometry subsystem to apply its ]128 mflops to image processing problems like FFT. As to what FFT's are ^^^^^^^^^! You just got my attention here... Any chance of getting at these mflops in a convenient way from high level code for general number crunching purposes? Is there enough precision to make it worthwhile? You wouldn't happen to have 1/sqrt(r) in there, would ya? George Seibel, UCSF seibel@cgl.ucsf.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29511; 6 Mar 90 2:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29328; 6 Mar 90 2:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29300; 6 Mar 90 2:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11334; 6 Mar 90 1:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02724; Mon, 5 Mar 90 22:44:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 06:19:51 GMT From: Operator Organization: Dept. of Math., Univ. of Arizona, Tucson AZ 85721 Subject: irisplot source Message-Id: <1493@amethyst.math.arizona.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, there: A couple of months ago, we posted a note about Irisplot. Some of the SGI users are interested in the source. We are sorry for not being able to reply to each of you. The source now is available for testing (tar format). As before, you can get it by anonymous ftp from connemara.math.arizona.edu (128.196.224.5). good luck Maorong   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02587; 6 Mar 90 8:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02156; 6 Mar 90 8:37 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa02071; 6 Mar 90 8:24 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa17472; 6 Mar 90 6:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12241; Tue, 6 Mar 90 02:34:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 06:06:46 GMT From: Rob Warnock Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIS Keyboard & etc. Message-Id: <52816@sgi.sgi.com> References: <2715@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2715@fs1.cam.nist.gov> blue@cam.nist.gov (Jim Blue) writes: +--------------- | I have been active at RTFM, all 31 volumes (though most of them don't apply) | but haven't found how to get the number of lines and columns inside a wsh. | (getsize() gives the size in pixels, but not in lines and columns.) Since vi, | among other programs knows how to do this, it must be possible. +--------------- Well, I don't know about "vi", but when porting a "lines&columns" app to an Iris recently, I found the more-or-less-standard Berkeley kernel screen size stuff [fragments attached below] to work just fine. That is, TIOCGWINSZ to get the size, and SIGWINCH to know when it changes. Resizing by dragging on a corner "does the right thing". So "wsh" must be telling the kernel. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 ============== attachment: code fragments ================================== #ifdef TIOCGWINSZ /* try to get window size from kernel */ struct winsize winsize; #ifdef SIGWINCH /* and if changing dynamically, track it int onwinch(); #endif #endif ============== ...somewhere in main()... #ifdef SIGWINCH signal(SIGWINCH, onwinch()); #endif ============== ...wherever it is (in main()?) you try to find out screen size... #ifdef TIOCGWINSZ if (ioctl(0, TIOCGWINSZ, &winsize) >= 0 && winsize.ws_row > 0 /* avoid common stty screwup */ && winsize.ws_col > 0 ) { MaxRow = winsize.ws_row - 1; /* make 0-based */ MaxCol = winsize.ws_col - 1; } else #endif { /* just use termcap size */ MaxRow = tgetnum ("li") - 1; MaxCol = tgetnum ("co") - 1; } ...do whatever calculations are needed based on the screen size... ============== #ifdef SIGWINCH onwinch() { /* * screen size changed -- do the right things */ if (ioctl(0, TIOCGWINSZ, &winsize) >= 0 && winsize.ws_row > 0 /* avoid common stty screwup */ && winsize.ws_col > 0 ) { MaxRow = winsize.ws_row - 1; MaxCol = winsize.ws_col - 1; } else { MaxRow = tgetnum ("li") - 1; MaxCol = tgetnum ("co") - 1; } ...do whatever calculations for values that have to change because the screen size changed, then... redraw(); /* clear and draw from scratch */ signal(SIGWINCH, onwinch); /* re-enable signal */ } #endif   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03015; 6 Mar 90 9:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02717; 6 Mar 90 9:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02678; 6 Mar 90 8:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14981; 6 Mar 90 8:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20454; Tue, 6 Mar 90 05:20:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 08:32:50 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: tar problems Message-Id: <3890@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Now that we are running 3.2, Has there been any major changes to 'tar' from a 3.1B release aside from things like the 'e' option and the like that would cause the following kinda thing to happen?: I had backed up alot of computations data on tape last spring and had just used 'tar -cv data' which was the directory I had things in. Well since 'data' took up more space than a single tape could hold, it kindly asked to 'please insert a new tape and press enter' or some congenial thing like that. Anyway, now that I try to get the stuff back off it's not so kind anymore and it doesn't recognize that the one tape ended and to put in the next tape and continue reading. The real problem is is that the end of the tape was in the middle of one of the files that I need and hence it doesn't get it all off the tape. It wouldn't matter much if this wasn't an important data file but it happens to be in the middle of some time series data that was quite costly to generate on a X-MP and is a big part towards my impending thesis deadline. This never happened when I origionally did all this under 3.1B, at that time it asked to put in the next tape and continue. We have not changed the tape drive or anything since, only the OS. Here's what transcribed this time: [14] % tar -xveqqqqqq ** the more q's the better ** x data/cldm230.10, 1320000 bytes, 2579 blocks x data/cldm230.20, 1760000 bytes, 3438 blocks x data/cldm230.30, 1760000 bytes, 3438 blocks x data/cldm230.40, 1760000 bytes, 3438 blocks .... a whole bunch of filenames deleted for brevity x data/cldm25.40, 880000 bytes, 1719 blocks x data/cldm25.50, 880000 bytes, 1719 blocks x data/cldm25.60, 880000 bytes, 1719 blocksmyio(read): wanted 204800 bytes, got 0 tar: tape premature EOF [15] % ls So here's where I put in the next tape that it was supposed to ask me to put in and then try to continue the process. The next error isn't suprising though, [16] % tar -xveqqqqqqq ** without the e it wouldn't even start reading ** tar: Directory checksum error. Continuing................................... ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ............................................................................. ...........................................................................OK x data/cldm25.70, 880000 bytes, 1719 blocks x data/cldm25.80, 880000 bytes, 1719 blocks x data/cldm25.90, 880000 bytes, 1719 blocks ..... and on it continues. If it helps here's what I get when I list the inventory: [20] % hinv 12 MHZ IP4 Processor FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 1.5 CPU: MIPS R2000A/R3000 Processor Chip Revision: 1.6 Data cache size: 32 Kbytes Instruction cache size: 64 Kbytes Main memory size: 16 Mbytes Interphase 3201 2-drive ESDI disk controller 0 ESDI Disk drive: unit 0 on Interphase controller 0 CMC ENP-10 Ethernet controller 0, firmware version 0 (CMC) Integral SCSI controller WD33C93 Tape drive: unit 7 on SCSI controller 0: QIC 24 [21] % H H EEEE L PPPP !! H H E L P P !! HHHHH EEE L PPPP !! H H E L P !! H H EEEE LLLL P .. Any whizz's know what I could do to get this back? HEAPS OF THANKS IN ADVANCE ****************************************************************************** TOM ROHLING trohling@uceng.uc.edu or rohling@afiris.ase.uc.edu ******************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03938; 6 Mar 90 10:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03691; 6 Mar 90 10:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03619; 6 Mar 90 9:57 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa16711; 6 Mar 90 9:11 EST Received: Tue, 6 Mar 90 09:14:31 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 6 Mar 90 09:14:31 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003061714.AA05556@aero4.larc.nasa.gov> To: marie@ernie.berkeley.edu Subject: Re: Optical disks on the SGI Cc: info-iris@BRL.MIL I have seen a couple of messages from people who have, they seemed to be pleased with what they were using. One person was evaluating a MO (magneto-optical) drive. He was quite impessed with it, he said it was unfortunate that they would not be able to buy it (funding problems). I don't remember off hand who that person was or which company the drive was from, I'll have to see were I put that info. So far I have only seen two companies advertise that they support machines on SGI equipment. They are: Genesis Imaging Technologies, Inc. 1220 Valley Forge Rd. Valley Forge, PA 19482-0962 Phone: (215) 933-4848 Sales Rep.: Barbara A. Wandersee Drive ~ $6,000 , Disk: ~$230 Introl Corporation A Control Systems Company Intelligent Peripheral Control 2675 Patton Road St. Paul, Minnesota 55113 Phone: (612) 631-7600 Director, Marketing, and Sales: Bruce J. Brunette Drive & SCSI port: ~$14,000, Disk ~$230 Both companies use the Sony SMO-D501 MO drives. We are concidering buying a MO drive and are also interested in what people have to say about their experience with both of these companies. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04657; 6 Mar 90 11:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04485; 6 Mar 90 11:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04441; 6 Mar 90 11:12 EST Received: from ux1.cso.uiuc.edu by SMOKE.BRL.MIL id aa19051; 6 Mar 90 10:50 EST Received: by ux1.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA15290; Tue, 6 Mar 90 09:52:29 -0600 Date: Tue, 6 Mar 90 09:52:29 -0600 From: Amy Swanson Message-Id: <9003061552.AA15290@ux1.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: directory write but no delete??? Cc: amys@ncsa.uiuc.edu I have a user who would like for users to be able to create files in a directory (owned by that user) but not delete files from that directory (unless "self-owned"). Setting the sticky bit would normally solve this, but the SGIs/IRIX don't do the sticky bit thing. Is there a workaround for this that I could use? Thanks for any information, Amy ======= Amy Swanson SGI/Alliant Systems Administrator NCSA - National Center for Supercomputing Applications University of Illinois @ Urbana-Champaign amys@ncsa.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00953; 6 Mar 90 14:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00089; 6 Mar 90 14:24 EST Received: from aos.brl.mil by VMB.BRL.MIL id aa05761; 6 Mar 90 12:57 EST Received: from lvax.brl.mil by AOS.BRL.MIL id aa24361; 6 Mar 90 12:53 EST Date: 6 Mar 90 12:54:00 EST From: "Earl N. Ferry" Subject: Optical Drives for Iris' To: info-iris Message-ID: <9003061253.aa24361@AOS.BRL.MIL> We are currently looking into a company called Q-Systems for an optical drive for our iris 4D/20's. Q-Systems 6701 Democracy Boulevard Suite 300 Bethesda, MD. 20817 Phone: (301)-571-9338 Sales Rep.: Brian Swafford Drive $7500, Disk $250 I cannot remember if these prices are GSA or not, but the Drive is the SONY SMO-S501 Erasable Optical Drive, and the disks are 650Meg (325Meg/side). Earl N. Ferry, Jr. USARMY Ballistic Research Lab Aberdeen Proving Grounds, MD. 21005-5066 Phone: (301)278-2916 Email: eferry@brl.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01869; 6 Mar 90 15:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01251; 6 Mar 90 14:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01014; 6 Mar 90 14:38 EST Received: from sgi.com by SMOKE.BRL.MIL id aa22839; 6 Mar 90 12:58 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/900301.SGI) for info-iris@brl.mil id AA22902; Tue, 6 Mar 90 09:24:55 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:seibel@cgl.ucsf.edu id AA00813; Tue, 6 Mar 90 09:24:53 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA18756; Tue, 6 Mar 90 09:24:51 PST Message-Id: <9003061724.AA18756@forest.sgi.com> To: seibel@cgl.ucsf.edu Cc: info-iris@BRL.MIL Subject: Re: Fast Fourier Transforms and the VGX Date: Tue, 06 Mar 90 09:24:48 PST From: baskett%forest@sgi.com ------- Forwarded Message From: George Seibel baskett%forest@SGI.COM writes: ] it uses special code in the geometry subsystem to apply its ]128 mflops to image processing problems like FFT. ^^^^^^^^^! You just got my attention here... Any chance of getting at these mflops in a convenient way from high level code for general number crunching purposes? Is there enough precision to make it worthwhile? You wouldn't happen to have 1/sqrt(r) in there, would ya? ------- End of Forwarded Message Most signal processing, image processing and geometry processing share the property of not usually needing double precision floating point. Most general number crunching is done in double precision. The 128 mflops in the geometry subsystem of the VGX is single precision. And the 128 mflops number is a peak number. For peak double precision, we recommend the 8 general purpose processors of the 4D/280 - -100 mflops. Forest Baskett Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02541; 6 Mar 90 15:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01869; 6 Mar 90 15:19 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa01636; 6 Mar 90 14:54 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa00721; 6 Mar 90 13:40 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09643; Tue, 6 Mar 90 10:37:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 18:21:58 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Exabyte drive (Non sgi supplied) Message-Id: <52832@sgi.sgi.com> References: <7016@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <7016@ubc-cs.UUCP>, buchanan@cs.ubc.ca (John Buchanan) writes: > My guess is that I simply set it up as a quarter inch drive and let the > SCSI driver handle the rest. This is probably incorrect, but it seems like > a good place to start. Does any one have any better advise? > 1st, be running 3.2 s/w release. Next, address the drive as 6, preferably. Next, look in /dev/mt. There will be several devices with 6 as the address. there are nr, ns, and v and combinations thereof. All will talk to the Exabyte drive... There are *some* drives that give back a vendor specific string on an inquiry, and there is some problem talking to the drive if that is so, as the s/w has no way of `knowing' what the heck it is. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac04839; 6 Mar 90 17:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04669; 6 Mar 90 17:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04568; 6 Mar 90 17:14 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa08159; 6 Mar 90 16:56 EST Received: Tue, 6 Mar 90 16:58:43 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 6 Mar 90 16:58:43 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003070058.AA07718@aero4.larc.nasa.gov> To: eferry@lvax.brl.mil Subject: Re: Optical Drives for Iris' Cc: info-iris@BRL.MIL Are you sure about them being 650Mb? I think they are less than 600Mb when used with an SGI machine. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01436; 7 Mar 90 13:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00089; 7 Mar 90 13:27 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa02883; 7 Mar 90 11:12 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa22435; 7 Mar 90 10:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06218; Tue, 6 Mar 90 17:14:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 00:47:49 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Flight, how to dogfight? Message-Id: <52877@sgi.sgi.com> References: <9003052007.AA01844@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've resurrected the old IRIS-3000 man pages for dog and shadow for the next release of IRIS-4D software. I've also tried to bring them up to date. So be patient ... they're coming. Think about the command "man dog" ... best friends or what??? -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01096; 7 Mar 90 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad00223; 7 Mar 90 13:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24483; 7 Mar 90 11:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08600; Tue, 6 Mar 90 17:49:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 00:43:06 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: Running an X Terminal off of a 210 Message-Id: <4948@odin.SGI.COM> References: <34750@ucbvax.BERKELEY.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There should be no problem running an X terminal off of an SGI box. I do it every day. --Jeff Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac01096; 7 Mar 90 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ae00223; 7 Mar 90 13:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24663; 7 Mar 90 11:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27886; Tue, 6 Mar 90 15:11:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 20:25:27 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: IRIS Keyboard & etc. Message-Id: <4944@odin.SGI.COM> References: <2715@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content." In article <2715@fs1.cam.nist.gov>, blue@cam.nist.gov (Jim Blue) writes: > I have been active at RTFM, all 31 volumes (though most of them don't apply) > but haven't found how to get the number of lines and columns inside a wsh. > (getsize() gives the size in pixels, but not in lines and columns.) Since vi, > among other programs knows how to do this, it must be possible. > Use the bsd ioctl. #include ioctl(fd, TIOCGWINSZ &winsiz) or let curses/terminfo handle it for you. It appears we didn't add this to our termio man page. Sorry about that. > Appendix A.2 of the "Using the GL/DGL Interface" in the "4Sight Programmer's > Guide lists the string supposedly returned by each key. I find that some > work and some don't. For example, F1 really does return "ESC [ 001 q" (without > the quotes and spaces), but F4 returns some garbage left over from an > old "ls" command. After powering the machine down and up, F4 returns some > other stuff (I don't know what). wsh sets up some default bindings on the function keys. See wsh(1) and bindkey(1) for details. > > Alt C with the right Alt key returns the correct value, but not with the > left Alt key. The left alt key is really a COMPOSE key. -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad01096; 7 Mar 90 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ag00223; 7 Mar 90 13:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24737; 7 Mar 90 11:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02027; Tue, 6 Mar 90 16:11:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 23:48:34 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Geometry Data Bases Message-Id: <52872@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know know of any swell public domain, or commercial geometry databases that are available? We're looking for data describing interesting geometric objects. Paul Haeberli paul@sgi.com 415-962-3665   Received: from VMB.BRL.MIL by VMB.BRL.MIL id af01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae01096; 7 Mar 90 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aj00223; 7 Mar 90 13:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24794; 7 Mar 90 12:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23309; Tue, 6 Mar 90 14:00:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 21:35:19 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: yp/resolver Message-Id: <52855@sgi.sgi.com> References: <5214.25f3c15f@uwovax.uwo.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <5214.25f3c15f@uwovax.uwo.ca> weimei@uwovax.uwo.ca writes: >We are running YP and resolver (i.e. /usr/etc/resolv.conf) on the 4D70GT. >Is there a way to talk to the resolver directly while still running yp for >passwd? Coming soon in a future release of IRIX.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id af01096; 7 Mar 90 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ak00223; 7 Mar 90 13:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24801; 7 Mar 90 12:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13061; Tue, 6 Mar 90 11:29:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 18:55:42 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!ria!uwovax!weimei@ucsd.edu Subject: yp/resolver Message-Id: <5214.25f3c15f@uwovax.uwo.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, We are running YP and resolver (i.e. /usr/etc/resolv.conf) on the 4D70GT. Is there a way to talk to the resolver directly while still running yp for passwd? Right now if I'm not serving the hosts map through ypserv -i I get unknown host instead of it hitting the nameserver. Thanks in advance! -- Wei Mei Shyr Phone: (519) 679-2151 ext. 6043 Internet: WEIMEI@uwovax.uwo.ca Bitnet: WEIMEI@UWOVAX.BITNET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ah01436; 7 Mar 90 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ai01096; 7 Mar 90 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aq00223; 7 Mar 90 13:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25693; 7 Mar 90 12:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24480; Tue, 6 Mar 90 14:17:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 90 18:39:42 GMT From: "Lonhyn T. Jasinskyj" Organization: NASA Ames Research Center, Moffett Field, CA Subject: Thanks for the dog info Message-Id: <5112@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thanks to all those who helped to get my important dog-fighting research off the ground. Countless lives have been saved and crises averted. The problem was that I was running yp and the yppush had failed to my particular ypserver. Everything seems OK now. Does anyone have the mentioned patches to allow dog to run between two machines without flooding the network with broadcast messages? E-mail me if you have any leads on these fine modifications. Thanks for all the help. Lonnie -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Email to: lonhyn@ew01.nas.nasa.gov Human at: 415-604-3989 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02489; 7 Mar 90 14:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad01862; 7 Mar 90 14:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac01796; 7 Mar 90 14:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24816; 7 Mar 90 12:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12450; Wed, 7 Mar 90 03:06:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 04:43:05 GMT From: Ian Hoyle Organization: none Subject: need tape tools for 9 track tape unit Message-Id: <1449@merlin.bhpmrl.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have/know of a set of utilities for the SGI 9 track tape unit ?? They have to read non Unix dumped ASCII tape files. Format conversion (ascii -> ebcdic, fixed -> data sensitive etc) would be nice but non-essential. We need this stuff _real_soon_now_ !! :-) ian -- Ian Hoyle /\/\ / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01436; 7 Mar 90 13:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01096; 7 Mar 90 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00223; 7 Mar 90 13:16 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23875; 7 Mar 90 11:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28489; Wed, 7 Mar 90 07:52:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 14:53:15 GMT From: Jim Blue Organization: National Institute of Standards & Technology, Gaithersburg, MD Subject: Alternate character sets Message-Id: <2757@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL curses(3) allows line graphics to be drawn using an alternate character set. I would like to do this outside of curses. Can I do this by changing to the appropriate font, then sending the appropriate characters to the screen? If so, what font does curses use? Thanks, Jim Blue   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01862; 7 Mar 90 14:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag01096; 7 Mar 90 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id an00223; 7 Mar 90 13:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24998; 7 Mar 90 12:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26412; Wed, 7 Mar 90 07:21:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 15:16:47 GMT From: Schrickel Randall Organization: Johns Hopkins University Subject: 2 Perplexing Problems Message-Id: <4857@aplcen.apl.jhu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have 2 very strange problems with a single application we have in house. I've talked to the Hot Line about the first, but haven't had any luck with what they suggested. Any help will be GREATLY appreciated (the Governor is coming in for a demo this weekend!) 1) The application gives random horizontal streaks of color across the screen. Hot line says we are trying to use an invalid bit plane (writemask) or color, but I have had no luck looking at those areas. Any other pointers/things to look at? 2) The same application goes through periods of slowing down then running at a normal speed. We have checked memory allocation, thinking that it may be growing, swapping, shrinking, but that looks like another dead end. It REALLY slows down; the animation almost stops. Help! Our setup has 6 2400 Turbos (4-6 Mb memory) networked to an HP 9000 835S. The application is a double-buffered animation program. The application acts the same on all 6 2400s, so we don't think it's a hardware problem. We also have other programs that use double buffering that don't have these problems. We are using the Remote Graphics Library (which we didn't develop; maybe it's from the Naval Postgrad School?) which uses sockets on both ends so the host HP sends graphics commands to the 2400s. Running 3.6 Unix. Also, to help with (2), what can I use to monitor my system/application performance besides "cc -p and prof"? Any PD full-screen monitors out there? If so, where? MUCH Thanx in advance!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03447; 7 Mar 90 15:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02768; 7 Mar 90 14:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02725; 7 Mar 90 14:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29302; 7 Mar 90 14:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11974; Wed, 7 Mar 90 11:30:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 17:29:09 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Optical Drives for Iris' Message-Id: <52923@sgi.sgi.com> References: <9003070058.AA07718@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003070058.AA07718@aero4.larc.nasa.gov>, blbates@aero4.larc.nasa.gov ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > Are you sure about them being 650Mb? I think they are less than 600Mb > when used with an SGI machine. > -- Yup, that is correct. The 512 byte/sector media yields only 298 MB/side, or 596 total. The 1024 byte/sector media (which is not filesystem compatible----yet) yields 652 total. If you use the (not yet readily available, I'm to understand) ZCAV media, this will be up lots--like 466/side at 512 byte sectors. I'm not sure if Sony supports this media, but the unit that SGI is considering OEMing certainly will. Our sales people can assist you in contacting one of our Geometry Partners for obtaining WORM, ROM and I think some MO (erasable) 3rd party solutions if you can't wait for the product from SGI (RSN (real soon now)). Don't be too hasty. We expect our device to be quite a bit faster than the products currently available. It is so far..... markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01126; 7 Mar 90 18:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00565; 7 Mar 90 17:51 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa00480; 7 Mar 90 17:34 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa01129; 7 Mar 90 17:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22172; Wed, 7 Mar 90 14:17:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 16:33:00 GMT From: David Wood Organization: New York University Subject: Re: tar problems Message-Id: <17280033@acf4.NYU.EDU> References: <3890@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Could it be that when you originally made the tar tape the tar you were using was gnu tar. I know that their makefile uses the name 'tar' when installing the binary. If that tar got lost and overwritten with the original during the upgrade this might explain your problems. Although, even gnu tar requires the -M option for multi- volumes.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01631; 7 Mar 90 18:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01126; 7 Mar 90 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00986; 7 Mar 90 17:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03893; 7 Mar 90 17:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20976; Wed, 7 Mar 90 13:58:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 21:46:14 GMT From: "Blair P. Houghton" Organization: Boston Univ. Col. of Eng. Subject: Fortran Graphics library loses device number in qread Message-Id: <5466@buengc.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Posting for a friend, therefore, please Send informative replies and requests for more info to gross@bucrf2.bu.edu (uunet!bu.edu!bucrf2!gross). When using qread() in Fortran on an IRIS 4D/220GTX we get back a device number of 0 no matter what device we try to use. Any clues? --Blair "Don't ask me, I'm just the messenger..."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02295; 7 Mar 90 18:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01887; 7 Mar 90 18:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01662; 7 Mar 90 18:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04757; 7 Mar 90 17:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22985; Wed, 7 Mar 90 14:31:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 90 21:51:16 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Running an X Terminal off of a 210 Message-Id: References: <34750@ucbvax.BERKELEY.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am also interested in any informating regarding the combination of X terminals and Iris 4D's. Does anyone know if there exists terminals supporting both X and NeWS applications? (XNeWS terminals, perhaps?) If anyone has a summary of X terminals they could send me or post in this newsgroup, it would be greatly appreciated. George Elkins elkins@topaz.rutgers.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01172; 8 Mar 90 13:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00606; 8 Mar 90 12:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00481; 8 Mar 90 12:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06376; 7 Mar 90 20:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03277; Wed, 7 Mar 90 17:17:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Mar 90 01:04:59 GMT From: Tim Hall Organization: Boston University Computer Graphics Lab Subject: Mouse position/Mouse buttons/INPUTCHANGE and the event queue Message-Id: <53537@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In my previous experience; when holding down a mouse button and moving the mouse MOUSEX/MOUSEY events are generated even if the mouse goes outside the window. While the button is being held down no INPUTCHANGE events occur. Now, suddenly, while holding the RIGHTMOUSE button and moving the cursor out of the window causes an INPUTCHANGE event to occur. Also the MOUSEX/MOUSEY events stop occuring. When moving the cursor back into the window no INPUTCHANGE event occurs but the MOUSEX/MOUSEY events start up again. ARGH! I swear this wasn't the case on our machines a week ago and nothing that I can think of was changed that would cause this. I tried this on a 240 a 220 and a PI. All machines are running 3.2.1. Any ideas on what happened? -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01172; 8 Mar 90 13:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00606; 8 Mar 90 12:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00481; 8 Mar 90 12:30 EST Received: from umrvmb.umr.edu by SMOKE.BRL.MIL id aa08447; 7 Mar 90 23:30 EST Received: from blumiris.chem.umr.edu by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with TCP; Wed, 07 Mar 90 22:32:11 CST Received: by blumiris.chem.umr.edu (5.52/5.6) id AA19996; Wed, 7 Mar 90 22:32:05 CST Date: Wed, 7 Mar 90 22:32:05 CST From: "Robert B. Funchess" Posted-Date: Wed, 7 Mar 90 22:32:05 CST Message-Id: <9003080432.AA19996@blumiris.chem.umr.edu> To: info-iris@BRL.MIL Subject: X11R4 OK... emboldened by the success of recent posters in building the MIT X distribution, I tried it... but apparently I am doing something wrong. "make World" gets as far as "making in ./server..." before it dies with the msg sh: syntax error at line 3: ';' unexpected "make clean" gives exactly the same error message, at exactly the same place. What am I doing wrong? I can't find an unexpected ';', the command on which it occurs looks exactly like a previous one which works fine... -- < Bob | bobf@blumiris.chem.umr.edu | Funchess > "The large print giveth, and the small print taketh away." - T. Waits   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03307; 8 Mar 90 15:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02959; 8 Mar 90 15:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02950; 8 Mar 90 14:55 EST Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa24067; 8 Mar 90 14:19 EST Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA11342; Thu, 8 Mar 90 13:21:00 CST Date: Thu, 8 Mar 90 13:21:00 CST From: Mike Goss Message-Id: <9003081921.AA11342@snow-white.merit-tech.com> To: info-iris@BRL.MIL, swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!randy@ucsd.edu Subject: Re: 2 Perplexing Problems In reply to your questions: > Date: 7 Mar 90 15:16:47 GMT > From: Schrickel Randall > Organization: Johns Hopkins University > Subject: 2 Perplexing Problems > Message-Id: <4857@aplcen.apl.jhu.edu> > > I have 2 very strange problems with a single application we have > in house. I've talked to the Hot Line about the first, but haven't > had any luck with what they suggested. Any help will be GREATLY > appreciated (the Governor is coming in for a demo this weekend!) > > 1) The application gives random horizontal streaks of color across > the screen. Hot line says we are trying to use an invalid bit > plane (writemask) or color, but I have had no luck looking at > those areas. Any other pointers/things to look at? > > 2) The same application goes through periods of slowing down then > running at a normal speed. We have checked memory allocation, > thinking that it may be growing, swapping, shrinking, but that > looks like another dead end. It REALLY slows down; the animation > almost stops. Help! > ... I've seen (1) on a 2000 series machine happen when an entry in the colormap is set to blinking status (see man page for "blink"). Not only does the color blink like it should, but you get random streaks on the screen. I don't know of any way around this problem other than to avoid blinking colors (if you are not using blinking colors explicitly, try doing a gclear command before running your program; I think this will reset the whole color map). Problem (2) can happen if you send invalid numerical values to a gl call. It appears that the gl traps floating point errors and ignores them, causing extreme slowness (and usually strange results on the screen). Sometimes you may get an error message when this happens. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04649; 8 Mar 90 16:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04360; 8 Mar 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04347; 8 Mar 90 16:22 EST Received: from PIG.DREA.DND.CA by SMOKE.BRL.MIL id aa27227; 8 Mar 90 15:54 EST Received: Thu, 8 Mar 90 15:43:10 AST by pig.drea.dnd.ca (5.52/5.6) Date: Thu, 8 Mar 90 15:43:10 AST From: Jim Diamond Message-Id: <9003081943.AA07295@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: laser writer support We're thinking of buying an Apple LaserWriter NTX for either our 3130 or 4D/50. Our sales people tell us that we need a $1500 software option to run these. It wasn't clear from my queries whether or not someone was trying to sell me troff software, which we don't want. Rather, we want to be able to print postscript and ASCII files; Can anyone tell me if there is any reliable public domain (or even cheaper) software available to run such a printer with the spooling software (?!) which comes with a 3130 or 4D system? Further, does anyone know where I can obtain software which will allow us to spool files to a printer on our ethernet? Thanks. Jim Diamond zsd@pig.drea.dnd.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04812; 8 Mar 90 17:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04649; 8 Mar 90 16:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04396; 8 Mar 90 16:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27680; 8 Mar 90 16:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AB12144; Thu, 8 Mar 90 13:05:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Mar 90 19:48:44 GMT From: "Jeff P. M. Hultquist" Organization: NASA Ames Research Center, Moffett Field, CA Subject: popup menus on left-mouse Message-Id: <5141@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to create a popup menu which appears when the user pushes the LEFT mouse button. This code ... dev = qread(&val); if ((dev == LEFTMOUSE) && (val == 1) { item = dopup(menu); } ... brings the menu up just fine, but the system waits for the release of the right button. How can I tell the system to watch the left button? Thanks. Please send mail, I will summarize. -- Jeff Hultquist hultquis@nas.nasa.gov NASA - Ames Research Center (415) 609-4970 Disclaimer: "I am not a rocket scientist."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06570; 8 Mar 90 21:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06490; 8 Mar 90 21:14 EST Date: Thu, 8 Mar 90 20:54:43 EST From: "Lee A. Butler" To: info-iris@BRL.MIL Subject: Graphics library examples Message-ID: <9003082054.aa06458@VMB.BRL.MIL> This evening I sat down at the IRIS to start learning to use the graphics library. On page 1-5 of the "Graphics Library Programming Guide" is the program "red.c" which I typed in verbatim: #include main() { prefposition(100, 500, 200, 600); shademodel(FLAT); winopen("red"); color(RED); clear(); sleep(5); } then I compiled with the command line in the manual: % cc red.c -lgl -o red And tried to run the result: % red Segmentation fault (core dumped) % dbx red dbx version 1.31 1/22/90 2:02 Copyright 1987 Silicon Graphics Inc. Copyright 1987 MIPS Computer Systems Inc. Type 'help' for help. Reading symbolic information of `red' . . . Process name from core dump: red Process died at pc 0x400774 of signal : segmentation violation [using memory image in core] (dbx) where > 0 shademodel(0x64, 0x1f4, 0xc8, 0x258, 0x0, 0x400214) [0x400770] 1 main() ["red.c":7, 0x400260] (dbx) q I noticed that if you leave out the call to "shademodel" the program works as advertised. Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07121; 8 Mar 90 23:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06967; 8 Mar 90 23:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06954; 8 Mar 90 23:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02308; 8 Mar 90 22:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07251; Thu, 8 Mar 90 19:52:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 03:37:16 GMT From: Scott Gilmore Organization: University of Delaware Subject: Where can I get imake (PLEASE)? Message-Id: <5832@udccvax1.acs.udel.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We just got a Personal Iris and are trying to build some of the PD X11 stuff. However, we need imake, which (as you probably already know) is not included in the X11 stuff from SGI. (We supposedly _have_ the X11 development option.) I checked all of the major X11 archive sites and couldn't find imake. Could someone please help me out? I apologize if this has been discussed before; I just subscribed to this group today and skimmed the subject lines of the past 200+ postings with no luck. Of course, Email responsed preferred. Thanks in advance. --- Scott Gilmore gilmore@vax1.acs.udel.edu Mechanical Engineering and Center for Composite Materials, U. of Delaware   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09302; 9 Mar 90 6:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08913; 9 Mar 90 6:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08909; 9 Mar 90 6:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05537; 9 Mar 90 6:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02986; Fri, 9 Mar 90 03:07:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 05:08:26 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: Re: popup menus on left-mouse Message-Id: <483@meritaus.UUCP> References: <5141@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From article <5141@amelia.nas.nasa.gov>, by hultquis@wk43..nas.nasa.gov (Jeff P. M. Hultquist): > I would like to create a popup menu which appears > when the user pushes the LEFT mouse button. This > code ... > > > ... brings the menu up just fine, but the system > waits for the release of the right button. How > can I tell the system to watch the left button? > > Jeff Hultquist hultquis@nas.nasa.gov > NASA - Ames Research Center (415) 609-4970 > Disclaimer: "I am not a rocket scientist." I spent a little time researching this, and didn't come up with any good solutions. The problem is that the pop-up menu is based on the 4Sight (NeWS) menu class LitePullRightMenu, which is based on LiteMenu, etc. This menu substrate has low-level code that uses the binding of MenuButton for menu selection. By default, MenuButton is the right mouse button (look in /usr/NeWS/lib/NeWS/init.ps). So, as far as I can tell, you can probably rebind MenuButton to be the left button by changing this. However, looks like you'd impact all menus. Despite my best attempts (and limited time), I can't figure out if there is a Lite method that can be overriden to solve this. -- dan haug Merit Technology, Inc. ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10750; 9 Mar 90 8:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10402; 9 Mar 90 8:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10260; 9 Mar 90 8:20 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa07106; 9 Mar 90 7:52 EST Received: Fri, 9 Mar 90 07:45:03 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 9 Mar 90 07:45:03 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003091545.AA16568@aero4.larc.nasa.gov> To: sgi!markb%denali.sgi.com@ucbvax.berkeley.edu Subject: Re: Optical Drives for Iris' Cc: info-iris@BRL.MIL You said 1024 bytes/sector is not filesystem compatible----yet! How long until it is? How long until the ZCAV media is available? If Sony doesn't support this media, who else is making the MO drives. As far as I have seen Sony is the only one making them. Buying a drive from SGI at twice the cost everyone else sells it for doesn't sound appeling either. We are looking at buying a MO drive shortly after our 4D/210VGX arrives, which hopefully will only be a few months from now. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10750; 9 Mar 90 8:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10402; 9 Mar 90 8:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10311; 9 Mar 90 8:22 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa07461; 9 Mar 90 8:05 EST Received: Fri, 9 Mar 90 08:07:53 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 9 Mar 90 08:07:53 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9003091607.AA16621@aero4.larc.nasa.gov> To: zsd@pig.drea.dnd.ca Subject: Re: laser writer support Cc: info-iris@BRL.MIL Someone is trying to sell you something you probably don't need. I have run all sorts of printers off our 3130, using both the serial and parallel ports. I just read the manuals to set up hardwired serial printers and also on parallel printers. If you already have PostScript files from some some where you just use lp to send them to the printer. If you don't have PostScript files you will either have to write some kind of script to do what you want or get something like TeX or Transcript to get the Postscript files. I had a NEC 890 SilentWriter connected to both our parallel and serial ports just last week. (We have a Tektronix 4693D color copier and when we weren't using it I had the laser printer plugged into the parallel port and when we needed color copies, I used the serial port instead.) In /usr/spool/lp/etc/util there are some printer utilities one is mkcentpr. I used it to get things started and then when to /usr/spool/lp/interface and changed the interface script file to delete the SGI filter, so that files would be sent to the Centronix port unaltered. I had to some similar things for the serial port all of which are in the manual. Appendix C of the OS 3.5 manuals (manual says Version 2.0) or Section 7.9 of the OS 3.6 manuals (manual says Version 3.0). If you have the older manual, use it, the documentation is much better than the new manual. SGI eliminated a lot of useful information in the newer manual. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11993; 9 Mar 90 9:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11203; 9 Mar 90 9:20 EST Date: Fri, 9 Mar 90 9:04:16 EST From: Gary S. Moss (VLD/VMB) To: Lee A. Butler cc: info-iris@BRL.MIL Subject: Re: Graphics library examples Message-ID: <9003090904.aa11127@VMB.BRL.MIL> [Lee Butler writes:] < This evening I sat down at the IRIS to start learning to use the graphics < library. On page 1-5 of the "Graphics Library Programming Guide" is the < program "red.c" which I typed in verbatim: < ... < shademodel(FLAT); < winopen("red"); Lee, This has been brought up before, the documentation is wrong, shade- model() must be called *after* winopen(). I suggested that the GL should protect itself against this by returning failure from shademodel(), with a useful diagnostic, but apparently it tries to reference window structures through an uninitialized pointer. The last word that I heard from SGI was that they are considering providing a debuging version of the GL which does some checking so that they don't have to impact the performance of the graphics routines. You should be able to dig up this discussion a month or so ago in the archives.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13494; 9 Mar 90 10:44 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13150; 9 Mar 90 10:33 EST Received: from tbd.brl.mil by VMB.BRL.MIL id aa13107; 9 Mar 90 10:22 EST Date: Fri, 9 Mar 90 10:18:55 EST From: Glenn Randers-Pehrson (WMB) To: butler@BRL.MIL cc: info-iris@BRL.MIL Subject: Re: Graphics Library Examples Organization: U.S. Army Ballistic Research Laboratory, APG, MD Message-ID: <9003091018.aa19597@TBD.BRL.MIL> Lee, Regarding your problem with the tutorial example "red.c": You should have put shademodel(FLAT) AFTER your call to winopen. ...Glenn R-P   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17771; 9 Mar 90 14:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17215; 9 Mar 90 13:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16975; 9 Mar 90 13:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17112; 9 Mar 90 13:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26463; Fri, 9 Mar 90 10:09:24 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 15:47:03 GMT From: Thant Tessman Organization: Silicon Graphics, Entry Systems Division Subject: Re: Graphics library examples Message-Id: <5074@odin.SGI.COM> References: <9003082054.aa06458@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003082054.aa06458@VMB.BRL.MIL>, butler@BRL.MIL ("Lee A. Butler") writes: > This evening I sat down at the IRIS to start learning to use the graphics > library. On page 1-5 of the "Graphics Library Programming Guide" is the > program "red.c" which I typed in verbatim: > > #include > > main() > { > prefposition(100, 500, 200, 600); > shademodel(FLAT); > winopen("red"); > color(RED); > clear(); > sleep(5); > } > ... > > I noticed that if you leave out the call to "shademodel" the program works > as advertised. > > Lee A. Butler > SLCBR-VL-V Internet: butler@brl.mil > Ballistic Research Laboratory Phone: (301) 278-8740 > Aberdeen Proving Grounds, MD 21005-5066 There is an error in the program. The 'winopen' needs to happen befor the 'shademodel' command. I think (hope) the manual has been fixed by now. Some commands (like prefposition) are hints, and go before the winopen. All the rest need to happen after the graphics have been initialized. thant   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17969; 9 Mar 90 14:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17215; 9 Mar 90 13:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16982; 9 Mar 90 13:35 EST Received: from [192.48.153.1] by SMOKE.BRL.MIL id aa17174; 9 Mar 90 13:21 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/900301.SGI) for info-iris@brl.mil id AA25800; Fri, 9 Mar 90 10:23:02 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:zsd@pig.drea.dnd.ca id AA22347; Fri, 9 Mar 90 10:22:57 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA29122; Fri, 9 Mar 90 10:22:54 PST Message-Id: <9003091822.AA29122@forest.sgi.com> To: Jim Diamond Cc: info-iris@BRL.MIL Subject: Re: laser writer support In-Reply-To: Your message of Thu, 08 Mar 90 15:43:10 -0400. <9003081943.AA07295@pig.drea.dnd.ca> Date: Fri, 09 Mar 90 10:22:48 PST From: baskett%forest@sgi.com The software in question is Transcript. It is from Adobe. You don't adsolutely have to have it but it provides a lot of useful utilities. It does make life easier. It is grossly overpriced. That is not our fault this time. We make no profit on it. It is the sort of software that you would pay $49.95 for if it were for a Mac or a PC. Forest Baskett Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18706; 9 Mar 90 14:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18227; 9 Mar 90 14:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18224; 9 Mar 90 14:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18724; 9 Mar 90 14:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28609; Fri, 9 Mar 90 10:42:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 17:45:43 GMT From: psuvm!fqh@psuvax1.cs.psu.edu Organization: Penn State University Subject: Re: Graphics library examples Message-Id: <90068.124543FQH@psuvm.psu.edu> References: <9003082054.aa06458@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I found that out yesterday. Also, the program only works in FORTRAN if you likewise leave out the call to SHADEM(). Woody Hunsberger .   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19364; 9 Mar 90 15:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18868; 9 Mar 90 15:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18734; 9 Mar 90 14:55 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19683; 9 Mar 90 14:41 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01530; Fri, 9 Mar 90 11:25:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 19:12:30 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Optical Drives for Iris' Message-Id: <53114@sgi.sgi.com> References: <9003091545.AA16568@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003091545.AA16568@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > You said 1024 bytes/sector is not filesystem compatible----yet! > How long until it is? How long until the ZCAV media is available? > If Sony doesn't support this media, who else is making the MO drives. > As far as I have seen Sony is the only one making them. Buying a > drive from SGI at twice the cost everyone else sells it for doesn't > sound appeling either. Variable sector lengths is probably about a year away. Perhaps a bit more. ZCAV is available to me in limited quantity today, but don't know about more commercial availability time frames. MO mfrs. include Sony, Ricoh, Maxoptics, Hitachi, Kodak, and probably others that I am not familiar with. Not too sure about Kodak any more but they and Verbatim (as I recall) had something going a while ago. I can't change the price for you. That's not in my realm. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22793; 9 Mar 90 18:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22757; 9 Mar 90 18:28 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa22755; 9 Mar 90 18:17 EST Received: from umrvma.umr.edu by ADM.BRL.MIL id aa05174; 9 Mar 90 17:38 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 0657; Fri, 09 Mar 90 16:32:39 CST Received: by UMRVMA (Mailer R2.05) id 0084; Fri, 09 Mar 90 16:32:36 CST Date: Fri, 09 Mar 90 14:02:22 CST From: Bob Funchess Subject: Mailer problems To: info-iris@BRL.MIL Message-ID: <9003091738.aa05174@ADM.BRL.MIL> Our mailer was working just a few days ago but now it seems to be broken. Outgoing mail works fine but incoming mail seems to be getting bounced between our Iris and our forwarding host, as if the Iris thought it was someone else... The mail eventually gets rejected with "maximum number of hops exceeded". How can I tell our machine to keep mail for "user@blumiris.chem.umr.edu" instead of attempting to forward it somewhere else? Please respond directly via E-mail to THIS ADDRESS; the one on the Iris (that receives this mailing list) won't work for obvious reasons. :( < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Disclaimer: If the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23525; 9 Mar 90 20:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23235; 9 Mar 90 20:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23160; 9 Mar 90 20:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25488; 9 Mar 90 19:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09439; Fri, 9 Mar 90 16:47:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 23:29:25 GMT From: martin Organization: Silicon Graphics, Inc., Mountain View, CA Subject: plotting packages Message-Id: <5100@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a customer, Andrew Schwartz at St. Joseph's Hospital, who is looking for a third party interface from a gl application to a plotter. Andrew has applications that he would like to interactively send output to a plotter. If anybody has or knows of such a package please send email to Andrew at arabs@asuacad.bitnet Thanks. Martin McDonald SGI Life is unpredictable. Eat dessert first.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26030; 10 Mar 90 1:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25935; 10 Mar 90 1:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25896; 10 Mar 90 1:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27374; 10 Mar 90 0:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25429; Fri, 9 Mar 90 21:29:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 90 21:55:27 GMT From: Don Preuss Organization: National Institutes of Health Subject: Slide Makers for the 4D Message-Id: <1393@nih-csl.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am currently looking for a slide maker for my SGI systems. What is available? What would be optimal is something that I could split between various machines on scsi (SGI, Mac, PC). donp -- donp@niaid.nih.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09496; 12 Mar 90 7:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08988; 12 Mar 90 7:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08980; 12 Mar 90 6:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09408; 12 Mar 90 6:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04153; Mon, 12 Mar 90 03:25:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 09:14:25 GMT From: Scum Organization: Carnegie-Mellon University, CS/RI Subject: World Coord -> ScreenCoords Message-Id: <8387@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anybody out there tell me how to map 3d world coordinates to screen coordinates? I can seem to find anything in the documentation. Thanks, -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12041; 12 Mar 90 10:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09683; 12 Mar 90 8:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09662; 12 Mar 90 8:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10422; 12 Mar 90 8:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08497; Mon, 12 Mar 90 04:56:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 10:33:16 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Reading IRIS image files into an array of longs. Message-Id: <53228@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Ever wonder how to read an IRIS image file into an array of longs so you can lrectwriteit to the screen? Here's a short piece of code that should help you out . . . /* * rectimg - * Display a color or black and white image on the iris. Simple * version for demo use. This will only work on machines that support * RGB mode. * Paul Haeberli - 1988 * * To compile this: * * cc rectimg.c -o rectimg -limage -lgl_s */ #include "gl.h" #include "device.h" #include "gl/image.h" unsigned long *longimagedata(); IMAGE *image; int xsize, ysize, zsize; unsigned long *lptr; main(argc,argv) int argc; char **argv; { short val; if( argc<2 ) { printf("usage: rectimg inimage\n"); exit(1); } sizeofimage(argv[1],&xsize,&ysize); if( xsize > (XMAXSCREEN+1) || ysize > (YMAXSCREEN+1)) { printf("rectimg: input image is too big %d %d",xsize,ysize); exit(1); } prefsize(xsize,ysize); winopen("rectimg"); RGBmode(); gconfig(); lptr = (unsigned long *)longimagedata(argv[1]); drawit(); while(1) { if(qread(&val) == REDRAW) drawit(); } } drawit() { reshapeviewport(); lrectwrite(0,0,xsize-1,ysize-1,lptr); } /* * Image library support . . . * */ sizeofimage(name, xsize, ysize) char *name; int *xsize, *ysize; { IMAGE *image; image = iopen(name,"r"); if(!image) { fprintf(stderr,"sizeofimage: can't open image file %s\n",name); exit(1); } *xsize = image->xsize; *ysize = image->ysize; iclose(image); } unsigned long *longimagedata(name) char *name; { unsigned long *base, *lptr; short *rbuf, *gbuf, *bbuf, *abuf; IMAGE *image; int y; image = iopen(name,"r"); if(!image) { fprintf(stderr,"longimagedata: can't open image file %s\n",name); exit(1); } base = (unsigned long *)malloc(image->xsize*image->ysize*sizeof(unsigned long)); rbuf = (short *)malloc(image->xsize*sizeof(short)); gbuf = (short *)malloc(image->xsize*sizeof(short)); bbuf = (short *)malloc(image->xsize*sizeof(short)); abuf = (short *)malloc(image->xsize*sizeof(short)); if(!base || !rbuf || !gbuf || !bbuf) { fprintf(stderr,"longimagedata: can't malloc enough memory\n"); exit(1); } lptr = base; for(y=0; yysize; y++) { if(image->zsize>=4) { getrow(image,rbuf,y,0); getrow(image,gbuf,y,1); getrow(image,bbuf,y,2); getrow(image,abuf,y,3); rgbatocpack(rbuf,gbuf,bbuf,abuf,lptr,image->xsize); lptr += image->xsize; } else if(image->zsize==3) { getrow(image,rbuf,y,0); getrow(image,gbuf,y,1); getrow(image,bbuf,y,2); rgbtocpack(rbuf,gbuf,bbuf,lptr,image->xsize); lptr += image->xsize; } else { getrow(image,rbuf,y,0); bwtocpack(rbuf,lptr,image->xsize); lptr += image->xsize; } } iclose(image); free(rbuf); free(gbuf); free(bbuf); free(abuf); return base; } bwtocpack(b,l,n) register unsigned short *b; register unsigned long *l; register int n; { while(n>=8) { l[0] = 0x00010101*b[0]; l[1] = 0x00010101*b[1]; l[2] = 0x00010101*b[2]; l[3] = 0x00010101*b[3]; l[4] = 0x00010101*b[4]; l[5] = 0x00010101*b[5]; l[6] = 0x00010101*b[6]; l[7] = 0x00010101*b[7]; l += 8; b += 8; n -= 8; } while(n--) *l++ = 0x00010101*(*b++); } rgbtocpack(r,g,b,l,n) register unsigned short *r, *g, *b; register unsigned long *l; register int n; { while(n>=8) { l[0] = r[0] | (g[0]<<8) | (b[0]<<16); l[1] = r[1] | (g[1]<<8) | (b[1]<<16); l[2] = r[2] | (g[2]<<8) | (b[2]<<16); l[3] = r[3] | (g[3]<<8) | (b[3]<<16); l[4] = r[4] | (g[4]<<8) | (b[4]<<16); l[5] = r[5] | (g[5]<<8) | (b[5]<<16); l[6] = r[6] | (g[6]<<8) | (b[6]<<16); l[7] = r[7] | (g[7]<<8) | (b[7]<<16); l += 8; r += 8; g += 8; b += 8; n -= 8; } while(n--) *l++ = *r++ | ((*g++)<<8) | ((*b++)<<16); } rgbatocpack(r,g,b,a,l,n) register unsigned short *r, *g, *b, *a; register unsigned long *l; register int n; { while(n>=8) { l[0] = r[0] | (g[0]<<8) | (b[0]<<16) | (a[0]<<24); l[1] = r[1] | (g[1]<<8) | (b[1]<<16) | (a[1]<<24); l[2] = r[2] | (g[2]<<8) | (b[2]<<16) | (a[2]<<24); l[3] = r[3] | (g[3]<<8) | (b[3]<<16) | (a[3]<<24); l[4] = r[4] | (g[4]<<8) | (b[4]<<16) | (a[4]<<24); l[5] = r[5] | (g[5]<<8) | (b[5]<<16) | (a[5]<<24); l[6] = r[6] | (g[6]<<8) | (b[6]<<16) | (a[6]<<24); l[7] = r[7] | (g[7]<<8) | (b[7]<<16) | (a[7]<<24); l += 8; r += 8; g += 8; b += 8; a += 8; n -= 8; } while(n--) *l++ = *r++ | ((*g++)<<8) | ((*b++)<<16) | ((*a++)<<24); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14619; 12 Mar 90 12:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14354; 12 Mar 90 12:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14295; 12 Mar 90 11:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16542; 12 Mar 90 11:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19105; Mon, 12 Mar 90 08:11:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 15:30:23 GMT From: Tom Haapanen Organization: WATMIMS Research Group, University of Waterloo Subject: Setting the access/modify time on a file Message-Id: <1413@watserv1.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I wish to update a file (with an advisory lock), and then to close it, setting the access and modify times to (almost) the same time. Here is what I'm attempting: FILE *fp; long times; fp = fopen("filename", "w"); flock(fileno(fp), LOCK_EX); ... much i/o to the file ... fflush(fp); times[1] = time(×[0]) - (long)2; utime(mailfile, times); flock(fileno(fp), LOCK_UN); fclose(fp); Now, at what point does the modify time get set? the utime() call appears to set the access time, but the modify time appears to be set AGAIN after the access time. Where SHOULD it get set? And what should I do to make sure that my access time > modify time? The OS is IRIX 3.2 -- aka System V.3. Thanks for any and all replies! [ \tom haapanen -- university of waterloo -- tom@mims-iris.waterloo.edu ] [ "i say what i say, but i say it for myself and myself only" -- me ] [ "i don't even know what street canada is on" -- al capone ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04209; 12 Mar 90 18:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03922; 12 Mar 90 18:23 EST Date: Mon, 12 Mar 90 17:57:45 EST From: "Lee A. Butler" To: info-iris@BRL.MIL Subject: Thanks and another question/problem Message-ID: <9003121757.aa03216@VMB.BRL.MIL> First off I would like to thank everyone (especially those at SGI) who offered help/explanations/appologies to my message on the problems with the program examples in the manuals. Now I have some new questions and a few nits to pick. Appologies to all if these have been discussed before. If I've missed a manual page somewhere, please let me know. 1) /dev/console (seems to be mode "20622" (also "crw--w--w-") as delivered. Might this pose some (minor?) security problems? chmod'ing it to '20600' seems to "stick". Other tty's seem to have similar conditions. Is this really the way a system should be configured? 2) The ownership of /dev/console seems to shift in bizzare ways. Sometimes when I log in (on the console) it is owned by me and sometimes by some other user or "root". 3) Perhaps related to the previous two items, it is possible for another user to open a window on the graphics display while I am using the window manager on the console. This becomes nasty when the program that other user runs is something like a "screen lock" program! Is there something that applications could check to reliably determine whether or not they should access the console? Better still, is there any way of enforcing console access to the user running 4sight/window-manager? 4) It would appear that there may be a minor problem with the keyboard or the keyboard handling routines on the Personal Iris. I was writing an application for the Iris and using "qread" to process keyboard (as well as other) input. One of my robustness tests was to rake my hands accross the keyboard in an attempt to overflow input buffers or find faults in the input handling. What I found was that keys would somehow become re-mapped. A bit of study leads me to believe that I was getting something akin to "alt-lock" and/or "control-lock." I speculate that whatever is processing the keystrokes was getting a "control-key-pressed" event, but missing the "control-key-released" event. Since it never got another "released" event without first, getting a "pressed" event, that key would never become fully "released". It is interesting to note that I was unable to duplicate the problem on a 4D/240. Comments? Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05458; 12 Mar 90 21:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05326; 12 Mar 90 21:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05298; 12 Mar 90 20:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27745; 12 Mar 90 18:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27752; Mon, 12 Mar 90 10:26:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 17:17:02 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: World Coord -> ScreenCoords Message-Id: <53238@sgi.sgi.com> References: <8387@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8387@pt.cs.cmu.edu>, cycy@isl1.ri.cmu.edu (Scum) writes: > Can anybody out there tell me how to map 3d world coordinates to screen > coordinates? I can seem to find anything in the documentation. > Thanks, > -- Chris. There are 2 things to remember when trying to do this: 1) viewports on the IRIS go from the left edge of the left most pixel to the right edge of the right most pixel same for top and bottom, thus viewport(0,1,0,1) is exactly 2 pixels by 2 pixels. 2) the screen coordinate of a pixel center is at an integer To map 3-D world coordinates [100,200] to a 100 x 100 viewport you would use the following ortho2 call: ortho2(100-.5, 200+.5, 100-.5, 200+.5); The reason for the +- 0.5 is to account for the left and right edges of the pixels (see (1) above). Also check the screenspace() call which does world coords to absolute screen coordinates (without regard for your window location or origin). -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05752; 12 Mar 90 22:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05598; 12 Mar 90 21:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05593; 12 Mar 90 21:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29169; 12 Mar 90 20:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22974; Mon, 12 Mar 90 16:55:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 23:52:39 GMT From: Gretchen Helms Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: World Coord -> ScreenCoords Message-Id: <5166@odin.SGI.COM> References: <8387@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL cycy@isl1.ri.cmu.edu (Scum) writes: >Can anybody out there tell me how to map 3d world coordinates to screen >coordinates? I can seem to find anything in the documentation. > Thanks, > -- Chris. I am currently in the final stages of debugging a program that will do exactly that, if you are using the perspective and polarview calls. There is another method if you are using other calls. Which calls are you using for viewing and projection? G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05962; 12 Mar 90 22:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05874; 12 Mar 90 22:36 EST Date: Mon, 12 Mar 90 22:17:01 EST From: Chuck Kennedy To: info-iris@BRL.MIL Subject: info-iris archives updated Message-ID: <9003122217.aa05800@VMB.BRL.MIL> The archives have recently been updated and include info-iris mail traffic as summarized below. The new digests are V07 through V21. Many apologies for the long delay in getting caught up with the traffic. As usual, these are available on host vgr.brl.mil (192.5.23.6) via anonymous ftp. My congratulations to the whole SGI community. Looking back over the discussions, I'm very impressed with the quality. The participation of SGI has also enhanced this forum. It's great to see folks like Forest Baskett, Jim Barton, Mark Bradley and many others jump in and answer questions. I look forward to many more discussions, hopefully of the same high quality that we've seen. One reminder, please send requests for additions or deletions to info-iris-request@brl.mil and not to the whole mailing list. Likewise, any requests or mail problems should be sent to the -request address. Best regards, -Chuck Kennedy Name Size (bytes) Subject ---- ------------ ------- info-iris.txt.01 488129 Info-Iris V01, 10 Jul 86 - 20 Sep 87 info-iris.txt.02 353723 Info-Iris V02, 25 Sep 87 - 15 Apr 88 info-iris.txt.03 356805 Info-Iris V03, 18 Apr 88 - 17 Aug 88 info-iris.txt.04 271888 Info-Iris V04, Panel Library, 18 Aug 88 info-iris.txt.05 423583 Info-Iris V05, 18 Aug 88 - 30 Dec 88 info-iris.txt.06 245064 Info-Iris V06, Virus Special Issue info-iris.txt.07 351730 Info-Iris V07, 01 Jan 89 - 28 Feb 89 info-iris.txt.08 365585 Info-Iris V08, 01 Mar 89 - 11 Apr 89 info-iris.txt.09 414828 Info-Iris V09, 12 Apr 89 - 04 May 89 info-iris.txt.10 342356 Info-Iris V10, 05 May 89 - 24 May 89 info-iris.txt.11 384734 Info-Iris V11, 25 May 89 - 31 May 89 info-iris.txt.12 317956 Info-Iris V12, 01 Jun 89 - 11 Jul 89 info-iris.txt.13 391780 Info-Iris V13, 12 Jul 89 - 03 Aug 89 info-iris.txt.14 397345 Info-Iris V14, 04 Aug 89 - 01 Sep 89 info-iris.txt.15 411221 Info-Iris V15, 02 Sep 89 - 28 Sep 89 info-iris.txt.16 396486 Info-Iris V16, 29 Sep 89 - 01 Nov 89 info-iris.txt.17 372350 Info-Iris V17, 02 Nov 89 - 21 Nov 89 info-iris.txt.18 395460 Info-Iris V18, 22 Nov 89 - 20 Dec 89 info-iris.txt.19 423473 Info-Iris V19, 21 Dec 89 - 21 Jan 90 info-iris.txt.20 398406 Info-Iris V20, 22 Jan 90 - 07 Feb 90 info-iris.txt.21 407751 Info-Iris V21, 08 Feb 90 - 26 Feb 90   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06864; 13 Mar 90 0:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06405; 13 Mar 90 0:21 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa06382; 12 Mar 90 23:58 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa14306; 12 Mar 90 23:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23646; Mon, 12 Mar 90 17:06:02 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 00:21:15 GMT From: "James P. Loan" Organization: Computer Science Department, Stanford University Subject: Sales help needed Message-Id: <1990Mar13.002115.2013@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Note: this is not a flame but rather an appeal for help I'm trying to get some info from SGI about X, Motif, and GSA contracts. Our sales rep is unreliable because he seems too busy to return my calls. This is NOT necessarily a criticism of him; he's probably a busy guy working a lot of contracts and after all, we're only ordering one PI. Maybe I'm just too impatient to wait the 1-2 weeks it takes him to call. Some of my questions concern the inner workings of X, so maybe he's not even the guy to ask. Anyway, is there anyone at SGI who has time to answer some questions? thanks, pete loan loan@neon.stanford.edu VA Medical Center 415.493.5000 x4474   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07144; 13 Mar 90 1:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07014; 13 Mar 90 1:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07008; 13 Mar 90 1:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00694; 12 Mar 90 23:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22974; Mon, 12 Mar 90 16:55:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 90 23:52:39 GMT From: Gretchen Helms Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: World Coord -> ScreenCoords Message-Id: <5166@odin.SGI.COM> References: <8387@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL cycy@isl1.ri.cmu.edu (Scum) writes: >Can anybody out there tell me how to map 3d world coordinates to screen >coordinates? I can seem to find anything in the documentation. > Thanks, > -- Chris. I am currently in the final stages of debugging a program that will do exactly that, if you are using the perspective and polarview calls. There is another method if you are using other calls. Which calls are you using for viewing and projection? G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07761; 13 Mar 90 4:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07700; 13 Mar 90 4:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab07683; 13 Mar 90 3:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02262; 13 Mar 90 3:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21052; Tue, 13 Mar 90 00:23:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 05:45:00 GMT From: CAEN Netnews Organization: U of M Engineering, Ann Arbor, Mich. Subject: Reference to interpolation using NURBS Message-Id: <4929ba11.a590@news.engin.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am looking for references on how to interpolate data in the form of z=f(x,y) using NURBS. Specifically, how can I represent an image of data- where pixels are the z's using NURBS, using the SGI-Iris hardware. Thanks in advance, Sarvajit sinha@caen.engin.umich.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08223; 13 Mar 90 6:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08007; 13 Mar 90 6:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08003; 13 Mar 90 5:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02794; 13 Mar 90 5:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26374; Tue, 13 Mar 90 02:01:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 05:56:48 GMT From: David Beecher Organization: Plus Five Computer Services, St. Louis Subject: Device Driver Source for SGI Power Series (R/3000) Message-Id: <3780@plus5.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is a plea for anyone out there who has source for a device driver that runs on the Silicon Graphics POWER series. I have a 240 system and am in the process of bringing up a commercially available disk farm (Maximum Strategy). I have had some success in talking to the device via memory mapping the register set ...but its a long way between that and a full blown device driver that supports DMA. My farm is a fairly simple device which has the capability of being a VME master. I'm sure that anything close would be extremely useful. As you all know its easier to modify something that exists (and works), than it is to start from the great void. I do have a copy of the new (and first) device driver manual from SGI. Unfortunately, it contains no complete examples. I would be VERY appreciative to any and all responses. Reasonable associated costs involved are no problem, and you would be welcome to have and hold the finished product. You can email to this address or to beech@pet835.wustl.edu. Or feel free to give me a call: Dave Beecher Research Associate Division of Radiation Sciences 510 South Kingshighway St. Louis, Missouri 63144 (314)362-8459 or (314)362-7117 You can leave a message at either location. Thanks in advance.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08319; 13 Mar 90 6:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08223; 13 Mar 90 6:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08215; 13 Mar 90 6:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03111; 13 Mar 90 6:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29751; Tue, 13 Mar 90 03:07:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 10:47:15 GMT From: Steve Lamont Organization: Foo Bar Brewers Cooperative Subject: Re: Sales help needed Message-Id: <1756@speedy.mcnc.org> References: <1990Mar13.002115.2013@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar13.002115.2013@Neon.Stanford.EDU> loan@Neon.Stanford.EDU (James P. Loan) writes: > >Our sales rep is unreliable because he seems too busy to return my calls. You think that's bad? My sales rep suggested that SGI could "play hard ball" with us because we bought third party memory (at a fraction of the cost of what SGI charged). Frankly, I'm getting a little tired for the arrogance of some SGI sales types. I hope that Stardent gets its act together soon, so that there will be some competition in the high end workstation market. Sigh. spl (the p stands for peeved) -- Steve Lamont, sciViGuy (919) 248-1120 EMail: spl@ncsc.org NCSC, Box 12732, Research Triangle Park, NC 27709 "...though you may have the falcon yet we certainly have you." Dashiell Hammett, _The Maltese Falcon_   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17936; 13 Mar 90 16:44 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17498; 13 Mar 90 16:23 EST Date: Tue, 13 Mar 90 16:06:24 EST From: Paul Stay To: info-iris@BRL.MIL Subject: maintenance updates Message-ID: <9003131606.aa17313@VMB.BRL.MIL> FYI We have been installing maintenance updates on many of our +60 SGI 4D systems and have found that the date/time is reported as 1989 instead of 1990. This can cause problems in the installation of your software especially when it tries to do the auto config since /unix "more recent" than the fixes which you have just installed. We are doing the installation over the network and so it may be related to grabbing the software from disk instead of /dev/tape. The quick fix is to "sh" and set the date right when you boot up the miniroot/installation program. Without setting the date right there may be problems with access to the network and associated programs (i.e. named), graphics (NeWS). Has anyone else tripped over this? -Paul Stay stay@brl.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18259; 13 Mar 90 17:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17498; 13 Mar 90 16:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17376; 13 Mar 90 16:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19099; 13 Mar 90 15:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02886; Tue, 13 Mar 90 12:19:15 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 16:49:33 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re-iterating/clarrifying SGI Support protocols Message-Id: <5187@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is to re-iterate a standing Support Engineering (aka Hotline) policy that we are experiencing a *little* slippage on and therefore need to make sure everyone--at least who reads comp.sys.sgi--is working with the same set of guidelines/procedural understandings: Admittedly, those encountering problems with X are enduring various levels of difficulty. We have found that in recent months, a certain kind of "end-run" situation has been developing wherein certain customers/users are up against the wall, and in various capacities are communicating directly with people in Software Engineering at SGI WITHOUT the problem/potential-bug/difficulty being matched/logged thru a currently opened call to the Hotline. As frustrated and fed-up as some people are with getting help/quick access from/to a Support Engineer on the Hotline, IT IS IMPERATIVE THAT ALL PROBLEMS HAVE A CALLOG ASSOCIATED WITH THEM SO THAT THEY MAY BE ACCURATELY AND EFFICIENTLY TRACKED. Without absolute adherence to this fundamentally basic tenet, our system of responding to the needs of our customer base will inevitably fail. This is because the only way to ensure that a given problem is known about and is being properly studied/tracked/monitored is for a callog's call-ID to match up on a one-to-one basis with each and every problem. Without this one-to-one matching, miscommunications and incorrect working assumptions shared between Support and Software Engineering, will inevitably create replicating situations where specific problems start falling through the cracks. Hence, to re-state, please be sure that at any point you may be communicating with SGI on whatever level or basis regarding a specific problem--difficulties with X have increased this non-logged call scenario--that there ALREADY EXISTS a call logged through the Hotline so all of us here at SGI, regardless of which division we're in, can be dealing with this problem with the same parameters and tracking mechanisms clearly and unambiguously in place. Support Engineering does its best to solve a given problem in as timely a fashion as is possible. Frequently if the call is beyond our knowledge base, we will setup a conference call which will include a Software Engineer, and take notes on the ensuing solution for future reference. If, in such a case, the Software Engineer offers to call the customer back, it should in NO WAY be construed from this that the Software Engineer is now devoting herself to the problem and will be responsible for pursuing the customer with callbacks. That is what Support Engineering does. We will continue to call back both the customer and Software Engineer until the problem is solved, but it is not the Software Engineer's duty to interface in that manner with customers. If further developments occur, the customer should call the Hotline back rather than the Software Engineer so we can log those problems as well. The Hotline will never give out the phone numbers for the Software Engineers even if politely asked. We also discourage customers from calling SGI and obtaining direct lines for Hotline people. We are aware that during peak times you may not get an immediate response, but in order for us to track your calls, it is imperative that you only use the Hotline number. If you are given a Software Engineer's phone number by the engineer herself, we ask you to please treat it with respect and only use it for the duration of that call if you must use it at all. Your adherence to these essential rules regarding our problem-solving procedures is greatly appreciated. dave ratcliffe, product support system engineer   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18756; 13 Mar 90 20:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18724; 13 Mar 90 19:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18704; 13 Mar 90 19:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22782; 13 Mar 90 19:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17007; Tue, 13 Mar 90 15:49:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 13:51:39 GMT From: Urs Meyer Organization: University of Zurich, Department of Computer Science Subject: C++ 2.0 availability? Message-Id: <1990Mar13.135139.2351@ifi.unizh.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We ordered the C++ tape from our local SGI branch and received version 1.2.1, which is not suitable for our needs. Is 2.0 already available? If not, when will it be available? --- Urs Meyer ---------- meyer@ifi.unizh.ch, {uunet,...}!mcsun!cernvax!unizh!meyer University of Zurich, Dept of Computer Science, Multimedia Lab, CH-8057 Zurich   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18935; 13 Mar 90 20:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18909; 13 Mar 90 20:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18899; 13 Mar 90 20:18 EST Received: from [192.12.31.1] by SMOKE.BRL.MIL id aa22930; 13 Mar 90 19:26 EST Date: Tue, 13 Mar 90 18:56:23 EST From: "Prof. David F. Rogers" To: info-iris@BRL.MIL Subject: Hot Line Message-ID: <9003131856.aa03408@CAD.USNA.MIL> For Dave Ratcliffe: Although I can certainly appreciate your problems with end runs and absorbtion of Software Engineering's time, you should appreciate your customers problems. The basic problem is that the Hot Line is nearly useless for someone on the East Coast. The scenerio goes something like this: A problem develops in the early to mid morning. We spend the rest of the morning and the early afternoon confirming that it is an SGI problem and not our problem. That's only fair and responsible action on our part. Right, it is now SGI's problem for whatever reason. Call the Hot Line. No one available for an immediate answer. Get a number with promise to call back. It is now 1530 EST or so. No way do we get a call back that day. When we come in in the morning it is 0500 on the West Coast! No realistic support can be expected until noonish, but that is lunch time so it will be 1300-1400 local time before we get ANY response -- 24 hours!!!! This is sure not a HOT LINE more like a COLD LINE. There is usually 2-3 days of this before the problem gets defined, much less resolved. We can't afford that and neither can commercial customers. Hence end runs. Note I am not one of the end runners. I have long recommended and still recommend an electronic mail Hot Line. This solves the time zone problem and significantly increases the interaction for those of us who have email access. Why is SGI so reluctant to develop an email Hot Line? Dave Rogers Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA Tel: 301-267-3283/4/5 ARPANET: dfr@usna.navy.mil UUCP: ~uunet!usna!dfr   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18976; 13 Mar 90 20:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18935; 13 Mar 90 20:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18929; 13 Mar 90 20:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23324; 13 Mar 90 20:10 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21332; Tue, 13 Mar 90 16:56:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 00:31:50 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Lighting made easy!! Message-Id: <53450@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Using lmdef and lmbind is kind of tricky. Here's a piece of C code that makes it easy to use the GL to create lighted images. paul h paul@sgi.com /* * glshade - * Simple support for describing materials and light sources * This makes it easy for people without PHD's in GL to actually * shade surfaces. * * Paul Haeberli - 1990 * * * exports: * matrixinit(); * shadeinit(); * shadeon(); * shadeoff(); * setdiffuse(r,g,b); * setspecular(r,g,b); * setshininess(s); * * * Here is the structure of a typical program: * * main() * { * winopen("shade"); * RGBmode(); * doublebuffer(); * gconfig(); * winopen("blat"); * matrixinit(); you must use two matrix model * . * . * perspective( . . . . ); * shadeinit(); init shading after perspective * . * . * while(1) * cpack(0x00404060); clear the screen * clear(); * zclear(); * . * . * shadeon(); turn lighting on * setdiffuse(1.0,0.0,0.0); make the diffuse color red * drawobjwithnormals(); draw the object * shadeoff(); turn lighting off * . * . * swapbuffers(); swap buffers * } * } */ #include "stdio.h" #include "gl.h" static int matrixinited; static float idmat[4][4] = { 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0 }; matrixinit() { mmode(MVIEWING); loadmatrix(idmat); matrixinited = 1; } shadeinit() { initmaterial(); initlights(); shadeoff(); } shadeon() { lmbind(LMODEL,1); } shadeoff() { lmbind(LMODEL,0); } setdiffuse(r,g,b) float r, g, b; { float c[3]; lmcolor(LMC_DIFFUSE); c[0] = r; c[1] = g; c[2] = b; c3f(c); lmcolor(LMC_COLOR); } setspecular(r,g,b) float r, g, b; { float c[3]; lmcolor(LMC_SPECULAR); c[0] = r; c[1] = g; c[2] = b; c3f(c); lmcolor(LMC_COLOR); } setshininess(s) float s; { float mat_desc[2]; mat_desc[0] = SHININESS; mat_desc[1] = s; lmdef(DEFMATERIAL, 1, 2, mat_desc); } static initmaterial() { float mat_desc[18]; mat_desc[0] = EMISSION; mat_desc[1] = 0.0; mat_desc[2] = 0.0; mat_desc[3] = 0.0; mat_desc[4] = AMBIENT; mat_desc[5] = 0.0; mat_desc[6] = 0.0; mat_desc[7] = 0.0; mat_desc[8] = DIFFUSE; mat_desc[9] = 0.7; mat_desc[10] = 0.7; mat_desc[11] = 0.7; mat_desc[12] = SPECULAR; mat_desc[13] = 0.9; mat_desc[14] = 0.9; mat_desc[15] = 0.9; mat_desc[16] = SHININESS; mat_desc[17] = 40.0; lmdef(DEFMATERIAL, 1, 18, mat_desc); lmbind(MATERIAL, 1); } static initlights() { float li_desc[10]; li_desc[0] = AMBIENT; li_desc[1] = 0.10; li_desc[2] = 0.10; li_desc[3] = 0.10; li_desc[4] = LOCALVIEWER; li_desc[5] = 0.0; li_desc[6] = ATTENUATION; li_desc[7] = 1.0; li_desc[8] = 0.0; li_desc[9] = LMNULL; lmdef(DEFLMODEL, 1, 0, li_desc); lmbind(LMODEL, 1); makelight(0,0.0,0.0,10.0); makelight(1,-5.0,5.0,10.0); makelight(2, 5.0,5.0,10.0); } static makelight(i,x,y,z) int i; float x, y, z; { float li_desc[14]; li_desc[0] = AMBIENT; li_desc[1] = 0.1; li_desc[2] = 0.1; li_desc[3] = 0.1; li_desc[4] = LCOLOR; li_desc[5] = 0.5; li_desc[6] = 0.5; li_desc[7] = 0.5; li_desc[8] = POSITION; li_desc[9] = x; li_desc[10] = y; li_desc[11] = z; li_desc[12] = 0.0; /* zero means infinte light */ li_desc[13] = LMNULL; lmdef(DEFLIGHT, i+1, 14, li_desc); lmbind(LIGHT0+i, i+1); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19048; 13 Mar 90 21:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18724; 13 Mar 90 19:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18701; 13 Mar 90 19:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22349; 13 Mar 90 18:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13366; Tue, 13 Mar 90 14:52:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 22:47:48 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: facilities in syslog Message-Id: <53884@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm trying to break up syslog messages into separate files on our Iris 4D's (running 3.2.1) - a script will then run from cron and look for bad things in them. The man page for syslog, syslogd and /usr/include/bsd/syslog.h all mention the facility "daemon", but syslogd doesn't seem to know about it: # /usr/etc/syslogd -d ... cfline(daemon.warning /usr/spool/log/daemon) syslogd: unknown facility name "daemon" ... -e ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19763; 13 Mar 90 22:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19483; 13 Mar 90 22:15 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa19420; 13 Mar 90 22:06 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa10316; 13 Mar 90 21:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27938; Tue, 13 Mar 90 18:44:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 02:35:53 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: named problems Message-Id: <53902@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm trying to run a secondary name server on an Iris 4D running 3.2.1 My /usr/etc/resolv.conf looks like this: domain bu.edu nameserver 127.0.0.1 nameserver 128.197.2.6 nameserver 128.197.21.21 and /usr/etc/named.d/named.boot: cache . /usr/etc/named.d/named.ca secondary BU.EDU 128.197.2.6 128.197.21.21 When I fire up named, nslookup seems to work fine. I have sendmail 5.61 running and it finds MX records with no problem. The problems start on the console - I can't open any windows, they fail with "grcond[2736]: CIO: getsocketpeername: Can't find name for 127.0.0.1 -- connection refused" Also, when booting it rejects all nfs mounts with "host unknown". The host it tries to mount IS in /etc/hosts (and in the nameserver) (I have not tried putting 127.0.0.1 in the nameserver or trying hostnames in uppercase) -e ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19797; 13 Mar 90 23:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19688; 13 Mar 90 22:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19505; 13 Mar 90 22:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22900; 13 Mar 90 19:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18385; Tue, 13 Mar 90 16:11:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 90 10:09:57 GMT From: Bruno Pape Organization: Silicon Graphics S.A., Zuerich, Switzerland Subject: Hitachi VY-5000 parallel driver? Message-Id: <1990Mar13.100957.1468@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know if there is a Personal IRIS Centronics interface driver for the Hitachi VY-5000 available? Thanks in advance. Bruno Pape   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20288; 14 Mar 90 0:21 EST Received: by VMB.BRL.MIL id aa20238; 14 Mar 90 0:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19988; 14 Mar 90 0:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19986; 13 Mar 90 23:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24719; 13 Mar 90 23:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03988; Tue, 13 Mar 90 20:25:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 04:20:51 GMT From: John Buchanan Organization: Imager, UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: Lighting made easy!! Message-Id: <7174@ubc-cs.UUCP> References: <53450@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <53450@sgi.sgi.com> paul@manray.sgi.com (Paul Haeberli) writes: >#include "stdio.h" >#include "gl.h" I will probably get nailed to the wall for this, but shouldn't this be: #include #include Since we really do not want cpp to look for these files in the current directory. ========================================================================= | |===============================| | John Buchanan (juancho) | buchanan@cs.ubc.ca | | Imager Manager |===============================| | Imager | (604) 228-2218 | | Department of Computer Science |===============================| | University of British Columbia | Standard disclaimer | | Vancouver, BC, Canada | included in this | | | box, right here. | =========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20451; 14 Mar 90 1:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20391; 14 Mar 90 1:04 EST Date: Wed, 14 Mar 90 0:44:00 EST From: "Lee A. Butler" To: Eric A. Pearce cc: info-iris@BRL.MIL Subject: Re: named problems Message-ID: <9003140044.aa20373@VMB.BRL.MIL> On the surface it looks like your nameserver isn't serving the domain 0.0.127.IN-ADDR.ARPA This is usually accomplished on the local host by adding the following line to your named.boot file: primary 0.0.127.IN-ADDR.ARPA named.local where the file named.local looks something like: @ IN SOA Server.bu.edu. named.bu.edu. ( 880912 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 7200 ) ; Minimum IN NS server.bu.edu. 1 IN PTR localhost. You can check all of this by running nslookup and listing the domain "0.0.127.IN-ADDR.ARPA" Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20838; 14 Mar 90 3:46 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20780; 14 Mar 90 3:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20763; 14 Mar 90 3:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25958; 14 Mar 90 2:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14266; Tue, 13 Mar 90 23:19:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 05:52:32 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: CORRECTED Lighting make easy!!! Message-Id: <53498@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Herb kuta here at SGI noticed a bug in my use of lmdef. A fixed version follows . . . sorry . . paul h paul@sgi.com /* * glshade - * Simple support for describing materials and light sources * This makes it easy for people without PHD's in GL to actually * shade surfaces CORRECTLY. * * Paul Haeberli - 1990 * * * exports: * matrixinit(); * shadeinit(); * shadeon(); * shadeoff(); * setdiffuse(r,g,b); * setspecular(r,g,b); * setshininess(s); * * * Here is the structure of a typical program: * * main() * { * winopen("shade"); * RGBmode(); * doublebuffer(); * gconfig(); * winopen("blat"); * matrixinit(); you must use two matrix model * . * . * perspective( . . . . ); * shadeinit(); init shading after perspective * . * . * while(1) * cpack(0x00404060); clear the screen * clear(); * zclear(); * . * . * shadeon(); turn lighting on * setdiffuse(1.0,0.0,0.0); make the diffuse color red * drawobjwithnormals(); draw the object * shadeoff(); turn lighting off * . * . * swapbuffers(); swap buffers * } * } */ #include "stdio.h" #include "gl.h" static float idmat[4][4] = { 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0 }; matrixinit() { mmode(MVIEWING); loadmatrix(idmat); } shadeinit() { initmaterial(); initlights(); shadeoff(); } shadeon() { lmbind(LMODEL,1); } shadeoff() { lmbind(LMODEL,0); } setdiffuse(r,g,b) float r, g, b; { float c[3]; lmcolor(LMC_DIFFUSE); c[0] = r; c[1] = g; c[2] = b; c3f(c); lmcolor(LMC_COLOR); } setspecular(r,g,b) float r, g, b; { float c[3]; lmcolor(LMC_SPECULAR); c[0] = r; c[1] = g; c[2] = b; c3f(c); lmcolor(LMC_COLOR); } setshininess(s) float s; { float mat_desc[3]; mat_desc[0] = SHININESS; mat_desc[1] = s; mat_desc[2] = LMNULL; lmdef(DEFMATERIAL,1,3,mat_desc); } static initmaterial() { float mat_desc[19]; mat_desc[0] = EMISSION; mat_desc[1] = 0.0; mat_desc[2] = 0.0; mat_desc[3] = 0.0; mat_desc[4] = AMBIENT; mat_desc[5] = 0.0; mat_desc[6] = 0.0; mat_desc[7] = 0.0; mat_desc[8] = DIFFUSE; mat_desc[9] = 0.7; mat_desc[10] = 0.7; mat_desc[11] = 0.7; mat_desc[12] = SPECULAR; mat_desc[13] = 0.9; mat_desc[14] = 0.9; mat_desc[15] = 0.9; mat_desc[16] = SHININESS; mat_desc[17] = 40.0; mat_desc[18] = LMNULL; lmdef(DEFMATERIAL,1,19,mat_desc); lmbind(MATERIAL,1); } static initlights() { float li_desc[10]; li_desc[0] = AMBIENT; li_desc[1] = 0.10; li_desc[2] = 0.10; li_desc[3] = 0.10; li_desc[4] = LOCALVIEWER; li_desc[5] = 0.0; li_desc[6] = ATTENUATION; li_desc[7] = 1.0; li_desc[8] = 0.0; li_desc[9] = LMNULL; lmdef(DEFLMODEL,1,10,li_desc); lmbind(LMODEL,1); makelight(0,0.0,0.0,10.0); makelight(1,-5.0,5.0,10.0); makelight(2, 5.0,5.0,10.0); } static makelight(i,x,y,z) int i; float x, y, z; { float li_desc[14]; li_desc[0] = AMBIENT; li_desc[1] = 0.1; li_desc[2] = 0.1; li_desc[3] = 0.1; li_desc[4] = LCOLOR; li_desc[5] = 0.5; li_desc[6] = 0.5; li_desc[7] = 0.5; li_desc[8] = POSITION; li_desc[9] = x; li_desc[10] = y; li_desc[11] = z; li_desc[12] = 0.0; /* zero means infinte light */ li_desc[13] = LMNULL; lmdef(DEFLIGHT,i+1,14,li_desc); lmbind(LIGHT0+i,i+1); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21183; 14 Mar 90 6:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20996; 14 Mar 90 5:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20983; 14 Mar 90 4:57 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa26577; 14 Mar 90 4:46 EST Received: from HGRRUG52.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6288; Wed, 14 Mar 90 04:44:46 EST Date: Wed, 14 Mar 90 10:31 N From: TORDA%HGRRUG52.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: more named problems To: INFO-IRIS@BRL.MIL X-Original-To: INFO-IRIS@BRL.MIL Message-ID: <9003140446.aa26577@SMOKE.BRL.MIL> With regards to named problem message from Eric Pearce on march 14. I had the same problems and now have new ones. Two things helped the first problem 1. Fix up the nameserver so it returns the name localhost (as suggested by Lee A Butler). 2. Go into the /usr/NeWS/lib/NeWS and edit init.ps. Change NetSecurityWanted from true to false. Having done this, my named works, the window system starts, but now wsh from a toolchest won't work. The console window opens, and from that I can invoke a wsh (just not from the toolchest icon/menu). The most likely relevant error message from SYSLOG seems to be Mar 14 10:11:04 RUGMD2 grcond[4436]: CIO: Stack: file(?,W,R) file(?,W,R) Mar 14 10:11:04 RUGMD2 grcond[4436]: CIO: Executing: `getsocketpeername' Mar 14 10:11:04 RUGMD2 At: {200 'dict' 'begin' 'initmatrix' `newprocessgroup' /ConnectionNumber ConnectionNumber 1 'add' 'store' /ProcessGroup ConnectionNumber 'def' 'exch' 'pop' 'exch' 'pop' 'dup' *`getsocketpeername' /OriginatingHost 'exch' 'def' RemoteHostRegistry OriginatingHost 'known' OriginatingHost `localhostname' `anchorsearch' array{6} array{2} 'ifelse' 'or' NetSecurityWanted 'not' 'or' array{20} array{8} 'ifelse' `currentprocess' `killprocessgroup'} Mar 14 10:11:24 RUGMD2 grcond[4436]: Child process /bin/wsh terminated with stat us 9 Mar 14 10:11:24 RUGMD2 grcond[4436]: CIO: Hangup This all happens under Irix 3.1 and 4sight 1.2 In confusion Andrew Torda (bitnet) torda@hgrrug52   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21429; 14 Mar 90 6:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21397; 14 Mar 90 6:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab21391; 14 Mar 90 6:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26931; 14 Mar 90 5:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23401; Wed, 14 Mar 90 02:46:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 05:09:59 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: user-group-meeting Message-Id: <408@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody know of an SGI annual user's group meeting? If none exists, how about trying to organize one so we can meet each other and interact with SGI on a more "personal" basis... I have been to SUN's user group meetings and they were quite informative.... any comments? out there....   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21473; 14 Mar 90 6:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21397; 14 Mar 90 6:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21391; 14 Mar 90 6:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26890; 14 Mar 90 5:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22537; Wed, 14 Mar 90 02:34:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 05:00:00 GMT From: SARVAJIT S SINHA Organization: U of M Engineering, Ann Arbor, Mich. Subject: Interpolation using NURBS Message-Id: <492eb331.156e6@hawk.engin.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am looking for references on how to interpolate data in the form of z=f(x,y) using NURBS. Specifically, how can I represent an image of data- where pixels are the z's using NURBS, (with the intention of using the SGI-Iris hardware for display later). Any references will be appreciated. Thanks in advance, Sarvajit sinha@caen.engin.umich.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21553; 14 Mar 90 7:01 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa21514; 14 Mar 90 6:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21502; 14 Mar 90 6:38 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa27151; 14 Mar 90 6:33 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 14 Mar 90 12:34:11+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 14 Mar 90 12:31:23+0100 Date: 14 Mar 90 12:31:23+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Hot Line Message-ID: <231*doelz@urz.unibas.ch> ahem ... in Europe the situation is not crtitical. It is no problem to contact the next SGI *sales* office. The only problem here (in Switzerland) is that support issues are piped through numerous 'specialists' unless they reach ISO in the U.S. if they get there at all. Which means that you will get any *reply* within short time (sometimes a day, sometimes six months), but you can be nearly sure that you will not get an *answer*. The SGI support in Switzerland is miserable! There are a few guys there who do their best but can't work because they don't have equipment/experience on hand. My best source of information so far have been SGI engineers who replied on my problems posted on this bboard, either by reposts, or by direct mail. I really appreciate this kind of support and I don't want to miss it! - Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24138; 14 Mar 90 9:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23458; 14 Mar 90 9:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23367; 14 Mar 90 8:50 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa29562; 14 Mar 90 8:34 EST Received: Wed, 14 Mar 90 05:34:27 -0800 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Wed, 14 Mar 90 08:34:08 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Wed, 14 Mar 90 08:51:10 EST by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Wed, 14 Mar 90 08:51:10 EST From: Tony Facca Message-Id: <9003141351.AA19379@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Hot Line > "Prof. David F. Rogers" writes: > > I have long recommended and still recommend an electronic mail Hot Line. > This solves the time zone problem and significantly increases the > interaction for those of us who have email access. Why is SGI so I second this recommendation. I can't see that it would require an inordinate amount of time on SGI's part to establish an e-mail Hot Line. We could mail problems "in our own words" and include system error messages. This may even cut out some lead time as the Hot Line personnel won't have to take all this information down. When the e-mail gets to SGI, it can still receive a message ID number which can be mailed back to the requester to let us know that the mail has been received and is being worked on. Works for me. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27025; 14 Mar 90 12:45 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa26871; 14 Mar 90 12:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26853; 14 Mar 90 12:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05108; 14 Mar 90 11:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12887; Wed, 14 Mar 90 08:28:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 16:24:21 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Bringing Up C++ V1.2.1 on 4D/80GT Message-Id: <417@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Yes, I know. I am behind the times, but, I am just now bringing up AT&T C++ V1.2.1 on the 4D/80GT. Question: Are there any particular [mods|changes] to the source (c files, makefiles...) that you could tell me about? Thanks. /s/ Rich Rosenthal richr@ai.etl.army.mil -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Alexandria, VA 22060-5546 Phone: +1 202 355 3653   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28983; 14 Mar 90 14:48 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa27718; 14 Mar 90 13:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27351; 14 Mar 90 13:28 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07509; 14 Mar 90 13:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19788; Wed, 14 Mar 90 10:06:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 17:23:55 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: C++ 2.0 availability? Message-Id: <5247@odin.SGI.COM> References: <1990Mar13.135139.2351@ifi.unizh.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have C++ 2.0 running in house. I have forwarded your mail to the people responsible for the product. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00588; 14 Mar 90 15:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29429; 14 Mar 90 15:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29307; 14 Mar 90 15:02 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa10416; 14 Mar 90 14:52 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 14 Mar 90 20:53:36+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 14 Mar 90 20:50:53+0100 Date: 14 Mar 90 20:50:53+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Re: C++ 2.0 availability? Message-ID: <235*doelz@urz.unibas.ch> I am interested as well. We are expecting the tape C++ to be delivered more or less yesterday... It would be nice if we could start with 2.0 from the beginning. Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01070; 14 Mar 90 15:41 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28120; 14 Mar 90 14:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27909; 14 Mar 90 13:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07971; 14 Mar 90 13:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19779; Wed, 14 Mar 90 10:06:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 17:11:21 GMT From: martin Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hot Line Message-Id: <5245@odin.SGI.COM> References: <9003131856.aa03408@CAD.USNA.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003131856.aa03408@CAD.USNA.MIL> dfr@CAD.USNA.MIL ("Prof. David F. Rogers") writes: > > >There is usually 2-3 days of this before the problem gets defined, much less >resolved. We can't afford that and neither can commercial customers. > >I have long recommended and still recommend an electronic mail Hot Line. >This solves the time zone problem and significantly increases the >interaction for those of us who have email access. Why is SGI so >reluctant to develop an email Hot Line? > until there is an official e-mail hot line, i freely give my email to calls i have taken. i also ask the call administrators to ask for an e-mail address when a customer calls back that i have had a hard time reaching. it is perfectly acceptable to give your e-mail address to the call administrator when first opening a call. this is still not as good as an electronic mail hot line, but still cuts time down between coasts. Martin McDonald SGI Life is unpredictable. Eat dessert first. Martin McDonald SGI Life is unpredictable. Eat dessert first.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02095; 14 Mar 90 16:02 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28395; 14 Mar 90 14:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28170; 14 Mar 90 14:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07928; 14 Mar 90 13:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21291; Wed, 14 Mar 90 10:28:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 18:02:26 GMT From: hart Organization: David Taylor Research Center, Bethesda, MD Subject: 8MM Drives Message-Id: <1290@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does SGI or anyone with SGI gear have recommendations for third-party 8MM tape drives for backups? It appears that SGI has them for the "tower" systems (like 4D/240), but not in an external form factor to use as plug in SCSI add-ons for (in my case ) PI's. Is it true that Exabyte is the sole source for 8MM transports in North America, regardless of the vendor name on the box?? If the above is true, there should be little if any compatibility problems; right???? I'd like names and numbers of vendors, along with comments, recommendations and flames. If netters could reply via E-mail, I'll summarize and post. For replies here, read it yourself!!! +++++++++++++++++++++++++++++ In a related matter, we took an Archive 150MB QIC drive from MaxStream for the Mac (Identical in all observable ways to the SGI external 150MB tape from Archive), hooked it up to a PI, and, while it kinda worked, it was certainly not reliable enough to use for anything valuable. Any ideas on why this is/was??? ================================================= Michael G. Hart David Taylor Research Center Bethesda, MD ph 202-227-1979 mhart @dtrc.dt.navy.mil ------------------------------------------------- Secretary Cheney speaks for the Navy, not me! -------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02448; 14 Mar 90 16:23 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02095; 14 Mar 90 16:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02080; 14 Mar 90 16:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11422; 14 Mar 90 15:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28866; Wed, 14 Mar 90 12:17:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 19:12:15 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hot Line Message-Id: <53549@sgi.sgi.com> References: <9003131856.aa03408@CAD.USNA.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003131856.aa03408@CAD.USNA.MIL>, dfr@CAD.USNA.MIL ("Prof. David F. Rogers") writes: > Why is SGI so > reluctant to develop an email Hot Line? > > Dave Rogers > Just personal opinion and wild guessing with professional bias against the competition, but I'll go out on a limb and guess that it's that HP box that is/was used for call logging??? :{) Actually, sounds like a good idea, as long as it can filter out cruft from irresponsible netters. I have had good success w/ e-mail to and from certain special, *very privileged* customers. :{) :{) :{) markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02448; 14 Mar 90 16:23 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac02095; 14 Mar 90 16:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02080; 14 Mar 90 16:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11471; 14 Mar 90 15:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28758; Wed, 14 Mar 90 12:16:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 18:54:40 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Band Printers Message-Id: <53543@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone successfully integrated the likes of a 600 LPM band printer on either the PI Centronics interface or on the Parallel (Centronics and Versatec) interface on the ASD machines? If you have, or know of anyone who has, I would appreciate any details you could provide to me. (I haven't touched one of these beasts in several years, and never on an SGI box. I mean, SGI only makes workstations :{) , and workstations don't need high speed line printers. So what if it has 8 25 MHz processors , tons of memory, gig and gigs of disk space? Doesn't SGI only make work- stations?) Just kidding, folks. Actually, I know of no reason for a Centronics interfaced band printer not to work on the SGI machines, but the question of certain control characters, form feed, overprint, etc. come to mind a being somewhat problematic from the s/w standpoint. And don't forget all of those Snoopy on his Doghouse landscape demos printed with asteriks and 0's that one needs to port to the new devices. :{), again. Thanks in advance for your help. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02929; 14 Mar 90 16:44 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac02448; 14 Mar 90 16:34 EST Date: Wed, 14 Mar 90 16:14:05 EST From: "Lee A. Butler" To: info-iris@BRL Subject: Re: more named problems Message-ID: <9003141614.aa02272@VMB.BRL.MIL> >With regards to named problem message from Eric Pearce on march 14. [ stuff deleted ] >2. Go into the /usr/NeWS/lib/NeWS and edit init.ps. > Change NetSecurityWanted from true to false. WARNING: This will allow ANYONE from ANY MACHINE with IP access to your machine to talk to your NeWS server! This implies the ability to open windows, close windows, alter windows, etc. IMHO this is a little too trusting for ANY machine connected to the Internet! Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03060; 14 Mar 90 17:03 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02929; 14 Mar 90 16:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02836; 14 Mar 90 16:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13643; 14 Mar 90 16:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02043; Wed, 14 Mar 90 13:07:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 20:08:35 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: facilities in syslog Message-Id: <53562@sgi.sgi.com> References: <53884@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <53884@bu.edu.bu.edu> eap@cs.bu.edu (Eric A. Pearce) writes: > The man page for syslog, syslogd and /usr/include/bsd/syslog.h all mention > the facility "daemon", but syslogd doesn't seem to know about it: Fixed in the next release of IRIX.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03060; 14 Mar 90 17:03 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac02929; 14 Mar 90 16:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02917; 14 Mar 90 16:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13947; 14 Mar 90 16:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02949; Wed, 14 Mar 90 13:21:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 20:37:46 GMT From: Craig Westveer Organization: CDI Technologies Inc., Grand Rapids, MI Subject: File Server for SGI's Message-Id: <719@cditi.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are looking for a fast file server to host 15 - 20 4D machines. If anyone is using such a server or knows of a good server please mail me the information. Thanks caw   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03381; 14 Mar 90 17:26 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac03060; 14 Mar 90 17:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03013; 14 Mar 90 16:58 EST Received: from [192.12.31.1] by SMOKE.BRL.MIL id aa13882; 14 Mar 90 16:32 EST Date: Wed, 14 Mar 90 16:20:30 EST From: "Prof. David F. Rogers" To: info-iris@BRL.MIL cc: lara@sgi.com Subject: Hot line Message-ID: <9003141620.aa01190@CAD.USNA.MIL> G'day Lara, Also no offense but you are also wrong. I'm up by 0700 and in the office by 0830. However, I have these funny things called classes that DO take precedence. My systems programmer for family reasons doesn't get in 'til 0900. Some of us like to try to accommodate those that work with us. I also always give my home telephone number when contacting the Hot Line because of the time difference. Yet to receive a call. If I were running a company that had as large an installed base as SGI does on the East Coast on the West Coast, I would definitely keep my `Hot Line' open till 8PM for them. Especially, if I charged money for it!!! My comment about an email `Hot Line' still stands. Dave Rogers   Received: from VMB.BRL.MIL by VMB.brl.MIL id ab04037; 14 Mar 90 18:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03958; 14 Mar 90 18:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03945; 14 Mar 90 18:21 EST Received: from [192.48.153.1] by SMOKE.BRL.MIL id aa15526; 14 Mar 90 18:10 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/900301.SGI) for info-iris@brl.mil id AA23678; Wed, 14 Mar 90 15:10:14 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:dfr@cad.usna.mil id AA17321; Wed, 14 Mar 90 15:10:10 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA13043; Wed, 14 Mar 90 15:10:08 PST Message-Id: <9003142310.AA13043@forest.sgi.com> To: "Prof. David F. Rogers" Cc: info-iris@BRL.MIL Subject: Re: Hot Line and e-mail In-Reply-To: Your message of Tue, 13 Mar 90 18:56:23 -0500. <9003131856.aa03408@CAD.USNA.MIL> Date: Wed, 14 Mar 90 15:10:05 PST From: baskett%forest@sgi.com We have two basic kinds of network connections that carry e-mail. One is the government sponsored Internet and one is the individually sponsored uucp net. At the moment we are not sure how to restrict people from using the Internet for a commercial purpose such as an e-mail Hot Line. So we don't have an e-mail Hot Line. Our use of the Internet is supposed to be for research and educational purposes. It is not hard to argue that info-iris falls in that usage category. The Hot Line, on the other hand, is a clear commercial offering from Silicon Graphics. One of these days, the networking issues will not be so difficult, we all hope. Forest Baskett Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04099; 14 Mar 90 19:05 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04037; 14 Mar 90 18:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab03976; 14 Mar 90 18:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15586; 14 Mar 90 18:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10567; Wed, 14 Mar 90 15:14:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 21:41:51 GMT From: ogicse!uwm.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!1k1mgm@decwrl.dec.com Organization: University of Kansas Academic Computing Services Subject: Wanted: Linpack benchmarks for SGI 4D/2x0s Message-Id: <22482.25fe6640@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody (S.G. itself, maybe?) have standard Dongarra/Linpack benchmarks (N=100 vanilla, N=1000 tweaked and/or parallel) for 4D/2x0s? I have what may be latest and best report from Dongarra himself, done Feb. 7, 1990, and only Silicon Graphics report is something old and slow--does a Model 2400 ring any bells? (I'm away from my desk...) This would be useful, not critical, for grant proposal I'm writing. I'll use Mips M/2000 numbers ~= 4D/210 if there's nothing SGI-specific. Christopher Gunn Molecular Graphics & Modeling Lab SPAN--KUPHSX::SYBYL Department of Medicinal Chemistry 913-864-4428 or -4495 University of Kansas, Lawrence, KS 66045   Received: from VMB.BRL.MIL by VMB.brl.MIL id ab04185; 14 Mar 90 19:43 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04150; 14 Mar 90 19:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04131; 14 Mar 90 19:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15757; 14 Mar 90 18:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12488; Wed, 14 Mar 90 15:43:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 23:00:46 GMT From: Mike Thompson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Setting the access/modify time on a file Message-Id: <53595@sgi.sgi.com> References: <1413@watserv1.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1413@watserv1.waterloo.edu>, tom@mims-iris.waterloo.edu (Tom Haapanen) writes: > I wish to update a file (with an advisory lock), and then to close it, > setting the access and modify times to (almost) the same time. Here > is what I'm attempting: > > FILE *fp; > long times; > > fp = fopen("filename", "w"); > flock(fileno(fp), LOCK_EX); > > ... much i/o to the file ... > > fflush(fp); > times[1] = time(×[0]) - (long)2; > utime(mailfile, times); > > flock(fileno(fp), LOCK_UN); > fclose(fp); > > Now, at what point does the modify time get set? the utime() call appears > to set the access time, but the modify time appears to be set AGAIN after > the access time. Where SHOULD it get set? And what should I do to make > sure that my access time > modify time? > > The OS is IRIX 3.2 -- aka System V.3. Thanks for any and all replies! This is a bug in 3.2 -- the Extent File System routine which is deallocating preallocated file blocks on close is (mistakenly) forcing the modify time to be set (to the close time). It has been fixed for the upcoming release. For now, reopen the file after the fclose, and *then* call utime and reclose the file. The deallocation routine will not be called (actually, will return without doing anything) since there had been no file activity since the open. Michael Thompson   Received: from VMB.BRL.MIL by VMB.brl.MIL id ab04296; 14 Mar 90 20:02 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04185; 14 Mar 90 19:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04162; 14 Mar 90 19:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15932; 14 Mar 90 19:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13474; Wed, 14 Mar 90 15:59:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 23:55:30 GMT From: Tim Moore Organization: University of Utah CS Dept Subject: load instruction on MIPS R2000 and R3000 Message-Id: <1990Mar14.165530.17748@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On the MIPS R2000 and R3000 processors, does the following instruction have predictable results? lw $1,some_disp($1) $1 is also $at and is used internally by the MIPS assembler, but I'm not using the MIPS assembler. Thanks, Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00094; 14 Mar 90 20:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04296; 14 Mar 90 20:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04225; 14 Mar 90 19:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16167; 14 Mar 90 19:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15524; Wed, 14 Mar 90 16:31:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 00:19:47 GMT From: Tim Moore Organization: University of Utah CS Dept Subject: y Message-Id: <1990Mar14.171948.18680@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm in the process of porting gdb to sgi 4d machines, based on a gdb port to DECstation mips machines. It seems to basically work, but unpredictably flakes out with messages such as "debugged process doesn't exist" or "unable to set break points". Oh well. My question has to do with ptrace: Directive 1 (PTRC_RD_I) reads data from I space, 2 (PTRC_RD_U) reads from D space. Does it matter if you read data from data space using PTRC_RD_I? Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00372; 14 Mar 90 20:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00094; 14 Mar 90 20:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04298; 14 Mar 90 19:56 EST Received: from wugate.wustl.edu by SMOKE.BRL.MIL id aa14602; 14 Mar 90 17:00 EST Received: from pollux.wustl.edu by wugate.wustl.edu with SMTP (5.61++/IDA-1.2.8) id AA18069; Wed, 14 Mar 90 14:42:47 -0600 Received: by pollux.wustl.edu (5.52/890607.SGI) (for @wugate.wustl.edu:info-iris@BRL.MIL) id AA20553; Wed, 14 Mar 90 14:42:29 CST Date: Wed, 14 Mar 90 14:42:29 CST From: drzymala Message-Id: <9003142042.AA20553@pollux.wustl.edu> To: info-iris@BRL.MIL Subject: simultaneous selection of items from popup menus Cc: drzymala@pollux.wustl.edu Dear IRIX users: We would like to select multiple items from popup menus in our application programs. Does anybody have any experience with selecting mutiple items SIMULTANEOUSLY? We have only been able to figure out how to select ONE item at a time, but this is inconvenient for our purposes. We would like to call the menu from FORTRAN but C is OK. Also, we have X-windows software, so we can use this as well. It would also be useful to be able to specify where the menu will appear on the screen. Thank you very much in advance for your help. -- Robert E. Drzymala, Ph.D. INTERNET: drzymala@pollux.wustl.edu Radiation Oncology Center BITNET: drzymala@wunet.bitnet 510 S. Kingshighway Blvd. uucp: !uunet!wucs1!dinorah!drzymala St. Louis, MO 63110 (314) 362-2629   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00508; 14 Mar 90 20:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00372; 14 Mar 90 20:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00257; 14 Mar 90 20:30 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16606; 14 Mar 90 20:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17736; Wed, 14 Mar 90 17:07:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 23:43:39 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: Re: C++ 2.0 availability? Message-Id: <485@meritaus.UUCP> References: <1990Mar13.135139.2351@ifi.unizh.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From article <1990Mar13.135139.2351@ifi.unizh.ch>, by meyer@unizh.ifi.unizh.ch (Urs Meyer): > We ordered the C++ tape from our local SGI branch and received > version 1.2.1, which is not suitable for our needs. ^^^^^ ack! I just placed an order for C++ a couple of weeks ago. I swore I asked the salesman if it was version 2.0, and got an affirmative answer. Either my brain screwed up (not unlikely), or my salesman was mis-informed. We added C++ to our maintenance contract, so will we get a free upgrade to 2.0 when it becomes available?? -- dan haug Merit Technology, Inc. ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01097; 14 Mar 90 23:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01039; 14 Mar 90 23:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00975; 14 Mar 90 22:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17339; 14 Mar 90 22:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24520; Wed, 14 Mar 90 18:56:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 90 18:45:15 GMT From: Scott_Klosterman Organization: SDRC, Cincinnati Subject: Is this wrong? Message-Id: <1196@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The top of the file /usr/include/bsd/sys/ioctl.h contains the following: #ifndef __BSD_IOCTL__ #define __BSD_IOCTL__ /* * SGI compatibility hack which apes 4.3BSD . */ #include "../../sys/ioctl.h" #include #include Should the last two lines look like this? #include #include Or am I missing something? There is no /usr/include/net directory nor a /usr/include/sys/soictl.h uunet!sdrc!crscott Scott Klosterman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01657; 15 Mar 90 1:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01597; 15 Mar 90 1:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01583; 15 Mar 90 0:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17697; 14 Mar 90 23:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00991; Wed, 14 Mar 90 20:46:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 04:00:40 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: general questions Message-Id: <3985@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here's a few general questions: 1). We ordered a Video Creator card for our 120GTX back in January with the knowledge that they were not going to start shipping until March 1. Well it's the middle of March and our Rep has 'no idea' when we can expect it. Anyone know what's happening with these? 2). A while ago I posted a question about audio for the POWER SERIES. Was there any serious consideration from anyone at SGI? 3). I've tried to get the net version of 'arena' working but to no avail. I uncommented the line in /etc/services and envoke arena with the -n option but the two machines don't seem to know each other are there. Is there anything else I should be doing? 4). On a related note, does anyone have any of the data files for flight that they have created themselves like new buildings, planes etc. that they would be willing to share. Like a real F-18, 15 or something. The ones we have are starting to get old. That's all for this time folks, Tom Rohling   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01657; 15 Mar 90 1:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01597; 15 Mar 90 1:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01583; 15 Mar 90 0:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17709; 14 Mar 90 23:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28592; Wed, 14 Mar 90 20:07:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 04:05:11 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: Hot Line and e-mail Message-Id: <90Mar14.230345est.1442@smoke.cs.toronto.edu> References: <9003131856.aa03408@CAD.USNA.MIL>, <9003142310.AA13043@forest.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Would it run against the policies of the various Internet networks if one end of the email conversation was a research facility that considered it important that they get quick/convenient/well-informed answers to problems with their machines, so they could get on with the research that they're supposed to be doing?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02173; 15 Mar 90 3:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02109; 15 Mar 90 2:51 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa02037; 15 Mar 90 2:39 EST Date: Thu, 15 Mar 90 2:30:47 EST From: Phil Dykstra To: info-iris@BRL.MIL Subject: Two gl questions Message-ID: <9003150230.aa18653@SPARK.BRL.MIL> I have two questions about libgl of the form "is there a better way, and if not it sure would be nice if there was." 1) Two sided polygons. I am trying to draw lighted, two sided, Z buffered polygons. The key is that the surface is not closed, but I would like to have more than just an ambient component on the back side. The solution I have come up with is to draw every polygon twice, once CW, once CCW. Since they are coincident the Z buffer would yield unpredictable results, so I have turned backface culling on. This works pretty well, but requires sending twice as much data down the pipe, as well as making the processing of tmeshes messier. Is there a better way to do this? Something I would find very nice is a MATERIAL and/or LMODEL level selection of double sided polygons. This would simply entail flipping the normal vectors if the lighting model dot products came up negative. The required bandwidth into the pipe would remain the same, and the rendering time should be nowhere near twice as long. 2) Fat points. On high res screens, individual pixels have become so small and faint as to be almost invisible (at least in colors less than full white). None the less, point clouds are still a very useful way to look at data sets. Is there some way to draw a fat (i.e. multi-pixel) point? The key is something which is scale invariant. The linewidth control behaves in exactly the right way, but is only thick in one dimension (so drawing a zero length line doesn't solve the problem). A "pointwidth(n)" call would be perfect. === Is support for these operations already there somewhere, or would they require microcode changes? Any comments/suggestions are welcome. - Phil uunet!brl!phil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02287; 15 Mar 90 3:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02261; 15 Mar 90 3:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02234; 15 Mar 90 3:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18767; 15 Mar 90 3:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12457; Wed, 14 Mar 90 23:54:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 07:53:15 GMT From: Rayan Zachariassen Subject: Re: Hot Line and e-mail Message-Id: <90Mar15.025254est.7625@neat.cs.toronto.edu> References: <9003131856.aa03408@CAD.USNA.MIL>, <9003142310.AA13043@forest.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL baskett%forest@SGI.COM writes: >At the moment we are not sure how to restrict >people from using the Internet for a commercial purpose such as an >e-mail Hot Line. So we don't have an e-mail Hot Line. Our use of the >Internet is supposed to be for research and educational purposes. To quote from the acceptable-use document from the Federation of American Research networks (FARnet): Traffic between mid-levels should be restricted to research or academic purposes, or to direct administrative support of such efforts. Organizations whose connection to the internet is sponsored by a FRICC agency can use the network in support of the sponsored activities. Traffic whose content is solely commercial is not acceptable. ... In other words, traffic in support of sponsored activities (that's R&D) is allowed. It doesn't matter what the endpoints of the traffic are, just that one of the parties is participating in the traffic to support a "sponsored activity" (which in many R&D labs is a euphemism for "breathing"). Although there may be gray areas, it seems generally accepted that anybody with an Internet connection has some (at times flimsy) reason for having one and as long as you don't do commercial EDI or non-focused activities (e.g. advertising) over the Internet that all is ok. How many SGI machines on the Internet are *not* used for some form of R&D (aka "sponsored activity")? This of course doesn't allow you to use the Internet as a third-party network, which means you still need to maintain UUCP (or other) connectivity to talk to non-Internet sites... but that's another matter. Bottom line is that what may look like a commercial activity to you looks like a we-needed-this-a-year-ago facility to many Research and Academic Internet member organizations. rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04966; 15 Mar 90 9:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03171; 15 Mar 90 7:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03127; 15 Mar 90 7:23 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa19802; 15 Mar 90 6:30 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 15 Mar 90 12:31:37+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 15 Mar 90 12:28:38+0100 Date: 15 Mar 90 12:28:38+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: commercial e-mail, problem database (was:Hot line) Message-ID: <237*doelz@urz.unibas.ch> 1.) concerning the commercial aspects of INTERNET usage: I hope that support is a little bit more than sales and advertising. As far as I know the rules, research must be involved in the subject of transmitted messages, or at least support research activities. Even though I see your point saying that you are a commercial company, I think that an email hotline would be directly supporting researchers thus permitting you to use the INTERNET. 2.) What about setting up an 'iris-maintenance' email adress which could be accessed as database? Provided that the people asking for support agree, their problems could be made available (anonymously if needed) including the answer given by the support. Quite often I meet problems which are answered with replies like like 'will be in the next release' or so. The release notes of the OS need to be accumulated somewhere at SGI. As soon as an entry is completed, it were easy for SGI to inform customers by spreading the news. Normally, the problems are not that site-specific and a database of questions and answers were quite helpful to me. OK, you're using an HP box. But a simple thing were to have a log number attach to each incoming problem by the mailer program and send out the answers to a bouncing list referring to that number. Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00088; 15 Mar 90 9:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05468; 15 Mar 90 9:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05368; 15 Mar 90 9:22 EST Received: from Princeton.EDU by SMOKE.BRL.MIL id aa23512; 15 Mar 90 8:53 EST Received: from acm.Princeton.EDU by Princeton.EDU (5.58+++/2.32/mailrelay) id AA28596; Thu, 15 Mar 90 08:19:22 EST Received: from taylor.Princeton.EDU by acm.Princeton.EDU (5.61/1.98) id AA05221; Thu, 15 Mar 90 08:20:34 -0500 Received: by taylor.Princeton.EDU (5.61/1.95) id AA07447; Thu, 15 Mar 90 08:20:32 -0500 Date: Thu, 15 Mar 90 08:20:32 -0500 From: ams@acm.princeton.edu Message-Id: <9003151320.AA07447@taylor.Princeton.EDU> To: info-iris@BRL.MIL Subject: Re: commercial e-mail, problem database (was:Hot line) I really don't see what the problem is. A number of commercial companies right now have e-mail hotline support, and even encourage its use for low priority problems (especially those that are of the "look at this 200 line segment of code, why is ... not placed in a full word at ..."). For all the fluff about what constitutes "proper" use of the internet, I really don't think anyone will care if SGI adds a support@sgi.com so long as they don't collect a special fee for using it. NCD & MIPs routinely answer questions in this way right now. It is my impression that questions emailed to either will be answered regardless of maintenance agreement status, however, there is no guaranteed turn around time. As far as what SGI should do, my hotline response time is consistantly good (and I am on the east coast). However, a lot of times I think I would prefer to place an 800 line call but get the response via email and say a follow up call the next day. --ams _________________________________________________________________________ Andrew Simms, System Manager Program in Applied and Computational Mathematics Princeton University 218 Fine Hall, Washington Road ams@acm.princeton.edu Princeton, NJ 08544 609/258-5324 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01347; 15 Mar 90 10:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00980; 15 Mar 90 10:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00703; 15 Mar 90 10:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26154; 15 Mar 90 10:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06352; Thu, 15 Mar 90 07:00:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 13:41:27 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Re: Bringing Up C++ V1.2.1 on 4D/80GT Message-Id: <419@ai.etl.army.mil> References: <417@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <417@ai.etl.army.mil> richr@ai.etl.army.mil writes: >I am just now bringing up AT&T C++ V1.2.1 on the 4D/80GT. > >Are there any particular [mods|changes] to the >source (c files, makefiles...) that you could tell me about? Let me add to my previous request - We acquired 1.2 C++ from AT&T. We did this before we knew of its availability directly from SGI. (It took us 12 months of Government nonsense to finally get the tape in!) So, I need to know what if anything I need to do to the generic AT&T product to get it to work on 4D/80GT. Additional point - Would my license directly from AT&T for 1.2 C++ for the 4D/80 qualify me to receive the customized version from SGI? Someone at SGI, thanks for listening. -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Alexandria, VA 22060-5546 Phone: +1 202 355 3653   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02165; 15 Mar 90 11:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01990; 15 Mar 90 11:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01972; 15 Mar 90 11:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28583; 15 Mar 90 11:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10297; Thu, 15 Mar 90 08:02:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 15:56:35 GMT From: Tim Hall Organization: Boston University Subject: Re: Two gl questions Message-Id: <54012@bu.edu.bu.edu> References: <9003150230.aa18653@SPARK.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003150230.aa18653@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes: > >1) Two sided polygons. > >just an ambient component on the back side. The solution I have come >up with is to draw every polygon twice, once CW, once CCW. Since they >are coincident the Z buffer would yield unpredictable results, so I >have turned backface culling on. > The other solution I use is to make two diametric light sources. This way no matter which side of the polygon the normal is pointing one of the light sources will cause the polygon to be shaded. This seems faster than the above solution but this also only works for diffuse shading, it doesn't work with specular shading. >Something I would find very nice is >a MATERIAL and/or LMODEL level selection of double sided polygons. I second that. -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02690; 15 Mar 90 12:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02571; 15 Mar 90 12:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02251; 15 Mar 90 11:44 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa29366; 15 Mar 90 11:26 EST Received: from relay2.cs.net by RELAY.CS.NET id ab05040; 15 Mar 90 10:25 EST Received: from dupont.com by RELAY.CS.NET id ak13414; 15 Mar 90 11:25 EST Date: Thu, 15 Mar 90 10:32 EST From: MOHRINGJ%ESVAX%dupont.com@relay.cs.net Subject: Re: Hot Line and e-mail To: info-iris@BRL.MIL X-VMS-To: ESPRNT::IN%"info-iris@brl.ARPA" Message-ID: <9003151126.aa29366@SMOKE.BRL.MIL> I agree with Rayan Zachariassen's interpretation of the quoted text. "Traffic between mid-levels should be restricted to research or academic purposes, or to direct administrative support of such efforts. Organizations whose connection to the internet is sponsored by a FRICC agency can use the network in support of the sponsored activities. Traffic whose content is solely commercial is not acceptable. ..." Being familiar with the Specific (?) statements the government is known for, I believe they used this entire dissertation to simply say; "NO commercial Advertising!" Whereas, a facility supporting the R&D community, even if it is a commercial endeavor, is acceptable. In many cases, until a resolution is found to a problem, research is slowed, if not halted. It would be our responsibility not to use the proposed e-mail facility unless the above situation were in effect. These opinions are my own and do not necessarily reflect those of my superiors and/or subordinates. Jim "Trouble" Mohring   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03864; 15 Mar 90 13:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03517; 15 Mar 90 13:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03197; 15 Mar 90 12:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01237; 15 Mar 90 12:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15020; Thu, 15 Mar 90 09:12:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 15:42:41 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: SGI- user group(s) meeting Message-Id: <409@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I received e-mail about the possibility of getting the several user-groups together for an annual meeting , information exchange.... This would be separate from Siggraph so we don't get distracted from all of the other exciting happenings that usually go on at Siggraph. How about it? If we can get enough interest going, I'm sure we can get SGI to participate. We need a location, and people with organizational skills to pull it together. First, of course, we need the desire to meet..... Mic   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03864; 15 Mar 90 13:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03517; 15 Mar 90 13:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03206; 15 Mar 90 12:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01284; 15 Mar 90 12:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15047; Thu, 15 Mar 90 09:13:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 13:50:37 GMT From: Tony Facca Organization: NASA/Lewis Research Center, Cleveland Subject: Re: Sales help needed Message-Id: <1990Mar15.135037.7420@eagle.lerc.nasa.gov> References: <1990Mar13.002115.2013@Neon.Stanford.EDU>, <1756@speedy.mcnc.org> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >In article <1990Mar13.002115.2013@Neon.Stanford.EDU> loan@Neon.Stanford.EDU (James P. Loan) writes: > >Our sales rep is unreliable because he seems too busy to return my calls. [ others' SGI sales force bashing deleted ] Since it seems vogue to be bashing SGI sales people these days, I'd like to break the trend by stating that the Pittsburgh office which services us here in Cleveland has been doing an outstanding job. We deal with many vendors here and I firmly believe that the SGI sales (and technical) folks are the best. As most sale people can certainly confirm, dealing with government procurements can be more trouble than they are worth, yet our salesman works with us through even the most difficult buys. It took 13 months to acquire a machine, and then another couple of months before SGI got paid. He had to submit tons of paperwork and make a bunch of phone calls. As a customer this is very embarassing, yet the saleman never gave me a hard time about it. He is always willing to drop off the latest equipment for a week or so and let us do bench- marks, etc. The technical help is equally competent -- often more so than the Hot Line. Although they are in Pittburgh (about 2 and half hours from Cleve- land), our machines are never down more than a day once the problem is diagnosed. The field administrator (sales assistant) will take down a list of requirements from me in the morning, work up quotes for various configurations, and FAX me them by lunchtime. Am I satified with the support? That's for damn sure. So, if you guys in the valley are having too much trouble, why not move out to the great North East ;-) -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05422; 15 Mar 90 15:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05231; 15 Mar 90 15:18 EST Received: by VMB.BRL.MIL id ao05107; 15 Mar 90 15:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04604; 15 Mar 90 14:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03913; 15 Mar 90 13:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18801; Thu, 15 Mar 90 10:12:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 18:05:12 GMT From: Jason Heirtzler Organization: Boston University Information Technology Subject: how do you run your batch jobs? Message-Id: <54023@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL At BU we have our jobs on the SGIs split into two categories: long running (non-interactive) batch jobs and interactive jobs, typically whomever is sitting at the console. What we'd like to do is reduce the batch jobs to having the lowest impact on the interactive jobs. It looks like one possible way to do this is to start cron with `runon 3 cron' and maybe changing the queuedefs file to further reduce the batch processes priority. This would, unfortunately, nullify any parallelism in the batch task. My questions are `npri -n 15 -p pid' doesn't seem to have much effect; is this a bug in IRIX 3.2.1? will `runon 3 cron' force batch(1) jobs to run on CPU 3? The MP_MUSTRUN parameter of sysmp(2) only affects the calling process. Will there be a way to affect an arbitrary process? If you have a system for handling batch jobs that you think is useful, I'd be interested in hearing from you. ------------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!harvard!bu.edu!bu-pub!jdh ------------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!harvard!bu.edu!bu-pub!jdh   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac05422; 15 Mar 90 15:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05231; 15 Mar 90 15:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05224; 15 Mar 90 15:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05583; 15 Mar 90 14:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22271; Thu, 15 Mar 90 11:07:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 17:11:15 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: Bringing Up C++ V1.2.1 on 4D/80GT Message-Id: <5294@odin.SGI.COM> References: <417@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL SGI sells the C++ 1.2.1 product, and supports it, if you want to avoid the effort... We will be shipping C++2.0 sometime in the future (we are using it in house already). kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad05422; 15 Mar 90 15:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac05231; 15 Mar 90 15:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab05224; 15 Mar 90 15:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05645; 15 Mar 90 14:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22261; Thu, 15 Mar 90 11:07:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 17:41:14 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: load instruction on MIPS R2000 and R3000 Message-Id: <53751@sgi.sgi.com> References: <1990Mar14.165530.17748@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar14.165530.17748@hellgate.utah.edu>, moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes: > On the MIPS R2000 and R3000 processors, does the following instruction > have predictable results? > > lw $1,some_disp($1) > > $1 is also $at and is used internally by the MIPS assembler, but I'm > not using the MIPS assembler. Yes, it is predicatable - two cycles later $1 will contain the data located at some_disp($1). Note $1 cannot be used in the cycle immediately following the lw instruction, however other instructions including lw can be done there. If you were using the assembler, you could use .set noat to tell the assembler not to use $at. If you are not using the assembler, then I assume you are generating object code yourself. If you are doing this while the program is running then don't forget to flush the icache. In either case, you must respect the load delay of 1 cycle. -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05753; 15 Mar 90 16:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05422; 15 Mar 90 15:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05260; 15 Mar 90 15:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06814; 15 Mar 90 15:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24698; Thu, 15 Mar 90 11:42:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 18:56:22 GMT From: "Scott R. Presnell" Subject: Re: how do you run your batch jobs? Message-Id: <13385@cgl.ucsf.EDU> References: <54023@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL jdh@bu-pub.bu.edu (Jason Heirtzler) writes: >At BU we have our jobs on the SGIs split into two categories: long >running (non-interactive) batch jobs and interactive jobs, typically >whomever is sitting at the console. >What we'd like to do is reduce the batch jobs to having the lowest >impact on the interactive jobs. It looks like one possible way to >do this is to start cron with `runon 3 cron' and maybe changing the >queuedefs file to further reduce the batch processes priority. This >would, unfortunately, nullify any parallelism in the batch task. >If you have a system for handling batch jobs that you think is useful, >I'd be interested in hearing from you. I have written a batch job handler that seems to work for us. Some of the things it can do... 1) Start and stop at various times of the day. 2) Start and stop at varying loads. 3) Start and stop based on whether or not someone has logged into the console. (interactive tasks have a definite priority at our site). (start and stop by sending SIGCONT and SIGSTOP to entire process groups) 4) Run jobs with different nices *and* different n-pri's 5) There is message logging and accounting as well. The interface looks something like BSD lpr: there is a /etc/batchcap. and the programs are: batch, baq, barm, bac (and batchd for the daemon). I haven't "beta" tested it with anyone, and I have no idea what it will do on a multiprocessor machine as we don't have one (this was developed on a PI). To be honest, I'm still fixing the occasional bug. But it's used almost constantly, and the daemon basically never goes down. I'm still adding features and making it more robust. If your interested, drop me a line. - Scott -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac05753; 15 Mar 90 16:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae05422; 15 Mar 90 15:42 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa05370; 15 Mar 90 15:26 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa19330; 15 Mar 90 15:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26670; Thu, 15 Mar 90 12:11:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 18:55:59 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: load instruction on MIPS R2000 and R3000 Message-Id: <5306@odin.SGI.COM> References: <1990Mar14.165530.17748@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar14.165530.17748@hellgate.utah.edu>, moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes: > On the MIPS R2000 and R3000 processors, does the following instruction > have predictable results? > > lw $1,some_disp($1) > > $1 is also $at and is used internally by the MIPS assembler, but I'm > not using the MIPS assembler. > Thanks, > > Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore > "Ah, youth. Ah, statute of limitations." > -John Waters No problem, this is just fine (if your your doing your own pipeline scheduling remember to wait once instruction before accessing AT). Chris Wagner   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06338; 15 Mar 90 16:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05753; 15 Mar 90 16:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05487; 15 Mar 90 15:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06842; 15 Mar 90 15:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23435; Thu, 15 Mar 90 11:24:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 19:18:48 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: more named fun Message-Id: <54034@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Much thanks to randy@tessa.iaf.uiowa.edu and butler@BRL.MIL for the localhost fix - I now see that the system originally came with this file (oops!) Everything seems to be working fine now, with the exception of booting. Both mount and exportfs reject foreign hosts as unknown. I tried modifying /etc/init.d/network so named is started before the mount -t nfs and exportfs take place and this worked - BUT daemons after these get confused i.e. timeslave, lpd and the window manager crap out. Am I correct in interpreting this to mean /etc/hosts is ingored if /usr/etc/resolv.conf is present (named running or not)? I assume that I could just get nameservice from another host and eliminate problems with daemons starting before named kicks in, but this introduces a dependency on the other host. Would I gain anything by running yp ? It looks like it starts before the mount takes place. (the system is in heavy use, so I'd like to reduce the amount of rebooting to test all this) -e ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07158; 15 Mar 90 16:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06338; 15 Mar 90 16:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06029; 15 Mar 90 16:13 EST Received: from cs.utah.edu by SMOKE.BRL.MIL id aa08491; 15 Mar 90 15:44 EST Received: from adenosine.pharm.utah.edu (adenosine.nurs.utah.edu) by cs.utah.edu (5.61/utah-2.6-cs) id AA15583; Thu, 15 Mar 90 13:44:17 -0700 Date: Thu, 15 Mar 90 13:49:36 MST From: "Darrell R. Davis" Posted-Date: Thu, 15 Mar 90 13:49:36 MST Message-Id: <9003152049.AA16479@adenosine.pharm.utah.edu> Received: by adenosine.pharm.utah.edu (5.52/5.51) id AA16479; Thu, 15 Mar 90 13:49:36 MST To: info-iris@BRL.MIL Subject: Reading Sparc Tapes I recently bought a couple of Sparcstation-1's (Software compatibility reasons) and have just today tried to read a tape written on another Sparc onto my Iris 4D/20 ( a real graphics workstation, :-) ). If it had worked I wouldn't be posting this message. In the past I have read tapes from Sun-4's using the command line: dd if=/dev/tape conv=swab | tar xvf - I know that the Sparc's have a 150 meg drive, but so is the SGI drive, so whats the problem? I have tried both straight tar and byte swapping. -----Darrell R. Davis davis@adenosine.pharm.utah.edu Department of Medicinal Chemistry, University of Utah "Faster, faster, until the thrill of speed overcomes the fear of death." --H.S. Thompson -----   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07560; 15 Mar 90 17:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07402; 15 Mar 90 17:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07343; 15 Mar 90 17:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09694; 15 Mar 90 16:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00123; Thu, 15 Mar 90 13:01:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 20:31:44 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Is this wrong? Message-Id: <53777@sgi.sgi.com> References: <1196@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1196@sdrc.UUCP>, crscott@sdrc.UUCP (Scott_Klosterman) writes: > The top of the file /usr/include/bsd/sys/ioctl.h contains the > following: > > #ifndef __BSD_IOCTL__ > #define __BSD_IOCTL__ > /* > * SGI compatibility hack which apes 4.3BSD . > */ > > #include "../../sys/ioctl.h" > #include > #include > > > Should the last two lines look like this? > > #include > #include > > Or am I missing something? There is no /usr/include/net directory > nor a /usr/include/sys/soictl.h But there is a /usr/include/bsd/net directory. From intro(3): (3B) The routines in libbsd provide a limited subset of the Berkeley 4.3BSD UNIX standard C library. Include files used by these routines are in the directory /usr/include/bsd. To compile and link a program that calls any of these routines, use a command of the form: cc -I/usr/include/bsd prog.c -lbsd The compiler directive -I/usr/include/bsd allows you to write portable programs, so do not use a leading ``bsd/'' in #include file names: #include /* non-portable */ #include /* portable, use -I/usr/include/bsd */ The BSD ioctls that Irix supports are not so well documented as the network and system call BSD compatibility routines, but the rule for is the same as for the network and generic headers. In no case should be used, as the leading slash tells cpp to look for the file by the given absolute pathname. Important note for all our patient BSD-oriented customers: in the next release almost all BSD compatibility "goes native." The /usr/include/bsd tree becomes a tree of symbolic links to BSD headers in their natural locations (for example /usr/include/net), and you may elect not to install this compatibility tree. Almost all (3B) and (3N) routines are in libc; libbsd contains only a handful of entry points that collide with System V or POSIX routines in libc, and that cannot be renamed via a required header file so as to coexist in libc. Perhaps best of all, Irix implements BSD and POSIX signals. This means that if you've used the "non-portable" include form ( instead of and -I.../bsd), your source has differed needlessly from its BSD base, and you will need the /usr/include/bsd symbolic link tree in the next release. If you've used -I.../bsd as the man page recommends, no source changes are required and the -I's in your makefiles are useless but benign. As one who has ported much BSD and Sun code for years into the SGI product, I've chafed at System V's hegemony over libc and /usr/include, and bemusedly watched as AT&T has gradually adopted BSD and SunOS features. But SGI made a commitment to System V for the 4D series that was strong enough to keep BSD compatibility in a second-class position, so as to avoid "polluting" System V name spaces, till now. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08130; 15 Mar 90 19:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08082; 15 Mar 90 19:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08068; 15 Mar 90 18:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12402; 15 Mar 90 18:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10119; Thu, 15 Mar 90 15:32:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 23:29:02 GMT From: Tim Moore Organization: University of Utah CS Dept Subject: Flushing the icache Message-Id: <1990Mar15.162903.19284@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thanx to all those who responded to my previous MIPS question (about lw). It turns out that the bug I'm battling is caused by an icache/dcache consistency problem. So now I ask, is there any way to flush the icache on sgi 4d machines? If the answer is no, is there a way to find out the size of the icache at runtime? Thanks much, Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08130; 15 Mar 90 19:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08082; 15 Mar 90 19:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab08068; 15 Mar 90 18:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12405; 15 Mar 90 18:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09985; Thu, 15 Mar 90 15:31:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 21:51:20 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Is this wrong? Message-Id: <53784@sgi.sgi.com> References: <1196@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1196@sdrc.UUCP>, crscott@sdrc.UUCP (Scott_Klosterman) writes: > > The top of the file /usr/include/bsd/sys/ioctl.h contains the > following: > > #ifndef __BSD_IOCTL__ > #define __BSD_IOCTL__ > #include "../../sys/ioctl.h" > #include > #include > > Should the last two lines look like this? Yes! Consider the note on the bottom of every BSD related man page, which refers the reader to the instructions for building BSD stuff in our SV system. The gist is that in 3.2 and before, we chose '-I/usr/include/bsd -lbsd' as the switch for saying "do BSD stuff". There are certain things that differ between SV and BSD, so that one cannot be in both universes at once. You have to choose, for example, which kind of directories you want. A future release will have other ways of saying the same thing, altho they will be upward compatible. Vernon Schryver Silicon Graphics vjs@sgi.com.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08475; 15 Mar 90 20:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08319; 15 Mar 90 20:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08246; 15 Mar 90 19:50 EST Received: from forsythe.Stanford.EDU by SMOKE.BRL.MIL id aa12598; 15 Mar 90 18:58 EST Received: by Forsythe.Stanford.EDU; Thu, 15 Mar 90 15:57:48 PST Received: by SLACVM (Mailer R2.03B) id 4061; Thu, 15 Mar 90 15:58:16 PST Date: Thu, 15 Mar 1990 15:53 PST From: Len Sweeney To: info-iris@BRL.MIL Subject: Two gl questions Message-ID: <9003151858.aa12598@SMOKE.BRL.MIL> I second the motion for easy, efficient fat points. Otherwise, I suppose we define a font with the appropriate size centered point, and do lots of cmov, charstr.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08475; 15 Mar 90 20:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08319; 15 Mar 90 20:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08269; 15 Mar 90 19:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12861; 15 Mar 90 19:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13536; Thu, 15 Mar 90 16:21:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 22:06:10 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hot Line and e-mail Message-Id: <53789@sgi.sgi.com> References: <9003131856.aa03408@CAD.USNA.MIL>, <9003142310.AA13043@forest.sgi.com>, <90Mar14.230345est.1442@smoke.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Mar14.230345est.1442@smoke.cs.toronto.edu>, moraes@cs.toronto.edu (Mark Moraes) writes: > Would it run against the policies of the various Internet networks if > one end of the email conversation was a research facility that > considered it important that they get quick/convenient/well-informed > answers to problems with their machines, so they could get on with the > research that they're supposed to be doing? I have occassionally asked Powers That Be essentially this question. I have been answered "... that might be ok, but don't quote me. We are working on the rules, and will let you and everyone else know." Notice one minor hassle with the current structure of the Internet. What about the zillion purely commercial customers of UUNET? Imagine what might happen if one of them purchased an IRIS (well, let's have them all purchase lots of IRIS's), and decided to send the Hotline a Valentine's Day greeting (while we're hypothesising, let's assume the customer has no problems). The message would probably go via private UUCP to the east coast to uunet.uu.net, then onto JVCNet (?), onto NSFNet, eventually to BARRNet to sgi.sgi.com, and finally to some machine within SGI. Notice how two evil money making organizations have communicated about something unrelated to any interests of any Official Sponsoring Agencies. There are other possibilities. What if Sun Microsystems purchased an IRIS, and decided to email to the Hotline? Such mail would likely use guvn'mnt subsidized wires and routers. Mind you, this is all hypothetical, since we all know that all Internet email, netnews, FTP's, and so on are purely for Official U.S. Guvnmnt Purposes. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08641; 15 Mar 90 20:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08526; 15 Mar 90 20:47 EST Date: Thu, 15 Mar 90 20:26:35 EST From: Mike Muuss To: Info-Iris@BRL Subject: Service Testimonial Time? Message-ID: <9003152026.aa08387@VMB.BRL.MIL> We at BRL have been very satisfied with SGI's field support. Our main serviceman is Dave Dabay, and he is top-notch. More skilled than many of the hardware developers, well versed in diagnostic technique, as well as intimately familiar with the details of the entire SGI product line. My observation has been that SGI service has a bi-modal distribution. Either it is very good, or it is poor. I can offer no explanation, but I'm glad that our experience has been very good. The local SGI sales organization is of ordinary quality. Two remaining challenges for SGI: Infant mortality of H/W, and obnoxious wrinkles in the software. Both are getting to be smaller problems as time goes by. But, both still continue to pain me regularly. Oh well. "Owning an SGI is like riding fast on a motorcycle. The sensation of speed and power is exhilarating, but you occasionally get hit by a blob of mud." Best, -Mike Muuss   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09327; 15 Mar 90 23:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09248; 15 Mar 90 23:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09206; 15 Mar 90 23:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14122; 15 Mar 90 22:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26377; Thu, 15 Mar 90 19:20:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 02:22:49 GMT From: Dave Olson Subject: Re: 8MM Drives Message-Id: <5331@odin.SGI.COM> References: <1290@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1290@nems.dt.navy.mil> mhart@dtoa1.dt.navy.mil (hart) writes: >Is it true that Exabyte is the sole source for 8MM transports in North >America, regardless of the vendor name on the box?? YES. >If the above is true, there should be little if any compatibility problems; >right???? NO. Exabyte produces different proms for different vendors, for assorted reasons. Some will work with our system, some won't. Also, because the same driver is used for all SCSI tape drives, we key off of the vendor name (and where appropriate) product name to decide what kind of special things we can/may do with the drive. Some of the special proms return different inquiry strings, so we may not recognize a drive from a third party vendor. >In a related matter, we took an Archive 150MB QIC drive from MaxStream >for the Mac (Identical in all observable ways to the SGI external 150MB >tape from Archive), hooked it up to a PI, and, while it kinda worked, >it was certainly not reliable enough to use for anything valuable. >Any ideas on why this is/was??? For the same reason an Exabyte might not work. The Mac doesn't quite implement the SCSI standard 'correctly', and the vendors often make special proms, and even sometimes PC board changes, when selling into the MAC market. One of the reasons we charge more than third party vendors for our peripherals is that we end up doing a fair amount of testing and working with vendors to try to ensure that the periphals do, in fact, work with our systems, both at the hardware and software level. Dave Olson Life would be so much easier if we could just look at the source code.   Received: from VMB.BRL.MIL by VMB.brl.MIL id ac01111; 16 Mar 90 17:02 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00090; 16 Mar 90 16:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16528; 16 Mar 90 11:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17684; 16 Mar 90 6:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24986; Fri, 16 Mar 90 03:04:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 04:35:00 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: Hot Line and e-mail Message-Id: <10579@alice.UUCP> References: <9003131856.aa03408@CAD.USNA.MIL>, <9003142310.AA13043@forest.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL forest's point is a good one but MIPS has an e-mail bug box. it is not a hotline as such, but a place to send bug reports to. i wonder if this evades the commercial restrictions.. if so, perhaps sgi could do the same.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01607; 16 Mar 90 17:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01111; 16 Mar 90 17:01 EST Received: by VMB.BRL.MIL id ad00558; 16 Mar 90 16:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13886; 16 Mar 90 9:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17876; 16 Mar 90 7:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24979; Fri, 16 Mar 90 03:04:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 04:29:37 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: 8MM Drives Message-Id: <10578@alice.UUCP> References: <1290@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i am only 99.5% sure of this but i believe it. Sony is the sole source of 8mm drives. Until somewhat recently, they shipped drives to Exabyte, who then modified the electronics and then sold it to you. Sony has since formed a 8mm data products group, which sells this tweaked drive directly to Exabyte who then resells it to you without further ado (more or less). Last i spoke with Sony people, they had no plans to sell the drivbes to anyone other than Exabyte (i can imagine licensing problems etc.). on the other hand, exabyte drives can be had quite cheaply these days from third parties ($3.5K?), despite the fact that SGI (and MIPS and DEC and ..) charge rather more (they do add value, even if only in FCC stuff).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01048; 17 Mar 90 0:58 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01008; 17 Mar 90 0:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00980; 17 Mar 90 0:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10483; 17 Mar 90 0:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29118; Fri, 16 Mar 90 21:03:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 90 16:09:52 GMT From: Scott_Klosterman Organization: SDRC, Cincinnati Subject: Re: Hot Line Message-Id: <1200@sdrc.UUCP> References: <9003131856.aa03408@CAD.USNA.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Certainly I've recieved better response from the SGI hotline than EVERY other vendors Hardware/Software Support line, for this would like to give you a hand. (clap,clap,etc.) But consider the following. After I receive a call back at my office phone (usually the next morning as described previously for us East Coast persons) I try the little tidbit which the Support person wants me to try which will verify the problem. This usually involves shutdown of the machine so I tell Support I will call him/her back right away, hang up the phone, walk to the machine, and call the Hotline back within thirty seconds. Now instead of getting an operator, During busy periods (afternoon our time) I get about five minutes of music, by the time some-one picks up and forwards my call, the Support Engineer has given up on me, and called another person or had another call come in. So I leave a message and write down the results of the previous test and walk back to my office and wait for his call. This may happen again if the SE has found something else to try. A lot of my time could be saved if I was given the direct call number of the SE to call him back. Instead all the SE are given instructions that all calls should go through the hotline even if a call has already been logged. Lately it seems that I don't wait nearly as long getting through the hotline, have you hired additional hotline staff?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10601; 16 Mar 90 3:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10537; 16 Mar 90 3:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10513; 16 Mar 90 2:57 EST Received: from cs.utah.edu by SMOKE.BRL.MIL id aa15962; 16 Mar 90 2:35 EST Received: from adenosine.pharm.utah.edu (adenosine.nurs.utah.edu) by cs.utah.edu (5.61/utah-2.6-cs) id AA01011; Thu, 15 Mar 90 23:44:43 -0700 Date: Thu, 15 Mar 90 23:50:04 MST From: "Darrell R. Davis" Posted-Date: Thu, 15 Mar 90 23:50:04 MST Message-Id: <9003160650.AA17864@adenosine.pharm.utah.edu> Received: by adenosine.pharm.utah.edu (5.52/5.51) id AA17864; Thu, 15 Mar 90 23:50:04 MST To: info-iris@BRL.MIL Subject: Gnu Make Has anyone been able/had inordinate trouble with "making" Gnu make. We haven't had more than usual minor difficulties with Emacs, gnutar, gnuplot. These are all up and running fine. gmake is also running on our Suns and we have the latest distribution from prep.ai.mit.edu. If this doesn't sound familiar I will provide specifics. Thanks, -----Darrell R. Davis davis@adenosine.pharm.utah.edu Department of Medicinal Chemistry, University of Utah "Faster, faster, until the thrill of speed overcomes the fear of death." --H.S. Thompson -----   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01607; 16 Mar 90 17:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01111; 16 Mar 90 17:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00784; 16 Mar 90 16:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03539; 16 Mar 90 15:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27034; Fri, 16 Mar 90 12:13:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 20:09:07 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: Random window death Message-Id: <54113@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I think this has been asked before, but I didn't see an answer. A lot of our users have been complaining about logging into the console and having the initial console window not showing up. You can open other windows at this point though. It seems to be random - it does it for different users at different times. Could it be related to system load? I'm not sure what else would vary so much. (This is on a Iris 4D/220 GT running 3.2.1) -e ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02635; 16 Mar 90 18:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02147; 16 Mar 90 18:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02098; 16 Mar 90 17:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01044; 16 Mar 90 13:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18914; Fri, 16 Mar 90 10:10:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 13:27:56 GMT From: Jeff Hanson Organization: NASA/Lewis Research Center, Cleveland Subject: E-mail HotLine Message-Id: <1990Mar16.132756.20844@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I agree with Prof. Rogers and everyone else who has requested an e-mail hotline and I agree with Forest Baskett about his concerns about legitimate and ethical use of the Internet. I suggest a variation, HotFax. SGI sets up several fax machines connected to an 800 number to which users can fax problems/questions/etc. This has two distinct advantages over e-mail. 1. Everyone can get a fax machine. Our local sales office in Pittsburgh doesnot have network access but does have a fax machine. 2. No conflicts with networks, nor problems with bounced mail. See the Viewpoint article by John McCarthy in CACM, Dec 89 for a discussion of fax versus currently constructed e-mail. This idea was expressed to me by Troy Norcross, SGI Indianapolis, as a warm line, where non-critical problems could be addressed. I think it makes a great deal of sense, allowing problems to be submitted and solved in a less rushed fashion. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* \ / \ / \ / \ / \ / \ / Jeff Hanson \ / \ / \ / \ / \ / \ / * * * * * * tohanson@gonzo.lerc.nasa.gov * * * * * * / \ / \ / \ / \ / \ / \ NASA Lewis Research Center / \ / \ / \ / \ / \ / \ * * * * * * * Cleveland, Ohio 44135 * * * * * * * \ / \ / \ / \ Telephone - (216) 433-2284 Fax - (216) 433-2182 \ / \ / \ / *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*   Received: from VMB.BRL.MIL by VMB.brl.MIL id ac02868; 16 Mar 90 19:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02780; 16 Mar 90 19:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02748; 16 Mar 90 19:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27805; 16 Mar 90 12:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11713; Fri, 16 Mar 90 08:19:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 06:26:26 GMT From: Paul Jackson Organization: Silicon Graphics, Research & Development Subject: Re: how do you run your batch jobs? Message-Id: <5339@odin.SGI.COM> References: <54023@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <54023@bu.edu.bu.edu>, jdh@bu-pub.bu.edu (Jason Heirtzler) writes: > > At BU we have our jobs on the SGIs split into two categories: long > running (non-interactive) batch jobs and interactive jobs, typically > whomever is sitting at the console. > > What we'd like to do is reduce the batch jobs to having the lowest > impact on the interactive jobs. It looks like one possible way to > do this is to start cron with `runon 3 cron' and maybe ... > > `npri -n 15 -p pid' doesn't seem to have much effect; is > this a bug in IRIX 3.2.1? The npri -n option takes absolute nice values, not relative. The nice command takes relative. The absolute nice of a process is visible under the NI column of ps -l. It is typically 20 for interactive processes. To slow a process down, try -n 30 or (slowest) -n 39. The request for -n 15 will actually speed a process up a little bit. > > ... > > If you have a system for handling batch jobs that you think is useful, > I'd be interested in hearing from you. The next release will support a new option - a port of NQS to IRIX. This is a more elaborate batch system that is available on several big-iron number crunchers, such as Cray, Convex, and (soon) SGI. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.brl.MIL id ad02868; 16 Mar 90 19:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02780; 16 Mar 90 19:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac02748; 16 Mar 90 19:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00537; 16 Mar 90 13:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18002; Fri, 16 Mar 90 09:56:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 17:27:29 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 8MM Drives Message-Id: <53844@sgi.sgi.com> References: <1290@nems.dt.navy.mil>, <10578@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10578@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: > > > i am only 99.5% sure of this but i believe it. > > Sony is the sole source of 8mm drives. Until somewhat recently, > they shipped drives to Exabyte, who then modified the electronics > and then sold it to you. Sony has since formed a 8mm data products > group, which sells this tweaked drive directly to Exabyte who then > resells it to you without further ado (more or less). Last i spoke > with Sony people, they had no plans to sell the drivbes to anyone other > than Exabyte (i can imagine licensing problems etc.). > > on the other hand, exabyte drives can be had quite cheaply these days > from third parties ($3.5K?), despite the fact that SGI (and MIPS and DEC and ..) > charge rather more (they do add value, even if only in FCC stuff). The mechanism is made by Sony. The drive is made by Exabyte. They have a *very* exclusive right to sell and mfr. these. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson Disclaimer: Anything I say is my opinion. If someone else wants to use it, it will cost...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03050; 16 Mar 90 19:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02780; 16 Mar 90 19:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02748; 16 Mar 90 19:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27791; 16 Mar 90 12:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13602; Fri, 16 Mar 90 08:50:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 15:45:33 GMT From: Jeff Doughty Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Flushing the icache Message-Id: <5342@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Thanx to all those who responded to my previous MIPS question (about > lw). It turns out that the bug I'm battling is caused by an > icache/dcache consistency problem. So now I ask, is there any way to > flush the icache on sgi 4d machines? If the answer is no, is there a > way to find out the size of the icache at runtime? The following code will do the job: #include ... sysmips(FLUSH_CACHE); ... Jeff Doughty IRIX group   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03050; 16 Mar 90 20:14 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02868; 16 Mar 90 19:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02807; 16 Mar 90 19:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02519; 16 Mar 90 14:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25310; Fri, 16 Mar 90 11:47:15 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 19:08:16 GMT From: Bob Blean Organization: Silicon Graphics Inc. Subject: Re: Make problems Message-Id: <5353@odin.SGI.COM> References: <9003051914.AA28827@blumiris.chem.umr.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9003051914.AA28827@blumiris.chem.umr.edu>, bobf@BLUMIRIS.CHEM.UMR.EDU ("Robert B. Funchess") writes: > I finally figured out what was causing the Make problems, by comparing a > Makefile from ~4Dgifts with the problem one. Apparently on some systems it > is NOT necessary to explicitly specify SHELL=/bin/sh, that being taken as a > given. Irix *seems* to require this, or at least it generally works if I > include it. Unless of course I need the BSD-flavor install. The real > problem is that there are (at least) two main kinds of unix and whatever it > is that you need was written for the other one, no matter which one it is that > you have. > -- > < Bob | bobf | Funchess > > > Stay alert! Trust no one! Keep your laser handy! This is not really an Irix matter. This is a difference between BSD make and System V make. In System V, "make" uses the SHELL variable to decide how to interpret the commands in the makefile. BSD: according to the man page on a DECstation 3100 (Ultrix): When invoked as make or /bin/make, the environment variable SHELL is ignored and /bin/sh is always used as the command interpreter. In System V make, which Irix has, the man page says: Command lines are executed one at a time, each by its own shell. The SHELL environment variable can be used to specify which shell make should use to execute commands. The default is /bin/sh. Since the environment variable SHELL is generally set to be your interactive shell, you need to arrange to have it reset if the makefile is written for another shell. Or, assuming you don't run "make -e", you can set SHELL in the makefile as the /usr/people/4Dgifts/Makefile does. (Note that it is common to use csh as your interactive shell, and so to have the environment variable $SHELL set to /bin/csh, but to have a Makefile written for Bourne shell.) One way for csh users to do this is with an alias: alias make '(setenv SHELL /bin/sh; exec make \!*)'   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03772; 16 Mar 90 20:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03050; 16 Mar 90 20:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02937; 16 Mar 90 19:38 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07614; 16 Mar 90 19:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11872; Fri, 16 Mar 90 16:14:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 90 23:34:19 GMT From: Keith Bierman - SPD Advanced Languages Organization: Sun MegaSystems Subject: Re: E-mail HotLine Message-Id: References: <1990Mar16.132756.20844@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Mar16.132756.20844@eagle.lerc.nasa.gov> tohanson@gonzo (Jeff Hanson) writes: ... I suggest a variation, HotFax. SGI sets up several fax machines connected to an 800 number to which users can fax problems/questions/etc. This has two distinct advantages over e-mail. How is this easier than setting up a BBS and using modems ? Several PC companies provide such services. -- Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM It's Not My Fault | MTS --Only my work belongs to Sun* kbierman%eng@sun.com I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00091; 16 Mar 90 22:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04120; 16 Mar 90 21:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04100; 16 Mar 90 21:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08464; 16 Mar 90 20:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15185; Fri, 16 Mar 90 17:04:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Mar 90 00:17:43 GMT From: Ron Fischer Organization: Silicon Graphics, Entry Systems Division Subject: Re: 8MM Drives Message-Id: <5367@odin.SGI.COM> References: <1290@nems.dt.navy.mil>, <10578@alice.UUCP>, <53844@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm just a software type and am curious. How different are the 8mm data drives from video drives? ronf();