Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25218; 29 Sep 89 7:24 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24918; 29 Sep 89 6:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24913; 29 Sep 89 6:38 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06455; 29 Sep 89 6:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA14602; Fri, 29 Sep 89 02:52:05 -0700 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: 29 Sep 89 09:46:05 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: Re: Disappearing debug Message-Id: <574@chem.ucsd.EDU> References: <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca>, <28319@abbott.mips.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <28319@abbott.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: #In article <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca> LEONARDZ@UOGUELPH.BITNET ("Len Zaifman UoGuelph 824-4120 xt 6566", 519) writes: ## Our operations group was running a backup recently, which crashed. ##The system was brought up again and much to my dismay(at a later date), there ##was no /debug file system(using df to show what was there). ##In particular, how can processes run without swap space?? Are they all kept ##in memory?? #/debug (or, in RISC/os, /proc) is *NOT* your swap space. It's a special #type of virtual filesystem which presents a view of your running processes #accessible through the file namespace. If it's not mounted, you just can't #use programs (like some debuggers and other tools) that access processes by #opening them like files. This has *nothing* to do with your swap space. #ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 But the burning question is... If your disk is partitioned so that /debug gets, say, 53meg, does that mean that you only have 53meg of swap space, maximum? -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27967; 29 Sep 89 10:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27452; 29 Sep 89 9:46 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa27392; 29 Sep 89 9:38 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa09123; 29 Sep 89 8:37 EDT Received: Fri, 29 Sep 89 08:36:44 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 29 Sep 89 08:36:44 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909291536.AA15392@aero4.larc.nasa.gov> To: psuvm!w0l@psuvax1.cs.psu.edu Subject: Re: Device drivers for HP printers Cc: info-iris@BRL.MIL I wrote a program that creates files for HP Thinkjet printers and works on SGI 3000's. You could use it as starting point. It is written in FORTRAN so you will have to change it to C, because the 4D FORTRAN doesn't support binary files (real pain in neck). I put this on the Info-Iris anonyous ftp account. There are also some programs in the file for other printers, Tektronix 4693D, Postscript, and Printronix. I hope these are of some help. -- 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 aa28790; 29 Sep 89 10:45 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28404; 29 Sep 89 10:34 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa28217; 29 Sep 89 10:18 EDT Received: from prandtl.nas.nasa.gov by ADM.BRL.MIL id aa08904; 29 Sep 89 9:44 EDT Received: Fri, 29 Sep 89 06:43:18 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Fri, 29 Sep 89 09:42:27 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Fri, 29 Sep 89 10:12:26 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Fri, 29 Sep 89 10:12:26 EDT From: Tony Facca Message-Id: <8909291412.AA13345@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: limiting resources Tom Haapanen writes: > Well, we have /tmp on a separate partition (the root partition) with normally > about 8.5 MB of free space. But the downside of this is that I can not vi > a one-megabyte ascii file! The temp file would be about 9 MB, I think! > > Does anyone know why vi creates such monster temp files? Can't this be > fixed (by someone who has source)? A workaround might be to set the environment variable EXINIT to change the default directory (/tmp) which vi uses when it starts up. I have plenty of disk space available in a directory called /usr/tmp on a separate partition, so if I enter the commend: setenv EXINIT 'set directory=/usr/tmp' from the C Shell, I can once again "vi" large files. This doesn't explain WHY vi creates such large temp files, but it might help someone. -- ----------------------------------------------------------------------------- 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 aa00137; 29 Sep 89 12:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29775; 29 Sep 89 12:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29762; 29 Sep 89 11:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11097; 29 Sep 89 9:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24340; Fri, 29 Sep 89 06:20:32 -0700 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: 29 Sep 89 10:06:36 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: NFS on PI Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am happy to report that SGI has fixed the problems I reported earlier with NFS crashing my PI. The second or third call to the hotline found someone who knew about a bug in the 3.1D revision relating to ethernet stuff. They shipped us a 3.1G tape and I have been unable to crash the system since :-). Apparently the releases between 3.1D and 3.1G were distributed only to sites which reported problems. This is a nice policy to relieve the user of the burden of upgrading all the time, but I would have liked to have heard about the existence of the upgrades and the bugs they fixed.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02652; 29 Sep 89 14:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02435; 29 Sep 89 14:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02168; 29 Sep 89 14:12 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa03356; 29 Sep 89 13:32 EDT Received: Fri, 29 Sep 89 13:31:46 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 29 Sep 89 13:31:46 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909292031.AA16218@aero4.larc.nasa.gov> To: prism!vsserv!stat!stat.fsu.edu!mccalpin@gatech.edu Subject: Re: NFS on PI Cc: info-iris@BRL.MIL What would be nice is if they sent you a short note when ever there was a new release and what that release fixes. Then you could send them a card back if you wanted the newest release. -- 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 aa03306; 29 Sep 89 15:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02957; 29 Sep 89 14:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02695; 29 Sep 89 14:45 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04114; 29 Sep 89 14:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09429; Fri, 29 Sep 89 10:56:56 -0700 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: 29 Sep 89 16:32:40 GMT From: HOUFAC Organization: Control Data Corporation, Arden Hills, MN. Subject: X Windows performance on PI Message-Id: <14134@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know how the Turbo Graphics option affects X-windows performance on a Personal IRIS? (For applications running locally -- not across a network.) I've heard that IRIX 3.2 provides a big improvement, but I'm looking for all I can get. I'm already planning a 20MHz CPU upgrade -- any idea how much that'll help? Is X CPU-bound or graphics-bound?? Thanks! --Pete Poorman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04551; 29 Sep 89 16:02 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02061; 29 Sep 89 14:16 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01912; 29 Sep 89 14:06 EDT Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa00257; 29 Sep 89 11:43 EDT Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA29145; Fri, 29 Sep 89 10:26:38 -0500 Received: by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA15606; Fri, 29 Sep 89 09:58:37 cdt Message-Id: <8909291458.AA15606@kailand.kai.com> From: Patrick Wolfe Date: Fri, 29 Sep 89 09:58:35 CDT Organization: Kuck and Associates, Inc., 1906 Fox Drive, Champaign IL 61820, voice 217-356-2288, fax 217-356-5199 X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: info-iris@BRL.MIL Subject: Re: limiting resources > Written by tom@watale.UUCP > > Well, we have /tmp on a separate partition (the root partition) with normally > about 8.5 MB of free space. When setting up our systems (both System V and BSD), I replace /tmp with a symbolic link to /usr/tmp, which has lots more free space than the root partition does. Many programs (both user and system alike) like to temporarily store huge files in /tmp. On the SGI systems, I also had to edit /etc/init.d/RMTMPFILES to change "mkdir /tmp" with "ln -s /usr/tmp /tmp", or my change would be undone at the next boot. This does not cause any problems with normal operations (nothing uses /tmp before /usr gets mounted). -- Patrick Wolfe (pat@kai.com, kailand!pat) System Manager, Kuck & Associates, Inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05202; 29 Sep 89 16:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04865; 29 Sep 89 16:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04731; 29 Sep 89 16:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07047; 29 Sep 89 15:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA14803; Fri, 29 Sep 89 12:22:48 -0700 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: 29 Sep 89 18:31:06 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: /debug (again and again and again...) Message-Id: <42340@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > #/debug (or, in RISC/os, /proc) is *NOT* your swap space. It's a special > #type of virtual filesystem which presents a view of your running processes > #accessible through the file namespace. If it's not mounted, you just can't > #use programs (like some debuggers and other tools) that access processes by > #opening them like files. This has *nothing* to do with your swap space. > #ROGER B.A. KLORESE MIPS Computer Systems, Inc. > But the burning question is... > If your disk is partitioned so that /debug gets, say, 53meg, does that mean > that you only have 53meg of swap space, maximum? > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu Tom, didn't you READ the article you were appending to? Repeat After Me, 500 times: "/debug is NOT my swap space". /debug is simply an informational window to processes' virtual space, used by debuggers (eg dbx). IT NEITHER CONSUMES NOR PROVIDES PHYSICAL RESOURCES. /debug is not "on" a disk partition. Your swap space IS on one or more disk partitions reserved for the purpose, normally partition 1 on the root disk. Other partitions can be added to the swap space; try 'man swap' for details. Incidentally, is anyone from Tech Pubs here reading this group? I would guess that the continuing confusion on the /debug issue is a strong suggestion that documentation on the point needs to be improved... Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06269; 29 Sep 89 19:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06124; 29 Sep 89 18:11 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06042; 29 Sep 89 18:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09016; 29 Sep 89 17:21 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21803; Fri, 29 Sep 89 14:08:11 -0700 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: 29 Sep 89 20:46:16 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: /debug (again and again and again...) Message-Id: <42352@sgi.sgi.com> References: <42340@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <42340@sgi.sgi.com>, daveh@xtenk.sgi.com (David A Higgen) writes: > > But the burning question is... > > If your disk is partitioned so that /debug gets, say, 53meg, does that mean > > that you only have 53meg of swap space, maximum? > > > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu > > Tom, didn't you READ the article you were appending to? > Repeat After Me, 500 times: "/debug is NOT my swap space". > > /debug is simply an informational window to processes' virtual space, used > by debuggers (eg dbx). IT NEITHER CONSUMES NOR PROVIDES PHYSICAL RESOURCES. > > /debug is not "on" a disk partition. Your swap space IS on one or more > disk partitions reserved for the purpose, normally partition 1 on the > root disk. Other partitions can be added to the swap space; try > 'man swap' for details. > > Incidentally, is anyone from Tech Pubs here reading this group? I would > guess that the continuing confusion on the /debug issue is a strong > suggestion that documentation on the point needs to be improved... > > > Dave Higgen > /debug is an file interface to system processes. Unmounting /debug to not unmount the swap space; unmounting only removes access to the interface which SGI's dbx can access and debug processes. However, playing out /debug's affectation of a real file system, many of the standard IRIX(TM) file and filesystem commands present information about the /debug interface and the swap partion AS THOUGH they were real live IRIX(TM) file systems though they are not. As part of of this, df of /debug reveals the size of your swap partion. Thus yes, if "df -k /debug" says /debug imitation file system has 51048 kbytes, your swap partion has been partioned for approximately 51MB of swap space (virtual memory). It is wise to take heed from Mr. Higgen and remember that /debug is not a real file system but is a file system abstraction of the processes executing under IRIX(TM). --- Dave Ciemiewicz -- ------------------------------------------------------------------------------- Cosmo Ciemo, Silicon Valley Dude I was traipsing through the fields of my mind when I stepped in something that smelled rather ripe. -------------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06680; 29 Sep 89 21:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06427; 29 Sep 89 19:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06408; 29 Sep 89 19:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10393; 29 Sep 89 19:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28558; Fri, 29 Sep 89 15:54:15 -0700 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: 29 Sep 89 18:41:15 GMT From: Tom Haapanen Organization: WATMIMS Research Group, University of Waterloo Subject: ftp, ftpd wanted for Iris 4D Message-Id: <3304@watale.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does someone have a new version of ftp and ftpd that has been properly ported to the Iris 4D? The one that came with our IRIX 3.1C appears to be rather old and broken: version 4.147 Nov 5 1988 12:18 Is IRIX 3.2 available now? Does it have a newer ftp/ftpd? Or if they are already in 3.1G, would it be possible to upgrade just those two? I have the current ftpd from uunet, but I'm getting tired of fixing things when I'm not really familiar with the program. Right now, in my almost-vanilla port, I get core dumps from a null password and from 'dir', and 'mget *' doesn't work -- you need to use 'mget ./*'. If anyone has ported the uunet versions to the Iris and has them working consistantly, please let me know. \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07020; 29 Sep 89 22:02 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06817; 29 Sep 89 21:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06745; 29 Sep 89 21:05 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10931; 29 Sep 89 20:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03478; Fri, 29 Sep 89 17:12:17 -0700 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: 29 Sep 89 22:51:00 GMT From: "Roger B.A. Klorese" Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Re: Disappearing debug Message-Id: <28500@abbott.mips.COM> References: <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca>, <28319@abbott.mips.COM>, <574@chem.ucsd.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <574@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes: >If your disk is partitioned so that /debug gets, say, 53meg, does that mean >that you only have 53meg of swap space, maximum? /debug doesn't get *any* space. It's a figment. Your swap space is your swap space. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07292; 29 Sep 89 22:33 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07000; 29 Sep 89 21:51 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06976; 29 Sep 89 21:44 EDT Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa11265; 29 Sep 89 20:50 EDT Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6821; Fri, 29 Sep 89 19:16:10 CDT Received: by UMRVMA (Mailer R2.03B) id 6820; Fri, 29 Sep 89 19:16:07 CDT Date: Fri, 29 Sep 89 19:12:16 CDT From: "Bob B. Funchess" Subject: GIF file converter To: info-iris@BRL.MIL Message-ID: <8909292050.aa11265@SMOKE.BRL.MIL> I recently posted a note wanting a rgb to GIF file converter. Since there was no response, I wrote my own... well, actually, I used large chunks of existing code, and just interfaced that with the SGI rgb file format. Since I've done this, and I hate to see anyone reinvent the wheel, I will provide source (in C) to anyone wanting it. I would love to get improved versions back, this is my first C program. Now if someone would provide an easy way to turn .im8 files into rgb... < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07433; 29 Sep 89 23:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07373; 29 Sep 89 22:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07336; 29 Sep 89 22:50 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10479; 29 Sep 89 19:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA00445; Fri, 29 Sep 89 16:22:08 -0700 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: 29 Sep 89 23:18:24 GMT From: Lance Kurisaki Organization: UCLA Computer Science Department Subject: CAP software on an SGI Message-Id: <27586@shemp.CS.UCLA.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, Has anyone successfully compiled the Columbia CAP software on a Silicon Graphics 4D machine? I'd like to set mine up as an Appleshare server, but I'm having problems bringing up CAP. Any help would be appreciated. Lance Kurisaki kurisaki@cs.ucla.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07531; 29 Sep 89 23:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07373; 29 Sep 89 22:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07371; 29 Sep 89 22:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12070; 29 Sep 89 22:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09315; Fri, 29 Sep 89 18:56:13 -0700 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: 30 Sep 89 01:10:25 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: /debug (again and again and again...) Message-Id: <42372@sgi.sgi.com> References: <42340@sgi.sgi.com>, <42352@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <42352@sgi.sgi.com>, ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) writes: > In article <42340@sgi.sgi.com>, daveh@xtenk.sgi.com (David A Higgen) writes: > > > > But the burning question is... > > > If your disk is partitioned so that /debug gets, say, 53meg, does that mean > > > that you only have 53meg of swap space, maximum? > > > > > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu > > > > Tom, didn't you READ the article you were appending to? > > Repeat After Me, 500 times: "/debug is NOT my swap space". > > > > /debug is simply an informational window to processes' virtual space, used > > by debuggers (eg dbx). IT NEITHER CONSUMES NOR PROVIDES PHYSICAL RESOURCES. > > > > /debug is not "on" a disk partition. Your swap space IS on one or more > > disk partitions reserved for the purpose, normally partition 1 on the > > root disk. Other partitions can be added to the swap space; try > > 'man swap' for details. > > > > Incidentally, is anyone from Tech Pubs here reading this group? I would > > guess that the continuing confusion on the /debug issue is a strong > > suggestion that documentation on the point needs to be improved... > > > > > > Dave Higgen > > > > /debug is an file interface to system processes. Unmounting /debug to > not unmount the swap space; unmounting only removes access to the interface > which SGI's dbx can access and debug processes. > > However, playing out /debug's affectation of a real file system, many > of the standard IRIX(TM) file and filesystem commands present information > about the /debug interface and the swap partion AS THOUGH they were real > live IRIX(TM) file systems though they are not. > > As part of of this, df of /debug reveals the size of your swap partion. > Thus yes, if "df -k /debug" says /debug imitation file system has > 51048 kbytes, your swap partion has been partioned for approximately > 51MB of swap space (virtual memory). It turns out I was wrong on this point. "df -k /debug" reveals the size of your virtual memory which is the size of the swap partition plus the size of physical memory. If you really want to find out the size of your swap partion, do as root: prtvtoc /dev/rvh This will print the volume header of your first disk. If your disk is of standard configuration, your root partion will be on partition 0, swap on partition 1, and /usr on partition 6. I did this on my machine and found out that my swap partion was 72,100 sectors or 36,050 kbytes in size. My physical memory is 16 MB or 16,384 kbytes. Add the two together and you get 52,434 KB or approximately what "df -k /debug" had reported above for my virtual memory size. (I can't account for the discrepancy.) > > It is wise to take heed from Mr. Higgen and remember that /debug is not > a real file system but is a file system abstraction of the processes > executing under IRIX(TM). > Advice I really should have taken myself. Thanks to Chris Dunlap for pointing out the error of my ways. -- ------------------------------------------------------------------------------- Cosmo Ciemo, Silicon Valley Dude I was traipsing through the fields of my mind when I stepped in something that smelled rather ripe. -------------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07730; 30 Sep 89 0:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07610; 30 Sep 89 0:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07579; 29 Sep 89 23:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12554; 29 Sep 89 23:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13189; Fri, 29 Sep 89 20:06:23 -0700 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: 29 Sep 89 14:45:58 GMT From: Jeff Doughty Organization: Silicon Graphics, Inc., Mountain View, CA Subject: vi and huge temp files Message-Id: <737@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Well, we have /tmp on a separate partition (the root partition) with normally > about 8.5 MB of free space. But the downside of this is that I can not vi > a one-megabyte ascii file! The temp file would be about 9 MB, I think! > Does anyone know why vi creates such monster temp files? Can't this be > fixed (by someone who has source)? This was a bug accidentally introduced in the 3.1 version. The 3.2 release (which should be available now) has a fixed version. A workaround is to create a .exrc in your home directory with the line: set directory=/usr/tmp This will cause vi to use /usr/tmp (or any other place with space) for its temp files. Jeff Doughty UNIX group   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08157; 30 Sep 89 3:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08144; 30 Sep 89 2:49 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08136; 30 Sep 89 2:42 EDT Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa13898; 30 Sep 89 2:06 EDT Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA11136; Sat, 30 Sep 89 02:05:02 EDT Received: by cmcl2.NYU.EDU (5.61/1.34) id AA10112; Sat, 30 Sep 89 01:06:58 -0400 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA09848; Fri, 29 Sep 89 23:46:51 EDT Date: Fri, 29 Sep 89 23:46:51 EDT From: Rod Paul Message-Id: <8909300346.AA09848@dasys1.UUCP> To: info-iris@BRL.MIL, maytag!vlsi!watale!tom@jarvis.csri.toronto.edu Subject: Re: limiting resources > Well, we have /tmp on a separate partition (the root partition) with normally > about 8.5 MB of free space. But the downside of this is that I can not vi > a one-megabyte ascii file! The temp file would be about 9 MB, I think! > > Does anyone know why vi creates such monster temp files? Can't this be > fixed (by someone who has source)? > As someone from SGI pointed out at an earlier date put the following in ~/.exrc set directory=/usr/tmp This will get around the problem unitl you receive 3.2.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13742; 1 Oct 89 20:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13567; 1 Oct 89 19:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13553; 1 Oct 89 19:31 EDT Received: from Outlaw.UWyo.Edu by SMOKE.BRL.MIL id aa02016; 1 Oct 89 18:46 EDT Received: from uwyo.edu by CORRAL.UWyo.Edu with INTERNET ; Sun, 1 Oct 89 16:45:50 MDT Received: by uwyo.edu (4.0/SMI-4.0) id AA07476; Sun, 1 Oct 89 16:34:14 MDT Date: Sun, 1 Oct 89 16:34:14 MDT From: mark oliver Message-Id: <8910012234.AA07476@uwyo.edu> To: info-iris@BRL.MIL Subject: gl history requested Would someone who is familiar with the initial project that led to the GL board be willing to provide a brief history of the "early" years of the GL board? Mark Oliver University of Wyoming captain@outlaw.uwyo.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17082; 4 Oct 89 11:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16678; 4 Oct 89 11:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16665; 4 Oct 89 11:02 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05672; 4 Oct 89 2:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA05502; Tue, 3 Oct 89 20:54:09 -0700 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 Oct 89 21:21:19 GMT From: Reid Ellis Organization: T'nir Software Subject: Re: X Windows performance on PI Message-Id: <472@alias.UUCP> References: <14134@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL pwp@shamash.UUCP (Pete Poorman - HOUFAC) writes: |Does anyone know how the Turbo Graphics option affects X-windows performance |on a Personal IRIS? (For applications running locally -- not across a network.) | |I've heard that IRIX 3.2 provides a big improvement, but I'm looking for |all I can get. Something that was recently pointed out to me was that you can improve the performance of X applications on Iris consoles by setting your DISPLAY to be "unix:0" rather than "localhost:0". Apparently, the latter causes some interaction with network daemons, whereas the former goes straight to work, so to speak. Reid --- Reid Ellis, 264 Broadway Avenue, Toronto ON, M4P 1V9, Canada rae%alias@csri.utoronto.ca, rae@geac.uucp, rae@ziebmef.uucp, rae@gpu.utcs.utoronto.ca, rae@tnir.uucp +1 416 487 1383   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25555; 2 Oct 89 19:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25521; 2 Oct 89 18:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25512; 2 Oct 89 18:37 EDT Received: from [131.120.1.17] by SMOKE.BRL.MIL id aa07593; 2 Oct 89 17:58 EDT Received: by trouble.cs.nps.navy.mil (4.1/cs.nps-1.0) id AA16481; Mon, 2 Oct 89 14:56:09 PDT Date: Mon, 2 Oct 89 14:56:09 PDT From: michael zyda Message-Id: <8910022156.AA16481@trouble.cs.nps.navy.mil> To: info-iris@BRL.MIL Subject: Optical disks for the IRIS... Cc: zyda@trouble.cs.nps.navy.mil I hear that the Introl Company has optical disks that can be plugged into a SCSI interface on the IRIS. Does anyone have any experience with these drives? Are there other manufacturers that provide optical drives for the IRIS? Does SGI have plans for providing such a capability (and by when)? Thank you for any responses. Michael Zyda   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27035; 3 Oct 89 1:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26927; 3 Oct 89 1:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab26873; 3 Oct 89 1:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10537; 2 Oct 89 23:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12420; Mon, 2 Oct 89 19:32:41 -0700 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 Oct 89 21:29:20 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: lampon/off Message-Id: <764@odin.SGI.COM> References: <8081@medusa.cs.purdue.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Can anyone explain why on earth the calls to lampon() and lampoff() > take such a significant portion of a second on a Personal IRIS? Thanks > in advance. Thanks to the "magic" of write only registers, some central agent has to remember the current keyboard state and all requests to change that state must go through the agent. The chosen agent is the window server. Hence there is a network trip involved. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!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 aa27265; 3 Oct 89 2:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26927; 3 Oct 89 1:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa26873; 3 Oct 89 1:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10525; 2 Oct 89 23:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08500; Mon, 2 Oct 89 18:23:23 -0700 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 Oct 89 23:36:03 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: GIF file converter Message-Id: <42429@sgi.sgi.com> References: <8909292050.aa11265@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* * fromsun.c - * convert a sun image file to Iris format. * * This program should handle 1-bit, 8-bit and 24-bit sun rasterfiles. * Please mail paul@sgi.com if you have a problem rasterfile. This * program will not work on run length encoded raster files yet, * send me info and I might make it work for you. . . . * * To use: * 1. copy /usr/include/rasterfile.h from a sun system * 2. cc -I/usr/inlcude/gl fromsun.c -o fromsun -limage * 3. to convert: fromsun blat.im8 t.rgb * 4. to display: ipaste t.rgb * * Paul Haeberli@Silicon Graphics - 1989 * */ #include "image.h" #include "rasterfile.h" #define MAXWIDTH 4096 char cbuf[3*MAXWIDTH]; short rbuf[MAXWIDTH]; short gbuf[MAXWIDTH]; short bbuf[MAXWIDTH]; unsigned char rmap[256]; unsigned char gmap[256]; unsigned char bmap[256]; main(argc,argv) int argc; char **argv; { IMAGE *image; FILE *inf; int xsize, ysize, zsize, rowbytes; int y, depth, maplen; struct rasterfile hdr; if(argc<3) { fprintf(stderr,"usage: fromsun image.im8 outimage\n"); exit(1); } inf = fopen(argv[1],"r"); if(!inf) { fprintf(stderr,"fromsun: can't open %s\n",argv[1]); exit(1); } fread(&hdr,1,sizeof(hdr),inf); hdr.ras_magic = RAS_MAGIC; xsize = hdr.ras_width; ysize = hdr.ras_height; depth = hdr.ras_depth; if(depth != 8 && depth != 24 && depth != 1) { fprintf(stderr,"fromsun: bad ras_depth is %d\n",hdr.ras_depth); exit(1); } rowbytes = hdr.ras_length/ysize; switch(hdr.ras_type) { case RT_OLD: hdr.ras_length = ysize*linebytes(xsize,depth); rowbytes = hdr.ras_length/ysize; break; case RT_STANDARD: rowbytes = hdr.ras_length/ysize; break; case RT_BYTE_ENCODED: fprintf(stderr,"fromsun: don't know about RT_BYTE_ENCODED\n"); exit(1); break; default: fprintf(stderr,"fromsun: bad ras_type is %d\n",hdr.ras_type); exit(1); break; } maplen = hdr.ras_maplength; if(maplen == 0 && depth == 8) { fprintf(stderr,"fromsun: no map on 8 bit image\n"); exit(1); } if(maplen > 0) { fread(rmap,maplen/3,1,inf); fread(gmap,maplen/3,1,inf); fread(bmap,maplen/3,1,inf); } if(depth == 1) image = iopen(argv[2],"w",RLE(1),3,xsize,ysize,1); else image = iopen(argv[2],"w",RLE(1),3,xsize,ysize,3); for(y=0; y0) { if(*cptr & 0x80) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x40) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x20) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x10) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x08) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x04) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x02) *sptr++ = 0; else *sptr++ = 255; if(*cptr & 0x01) *sptr++ = 0; else *sptr++ = 255; cptr++; n -= 8; } } linebytes(xsize,depth) int xsize, depth; { return (( ((xsize*depth) + (16-1)) >> 3) &~ 1); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11968; 4 Oct 89 6:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11675; 4 Oct 89 5:30 EDT Received: by VMB.BRL.MIL id aa11540; 4 Oct 89 5:01 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa11531; 4 Oct 89 4:51 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa06253; 4 Oct 89 4:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22732; Tue, 3 Oct 89 09:04:10 -0700 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 Oct 89 20:18:47 GMT From: "Loren (Buck" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center Subject: Virtual Memory (Was: Disappearing debug) Message-Id: <492@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL All of this discussion brings back a question I have had for a while, and that is: How do you tell how much virtual (and real) memory a given process is using? B Cing U Buck Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer CSC, 1100 West St. | uucp: ...!ames!dftsrv!drax!buck | "By the horns of a Laurel, MD 20707 | phonenet: (301) 497-2531 or 9898 | sky demon..."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29135; 3 Oct 89 8:16 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28102; 3 Oct 89 7:39 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa27878; 3 Oct 89 7:19 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13150; 3 Oct 89 6:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA05144; Tue, 3 Oct 89 03:28:43 -0700 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 Oct 89 07:59:52 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: A filter to convert IRIS images to Compuserve GIF format Message-Id: <42452@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* * togif - * Convert an IRIS image to GIF format. Converts b/w and * color images to 8 bit per pixel GIF format. Color images * are dithered with a 4 by 4 dither matrix. GIF image files * may be uuencoded, and sent over the network. * * Paul Haeberli @ Silicon Graphics - 1989 * * To compile use: * * cc -I/usr/include/gl togif.c -o togif -limage * */ #include "image.h" #define MAXXSIZE 4096 #define MAXCOLORS 256 short rbuf[MAXXSIZE]; short gbuf[MAXXSIZE]; short bbuf[MAXXSIZE]; short obuf[MAXXSIZE]; int rmap[MAXCOLORS]; int gmap[MAXCOLORS]; int bmap[MAXCOLORS]; int iscolor, currow; IMAGE *iimage; int getgifpix(x,y) int x, y; { if(iscolor) { if(currow!= y) { getrow(iimage,rbuf,iimage->ysize-1-y,0); getrow(iimage,gbuf,iimage->ysize-1-y,1); getrow(iimage,bbuf,iimage->ysize-1-y,2); ditherrow(rbuf,gbuf,bbuf,obuf,iimage->xsize,y); currow = y; } return obuf[x]; } else { if(currow!= y) { getrow(iimage,rbuf,iimage->ysize-1-y,0); currow = y; } return rbuf[x]; } } main( argc, argv ) int argc; char *argv[]; { FILE *of; int xsize, ysize; int i, bpp; int r, g, b; if(argc<2) { fprintf(stderr,"usage: togif image.rgb image.gif\n"); exit(1); } iimage = iopen(argv[1],"r"); if(!iimage) { fprintf(stderr,"togif: can't open input image [%s]\n",argv[1]); exit(1); } xsize = iimage->xsize; ysize = iimage->ysize; if(iimage->zsize>=3) iscolor = 1; else iscolor = 0; of = fopen(argv[2],"w"); if(!of) { fprintf(stderr,"togif: can't open out image [%s]\n",argv[2]); exit(1); } if(iscolor) { for(i=0; i>0)&0x7; g = (i>>3)&0x7; b = (i>>6)&0x3; rmap[i] = (255*r)/7; gmap[i] = (255*g)/7; bmap[i] = (255*b)/3; } } else { for(i=0; imatval) tabval = (val/TOTAL)+1; else tabval = (val/TOTAL); tabval *= mult; tabval += add; tab[j][256*i+k] = tabval; } } } return tab; } ditherrow(r,g,b,wp,n,y) unsigned short *r, *g, *b; short *wp; int n, y; { short *rbase; short *gbase; short *bbase; if(!rtab) { rtab = makedittab(8,1,0); gtab = makedittab(8,8,0); btab = makedittab(4,64,0); } rbase = rtab[WRAPY(y)]; gbase = gtab[WRAPY(y)]; bbase = btab[WRAPY(y)]; while(n) { if(n>=XSIZE) { *wp++ = rbase[*r++ + 0] + gbase[*g++ + 0] + bbase[*b++ + 0]; *wp++ = rbase[*r++ + 256] + gbase[*g++ + 256] + bbase[*b++ + 256]; *wp++ = rbase[*r++ + 512] + gbase[*g++ + 512] + bbase[*b++ + 512]; *wp++ = rbase[*r++ + 768] + gbase[*g++ + 768] + bbase[*b++ + 768]; n -= XSIZE; } else { *wp++ = rbase[*r++] + gbase[*g++] + bbase[*b++]; rbase += 256; gbase += 256; bbase += 256; n--; } } } /* * SCARY GIF code follows . . . . sorry. * * Based on GIFENCOD by David Rowley .A * Lempel-Zim compression based on "compress". * */ /***************************************************************************** * * GIFENCODE.C - GIF Image compression interface * * GIFEncode( FName, GHeight, GWidth, GInterlace, Background, * BitsPerPixel, Red, Green, Blue, GetPixel ) * *****************************************************************************/ typedef int (* ifunptr)(); #define TRUE 1 #define FALSE 0 int Width, Height; int curx, cury; long CountDown; int Pass = 0; int Interlace; /* * Bump the 'curx' and 'cury' to point to the next pixel */ BumpPixel() { curx++; if( curx == Width ) { curx = 0; if( !Interlace ) { cury++; } else { switch( Pass ) { case 0: cury += 8; if( cury >= Height ) { Pass++; cury = 4; } break; case 1: cury += 8; if( cury >= Height ) { Pass++; cury = 2; } break; case 2: cury += 4; if( cury >= Height ) { Pass++; cury = 1; } break; case 3: cury += 2; break; } } } } /* * Return the next pixel from the image */ GIFNextPixel( getpixel ) ifunptr getpixel; { int r; if( CountDown == 0 ) return EOF; CountDown--; r = (*getpixel)( curx, cury ); BumpPixel(); return r; } /* * public GIFEncode */ GIFEncode( fp, GWidth, GHeight, GInterlace, Background, BitsPerPixel, Red, Green, Blue, GetPixel ) FILE *fp; int GWidth, GHeight; int GInterlace; int Background; int BitsPerPixel; int Red[], Green[], Blue[]; ifunptr GetPixel; { int B; int RWidth, RHeight; int LeftOfs, TopOfs; int Resolution; int ColorMapSize; int InitCodeSize; int i; Interlace = GInterlace; ColorMapSize = 1 << BitsPerPixel; RWidth = Width = GWidth; RHeight = Height = GHeight; LeftOfs = TopOfs = 0; Resolution = BitsPerPixel; CountDown = (long)Width * (long)Height; Pass = 0; if( BitsPerPixel <= 1 ) InitCodeSize = 2; else InitCodeSize = BitsPerPixel; curx = cury = 0; fwrite( "GIF87a", 1, 6, fp ); Putword( RWidth, fp ); Putword( RHeight, fp ); B = 0x80; /* Yes, there is a color map */ B |= (Resolution - 1) << 5; B |= (BitsPerPixel - 1); fputc( B, fp ); fputc( Background, fp ); fputc( 0, fp ); for( i=0; i #define ARGVAL() (*++(*argv) || (--argc && *++argv)) int n_bits; /* number of bits/code */ int maxbits = BITS; /* user settable max # bits/code */ code_int maxcode; /* maximum code, given n_bits */ code_int maxmaxcode = (code_int)1 << BITS; /* should NEVER generate this code */ # define MAXCODE(n_bits) (((code_int) 1 << (n_bits)) - 1) count_int htab [HSIZE]; unsigned short codetab [HSIZE]; #define HashTabOf(i) htab[i] #define CodeTabOf(i) codetab[i] code_int hsize = HSIZE; /* for dynamic table sizing */ count_int fsize; /* * To save much memory, we overlay the table used by compress() with those * used by decompress(). The tab_prefix table is the same size and type * as the codetab. The tab_suffix table needs 2**BITS characters. We * get this from the beginning of htab. The output stack uses the rest * of htab, and contains characters. There is plenty of room for any * possible stack (stack used to be 8000 characters). */ #define tab_prefixof(i) CodeTabOf(i) #define tab_suffixof(i) ((char_type *)(htab))[i] #define de_stack ((char_type *)&tab_suffixof((code_int)1< 0 ) goto probe; nomatch: output ( (code_int) ent ); out_count++; ent = c; if ( free_ent < maxmaxcode ) { CodeTabOf (i) = free_ent++; /* code -> hashtable */ HashTabOf (i) = fcode; } else cl_block(); } /* * Put out the final code. */ output( (code_int)ent ); out_count++; output( (code_int) EOFCode ); return; } /***************************************************************** * TAG( output ) * * Output the given code. * Inputs: * code: A n_bits-bit integer. If == -1, then EOF. This assumes * that n_bits =< (long)wordsize - 1. * Outputs: * Outputs code to the file. * Assumptions: * Chars are 8 bits long. * Algorithm: * Maintain a BITS character long buffer (so that 8 codes will * fit in it exactly). Use the VAX insv instruction to insert each * code in turn. When the buffer fills up empty it and start over. */ unsigned long cur_accum = 0; int cur_bits = 0; unsigned long masks[] = { 0x0000, 0x0001, 0x0003, 0x0007, 0x000F, 0x001F, 0x003F, 0x007F, 0x00FF, 0x01FF, 0x03FF, 0x07FF, 0x0FFF, 0x1FFF, 0x3FFF, 0x7FFF, 0xFFFF }; output( code ) code_int code; { cur_accum &= masks[ cur_bits ]; if( cur_bits > 0 ) cur_accum |= ((long)code << cur_bits); else cur_accum = code; cur_bits += n_bits; while( cur_bits >= 8 ) { char_out( (unsigned int)(cur_accum & 0xff) ); cur_accum >>= 8; cur_bits -= 8; } /* * If the next entry is going to be too big for the code size, * then increase it, if possible. */ if ( free_ent > maxcode || clear_flg ) { if( clear_flg ) { maxcode = MAXCODE (n_bits = g_init_bits); clear_flg = 0; } else { n_bits++; if ( n_bits == maxbits ) maxcode = maxmaxcode; else maxcode = MAXCODE(n_bits); } } if( code == EOFCode ) { /* * At EOF, write the rest of the buffer. */ while( cur_bits > 0 ) { char_out( (unsigned int)(cur_accum & 0xff) ); cur_accum >>= 8; cur_bits -= 8; } flush_char(); fflush( g_outfile ); if( ferror( g_outfile ) ) writeerr(); } } /* * Clear out the hash table */ cl_block () /* table clear for block compress */ { cl_hash ( (count_int) hsize ); free_ent = ClearCode + 2; clear_flg = 1; output( (code_int)ClearCode ); } cl_hash(hsize) /* reset code table */ register count_int hsize; { register count_int *htab_p = htab+hsize; register long i; register long m1 = -1; i = hsize - 16; do { /* might use Sys V memset(3) here */ *(htab_p-16) = m1; *(htab_p-15) = m1; *(htab_p-14) = m1; *(htab_p-13) = m1; *(htab_p-12) = m1; *(htab_p-11) = m1; *(htab_p-10) = m1; *(htab_p-9) = m1; *(htab_p-8) = m1; *(htab_p-7) = m1; *(htab_p-6) = m1; *(htab_p-5) = m1; *(htab_p-4) = m1; *(htab_p-3) = m1; *(htab_p-2) = m1; *(htab_p-1) = m1; htab_p -= 16; } while ((i -= 16) >= 0); for ( i += 16; i > 0; i-- ) *--htab_p = m1; } writeerr() { printf( "error writing output file\n" ); exit(1); } /****************************************************************************** * * GIF Specific routines * ******************************************************************************/ /* * Number of characters so far in this 'packet' */ int a_count; /* * Set up the 'byte output' routine */ char_init() { a_count = 0; } /* * Define the storage for the packet accumulator */ char accum[ 256 ]; /* * Add a character to the end of the current packet, and if it is 254 * characters, flush the packet to disk. */ char_out( c ) int c; { accum[ a_count++ ] = c; if( a_count >= 254 ) flush_char(); } /* * Flush the packet to disk, and reset the accumulator */ flush_char() { if( a_count > 0 ) { fputc( a_count, g_outfile ); fwrite( accum, 1, a_count, g_outfile ); a_count = 0; } }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01638; 3 Oct 89 9:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28446; 3 Oct 89 8:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28201; 3 Oct 89 7:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13313; 3 Oct 89 7:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA05170; Tue, 3 Oct 89 03:29:09 -0700 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 Oct 89 08:01:33 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Program to convert GIF image files to IRIS image file format Message-Id: <42453@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* * fromgif - * convert a GIF file into an IRIS image file. * * I hereby place this program * in the public domain, i.e. there are no * copying restrictions of any kind. * * based on a GIF file reader by Marcel J.E. Mol March 23 1989 * * Paul Haeberli @ Silicon Graphics - 1989 * * To compile use: * * cc -I/usr/include/gl fromgif.c -o fromgif -limage * */ #include "image.h" short rbuf[4096]; short gbuf[4096]; short bbuf[4096]; #define COLSIZE 256 unsigned char *stackp; unsigned int prefix[4096]; unsigned char suffix[4096]; unsigned char stack[4096]; int datasize,codesize,codemask; /* Decoder working variables */ int clear,eoi; /* Special code values */ int avail, oldcode; FILE *infile; int global; /* Is there a global color map? */ int globalbits; /* Number of bits of global colors */ unsigned char globalmap[COLSIZE][3];/* RGB values for global color map */ char bgcolor; /* background color */ unsigned char *raster; /* Decoded image data */ unsigned int width, height; unsigned char red[COLSIZE]; unsigned char green[COLSIZE]; unsigned char blue[COLSIZE]; char *filename, *imagename; main(argc,argv) int argc; char *argv[]; { extern int optind; extern char *optarg; int flag; if(argc<2) { fprintf(stderr,"usage: fromgif image.gif image.rgb\n"); exit(1); } filename = argv[1]; imagename = argv[2]; if ((infile = fopen(filename,"r")) == NULL) { perror(filename); exit(1); } convert(); fclose(infile); exit(0); } convert() { char ch; if (checksignature()) return; readscreen(); while ((ch = getc(infile)) != ';' && ch != EOF) { switch (ch) { case '\0': break; /* this kludge for non-standard files */ case ',': if (readgifimage()) return; break; case '!': readextension(); break; default: fprintf(stderr, "illegal GIF block type\n"); return; break; } } } checksignature() { char buf[6]; fread(buf,1,6,infile); if (strncmp(buf,"GIF",3)) { fprintf(stderr, "file is not a GIF file\n"); return 1; } if (strncmp(&buf[3],"87a",3)) { fprintf(stderr, "unknown GIF version number\n"); return 1; } return 0; } /* * readscreen - * Get information which is global to all the images stored * in the file */ readscreen() { unsigned char buf[7]; unsigned int screenwidth; /* The dimensions of the screen */ unsigned int screenheight; /* (not those of the image) */ unsigned int rscreenwidth; /* The dimensions of the raster */ fread(buf,1,7,infile); screenwidth = buf[0] + (buf[1] << 8); rscreenwidth = screenwidth + screenwidth%2; /* compensate odd widths */ screenheight = buf[2] + (buf[3] << 8); global = buf[4] & 0x80; if (global) { globalbits = (buf[4] & 0x07) + 1; fread(globalmap,3,1< 0; count = getc(infile)) { fread(buf,1,count,infile); for (ch=buf; count-- > 0; ch++) { datum += *ch << bits; bits += 8; while (bits >= codesize) { code = datum & codemask; datum >>= codesize; bits -= codesize; if (code == eoi) { /* This kludge put in */ #ifdef DEBUG fprintf(stderr, "found eoi code\n"); #endif goto exitloop; /* because some GIF files*/ } /* aren't standard */ if (process(code, &fill)) { goto exitloop; } } } if (fill >= raster + width*height) { fprintf(stderr, "raster full before eoi code\n"); goto exitloop; } } exitloop: if (fill != raster + width*height) { fprintf(stderr, "warning: wrong rastersize: %ld bytes\n", (long) (fill-raster)); fprintf(stderr, " instead of %ld bytes\n", (long) width*height); return 0; /* can still draw a picture ... */ } return 0; } /* * process - * Process a compression code. "clear" resets the code table. * Otherwise make a new code table entry, and output the bytes * associated with the code. */ process(code, fill) register code; unsigned char **fill; { int incode; static unsigned char firstchar; if (code == clear) { codesize = datasize + 1; codemask = (1 << codesize) - 1; avail = clear + 2; oldcode = -1; return 0; } if (oldcode == -1) { *(*fill)++ = suffix[code]; firstchar = oldcode = code; return 0; } if (code > avail) { fprintf(stderr, "code % d to large for %d\n", code, avail); return 1; } incode = code; if (code == avail) { /* the first code is always < avail */ *stackp++ = firstchar; code = oldcode; } while (code > clear) { *stackp++ = suffix[code]; code = prefix[code]; } *stackp++ = firstchar = suffix[code]; prefix[avail] = oldcode; suffix[avail] = firstchar; avail++; if (((avail & codemask) == 0) && (avail < 4096)) { codesize++; codemask += avail; } oldcode = incode; do { *(*fill)++ = *--stackp; } while (stackp > stack); return 0; } /* * initcolors - * Convert a color map (local or global) to arrays with R, G and B * values. Pass colors to SUNVIEW and set the background color. * */ initcolors(colormap, ncolors, bgcolor) unsigned char colormap[COLSIZE][3]; int ncolors; int bgcolor; { register i, k; for (i = 0; i < ncolors; i++) { red[i] = colormap[i][0]; green[i] = colormap[i][1]; blue[i] = colormap[i][2]; } } /* * rasterize - * Read a row out of the raster image and write it to the screen * */ rasterize(interleaved, raster) int interleaved; register unsigned char *raster; { register row, col; register unsigned char *rr; unsigned char *newras; IMAGE *image; #define DRAWSEGMENT(offset, step) \ for (row = offset; row < height; row += step) { \ rr = newras + row*width; \ bcopy(raster, rr, width); \ raster += width; \ } if ((newras = (unsigned char*) malloc(width*height)) == NULL) { fprintf(stderr, "not enough memory for image\n"); return 1; } rr = newras; if (interleaved) { DRAWSEGMENT(0, 8); DRAWSEGMENT(4, 8); DRAWSEGMENT(2, 4); DRAWSEGMENT(1, 2); } else DRAWSEGMENT(0, 1); image = iopen(imagename,"w",RLE(1),3,width,height,3); if(!image) { fprintf(stderr,"fromgif: can't open output image %s\n",imagename); exit(1); } rastertoimg(newras,image,width,height); iclose(image); free(newras); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10108; 3 Oct 89 20:19 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10051; 3 Oct 89 20:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10008; 3 Oct 89 19:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01974; 3 Oct 89 18:57 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06363; Tue, 3 Oct 89 12:42:24 -0700 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 Oct 89 19:05:00 GMT From: Jim Bennett Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: X Windows performance on PI Message-Id: <42473@sgi.sgi.com> References: <14134@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <14134@shamash.cdc.com>, pwp@shamash.cdc.com ( HOUFAC) writes: > Does anyone know how the Turbo Graphics option affects X-windows performance > on a Personal IRIS? (For applications running locally -- not across a network.) > > I'm already planning a 20MHz CPU upgrade -- any idea how much that'll help? > Is X CPU-bound or graphics-bound?? > > Thanks! --Pete Poorman I haven't benchmarked this, so I can't give you a precise answer. In general, the CPU speedup will give you the greatest boost in performance. The Turbo graphics upgrade will help out applications that are drawing lots of lines or small polygons. Large polygons are slightly improved. Jim Bennett (bennett@esd.sgi.com)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11418; 4 Oct 89 3:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11253; 4 Oct 89 2:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11199; 4 Oct 89 2:35 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05005; 4 Oct 89 0:27 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04410; Tue, 3 Oct 89 20:36:18 -0700 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 Oct 89 17:51:02 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: GIF file converter Message-Id: <771@odin.SGI.COM> References: <125@suntc.UUCP>, <8909292050.aa11265@SMOKE.BRL.MIL>, <42429@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <125@suntc.UUCP>, jh34607@suntc.UUCP (john howell) writes: > Fantastic!! Now .. does anyone have a "tosun" program to move Iris > imagefiles to a Sun Rasterfile format? It's in 4Dgifts, called tonews. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!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 ab11675; 4 Oct 89 5:30 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11537; 4 Oct 89 5:11 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa11526; 4 Oct 89 4:50 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa06249; 4 Oct 89 4:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27550; Tue, 3 Oct 89 10:24:09 -0700 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 Oct 89 16:42:07 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Optical disks for the IRIS... Message-Id: <42458@sgi.sgi.com> References: <8910022156.AA16481@trouble.cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910022156.AA16481@trouble.cs.nps.navy.mil>, zyda@TROUBLE.CS.NPS.NAVY.MIL (michael zyda) writes: > > I hear that the Introl Company has optical disks that can be plugged > into a SCSI interface on the IRIS. Does anyone have any experience > with these drives? Are there other manufacturers that provide > optical drives for the IRIS? Does SGI have plans for providing > such a capability (and by when)? > > Thank you for any responses. > > Michael Zyda This was brought up here before. Let me reiterate the information from that discussion; 1)Introl has announced such a product. 2)SGI was not involved with the development or testing. 3)There are reports that this product does not work correctly/reliably. 4)SGI does not endorse this product in any way, shape or form. 5)Your SGI salesperson DOES have a list of 3rd party suppliers that may be able to help you. (Products from vendors on this list have presumably been blessed in some manner by SGI.) 6)SGI does not sell a WORM, and probably won't unless there is sufficient customer demand to warant such product development internally. There are 3rd party suppliers for WORM. 7)SGI does not yet sell or support MO drives (erasable optical). markb -- Mark Bradley "Faster, faster, until the thrill of IO Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12223; 4 Oct 89 7:03 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11995; 4 Oct 89 6:52 EDT Received: by VMB.BRL.MIL id aa11989; 4 Oct 89 6:35 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa11716; 4 Oct 89 5:46 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa05931; 4 Oct 89 3:45 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16509; Tue, 3 Oct 89 15:32:08 -0700 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 Oct 89 22:30:18 GMT From: Timothy H Smith Organization: University of Akron, Ohio Subject: Multi-processing on SGI 4D/240 Message-Id: <64483@tut.cis.ohio-state.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello all, I am looking for a good intro to multi-processing on the SGI 4D/240 soon to be a 4D/280. I need a good intro using C and Fortran. I haved looked through the manuals that came with the machine and there pertty bad. Any ideas of where I can get some good info will be of great help. Timothy Smith Timothy Smith Univ of Akron tim@VAX1.CC.UAKRON.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14506; 4 Oct 89 9:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14032; 4 Oct 89 9:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13845; 4 Oct 89 9:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06659; 4 Oct 89 4:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16515; Tue, 3 Oct 89 07:14:31 -0700 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 Oct 89 13:20:28 GMT From: john howell Organization: Deere & Co. Technical Center, Moline,IL Subject: Re: GIF file converter Message-Id: <125@suntc.UUCP> References: <8909292050.aa11265@SMOKE.BRL.MIL>, <42429@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <42429@sgi.sgi.com>, paul@manray.sgi.com (Paul Haeberli) writes: > > /* > * fromsun.c - > * convert a sun image file to Iris format. > * Fantastic!! Now .. does anyone have a "tosun" program to move Iris imagefiles to a Sun Rasterfile format?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16122; 4 Oct 89 10:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15653; 4 Oct 89 10:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15398; 4 Oct 89 10:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06007; 4 Oct 89 3:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA20050; Tue, 3 Oct 89 16:30:11 -0700 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 Oct 89 23:13:38 GMT From: George Hartzell Organization: University of Colorado, Boulder Subject: Help booting a 2400Turbo from tape. Message-Id: <12349@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I haver recently been called on to try to resuscitate an IRIS 2400Turbo that has (once again) munched its disks. I used to be primary care provider for this machine when it was a lowly IRIS 2400. While I was caring for it I made several (3) bootable tapes, and used them several times to rebuild the machine from scratch. The sequence went something like: tb mdfex ( to boot the md formatter/exerciser) Z ( enter a security password) xxxxx ( stupid password :)) t ( tape to disk copy) 2 ( second file on tape) 0 ( md 0) g ( partition g, the boot area) go ( do it) t ( tape to disk copy) 3 ( third file on tape) 0 ( md 0) a ( partition a, the root partition) go ( do it) When I tried to go through this sequence on the now upgraded machine, I found that it seems to have a new monitor. The command that loads mdfex from the bootable tape seems to be: b ct.0:mdfex The password stuff still works. When I went to use the "t20ggo" sequence it reported copying 0 blocks to md0g. This worried me, but I continued on. The "t20ago" sequence reported copying some larger number of blocks, and actually printed a sequence of "5 10 15 ... 40" as it worked. Now when I tried to boot the machine, using the good old "b" it informed me that it couldn't find "defaultboot". It seems that the "t20ggo" not only didn't copy anything, but actually zapped what used to be there. The OS that we have been running is apparently GL2/W3.5. There are roms on the cpu board labelled IP2/3.0.7, and most of the labelled chips have some label on them which reads IP2something. So, I have two questions. 1. Are my old (3.5 from an IRIS 2400) bootable tapes any good? If so, can someone tell me what has changed about the rebuilding procedure. 2. If I need a new bootable tape, can someone out there help me? (oh yeah, did I mention that the machine *isn't* under maintenance...). It seems that there shouldn't be a licensing problem, since we own the machine and the system, our problem is just that the dealer who we bought it from didn't bother to give us the tools that we need to solve such problems, and the people who were maintaining the machine weren't informed of the need for a set of bootable tapes. If you reply to this via e-mail, please also send a copy to marvil@boulder.colorado.edu, since she is the most heavily impacted user, and would like to keep up with what is happening. I will be out of town until Thurs, 10-12-89, but someone will be watching this newsgroup for me. THANKS. g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22216; 4 Oct 89 18:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20499; 4 Oct 89 16:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20481; 4 Oct 89 15:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20683; 4 Oct 89 13:55 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19022; Wed, 4 Oct 89 10:38:06 -0700 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 Oct 89 17:22:50 GMT From: Paul Connally Organization: University of Colorado, Boulder Subject: noborder(), fudg(), and VME bus Message-Id: <12376@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL ----- Has anyone had strange results on a PI using the function "noborder()"? It seems to change the given postion of a window when using "prefposition()". What I'm doing is to get the coordinates of a window using getorigin() and getsize() then closing the window and opening a new one after a call to prefposition, ............. getorigin(&x, &y); getsize(&xsize, &ysize); winclose(gid); prefposition(x, x+xsize-1, y, y+ysize-1); gid = winopen(); .............. I do this everytime I receive a REDRAW token and each time the x postion is one greater and the y postion is one smaller. Also, with noborder, everytime I use the middle mouse button or the Move command from the managers menu with the right button to move the window it places a REDRAW token on the queue even if I don't move the window at all (I hold the button down while the mouse is off the pad to assure that my hand doesn't move it on accident). This doesn't occure if I don't use noborder(), a REDRAW token only appears if I move the window. ----- Does fudge() do anything? It doesn't seem to be enlarging the window at all. I've called it before and after winopen() and used winconstraints() and also used winpostion() to see if the window is enlarged. And yes, I've checked after resaphing the viewport. ----- I've been told not to mess with this one but..Can anyone tell me how to read and write the bus directly. I need to talk to some boards connected to it. I know their base addresses and what positons to write and read to access them but I'm not sure what to do to get to them. I don't want to go mucking about without knowing EXACTLY what to do. TIA,   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22568; 4 Oct 89 20:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22427; 4 Oct 89 19:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22400; 4 Oct 89 19:25 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00638; 4 Oct 89 17:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03249; Wed, 4 Oct 89 14:36:23 -0700 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 Oct 89 21:17:06 GMT From: Roy Smith Organization: Public Health Research Institute, NYC, NY Subject: Using a Personal Iris (4D/25S) as a timesharing machine Message-Id: <4029@phri.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We're considering getting a 16-Mbyte 4D/25S to use as a general purpose time sharing box (to replace an old Vax-11/750). We're looking for something which can support about 10-15 simultaneous users doing a random mix of generic non-floating-point stuff (emacs, big bib/tbl/eqn/troff jobs, etc) mostly coming in via telnet connections. We also expect to use it as a server for a variety of network services, such as a domain name server, yp server, nntp, nfs, mail, and as a line printer spooler. I suspect I/O performance will be more of a concern than raw CPU speed. Has anybody put a 4D/25S to this type of use? Are there any hidden problems I should know about? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23058; 4 Oct 89 23:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22929; 4 Oct 89 22:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22805; 4 Oct 89 22:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02655; 4 Oct 89 19:53 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09867; Wed, 4 Oct 89 16:22:10 -0700 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 Oct 89 22:38:58 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Optical disks for the IRIS... Message-Id: <42530@sgi.sgi.com> References: <8910022156.AA16481@trouble.cs.nps.navy.mil>, <42458@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <42458@sgi.sgi.com>, markb@denali.sgi.com (Mark Bradley) writes: > In article <8910022156.AA16481@trouble.cs.nps.navy.mil>, zyda@TROUBLE.CS.NPS.NAVY.MIL (michael zyda) writes: > > > > I hear that the Introl Company has optical disks that can be plugged > > into a SCSI interface on the IRIS. Does anyone have any experience > > with these drives? Are there other manufacturers that provide > > optical drives for the IRIS? Does SGI have plans for providing > > such a capability (and by when)? > > > > Thank you for any responses. > > > > Michael Zyda > > This was brought up here before. Let me reiterate the information from that > discussion; > > 1)Introl has announced such a product. > > 2)SGI was not involved with the development or testing. > > 3)There are reports that this product does not work correctly/reliably. > > 4)SGI does not endorse this product in any way, shape or form. > > 5)Your SGI salesperson DOES have a list of 3rd party suppliers that > may be able to help you. (Products from vendors on this list have > presumably been blessed in some manner by SGI.) > > 6)SGI does not sell a WORM, and probably won't unless there is > sufficient customer demand to warant such product development > internally. There are 3rd party suppliers for WORM. > > 7)SGI does not yet sell or support MO drives (erasable optical). > Let me clarify item #3 above; I have heard such reports, but can not substantiate them, as SGI engineering has not had first hand experience with this product, as per item #2 above. Your best bet is to try it if you can't wait for SGI's offering of such a product. As previously posted, SGI has not announced such a product, so it's your choice. Good luck. 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 aa23814; 5 Oct 89 1:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23558; 5 Oct 89 0:22 EDT Received: from [192.5.23.3] by VMB.BRL.MIL id aa23341; 5 Oct 89 0:02 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26820; 4 Oct 89 16:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24932; Wed, 4 Oct 89 12:19:03 -0700 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 Oct 89 19:04:01 GMT From: john howell Organization: Deere & Co. Technical Center, Moline,IL Subject: Re: GIF file converter Message-Id: <128@suntc.UUCP> References: <125@suntc.UUCP>, <8909292050.aa11265@SMOKE.BRL.MIL>, <771@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <771@odin.SGI.COM>, msc@ramoth.esd.sgi.com (Mark Callow) writes: > In article <125@suntc.UUCP>, jh34607@suntc.UUCP (john howell) writes: > > Fantastic!! Now .. does anyone have a "tosun" program to move Iris > > imagefiles to a Sun Rasterfile format? > > It's in 4Dgifts, called tonews. > > -- > From the TARDIS of Mark Callow > msc@ramoth.sgi.com, ...{ames,decwrl,sun}!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." I am aware that "tonews" exists, but I want to make Sun raster files that can be used on pre-NeWS suns (like pretty much all of them). Isn't the native Sun raster image file format a different beast than NeWS?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02039; 6 Oct 89 7:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01791; 6 Oct 89 7:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01773; 6 Oct 89 6:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01657; 6 Oct 89 6:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02943; Fri, 6 Oct 89 03:11:04 -0700 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 Oct 89 15:55:37 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: X Windows performance on PI Message-Id: <594@voodoo.UUCP> References: <14134@shamash.cdc.com>, <42473@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <42473@sgi.sgi.com> bennett@galois.esd.sgi.com (Jim Bennett) writes: >The Turbo graphics upgrade will help out applications that are drawing lots >of lines or small polygons. Large polygons are slightly improved. How about picking? The reason I ask is we were planning on getting the GT upgrade for our 4D/70's, but discovered that picking was significantly slower with the GT upgrade (6 times slower with 3.0, 2 times slower with 3.1 -- we have 3.2 but have not ran our benchmarks yet). Now we have lots of 4D/20's that our users want to upgrade. Will the turbo upgrade slow picking down? -- Mike York Boeing Computer Services, Renton, Washington (206) 234-7724 uw-beaver!ssc-vax!voodoo!zombie   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02136; 5 Oct 89 13:16 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00572; 5 Oct 89 12:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00332; 5 Oct 89 11:51 EDT Received: from ANCHOR.RUTGERS.EDU by SMOKE.BRL.MIL id aa12505; 5 Oct 89 10:46 EDT Date: 5 Oct 89 10:09:00 EDT From: "Tim Stearns, MBCL" Subject: Prolog on an Iris? To: info-iris Message-ID: <8910051046.aa12505@SMOKE.BRL.MIL> Does anyone know of a version of Prolog that runs on an Iris (4D series)? Any advice is welcome -- Tim Stearns stearns@biovax.rutgers.edu Bitnet: stearns@biovax   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03692; 5 Oct 89 14:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01280; 5 Oct 89 12:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01161; 5 Oct 89 12:36 EDT Received: from pitbull.nrl.navy.mil by VGR.BRL.MIL id aa02445; 5 Oct 89 12:33 EDT Received: by pitbull.nrl.navy.mil (5.57/Ultrix2.4-C) id AA03491; Thu, 5 Oct 89 12:31:39 EDT Date: Thu, 5 Oct 89 12:31:39 EDT From: Kevin Russo Message-Id: <8910051631.AA03491@pitbull.nrl.navy.mil> To: info-iris@vgr.brl.mil Subject: iris archives hi Where are the info-iris archives stored on the net? The one on vgr.brl.mil seems to be dormant. thanks, kevin russo russo@pitbull.nrl.navy.mil (128.60.7.43)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08387; 5 Oct 89 17:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06897; 5 Oct 89 16:33 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06770; 5 Oct 89 16:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19187; 5 Oct 89 15:07 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12111; Thu, 5 Oct 89 11:40:48 -0700 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 Oct 89 17:13:15 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Virtual Memory (Was: Disappearing debug) Message-Id: <42572@sgi.sgi.com> References: <492@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <492@dftsrv.gsfc.nasa.gov>, buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: > All of this discussion brings back a question I have had for a while, and > that is: > > How do you tell how much virtual (and real) memory a given > process is using? > > B Cing U > > Buck > > Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer > CSC, 1100 West St. | uucp: ...!ames!dftsrv!drax!buck | "By the horns of a > Laurel, MD 20707 | phonenet: (301) 497-2531 or 9898 | sky demon..." The 'ps -l' command shows the process size and resident set size for processes. The man page has all the detail, but please examine the SZ:RSS field. The numbers take the format 'n:m', where 'n' is the virtual size of the process (in pages), and 'm' is the number of pages actually residing in memory. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08726; 5 Oct 89 18:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08563; 5 Oct 89 18:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08436; 5 Oct 89 17:48 EDT Received: from NWC.NAVY.MIL by SMOKE.BRL.MIL id aa22396; 5 Oct 89 16:47 EDT Date: 5 Oct 89 13:40:00 PDT From: "FIDLER::LEVINE" Subject: Problem reading foreign TAR tapes To: info-iris Message-ID: <8910051647.aa22396@SMOKE.BRL.MIL> I am vax cluster system manager with a user who just got a Silicon Graphics IRIS 4D/240GTX running IRIX (AT&T System V with BSD Extentions) V3.1 . He wants to be able to exchange data between his computer and my cluster useing mag-tapes. I used the TARWRITE program supplied in the Spring 89 VAX/L&T SIG Tape VAX000.TOOLS directory to build a tar tape, but he is unable to read it even useing the command dd | tar . . . is there anything else to try on the VAX or Silicon Graphics to be able to produce a readable tar tape, or is there a way on the Silicon Graphics to read/write blocked tapes? Please respond directly as I do not get the INFO-IRIS conference. Michael N. LeVine Naval Weapons Center, China Lake, Ca 93555, USA Internet: levine%fidler.decnet@nwc.navy.mil,levine%fidler.decnet@26.3.0.85 (619) 939-2614 avn 437-2614   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08936; 5 Oct 89 18:54 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08842; 5 Oct 89 18:43 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08808; 5 Oct 89 18:32 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23546; 5 Oct 89 17:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22984; Thu, 5 Oct 89 14:41:09 -0700 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 Oct 89 20:41:51 GMT From: "Frank J. Henigman" Organization: U of Waterloo, Ontario Subject: Passing floats - Is this a bug? Message-Id: <11787@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Take a look at the following program. ------------------------------------------------------------------ bar(x) float *x; { printf("bar: %f\n", *x); } foo(x) float x; { printf("foo: %f\n", x); bar(&x); } main() { float x = 1.0; foo(x); } ------------------------------------------------------------------ Here is the output of this program compiled and run on a 4D/120GTX with 3.1G foo: 1.000000 bar: 1.875000 You get the same thing EVEN IF COMPILED WITH -float. Compile it with gcc and you get: foo: 1.000000 bar: 1.000000 -- fjhenigman@watcgl.uwaterloo.ca Computer Graphics Lab fjhenigman@watcgl.waterloo.edu Frank J. Henigman University of Waterloo ...!watmath!watcgl!fjhenigman Waterloo, Ontario, Canada -- fjhenigman@watcgl.uwaterloo.ca Computer Graphics Lab fjhenigman@watcgl.waterloo.edu Frank J. Henigman University of Waterloo ...!watmath!watcgl!fjhenigman Waterloo, Ontario, Canada   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09070; 5 Oct 89 19:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08563; 5 Oct 89 18:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08486; 5 Oct 89 17:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22744; 5 Oct 89 17:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA20118; Thu, 5 Oct 89 13:52:30 -0700 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 Oct 89 20:32:00 GMT From: Michael Piplani Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Re: Optical disks for the IRIS... Message-Id: <9007@batcomputer.tn.cornell.edu> References: <8910022156.AA16481@trouble.cs.nps.navy.mil>, <42458@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In late August I posted that we were getting the INTROL read/write optical disk drive for our personal iris. Sad to say it worked for a weekend, then one of our programs crashed the pi reading a file off the disk (it was the programs fault/not the disks). Everytime I ran fsck on the disk, more and more errors would be found, until it got so bad I couldn't mount the disk. I then tried to reformat the disk ,recreate a file system, run a fsck on the new file system, and then mount it. Every time I ran fsck I would get hundreds of errors, and was never able to mount the disk. Our site was the first personal iris that Introl had installed one of their disks. I understand (from them) that the disk drive is quite robust on the higher end 4d's. It would be nice if someone could confirm that for us. On the whole the installation was very easy. I've been told that they are working on their driver so it will handle the personal iris. One thing that is not made perfectly clear in their adds is that the drive has only one head, so to get the maximum capacity from the optical disk you have to unmount it, flip it over, and remount. The key spec. is that you get 270+Meg a side, formatted. I do hope they get it fixed, because I don't know of another read/write many time optical disk for the IRIS (I've seen adds that TRIMARCHI makes a read/write disk for the vax using the same SONY engine.). Michael Piplani Cornell/Hospital for Special Surgery Program in Biomechanical Engineering piplani@tcgould.tn.cornell.edu piplani@crnlimap.bitnet (607)255-0990   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00236; 6 Oct 89 1:57 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09417; 5 Oct 89 20:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09381; 5 Oct 89 20:39 EDT Received: from orville.nas.nasa.gov by SMOKE.BRL.MIL id aa24945; 5 Oct 89 20:05 EDT Received: Thu, 5 Oct 89 17:01:45 PDT by orville.nas.nasa.gov (5.59/1.2) Date: Thu, 5 Oct 89 17:01:45 PDT From: Dave Tristram Message-Id: <8910060001.AA18864@orville.nas.nasa.gov> To: info-iris@BRL.MIL, watmath!watcgl!fjhenigman@iuvax.cs.indiana.edu Subject: Re: Passing floats - Is this a bug? > Here is the output this program compiled and run on a 4D/120GTX with 3.1G > > foo: 1.000000 > bar: 1.875000 > > try declaring the parameters as doubles. I've had problems using the ansi style declarations like foo( float ) has something to do with automatic promotion of arguments, etc...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00841; 6 Oct 89 2:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00467; 6 Oct 89 2:14 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa00414; 6 Oct 89 2:04 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa04012; 5 Oct 89 23:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11202; Thu, 5 Oct 89 19:58:29 -0700 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 Oct 89 01:05:53 GMT From: pa1081 Organization: Univ. of California, San Diego Subject: Info on Personal IRIS Message-Id: <1255@sdcc13.ucsd.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need very basic information about SGI's Personal IRIS for the purposes of Image Processing and Display, general number crunching, timesharing and software development. We may be buying many in the future and we will need to know the opinions of people who have used them. Any comments you can spare will be appreciated. Please reply to: Steve Diggs: UUCP:{uunet,ucsd}!photon!steve Thanks in Advance, Steve Photon Research Associates, Inc. San Diego, CA UUCP:{suntan,ucsd,uunet}!photon!steve   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07026; 6 Oct 89 12:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06596; 6 Oct 89 12:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06493; 6 Oct 89 12:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08265; 6 Oct 89 11:07 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18920; Fri, 6 Oct 89 08:02:55 -0700 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 Oct 89 22:08:23 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: GIF file converter Message-Id: <822@odin.SGI.COM> References: <125@suntc.UUCP>, <8909292050.aa11265@SMOKE.BRL.MIL>, <771@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <128@suntc.UUCP>, jh34607@suntc.UUCP (john howell) writes: > I am aware that "tonews" exists, but I want to make Sun raster files > that can be used on pre-NeWS suns (like pretty much all of them). Isn't > the native Sun raster image file format a different beast than NeWS? As far as I'm aware, they are the same. We certainly use the same rasterfile.h file that is (or was when we received the source code) shipped with SunOS/SunWindows. If tonews has a limitation it's that it only knows how to make .im8 files. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!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 ab00659; 6 Oct 89 2:30 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00467; 6 Oct 89 2:19 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ae00414; 6 Oct 89 2:05 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa04954; 6 Oct 89 0:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16134; Thu, 5 Oct 89 21:31:39 -0700 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 Oct 89 04:05:53 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Problem reading foreign TAR tapes Message-Id: <42613@sgi.sgi.com> References: <8910051647.aa22396@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910051647.aa22396@SMOKE.BRL.MIL>, levine%fidler.decnet@NWC.NAVY.MIL ("FIDLER::LEVINE") writes: > > I am vax cluster system manager with a user who just got a > Silicon Graphics IRIS 4D/240GTX running IRIX (AT&T System V with > BSD Extentions) V3.1 . He wants to be able to exchange data between his > computer and my cluster useing mag-tapes. I used the TARWRITE program > supplied in the Spring 89 VAX/L&T SIG Tape VAX000.TOOLS directory to > build a tar tape, but he is unable to read it even useing the command > > dd | tar . . . > > is there anything else to try on the VAX or Silicon Graphics to be able > to produce a readable tar tape, or is there a way on the Silicon Graphics > to read/write blocked tapes? > > Please respond directly as I do not get the INFO-IRIS conference. > > Michael N. LeVine Naval Weapons Center, China Lake, Ca 93555, USA > Internet: levine%fidler.decnet@nwc.navy.mil,levine%fidler.decnet@26.3.0.85 > (619) 939-2614 avn 437-2614 IRISes and VAXen typically create tapes with different byte ordering. For your dd | tar try: dd conv=swab | tar . . . The conv=swab selects byte swapping in dd. -- ------------------------------------------------------------------------------- Cosmo Ciemo, Silicon Valley Dude I was traipsing through the fields of my mind when I stepped in something that smelled rather ripe. -------------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01006; 6 Oct 89 3:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00951; 6 Oct 89 3:36 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00930; 6 Oct 89 3:24 EDT Received: from vmb.brl.mil by VGR.BRL.MIL id aa00935; 6 Oct 89 2:50 EDT Date: Fri, 6 Oct 89 2:40:23 EDT From: Chuck Kennedy To: Kevin Russo cc: info-iris@vgr.brl.mil Subject: Re: iris archives Message-ID: <8910060240.aa00725@VMB.BRL.MIL> Sorry about the staleness of the archives. I will see to updating them in the next week or so. I had meant to do this earlier but have been swamped with several major procurement action. I just had eight 4D/280S with 64 1.2GB drives plus twelve 4D/240GTXB with 48 380MB drives drop on me this week. I'm looking forward to some fun. -Chuck   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02098; 6 Oct 89 7:21 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01791; 6 Oct 89 7:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab01773; 6 Oct 89 6:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01664; 6 Oct 89 6:21 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02903; Fri, 6 Oct 89 03:10:27 -0700 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 Oct 89 08:59:32 GMT From: Ramani Pichumani Organization: Stanford University Computer Science Department Subject: X11 toolkits Message-Id: <12223@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am currently in the process of searching for a application level toolkit for X11 on the Iris 4D. The software we are writing is intended to be used by surgeons who know very little about computers and want to know even less. The software is very complex but the user interface must be kept as simple as possible. For instance, a three button mouse is considered to be too complicated for our users so we have to define all the mouse buttons to be functionally identical. We would like to get a user interface (UI) toolkit that will be as easy to use as those found on the MacIntosh or Next computers. I have found the UI objects in ForeSight to be too buggy, hard to debug and unsupported. Also, the cps packet communication scheme proved to be hard to incorporate into our object models in Lisp. I found the XView toolkit from Sun to fit my requirements very nicely. Unfortunately, XView is only supported on Sun machines and is only intended to be ported to BSD machines or System V Release 4 (SVR4) machines. That leaves me in the position of trying to port XView to the Iris 4D or find an existing toolkit for our application. If anyone out there knows of a X11 UI toolkit to meet our requirements, please let me know. Hopefully I'll get enough replies to summarize them on the net. Thanks in advance, Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06280; 6 Oct 89 12:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05990; 6 Oct 89 11:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05968; 6 Oct 89 11:40 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07417; 6 Oct 89 10:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16937; Fri, 6 Oct 89 07:24:57 -0700 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 Oct 89 13:12:16 GMT From: Michael Piplani Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Re: Optical disks for the IRIS... Message-Id: <9011@batcomputer.tn.cornell.edu> References: <8910022156.AA16481@trouble.cs.nps.navy.mil>, <42458@sgi.sgi.com>, <9007@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL 5 minutes after I posted the article on our problems with the Introl optical disk on the PI, I got a call from them saying they were sending out a new controller board for the PI... Stay tuned, Michael Piplani   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07418; 6 Oct 89 13:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05990; 6 Oct 89 11:54 EDT Received: by VMB.BRL.MIL id aa05821; 6 Oct 89 11:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04532; 6 Oct 89 10:06 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa04923; 6 Oct 89 9:09 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA02029; Fri, 6 Oct 89 08:09:24 CDT Date: Fri, 6 Oct 89 08:09:24 CDT From: Mike Goss Message-Id: <8910061309.AA02029@snow-white.merit-tech.com> To: info-iris@BRL.MIL Subject: Re: Passing floats - Is this a bug? In reply to: > Date: 5 Oct 89 20:41:51 GMT > From: "Frank J. Henigman" > Organization: U of Waterloo, Ontario > Subject: Passing floats - Is this a bug? > > Take a look at the following program. > . . . > > Here is the output of this program compiled and run on a 4D/120GTX with 3.1G > > foo: 1.000000 > bar: 1.875000 > > You get the same thing EVEN IF COMPILED WITH -float. > > > Compile it with gcc and you get: > > foo: 1.000000 > bar: 1.000000 > > -- > fjhenigman@watcgl.uwaterloo.ca Computer Graphics Lab > fjhenigman@watcgl.waterloo.edu Frank J. Henigman University of Waterloo > ...!watmath!watcgl!fjhenigman Waterloo, Ontario, Canada This is due to an ambiguity in the C language regarding passing parameters of type "float". If you don't use an ANSI style function prototype, C promotes all floating point function arguments to type "double". Therefore, you can never really get a function argument of type "float". There are two schools of thought among compiler writers on handling this problem. Some (shown by your first example on the IRIX C compiler) assume that if you declare an argument as "float" that you really meant "double". Others (such as gcc) assume that since you want a "float" argument, they should convert the "double" argument to "float". The best way around this would be to use ANSI style function prototypes for all functions; this causes the compiler to generate code to pass the argument exactly as it is declared in the prototype. The compiler does type checking of arguments and performs type conversion (for example, int to float or float to double) where possible, and issues an error message otherwise (for example, passing a pointer to a float parameter). Unfortunately, the ANSI C standard has not been finalized yet, and not all C compilers implement even the draft standard yet. The IRIX C compiler implements some of the ANSI features, including function prototypes, but not others (such as "void" pointers). ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08745; 6 Oct 89 13:59 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07860; 6 Oct 89 13:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07694; 6 Oct 89 13:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10390; 6 Oct 89 12:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23877; Fri, 6 Oct 89 09:30:42 -0700 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 Oct 89 15:54:44 GMT From: HOUFAC Organization: Control Data Corp., Arden Hills, MN Subject: "Relocation out-of-range" errors Message-Id: <14188@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A few weeks back Steve Maurer asked what caused "jump relocation out of range" errors, and someone explained it. Now, it's happening to me and the response has aged-away on my system. Can someone please explain again? (I promise to save it this time!) Also, is this stuff archived somewhere on the net? (vgr.brl.mil still isn't responding.) Thanks in advance: --Pete pwp@shamash.cdc.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09350; 6 Oct 89 14:19 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08745; 6 Oct 89 14:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08539; 6 Oct 89 13:52 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10762; 6 Oct 89 12:53 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24328; Fri, 6 Oct 89 09:38:46 -0700 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 Oct 89 16:19:12 GMT From: Vimal Parikh Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: X Windows performance on PI Message-Id: <42636@sgi.sgi.com> References: <14134@shamash.cdc.com>, <42473@sgi.sgi.com>, <594@voodoo.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <594@voodoo.UUCP>, zombie@voodoo.UUCP (Mike York) writes: > How about picking? The reason I ask is we were planning on getting the > GT upgrade for our 4D/70's, but discovered that picking was > significantly slower with the GT upgrade (6 times slower with 3.0, > 2 times slower with 3.1 -- we have 3.2 but have not ran our benchmarks yet). > > Now we have lots of 4D/20's that our users want to upgrade. Will the > turbo upgrade slow picking down? > Picking operation on Turbo PI is slightly faster than on non-turbo PI. You probably won't notice a significant increase but it will NOT be slower. Vimal Parikh MTS, Entry Systems Division. Silicon Graphics Inc. Mt. View, CA.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11646; 6 Oct 89 17:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11570; 6 Oct 89 17:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11556; 6 Oct 89 17:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16258; 6 Oct 89 16:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA07971; Fri, 6 Oct 89 13:22:14 -0700 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 Oct 89 19:50:27 GMT From: "James P. Loan" Organization: Stanford University Subject: X11 on a 2400T Message-Id: <12244@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We at the VA Medical Center would like to port X11 to our 2400T, as we wait 4-6 months for our 4D-25 to arrive. We can get the code via anonymous ftp, and the Release Notes (R3) say that a user-contributed directory contains stuff for porting to SGI machines, but we have questions before we even try to start: * Does it run on 2400's? * Does it run well? * Do we have a chance of doing it with 55 Megabytes of disk? * Do we have to be kernel experts? * Are we in over our heads just by asking these questions? -thanks in advance Peter Loan VA Medical Center Stanford University   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00691; 8 Oct 89 6:59 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00628; 8 Oct 89 6:44 EDT Received: from sem.brl.mil by VMB.BRL.MIL id ab00413; 8 Oct 89 6:21 EDT Received: from umrvma.umr.edu by SEM.BRL.MIL id aa01770; 8 Oct 89 5:59 EDT Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7727; Fri, 06 Oct 89 22:33:16 CDT Received: by UMRVMA (Mailer R2.03B) id 7726; Fri, 06 Oct 89 22:33:11 CDT Date: Fri, 06 Oct 89 22:30:32 CDT From: "Bob B. Funchess" Subject: Columbia Appletalk Protocol To: info-iris@BRL.MIL Message-ID: <8910080559.aa01770@SEM.BRL.MIL> Does anyone have the Columbia Appletalk protocols up and running on a Personal Iris or something closely resembling it? Please mail responses directly to me at the address below or S090726@UMRVMA (for those on BITNET). < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00907; 8 Oct 89 7:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00341; 8 Oct 89 6:26 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa00310; 8 Oct 89 6:11 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa01959; 6 Oct 89 23:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01886; Fri, 6 Oct 89 20:39:42 -0700 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 Oct 89 17:57:45 GMT From: "0000-Admin(0000" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Re: X11 toolkits Message-Id: <838@odin.SGI.COM> References: <12223@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL tape. It provides an interface very similar to a MacIntosh's, which sounds like what you have in mind. We had no major problems in making it work locally. bruce a. campbell baruch@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00691; 8 Oct 89 6:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00628; 8 Oct 89 6:43 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa00368; 8 Oct 89 6:16 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa07182; 7 Oct 89 21:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28902; Sat, 7 Oct 89 17:18:06 -0700 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 Oct 89 23:48:21 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: "Relocation out-of-range" errors Message-Id: <42681@sgi.sgi.com> References: <14188@shamash.cdc.com>, <28025@mips.mips.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <14188@shamash.cdc.com> pwp@shamash.UUCP (Pete Poorman) writes: >A few weeks back Steve Maurer asked what caused "jump relocation out of range" >errors, and someone explained it. > >Now, it's happening to me and the response has aged-away on my system. > >Can someone please explain again? (I promise to save it this time!) The question was answered by: len@synthesis.Synthesis.COM (Len Lattanzi) in <28025@mips.mips.COM> ;;Typically this is caused by one importing module referencing a symbol as text ;;and trying to jump to it. And the exporting module defining the symbol ;;to be data. Text and Data are normally too far apart to jump between. ;;You could use -Wl,-yerror,-yasm on the link command to indicate all ;;modules referencing error and asm and make sure the uses are consistent. Len was exactly right. Some further information: A call to a named function is generated as a JAL instruction. In the MIPS R2/3000 a JAL gets 26 bits for the address. It is a word address by definition, so the 2 least significant bits are implicit. Shifting the 26 bits from the instruction left two bits and making the top 4 bits identical to the address of the jump instruction itself gives a target address. (Wouldn't a picture be better than words? :-) In the ZMAGIC format (the format used for executables in IRIX) code starts at 0x400000 and data starts at 0x10000000. When one does a call (JAL) and the name is resolved to a _data address_ one gets ``jump relocation out of range'' since the linker can see that the top 4 bits are not the same in the JAL instruction address and the target address. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00691; 8 Oct 89 6:57 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00628; 8 Oct 89 6:43 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab00368; 8 Oct 89 6:17 EDT Received: from uunet.UU.NET by ADM.BRL.MIL id aa08125; 7 Oct 89 23:15 EDT Received: from munnari.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA22577; Sat, 7 Oct 89 22:22:47 -0400 Received: from munnari.oz.au (munnari.oz) by murtoa.cs.mu.oz (5.5) id AA13430; Sun, 8 Oct 89 12:21:26 EST (from mg@cidam.me.rmit.oz for uunet!info-iris@BRL.MIL) Received: from cidam.me.rmit.oz (via murtoa) by munnari.oz.au with SunIII (5.61+IDA+MU) id AA14842; Sun, 8 Oct 89 12:20:58 +1000 (from mg@cidam.me.rmit.oz for info-iris@BRL.MIL@murtoa.cs.mu.OZ.AU) Message-Id: <8910080220.14842@munnari.oz.au> Date: Sat, 7 Oct 89 21:45:15 EST From: "Mike A. Gigante" Received: by cidam.me.rmit.oz (5.51) id AA28285; Sat, 7 Oct 89 21:45:15 EST To: info-iris@BRL.MIL, iuvax.cs.indiana.edu!watmath!watcgl!fjhenigman@murtoa.cs.mu.oz.au Subject: Re: Passing floats - Is this a bug? yes, I have seen the same problem (in the middle of a large program) The -float doesn't help as it doesn't prevent the promotion of arguments to double, merely the promotion of expressions to double. the way to *avoid* the bug is to #define float double horrid, but it works on my program. Haven't ttried it on your test case (this machine ain't an iris) Mike Gigante, ACGL, RMIT Australia   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00691; 8 Oct 89 6:59 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00628; 8 Oct 89 6:45 EDT Received: from sem.brl.mil by VMB.BRL.MIL id ad00413; 8 Oct 89 6:22 EDT Received: from umrvma.umr.edu by SEM.BRL.MIL id aa01784; 8 Oct 89 5:59 EDT Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7818; Sat, 07 Oct 89 00:41:45 CDT Received: by UMRVMA (Mailer R2.03B) id 7817; Sat, 07 Oct 89 00:41:42 CDT Date: Sat, 07 Oct 89 00:38:37 CDT From: "Bob B. Funchess" Subject: Memory for 4D/20 & 4D/25 To: info-iris@BRL.MIL Message-ID: <8910080559.aa01784@SEM.BRL.MIL> Does anyone know of a source of memory chips for a personal Iris? (obviously SG has them, but are there other suppliers?) We have 8M and we're hitting the wall on several programs. < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00691; 8 Oct 89 6:58 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00628; 8 Oct 89 6:44 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa00401; 8 Oct 89 6:18 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa10193; 8 Oct 89 5:51 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24859; Sun, 8 Oct 89 02:38:13 -0700 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 Oct 89 08:41:39 GMT From: Ramani Pichumani Organization: Stanford University Computer Science Department Subject: saving and loading the screen on a 4D Message-Id: <12278@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here's an easy question for 4D veterans: What is the preferred method for saving the entire screen (not just a window) in a file and loading it back from a file (ie., the equivalent of screendump and screenload on the Sun's)? Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani   Received: from VMB.BRL.MIL by VMB.BRL.MIL id af00691; 8 Oct 89 7:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id af00628; 8 Oct 89 6:46 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa00546; 8 Oct 89 6:23 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa01931; 8 Oct 89 6:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA26088; Sun, 8 Oct 89 03:04:19 -0700 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 Oct 89 09:27:59 GMT From: LTH network news server Organization: Lund Institute of Technology, Sweden Subject: Dog on Iris-2300 Message-Id: <1989Oct8.092759.9980@lth.se> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody have a version of xdog (or dog) for the Iris-2300 (68010-processor) ? If so I would appreciate if you could email ( or ftp, or let me ftp or .. ) an executable to me. Any answers to this request may be emailed to bertilr@dit.lth.se Thanks. PS. I need an executable NOT the source code DS.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01157; 8 Oct 89 17:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01012; 8 Oct 89 16:32 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa00962; 8 Oct 89 16:18 EDT Received: from gatech.edu by SEM.BRL.MIL id aa04490; 8 Oct 89 16:07 EDT Received: from hydra.gatech.edu by gatech.edu (5.58/GATECH-8.6) id AA01246 for ; Sun, 8 Oct 89 15:53:25 EDT Received: by hydra.gatech.edu (4.12/2.5) id AA04925; Sun, 8 Oct 89 15:52:08 edt Date: Sun, 8 Oct 89 15:52:08 edt From: "SCHREIBER, O. A." Message-Id: <8910081952.AA04925@prism.gatech.edu> To: info-iris@BRL.MIL, sgi!shinobu!odin!dillo.wpd.sgi.com!root@ucbvax.berk Subject: f77 command Cc: ccsupos@prism.gatech.edu How does one get a listing of the FORTRAN program when using f77. Thanks Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01201; 8 Oct 89 17:40 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01157; 8 Oct 89 17:19 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa01154; 8 Oct 89 17:11 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa04756; 8 Oct 89 17:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23468; Sun, 8 Oct 89 14:00:23 -0700 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 Oct 89 20:10:00 GMT From: "John Scott McCauley Jr." Organization: Princeton University, NJ Subject: some questions about IRIS 3120 Message-Id: <10756@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, A friend of mine just acquired an IRIS 3120 workstation. Here are some questions we have (pardon us, we're new to IRIS): 1) System Software We seem to be running version 3.5 of the system. We'd like job control, if possible. Are there any more recent versions of the system around? 2) modem We'd like to set up a dial-in/dial-out modem. I could write a program to edit /etc/inittab and send signals to init -- just wondering if there was an easier way. 3) X-windows: is there a version ported to this beast? Thanks very much, Scott jsm@phoenix.princeton.edu -- Scott McCauley, jsm@phoenix.princeton.edu (INTERNET) Home: (609) 683-9065 Office: (609) 243-3312 (FTS 340-3312) Fax: (609) 243-2160 (FTS 340-2160)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac01920; 10 Oct 89 18:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00909; 10 Oct 89 18:24 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa00294; 10 Oct 89 18:05 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa16869; 6 Oct 89 19:43 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08642; Mon, 9 Oct 89 15:19:59 -0700 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 Oct 89 21:42:19 GMT From: Bill Dunlap Organization: UW Statistics, Seattle Subject: Re: "Relocation out-of-range" errors Message-Id: <2288@uw-entropy.ms.washington.edu> References: <14188@shamash.cdc.com>, <28025@mips.mips.COM>, <42681@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I dealt with the 'jump out of range' linking errors by adding to LDFLAGS -T 10000000 -D 12000000 (or the equivalent -Wl,'...' if you link through cc). to get text and data close enough. Make sure your text segment is not bigger than 0x2000000 bytes or bump up the difference a bit. This got my dynamic linking code to run.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad01920; 10 Oct 89 18:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00909; 10 Oct 89 18:24 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab00433; 10 Oct 89 18:07 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa26190; 9 Oct 89 21:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA17180; Mon, 9 Oct 89 17:54:23 -0700 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 Oct 89 23:45:35 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: saving and loading the screen on a 4D Message-Id: <42737@sgi.sgi.com> References: <12278@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12278@polya.Stanford.EDU>, ramani@patience.Stanford.EDU (Ramani Pichumani) writes: > > Here's an easy question for 4D veterans: What is the preferred method > for saving the entire screen (not just a window) in a file and loading > it back from a file (ie., the equivalent of screendump and screenload > on the Sun's)? Check out scrsave, icut, and ipaste. thant -- When things get tough, the tough get things.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae01920; 10 Oct 89 18:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00909; 10 Oct 89 18:25 EDT Received: from sem.brl.mil by VMB.BRL.MIL id ac00453; 10 Oct 89 18:08 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa16552; 9 Oct 89 17:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06184; Mon, 9 Oct 89 14:36:26 -0700 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 Oct 89 21:19:40 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: saving and loading the screen on a 4D Message-Id: References: <12278@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12278@polya.Stanford.EDU>, ramani@patience.Stanford.EDU (Ramani Pichumani) writes: > Here's an easy question for 4D veterans: What is the preferred method > for saving the entire screen (not just a window) in a file and loading > it back from a file? You can use scrsave or icut to capture a screen image and then display with the ipaste command. For example, scrsave scrdump.rgb (By default, scrsave will save the entire screen.) ipaste scrdump.rgb George Elkins   Received: from VMB.BRL.MIL by VMB.BRL.MIL id af01920; 10 Oct 89 18:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id af00909; 10 Oct 89 18:25 EDT Received: from sem.brl.mil by VMB.BRL.MIL id ad00453; 10 Oct 89 18:08 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa16554; 9 Oct 89 17:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06937; Mon, 9 Oct 89 14:49:06 -0700 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 Oct 89 21:24:35 GMT From: "0048;0000030235;500;737;56;" Organization: University of California, Davis Subject: CAP 5.0 on Iris 3130? Message-Id: <5543@ucdavis.ucdavis.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone out there in netland ported Columbia Appletalk Protocol (CAP) to an Iris 3130? I am about to try and get CAP up and running on such a machine and would appreciate any pointers or hints. Thanks. Bernard Littau VM Radiological Sciences Telephone: (916) 752-0184 School of Veterinary Medicine Internet: vmrad@ucdavis.edu University of California BITNET: vmrad@ucdavis Davis, CA 95616 UUCP: {ucbvax,lll-crg,sdcsvax}!ucdavis!vmrad Bernard Littau VM Radiological Sciences Telephone: (916) 752-0184 School of Veterinary Medicine Internet: vmrad@ucdavis.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02631; 10 Oct 89 18:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00909; 10 Oct 89 18:24 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa00453; 10 Oct 89 18:08 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa15130; 9 Oct 89 15:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27023; Mon, 9 Oct 89 12:08:25 -0700 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 Oct 89 16:55:18 GMT From: "Jeff P.M. Hultquist" Organization: NASA Ames Research Center, Moffett Field, CA Subject: Re: "Relocation out-of-range" errors Message-Id: <3366@amelia.nas.nasa.gov> References: <14188@shamash.cdc.com>, <28025@mips.mips.COM>, <42681@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > From: davea@quasar.wpd.sgi.com (David B. Anderson) > > In article <14188@shamash.cdc.com> pwp@shamash.UUCP (Pete Poorman) writes: > > > A few weeks back Steve Maurer asked what caused > > > "jump relocation out of range" errors, ... > > > Can someone please explain again? > > > > The question was answered by: > > len@synthesis.Synthesis.COM (Len Lattanzi) in <28025@mips.mips.COM> > > > ;;Typically this is caused by one importing module referencing a > > > symbol as text and trying to jump to it. And the exporting module > > > defining the symbol to be data. Text and Data are normally too > > > far apart to jump between. > > In the ZMAGIC format (the format used for executables in IRIX) code starts > at 0x400000 and data starts at 0x10000000. I ran into this problem when implemented a simple dynamic loader for the Personal Iris. The newly compiled code would be loaded into a malloc'ed chunk of memory, and the address of that block would then be treated as a pointer to a function. The way around this problem is to place Data and Text more closely together when building the application. How does one do this? cc -Wl,-D,a000000 This instructs the linker to place the Data segment lower in the address space.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag01920; 10 Oct 89 18:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag00909; 10 Oct 89 18:25 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa00590; 10 Oct 89 18:10 EDT Received: from ucbvax.Berkeley.EDU by SEM.BRL.MIL id aa21280; 10 Oct 89 9:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA25531; Tue, 10 Oct 89 06:48:15 -0700 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: 10 Oct 89 12:51:18 GMT From: Greg Gilley Organization: Numerical Design Ltd. Subject: NTP Message-Id: <141@ndl.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone successfully ported the NTP (network time protocol) daemon to IRIX? Thanks, Greg -- ------------------------------------------------------- Greg Gilley gilley@ndl.COM [Numerical Design Limited] 919-929-2917 (voice)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03011; 10 Oct 89 19:03 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02631; 10 Oct 89 18:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab02477; 10 Oct 89 18:42 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21491; 10 Oct 89 13:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06790; Tue, 10 Oct 89 10:11:40 -0700 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: 10 Oct 89 17:08:24 GMT From: Fengmin Gong Organization: Washington University, St. Louis MO Subject: Request for Information Message-Id: <1989Oct10.170824.8392@wucs1.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am interested in information on Silicon Graphics systems and development of visualization support on such platforms. Anyone who has such information please send the corresponding references to "lfg@cs1.wustl.edu", your help will be greatly appreciated. Similar information on other graphics supers such as pixar's, Ardent's and Stellar's is also welcome (but please excuse me for requesting these information from sgi group). Thanks. - larry gong Washington U. in St. Louis.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03200; 10 Oct 89 19:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03171; 10 Oct 89 19:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab03137; 10 Oct 89 19:10 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28142; 10 Oct 89 16:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19376; Tue, 10 Oct 89 13:28:18 -0700 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: 10 Oct 89 19:35:51 GMT From: Bill Lasher Organization: Penn State University Subject: Hung printer queue's Message-Id: <89283.153553W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a room full of Personal IRIS's on a network, with several plotters and printers. All machines are set up to send their plot or print files to the appropriate device over the network. The output devices are plugged into the serial or parallel port of one of the machines. Most of the time, everything works fine, but every once in awhile, the queue gets hung. If we lpstat on the machine that created the file, it shows it as currently being printed, but nothing is coming out of the printer or plotter. Any jobs sent after that just sit there. If we cancel the job that hung, the queue is freed up and everything works fine for awhile. It doesn't appear to be a specific file; if a file gets hung and we cancel it, then re-submit the same job, it works fine. We have contacted the SGI hotline, but they don't yet know what the problem is, however, they did say that someone else had reported it. Anyone else having this problem; or any ideas as to what might be causing it? Many thanks, Bill Lasher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15154; 11 Oct 89 9:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14491; 11 Oct 89 8:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14364; 11 Oct 89 8:21 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa06866; 11 Oct 89 7:45 EDT Received: Wed, 11 Oct 89 07:45:51 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 11 Oct 89 07:45:51 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910111445.AA04020@aero4.larc.nasa.gov> To: phoenix!jsm@princeton.edu Subject: Re: some questions about IRIS 3120 Cc: info-iris@BRL.MIL We have a 3130, but I think most things are the same. 1) 3.6 is the most recent version of the OS. I suggest you get it. There are several annoying bugs in 3.5. 2) I have been able to use a serial port for dialing in OR out, but not both. I don't see any way of doing both on the same serial port. When you have the port set for both the software tries to talk to itself and gets all messed up. Our manuals tell you how to set up a serial port for a modem. I suggest you use ttyf* , because this has hardware handshaking. 3) I don't know about the availability of X-windows. -- 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 aa17654; 11 Oct 89 11:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16968; 11 Oct 89 10:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16767; 11 Oct 89 10:37 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10375; 11 Oct 89 10:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18422; Wed, 11 Oct 89 06:51:57 -0700 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: 11 Oct 89 11:43:26 GMT From: Chuck Musciano Organization: Advanced Technology Dept., Harris Corp., Melbourne, Fl. Subject: Some questions... Message-Id: <2756@trantor.harris-atd.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am the proud new owner of a 4D/50GTB, and have been having lots of fun coming up to speed writing graphics code. Here are some general questions I have which others in this group may be able to answer: How can you see exactly which graphics hardware you have? The manuals mention using "hinv", which says nothing about graphics hardware. "hinv -v" doesn't say anything more than "hinv". Are there any papers/references which describe how the rendering engines function? Which format is fastest when sending vertices to the graphics pipe, shorts, ints, floats, or doubles? What is the internal numeric format of the pipeline? When can I expect my copy of 3.2, with the Personal Wavefront package on it? Can I just get a copy of the Wavefront stuff in the meantime? Is anyone at SGI going to proofread those manuals? They are rife with spelling, grammar, and punctuation errors. While I like the nice binders, accurate text is even nicer. Are there really 256 vertex limits on the polygon and tmesh routines? I drew a tmesh with 1200 vertices with no problem. Exactly which combinations of colors and Z values are required on a 4D/50GTB to get czclear() to do an optimized clear of the frame buffer and the Z buffer? The documentation is very confusing. When I run "gr_osview -a" to see what the CPU spends its time waiting on, it seems to be spending 100% of its time waiting on the graphics FIFO to empty. Is this really the case? Does this mean that the machine is at top rendering speed? I was under the impression that the graphics hardware is much faster than the CPU in the 50, and that performance could be gained by just adding a faster CPU, like in a 4D/70 or 4D/80. Well, I suppose that's enough for now. Also, many kudoes to SGI, for making the system so easy to unpack and install. After fighting to get the OS installed and configued on Suns, it was a dream to boot the machine, give it my NFS tape, let it get everything set, change two files, and be up and running! Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} Gee, Beaver, everything that's fun can get you in trouble. Haven't you learned that yet? --Gilbert   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17907; 11 Oct 89 12:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17778; 11 Oct 89 11:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab17774; 11 Oct 89 11:42 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa12405; 11 Oct 89 11:20 EDT Received: Wed, 11 Oct 89 08:21:11 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Wed, 11 Oct 89 11:20:52 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Wed, 11 Oct 89 11:29:17 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Wed, 11 Oct 89 11:29:17 EDT From: Tony Facca Message-Id: <8910111529.AA23538@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Hung print spooler (sorry, I deleted the subject line from the original message) Bill Lasher writes: > We have a room full of Personal IRIS's on a network, with several plotters and > > << stuff deleted >> > > sit there. If we cancel the job that hung, the queue is freed up and > everything works fine for awhile. It doesn't appear to be a specific file; if > a file gets hung and we cancel it, then re-submit the same job, it works fine. > We have contacted the SGI hotline, but they don't yet know what the problem is > however, they did say that someone else had reported it. Anyone else having > this problem; or any ideas as to what might be causing it? > > Many thanks, > > Bill Lasher > I reported the same problem way back when 3.1 first came out. The problem didn't exist in 3.0 but started when I upgraded to 3.1 I called the hotline and the guys worked on it for several days but couldn't find exactly what the problem was. Seems that there is a "sleep" in the network interface script which causes the spooler to appear hung. This section of code is executed when an attempt to spool a file to a machine which is down (or not accepting requests) is made. The current job is held up, and the remote copy will be tried again later. I suppose this is preferable to disabling the local print spooler as was done in the past. If you look at the script you'll see that the lines containing the "disable" command are commented out as well as the "exit 1" command -- so there is no way out of this section of code if the file is not transferred. I don't know why it doesn't work eventually (when the target machine comes back up)? Anyway, I just used the 3.0 script in place of the 3.1 stuff. This works fine. And, since I had several other changes in the 3.0 script, it was easier than trying to get the 3.1 version working. I guess this is where the Hotline call must have died. Maybe I canceled it, I don't remember. The original script used by "mknetpr" is found in /usr/spool/lp/etc/lib and is called "netface". This is NOT the one I change. Instead, I let mknetpr do its thing, then just swap out the final script in /usr/spool/lp/interface for the old script. Rather than post the script here, you can contact me directly and I can let you "ftp" it from me. Good luck. -- ----------------------------------------------------------------------------- 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 aa24299; 12 Oct 89 0:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab24149; 11 Oct 89 23:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab24111; 11 Oct 89 23:44 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24536; 11 Oct 89 23:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA07351; Wed, 11 Oct 89 20:18:29 -0700 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 Oct 89 03:14:35 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Robots' geometry request. Message-Id: <21032@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was wondering if there are any people out there in the net that have geometry description of different robots and are willing to trade/share with us here at the Machine Intelligence Laboratory at the University of Florida. Where are interested in everything from old models to Pumas, T3, P60, P50, etc. Thanks! Pablo pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research." -, _/: \ o.O , =(___)=   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24372; 12 Oct 89 0:29 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24099; 11 Oct 89 23:43 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24028; 11 Oct 89 23:26 EDT Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa24378; 11 Oct 89 23:00 EDT Received: from uoguelph.netnorth (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57373; Wed, 11 Oct 89 22:56:43 EDT Received: by UOGUELPH (Mailer R2.02A) id 4143; Wed, 11 Oct 89 22:54:47 EDT Date: Wed, 11 Oct 89 22:46:48 EDT From: "Len Zaifman UoGuelph (519)824-4120 xt 6566" Subject: X-terminal support on SGIs at 3.2 and Greater To: info-iris Message-Id: <89Oct11.225643edt.57373@ugw.utcs.utoronto.ca> We are configuring a setup where a power series is centrally located and several X-terminals are on lans connected via routers(IE not on the same logical segment) to the Power Series. The question is : What X-terminals have SGI boot support so that the terminal may boot from the Power Series ?? Does this support work to any valid IP address or must the X-terminal and the server be on the same segment (or node depending on your terminology)? Where does this software come from ?? SGI (I should think) or the X-terminal vendor(which I doubt they supply) ?? Any idea of cost ?? Also, if anyone has had experience with X-terminals hooked up to SGI systems, I would be happy to hear any comments on it's effectiveness. We expect to be at 3.2 by the end of the month, so any news at that version or later ,if known, would be of interest. Many thanks. Regards Len Zaifman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24533; 12 Oct 89 1:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24149; 11 Oct 89 23:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24111; 11 Oct 89 23:44 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24530; 11 Oct 89 23:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA07344; Wed, 11 Oct 89 20:18:19 -0700 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 Oct 89 03:08:22 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Use lookat or redraw? Message-Id: <21031@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was wondering if anybody knows whether programs such as dog redraw the scenery at a different position in response to the user's input or if they just set up a new lookat point. Is there any concensus as to which method is better/faster? Thanks! Pablo Machine Intelligence Laboratory pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research." -, _/: \ o.O , =(___)=   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25450; 12 Oct 89 3:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25041; 12 Oct 89 2:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25008; 12 Oct 89 2:05 EDT Received: from santra.hut.fi by SMOKE.BRL.MIL id aa25928; 12 Oct 89 1:47 EDT Received: from [130.188.1.1] by santra.hut.fi (5.61++/7.0/TeKoLa) id AA08284; Thu, 12 Oct 89 07:47:14 +0200 Received: by vtt.fi; id AA27002.R2.6; Thu, 12 Oct 89 07:45:25+0300 Received: by geeni.bio.vtt.fi (5.52/1.1.geeni) id AA01413; Thu, 12 Oct 89 07:49:46 GMT Date: Thu, 12 Oct 89 07:49:46 GMT From: Leif Laaksonen Message-Id: <8910120749.AA01413@geeni.bio.vtt.fi> Apparently-To: info-iris@brl.mil Greetings from a cold and wet Finland. Apart from the weather I have in mind a problem with our 4D/70GTB. Quite frequently the screen goes black in the middle of a graphics session. I have tried to kill the grcond from an other terminal but without success. Usually I just boot the system. This is very annoying because we are running quite long jobs in the background. The next thing I did was to look into the SYSLOG file and found following things: ...... Oct 3 12:56:53 geeni grcond[9658]: Child process /bin/wsh terminated with status 9 Oct 3 12:56:58 geeni grcond[9658]: Child process /bin/news_server terminated with status 0 ...... Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/wsh terminated with status 9 Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/news_server terminated with status 6 ...... Oct 6 13:02:26 geeni grcond[3548]: CIO: NeWS: bus error signal received Oct 6 13:02:26 geeni grcond[3548]: Child process /bin/news_server terminated with status 6 ...... Oct 6 11:07:42 geeni grcond[3396]: Child process /bin/wsh terminated with status 0 Oct 6 11:07:44 geeni grcond[3396]: CIO: NeWS: segmentation violation signal received Oct 6 11:07:44 geeni grcond[3396]: Child process /bin/news_server terminated with status 6 What's the problem when /bin/wsh exits with status 9 and /bin/news_server exits with status 6 and what might be the problem to the bus error and segment violation? I phoned the local SGI service and a chap had a look at the system but he did not find anything wrong with it. And the screen still goes black. Is there any suggestions? Many thanks, Leif Laaksonen Technical research centre of Finland Biotechnical laboratory LAAKSONEN@FINFUN or laaksone@geeni.bio.vtt.fi   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29780; 12 Oct 89 10:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28813; 12 Oct 89 9:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28659; 12 Oct 89 9:08 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02743; 12 Oct 89 8:57 EDT Received: Thu, 12 Oct 89 08:58:09 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 12 Oct 89 08:58:09 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910121558.AA00235@aero4.larc.nasa.gov> To: mailrus!uflorida!beach.cis.ufl.edu!pff@tut.cis.ohio-state.edu Subject: Re: Use lookat or redraw? Cc: info-iris@BRL.MIL I am not sure what you're asking. Everything has to be redrawn, no matter what you do. The only difference I can see is whether you change your perspective with lookat or do your movement by changing translation, rotation, and scaling on the objects drawn. Personally, I prefer to use lookat most of the time, it makes most things simpler and easier to implement and understand. -- 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 aa00563; 12 Oct 89 11:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29780; 12 Oct 89 10:51 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab29679; 12 Oct 89 10:37 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa29625; 12 Oct 89 10:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA12704; Thu, 12 Oct 89 07:08:09 -0700 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 Oct 89 13:24:32 GMT From: Andrew Simms Organization: Princeton University Subject: Re: Memory for 4D/20 & 4D/25 Message-Id: <10818@phoenix.Princeton.EDU> References: <8910080559.aa01784@SEM.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Impediment 617/837-8877 He has memory for 4D/20 & 4D/25 right now at $120/megabyte. He will ["next week"] have memory for the 4D/200 series at around $225/megabyte. Lifetime replacement garantee. Alex is the contact. We have purchased more than 50 Megabytes from him which has been in service without failure for 6 months. He also has Macintosh simms at $89/megabyte.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00563; 12 Oct 89 11:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00161; 12 Oct 89 11:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29935; 12 Oct 89 11:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06741; 12 Oct 89 10:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA13411; Thu, 12 Oct 89 07:22:08 -0700 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 Oct 89 13:49:12 GMT From: Tom Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: X terminals on an Iris4D Message-Id: <19504@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have recently attached an NCD X terminal to our SGI 4D/80 server, and I have noticed an annoying "feature" I'd like to share with you. We're running XDM to keep track of the display, and when an user logs in XDM spawns a UWM (I've set it up that way) and then execs an xterm (again, nothing wrong yet). Thing is that if one does a "who am i" in the xterm window, it says that you are "rlogin"! This happens for any new xterm windows you might choose to create from UWM, except those which explicitly rlogin to another machine or rlogin to localhost. Of course, except for the latter case, a "who" doesn't show any of the people who are logged in from X terminals. All processes you might start from within the xterm window, however, have the correct user ID associated with them, so a ps -u russo does show all of my processes, including the csh that xterm is presumably execing. Does anyone know the root of this behaviour? Is this a normal thing, or is something strange about the version of xterm we're running? Our system is running IRIX 3.1G, with the X development option. If this is not a normal thing, is there any way around it, short of using "rlogin localhost" all over the place? thanks. +----------------------------------------------------------------------+ |Thomas Russo | russo@chaos.utexas.edu | |Center for Nonlinear Dynamics, University of Texas at Austin | +----------------------------------------------------------------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01207; 12 Oct 89 13:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00910; 12 Oct 89 12:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00905; 12 Oct 89 12:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09601; 12 Oct 89 11:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA17789; Thu, 12 Oct 89 08:35:45 -0700 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 Oct 89 15:27:13 GMT From: Rayan Zachariassen Subject: Re: NTP Message-Id: <89Oct12.112610edt.3212@neat.cs.toronto.edu> References: <141@ndl.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There are at least two NTP implementations for UNIX boxes (one from UMD, one from UofToronto), and the local one at least requires 2 things IRIX doesn't have: - sub-second time setting ability (nominally settimeofday()) - BSD signals Considering gettimeofday() exists, I'm surprised settimeofday() doesn't. It is probably possible to work around these and end up with an NTP that limps along, but it isn't worth the time...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01404; 12 Oct 89 13:21 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01207; 12 Oct 89 13:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01154; 12 Oct 89 12:55 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10473; 12 Oct 89 12:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA21106; Thu, 12 Oct 89 09:28:37 -0700 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 Oct 89 16:18:55 GMT From: Jean-Francois Lamy Subject: Re: NTP Message-Id: <89Oct12.121835edt.3216@neat.cs.toronto.edu> References: <141@ndl.UUCP>, <89Oct12.112610edt.3212@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Should anyone wonder: interest in NTP does not necessarily have anything to do with an obsession to be within a couple femtoseconds of official earth time. A common practice around here is to keep a single copy of a program on one machine and have a shadow directory structure on the target machine with symbolic links pointing at files in the master source. I've been burned too often by compiling a file on the target machine that ends up being older than the source it was compiled from because of clock drift. Is it too much to ask to be able to keep clock accuracy within the compile time of a short C file? This symlink practice also does wonders for - keeping your makefiles squeaky clean - crashing NFS implementations (our 4D/240 has been up since yesterday at 5 without hanging since upgrading to 3.2, we're duly impressed). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03572; 12 Oct 89 16:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03158; 12 Oct 89 16:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03108; 12 Oct 89 15:55 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16987; 12 Oct 89 15:22 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA01770; Thu, 12 Oct 89 12:16:29 -0700 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 Oct 89 19:05:58 GMT From: Rayan Zachariassen Subject: Re: NTP Message-Id: <89Oct12.150453edt.3224@neat.cs.toronto.edu> References: <141@ndl.UUCP>, <89Oct12.112610edt.3212@neat.cs.toronto.edu>, <42894@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Given the microsecond resolution in the IRIX adjtime(2) and the sub-second >resolution in gettimeofday(2), NTP should be an easy port. Other issues >such as signals should be trivial, particularly in view of the similarities >between SVR3 "reliable" and BSD signals. Re signals, it seems more to be a matter of signal masks and such, which can be overcome by careful bookkeeping and simulation functions. The more serious issue is settimeofday() (or similar capability). Here's what our local NTP wiz says about the matter: > From: Dennis Ferguson > To: rayan@ai.toronto.edu > Subject: Re: is settimeofday needed? > Date: Thu, 1 Jun 89 12:58:28 EDT > > NTP uses settimeofday() to step the time when the offset is greater > than 128 milliseconds (rather than using adjtime() to adjust it). > It does this rarely, usually just once when the program is started > after a reboot. It certainly can use better than 10 ms precision if > you can provide it, especially on a fast machine where the > gettimeofday()-add an offset-settimeofday() can be executed quickly. > What I usually see is the first step bringing the clock to within 5-15 ms, > leaving the adjustment routine to correct the remainder. > > You don't necessarily need quite that precision. You *must* be able > to step the clock to within 100 ms of where you want it, however. If > you do a step and the result falls outside the 128 ms aperture, it will > step the time again after the 10 minutes it will take to refill the > peer registers (and again, and again...). stime() isn't good enough. > > If nothing can be done, there is an option which I am not fond of. > The local clock procedure can be compiled to always use adjtime() to > adjust the clock. This was included because I once thought that > some people might find the occasional stepping of the time backwards > offensive. Trouble is, I never tested this since the time stepping > happened so infrequently. It also adds code to a critical section, > and may suffer from races between the adjustment code and the SIGIO > interrupt. In the worst case this could be debugged into service, > but it is a lot cleaner to just step the clock once in a while. Would > be a lot better to have a settimeofday(). > > Dennis One could also kluge around it by napping just enough to get to a whole-second boundary and then do the stime(), but this is pretty gross. In other words, it can be kluged but it involves a "port" as opposed to just fixing up names and recompiling.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04996; 12 Oct 89 17:59 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02639; 12 Oct 89 15:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02517; 12 Oct 89 15:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14754; 12 Oct 89 14:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA27461; Thu, 12 Oct 89 11:09:48 -0700 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 Oct 89 17:52:08 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NTP Message-Id: <42894@sgi.sgi.com> References: <141@ndl.UUCP>, <89Oct12.112610edt.3212@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Given the microsecond resolution in the IRIX adjtime(2) and the sub-second resolution in gettimeofday(2), NTP should be an easy port. Other issues such as signals should be trivial, particularly in view of the similarities between SVR3 "reliable" and BSD signals. NTP does wonders for synchronizing clocks. However, it requires each host to be individually configured. That can be a pain in large networks. Broadcast, election schemes such as that used by timed(1m) are much easier to administer, although they cannot hope for the microsecond accuracy achieved by NTP. Given the general sloppiness of UNIX time and process scheduling, fractional second accuracy for things like NFS and make(1) is usually necessary and sufficent. Better accuracy is generally an academic exercise, albeit one which I personally find a lot of fun. (Before flaming, usec time can be useful for things like network performance research and development). If I had a bunch of IRIS's near one or more NTP true-tickers, I would nominate one IRIS as a timemaster, use timeslave(1m) to synchronize the IRIS timemaster to the nearest NTP ticker, and timed(1m) to synchronize the rest of the IRIS's to the timemaster. The thousands of IRIS's in SGI's internal network are synchronized in a similar fashion. One machine listens to a WWV receiver with timeslave(1m). A second machine follows the first with `timeslave -H first` and uses `timed -M -F itself` to be the corporate timemaster. All other machines use `timed -M -G timelords`. The machines in the "timelords" YP netgroup are IP gateways between networks (i.e. routers). The netgroup permits the semi-automatic, centrally adminstrated construction of a hierachy of time keepers. I think the -G argument for timed was not present until 3.2, but the same effect, except for the central administration, is available with -F. When I checked a few minutes ago, the SGI network appears to be synchronized to about 30 milliseconds. Much better values are possible in IRIX 3.3 where the system clock can be trimmed using the values suggested by timeslave(1m) and timed(1m) in /usr/adm/SYSLOG. Timedc(1m) is a useful tool for measuring differences in time of day. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07407; 12 Oct 89 23:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06437; 12 Oct 89 22:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06414; 12 Oct 89 22:08 EDT Received: from ucsd.edu by SMOKE.BRL.MIL id aa23712; 12 Oct 89 21:45 EDT Received: from chema.ucsd.edu by ucsd.edu; id AA17441 sendmail 5.61/UCSD-2.0-sun via SMTP Thu, 12 Oct 89 18:46:10 -0700 for info-iris@brl.mil Received: by chem.chem.ucsd.edu (5.51) id AA02565; Thu, 12 Oct 89 18:44:32 PDT Date: Thu, 12 Oct 89 18:44:32 PDT From: Steve Dempsey Message-Id: <8910130144.AA02565@chem.chem.ucsd.edu> To: info-iris@BRL.MIL Subject: problems with 'picking' on various models of the 4D Has anybody noticed any problems with 'picking' on the 4D workstations? Recently, several people running my molecular modeling software (MMS) have called to report that it has stopped working. I have traced the problem to erroneous results being returned by 'endpick'. Just to make life complicated, different models of the 4D report different results, and on the one 4D that I have routine access to (a 240GTX running 3.1G) the problem does not occur. Most bizarre has been the behavior of Personal Irises. These machines are running 3.1D and 3.1G. In three cases people reported identical situations: 1. They had been using my software for weeks or months without problems. 2. Their machines crashed because of a local power failure. 3. My program would not operate properly after power was restored. No hardware or software changes had taken place between steps 1 and 3. In one case the PI was turned back off for the weekend, and when it was restarted on Monday morning the problem was gone! What I am expecting from 'endpick' (and what I see on the 240GTX) is a function value of 1 (indicating 1 hit) and a pick buffer containing two values; a 1 (length of name stack) and the value placed on the namestack with 'loadname'. The Personal Irises are returning 0 from 'endpick', indicating that no hits occured. A 70G (3.141592638...) and and a 70GT (3.0) report multiple 'null' hits in addition to the real hit. For example, if 'endpick' returns a value of 3 the pick buffer contains: pickbuf[0] = 0 0 length namestack pickbuf[1] = 0 0 length namestack pickbuf[2] = 1 namestack has one value pickbuf[3] = expected value -------------------------------------------------------------------------------- Steve Dempsey (619) 534-0208 Dept. of Chemistry Computer Facility, B-014 INTERNET: sdempsey@ucsd.edu University of Calif. at San Diego BITNET: sdempsey@ucsd La Jolla, CA 92093 UUCP: ucsd!sdempsey   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08512; 13 Oct 89 1:58 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07931; 13 Oct 89 0:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07894; 13 Oct 89 0:36 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25285; 13 Oct 89 0:28 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA04873; Thu, 12 Oct 89 21:24:40 -0700 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 Oct 89 03:35:22 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NTP Message-Id: <42950@sgi.sgi.com> References: <141@ndl.UUCP>, <89Oct12.112610edt.3212@neat.cs.toronto.edu>, <89Oct12.150453edt.3224@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Oct12.150453edt.3224@neat.cs.toronto.edu>, rayan@cs.toronto.edu (Rayan Zachariassen) writes: > > > From: Dennis Ferguson > > To: rayan@ai.toronto.edu > > > > ... This was included because I once thought that > > some people might find the occasional stepping of the time backwards > > offensive. Trouble is, I never tested this since the time stepping > > happened so infrequently.... Things like cron and NeWS do not take kindly to reliving the past. Reverse time jumps are noticed around here. I speak from experience. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08630; 13 Oct 89 2:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08512; 13 Oct 89 2:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08499; 13 Oct 89 1:57 EDT Received: from santra.hut.fi by SMOKE.BRL.MIL id aa25968; 13 Oct 89 1:40 EDT Received: from [130.188.1.1] by santra.hut.fi (5.61++/7.0/TeKoLa) id AA08623; Fri, 13 Oct 89 07:40:27 +0200 Received: by vtt.fi; id AA27677.R2.6; Fri, 13 Oct 89 07:38:29+0300 Received: by geeni.bio.vtt.fi (5.52/1.1.geeni) id AA03073; Fri, 13 Oct 89 07:43:33 GMT Date: Fri, 13 Oct 89 07:43:33 GMT From: Leif Laaksonen Message-Id: <8910130743.AA03073@geeni.bio.vtt.fi> Apparently-To: info-iris@brl.mil I'm sorry to bother you once more with this query but I must have explained my problem in my previous query very badly. I have some problems with our 4D/70GTB. Quite frequently the screen goes black in the middle of a graphics session. No this has nothing to do with the screen blanks after some time intervals. There is now way I know of to get the display alive again. (I have not tried a hammer). (We had problems with one of the graphics boards which was replaced some weeks ago.) One of the things I tried was to kill grcond and restart the graphics. Some times this works. The problem is that it is usually impossible to kill the old grcond. Usually I just boot the system. This is very annoying because we are running quite long jobs in the background. The next thing I did was to look into the SYSLOG file and found the following things: ...... Oct 3 12:56:53 geeni grcond[9658]: Child process /bin/wsh terminated with status 9 Oct 3 12:56:58 geeni grcond[9658]: Child process /bin/news_server terminated with status 0 ...... Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/wsh terminated with status 9 Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/news_server terminated with status 6 ...... Oct 6 13:02:26 geeni grcond[3548]: CIO: NeWS: bus error signal received Oct 6 13:02:26 geeni grcond[3548]: Child process /bin/news_server terminated with status 6 ...... Oct 6 11:07:42 geeni grcond[3396]: Child process /bin/wsh terminated with status 0 Oct 6 11:07:44 geeni grcond[3396]: CIO: NeWS: segmentation violation signal received Oct 6 11:07:44 geeni grcond[3396]: Child process /bin/news_server terminated with status 6 What's the problem when /bin/wsh exits with status 9 and /bin/news_server exits with status 6 and what might be the problem to the bus error and segment violation? I phoned the local SGI service and a chap had a look at the system but he did not find anything wrong with it. And the screen still goes black. Is there any suggestions? Many thanks, Leif Laaksonen Technical research centre of Finland Biotechnical laboratory LAAKSONEN@FINFUN or laaksone@geeni.bio.vtt.fi Ps. It's still very wet and cold in Finland.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14408; 13 Oct 89 12:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13992; 13 Oct 89 12:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13913; 13 Oct 89 11:58 EDT Received: from gatech.edu by SMOKE.BRL.MIL id aa08713; 13 Oct 89 11:40 EDT Received: from hydra.gatech.edu by gatech.edu (5.58/GATECH-8.6) id AA18540 for ; Fri, 13 Oct 89 11:17:44 EDT Received: by hydra.gatech.edu (4.12/2.5) id AA13135; Fri, 13 Oct 89 11:15:57 edt Date: Fri, 13 Oct 89 11:15:57 edt From: "SCHREIBER, O. A." Message-Id: <8910131515.AA13135@prism.gatech.edu> To: info-iris@BRL.MIL, sd%chem@ucsd.edu Subject: Re: problems with 'picking' on various models of the 4D Cc: ccsupos@prism.gatech.edu > >Has anybody noticed any problems with 'picking' on the 4D workstations? >erroneous results being returned by 'endpick'. Just to make life complicated, > >A 70G (3.141592638...) and and a 70GT (3.0) report multiple 'null' hits in >addition to the real hit. For example, if 'endpick' returns a value of 3 >the pick buffer contains: > >>pickbuf[0] =>0>>0 length namestack >>pickbuf[1] =>0>>0 length namestack >>pickbuf[2] =>1>>namestack has one value >>pickbuf[3] =>expected value > I get this with a 120GTX. I figured I can live with it though. I am going to test the 50GT though to see what it gives. I am running FORTRAN programs, options 'f77 -g -DDEBUG -ZG' I have been thinking also about trying others. Also, I have noticed an error in 'lookat' and 'polarview' where they do not do the transformations expected. Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18024; 13 Oct 89 19:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17326; 13 Oct 89 18:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17309; 13 Oct 89 18:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19229; 13 Oct 89 17:43 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA01460; Fri, 13 Oct 89 14:34:26 -0700 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 Oct 89 21:27:28 GMT From: Chris Siebenmann Organization: Ziebmef home away from home Subject: Re: NTP Message-Id: <89Oct13.172654edt.30802@snow.white.toronto.edu> References: <141@ndl.UUCP>, <89Oct12.112610edt.3212@neat.cs.toronto.edu>, <42894@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: | NTP does wonders for synchronizing clocks. However, it requires each host | to be individually configured. That can be a pain in large networks. It depends on what you mean by "individually configured"; often you can get away with a common configuration file on many of your hosts. We run Dennis Ferguson's xntp, and all of our workstations (Vaxen and DS3100s) have a common config file (which points them at our two fileservers). I'd expect that you could easily come up with a common configuration for the machines where you'd just be running timed(1m) on anyways and fault tolerance and falseticker detection isn't such a big problem. [If our servers go south, I don't care what happens to time on the clients; I've got bigger problems!] -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19601; 14 Oct 89 1:31 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19343; 14 Oct 89 0:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19209; 13 Oct 89 23:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22742; 13 Oct 89 23:11 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA20370; Fri, 13 Oct 89 20:06:29 -0700 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 Oct 89 23:50:22 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: VIDEO frame grabber need for PI Message-Id: <43015@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know of a company that supplies a very dumb RS-170 RGB or NTSC frame grabber that sits on the VME bus? It would also be nice if the board could generate video as well. We would like to plug it into a PI, so the board can't be larger than 6U high. Speed is not as importent as cost - being able to grab about 1 frame a second would be fine. Thx for any info. paul haeberli @ silicon graphics paul@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19760; 14 Oct 89 2:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19494; 14 Oct 89 1:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19465; 14 Oct 89 1:02 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23812; 14 Oct 89 0:26 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA24486; Fri, 13 Oct 89 21:22:20 -0700 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 Oct 89 19:26:30 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Message-Id: <953@odin.SGI.COM> References: <8910120749.AA01413@geeni.bio.vtt.fi> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910120749.AA01413@geeni.bio.vtt.fi>, laaksone@BIO.VTT.FI (Leif Laaksonen) writes: > > ...... > Oct 3 12:56:53 geeni grcond[9658]: Child process /bin/wsh terminated with status 9 > Oct 3 12:56:58 geeni grcond[9658]: Child process /bin/news_server terminated with status 0 This is a normal exit. I don't know why grcond printed the messages. > ...... > Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/wsh terminated with status 9 > Oct 6 10:38:16 geeni grcond[2868]: Child process /bin/news_server terminated with status 6 This looks like NeWS called abort(3). I'm surprised there wasn't a message. > ...... > Oct 6 13:02:26 geeni grcond[3548]: CIO: NeWS: bus error signal received > Oct 6 13:02:26 geeni grcond[3548]: Child process /bin/news_server terminated with status 6 > ...... > Oct 6 11:07:42 geeni grcond[3396]: Child process /bin/wsh terminated with status 0 > Oct 6 11:07:44 geeni grcond[3396]: CIO: NeWS: segmentation violation signal received > Oct 6 11:07:44 geeni grcond[3396]: Child process /bin/news_server terminated with status 6 > There are a few funny PostScript things we know of that can cause segmentation violations in NeWS. You don't see them in normal use of the system. Is there some program that you are usually running when the screen goes black? This is very mysterious. When the NeWS server crashes, you should get another log in prompt not a black screen. The general flakiness you are experiencing smells like a hardware problem. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!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 aa23286; 15 Oct 89 0:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23139; 14 Oct 89 23:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23122; 14 Oct 89 23:41 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09999; 14 Oct 89 23:26 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA01613; Sat, 14 Oct 89 20:24:26 -0700 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 Oct 89 02:14:54 GMT From: Christopher Hull Organization: EMBA Computer Facility, Univ. of Vermont, Burlington. Subject: news_server set uid to root Message-Id: <1304@uvm-gen.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Why does the NeWS server need to be set uid to root? We have changed it on one of our machines an have not run into any problems yet. On another note, we are trying to come up with a way to change the standard console login screen, to a more interesting display. We want to have a graphics (gl) program running in the background. This will mean a NeWS server will have to be run after someone logs out. Is there a way to do this cleanly and elegantly? (i.e no massive system hacks) Email-reply is fine, If there enough response I'll post a summary. Christopher Hull ------------------------------------------------------------------------------- EMBA-CF, University of Vermont, Burlington, VT USENET: hull@uvm-gen.uucp CSNET: hull@uvm.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27321; 16 Oct 89 4:21 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27094; 16 Oct 89 3:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa27069; 16 Oct 89 3:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24755; 16 Oct 89 2:56 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA16034; Sun, 15 Oct 89 23:43:38 -0700 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 Oct 89 06:33:07 GMT From: Rayan Zachariassen Subject: pstat functionality? Message-Id: <89Oct16.023221edt.2337@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for a command that prints kernel data associated with a process, in particular I'm trying to find out about the file descriptors of a process and what they're attached to (with pstat I'd cross-reference the u-area information with the file and inode tables). I recall some program with a command-line interface to this sort of thing but can't remember its name, and half an hour of looking through man page synopses didn't jog my memory. Any suggestions? Thanks, rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00193; 16 Oct 89 9:19 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29871; 16 Oct 89 9:08 EDT Received: by VMB.BRL.MIL id aa29789; 16 Oct 89 8:59 EDT Received: from [128.228.1.2] by VMB.BRL.MIL id aa29365; 16 Oct 89 8:30 EDT Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1916; Mon, 16 Oct 89 08:30:55 EDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5839; Mon, 16 Oct 89 13:26:05 BST Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1335; Mon, 16 Oct 89 13:26:05 BS Via: UK.AC.OX.VAX; 16 OCT 89 13:26:02 BST Date: Mon, 16 OCT 89 13:25:54 BST From: HCART%VAX.OXFORD.AC.UK@cunyvm.cuny.edu To: INFO-IRIS@vmb.brl.mil Subject: Why has my printer given up? Message-ID: <8910160830.aa29365@VMB.BRL.MIL> I have a malibu printer on an IRIS 3130. The printer has been working OK for some time, but now refuses to print. lpstat -t gives the error message disabled by scheduler: can't open /dev/ttyd3 As far as I can see, all the permissions are as they always were and resetting them to their old values does not trigger the scheduler. Stopping and starting the print queue has no effect. Could this be a hardware problem? Or would I get a different message from lpstat if it couldn't activate the printer? Any help much appreciated. Hugh Cartwright, Oxford University.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03173; 16 Oct 89 12:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02581; 16 Oct 89 11:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02390; 16 Oct 89 11:26 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa01060; 16 Oct 89 10:45 EDT Received: Mon, 16 Oct 89 07:45:35 -0700 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Mon, 16 Oct 89 10:45:18 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 16 Oct 89 10:56:28 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 16 Oct 89 10:56:28 EDT From: Tony Facca Message-Id: <8910161456.AA11256@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Why has my printer given up? HCART%VAX.OXFORD.AC.UK@cunyvm.cuny.edu writes: > I have a malibu printer on an IRIS 3130. The printer has been working > OK for some time, but now refuses to print. lpstat -t gives the > error message > > disabled by scheduler: can't open /dev/ttyd3 > > As far as I can see, all the permissions are as they always were > and resetting them to their old values does not trigger the > scheduler. Stopping and starting the print queue has no effect. > > Could this be a hardware problem? Or would I get a different > message from lpstat if it couldn't activate the printer? Any help > much appreciated. > > Hugh Cartwright, Oxford University. Could it be that the line has hung up? Try something to hold the port open like: nuhup sleep 10000000 < /dev/ttyd3 & and then re-enable the printer. This is usually done in /etc/rc.local when the system is started, but something may have happened along the way.. Hope this helps. -- ----------------------------------------------------------------------------- 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 aa01344; 17 Oct 89 3:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01292; 17 Oct 89 3:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01267; 17 Oct 89 3:01 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05691; 17 Oct 89 2:27 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03321; Mon, 16 Oct 89 23:17:10 -0700 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 Oct 89 00:01:46 GMT From: michael zyda Organization: Naval Postgraduate School, Monterey CA Subject: NPS Distinguished Lecturer Series Message-Id: <335@cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The Naval Postgraduate School's Computer Science Distinguished Speaker Series Presents INTERACTIVE 3D DISPLAYS FOR THE 21ST CENTURY: Beyond the Desktop Metaphor Professor Henry Fuchs Department of Computer Science University of North Carolina, Chapel Hill Date: October 19, 1989 Time: 3:10 - 4:00 pm Place: Spanagel 421 Host: Associate Professor Michael J. Zyda Abstract The direct manipulation WYSIWYG interface popularized by the Apple Macintosh is fine for most 2D applications but inadequate for most 3D ones. Described in this talk is work at UNC-Chapel Hill on a direct manipulation interactive 3D system based on Ivan Sutherland's head-mounted display ideas of the 1960's. In order to have a usefully-effective system of this kind, several major problems need to be solved: 1) absolutely real-time image generation with minimal lag, 2) precise but minimally obtrusive tracking of the user's head and hand, 3) generation of a comfortable and effective head-mounted display, and 4) development of new human-machine interaction protocols that work for real applications. At UNC-Chapel Hill we have been working on most of these problems: a) a new graphics system, Pixel-Planes 5, that should generate over 1 million polygons per second (about 10 times that of current top-of- the-line graphics workstations), b) a real-time head-tracking device that can determine the user's position in a large room by imaging LEDs on the ceiling with a small head-worn camera, and 3) interaction protocols for architectural and medical applications using this system in which the user can visualize, move about, and interact with a virtual 3D environment in a natural WYSIWYG fashion. A videotape sequence shows the current state of these various systems. Difficult remaining problems are described. About the Speaker Henry Fuchs is Federico Gil professor of computer science and adjunct professor of radiation oncology at the University of North Carolina at Chapel Hill. He received a BA in Information and Computer Science from the University of California at Santa Cruz in 1970 and a PhD in computer science from the University of Utah in 1975. He has been an associate editor of ACM Transactions on Graphics (1983-1988) and the guest editor of its first issue. He was the technical program chair for ACM Siggraph'81 Conference, chairman of the 1985 Chapel Hill Conference on Advanced Research in VLSI, and chairman of the 1986 Chapel Hill Workshop on Interactive 3D Graphics. He serves on various advisory committees, including that of NSF's Division of Microelectronic Information Processing Systems and Stellar Computer's Technical Advisory Board. Attendance Notes This presentation is open to the public. The Naval Postgraduate School is adjacent to Highway 1 and is one of the first Monterey exits. The lecture will be held in Spanagel Hall 421. Spanagel Hall is the highest building on campus and is visible from Highway 1 as the 6 story building with all the antennas on top. Exit Highway 1 on Camino Aguajito. Take Camino Aguajito West (right off the Highway) to 7th St. Turn North on 7th (right turn). Take 7th to Sloat. Turn right on Sloat and take the first left into the school (at 9th St.). Spanagel Hall is in front of you, on your left. Park in a brown space, if possible. If you need telephone directions, contact the departmental office at (408) 646-2449.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04708; 17 Oct 89 16:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac04231; 17 Oct 89 15:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab04211; 17 Oct 89 15:37 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa09209; 16 Oct 89 16:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28942; Mon, 16 Oct 89 13:06:20 -0700 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 Oct 89 19:49:14 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: Transcript on SGI's Message-Id: <40559@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody have Transcript 2.1 working on their Iris4D ? I compiled it as if it were a bsd system, since we have bsd lpd running on our machines. The ditroff I am using is version 8 "titroff" (and "makedev"), and it seems to be producing bad input for the "psdit" program. If I bring the output of ditroff over to a machine with a working package, it's psdit will also crap out in the same place. psdit: can't open font table /usr/local/lib/ps/ditroff.font/Times/devpsc/.out ^ | Some control characters appear in front of ".out" -e -- ------------------------------------------------------------------------------- Eric Pearce eap@bu-it.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 aa04922; 17 Oct 89 16:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04231; 17 Oct 89 15:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa04211; 17 Oct 89 15:37 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa09083; 16 Oct 89 16:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27863; Mon, 16 Oct 89 12:49:09 -0700 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 Oct 89 19:34:42 GMT From: "Eric A. Pearce" Organization: Boston University Info Tech Subject: missing ioctl Message-Id: <40556@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I can not find "TIOCSTART" on our Iris4D's (running 3.1G). Is there a compatibility function or another way do the to do the same thing? -e -- ------------------------------------------------------------------------------- Eric Pearce eap@bu-it.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 aa02140; 19 Oct 89 15:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00776; 19 Oct 89 13:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00755; 19 Oct 89 13:44 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16563; 19 Oct 89 13:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24903; Wed, 18 Oct 89 14:45:06 -0700 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 Oct 89 12:07:32 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: BSD Style "lpr" for 4D Message-Id: <352@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A while back BSD style "lpr" for IRIS 4D was discussed. I want to be able to remote print to BSD VAX. Will this "lpr" for IRIS 4D do this? If so, is there somewhere I can get it by way of "ftp?" /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 Ft. Belvoir, VA 22060-5546 BITNET: richr%ai.etl.army.mil@CUNYVM +1 202 355 3653 CSNET: richr%ai.etl.army.mil@RELAY.CS.NET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01658; 20 Oct 89 8:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01425; 20 Oct 89 8:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01147; 20 Oct 89 7:55 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01204; 20 Oct 89 7:29 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA13726; Fri, 20 Oct 89 04:29:08 -0700 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 Oct 89 19:34:57 GMT From: Mike York Organization: Voodoo Graphics Project, Everett WA Subject: WorkSpace Icons Message-Id: <598@voodoo.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We've had 3.2 up an running for while and are having fun playing with WorkSpace. Great icons! Our question is: What does the icon for foreign executable files represent? Some people say it looks like a snail, others say it looks like tire with a blowout. What is it? What does it mean? -- Mike York Boeing Computer Services, Renton, Washington (206) 234-7724 uw-beaver!ssc-vax!voodoo!zombie   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02665; 19 Oct 89 15:19 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01614; 19 Oct 89 14:53 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa01524; 19 Oct 89 14:44 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa11798; 19 Oct 89 14:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23002; Wed, 18 Oct 89 21:44:32 -0700 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: 18 Oct 89 21:34:41 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: FORTRAN System Interface Routine Library Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to use some of the routines listed in IRIS 4D FORTRAN 77 Programmer's Guide, Chapter 4, System Functions and Subroutines. These allow many of the same system calls that can be easily done in the C language. I cannot seem to get these to work given only the man page and the Guide's description. I would rather use C, but since I am modifying a FORTRAN program, I am stuck. I would be extremely grateful if someone could send me a FORTRAN code fragment containing some of these (For example, getenv, getlog, fdate, etc.). George Elkins   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22727; 19 Oct 89 2:17 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa22018; 19 Oct 89 1:35 EDT Date: Thu, 19 Oct 89 1:17:43 EDT From: Lee A. Butler (VLD/VMB) To: info-iris@brl.mil Subject: X11 on Personal Iris Message-ID: <8910190117.aa21978@VMB.BRL.MIL> Has anyone gotten twm compiled on an Iris under O.S. 3.2's X11? I can't locate the following header files: Xlib.h Xutil.h cursorfont.h I do have /usr/include/X11, but all the files there are sym-links to files in /usr/include/X11/Xaw, which is an empty directory. Does this mean that SGI is not supplying all of X? In case you are wondering, I did install *ALL* software (manually), so I expected these files to be around. 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 ab07215; 20 Oct 89 21:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07133; 20 Oct 89 20:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07072; 20 Oct 89 20:49 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20167; 20 Oct 89 19:45 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28662; Fri, 20 Oct 89 16:37:30 -0700 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: 19 Oct 89 13:17:00 GMT From: "David M. McQueen" Organization: New York University Subject: Re: FORTRAN System Interface Routine Library Message-Id: <17280021@acf4.NYU.EDU> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL c c this fragment determines what type of terminal you are logged in on c using the getenv routine. the purpose is to prevent inadvertently c running graphics when you are not (and somebody else is) at the c IRIS console. this may not be elegant, but it works. c character*80 terminal c do 101 iterm=1,80 terminal(iterm:iterm) = ' ' 101 continue call getenv('TERM',terminal) if (terminal .ne. 'iris-ansi') then do 103 iterm=1,80 lterm = iterm if (terminal(iterm:iterm) .eq. ' ') go to 104 103 continue 104 lterm = lterm - 1 if (lterm .lt. 10) then write(fm,111) lterm else write(fm,112) lterm end if 111 format('(a',i1,',a52)') 112 format('(a',i2,',a52)') write(6,*) write(6,fm) terminal(1:lterm), c ' is an inappropriate terminal type for IRIS graphics' write(6,*) stop end if   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03120; 20 Oct 89 14:32 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01589; 20 Oct 89 13:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01488; 20 Oct 89 13:31 EDT Received: from uxe.cso.uiuc.edu by SMOKE.BRL.MIL id aa10872; 20 Oct 89 12:51 EDT Received: by uxe.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA15183; Fri, 20 Oct 89 11:51:24 -0500 Date: Fri, 20 Oct 89 11:51:24 -0500 From: Amy Swanson Message-Id: <8910201651.AA15183@uxe.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: moving CPUs far away Cc: amys@ncsa.uiuc.edu We have a lab of 20 IRIS 4D/20s and will be moving the CPUs out of the room. The CPUs are to be "rack mounted", and I'd like to know if anyone has done/thought of this. I would like to know if anyone has had any experience with simply moving a CPU about 75'-100' from the monitor and the wonderful things I can expect to happen from this; as well as any opinions on a rack design for the CPUs. Thanks, Amy Swanson SGI/Alliant Systems Administrator NCSA - National Center for Supercomputing Applications University of Illinois at Champaign-Urbana email: amys@ncsa.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03342; 20 Oct 89 14:43 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01589; 20 Oct 89 13:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01327; 20 Oct 89 13:27 EDT Received: from uxe.cso.uiuc.edu by SMOKE.BRL.MIL id aa10232; 20 Oct 89 12:36 EDT Received: by uxe.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA14943; Fri, 20 Oct 89 11:37:09 -0500 Date: Fri, 20 Oct 89 11:37:09 -0500 From: Amy Swanson Message-Id: <8910201637.AA14943@uxe.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: compiling and YP Cc: amys@uxe.cso.uiuc.edu I am attempting to compile "notes" on our SGIs (both 4D/20s and 4D/240s) but have run into a snag. Since we run Yellow Pages on all our systems, I need to compile with the sun and bsd include files as well as link with the sun and bsd libraries. The include files are no big deal; I can alter the Makefile to use these. It's the linking that's creating BIG problems with me. According to SGI docs, (from intro(3)) using a command like this: cc -I/usr/include/sun -I/usr/include/bsd prog.c -lsun -lbsd will tell the system to use the YP routines such as "getpwent" which under- stands the "+" in the password entries. But, how do I get the "-l" options attached to the cc lines? The Makefile that comes with notes uses the internal rules for compiling the source code, creating the object files, and then links the objects with flags provided in the Makefile. So, as I under- stand it, I would need to alter the internal rules for Make to get the code compiled for use with YP. Now, to complicate matters, I have actually manually compiled all the source with the above syntax, and it still sees me as "Anonymous" unless I place myself in /etc/passwd as a local entry (w/o the +). That leaves the "install" command as the culprit... Someone else is attempting to create an "installit" program to allow users to install their own software in designated directories; this program uses "install" and is bombing out on the YP entries. The only way we can see to fix this is to get the source to "install" and recompile it using the Yellow Pages stuff (sun and bsd include files and libraries). So, two questions: 1) Does anyone have/know of a work-around for this? 2) Why wasn't the source code on the SGIs complied to use the sun and bsd libraries automatically? If you don't run YP, then the default is to use the normal stuff anyway, so everyone would have been happy! *sigh* Amy Swanson SGI/Alliant Systems Administrator NCSA - National Center for Supercomputing Applications University of Illinois at Champaign-Urbana email: amys@ncsa.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05811; 20 Oct 89 17:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05538; 20 Oct 89 17:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab05405; 20 Oct 89 16:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17906; 20 Oct 89 16:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15119; Fri, 20 Oct 89 13:08:34 -0700 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: 20 Oct 89 18:58:11 GMT From: "Calvin H. Vu" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: FORTRAN System Interface Routine Library Message-Id: <43311@sgi.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , elkins@topaz.rutgers.edu (George Elkins) writes: > > I need to use some of the routines listed in IRIS 4D FORTRAN 77 > Programmer's Guide, Chapter 4, System Functions and Subroutines. > containing some of these (For example, getenv, getlog, fdate, etc.). > > George Elkins This is an example in Fortran: integer putenv character*10 value character*24 name, date i = putenv("foo=bar") call getenv("foo", value) print *, value call getlog(name) print *, name call fdate(date) print *, date end and everything seems to work fine for me. In 3.2 and previous releases, for some Fortran system routines that take character arguments, if the length of your character arguments exceed 128 bytes those routines will return an 'invalid argument' error. This has been fixed in our next release. If you have the error above just check to make sure that the character argument is not defined with a length exceeding 128 bytes. Calvin Vu Silicon Graphics calvin@wpd.sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07215; 20 Oct 89 21:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07133; 20 Oct 89 20:59 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa07029; 20 Oct 89 20:46 EDT Date: Fri, 20 Oct 89 20:11:10 EDT From: Mike Muuss To: Amy Swanson cc: info-iris@BRL.MIL, amys@ncsa.uiuc.edu Subject: Re: moving CPUs far away Message-ID: <8910202011.aa10448@SEM.BRL.MIL> SGI has told us that 75' of cable is the "design limit" for good quality on the Iris machines. Personally, I can't stand the noise of the CPUs, so I *always* remote my Iris. Usually I use the 75 foot cables that we pay SGI to provide us. In one circumstance, I had to remote my display about 175 cable feet. The image was still surprisingly good at that distance, although the fact that the cable was run over the fluorescent light fixtures for about 80 feet of that resulted in some 60 Hz noise being picked up, but it was tolerable. If you have a processor that will be running a (video) film recorder, or driving an RGB-to-NTSC converter for video tape, do NOT remote that display. Keep your video cable lengths as short as possible, and use the best coax you can afford. (There is a special kind of Belden coax to use for this purpose, I don't recall the number off hand). The astute eye (and ear, for sound) can see (hear) almost any kind of regular noise in the signal. (If you think I sound fanatical about video quality, you should hear the lengths I take to preserve sound quality). I have no experience rack-mounting SGI equipment. For that, you need a mechanical engineer. Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07363; 20 Oct 89 21:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07306; 20 Oct 89 21:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07279; 20 Oct 89 21:12 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20379; 20 Oct 89 20:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00631; Fri, 20 Oct 89 17:06:35 -0700 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: 20 Oct 89 20:18:42 GMT From: Archer Sully Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: WorkSpace Icons Message-Id: <43318@sgi.sgi.com> References: <598@voodoo.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <598@voodoo.UUCP>, zombie@voodoo.UUCP (Mike York) writes: > We've had 3.2 up an running for while and are having fun playing with > WorkSpace. Great icons! Our question is: What does the icon for > foreign executable files represent? Some people say it looks like a > snail, others say it looks like tire with a blowout. What is it? What > does it mean? > It's a blown tire, meaning, of course, that it won't run :-) -- Archer Sully (archer@sgi.com) "life is short, filled with stuff" -- Lux Interior   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07363; 20 Oct 89 21:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07306; 20 Oct 89 21:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab07279; 20 Oct 89 21:12 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20381; 20 Oct 89 20:48 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00796; Fri, 20 Oct 89 17:09:25 -0700 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: 20 Oct 89 22:31:30 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: BSD Style "lpr" for 4D Message-Id: <43331@sgi.sgi.com> References: <352@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <352@ai.etl.army.mil>, richr@ai.etl.army.mil (Richard Rosenthal) writes: > A while back BSD style "lpr" for IRIS 4D was discussed. > > I want to be able to remote print to BSD VAX. Will this > "lpr" for IRIS 4D do this? If so, is there somewhere I can > get it by way of "ftp?" > We have done a port of the lpr spooler; it will appear in the next IRIX release (don't know if this is known as "3.3" or "aspen" to the outside world; anyway, it's the one after 3.2!) I'm not sure if it will come as a standard part of the release (it does after all essentially duplicate much of the functionality of the existing IRIX spooler system), but if not it will certainly be available as an option. I believe there may be some non-SGI ports of lpr around, but I don't know where they are or how good they are; for example, do they understand SGI executable & archive file formats? do they do the tty settings correctly?... Caveat ftp'er!! Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07443; 20 Oct 89 21:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac07133; 20 Oct 89 20:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id af07095; 20 Oct 89 20:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20316; 20 Oct 89 20:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00715; Fri, 20 Oct 89 17:07:46 -0700 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: 20 Oct 89 22:14:50 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: compiling and YP Message-Id: <43327@sgi.sgi.com> References: <8910201637.AA14943@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > But, how do I get the "-l" options > attached to the cc lines? The Makefile that comes with notes uses the > internal rules for compiling the source code, creating the object files, and > then links the objects with flags provided in the Makefile. So, as I under- > stand it, I would need to alter the internal rules for Make to get the code > compiled for use with YP. The -l option should be used when compiling a .c into an executable, and when linking one or more .o's into a single executable. I don't know the particulars of the notes makefile, but it could use an inference (internal) make rule only to do the former (the .c: inference rule -- you can see it via make -n -p). The way to get those -l's through is to set LDFLAGS to include -lsun -lbsd in the makefile. If the makefile links one or more .o files into a program, it must be using an explicit rule, and should list $(LDFLAGS) among the arguments to $(CC), *after* the objects. > Now, to complicate matters, I have actually manually compiled all the > source with the above syntax, and it still sees me as "Anonymous" unless I > place myself in /etc/passwd as a local entry (w/o the +). That leaves the > "install" command as the culprit... If you were using -l when compiling .c's into .o's, no linking would be done (nor would you get a usage error). Could this be the mistake? The libsun code will query YP. Almost all SGI commands that use getpwent(3C) routines link with it. > Someone else is attempting to create an "installit" program to allow > users to install their own software in designated directories; this program > uses "install" and is bombing out on the YP entries. The only way we can see > to fix this is to get the source to "install" and recompile it using the > Yellow Pages stuff (sun and bsd include files and libraries). /etc/install (documented in install(1)) does use YP. If this is the install program you're describing, perhaps the YP client on which you're running it is not bound to a YP server. Since 4D1-3.1, SGI's libsun YP-passwd code will use /etc/passwd and treat + as a username character if ypbind has not bound your domain. Try ypwhich(1) to see if you're bound. > 2) Why wasn't the source code on the SGIs complied to use the sun and > bsd libraries automatically? If you don't run YP, then the > default is to use the normal stuff anyway, so everyone would have > been happy! Everything except passwd(1), netstat(1), and a few other hard cases, *is* linked with libsun. Some people complain that linking with YP leaves them at hanging when YP servers are unavailable. We've tried to take the sting out of YP by falling back on the local /etc files when service is lost. > Amy Swanson Regards, Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09554; 21 Oct 89 9:45 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09520; 21 Oct 89 9:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09509; 21 Oct 89 9:19 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa24434; 21 Oct 89 8:58 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4521; Sat, 21 Oct 89 08:35:06 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 21 Oct 89 13:32:48 Date: Sat, 21 Oct 89 13:34:15 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: The memory eater strikes back (2nd attempt to get attention) To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8910210901.aa24434@SMOKE.BRL.MIL> Hello, I've posted this one month ago, but I think I've never seen an answer to the following problem: To get best performance in memory allocation I want to use the malloc(3X) routines by using '-lmalloc' at link time. Now it seems that there is something wrong with it, because 'free' doesn't seem to work when using '-lmalloc'. The code fragment attached to this mail does allocation/deallocation of some ammount of memory in a endless loop. Using the libraries -lgl_s -lbsd -lfastm -lm -lc_s #(make mem) everything is fine. Using instead the libraries -lgl_s -lmalloc -lbsd -lfastm -lm -lc_s #(make meml) the process' memory size is increasing and on a 8MB GT the system is after about 50 steps saturated with really heavy paging. What I really would like to know is: a) Is it my fault (using wrong library order?)? b) Is it a bug? - known? - fixed when? c) Is there really a performance gain when using -lmalloc (supposed it works properly)? Any comments are welcome and appreciated. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET: -------------------------makefile----------------------------------------- # # make - directives # CFLAGS = -g -I/usr/include/bsd # # Library Selection # LIBRL = -lgl_s -lmalloc -lbsd -lfastm -lm -lc_s LIBR = -lgl_s -lbsd -lfastm -lm -lc_s # # # mem: mem.c cc mem.c $(CFLAGS) -o mem $(LIBR) # meml: mem.c cc mem.c $(CFLAGS) -o meml $(LIBRL) # -------------------------mem.c-------------------------------------------- /* ** MOLCAD Version 4.1 ** ** COPYRIGHT AND ALL OTHER RIGHTS RESERVED ** ** Contact: ** ** Prof. Dr. J. Brickmann ** c/o TH - Darmstadt ** Dept. for Physical Chemistry ** Petersenstr. 20 ** D-6100 Darmstadt, FRG ** ** BITNET : ** ** ** file : mem.c ** author : Martin Knoblauch + Michael Teschner ** date : ** purpose : memory allocation test ** comment : ** ** ** ** */ #include #include int acount,dcount; struct Dot { struct Dot *next; float arr[4]; }; extern struct Dot *mk_Newdot(); main() { struct Dot *first,*dot; int i,j,count; first = NULL; for(j=0;j<1000;j++){ mk_Deldots(first); dot = first = NULL; count = 0; for(i=0;i<5000;i++){ dot = mk_Newdot(dot); count++; if( first == NULL ) first = dot; } printf(" loop %d count %d \n",j,count); } } /* end main */ struct Dot *mk_Newdot(prev) struct Dot *prev; { struct Dot *help; if ((help = (struct Dot *)malloc(sizeof(struct Dot))) == NULL) return(NULL); if (prev != NULL) prev->next = help; help->next = NULL; return(help); } mk_Deldots(start) struct Dot *start; { struct Dot *help; while (start != NULL) { help = start->next; free(start); start = help; } } --------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11367; 21 Oct 89 22:31 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11185; 21 Oct 89 21:29 EDT Received: from neat.cs.toronto.edu by VMB.BRL.MIL id aa11159; 21 Oct 89 21:18 EDT Received: by neat.cs.toronto.edu id 3287; Sat, 21 Oct 89 21:18:25 EDT From: Mark Moraes To: XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) Subject: Re: The memory eater strikes back (2nd attempt to get attention) Cc: info-iris@vmb.brl.mil Newsgroups: list.info-iris References: <8910210901.aa24434@SMOKE.BRL.MIL> Message-Id: <89Oct21.211825edt.3287@neat.cs.toronto.edu> Date: Sat, 21 Oct 89 21:18:19 EDT In comp.sys.sgi you write: >a) Is it my fault (using wrong library order?)? Nope. Even if you remove all libraries except for -lmalloc, it still grows. You can see the problem over only a couple of iterations by printing the value of sbrk(0) after every loop. The break will grow steadily when using -lmalloc or amalloc/afree from -lmpc. With libc malloc, the BSD4.3 malloc or any other working malloc, the value stays constant after the first iteration. >b) Is it a bug? > - known? > - fixed when? Looks like a bug. Not fixed in Irix 3.2, it seems. >c) Is there really a performance gain when using -lmalloc (supposed it > works properly)? Not likely if it doesn't free... The standard libc malloc is about the speed of the "fast" BSD4.3 (Caltech) malloc for your example code (which is straight allocation followed by free -- not very demanding on most mallocs). But the Caltech malloc typically wastes twice as much memory, which can cause more paging if you use a lot of memory. (If free() doesn't work in -lmalloc, it isn't very useful, no matter how fast it is -- on our Power Iris, it takes about twice as long as the libc malloc...) The libmpc amalloc and afree show the same behaviour as -lmalloc if you modify your code to acreate an arena first, and add a grow function. Stay with the libc malloc unless profiling your application indicates that malloc is a bottleneck. At that point, consider custom allocation strategies for the most frequent uses of malloc. (like preallocating and managing memory pools of frequently used objects, using pages of memory where only the page is freed, using stack allocators with mark/release etc)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14713; 22 Oct 89 17:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14678; 22 Oct 89 17:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14657; 22 Oct 89 17:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05803; 22 Oct 89 16:44 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11602; Sun, 22 Oct 89 13:31:40 -0700 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: 22 Oct 89 17:07:11 GMT From: jim frost Organization: Software Tool & Die Subject: Re: moving CPUs far away Message-Id: <1989Oct22.170711.3257@world.std.com> References: <8910202011.aa10448@SEM.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL At my previous job we had a 3100 (the nice tall one with the very big fans :-) which was put in another room to make life bearable. It was a fairly long run (if 75' was SGI's max recommendation, it was pretty close to that if not over). Worked fine enough for me. Flourescent lights were along the cable run so there should have been quite a bit of interference. jim frost software tool & die madd@std.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07918; 23 Oct 89 14:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07320; 23 Oct 89 14:23 EDT Received: by VMB.BRL.MIL id aa07168; 23 Oct 89 14:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06396; 23 Oct 89 13:02 EDT Received: from ifi.uio.no by SMOKE.BRL.MIL id aa19473; 23 Oct 89 11:19 EDT Received: from runix.runit.sintef.no by ifi.uio.no (5.61++/1.15) with SMTP id AA16626; Mon, 23 Oct 89 16:18:15 +0100 Received: by runix.runit.sintef.no (norunix.EARN) (1.2/7.1) id AA14890; Mon, 23 Oct 89 16:15:41 +0100 Date: 23 Oct 89 15:28 +0100 From: Finn Drablos To: info-iris@BRL.MIL Message-Id: <63*finnd@vax.runit.unit.uninett> Subject: rand in awk I try to install an utility under Irix 3.1D, using awk. However, I get problems with rand() and srand(). For example $awk '{ print rand() }' awk: syntax error near line 1 awk: illegal statement near line 1 $awk '{ print rand(2.0) }' 2 2 Not very useful, really. Am I doing something wrong, or is this a bug ? Is there anything I can do to make it work (except for implementing my own random number generator) ? ================== Finn Drablos PHONE +47 7 597710 FAX +47 7 597708 MR-Senteret, SINTEF MHS(EAN) : finnd@vax.runit.unit.uninett N-7034 TRONDHEIM, NORWAY EARN/BITNET : drabloes@norunit -----------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08181; 23 Oct 89 14:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07320; 23 Oct 89 14:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06890; 23 Oct 89 13:41 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa22671; 23 Oct 89 13:18 EDT Received: Mon, 23 Oct 89 13:17:47 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 23 Oct 89 13:17:47 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910232017.AA01137@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Preventing remote graphics use A while back I asked the following question, but didn't get any responce. Is is possible to let a remote user on and allow them to do anything BUT graphics? Someone asked me about this, I told them I didn't think there was a way, but I would post a message just incase there is. They want others to be able to get on and compile any program and run non-graphics programs. They want only the console to be able to run a graphics program. Thanks. -- Brent   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08418; 23 Oct 89 14:55 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06816; 23 Oct 89 13:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06656; 23 Oct 89 13:35 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa22281; 23 Oct 89 13:01 EDT Received: Mon, 23 Oct 89 13:00:13 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 23 Oct 89 13:00:13 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910232000.AA01082@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Magnetic Optical Disk Drive Anything new on the MO drives? We are thinking about getting an Introl Sterling 650E drive and putting it on a 4D/220. What is the experience with these drives on SGI machines? Thanks in advance. -- Brent   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10769; 23 Oct 89 17:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10355; 23 Oct 89 17:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10337; 23 Oct 89 16:47 EDT Received: from nrtc.northrop.com by SMOKE.BRL.MIL id aa01680; 23 Oct 89 16:22 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id ab04688; 23 Oct 89 13:22 PDT Date: Mon, 23 Oct 89 13:24:34 PDT From: Fletcher Robinson To: info-iris@BRL.MIL Subject: drives Message-ID: <8910231622.aa01680@SMOKE.BRL.MIL> Hitachi has a new 760 MB ESDI disk drive which SGI supports on a 4D. Does anyone know the specific model number ??   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11449; 23 Oct 89 18:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11130; 23 Oct 89 17:56 EDT Date: Mon, 23 Oct 89 17:41:00 EDT From: Lee A. Butler (VLD/VMB) To: info-iris@BRL.MIL Subject: 4Sight configuration Message-ID: <8910231741.aa10720@VMB.BRL.MIL> I'v just about managed to do away with the toolchests and the WorkSpace from my 4Sight display (I like all my window ops on a pop-up menu). One thing I can't seem to do is get Icons to automatically go to the corners of the display. 4Sight seems to have a wired in allowance of space on the left for toolchests, and space on the right for the "WorkSpace" window. Has anyone gotten around this without modifying the system files? I readily admit to being a neophyte at writing PostScript, so I may be missing something obvious. On a related note, does anyone have any recommendations for books or documentation on "Introductory NeWS/4Sight?" I've got the books from Adobe, but NeWS seems to be both more and less than the PostScript in those books. The SGI manuals seem to deal mostly with programatic interfaces to 4Sight. 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 aa17755; 24 Oct 89 11:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17517; 24 Oct 89 10:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa17413; 24 Oct 89 10:28 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa02246; 23 Oct 89 17:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA01273; Mon, 23 Oct 89 14:34:03 -0700 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: 23 Oct 89 19:14:07 GMT From: jim frost Organization: Software Tool & Die Subject: Re: The memory eater strikes back (2nd attempt to get attention) Message-Id: <1989Oct23.191407.13894@world.std.com> References: <8910210901.aa24434@SMOKE.BRL.MIL>, <89Oct21.211825edt.3287@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL About SGI's and memory leakage: Something to remember is that the SGI graphical object library has memory leaks. This is a random fact that I ran into which I though some people might be interested in. In article <89Oct21.211825edt.3287@neat.cs.toronto.edu> moraes@CS.TORONTO.EDU (Mark Moraes) writes: |Stay with the libc malloc unless profiling your application indicates |that malloc is a bottleneck. At that point, consider custom allocation |strategies for the most frequent uses of malloc. (like preallocating |and managing memory pools of frequently used objects [...] ) The libc malloc slows considerably when dealing with many small object allocations and deallocations (typically a few hundred thousand if I remember right) where the BSD malloc degrades "reasonably"; pooled allocations will improve performance dramatically if you are doing this type of allocation on the SGI. The libmalloc malloc, even if broken, is good to run some tests with because it smashes the malloc'ed area; we found many bugs because of this behavior (and even more when running on a machine which disallowed null pointer dereferencing :-). jim frost software tool & die madd@std.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17755; 24 Oct 89 11:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17517; 24 Oct 89 10:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa17422; 24 Oct 89 10:29 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa02950; 23 Oct 89 18:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA04835; Mon, 23 Oct 89 15:29:36 -0700 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: 23 Oct 89 21:19:24 GMT From: "Louis D. Langholtz" Organization: EMBA Computer Facility, Univ. of Vermont, Burlington. Subject: Re: moving CPUs far away Message-Id: <1313@uvm-gen.UUCP> References: <8910201651.AA15183@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From article <8910201651.AA15183@uxe.cso.uiuc.edu>, by swanson@UXE.CSO.UIUC.EDU (Amy Swanson): > I would like to know if anyone has had any > experience with simply moving a CPU about 75'-100' from the monitor and the > wonderful things I can expect to happen from this. We have seperated CPUs from their keyboards and monitors by cables around 80' long with no noticable effects. However, we did use cables that have extra shielding, and are thicker (RG-59) but less expensive than sgi's cables. These CPUs are shelved on metal racks from Reliance in NJ. We have had no problems with them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Louis D. Langholtz Systems Programmer EMBA Computer Facility USENET: ldl@uvm-gen.uucp University of Vermont CSNET: ldl@uvm.edu Phone:(802)656-2926 Burlington,VT 05405   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17755; 24 Oct 89 11:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17517; 24 Oct 89 10:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa17483; 24 Oct 89 10:38 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa04715; 24 Oct 89 7:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17955; Tue, 24 Oct 89 04:23:31 -0700 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: 24 Oct 89 02:15:23 GMT From: sgi!shinobu!odin!fjord!pj@ucbvax.berkeley.edu Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: The memory eater strikes back (2nd attempt to get attention) Message-Id: <1065@odin.SGI.COM> References: <8910210901.aa24434@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910210901.aa24434@SMOKE.BRL.MIL> XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > I want to use the malloc(3X) > Now it seems that there is something > wrong with it, because 'free' doesn't seem to work when using '-lmalloc'. Yes, the 3.1 releases of IRIX did have a memory leakage with alot of small (under 28 bytes ??) allocs/frees. This was fixed in release 3.2. We believe that libmalloc will provide substantially better CPU performance and perhaps less memory fragmentation. Considerable work was done on libmalloc for 3.2, and we recommend its use for examples like yours. I assume that you have profiled your application, so that you already know that optimizing malloc is important to your performance. And I assume that you have noticed the behavioural differences between libc malloc and libmalloc, primarily that you should not dereference a pointer after freeing it when using libmalloc. Thanks, take care ... Paul Jackson (pj@sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20549; 24 Oct 89 15:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20047; 24 Oct 89 15:40 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa20019; 24 Oct 89 15:24 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa24300; 23 Oct 89 12:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11345; Mon, 23 Oct 89 09:22:13 -0700 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: 23 Oct 89 16:12:09 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Running remote Sun programs Message-Id: <21090@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I rlogin to a Sun and want to use programs that generate graphics, what should I set my terminal type to in order to see the graphics on our Personal Iris? I thought this was possible since PI uses NeWS. Thanks! Pablo pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research." -, _/: \ o.O , =(___)=   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20549; 24 Oct 89 15:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20047; 24 Oct 89 15:40 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab20019; 24 Oct 89 15:24 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa24355; 23 Oct 89 12:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11462; Mon, 23 Oct 89 09:24:27 -0700 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: 23 Oct 89 16:00:54 GMT From: Tom Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: Sendmail version on IRIX 3.1G Message-Id: <19977@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi. We're using IRIX 3.1G on a 4D/80 server. We have been having trouble lately with sendmail. Here's the story: Every couple of months sendmail starts going through a little dance where it tries to access locked queue files and in the process spawns many many sendmail processes. This appears to happen only when incoming mail shows up. This clutters up the system, then users get "no more processes" messages when they log in. Bad stuff, I have to go around manually killing (well, killing with awk...) lots of these sendmails, which invariable get reincarnated when the remote host tries to reconnect. Left unchecked, the behavior goes away as quietly as it came in about a day! Talking to some gurus on campus resulted in a suggestion that we move to sendmail 5.61. I've pulled the source over from berkeley, but it won't make without mods. Before I invest any time at all in this task, could I ask y'all if anyone's ported sendmail 5.61 to IRIX (it looks fairly simple, but then...), and why SGI is running an old sendmail anyway? The date on the 5.61 distribution is 9/20/88! Is it a big deal to get sendmail compiled for IRIX? Has anybody else seen this gremlin? Help? +----------------------------------------------------------------------+ |Thomas Russo | russo@chaos.utexas.edu | |Center for Nonlinear Dynamics, University of Texas at Austin | +----------------------------------------------------------------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22019; 24 Oct 89 18:59 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21940; 24 Oct 89 18:49 EDT Received: from steeles.csri.toronto.edu by VMB.BRL.MIL id aa21918; 24 Oct 89 18:40 EDT Received: from moraes by steeles.csri.toronto.edu via UNIX id AA14873; Mon, 23 Oct 89 20:37:33 EDT Message-Id: <8910240037.AA14873@steeles.csri.toronto.edu> To: info-iris@vmb.brl.mil Subject: Re: The memory eater strikes back (2nd attempt to get attention) Date: Mon, 23 Oct 89 20:37:28 -0400 From: Mark Moraes | The libc malloc slows considerably when dealing with many small object | allocations and deallocations (typically a few hundred thousand if I | remember right) where the BSD malloc degrades "reasonably"; pooled | allocations will improve performance dramatically if you are doing | this type of allocation on the SGI. True. I should also amend my earlier comment: For large numbers of small allocations, -lmalloc does indeed perform much faster than even the BSD4.3 malloc (and appears to free stuff correctly) For the specific case posted, it does not free correctly, and runs much slower. There are similar cases where the BSD malloc, while not losing performance in terms of CPU, will gobble up memory and causes paging activity. (eg. allocate a 1000 elements of 50 bytes each, free them all, then allocate a single element of 2000 bytes and watch it sbrk again, unnecessarily) | The libmalloc malloc, even if broken, is good to run some tests with | because it smashes the malloc'ed area; we found many bugs beca | use of | this behavior (and even more when running on a machine which | disallowed null pointer dereferencing :-). Huh? In Irix3.2, it doesn't necessarily smash the contents of freed blocks (I assume you mean smash the malloc'ed area on free -- I'd be rather displeased with a malloc that trashed the contents of the malloc'ed blocks:-) The following program prints hello world twice even when compiled with -lmalloc. Change that to "hello xxxxxxxxxxxxxxxxxxxxxxxxxxxx world" and it will then smash the freed block. Smashing the contents of a freed block (among other things) is desirable behaviour in a debugging malloc -- it degrades performance enough that you probably don't want it in your final code. -lmalloc won't work with the old kludge where you were allowed to rely on a freed block being undamaged till the next malloc. -lmalloc also returns NULL on malloc(0), following the SVID. Both are good for people who care about portability. #include #define HELLO "hello world\n" main() { extern char *malloc(); char *cp = malloc(sizeof(HELLO)); strcpy(cp, HELLO); fputs(cp, stdout); free(cp); fputs(cp, stdout); exit(0); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24465; 25 Oct 89 0:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24420; 25 Oct 89 0:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24329; 24 Oct 89 23:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06205; 24 Oct 89 23:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19485; Tue, 24 Oct 89 20:26:24 -0700 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: 23 Oct 89 14:47:41 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: moving CPUs far away Message-Id: <604@voodoo.UUCP> References: <8910201651.AA15183@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910201651.AA15183@uxe.cso.uiuc.edu> swanson@UXE.CSO.UIUC.EDU (Amy Swanson) writes: > > > ... I would like to know if anyone has had any >experience with simply moving a CPU about 75'-100' from the monitor and the >wonderful things I can expect to happen from this;... > We have 23 4D/70's that are cabled between 135' and 189'. We haven't had any real problems with this, although some of our users claim some of the displays are somewhat "washed out". This may be due to the cable length, but is seems to be caused by differences in the individual displays. SGI told us the supported limit was 75', so we usually move a bad display to a machine with 10' cables to prove the display is bad before calling SGI to fix it. -- Mike York Boeing Computer Services, Renton, Washington (206) 234-7724 uw-beaver!ssc-vax!voodoo!zombie   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18071; 24 Oct 89 11:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17352; 24 Oct 89 10:30 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17228; 24 Oct 89 10:06 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa15601; 24 Oct 89 9:06 EDT Received: Tue, 24 Oct 89 06:06:54 -0700 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Tue, 24 Oct 89 09:06:45 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Tue, 24 Oct 89 09:23:30 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Tue, 24 Oct 89 09:23:30 EDT From: Tony Facca Message-Id: <8910241323.AA28076@lerc08.lerc.nasa.gov> To: butler@BRL.MIL Subject: Re: 4Sight configuration Cc: info-iris%brl.mil@prandtl.nas.nasa.gov Have you taken a look at the 4Dgifts directory? You have to install it manually from tape, but it has some good sample startup files. -- ----------------------------------------------------------------------------- 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 aa18518; 24 Oct 89 13:22 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18410; 24 Oct 89 13:11 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18392; 24 Oct 89 12:50 EDT Received: from santra.hut.fi by SMOKE.BRL.MIL id aa23730; 24 Oct 89 12:04 EDT Received: from vtt.fi by santra.hut.fi (5.61++/7.0/TeKoLa) id AA23036; Tue, 24 Oct 89 17:44:28 +0200 Received: by vtt.fi; id AA05515.R2.6; Tue, 24 Oct 89 17:40:23+0300 Received: by geeni.bio.vtt.fi (5.52/1.1.geeni) id AA01676; Tue, 24 Oct 89 17:50:20 GMT Date: Tue, 24 Oct 89 17:50:20 GMT From: Leif Laaksonen Message-Id: <8910241750.AA01676@geeni.bio.vtt.fi> Apparently-To: info-iris@brl.mil Thanks for the response I got to my hardware problem with our 4D/70GTB. The system has now been checked for 2 weeks and no error has been found. This week the cpu-board will be checked and if the system still does not work properly after that I don't know what to do. The strange thing is that all the demo software is running properly but not QUANTA and INSIGHT both programs produce a tilted molecule. The next problem I have is to use a c-program to read a binary file produced by a fortran program. I have come that far that there is 4 bytes in the beginning of the file and 8 bytes between the records with are not recognised by a fortran program but are recognised by a c-program. Can somebody explain me what I should do to be able to read properly a fortran binary file with the c-function fread(). Thanks in advance, -leif laaksonen VTT/BIO Finland laaksonen@finfun or laaksone@geeni.bio.vtt.fi   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21846; 24 Oct 89 18:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21606; 24 Oct 89 18:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21590; 24 Oct 89 17:40 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02617; 24 Oct 89 16:45 EDT Received: Tue, 24 Oct 89 16:43:32 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 24 Oct 89 16:43:32 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910242343.AA05386@aero4.larc.nasa.gov> To: laaksone@bio.vtt.fi Subject: 'binary' files Cc: info-iris@BRL.MIL The problem is that it ISN'T a binary file. It is an unformatted file. The 3000's let you create BINARY files, I don't think any of the 4D machines will let you (in FORTRAN). If you specify 'BINARY' as the form in a FORTRAN open statement, you don't get a binary file; you get an unformatted file that has record marks between each record. A binary file created on a 3000 doesn't have these record marks. The only bytes in the file are what you write there. On the 4D's the only way to get a binary file from a FORTRAN program is to write a C routine that does the binary writes and call it from FORTRAN. I hope SGI changes this. Binary writes from FORTRAN are a MUST in my work. This is one of the things I will dread, if we get a 4D machine. I find unformatted files useless, they are also larger than binary files. -- 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 aa23894; 24 Oct 89 21:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23624; 24 Oct 89 21:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23428; 24 Oct 89 20:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05207; 24 Oct 89 20:45 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08603; Tue, 24 Oct 89 17:35:59 -0700 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: 25 Oct 89 00:19:42 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Preventing remote graphics use Message-Id: References: <8910232017.AA01137@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Idea: whenever a person logs in thru the console, just chmod go-w /dev/console and then only the current console login can write to that device. Would this work? George Elkins   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24044; 24 Oct 89 22:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23624; 24 Oct 89 21:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac23428; 24 Oct 89 20:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05224; 24 Oct 89 20:48 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08501; Tue, 24 Oct 89 17:34:53 -0700 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: 24 Oct 89 22:06:46 GMT From: Archer Sully Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: rand in awk Message-Id: <43482@sgi.sgi.com> References: <63*finnd@vax.runit.unit.uninett> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <63*finnd@vax.runit.unit.uninett>, finnd%vax.runit.unit.uninett@NAC.NO (Finn Drablos) writes: > I try to install an utility under Irix 3.1D, using awk. However, I get > problems with rand() and srand(). For example > > $awk '{ print rand() }' > awk: syntax error near line 1 > awk: illegal statement near line 1 > $awk '{ print rand(2.0) }' > > 2 > > 2 > > Not very useful, really. Am I doing something wrong, or is this a bug ? > Is there anything I can do to make it work (except for implementing my > own random number generator) ? awk is still the old awk. Try using 'nawk' instead. It is the new awk that is described in 'The AWK programming Language'. -- Archer Sully (archer@sgi.com) "life is short, filled with stuff" -- Lux Interior   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24213; 24 Oct 89 23:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24018; 24 Oct 89 22:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23985; 24 Oct 89 22:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05691; 24 Oct 89 21:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA12464; Tue, 24 Oct 89 18:33:12 -0700 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: 24 Oct 89 22:15:05 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Re: 'binary' files Message-Id: References: <8910242343.AA05386@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910242343.AA05386@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > The problem is that it ISN'T a binary file. It is an unformatted >file. The 3000's let you create BINARY files, I don't think any of the 4D >machines will let you (in FORTRAN). If you specify 'BINARY' as the >form in a FORTRAN open statement, you don't get a binary file; you get >an unformatted file that has record marks between each record. A binary >file created on a 3000 doesn't have these record marks. The only bytes >in the file are what you write there. Let's get all of this straight: On the 3000, form='unformatted' gives a file with binary data separated by newline characters On the 3000, form='binary' gives a file with binary data with no record marks of _any_ type. On the 4D, form='unformatted' gives a file which is control-word-delimited (to borrow from CDC's notation). Each record is preceded by a 32-bit integer giving the number of bytes in the record. The record is also followed by the same integer. On the 4D, form='binary' gives obscure error messages. > On the 4D's the only way to get a binary file from a FORTRAN program >is to write a C routine that does the binary writes and call it from >FORTRAN. That is how we do it here.... > I hope SGI changes this. Binary writes from FORTRAN are a MUST in >my work. This is one of the things I will dread, if we get a 4D machine. >I find unformatted files useless, they are also larger than binary >files. On the other hand, the control-word-delimited format is identical to that used on Sun machines (at least the Sun-4's). This makes it trivial to copy binary data files between SGI and Sun machines. The control-word-delimited format also makes it possible for the run-time system to do some checking of whether or not you are reading the data correctly, and it makes it easier to recover data from a partially corrupted file. -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24539; 25 Oct 89 0:55 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa24306; 24 Oct 89 23:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24294; 24 Oct 89 23:38 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06095; 24 Oct 89 23:15 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18711; Tue, 24 Oct 89 20:12:56 -0700 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: 24 Oct 89 22:43:17 GMT From: Dan Rosenblatt Organization: Sigma Design Inc., Denver, CO Subject: Want X11 help Message-Id: <281@koala.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We here at Sigma are doing a port of our ARRIS software (architectural CAD) to the DECstation 3100 and X-windows. We are having problems (to put it mildly) and are getting almost no help from DEC (local and otherwise). Anyone out there interested in doing telephone support for $$? We have ported to several other windowing systems and are having problems mostly in the area of poor X11 doc and examples. Thanx Dan Rosenblatt Sigma Design Voice: (303) 790-9080 Email: ..!{udenva|dunike}!koala!dir   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25155; 25 Oct 89 4:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25132; 25 Oct 89 4:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25113; 25 Oct 89 4:06 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa07723; 25 Oct 89 3:57 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2942; Wed, 25 Oct 89 03:57:57 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 25 Oct 89 08:28:41 Date: Wed, 25 Oct 89 07:55:13 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Reading fortran "unformatted" files from C on the 4D. To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8910250357.aa07723@SMOKE.BRL.MIL> Hallo, here comes a code fragment that reads (from C) a fortran "unformatted" file. Suppose the file has been fopen'ed to fp and that i1,i2,i3 are int's and that farr is a float-array. The programm then reads max fortran-records from the file, each record written by a fortran code like write(11) i1,i2,i3,farr ! with REAL farr(3) You have of course to know what is written in the records to interpret them correctly. For my opinion having the record-size included in the record is not as bad as somebody on the list told us. If you really need "C"-binary files, write a "C"-routine. Regards Martin Knoblauch TH-Darmstadt Phys. Chem. 1 Petersenstrasse 20 D-6100 Darmstadt, F.R.G. ------------------------------------------------------------------------------ for(iz=0;iz Subject: Third Party Disks for 4D/70GT To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8910250440.aa07989@SMOKE.BRL.MIL> Hallo, we plan to put an additional disk to our 70GT. We have currently a 380 MB ESDI disk used for system and user data. We want to add one of the available 760 MB drives. For price reasons we can't buy the "official" SGI product. Our plan is to get cage and cabling from SGI and the drive from a third party. Now I have got some questions on this topic: 1) Should we add the 760MB disk as a second EDSI disk, or should we add it on the SCSI bus build into the 4D? The disk will be used for user data for both the local processor and our NFS based network. 2) Available disk in the size we are thinking of are the CDC/Imprimis WREN-V700, WREN-VI770 and the Fujuitsu M2263 (and probably others). Has anybody (SGI specialist are highly welcome !!!) experience with this drives (ESDI and SCSI version) that he want to share with me? Does the 3.2 fx support any of this drives? How good is fx on "unknown" disk types? I would really like to hear any comments about our plan, EXCLUDED those stating that only SGI products are warranted to run on SGI processors. I have heard them before, I can see their point, but I cant afford to pay more than 100% more for (probably) the same product (here the original SGI cage is already counted). Many thanks in advance, Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27162; 25 Oct 89 9:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26969; 25 Oct 89 8:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa26841; 25 Oct 89 8:36 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa10056; 25 Oct 89 8:18 EDT Received: Wed, 25 Oct 89 08:17:46 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 25 Oct 89 08:17:46 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910251517.AA07293@aero4.larc.nasa.gov> To: pacific.mps.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!stat!stat.fsu.edu!mccalpin@tut.cis.ohio-state.edu Subject: Re: 'binary' files Cc: info-iris@BRL.MIL I used a 4D/20, Personal Iris and with form='binary' I didn't get any errors. The compiler took 'binary' to mean the same as 'unformatted'. I wish it had given me an error, that would have made it easier to find out what the problems was. What type of 4D were you using? Thanks for the info, up till this point I hadn't see any use for unformatted files. -- 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 aa28403; 25 Oct 89 10:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28128; 25 Oct 89 10:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28033; 25 Oct 89 10:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11708; 25 Oct 89 9:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23693; Wed, 25 Oct 89 06:23:48 -0700 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: 25 Oct 89 06:24:35 GMT From: George Travan Organization: Computing Services, Uni of Adelaide, Australia Subject: SLIP on SGI ? Message-Id: <587@sirius.ua.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL is SLIP supported through SGI's version of unix? i have a SUN that i would to connect to a SGI 210 via SLIP (more specifically dialup SLIP). is this possible? --Geo George Travan University of Adelaide Adelaide,AUSTRALIA. e-mail: gtravan@sirius.ua.oz george@frodo.ua.oz   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01225; 25 Oct 89 14:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01015; 25 Oct 89 14:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00827; 25 Oct 89 13:47 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19682; 25 Oct 89 13:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08202; Wed, 25 Oct 89 10:25:35 -0700 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: 25 Oct 89 17:11:55 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Third Party Disks for 4D/70GT Message-Id: <43521@sgi.sgi.com> References: <8910250440.aa07989@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910250440.aa07989@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > Hallo, > > 1) Should we add the 760MB disk as a second EDSI disk, or should we add it on > the SCSI bus build into the 4D? The disk will be used for user data for > both the local processor and our NFS based network. The ESDI version will perform better than our SCSI on your current machine. (We're making SCSI faster, but it's not there yet on Professional and Power Series machines. New Personal Iris' have pretty fast SCSI hardware today.) > > 2) Available disk in the size we are thinking of are the CDC/Imprimis > WREN-V700, WREN-VI770 and the Fujuitsu M2263 (and probably others). > Has anybody (SGI specialist are highly welcome !!!) experience with this > drives (ESDI and SCSI version) that he want to share with me? Does the 3.2 > fx support any of this drives? How good is fx on "unknown" disk types? > > I would really like to hear any comments about our plan, EXCLUDED those > stating that only SGI products are warranted to run on SGI processors. I have > heard them before, I can see their point, but I cant afford to pay more than > 100% more for (probably) the same product (here the original SGI cage is > already counted). > OK, OK, no warnings this time. 3.2 knows about the 2263, the Imprimis and others. Personally, I think you would be best getting the Hitachi 780 for performance reasons. I have actually not used the 'other' feature in fx. I either create the correct entry (Having source is nice that way.) or modify one that has similar parameters simply because it is easier. But you really should buy it from us..... :{) 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 aa01600; 25 Oct 89 14:29 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01225; 25 Oct 89 14:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01143; 25 Oct 89 14:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19664; 25 Oct 89 13:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08536; Wed, 25 Oct 89 10:30:10 -0700 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: 25 Oct 89 17:08:32 GMT From: Ken Lee Organization: DEC Western Software Laboratory Subject: Re: Want X11 help Message-Id: <1980@bacchus.dec.com> References: <281@koala.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <281@koala.UUCP>, dir@koala.UUCP (Dan Rosenblatt) writes: > Anyone out there interested in doing telephone support for $$? > We have ported to several other windowing systems and are > having problems mostly in the area of poor X11 doc and examples. Sorry, I can't offer direct help, but you may want to look at some of the excelent X tutorials. The documents on the X tape are really specifications. These are much more popular with beginners (listed in no particular order): Young, *X Window Systems Programming and Applications With Xt*, Prentice-Hall, ISBN 0-13-972167-3. Jones, *Introduction to the X Window System*, Prentice-Hall, ISBN 0-13-499997-5. O'Reilly and Associates, *The X Window System Series*, 4 volumes, ISBN 0-937175-26-9, 0-937175-27-7, etc. Johnson & Reichard, *X Window Applications Programming*, MIS: Press, ISBN 1-55828-016-2. Also, you should read the "hello, world" paper by Rosenthal that's on the X tape. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02717; 25 Oct 89 15:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02364; 25 Oct 89 15:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02233; 25 Oct 89 15:01 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa22469; 25 Oct 89 14:46 EDT Received: Wed, 25 Oct 89 14:45:43 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 25 Oct 89 14:45:43 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910252145.AA09555@aero4.larc.nasa.gov> To: info-iris@BRL.MIL, sgi!markb%denali.sgi.com@ucbvax.berkeley.edu Subject: Re: Third Party Disks for 4D/70GT We wouldn't have to buy 3rd party if SGI charge REASONABLE prices for options like disks and memory, instead of the 100% to 300% over fair market value! -- 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 aa03736; 25 Oct 89 17:54 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03159; 25 Oct 89 16:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03077; 25 Oct 89 16:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25436; 25 Oct 89 16:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19132; Wed, 25 Oct 89 12:50:41 -0700 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: 25 Oct 89 16:25:51 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Daisy-chained SCSI's on PI Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone had any success daisy-chaining one or more extra SCSI drives on a Personal IRIS? How about with non-SGI-purchased drives? I would appreciate knowing about any drives that are known to work.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04127; 25 Oct 89 19:16 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03997; 25 Oct 89 18:55 EDT Received: from vat.brl.mil by VMB.BRL.MIL id aa03974; 25 Oct 89 18:39 EDT Date: Wed, 25 Oct 89 18:18:05 EDT From: "John R. Anderson" (VLD/ASB) To: Knobi der Rechnerschrat cc: info-iris@BRL.MIL Subject: Re: Reading fortran "unformatted" files from C on the 4D. Message-ID: <8910251818.aa09277@VAT.BRL.MIL> Martin Knoblauch writes: > for(iz=0;iz nitem = fread(&dummy,4,1,fp); > fread(&i1,sizeof(int),1,fp); > fread(&i2,sizeof(int),1,fp); > fread(&i3,sizeof(int),1,fp); > fread(&farr[0],sizeof(float),3,fp); > nitem = fread(&dummy,4,1,fp); > } Note that although this will work on an IRIS 4D, not all fortran compilers create "unforamtted" files with the record length repeated at the beginning and end of the record. I have seen some that only include the record length at the start of each record. So depending on this will create non-portable code. -John   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04667; 25 Oct 89 22:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04635; 25 Oct 89 22:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04625; 25 Oct 89 22:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29083; 25 Oct 89 22:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA13036; Wed, 25 Oct 89 19:02:03 -0700 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: 25 Oct 89 22:54:40 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Re: Reading fortran "unformatted" files from C on the 4D. Message-Id: References: <8910251818.aa09277@VAT.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Martin Knoblauch writes: > for(iz=0;iz nitem = fread(&dummy,4,1,fp); > fread(&i1,sizeof(int),1,fp); > fread(&i2,sizeof(int),1,fp); > fread(&i3,sizeof(int),1,fp); > fread(&farr[0],sizeof(float),3,fp); > nitem = fread(&dummy,4,1,fp); > } In article <8910251818.aa09277@VAT.BRL.MIL> jra@BRL.MIL ("John R. Anderson", VLD/ASB) replies: >Note that although this will work on an IRIS 4D, not all fortran >compilers create "unforamtted" files with the record length repeated >at the beginning and end of the record. I have seen some that only >include the record length at the start of each record. So depending >on this will create non-portable code. > -John That's why you have to use the same C routines to write the data, too.... Having IEEE binary compatibility does not do you any good if the record structures differ, and only C allows you to be absolutely specific about what you are writing and reading.... By the way, on the 4D machines, the control words can be eliminated by writing the file as "access='direct'" rather than "access='sequential'". Of course all the records have to be the same length in this case.... Direct access files have _no_ record marks of any type -- they are just like the "form='binary'" files on the IRIS 3000, and in fact are transportable between FORTRAN applications on the two families of machines.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04822; 25 Oct 89 23:16 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04761; 25 Oct 89 23:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04715; 25 Oct 89 22:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29143; 25 Oct 89 22:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14355; Wed, 25 Oct 89 19:21:29 -0700 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: 25 Oct 89 22:26:14 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: news_server set uid to root Message-Id: <1115@odin.SGI.COM> References: <1304@uvm-gen.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The news_server is suid root so it can mpin one of its pages to prevent being swapped out and so it can set itself a non-degrading priority. If you run it non-suid root it still works, as you've observed, but you suffer a small performance loss. To run a gl program behind the console window will require "massive system hacks". Also when you see release 3.2 with pandora (visual login) you won't want your gl background anymore. -- 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 aa05357; 26 Oct 89 1:19 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05157; 26 Oct 89 0:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05143; 26 Oct 89 0:23 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29702; 26 Oct 89 0:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19593; Wed, 25 Oct 89 20:47:53 -0700 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: 26 Oct 89 03:40:51 GMT From: Timothy Hall Organization: Boston Univ. Computer Graphics Lab Subject: remote graphics usage Message-Id: <41208@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL With the recent talk of preventing a person not on the console from running a graphics job...... I often want to run a remote (not logged into the console) graphics program. Is there a way I can do this without 4sight running? (The console waiting for a login or sombody logged into the console with NOGRAPHICS) -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06183; 26 Oct 89 5:45 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06144; 26 Oct 89 5:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab06139; 26 Oct 89 5:23 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01510; 26 Oct 89 5:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07134; Thu, 26 Oct 89 01:52:14 -0700 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: 25 Oct 89 23:38:28 GMT From: Ted Wilcox Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Preventing remote graphics use Message-Id: <1119@odin.SGI.COM> References: <8910232017.AA01137@aero4.larc.nasa.gov>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article elkins@topaz.rutgers.edu (George Elkins) writes: >Idea: whenever a person logs in thru the console, just > chmod go-w /dev/console >and then only the current console login can write to >that device. Would this work? Nope. This would only prevent anyone else from sending text to the console wsh window on the screen. Everyone would still have access to any graphics program. Ted. ted@sgi.com {sun|decwrl|pyramid|ucbvax}!sgi!ted   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06248; 26 Oct 89 5:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac06144; 26 Oct 89 5:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac06139; 26 Oct 89 5:23 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01515; 26 Oct 89 5:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07154; Thu, 26 Oct 89 01:52:57 -0700 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: 26 Oct 89 00:34:40 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: 4Sight configuration Message-Id: <1121@odin.SGI.COM> References: <8910231741.aa10720@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910231741.aa10720@VMB.BRL.MIL>, butler@BRL.MIL ("Lee A. Butler", VLD/VMB) writes: > I'v just about managed to do away with the toolchests and the WorkSpace from > my 4Sight display (I like all my window ops on a pop-up menu). One thing I > can't seem to do is get Icons to automatically go to the corners of the > display. 4Sight seems to have a wired in allowance of space on the left for > toolchests, and space on the right for the "WorkSpace" window. Has anyone > gotten around this without modifying the system files? I readily admit to > being a neophyte at writing PostScript, so I may be missing something obvious. Put something like the following in your user.ps file. % % Personalize the icon layout % % Left Bottom Width Height 0 0 WORKSPACE-LEFT RGB-TOP /newarea IconTiler send This makes an icon area from the left hand edge over to where the default workspace window starts. The area is the full height of the screen. I also add the following so my icons go down the screen instead of across: /upperleft /corner IconTiler send /vertical /direction IconTiler send > > On a related note, does anyone have any recommendations for books or > documentation on "Introductory NeWS/4Sight?" I've got the books from Adobe, > but NeWS seems to be both more and less than the PostScript in those books. > The SGI manuals seem to deal mostly with programatic interfaces to 4Sight. Try "The NeWS Book" by Arden, Gosling and Rosenthal published by Springer-Verlag. It gives a good introduction and a description of the PostScript extensions that goes beyond that in the 4Sight (and NeWS) manuals. -- 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 aa06438; 26 Oct 89 6:27 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06144; 26 Oct 89 5:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06139; 26 Oct 89 5:23 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01508; 26 Oct 89 5:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07141; Thu, 26 Oct 89 01:52:34 -0700 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: 25 Oct 89 23:52:14 GMT From: Michael Toy Subject: ADD to <1115@odin.SGI.COM> news setuid root Message-Id: <1120@odin.SGI.COM> References: <1115@odin.SGI.COM>, <1304@uvm-gen.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL NeWS is no longer non degrading priority, nor does it mpin() to avoid swapping. It is setuid root so that it can 1) make the schedctl() call so that it isn't swapped (dubious value) 2) Kill any graphics process when "Quit"ing or Zapping a window Michael Toy   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00293; 27 Oct 89 0:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00088; 27 Oct 89 0:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16529; 26 Oct 89 23:30 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20472; 26 Oct 89 23:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA10169; Thu, 26 Oct 89 19:49:04 -0700 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: 25 Oct 89 17:01:17 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: The memory eater strikes back (2nd attempt to get attention) Message-Id: <605@voodoo.UUCP> References: <8910210901.aa24434@SMOKE.BRL.MIL>, <89Oct21.211825edt.3287@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Oct21.211825edt.3287@neat.cs.toronto.edu> moraes@CS.TORONTO.EDU (Mark Moraes) writes: >Nope. Even if you remove all libraries except for -lmalloc, it still >grows. You can see the problem over only a couple of iterations by >printing the value of sbrk(0) after every loop. The break will grow >steadily when using -lmalloc or amalloc/afree from -lmpc. With libc >malloc, the BSD4.3 malloc or any other working malloc, the value stays >constant after the first iteration. > >>b) Is it a bug? >> - known? >> - fixed when? > >Looks like a bug. Not fixed in Irix 3.2, it seems. Actually, it seems that it IS fixed in 3.2: I'm running it right now on a 4D/70GT with 8MB and Irix 3.2 -- no problems. After the first iteration, the value of sbrk(0) remained constant. On a 4D/70G with 8MB running Irix 3.1, the value of sbrk does indeed grow, and after 60 iterations, it REALLY slows down. However, by inserting mallopt(M_MXFAST, 0) in mem.c before the main loop, the program works as desired under 3.1. -- Mike York Boeing Computer Services, Renton, Washington (206) 234-7724 uw-beaver!ssc-vax!voodoo!zombie   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08473; 26 Oct 89 9:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07676; 26 Oct 89 8:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac07575; 26 Oct 89 8:26 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02721; 26 Oct 89 8:08 EDT Received: Thu, 26 Oct 89 08:07:41 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 26 Oct 89 08:07:41 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910261507.AA11809@aero4.larc.nasa.gov> To: info-iris@BRL.MIL, sgi!shinobu!odin!bangles!ted@ucbvax.berkeley.edu Subject: Re: Preventing remote graphics use I thought that was the case. I didn't think using chmod on /dev/console would work, but I wasn't sure. Is there a solution? There dosen't appear to be one. -- 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 aa13664; 26 Oct 89 16:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13398; 26 Oct 89 15:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13371; 26 Oct 89 15:41 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12965; 26 Oct 89 15:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11290; Thu, 26 Oct 89 12:02:48 -0700 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: 26 Oct 89 17:22:48 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Fair Market Value Message-Id: <43607@sgi.sgi.com> References: <8910252145.AA09555@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910252145.AA09555@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > We wouldn't have to buy 3rd party if SGI charge REASONABLE prices > for options like disks and memory, instead of the 100% to 300% over > fair market value! > -- Next time you get a chance, compare our pricing against the competitions'. Then talk about fair market value. When I have looked at other computer vendors' prices, it seems that we have been sort of in the middle; that is, not as high as some, nor as low as others. As far as workstations go, it is probably safe to say that our performance is better than most if not all in the area of disk I/O today, IMHO. It is often difficult to understand why a computer vendor sells a disk for more than you could buy one off-the-shelf. It simply costs us money to develop the s/w to run them, evaluate the h/w to select the best, work on performance tuning, ensure the best quality we can provide, do the burn-in, run the diagnostics, and so on. That is, we have actually prov- ided the tools to run the thing, gotten safety and FCC (and other) approvals that are required by our government (and others). Folks who sell off-the shelf stuff don't have to do all this. They don't add value, hence can't honestly ask you to pay for that. Hope that helps to understand the pricing. On the other hand one can not help but want to save $ when possible.... 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 aa14575; 26 Oct 89 17:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13398; 26 Oct 89 15:54 EDT Date: Thu, 26 Oct 89 15:39:29 EDT From: Lee A. Butler (VLD/VMB) To: info-iris@BRL.MIL Subject: Re: 4Sight configuration Message-ID: <8910261539.aa13240@VMB.BRL.MIL> Many thanks to all who responded to my request. I have located the 4Dgifts directory, and it has the examples and explanations I was looking for. Thanks also to those who suggested I get a copy of "The NeWS Book" by Arden, Gosling and Rosenthal. 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 aa15378; 26 Oct 89 18:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14918; 26 Oct 89 17:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14827; 26 Oct 89 17:38 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15573; 26 Oct 89 17:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18329; Thu, 26 Oct 89 14:00:10 -0700 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: 26 Oct 89 20:16:25 GMT From: Stephen Smith Organization: NASA Ames Research Center, California Subject: multi-volume tar/cpio Message-Id: <5432@eos.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to archive filesystems larger than one 1/4" cartridge tape on both 2-3000 and 4D series machines. I'm sure this has been discussed before, but I am not a regular on this group,i.e., be kind. E-mail is fine, I'll summarize and post responses ... Thanks in advance. --------------------------------- Internet: ssmith@eos.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15727; 26 Oct 89 20:49 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15555; 26 Oct 89 19:46 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15541; 26 Oct 89 19:33 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17884; 26 Oct 89 19:15 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA25885; Thu, 26 Oct 89 16:09:29 -0700 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: 26 Oct 89 23:04:45 GMT From: Steven Lynch Subject: Third Party Disks for 4D/25 Message-Id: <2541@munnari.oz.au> References: <8910252145.AA09555@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is anyone out there using third party disks of around 700Mb (or more) on a 4D/20(25) ? If so what type of disk ? Did you have any problems ? What were the format parameters that you found successful ? What should I look out for ? Thanks Steven .......................................................................... Steven Lynch Mail: sl@cs.mu.OZ.AU Snail: The University of Melbourne, Phone: +61 3 344-4045 Department of Computer Science, Fax: +61 3 348-1184 Parkville, Vic, 3052, Australia ..........................................................................   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16308; 26 Oct 89 22:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16234; 26 Oct 89 22:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16203; 26 Oct 89 22:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19864; 26 Oct 89 22:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA06831; Thu, 26 Oct 89 18:57:46 -0700 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: 26 Oct 89 20:33:00 GMT From: Steve Cook Organization: RDA Logicon, in good ole Sunny California Subject: Re: Want X11 help Message-Id: <6356@tacky.UUCP> References: <1980@bacchus.dec.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL in article <1980@bacchus.dec.com>, klee@chico.pa.dec.com (Ken Lee) says: > Xref: tacky comp.windows.x:9336 comp.sys.dec:1659 comp.sys.sgi:740 comp.org.decus:401 > > O'Reilly and Associates, *The X Window System Series*, 4 volumes, ISBN > 0-937175-26-9, 0-937175-27-7, etc. Does this mean that the O'reilly book on the Xt Intrinsics came out?? -- He who wonders discovers that this in itself is wonder. - M. C. Escher uunet!ames!elroy!tacky!steve   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16349; 26 Oct 89 22:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16146; 26 Oct 89 22:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16093; 26 Oct 89 21:52 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19396; 26 Oct 89 21:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA04388; Thu, 26 Oct 89 18:17:48 -0700 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 Oct 89 01:11:03 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: 3.2 Enhancements Message-Id: <21113@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Would someone post a description of enhancements and features that are a part of release 3.2? Thanks! Pablo pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research." -, _/: \ o.O , =(___)=   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03226; 27 Oct 89 8:51 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa02725; 27 Oct 89 8:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02604; 27 Oct 89 8:26 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24069; 27 Oct 89 8:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09195; Fri, 27 Oct 89 04:51:56 -0700 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: 26 Oct 89 19:47:03 GMT From: Reid Ellis Organization: Alias Research -- the cutting edge in Jaggie technology Subject: gcc and g++ on a 4D Message-Id: <562@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I managed to get gcc to link and everything, but then when I tried to compile, it dumped core. dbx had this to say: 0 .kill.kill(0x10022118, 0x1c, 0x0, 0x10020908, 0x10057948, 0x4a4f58) ["kill.s":17, 0x4b9db4] 1 .abort.abort(0x0, 0x1005aec0, 0x10057948, 0x44f468, 0x1c, 0x4a5274) ["abort.c":36, 0x4b5648] 2 output_operand_lossage(str = 0x1000c374 = "operand number missing after %-letter") ["final.c":1242, 0x4a4f54] 3 output_asm_insn(template = 0x1000fd00 = "addi%u\t%0,%1,%x2\t#subsi3\t%1,%d3 -> %0", operands = 0x7fffac68) ["final.c":1320, 0x4a5270] 4 output_7(operands = 0x1001a018, insn = 0x10022128) ["insn-output.c":124, 0x4b0dac] 5 .final.final(first = 0x10021c70, file = 0x10012de0, write_symbols = NO_DEBUG, optimize = 0, prescan = 0) ["final.c":897, 0x4a4490] 6 rest_of_compilation(decl = 0x10055890) ["toplev.c":1514, 0x419e20] 7 finish_function() ["c-decl.c":3647, 0x40ddd0] 8 yyparse() ["bison.simple":414, 0x400960] 9 compile_file(name = 0x7fffc7ff = "/tmp/cca08205.cpp") ["toplev.c":1014, 0x418bcc] 10 main(argc = 7, argv = 0x7fffc71c, envp = 0x7fffc73c) ["toplev.c":1795, 0x41a8c8] Now the "operand number missing after %-letter" to me seems to be saying that the mips.md file is incorrect. When I try compiling other files, I get similar errors. [i.e. calls to output_operand_lossage with missing operand numbers after %'s] Any pointers/help would be greatly appreciated. Any additional help on how to get g++ running would be doubly so. Thanks in advance, Reid --- Reid Ellis, 264 Broadway Avenue, Toronto ON, M4P 1V9, Canada rae%alias@csri.utoronto.ca, rae@geac.uucp, rae@ziebmef.uucp, rae@gpu.utcs.utoronto.ca, rae@tnir.uucp +1 416 487 1383   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02060; 28 Oct 89 11:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01927; 28 Oct 89 10:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01899; 28 Oct 89 9:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17964; 28 Oct 89 9:48 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA01170; Sat, 28 Oct 89 06:40:26 -0700 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 Oct 89 00:53:11 GMT From: Kian-Tat Lim Organization: California Institute of Technology, Pasadena, CA Subject: CG2 genlock board with Iris 4D/240GTX Message-Id: <12379@cit-vax.Caltech.Edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have been attempting to connect our Iris 4D/240GTX with CG2 genlock board to an NTSC monitor. At first, we had no success following the information in "Using the Composite Video/Genlock Board". We consulted SGI, who faxed us "Set Up/Integration of the CG2 board", a 25 page document. We were then able to produce a picture on the monitor, but only when the SYNC output on the Iris was connected to the external sync input of the monitor. The picture contains numerous spurious horizontal lines, making it unusable for our application. This problem occurs in both NTSC mode [setmonitor(NTSC);] and CG2 mode [setvideo(DE_R1, DER1_G_170 | DER1_UNBLANK); setvideo(CG_MODE, CG2_M_MODE2);]. Every graphics-related board in the machine has been swapped; only the CPU and IO boards have not been changed out. We are still talking to SGI, but I was wondering if anyone else has any experience with this board or with this particular problem. -- Kian-Tat Lim (ktl@wagvax.caltech.edu, KTL @ CITCHEM.BITNET, GEnie: K.LIM1)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00621; 27 Oct 89 1:52 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00594; 27 Oct 89 1:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00572; 27 Oct 89 1:30 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21794; 27 Oct 89 1:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17999; Thu, 26 Oct 89 22:03:38 -0700 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 Oct 89 04:22:35 GMT From: "Jeff P.M. Hultquist" Organization: NASA Ames Research Center, Moffett Field, CA Subject: screen-save with colormap and RGB modes Message-Id: <3599@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am using a Personal Iris running IRIX 3.1 ... For making screen-dumps, I have been using the program 'scrsave' (which is in '/usr/people/4Dgifts/...'). This works fine for windows which are in colormap mode, but it doesn't grab the proper color-components for windows which are using RGBmode. The source for 'scrsave.c' contains a call to 'gl_readscreen', which appears to be intended to handle pixels regardless of their display mode. This function is not listed in the man pages; however, it *is* in '/usr/lib/libgl.a'. So ... what gives? * Can I find the displayed color of a pixel regardless of its display mode? * If so, how? * If gl_readscreen is the right thing to be using for this, why is my copy broken? Solutions (or even hints) will be warmly welcomed; send mail to me and I will summarize. -- Jeff Hultquist hultquis@nas.nasa.gov (415) 694-4970   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02555; 27 Oct 89 8:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01678; 27 Oct 89 7:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01670; 27 Oct 89 7:10 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa23298; 27 Oct 89 6:47 EDT Received: from DS0RUS1I by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1588; Fri, 27 Oct 89 06:48:13 EDT Received: by DS0RUS1I (Mailer R2.04) id 0062; Fri, 27 Oct 89 11:47:43 MEZ Date: Fri, 27 Oct 89 11:43:40 MEZ From: "Dr. Heinz W. Poehlmann" Subject: ar To: info-iris@BRL.MIL Message-ID: <8910270647.aa23298@SMOKE.BRL.MIL> Hello, I've some problems with 'ar'. I'm working on a 4D/20G with System Level 3.1D . Problem: ar qv `lorder *.o | tsort` comes up with an error message: word too long when I have about 100 object files in the current directory. I guess this is a rather silly small limit for ar. Please report any hints/guesses also directly to ZRFL@DS0RUS1I.BITNET . Thanks in advance - Heinz   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03226; 27 Oct 89 8:51 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02725; 27 Oct 89 8:41 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02639; 27 Oct 89 8:27 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa24515; 27 Oct 89 8:17 EDT Received: Fri, 27 Oct 89 08:16:47 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 27 Oct 89 08:16:47 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910271516.AA15182@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Re: 3rd Party Hardware This is in responce to a message I got from an SGI employee. I was so annoyed by his pat "recorded" responce, I deleted it before replying. I don't even remember who sent the mail. NO, SGI's pricing does not make sence. Why should we pay SGI $22,000 for 24Mb of memory and have only a 90 day warranty, when we can buy the same amount of memory from someone else for less than $6000 and get a lifetime replacement garantee? Why should we pay SGI twice as much for a disk and get a 90 day warranty when we can get a year warranty? Your 'broken record' excuses are meaningless. -- Brent   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04200; 27 Oct 89 15:31 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa02805; 27 Oct 89 14:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02655; 27 Oct 89 13:49 EDT Received: from ew09.nas.nasa.gov by SMOKE.BRL.MIL id aa02440; 27 Oct 89 13:21 EDT Received: by ew09.nas.nasa.gov (5.61/1.34) id AA19806; Fri, 27 Oct 89 10:22:04 -0700 Date: Fri, 27 Oct 89 10:22:04 -0700 From: "Eric L. Raible" Message-Id: <8910271722.AA19806@ew09.nas.nasa.gov> To: info-iris@BRL.MIL Subject: NeWS emacs interface Reply-To: raible@orville.nas.nasa.gov Has anyone gotten either ps-emacs or any other NeWS interface to gnu emacs working on 4D's? I tried it a while ago, but never got the mouse to work properly. - Eric   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05946; 27 Oct 89 17:53 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05796; 27 Oct 89 17:32 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa05792; 27 Oct 89 17:22 EDT Date: Fri, 27 Oct 89 17:20:38 EDT From: Phil Dykstra To: info-iris@BRL.MIL Subject: SGI Disk Performance Message-ID: <8910271720.aa15354@SPARK.BRL.MIL> I kept hearing Mark Bradley say that SGI had about the best disk performance in the business, so I finally decided to test it out. Using a Personal Iris (SGI 4D/25G) with a SCSI controller and disk, IRIX 3.2, and the read/write system calls, I got: 560 KBytes/sec on writes 1040 KBytes/sec on reads (~3200 KBytes/sec on reads out of the disk cache) (K=1000, actual peak values were slightly higher, average a little lower) I/O speed was nearly independent of read/write size over a range of 1KB to 1MB. So, how does that compare? In short, that's the best darn SCSI disk I have ever seen (but then I'm used to the little Sun SCSI drives, which peak at about 240KB/sec for reads and writes). Here are some perhaps UNFAIR comparisons: Sun 3/280, SunOS 4.0.3, the Xylogics 3MB/sec SMDE controller, CDC 9720 drives: 930-1540 KBytes/sec on writes (1k - 8k/1M) 1330-1540 KBytes/sec on reads (~4760 KBytes/sec on reads out of the disk cache) Cray-2, Unicos 5, DD-49 drives :-) ~10000 KBytes/sec on reads and writes ~45000 KBytes/sec on reads and writes from the 4 way striped /tmp. Disclaimers: (1) these numbers are hard to measure, especially when large memory disk cacheing is going on, so don't take this as gospel, (2) the Cray-2 numbers are from memory (I did actually measure it, but the machine wasn't up right now), (3) when our SGI 4D/280's with the Xylogics controllers are installed I will measure those disks (that will be a more fair comparison to the Sun). Summary: SGI has the best SCSI disks I have ever seen. I have not yet measured their non-SCSI drives. - Phil ps: If someone wants my test program they are welcome to it.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02002; 28 Oct 89 10:40 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01963; 28 Oct 89 10:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01945; 28 Oct 89 10:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17980; 28 Oct 89 9:55 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA01541; Sat, 28 Oct 89 06:44:37 -0700 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 Oct 89 02:52:06 GMT From: Jean-Francois Lamy Subject: Re: Third Party Disks for 4D/25 Message-Id: <89Oct27.225152edt.2687@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have seen several cases where third party hardware was actually making bugs in the vendor's OS show up more dramatically. This may have actually saved the vendor some money and a lot of hair investigating irreproducible bug reports that where transient when their own equipment was being used (for example, Revision 14 of the Sun 4/280 CPU board was the first one that could support both X.25 (synchronous I/O) and stick to the VME specs well enough for a Ciprico Rimfire board (and no doubt others) to run at its design speed). Neither of these things were "supported" by Sun or done with Sun software, but there is no denying that the bugs were there, in the hardware, all along! I would fully expect a company touting a SCSI driver (which is part of Irix) to fix it in the event that a bug in the driver gets found, even if none of the device they sell triggers the bug, or else to be honest enough start calling the product an "SCSI-like driver" (that would have to happen for SCSI-like devices too :-). Part of the selling point for SCSI is the wide availability of useful devices. Exabytes caused customers to complain about bugs in the vendors' SCSI software, and in the drives' firmware. And the vendors who fixed their own bugs and worked around bugs in hardware their customers wanted got happier customers, and presumably more sales. And then some vendors even started supporting and selling them... If I was a vendor and someone I can reasonably trust told me that doing something reasonable with a reasonably common device used to work and doesn't, I'd have someone have a look under the hood. I fully understand that my definition of reasonable may bear little resemblance to that of a company with finite resources and trying to turn in a profit for this term. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02497; 28 Oct 89 14:49 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02363; 28 Oct 89 13:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02343; 28 Oct 89 13:42 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18601; 28 Oct 89 13:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14319; Sat, 28 Oct 89 10:16:12 -0700 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 Oct 89 22:49:26 GMT From: "Ian S. Small" Organization: University of Toronto, CSRI Subject: Re: Third Party Disks for 4D/25 Message-Id: <1989Oct27.184925.13487@jarvis.csri.toronto.edu> References: <8910252145.AA09555@aero4.larc.nasa.gov>, <2541@munnari.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A word of warning re third party disks - what works now may not work tomorrow. We have been running Wren V's on both Personal Irises and Power Irises without too much distress after some initial teething problems. One of the Personal Iris/Wren V combinations just upgraded to 3.2 and guess what? His Wren V doesn't behave any more. SGI's response appears to be: "We didn't support it, it's your problem." We have only tried to upgrade the one machine, so cannot determine if this problem is endemic across the entire line, or whether it is just Personal Irises, or just 4D/25's for that matter. But when the manufacturer breaks things that used to work (and doesn't offer any help in fixing the problem), that's good cause for customer dissatisfaction. While we are used to doing a lot of hacking, and aren't terribly bothered by the prospect of doing a little more, hacking to fix things that shouldn't have to be fixed is simply annoying. Seems to me that the glow that appeared about SGI products and SGI willing-to-pleaseness (gack, what a word!) around about the time of the Personal Iris introduction is fast disappearing. We should know better, of course, having been original owners of a 2400T, but hey, one could always hope. -- Ian S. Small (416) 978-6619 Dynamic Graphics Project Computer Systems Research Institute BITNET: ian@dgp.utoronto University of Toronto EAN: ian@dgp.toronto.cdn Toronto, Ontario M5S 1A4 UUCP/CSNET: ian@dgp.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02577; 28 Oct 89 15:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02443; 28 Oct 89 14:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02427; 28 Oct 89 14:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18752; 28 Oct 89 14:02 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16459; Sat, 28 Oct 89 10:50:06 -0700 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 Oct 89 00:16:34 GMT From: Keith Bierman - SPD Advanced Languages Organization: Sun Microsystems, Mountain View Subject: Re: Third Party Disks for 4D/25 Message-Id: <126991@sun.Eng.Sun.COM> References: <8910252145.AA09555@aero4.larc.nasa.gov>, <2541@munnari.oz.au>, <1989Oct27.184925.13487@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Oct27.184925.13487@jarvis.csri.toronto.edu> ian@dgp.toronto.edu (Ian S. Small) writes: > >... story of 3rd party drives.. > >But when the manufacturer breaks things that used to work (and doesn't >offer any help in fixing the problem), that's good cause for customer > I'm not in the habit of defending SGI :> , but here goes: 1) SGI offered to solve your problem originally; there is a disk drive (or several) in their price list. I have little doubt that SGI would ensure that it worked, and would continue to do so. 2) You chose to save money ... you bought a drive from someone else. That someone else gets to save money by not offering service, support, quality control, etc. 3) You blame SGI for not doing the job of #2. This seems unfair. In case there is any doubt; SunManagement does not endorse this, or any other defense of SGI (:>). Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04003; 29 Oct 89 1:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03941; 29 Oct 89 0:59 EDT Received: by VMB.BRL.MIL id aa03936; 29 Oct 89 0:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03610; 28 Oct 89 22:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21373; 28 Oct 89 22:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA12874; Sat, 28 Oct 89 19:18:52 -0700 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 Oct 89 04:06:48 GMT From: Dave Olson Subject: Re: Third Party Disks for 4D/25 Message-Id: <1155@odin.SGI.COM> References: <8910252145.AA09555@aero4.larc.nasa.gov>, <2541@munnari.oz.au>, <1989Oct27.184925.13487@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL ian@dgp.toronto.edu (Ian S. Small) writes: >A word of warning re third party disks - what works now may not >work tomorrow. We have been running Wren V's on both Personal Irises >and Power Irises without too much distress after some initial teething >problems. >One of the Personal Iris/Wren V combinations just upgraded to 3.2 and >guess what? His Wren V doesn't behave any more. SGI's response appears >to be: "We didn't support it, it's your problem." We have only tried to >upgrade the one machine, so cannot determine if this problem is endemic >across the entire line, or whether it is just Personal Irises, or >just 4D/25's for that matter. As I have replied to many people privately, we discovered the hard way that CDC made some mistakes in the firmware on the Wren IV, V, VI, and possibly VII SCSI drives. It was first discovered (by us) on the Wren VI 760 Mb drive; after we discovered it, it showed up in new releases of firmware for the IV and V models. If you are experiencing SCSI bus timeouts, this is almost certainly the problem. Contact your vendor to get your DRIVE firmware upgraded. CDC has released new firmware that resolves the problem for all the drives listed above. The 3.2 release supports synchronous SCSI if the drive also supports it (on the 4D/20 and 4D/25 only). All the Wren V drives do support it. On the 4D25 in particular, we have a very high transfer rate. This exposed the bugs in the CDC firmware. If you want to mail me which Wren V you have, and it's firmware rev (boot the system with bootmode set to d, or use the 'ide' program), I can try (unofficially) to determine if you have the faulty firmware. I would like to hear just who it was at SGI that gave you the reply you indicated above. Our support people generally contact me when SCSI issues arise, and I haven't had your problem referred to me. I'm posting this reply rather than mailing, specifically to let people know that we DO try to support our customers, even when unsupported hardware is used (as far as is reasonable, of course). Particularly in cases like this, where there is a known problem, we can try to help. Issues like this are one of the reasons why supported hardware costs more when purchased from a systems vendor; we DO support it with extensive, and continuing, testing and qualification work. Dave Olson It's important to keep an open mind, but not so open that your brains fall out. -- Stephen A. Kallis, Jr.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00548; 29 Oct 89 14:30 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00444; 29 Oct 89 13:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id bc00181; 29 Oct 89 13:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25689; 29 Oct 89 11:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA20334; Sun, 29 Oct 89 08:02: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: 29 Oct 89 15:39:02 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: 3.2 upgrade: word of warning Message-Id: <2858@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Just a word of warning: if your SGI machines are being ypserved from non-SGI ypmaster (ours is a Sun 4/280) and you're planning on upgrading to 3.2, make sure that /etc/services AND /etc/rpc on the ypmaster are merged with the versions on the SGI. Otherwise things break, like the new WorkSpace manager. Another minor "gotcha" that bit me was in the Visual Administration tool. If you let it configure your network for you, it just asks for a hostname and IP address and defaults the other parameters to what it thinks they should be. It was wrong in our case; we use a broadcast address of 128.61.0.0, not 128.61.255.255. In the Visual Administration tool's defense, I will say that I found it to be fairly robust in all other areas. I don't normally use such tools, having learned to distrust them, but whenever I come up against one, I usually give it a try to see how well it works. I prefer the old, "tried-and-true" method of mucking with the system startup scripts and system configuration files directly. SGI's, although somewhat limited in what sysadm tasks it allowed you to do, was pretty solid and didn't even complain when I did things behind its back. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00610; 29 Oct 89 14:46 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00444; 29 Oct 89 13:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id az00181; 29 Oct 89 13:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25337; 29 Oct 89 9:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16425; Sun, 29 Oct 89 06:32: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: 29 Oct 89 12:57:54 GMT From: Axel Dirksen Organization: Axel Dirksen ( system & software consulting, Berlin ) Subject: porting news B to Iris Message-Id: <761@txlad.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, I experienced difficulties porting news software rel. B 2.11 to Iris 80GTX or Personal Iris. Did someone do that already ? Any hints are appreciated. So far the compile went through but executables produced nothing but core dumps and a short debugging look with edge and dbx didn't show the problem. It looks like there might be a simple answer to this. I'm not too familiar with the Unix port SGI did. Axel -- Axel Dirksen {{uunet!unido},{pyramid}!tub,tmpmbx}!txlad!ad   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00610; 29 Oct 89 14:46 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00548; 29 Oct 89 14:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00518; 29 Oct 89 14:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26287; 29 Oct 89 14:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28245; Sun, 29 Oct 89 10:54: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: 29 Oct 89 18:50:34 GMT From: Mike Cohen Organization: Center for Adaptive Systems Subject: Questions about NeWS Message-Id: <41489@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is a question re NeWs. I would like to write a simple interface which took a sgimenu item placed you on a line in the window menu and queried for a response. Using the data for from this response is started up another program. What I have in mind is a menu item for edge which would request the name of the program to be debugged then did a {(edge ) forkunix}. All the ways I see to do this involve reasonable involved programming for such a simple request. (Like setting up an event handler for each character which is silly for such a simple task). I guess I have in mind something like an X11 widget. If such is not available as a Litemenu or SGIMENU or Toolchest method it ought to be. With this in mind I'd like to report some bugs: 1. Any killing of the console window by an external process (after /etc/gl/startconsole, makes reconnection of the console impossible via restart. What happens is one gets a console window connected to device ? instead of /dev/console. 2. psh executive console 80 string readline Running a postscript shell which has such a code in it hangs in the readline echoing what it reads intermidably. 3. Starting edge from a postscript shell i.e. (edge) { (getenv EDGE) (edge ) exch append forkunix } in a menu entry or in psh produces an edge window which doesn't type out to the created window. The terminal settings are quite wierd. A dump is available on request. I can see know way of resetting the terminal properly I tried a (stty correct settings) forkunix. But this didn't work. I'm sure this is not all that difficult. I'm a fan of NeWS, my feeling about it is NeWS/X11 as EMACS/TECO. But the available NeWS docs except perhaps for the Sun ones are not terribly clear. In regard to Gosling's book, I find it quite useful, but elementary. Is the Sun NewS documentation any better than 4sight docs I have? The docs contain a useful set of implimented codes. But both demos and docs are woefully short on the type of example I would like to see, i.e. programming NeWS efficiently to interact with the rest of the operating system. -mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01451; 30 Oct 89 6:20 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01316; 30 Oct 89 6:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01301; 30 Oct 89 5:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02340; 30 Oct 89 5:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA12233; Mon, 30 Oct 89 02:33:35 -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: 30 Oct 89 03:56:37 GMT From: Eric A Pearce Organization: BD&HR (Beer Drinkers & Hell Raisers) Subject: Transcript/ditroff on Iris Message-Id: <1989Oct30.035637.6099@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I don't know if anybody gives a hoot, but Transcript does work on the SGI. I compiled it using the bsd setup. There is one ioctl to change in pscomm.c in the transcript package. I used Version 8 "titroff" for the ditroff required by psroff. You just comment out the "-t" option to ditroff in the "psroff" shell script. I can supply details or diffs if someone needs it. I was able use the bsd printer spooling software, since it has been ported to the Iris at BU. -e   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02772; 30 Oct 89 8:21 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa02496; 30 Oct 89 8:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02480; 30 Oct 89 8:01 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa04209; 30 Oct 89 7:54 EST Received: Mon, 30 Oct 89 07:53:42 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 30 Oct 89 07:53:42 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910301553.AA24237@aero4.larc.nasa.gov> To: chiba!khb@sun.com Subject: Re: Third Party Disks for 4D/25 Cc: info-iris@BRL.MIL Keith Bierman writes: "2) You chose to save money ... you bought a drive from someone else. That someone else gets to save money by not offering service, support, quality control, etc. " We wouldn't mind spending a little more for service, support, and quality control, but like I said 100% to 300% mark up is not reasonable. Futher more as far as quality control goes; we have a 3130 and the disk- tape drive controller went out. It was sent to SGI for repairs, when it came back it didn't work. We sent it back again, they sent us a brand new board, that didn't work. I wasn't until the 3rd time did we got a working board (fingers crossed). I don't call that good service or quality control. P.S. I hear SUN isn't quite as bad as SGI is as far as mark up is concerned. They only charge half the mark up that SGI does. -- 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 aa01609; 30 Oct 89 12:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01339; 30 Oct 89 12:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00636; 30 Oct 89 11:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10018; 30 Oct 89 10:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA26552; Mon, 30 Oct 89 07:42:03 -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: 30 Oct 89 14:53:35 GMT From: "ROBERT E. MINSK" Organization: Georgia Institute of Technology Subject: 3.2 colormap Message-Id: <9491@pyr.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have just upgraded our systems to version 3.2 of the operating system. I have several startup files that I use one of which sets up my window colors. SGI changed the default colormap making most of my windows almost unreadable (by the way, I agree with SGI reason for changing it.) Does anyone have a mapping of the first 256 entries in the 3.1 color map to the closest color map entries in 3.2? Thank you, -- ROBERT E. MINSK (Office of Computing Services) | Save the whales... | | collect the whole set | ARPA: ccoprrm@pyr.gatech.edu |-----------------------| uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!ccoprrm   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01609; 30 Oct 89 12:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01339; 30 Oct 89 12:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00832; 30 Oct 89 11:58 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa11832; 30 Oct 89 11:39 EST Received: Mon, 30 Oct 89 08:36:55 -0800 from AERO4.LARC.NASA.GOV by prandtl.nas.nasa.gov (5.61/1.2) Received: Mon, 30 Oct 89 11:38:33 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 30 Oct 89 11:38:33 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8910301938.AA25246@aero4.larc.nasa.gov> To: fsfacca@lerc08.lerc.nasa.gov Subject: Re: 3rd Party Hardware Cc: info-iris%brl.mil@prandtl.nas.nasa.gov I know the $6000 was high, but I thought I would err on the high side. :-) -- 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 aa01741; 30 Oct 89 12:39 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00646; 30 Oct 89 12:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad00449; 30 Oct 89 11:48 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa07191; 30 Oct 89 9:14 EST Received: Mon, 30 Oct 89 06:12:29 -0800 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Mon, 30 Oct 89 09:14:18 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 30 Oct 89 09:36:07 EST by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 30 Oct 89 09:36:07 EST From: Tony Facca Message-Id: <8910301436.AA16360@lerc08.lerc.nasa.gov> To: blbates@aero4.larc.nasa.gov Subject: Re: 3rd Party Hardware Cc: info-iris%brl.mil@prandtl.nas.nasa.gov "Brent L. Bates AAD/TAB MS294 x42854" writes: > NO, SGI's pricing does not make sence. Why should we pay SGI > $22,000 for 24Mb of memory and have only a 90 day warranty, when > we can buy the same amount of memory from someone else for less than > $6000 and get a lifetime replacement garantee? ^^^^^ Brent, Your point is well taken. However, you exaggerate. You can buy the same amount of memory from Clearpoint for around $4000. :-) -- ----------------------------------------------------------------------------- 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 ab02169; 30 Oct 89 13:11 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01962; 30 Oct 89 12:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01861; 30 Oct 89 12:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12958; 30 Oct 89 12:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA02272; Mon, 30 Oct 89 09:15: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: 30 Oct 89 17:09:43 GMT From: Tom Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: Emacs 18.52 on an Iris4d--problems with shell Message-Id: <20272@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are running Gnu Emacs 18.52 on an Iris 4d. There appears to be a problem in how "interrupt-shell-subjob" and functions of its ilk are operating. The behavior we see is that if one tries to invoke such functions, e.g. by typing C-c C-c in shell mode, then there is no effect on the subjob. The question I have is simply this: Is there a trick to setting things in the configuration files so that the interrupt functions behave correctly? I'm using the m-iris4d.h and s-iris3-6.h as posted in comp.sys.sgi many many months ago. Any takers? +----------------------------------------------------------------------+ |Thomas Russo | russo@chaos.utexas.edu | |Center for Nonlinear Dynamics, University of Texas at Austin | +----------------------------------------------------------------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00717; 30 Oct 89 17:08 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00089; 30 Oct 89 16:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03752; 30 Oct 89 14:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17100; 30 Oct 89 14:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09493; Mon, 30 Oct 89 11:10: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: 30 Oct 89 18:21:01 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: screen-save with colormap and RGB modes Message-Id: <43738@sgi.sgi.com> References: <3599@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3599@amelia.nas.nasa.gov>, hultquis@orville.nas.nasa.gov (Jeff P.M. Hultquist) writes: > I am using a Personal Iris running IRIX 3.1 ... > > For making screen-dumps, I have been using the program 'scrsave' > (which is in '/usr/people/4Dgifts/...'). This works fine for > windows which are in colormap mode, but it doesn't grab the proper > color-components for windows which are using RGBmode. The source > for 'scrsave.c' contains a call to 'gl_readscreen', which appears > to be intended to handle pixels regardless of their display mode. > This function is not listed in the man pages; however, it *is* in > '/usr/lib/libgl.a'. > > So ... what gives? > > * Can I find the displayed color of a pixel regardless > of its display mode? > * If so, how? > * If gl_readscreen is the right thing to be using for this, > why is my copy broken? I don't know a lot about this stuff, but I think that the reason the source to gl_readscreen isn't available is because it does some hardware dependent things to determine the graphics mode of the pixels. I have no idea why your copy doesn't work. Does the scrsave in /usr/sbin work? (Stuff beginning with 'gl_' is not guaranteed to work from platform to platform or even from release to release, and is not recommended for use.) Here's the 3.2 source for scrsave (from 4Dgifts): (Is it different?) thant ----------------------------------------------------------------------------- /* * scrsave - * Save a part of the screen in an image file. * * Paul Haeberli - 1988 */ #include "gl.h" #include #include "port.h" #include "image.h" char rbuf[2048]; char gbuf[2048]; char bbuf[2048]; short rs[2048]; short gs[2048]; short bs[2048]; main(argc,argv) int argc; char **argv; { int i, y, gotfirst; int x1, x2, y1, y2; if(argc!=2 && argc!=6) { printf("usage: scrsave outimage [x1 x2 y1 y2]\n"); exit(1); } if(argc==6) { x1 = atoi(argv[2]); x2 = atoi(argv[3]); y1 = atoi(argv[4]); y2 = atoi(argv[5]); } else { x1 = 0; x2 = XMAXSCREEN; y1 = 0; y2 = YMAXSCREEN; } foreground(); noport(); winopen("scrsave"); savescreen(argv[1],x1,x2,y1,y2); } savescreen(name,x1,x2,y1,y2) char *name; int x1, x2, y1, y2; { IMAGE *oimage; int xsize, ysize; int xorg, yorg; int temp, y, i; int pos, togo, n; xorg = MIN(x1,x2); yorg = MIN(y1,y2); if(xorg<0) xorg = 0; if(yorg<0) yorg = 0; xsize = ABS(x2-x1); ysize = ABS(y2-y1); if((xorg+xsize)>XMAXSCREEN) xsize = XMAXSCREEN-xorg; if((yorg+ysize)>YMAXSCREEN) ysize = YMAXSCREEN-yorg; xsize++; ysize++; oimage = iopen(name,"w",RLE(1),3,xsize,ysize,3); wmplanes(); screenspace(); for(y=0; y256) n = 256; cmov2i(xorg+pos,yorg+y); gl_readscreen(n,rbuf+pos,gbuf+pos,bbuf+pos); pos += n; togo -= n; } #else cmov2i(xorg,yorg+y); gl_readscreen(xsize,rbuf,gbuf,bbuf); #endif ctos(rbuf,rs,xsize); ctos(gbuf,gs,xsize); ctos(bbuf,bs,xsize); putrow(oimage,rs,y,0); putrow(oimage,gs,y,1); putrow(oimage,bs,y,2); } iclose(oimage); } -- There are 336 dimples on the standard golf ball.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01035; 30 Oct 89 17:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ad00717; 30 Oct 89 17:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac00518; 30 Oct 89 17:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19617; 30 Oct 89 15:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA13807; Mon, 30 Oct 89 12:18: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: 30 Oct 89 16:31:09 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Re: 3rd Party Hardware Message-Id: References: <8910301436.AA16360@lerc08.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8910301436.AA16360@lerc08.lerc.nasa.gov> fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) writes: >"Brent L. Bates AAD/TAB MS294 x42854" writes: >> NO, SGI's pricing does not make sence. Why should we pay SGI >> $22,000 for 24Mb of memory and have only a 90 day warranty, when >> we can buy the same amount of memory from someone else for less than >> $6000 and get a lifetime replacement garantee? > ^^^^^ >Brent, >Your point is well taken. However, you exaggerate. You can buy the same >amount of memory from Clearpoint for around $4000. :-) >Tony Facca | phone: 216-433-8318 Does anyone know what speed is required for the SIMM's in a Personal IRIS 4D/20 and 4D/25? For the NeXT machine, it is possible to find 1 MB 100 ns page-mode SIMM's for under $100! Since the 4D/20 is only running at 12.5 MHz and the NeXT is running at 25 MHz, the memory speed should be comparable (assuming that the Motorola chip is running on a multi-cycle memory access scheme). -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01035; 30 Oct 89 17:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ae00717; 30 Oct 89 17:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad00600; 30 Oct 89 17:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20720; 30 Oct 89 16:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16915; Mon, 30 Oct 89 13:03: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: 30 Oct 89 17:30:43 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: waiting for `man'........ Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone put together a replacement for the `man' command on the 4D machines? Every time I try to use it, I am amazed that a machine costing so much money can do something sooooo slowly! :-) Seriously, the `man' program is *much* too slow to be useful for online reference, and there has to be some reasonable way to replace it. Has anyone done this? The one (and only) thing that I liked about the Apollo DN10000 was that when you typed `man csh', it opened a window already filled with the first page of text in about 1 second. Going back to the SGI machine (even a 4D/240) was very painful.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac01035; 30 Oct 89 17:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ag00717; 30 Oct 89 17:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00666; 30 Oct 89 17:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21434; 30 Oct 89 16:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19029; Mon, 30 Oct 89 13:35:36 -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: 30 Oct 89 21:15:20 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Third Party Disks for 4D/25 Message-Id: <43751@sgi.sgi.com> References: <8910252145.AA09555@aero4.larc.nasa.gov>, <2541@munnari.oz.au>, <1989Oct27.184925.13487@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Oct27.184925.13487@jarvis.csri.toronto.edu>, ian@dgp.toronto.edu (Ian S. Small) writes: > A word of warning re third party disks - what works now may not > work tomorrow. We have been running Wren V's on both Personal Irises > and Power Irises without too much distress after some initial teething > problems. > > One of the Personal Iris/Wren V combinations just upgraded to 3.2 and > guess what? His Wren V doesn't behave any more. SGI's response appears > to be: "We didn't support it, it's your problem." We have only tried to > upgrade the one machine, so cannot determine if this problem is endemic > across the entire line, or whether it is just Personal Irises, or > just 4D/25's for that matter. > > But when the manufacturer breaks things that used to work (and doesn't > offer any help in fixing the problem), that's good cause for customer > dissatisfaction. While we are used to doing a lot of hacking, and aren't > terribly bothered by the prospect of doing a little more, hacking to > fix things that shouldn't have to be fixed is simply annoying. > > Seems to me that the glow that appeared about SGI products and SGI > willing-to-pleaseness (gack, what a word!) around about the time of > the Personal Iris introduction is fast disappearing. We should know > better, of course, having been original owners of a 2400T, but hey, > one could always hope. > -- > Ian S. Small (416) 978-6619 Dynamic Graphics Project > Computer Systems Research Institute > BITNET: ian@dgp.utoronto University of Toronto > EAN: ian@dgp.toronto.cdn Toronto, Ontario M5S 1A4 > UUCP/CSNET: ian@dgp.toronto.edu You should probably have whomever sold you that drive upgrade the firmware. 3.2 has some performance enhancements that we found (rather painfully) bring out some bugs in old, braindead, buggy drive f/w. It would be really nice if everyone tried as hard to determine the problem and its solution as they do trying to find someone to blame. You may have noticed that there are some of us here on the net who actually DO want to help you solve your problems. As for someone telling you that we don't support your drive, that person was probably doing as they were told. Support is a cost/profit center, too. They are also not privy to all of the information they would have needed to help you solve your problem. Anyhow, try to get your drives' f/w upgraded to the latest rev. It will probably work just fine. 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 aa01455; 30 Oct 89 18:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01395; 30 Oct 89 18:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01369; 30 Oct 89 18:12 EST Received: from indy.Princeton.EDU by SMOKE.BRL.MIL id aa22543; 30 Oct 89 17:44 EST Received: from fourier.Princeton.EDU by Princeton.EDU (5.58+++/2.22/mailrelay) id AA19665; Mon, 30 Oct 89 17:42:12 EST Received: by acm.princeton.edu (4.0/1.89) id AA03708; Mon, 30 Oct 89 17:49:13 EST Date: Mon, 30 Oct 89 17:49:13 EST From: Andrew Simms Message-Id: <8910302249.AA03708@acm.princeton.edu> To: gem.mps.ohio-state.edu!samsung!shadooby!mailrus!uflorida!stat!stat.fsu.edu!mccalpin@tut.cis.ohio-state.edu, info-iris@BRL.MIL Subject: Re: 3rd Party Hardware John D. McCalpin asked about memory for 4D/20, 4D/25: The best source I have found for memory is: 617/837-8877 Impediment Alex, the contact, can get 1x9 100ns SOJ simms for the personal iris at $120/megabyte. He sells an excellent product (Kensington) that has a lifetime replacement warranty. This week Alex should also have memory for the 4D/200 series (power series) at 25% of SGI's price (possibly less!). I highly recommend him because he is honest and ships on time (memory typically takes 3 days to arrive). --andrew simms p.s. For those who are curious, I have now installed over 40 MB of his memory without a single failure (longest operation time is 6 months). _________________________________________________________________________ Andrew Simms, System Manager Program in Applied and Computational Mathematics 218 Fine Hall, Washington Road ams@acm.princeton.edu Princeton, NJ 08544 609/258-5324 609/258-6227 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02431; 30 Oct 89 22:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab02364; 30 Oct 89 22:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02344; 30 Oct 89 21:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24939; 30 Oct 89 21:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08195; Mon, 30 Oct 89 18:29: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: 30 Oct 89 23:32:32 GMT From: George Travan Organization: Computing Services, Uni of Adelaide, Australia Subject: SLIP on SGI Message-Id: <591@sirius.ua.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i did'nt get any responses to my query as to whether SLIP was supported in SGI version of unix! i'm real keen though....anyone at sgi listening? can you run SLIP (serial line internet protocol) between sgi machines? helppppppp. --GeO George Travan University of Adelaide Box 498 G.P.O Adelaide,AUSTRALIA e-mail: george@frodo.ua.oz gtravan@sirius.ua.oz   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02431; 30 Oct 89 22:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac02364; 30 Oct 89 22:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02344; 30 Oct 89 21:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24943; 30 Oct 89 21:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07664; Mon, 30 Oct 89 18:22: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: 31 Oct 89 02:01:00 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: waiting for `man'........ Message-Id: <43773@sgi.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) writes: > Has anyone put together a replacement for the `man' command on the 4D > machines? Every time I try to use it, I am amazed that a machine > costing so much money can do something sooooo slowly! :-) > > Seriously, the `man' program is *much* too slow to be useful for > online reference, and there has to be some reasonable way to replace > it. Has anyone done this? > Dear John, (sorry, I couldn't resist :^) In the new 3.2 release, there is a completely rewritten version of 'man' which replaces the pitiful AT&T shell script. In addition to being faster (finds a man page in 1-2 seconds) it has the following features: From BSD: PAGER and MANPAGER environment variables for specifying alternative pagers for man output. Sorry, SGI doesn't supply less(1) though if you have it, you can use it. -M command line option and MANPATH environment variables for specifying alternate manual paths. New features modelled on those a popular competitor's man command: -T command line option for specifying an alternate formatting package. -t command line option for printing manual pages on default printer (see lpadmin(1) for setting default). The preformatted manual pages shipped by SGI will be printed as NROFF style output. If you have your own manual page sources and the TranScript(TM Adobe) (SGI Laser Printer) option, and the Documentor's Workbench (NROFF) option, the output will be formatted accordingly. New features which are SGI specific: Will search both AT&T System V style manual page trees and BSD manual page trees. In conjunction with the MANPATH/-M feature, you can NFS mount manual page trees from other manufacturers and read them on your IRIS-4D. The differences in manual page tree structures prevent this from happening the other way around. -w command line option just prints the path(s) of the matching manual page(s) instead of formatting them. This can be used within shell scripts or programs which need to search manual page trees. location of manual pages via regular expressions. Preformatted, pack'ed preformatted, compress'ed preformatted, and nroff source manual pages may be freely mixed in manual page trees. The man command determines the type of manual page automatically and selects the proper output filters automatically. This new manual page command is not a port of the BSD man or any other man command. The new SGI man was written from the ground up to support the special manual page tree and manual page format requirements of the SGI manual page trees. I'm sorry to say that the desparately desired -k and -w (apropos and whatis) features from BSD have not been implemented in the 3.2 man. As SGI's licensing agreements with AT&T require us to ship preformatted manual pages. There a couple of apropos and whatis scripts that work for the SGI specific manual pages floating around from users on comp.sys.sgi (info-iris). A robust and generic solution that handles any manual page tree should be available in an upcoming major release. > The one (and only) thing that I liked about the Apollo DN10000 was > that when you typed `man csh', it opened a window already filled with > the first page of text in about 1 second. Going back to the SGI > machine (even a 4D/240) was very painful.... > Using the new man command, you can create a script which will create a window like on the Apollo Dino 10 Billion. Try the following: ----- myman ------------------------------------------------------------------ # # See wsh(1) for additional flags for prepositioning the wsh or changing # other wsh attributes. -H is used to prevent wsh from disappearing at # upon hitting the end of the manual page. # wsh -H -c man $* ----- myman ------------------------------------------------------------------ > -- > John D. McCalpin - mccalpin@masig1.ocean.fsu.edu > mccalpin@scri1.scri.fsu.edu > mccalpin@delocn.udel.edu Yet another reason to upgrade to 3.2. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02574; 30 Oct 89 22:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02264; 30 Oct 89 21:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02222; 30 Oct 89 21:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24831; 30 Oct 89 21:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA06645; Mon, 30 Oct 89 18:10: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: 31 Oct 89 01:54:47 GMT From: Jim Helman Subject: minor security hole (tftp) Message-Id: <537@isl.stanford.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL ----------- After last fall's Internet worm, there was a flurry of people pointing out all sorts of security holes, big and small. Not surprisingly, now, almost a year later, most sysadmins (at least in Universities) have gone back to sleep. One of the small dangers pointed out last year was unrestricted tftp access. tftp uses the Trivial File Transfer Protocol (RFC 783), which is like ftp, but, well, more trivial. In particular, it requires no user authentication. The problem is that tftp allows anyone on your net, which in our case means the entire Internet, to access publicly readable files, including /etc/passwd. Also, there is a lesser risk from writing to publicly writable files. Actually, most machines have no need for tftp at all. Some need it when acting as a bootfile server, but this function only requires access to a few files, certainly not to every publicly readable file on a machine, which is the default. After the worm incident, I was surprised to see that SGI was still distributing IRIX configured for unrestricted tftp. I called it in as a bug report on 3.1D back in June. The support engineer seemed concerned about it, but it didn't change in 3.1G. We just got 3.2, and once again the installation procedure renabled unrestricted tftp. This may seem to be a very minor hole, but a surprising number of sysadmins create new accounts without passwords and users never get around to setting a password. Also, many encrypted passwords can be broken by dictionary searches. Worse still, some sloppy sysadmins leave field or diag accounts without passwords. For example, the first IRIS machine at Stanford to which I tftp'ed had an account with no password, a uid of 0, and /bin/csh as its shell. Very bad. Possible Solutions: If you don't need tftp, the easiest thing to do is to comment out the tftpd line in /usr/etc/inetd.conf. Be sure to repeat this after every software upgrade. But if you do need tftp, read on. In Sun's standard inetd.conf (SunOS 4.0 and later), tftp's access is restricted to the /tftpboot directory using a new -s switch they added to tftpd. I don't think SGI's tftpd has such a switch. Prior to 4.0, Sun distributed a tftpbootd as an alternative to the tftpd daemon. tftpbootd was a shell script which did a "chroot /tftpboot /usr/etc/tftpd," which restricted tftpd activities to a directory tree containing the bootfiles. The same trick will work under IRIX. However, if you try this trick and haven't used chroot before, be careful because you must: 1) Put a copy of /tftpd in /usr/etc/tftpd since chroot needs all executables under tftp's new root directory. You should do the same for /dev/console and /dev/log which might be accessed by tftpd. 2) Put a copy or hard link of the shared library /lib/libc_s in /lib/libc_s. 3) Have chroot execute as root (chroot won't run otherwise, for obvious security reasons). So change the "guest" on the line in inetd.conf to "root" and then change the ownership of /usr/etc/tftpd to "guest" and turn on the setuid bit. If you're not sure what to do, I'd suggest calling the hotline. I'm sure someone at SGI can provide a more complete solution. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@kaos.stanford.edu) (415) 723-4940 Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00273; 30 Oct 89 23:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00088; 30 Oct 89 23:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02597; 30 Oct 89 22:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25305; 30 Oct 89 22:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA10119; Mon, 30 Oct 89 19:02: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: 31 Oct 89 02:52:33 GMT From: Rayan Zachariassen Subject: Re: SLIP on SGI Message-Id: <89Oct30.215147est.2742@neat.cs.toronto.edu> References: <591@sirius.ua.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL It seems like IRIX 3.2 doesn't come with SLIP, although I vaguely recall hearing SLIP would be in a future IRIX release (disclaimer!). However, since IRIX is very much like SunOS in that the tty system is stream-ized and the networking is socket-ized, you could try your hand at installing the SunOS 4.x SLIP by yours truly. Available from cs.toronto.edu:pub/slip-4.0.tar.Z. I don't know what the necessary steps would be, you'll have to wing it based on the Sun-relevant README. rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01090; 31 Oct 89 1:21 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00885; 31 Oct 89 1:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00841; 31 Oct 89 0:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26894; 31 Oct 89 0:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18557; Mon, 30 Oct 89 21:24: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: 31 Oct 89 04:10:31 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SLIP on SGI Message-Id: <43777@sgi.sgi.com> References: <591@sirius.ua.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <591@sirius.ua.oz.au>, gtravan@sirius.ua.oz.au (George Travan) writes: > i did'nt get any responses to my query as to whether SLIP was supported > in SGI version of unix! > i'm real keen though....anyone at sgi listening? > > can you run SLIP (serial line internet protocol) between sgi machines? > > --GeO George Travan > University of Adelaide > Box 498 G.P.O > Adelaide,AUSTRALIA > e-mail: george@frodo.ua.oz > gtravan@sirius.ua.oz A version of SLIP has been implemented. It has been in beta-test for months. One might guess it will be shipped someday. How soon, in what form, for how much $, and to which countries depends in part on the interest expressed by customers. One problem is that some important RFC's are <> not published. As a result, it is likely that anything shipped soon will not support the PPP or the common TCP/IP header compression. However, it is likely to support a less common but slightly more radical compression scheme which puts all three headers in 3 bytes, including framing and checksum. The impatient could take the BSD source, and rewrite it from a clist-to-mbuf converter into a STREAMS-buffer-to-mbuf converter. One would also want to get the source to routed and make the necessary fixes, if you wanted RIP. Adding suitable code to chat with modems for call-setup can be handy. Header compression is required when used with TB+'s, so one might want to obtain a pre-print of the relevant RFC. Vernon Schryver Silicon Graphics vjs@sgi.com P.S. How important is "dial-up SLIP"? That is, when an IP packet arrives, the local computer automatically dials the other computer, negotiates a new connection, and later kills the connection, not merely a facility to dial when a human orders.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00444; 31 Oct 89 4:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00337; 31 Oct 89 3:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00289; 31 Oct 89 3:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27542; 31 Oct 89 2:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA25221; Mon, 30 Oct 89 23:34: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: 31 Oct 89 06:52:29 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: minor security hole (tftp) Message-Id: <43779@sgi.sgi.com> References: <537@isl.stanford.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In the next release after 3.2, which one might hope will be called 3.3, tftpd will support the following options: -s Reject read- and write-requests naming a file with an absolute pathname. Tftpd relates filenames to a home directory, by default /usr/etc/boot. -h homedir Change tftpd's home directory from /usr/etc/boot to homedir, which must be an absolute pathname. -n Suppress negative acknowledgement of requests to read or write relative pathnames. Sun diskless clients like to broadcast read-requests for filenames in /tftpboot, causing very unpleasant nak storms from SGI and other 4.3BSD-based tftp daemons. Question to network administrators in the SGI user community: should the -s option be set in the inetd.conf that we ship? Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03664; 31 Oct 89 9:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03168; 31 Oct 89 8:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab03071; 31 Oct 89 8:47 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa01544; 31 Oct 89 8:37 EST Received: Tue, 31 Oct 89 05:34:43 -0800 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Tue, 31 Oct 89 08:36:16 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Tue, 31 Oct 89 08:58:42 EST by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Tue, 31 Oct 89 08:58:42 EST From: Tony Facca Message-Id: <8910311358.AA20060@lerc08.lerc.nasa.gov> To: sgi!brendan%illyria.wpd.sgi.com@ucbvax.berkeley.edu Subject: Re: minor security hole (tftp) Cc: info-iris%brl.mil@prandtl.nas.nasa.gov Brendan Eich writes: > In the next release after 3.2, which one might hope will be called 3.3, > tftpd will support the following options: > > -s Reject read- and write-requests naming a file with an > absolute pathname. Tftpd relates filenames to a home > directory, by default /usr/etc/boot. > > Question to network administrators in the SGI user community: should > the -s option be set in the inetd.conf that we ship? If the only reason that tftpd is turned on initially in /usr/etc/inetd.conf is to support remote boots over the network, I would say "yes", set the -s option -- and setup the default home directory to support the option. On the other hand, isn't it perhaps a little safer, from a security standpoint to ship the systems without tftpd turned on in the first place? Then, as part of the "How to boot from a Remote Device" procedure, you could include a line or two which explains, "you will have to uncomment the tftpd line in inetd.conf on the machines before remote booting will work..." I share the original poster's concern about network security. However, we do have several users who have configured their systems with only one tape drive among several machines. If the sysadmin is just careful enough to secure the password file from the obvious, I think net.hackers will look elsewhere, but in many cases (Personal Iris owners, especially), the sysadmin simply doesn't understand the details of administration. Perhaps a survey of how many people boot over the net as opposed to how many chose to have a tape drive for each system? Also, how does this affect the remote installation procedures (from disk) which are now available in 3.2 (sorry I forget what this is called right now, its the option where one machine loads all the installation tapes and the others can install from disk over the net rather than tape) -- does this rely on tftp being configured? And, as long as I'm ramblin' -- I set up a Data General AViiON machine a couple of weeks ago. It has one of those "auto-configure-everything" scripts it goes through when you setup networking... it even creates an anonymous ftp account for the system :-] -- ----------------------------------------------------------------------------- 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 aa10542; 31 Oct 89 19:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10500; 31 Oct 89 19:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10484; 31 Oct 89 19:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14866; 31 Oct 89 17:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15635; Tue, 31 Oct 89 14:08: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: 31 Oct 89 18:59:41 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: Re: 3rd Party Hardware Message-Id: <1989Oct31.185941.2494@utzoo.uucp> References: <8910301436.AA16360@lerc08.lerc.nasa.gov>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) writes: >... Since the 4D/20 is only >running at 12.5 MHz and the NeXT is running at 25 MHz, the memory >speed should be comparable ... MHz numbers have *absolutely no* correlation across different CPU (well, really different CPU-bus) architectures. There is no safe way of comparing the two, especially when you consider the possibility of wait states. The only reliable grounds for saying "the memory speeds should be comparable" would be specs for required memory speeds. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11947; 1 Nov 89 1:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11637; 1 Nov 89 0:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11598; 31 Oct 89 23:40 EST Received: from uunet.UU.NET by SMOKE.BRL.MIL id aa18725; 31 Oct 89 23:06 EST Received: from lsr-vax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA28707; Tue, 31 Oct 89 23:07:14 -0500 Received: from lsr-sund. by (4.1/SMI-4.0) id AA18890; Tue, 31 Oct 89 22:43:00 EST Date: Tue, 31 Oct 89 22:43:00 EST From: Art Hays - PSTAFF Message-Id: <8911010343.AA18890@> To: uunet!brl.mil!info-iris@uunet.uu.net Subject: Re: waiting for `man'........ ----- Begin excerpt from message ----- Date: 31 Oct 89 02:01:00 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: waiting for `man'........ Message-Id: <43773@sgi.sgi.com> References: I'm sorry to say that the desparately desired -k and -w (apropos and whatis) features from BSD have not been implemented in the 3.2 man. As SGI's licensing agreements with AT&T require us to ship preformatted manual pages. ----- End ----- I would like to know why SGI's licensing agreement precludes shipping unformatted manual pages. This is an inconvenience. I briefly checked a few other vendors here (Sun, Convex, Ultrix) and they ship unformatted pages. Art Hays, Nat. Eye Institute, uunet!lsr-vax!art Nat. Institutes of Health, Bethesda, MD (301) 496-7143   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12693; 1 Nov 89 4:47 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa12567; 1 Nov 89 3:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12523; 1 Nov 89 3:30 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21533; 1 Nov 89 2:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18971; Tue, 31 Oct 89 23:34: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: 31 Oct 89 18:03:04 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: Third Party Disks for 4D/25 Message-Id: <10076@alice.UUCP> References: <89Oct27.225152edt.2687@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL we had trouble with our wren v's initially on our MIPS M120's (the same problem with SCSI bus timeouts on large transfers) but simply sent them back to imprimis under warranty and they came back working perfectly. we have just bought new Wren VIs for our 4D-240 (to go an a jaguar controller) and they work just fine on the M120 so i assume we are over that firmware bug. for those who are interested, we mounted the 4 wren VI's in a rack mount power supply that fits neatly in the sgi disk farm box. the whole thing (disks+power supply) gives us about 2.5GB of file system for under $9K. it seems to me that people are far too hard on SGI for charging what they do. they seem average for disks although like MIPS, they do charge A LOT for memory. still, DEC was never cheap either and you do get performance for your buck. in any case, if you do buy third party disks, i think you are responsible for them working, not SGI. if SGI (or in my case, MIPS) helps you out trying to get your hardware working, then all praise to them. if they don't, then you don't get much sympathy from me. andrew@research.att.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12935; 1 Nov 89 6:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12760; 1 Nov 89 5:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12748; 1 Nov 89 5:11 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa22091; 1 Nov 89 4:42 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA28621; Wed, 1 Nov 89 04:43:03 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA00581; Wed, 1 Nov 89 04:12:33 -0500 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA15566; Wed, 1 Nov 89 03:32:00 EST Date: Wed, 1 Nov 89 03:32:00 EST From: Rod Paul Message-Id: <8911010832.AA15566@dasys1.UUCP> To: ciemo@bananapc.wpd.sgi.com, info-iris@BRL.MIL Subject: Re: waiting for `man'........ >> Has anyone put together a replacement for the `man' command on the 4D >> machines? Every time I try to use it, I am amazed that a machine >> costing so much money can do something sooooo slowly! :-) >> >> Seriously, the `man' program is *much* too slow to be useful for >> online reference, and there has to be some reasonable way to replace >> it. Has anyone done this? >> >In the new 3.2 release, there is a completely rewritten version of >'man' which replaces the pitiful AT&T shell script. In addition to >being faster (finds a man page in 1-2 seconds) it has the following >features: > > From BSD: > PAGER and MANPAGER environment variables for specifying > alternative pagers for man output. Sorry, SGI doesn't supply > less(1) though if you have it, you can use it. I'm sure you guy's must've trashed/optimized "pack" to get those kinda times |-). Anyway, I've been modifying "man" since v 2.0 and using "less" as the pager, just edit that ol' script... Pity SGI doesn't release "less" along with the other unsupported utilities such as "compress", "uuen/decode" etc. so that users who've never used it will appreciate how clunky "more" really is. By the way, talking about pagers, if you use BSD mail (/usr/sbin/Mail), you can "setenv PAGER " in your .login, and put "set crt" somewhere in your ~/.mailrc, now you won't have those large mail files flying out of view.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16816; 1 Nov 89 10:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14963; 1 Nov 89 9:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14894; 1 Nov 89 8:57 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa25007; 1 Nov 89 8:03 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6862; Wed, 01 Nov 89 08:02:52 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 01 Nov 89 14:03:48 Date: Wed, 1 Nov 89 14:04:14 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Upgrading to 3.2 To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8911010803.aa25007@SMOKE.BRL.MIL> Hallo, we have just upgraded our 70GT to IRIX 3.2 (full upgrade, cleaning filesystems before installation). I think we have already found two problems/bugs: 1) when using 'df' the used and available items for NFS directories are swapped. I love to see our EAGLE-disks 99% free, but it is to disappointing when you realize that it's the other way round as before 3.2. 2) We have a medium sized fortran program (MOPAC 5.0, 25000 lines of code, -static dependent). After compiling it with the 3.2 compiler it went into infinite loops even for water-molecules. The 3.1d version worked fine. We use the following compilation flags: '-static -g -vms'. First I thought it was an optimizer problem (using '-O2'), but the problem stays using '-g'. This is really a problem, because we and probably two or three other SGI customrs might want to run large fortran programs. I like the new gr_osview. It's really impressive. And the visual login icon for 'root' is cute. Workspace looks interesting, but I think I'm to old to get used to window based shells. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20349; 1 Nov 89 12:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20113; 1 Nov 89 12:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19965; 1 Nov 89 12:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02584; 1 Nov 89 12:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18844; Wed, 1 Nov 89 08:48: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: 1 Nov 89 16:37:05 GMT From: John Buchanan Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: waiting for `man'........ Message-Id: <5448@ubc-cs.UUCP> References: <8911010343.AA18890@> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911010343.AA18890@> art@lsr-vax.UUCP (Art Hays - PSTAFF) writes: >Date: 31 Oct 89 02:01:00 GMT >From: Dave Ciemiewicz >Organization: Silicon Graphics, Inc., Mountain View, CA >I'm sorry to say that the desparately desired -k and -w (apropos and whatis) >features from BSD have not been implemented in the 3.2 man. As SGI's licensing >agreements with AT&T require us to ship preformatted manual pages. Hmmmm. I have heard this from SGI many times. However I suspect that it has more with SGI's desire to unbundle troff and nroff thus formating pages becomes impossible. Then it probably becomes an issue that SGI cannot ship nroff with out troff, thus their statement that it is a licencing agreement with AT&T. #include John Buchanan buchanan@cs.ubc.ca Imager DCS, UBC, Van, BC, Can   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23230; 1 Nov 89 14:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21366; 1 Nov 89 13:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21355; 1 Nov 89 13:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04163; 1 Nov 89 13:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24445; Wed, 1 Nov 89 10:13: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: 1 Nov 89 17:52:03 GMT From: Rayan Zachariassen Subject: Re: waiting for `man'........ Message-Id: <89Nov1.125126est.2791@neat.cs.toronto.edu> References: <89Nov1.001058est.2999@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL lsr-vax!art@uunet.uu.net (Art Hays - PSTAFF) writes: > I would like to know why SGI's licensing agreement precludes shipping >unformatted manual pages. This is an inconvenience. I briefly checked >a few other vendors here (Sun, Convex, Ultrix) and they ship unformatted pages. AT&T has a separate license for unformatted manual pages. If you pay them 10000$US non-discountable (i.e. this is also the educational price) they'll give you a license. Apart from the price, this license has another problem: it includes the document source to things you don't want (the source for), like the AT&T documentation set, books, the SVID, etc. This is according to the AT&T licensing person in Canada. Obviously, you are paying for stuff you don't want. Knowing AT&T, I'm skeptical this situation will change any time soon. SGI said to us that they can't ship unformatted manual pages because their customers aren't licensed for them. So, how come Sun et al do ship unformatted manual pages? The line from Sun is that they rewrote all the new ones so they don't have to worry about licensing restrictions (since the older manual pages are derived from pre-licensing days). Comparing a couple of manual pages (cxref, pg) from SunOS and IRIX, they seem very incestuously related. The obvious minimal-work solution for SGI if they wish to address this issue, is to identify the exact source of each manual page and include source for the ones that don't fall under the separate man-page license but stem from V7/BSD/SVR2(?) where it all came bundled. I assume the man page macros can be cleansed as well considering their age. (Why would anyone want man page sources if they don't buy DWB from SGI? Well, perhaps they have DWB or equivalent on other machines, or another license that covers the SGI for DWB-functionality). Meanwhile, I don't suppose anyone is going to write a man-page decompiler... rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26869; 1 Nov 89 16:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26732; 1 Nov 89 16:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26719; 1 Nov 89 16:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09990; 1 Nov 89 16:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA04781; Wed, 1 Nov 89 12:50: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: 1 Nov 89 19:58:50 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: waiting for `man'........ Message-Id: <43864@sgi.sgi.com> References: <8911010343.AA18890@> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911010343.AA18890@>, art@lsr-vax.UUCP (Art Hays - PSTAFF) writes: >> From: Dave Ciemiewicz >> Organization: Silicon Graphics, Inc., Mountain View, CA >> Subject: Re: waiting for `man'........ >> >> I'm sorry to say that the desparately desired -k and -w (apropos and whatis) >> features from BSD have not been implemented in the 3.2 man. As SGI's licensing >> agreements with AT&T require us to ship preformatted manual pages. >> > > ----- End ----- > > I would like to know why SGI's licensing agreement precludes shipping > unformatted manual pages. This is an inconvenience. I briefly checked > a few other vendors here (Sun, Convex, Ultrix) and they ship unformatted pages. > > Art Hays, Nat. Eye Institute, uunet!lsr-vax!art > Nat. Institutes of Health, Bethesda, MD (301) 496-7143 Sun, Ultrix, and other UNIX(TM AT&T) vendors have BSD derived implementations with AT&T features added. They have taken it upon themselves to maintain nroff et al and their own manual pages. As of AT&T System V.2, nroff et al were separated from the standard UNIX distribution and licensed as a separate option, the Documentor's WorkBench. IRIX is System V derived with extensions and so Documentor's WorkBench is not offered as part of the standard distribution but as a separate option. Without nroff, having manual page sources would be useless thus a major reason for shipping only preformatted manual pages. Reason #2 is that AT&T System V manual page sources now fall under source licensing agreements with AT&T so yet another complication. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26869; 1 Nov 89 16:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26732; 1 Nov 89 16:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab26719; 1 Nov 89 16:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09992; 1 Nov 89 16:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA05430; Wed, 1 Nov 89 13:00: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 Nov 89 20:11:21 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: waiting for `man'........ Message-Id: <43866@sgi.sgi.com> References: <8911010832.AA15566@dasys1.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911010832.AA15566@dasys1.UUCP>, rpaul@dasys1.UUCP (Rod Paul) writes: > I'm sure you guy's must've trashed/optimized "pack" to get those kinda > times |-). No, actually, a very fast search mechanism was implemented to locate manual pages. It's the same old pack. I did some timing trials to to make sure I wasn't exaggerating. On my quiescent 4D/70, it took 3 seconds to bring up a man page the first time. Subsequent man searches took only about 1.6 seconds because the relevent disk blocks were in the disk cache. The new man command will uncompress preformatted manual pages instead of unpacking them if they are compressed. If you feel it will be that much of a performance win, you can unpack all of your manual pages and compress them. I seem to remember previous time trials I did a long time ago which indicated that uncompress was not appreciably faster than unpack for the typical manual page file. > > Anyway, I've been modifying "man" since v 2.0 and using "less" as the pager, > just edit that ol' script... > > Pity SGI doesn't release "less" along with the other unsupported utilities > such as "compress", "uuen/decode" etc. so that users who've never used it > will appreciate how clunky "more" really is. Well, compress is in 3.2 along with uuencode and uudecode. Again, sorry, less is not there. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00493; 1 Nov 89 18:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00230; 1 Nov 89 18:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac00177; 1 Nov 89 17:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11177; 1 Nov 89 17:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09040; Wed, 1 Nov 89 13:56: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: 1 Nov 89 20:27:43 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: waiting for `man'........ Message-Id: <43868@sgi.sgi.com> References: <89Nov1.001058est.2999@neat.cs.toronto.edu>, <89Nov1.125126est.2791@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Nov1.125126est.2791@neat.cs.toronto.edu>, rayan@cs.toronto.edu (Rayan Zachariassen) writes: > lsr-vax!art@uunet.uu.net (Art Hays - PSTAFF) writes: > > Meanwhile, I don't suppose anyone is going to write a man-page decompiler... > > rayan Well, it it doesn't produce -man macros but the following will produce t/nroff commands from nroff formatted output. What it mostly does is convert the italic and bold text to font changes. I did this so the preformatted output could be wired into a prototype ditroff previewer for nicer manual page previewing. This approach is slow and I don't recommend it (no I don't have the ditroff previewer anymore so please don't ask.) ------------------------------------------------------------------------------ #! /bin/sh echo ".nf" echo ".fp 5 C" echo ".fp 6 CO" echo ".fp 7 CB" echo ".ft 5" echo ".po 0.25i" echo ".ps 12" echo ".ta 0.8i 1.6i 2.4i 3.2i 4.0i 4.8i 5.6i 6.4i 7.2i" sed -e 's/\\/\\\\/g' \ -e 's/\(\\\\\)\1\1\1/\\f7\1\\fP/g' \ -e 's/\(.\)\1\1\1/\\f7\1\\fP/g' \ -e 's/\(.\)_\1\1\1/\\z_\\f7\1\\fP/g' \ -e 's/_|/\\z_|/g' \ -e 's/_\(.\)/\\f6\1\\fP/g' \ -e 's/^9/\\u/g' \ -e 's/^8/\\d/g' \ -e 's/+o/\\(bu/g' ------------------------------------------------------------------------------ I make no promises about the above code working.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00892; 1 Nov 89 20:14 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00665; 1 Nov 89 19:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00656; 1 Nov 89 18:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12970; 1 Nov 89 18:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14770; Wed, 1 Nov 89 15:26: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: 1 Nov 89 22:52:51 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: Re: Upgrading to 3.2 Message-Id: <2981@hydra.gatech.EDU> References: <8911010803.aa25007@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > > we have just upgraded our 70GT to IRIX 3.2 (full upgrade, cleaning > filesystems before installation). I think we have already found two > problems/bugs: > > 1) when using 'df' the used and available items for NFS directories > are swapped. I love to see our EAGLE-disks 99% free, but it is to > disappointing when you realize that it's the other way round as > before 3.2. Df works fine on our IRIX 3.2 4D/120GT. We also do a full upgrade, cleaning the system beforehand. Here's what the output looks like: Filesystem Type blocks use avail %use Mounted on /dev/root efs 31050 15700 15350 51% / /dev/usr efs 479044 277598 201446 58% /usr /debug dbg 131912 12936 118976 10% /debug max:/usr1 nfs 964654 831836 132818 86% /max xtal:/usr nfs 463598 425718 37880 92% /xtal radar:/radar2 nfs 1025800 1007716 18084 98% /radar2 radar:/radar1 nfs 1025800 992108 33692 97% /radar1 hydra:/local nfs 763838 729818 34020 96% /.local frencha:/frencha2 nfs 906956 195814 711142 22% /frencha2 frencha:/frencha1 nfs 906956 363730 543226 40% /frencha1 hydra:/usr/spool/mail nfs 382506 293640 88866 77% /usr/mail hydra:/hydra5 nfs 1382586 1298480 84106 94% /hydra5 hydra:/hydra4 nfs 1382586 1254236 128350 91% /hydra4 hydra:/hydra3 nfs 1382586 1211782 170804 88% /hydra3 hydra:/hydra2 nfs 1382586 1289380 93206 93% /hydra2 hydra:/hydra1 nfs 1382586 1300948 81638 94% /hydra1 liba:/liba2 nfs 906956 417002 489954 46% /liba2 liba:/liba1 nfs 906956 567400 339556 63% /liba1 And, yes, as is typical, most of our disks are really as full as df says they are. Perhaps the problem is in your server not reporting the fs statistics correctly. Our servers are a couple of other SGI machines, a few Sun 4/280s and one Sequent and they all report the right numbers. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01184; 1 Nov 89 21:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00942; 1 Nov 89 20:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00918; 1 Nov 89 20:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13513; 1 Nov 89 20:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA20363; Wed, 1 Nov 89 16:56: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: 1 Nov 89 23:26:28 GMT From: David Haight Organization: Tektronix Inc., Beaverton, Or. Subject: Tek device driver (/dev/tek) Message-Id: <8092@pogo.WV.TEK.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am looking for information on /dev/tek, a driver for tek color printers. If you know of this, please contact me by email. Thank You David Haight Tek/GPID