Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16799; 22 Nov 89 2:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16428; 22 Nov 89 1:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16425; 22 Nov 89 1:11 EST Received: from KAOS.Stanford.EDU by SMOKE.BRL.MIL id aa06916; 22 Nov 89 0:49 EST Received: by kaos.Stanford.EDU (4.0/MasterMail-1.0) id AA00748; Tue, 21 Nov 89 21:44:59 PST From: Paul Ning Message-Id: <8911220544.AA00748@kaos.Stanford.EDU> To: info-iris@BRL.MIL Cc: paul@kaos.stanford.edu, jim@kaos.stanford.edu Subject: Problems with system tools in 3.2 Date: Tue, 21 Nov 89 21:44:59 PST We have just upgraded our two machines (4D/80GT and 4D/220GTX) to 3.2. The 80 seems to be happy but we are having difficulties running some of the utilities in the System Menu on the 220. Here are the symptoms : 1) WorkSpace - when selected, the only result is the message "Can't connect with File Access Monitor (fam)" in the console window. 2) Transfer Manager - when selected, nothing happens. 3) System Manager & Confidence Tests - a window pops up, and then goes away. The /etc/services and /usr/etc/inetd.conf files on both machines are identical and the executables /usr/etc/fam, /usr/etc/rpc.toolkitbus are present as well. Any ideas what the problem could be? Thanks, Paul Ning Dept. of Elec. Engr. Stanford University, Durand 358 Stanford, CA 94305-4035 paul@kaos.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17240; 22 Nov 89 4:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17010; 22 Nov 89 2:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16989; 22 Nov 89 2:44 EST Received: from KAOS.Stanford.EDU by SMOKE.BRL.MIL id aa07479; 22 Nov 89 2:34 EST Received: by kaos.Stanford.EDU (4.0/MasterMail-1.0) id AA01080; Tue, 21 Nov 89 23:29:28 PST From: Paul Ning Message-Id: <8911220729.AA01080@kaos.Stanford.EDU> To: info-iris@BRL.MIL Cc: paul@kaos.stanford.edu, jim@kaos.stanford.edu Subject: Re: Problems with system tools in 3.2 (aka Oops) Date: Tue, 21 Nov 89 23:29:28 PST Oops, I found the answer to my last message in an old posting to this group. In my last message I wrote, > We have just upgraded our two machines (4D/80GT and 4D/220GTX) to 3.2. > The 80 seems to be happy but we are having difficulties running > some of the utilities in the System Menu on the 220. Here are the > symptoms : > > 1) WorkSpace - when selected, the only result is the message > "Can't connect with File Access Monitor (fam)" > in the console window. > > 2) Transfer Manager - when selected, nothing happens. > > 3) System Manager & Confidence Tests - a window pops up, and then goes away. > > The /etc/services and /usr/etc/inetd.conf files on both machines are > identical and the executables /usr/etc/fam, /usr/etc/rpc.toolkitbus are > present as well. The fix was given by Robert Viduya : > 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. I fixed /etc/rpc on our ypmaster (a Sun 3/260), rebooted the 4D/220GTX, and all of the System Menu stuff worked. :) I still don't know why our 4D/80GT (which is also set up as a ypslave) didn't have any of these problems before the fix, but, hey, why worry about things that ain't broke? Paul Ning Dept. of Elec. Engr. Stanford University, Durand 358 Stanford, CA 94305-4035 paul@kaos.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21022; 22 Nov 89 9:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20701; 22 Nov 89 9:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20668; 22 Nov 89 9:15 EST Received: from Princeton.EDU by SMOKE.BRL.MIL id aa02869; 22 Nov 89 9:08 EST Received: from fourier.Princeton.EDU by Princeton.EDU (5.58+++/2.25/mailrelay) id AA08780; Wed, 22 Nov 89 09:05:30 EST Received: by fourier.Princeton.EDU (5.61/1.95) id AA01314; Wed, 22 Nov 89 09:08:30 -0500 Date: Wed, 22 Nov 89 09:08:30 -0500 From: ams@acm.princeton.edu Message-Id: <8911221408.AA01314@fourier.Princeton.EDU> To: info-iris@BRL.MIL, paul@kaos.stanford.edu Subject: Re: Problems with system tools in 3.2 Cc: jim@kaos.stanford.edu Paul Ning asks: > Subject: Problems with system tools in 3.2 > Date: Tue, 21 Nov 89 21:44:59 PST > Status: R > We have just upgraded our two machines (4D/80GT and 4D/220GTX) to 3.2. > The 80 seems to be happy but we are having difficulties running > some of the utilities in the System Menu on the 220. Here are the > symptoms : > 1) WorkSpace - when selected, the only result is the message "Can't connect with File Access Monitor (fam)" in the console window. > 2) Transfer Manager - when selected, nothing happens. > 3) System Manager & Confidence Tests - a window pops up, and then goes away. > The /etc/services and /usr/etc/inetd.conf files on both machines are > identical and the executables /usr/etc/fam, /usr/etc/rpc.toolkitbus are > present as well. I know this can happen if you are using yp and your server isn't an SGI box. I had this same problem, you have to add the following lines to the /etc/rpc file on your yp server: sgi_toolkitbus 391001 sgi_fam 391002 Then rebuild the maps (cd /var/yp; make on a Sun) and reboot the SGIs that don't work. This should clear up the "can't contact fam" and will probably fix all of it. --ams _________________________________________________________________________ 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 aa27416; 22 Nov 89 14:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25979; 22 Nov 89 13:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25828; 22 Nov 89 13:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00639; 22 Nov 89 12:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11942; Wed, 22 Nov 89 09:15:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 15:11:32 GMT From: Bill Lasher Organization: Penn State University Subject: Re: Problems with system tools in 3.2 (aka Oops) Message-Id: <89326.101132W0L@PSUVM.BITNET> References: <8911220729.AA01080@kaos.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Workspace will also not work on a client if the yp server is an SGI that does not yet have 3.2, unless you copy /etc/rpc from the client to the server and re-make.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28570; 22 Nov 89 15:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27034; 22 Nov 89 14:22 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa27029; 22 Nov 89 14:16 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa03170; 22 Nov 89 14:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18253; Wed, 22 Nov 89 10:55:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 18:13:43 GMT From: Mark T Vandewettering Organization: Princeton Univ. Computing and Information Technology Subject: Wanted: Opinions on Pixar II Message-Id: <11690@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are considering obtaining a Pixar II for use as part of the scientific visualization effort at the Program in Applied and Computational Math at Princeton. Our primary use would be for the development of an interactive volume visualization tool for computational fluid dynamics. I am anxious to talk or exchange email with anyone who is currently using a Pixar II, especially in an environment with an SGI machine as a host. In particular, I would like to hear about: o speed, especially in volume visualization tasks o ease of programming o ease of use o how it helped you achieve tasks that were beyond the realm of normal SGI equipment Thanks in advance for your help. Mark T. VandeWettering (markv@acm.princeton.edu) Program in Applied and Computational Math --- 609-258-5324   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29197; 22 Nov 89 16:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28757; 22 Nov 89 15:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28643; 22 Nov 89 15:41 EST Received: from UV4.EGLIN.AF.MIL by SMOKE.BRL.MIL id aa00938; 22 Nov 89 15:27 EST Date: 22 Nov 89 14:06:00 CST From: ferrill@eglin.af.mil Subject: Image display software To: info-iris Message-ID: <8911221527.aa00938@SMOKE.BRL.MIL> I'm looking for a general purpose image viewer for the Iris workstation. We have a new machine and are just getting started using it. The data we want to display is a gray-scale type of image in the 256 X 256 size with 256 levels of grey. Any pointers would be greatly appreciated. Please respond directly to me as I am not a subscriber of the list. Paul Ferrill ferrill@eglin.af.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29360; 22 Nov 89 17:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29131; 22 Nov 89 16:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29129; 22 Nov 89 16:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01694; 22 Nov 89 16:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA26890; Wed, 22 Nov 89 13:09:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 20:21:27 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Problems with system tools in 3.2 Message-Id: <45161@sgi.sgi.com> References: <8911220544.AA00748@kaos.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911220544.AA00748@kaos.Stanford.EDU> paul@KAOS.STANFORD.EDU (Paul Ning) writes: > >We have just upgraded our two machines (4D/80GT and 4D/220GTX) to 3.2. >The 80 seems to be happy but we are having difficulties running >some of the utilities in the System Menu on the 220. Here are the >symptoms : > >1) WorkSpace - when selected, the only result is the message > "Can't connect with File Access Monitor (fam)" > in the console window. > >2) Transfer Manager - when selected, nothing happens. > >3) System Manager & Confidence Tests - a window pops up, and then goes away. > >The /etc/services and /usr/etc/inetd.conf files on both machines are >identical and the executables /usr/etc/fam, /usr/etc/rpc.toolkitbus are >present as well. > >Any ideas what the problem could be? > The first possibility that comes to mind is that your yp server has to have the following lines in its /usr/etc/inetd.conf sgi_fam/1 stream rpc/tcp wait root /usr/etc/fam famd sgi_toolkitbus/1 stream rpc/tcp wait root /usr/etc/rpc.toolkitbus toolkitb usd After you change that file, you need to bounce the inetd. kill -1 process# for inetd This should help things out a lot. Please post again if things are not better. Betsy Zeller betsy@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29414; 22 Nov 89 17:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29254; 22 Nov 89 17:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29251; 22 Nov 89 16:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02112; 22 Nov 89 16:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28921; Wed, 22 Nov 89 13:41: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: 22 Nov 89 21:31:29 GMT From: Paul Connally Organization: University of Colorado, Boulder Subject: IRIX 3.2 and other questions Message-Id: <14182@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I know that some (or maybe all) of these questions have probably been posted at some time or another but I either missed the answer or one was never posted, so please bare with me. I have a Personal IRIS w/8Mb of memory, 170MB disk, and 12 bit planes. 1) On IRIX 3.2: - Obviously many people have this already, how do I get mine?!!! - Does any X stuff come with it? - Is the NFS software fixed? - Was there a major change to the manuals and do any new manuals come with the upgrade? 2) What is the best place to obtain the following third party hardware, what problems will arise with it, what is it's cost and should I install it myself? Also, what software changes will be need for some of these? - Memory - External SCSI Hard Disk - VME Bus extension - Extra Serial lines 3) What is a good SPICE-like package (with A & D circuit design) that has a nice graphics interface for editing the design and possibly features like an oscilloscope or a wave function generator? (and who sells it?) Sorry if any of these questions are moog points but I've been out of it for a while. Paul Connally paulc@boulder.colorado.edu University of Colorado High Voltage Electron Microscope Lab MCDB - Box 347 "A higher potential for Boulder, CO 80309 better penetration."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00495; 22 Nov 89 21:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00446; 22 Nov 89 21:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00427; 22 Nov 89 21:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04124; 22 Nov 89 20:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA13260; Wed, 22 Nov 89 17:33:33 -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: 23 Nov 89 01:11:35 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Updating directory views Message-Id: <45187@sgi.sgi.com> References: <17093@umn-cs.CS.UMN.EDU>, <45022@sgi.sgi.com>, <3678@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >Actually, NFS mounts do make a difference. The fam daemon runs as root and >if you've got a NFS directory open in the workspace that has modes of something >like 0700, and the NFS server has the filesystem exported WITHOUT root access, >root will NOT be able to see into that directory. The effect that we've noticed >here when that situation occurs is that on the initial open of the directory >from the workspace all the files in that directory appear for a split second >and then disappear. > >I reported this problem to the hot-line (problem number B3520) and was told >that, yes, it was a problem and that, no, SGI wouldn't fix it. I've had to >resort to telling my users that if they want to be able to access their files >from the workspace, they need to make them publicly available for everyone else >to access. > I think that there has been a slight problem in communication here. It is clear that when you open a directory view that you have permission to access, you should see the files in it without their icons disappearing. This problem will be addressed in a future release. One problem that is currently impeding me from addressing it is that I cannot reproduce it. All combinations that I have tried of exporting/mounting directories over nfs have worked fine. It would be a great help if you could email me i) the contents of /etc/exports referring to the troublesome directories ii) the appropriate lines from /etc/fstab iii) has anyone had this problem when the NFS mounts were only between SGI machines The fam daemon will continue to run as root, because more than one WorkSpace can be run at a time, and the fam daemon must serve them all. There are, however, other ways around the problem and we will continue to investigate them. Betsy Zeller betsy@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02358; 23 Nov 89 9:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02328; 23 Nov 89 8:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02313; 23 Nov 89 8:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08809; 23 Nov 89 8:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16839; Thu, 23 Nov 89 05:22:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 19:34:12 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: TERMCAP entries for IRIS-4D wsh (iris-ansi) windows Message-Id: <1581@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From time to time, I've had inqueries as to what should users of BSD derived systems set their TERM or TERMCAP entries to when they rlogin from an IRIS-4D wsh window. Well, in desparation, a VT-100 termcap entry should do. The wsh window supports the "iris-ansi" terminal emulation which is a superset (for the most part) of the ANSI (VT-100) standard terminal. If you want a proper emulation, you can query the TERMINFO database (AT&T Sys V's answer to TERMCAP) for a TERMCAP compatible terminal description. Use the command, "infocmp -C -r iris-ansi". This will printout: iris-ansi|IRIS emulating 40 line ANSI terminal (almost VT100):\ :am:pt:\ :co#80:it#8:li#40:kn#4:\ :!2=\E[218q:#2=\E[143q:#4=\E[158q:%9=\E[209q:\ :%f=\E[210q:%i=\E[167q:&7=\E[217q:*4=\E[P:*7=\E[147q:\ :@7=\E[146q:@8=\r:AL=\E[%dL:DL=\E[%dM:DO=\E[%dB:\ :F1=\EOR:F2=\EOS:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:\ :al=\E[L:bl=^G:cb=\E[1K:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ :cm=\E[%i%d;%dH:cr=\r:dl=\E[M:do=\n:ho=\E[H:\ :is=\E[?1l\E>\E[?7h:k1=\E[001q:k2=\E[002q:k3=\E[003q:\ :k4=\E[004q:k5=\E[005q:k6=\E[006q:k7=\E[007q:\ :k8=\E[008q:k9=\EOP:k;=\EOQ:kB=\E[Z:kD=^?:kI=\E[139q:\ :kM=\E[146q:kN=\E[154q:kP=\E[150q:kb=\b:kd=\E[B:\ :ke=\E>:kh=\E[H:kl=\E[D:kr=\E[C:ks=\E=:ku=\E[A:\ :le=\E[D:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:nw=\EE:\ :.pk=!!! MUST CHANGE BY HAND !!!\EP101;%p1%d.y%p2%s\E\\:\ :se=\E[m:sf=\ED:so=\E[1;7m:sr=\EM:ta=\t:ue=\E[m:\ :up=\E[A:us=\E[4m:ve=\E[9/y\E[12/y\E[=6l:\ :vs=\E[10/y\E[=1h\E[=2l\E[=6h:bc=\E[D:ko=le,nd,up,ho: Locally, we have used this /etc/termcap entry on our local TERMCAP using systems. We have however, made one modification. We remove the following line from the entry: :.pk=!!! MUST CHANGE BY HAND !!!\EP101;%p1%d.y%p2%s\E\\:\ You should be able to add this entry with the modification to your /etc/termcap file on a BSD derived system. For more information about infocmp and terminfo, see their manual pages.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02591; 23 Nov 89 10:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02484; 23 Nov 89 10:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02478; 23 Nov 89 9:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09158; 23 Nov 89 9:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA21321; Thu, 23 Nov 89 06:46: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: 22 Nov 89 14:21:13 GMT From: Gunnar Moan Organization: Scottish HCI Centre, Glasgow, Scotland Subject: gcc on Iris 3130 Message-Id: <740@tivax.turing.ac.uk> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to use C++ on an Iris 3130. Gnu's gcc/g++ seems the most reasonable option. I have however had very little success in compiling the gcc compiler as no configuration file for this machine accompanies the gcc-1.36 distribution. If somebody has ported gcc/g++ to this machine, or has experience porting to a similar configuration (m68020, Weitek 1064/1065 FP coprocessor, SysV with `Berkeley enhancements') I would very much like to hear from them. Marius. marius@uk.ac.strath.hci (JANET) marius@hci.strath.ac.uk (ARPA) ...uunet!mcvax!ukc!tivax!snowwhite!marius (UUCP)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10106; 24 Nov 89 15:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09490; 24 Nov 89 14:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09407; 24 Nov 89 14:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22758; 24 Nov 89 14:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08720; Fri, 24 Nov 89 11:02:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Nov 89 18:54:45 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: REDRAW question Message-Id: <21289@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In a program that I am working on, whenever the window gets redrawn the ghosts of the previous border stays inside the window. In that window I make use of writemask, but I thought that using it wouldn't have any effects on a clear() instruction. Am I right? Anybody has any clues as to what I am forgetting to do? -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I am graduating next year and I am looking for a job. MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10952; 24 Nov 89 16:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10780; 24 Nov 89 16:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10735; 24 Nov 89 16:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24720; 24 Nov 89 16:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14712; Fri, 24 Nov 89 13: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: 24 Nov 89 17:59:42 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: floating-point exceptions Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How does one modify the response of the floating-point exception handler on the IRIS 4D machines? What I want to do is to turn off error handling for operations which have NaN as an operand, so that the code will simply continue. I know that in this case, the effects of the NaN's will be limited, since the problem occurs in the scaling of some results for output.... Thanks.... -- 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 aa12231; 24 Nov 89 21:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11986; 24 Nov 89 20:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11984; 24 Nov 89 20:48 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa26144; 24 Nov 89 20:42 EST Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4850; Fri, 24 Nov 89 19:41:40 CST Received: by UMRVMA (Mailer R2.05) id 4849; Fri, 24 Nov 89 19:41:38 CST Date: Fri, 24 Nov 89 19:38:55 CST From: "Bob B. Funchess" Subject: cron and logins To: info-iris@BRL.MIL Message-ID: <8911242042.aa26144@SMOKE.BRL.MIL> I want to set up a system on our 4D/20 where certain users can only login at certain times, such as non-prime hours. The only way I can think of to do this is to have cron swap /etc/passwd in and out at these times, and frankly this frightens me a little :). Does anyone have such a setup? Will you share your secrets? You can mail me direct at the address below... < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13655; 25 Nov 89 2:05 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa13467; 25 Nov 89 1:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13366; 25 Nov 89 1:29 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa27843; 25 Nov 89 1:19 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA07170; Sat, 25 Nov 89 01:20:35 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA27165; Sat, 25 Nov 89 01:11:15 -0500 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA27913; Sat, 25 Nov 89 00:31:44 EST Date: Sat, 25 Nov 89 00:31:44 EST From: Rod Paul Message-Id: <8911250531.AA27913@dasys1.UUCP> To: Info-Iris@BRL.MIL Subject: CCIR 601, D1, Digital Video I'm sorry to hear about the kludge; VideoCreator, that has just been anounced on this newsgroup. It it such a pity that SGI, who undoubtedly produce one of the finest platforms for high-end 3D graphics, continue to neglect the field of BROADCAST video. Just about all the SGI machines I've used have had some form of NTSC out, but at such poor levels. All I've been using the CG2-boards for is rough tests. To get some form of decent video out, I've had to use an Abekas A60 via ethernet, an option that I'm sure is not within the budget of many a user. The one problem with the above method is the time it takes to convert RGB images to the digital video format, CCIR 601, which the Abekas needs as input. I must admit that dealing with digital video is the easiest, and that is why I wonder why SGI doesn't seem to be addressing this avenue. At SIGGRAPH this year I saw a 3rd party's product for displaying video in it's own window on a graphics terminal. I wonder, how hard would it be to have a device that accepted CCIR 601 in/out, and its' display memory accessable via the GL routines lrectread/write and read/writeRGB? This option would speed up conversion, and be able to tie into both hard-disk and digital tape recorders. Sure this option would still be beyond the budget of most users, but you'd have a fast way to record images with very high quality. Also, the more products/people using digital video will have some effect on bringing down the cost of the format. Well who knows, in 5 to 10 years everything may be HiDef, a whole new ball of wax, but I sure hope I don't have to wait that long before getting decent video out of an SGI platform.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20686; 26 Nov 89 8:56 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20438; 26 Nov 89 8:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20434; 26 Nov 89 7:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07678; 26 Nov 89 7:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27816; Sun, 26 Nov 89 04:46:33 -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: 26 Nov 89 12:39:05 GMT From: "DGP Project Account (Robert Lansdale" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Help needed extending 8-bit X11 driver to 24 bits Message-Id: <1989Nov26.073905.7689@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am currently trying to extend my 8-plane color X windows driver to work on a 24-bit Iris/4D, but am somewhat confused as to the correct way to go about this. I've read through all X11 colormap tutorials we have online (ICCCM turorial, Xlib manual, several talks given at USENIX, etc) but most deal do not talk about DirectColor displays with 24 planes. I believe the ICCCM tutorial had a small example showing how to allocate a 24-bit colormap using XAllocColorPlanes(), but they did not show much else. Anyone have any code fragments they wouldn't mind sharing that shows how to write to such a display?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22941; 26 Nov 89 19:47 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa22706; 26 Nov 89 18:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab22681; 26 Nov 89 18:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11301; 26 Nov 89 18:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA25551; Sun, 26 Nov 89 15:22:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Nov 89 23:08:20 GMT From: Scum Organization: Carnegie-Mellon University, CS/RI Subject: Problems with system 3.2 Message-Id: <7089@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I, like some of the other on this list, have been having some problems with the newly released system. However, I've not seen anybody post a problem like the ones I have, and I am in desperate need of help with a 15 Dec deadline approching. I've spent the past couple of weeks trying to deal with these problems. Most basically, my programme worked under 3.1, but does not work under 3.2. I even recomplied. The two problems I've uncovered so far are both graphics problems. First of all, objects are not being drawn when I use the lighting calculations (materials, lighting models, lights). Second, mapw doesn't work anymore. In the first problem, I thought maybe there was something to do with the changes in the colour map, even though I use RGBmode. I figured when faced with a problem like this with no staring point, I might as well try anything. Through some twiddling, I found that that was not the problem. I define and bind the materials, lighting model, and lights. Then I clear the window to black with both zclear and clear (I use zbuffering), setting the colour with cpack(0x00000000). Then I draw the objects. They don't appear! So I set the colour to turquoise (no reason for the colour.... it's just what the colour turned out to be) after I clear and just before the objects are drawn, and lo they show up! So the lmbinds don't seem to be taking effect or something. What's going on here? Is there something else I must do now to get the lighting stuff to work? Help! In the second problem, mapw doesn't put valid values at the addresses sent for the end points of the reference line; that is, the last six arguments. This used to work too. Now when I try to printf the values as floats (which is what Coord is typedefed to), I get NaN (which is decidedly not a float). I've defined the object used for reference, as I had before. There was nothing changed from when this was working in 3.1 and now that it is not working in 3.2. I tried twiddling parameters and everything, but I can't seem to get anywhere with this problem. Below is the code which sets up the object. makeobj(wrldview = genobj()); prefposition(0, 1023, 0, 1023); objwin = winopen("DF Interface"); ortho(gs_vec_num(0.0), gs_vec_num(scaler), gs_vec_num(0.0), gs_vec_num(scaler), gs_vec_num(-scaler), gs_vec_num(0.0)); lsetdepth(1023, 0); closeobj(); Not helping the situation any is the basic lack of documentation either on line or on paper, which accompanied the new system. I really appreciated John Barton posting those release notes; they were very useful. Unfortunately, documents referenced within these notes had not come with our upgrade either, so I was still at a loss for details. I don't don't know... were we the only ones this happened to? The release notes had promising stuff in them, but I can't really use them well if I have no documentation. I'm getting frustrated, because I still have stuff I have to add to the system, and this is using up all my time. Any help with these problems would be gratefully received! Thanks, -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23507; 26 Nov 89 22:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23257; 26 Nov 89 21:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23210; 26 Nov 89 20:55 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12092; 26 Nov 89 20:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA02548; Sun, 26 Nov 89 17:43:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Nov 89 01:20:59 GMT From: Charlie Gibson Organization: Rhythm & Hues, Inc., Hollywood Subject: Re: CCIR 601, D1, Digital Video Message-Id: <564@celia.UUCP> References: <8911250531.AA27913@dasys1.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911250531.AA27913@dasys1.UUCP> rpaul@dasys1.UUCP (Rod Paul) writes: > >I'm sorry to hear about the kludge; VideoCreator, that has just been anounced >on this newsgroup. > >It it such a pity that SGI, who undoubtedly produce one of the finest platforms >for high-end 3D graphics, continue to neglect the field of BROADCAST video. .... >To get some form of decent video out, I've had to use an Abekas A60 via >ethernet, an option that I'm sure is not within the budget of many a user. >The one problem with the above method is the time it takes to convert RGB images >to the digital video format, CCIR 601, which the Abekas needs as input. > >I must admit that dealing with digital video is the easiest, and that is why >I wonder why SGI doesn't seem to be addressing this avenue. Since Tektronix now offers an RGB-IN 601-OUT framebuffer in their 88000 based workstations, and because those stations are causing a bit of a rumble in the video world, I suspect that SGI will soon follow suit. I know that this is not a new request -- we've been harping on them for over a year. Vertigo also manufactures a hardware-based RGB-601 converter, but, alas, they are only selling it in conjunctionn with their software. I think that their feeling is that it will boost software sales. Also, unlike the TEK board, I think that the conversion is slow -- like, I've even heard as slow as 23 seconds per frame, which is far worse than doing it in software. If speed is a real problem, and you have an Abekas A60, you might want to buy an A20, which is a real-time ANALOG RGB to 601 encoder. I think that it's only about $5000. We have one, and you can snap frames onto the A60 as fast as you can display them on a frame buffer. The quality is obviously not quite as good as a purely digital transfer, but it sure beats waiting around for some old tape machine to preroll and edit single frames. -- Charlie Gibson -- Rhythm & Hues, Inc. INTERNET: celia!charlie@usc.edu Consequences, shmonsequences, celia!charlie@tis.llnl.gov as long as I'm rich.... UUCP: ...{ames,hplabs}!lll-tis!celia!charlie   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02866; 27 Nov 89 12:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02567; 27 Nov 89 12:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02548; 27 Nov 89 11:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24260; 27 Nov 89 11:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17706; Mon, 27 Nov 89 08:03:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Nov 89 12:59:24 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Re: nfs failure between Gould NP1 and Personal Iris Message-Id: References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article mike@cfdl.larc.nasa.gov (Mike Walker) writes: >I am having a strange error occur on a NFS mounted partition on our PI. >First a little info about the machines involved: [ ... details deleted ... ] >Symptoms: > - ls works everywhere > - cat, grep, etc. (normal file access) works everywhere > - echo * fails only on the Gould file-system (error: ``no match'') > - find fails only on the Gould file-system > (error: ``getwd: read error in ..'') > - None of these problems show up on the Sun or the Gould using local, > Sun NFS, or Irix NFS file-systems. >Thanks for any help, >Mike >-- >Mike Walker AS&M Inc/NASA LaRC (804) 864-2305 I have had very similar problems trying to get NFS to work between our PI and our NeXT (which we bought as a cheap file server). NFS works pretty well between our 3030's and our NeXT, though often when the NeXT tries to write a file on the IRIS's disk, it ends up with user-id=-1 and group-id=-1. I would understand this if a setuid program were trying to write the file, but it happens when almost any program writes.... Examples are `cp' and `emacs', both owned by root, but neither with setuid or setgroupid bits set.... -- 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 aa03558; 27 Nov 89 12:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01044; 27 Nov 89 10:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00979; 27 Nov 89 10:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22081; 27 Nov 89 10:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14650; Mon, 27 Nov 89 07:14: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: 27 Nov 89 15:44:20 GMT From: Mike Walker Organization: NASA Langley Research Center, Hampton, Va. 23665 Subject: nfs failure between Gould NP1 and Personal Iris Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am having a strange error occur on a NFS mounted partition on our PI. First a little info about the machines involved: 1) Personal Iris 4D-20 w/ Irix 3.2 2) Gould NP1 w/ UTX/32 3.1 (BSD w/ SVR3 extensions) 3) Sun 3/280 w/ Sun Unix 3.4 I have one file system from machines 2 and 3 above mounted on the PI. Everything seems to work fine with the Sun based fs, but certain operations fail on the fs mounted off of the Gould. Symptoms: - ls works everywhere - cat, grep, etc. (normal file access) works everywhere - echo * fails only on the Gould file-system (error: ``no match'') - find fails only on the Gould file-system (error: ``getwd: read error in ..'') - None of these problems show up on the Sun or the Gould using local, Sun NFS, or Irix NFS file-systems. I noticed the problem when I tried running the X11 lndir.sh script on the Iris to set up links to the X distribution mounted from my Gould. Does anyone have any clues as to what could be wrong here? As I said, many things work find (after running lndir on the Gould, I was able to compile the X library on the Iris without any [NFS related] problems). Thanks for any help, Mike -- Mike Walker AS&M Inc/NASA LaRC (804) 864-2305   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10946; 27 Nov 89 21:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10897; 27 Nov 89 21:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10697; 27 Nov 89 20:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08924; 27 Nov 89 20:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23355; Mon, 27 Nov 89 17:20:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Nov 89 23:47:30 GMT From: Steve Maurer Organization: Vicom Systems Inc. San Jose, Cal. Subject: Outright bug in the SGI C compiler... Message-Id: <1989Nov27.234730.25669@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL While trying to polish off the ends of a project, I ended up having to do a work-around for a mutual design deficiency between our product and the SGI compiler. However, on the work around itself, I found another, much less forgivable bug in the SGI compiler; an outright violation of the C standard. While the compiler allows pointers to functions to be assigned, it does not allow them to be compared. It also doesn't allow them to be cast to allow comparison. The following example illustrates the problem. It was checked out on a number of other C compilers (Sun being the main one), and it compiled and performs flawlessly. But not on the SGI. - - - - - - - - - - - - - - - - - - - - - - - - void foo(), bar(); main() { void (*pfn)(); pfn = foo; /* SGI compiler allows this */ if ( pfn == foo ) /* but barfs on this */ printf("Pfn calls foo\n"); else printf("Pfn calls bar\n"); } void foo() { } void bar() { } - - - - - - - - - - - - - - - - - - - - - - - - My question is: does anybody know a work around for this flaw? Is there a new release fix for it? If that's the case, I need the new stuff immediately, since the project I'm working on is already way behind. Steve Maurer steve@vicom.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11111; 27 Nov 89 21:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab10687; 27 Nov 89 20:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab10579; 27 Nov 89 20:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08915; 27 Nov 89 20:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23370; Mon, 27 Nov 89 17:20:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 00:01:01 GMT From: Steve Maurer Organization: Vicom Systems Inc. San Jose, Cal. Subject: Re: Outright bug in the SGI C compiler... Message-Id: <1989Nov28.000101.25845@vicom.com> References: <1989Nov27.234730.25669@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Steve Maurer: >- - - - - - - - - - - - - - - - - - - - - - - - > > My question is: does anybody know a work around for this flaw? >Is there a new release fix for it? If that's the case, I need the >new stuff immediately, since the project I'm working on is already way >behind. Never mind. I found a work-around by declaring a dummy procedure rk (for real kludge), which I pass the function pointer to, but declare as an integer argument. Gack. Never thought I'd have to resort to a pascal function pseudo-cast in a C program. Steve Maurer steve@vicom.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11893; 27 Nov 89 23:21 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11786; 27 Nov 89 23:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11728; 27 Nov 89 22:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10551; 27 Nov 89 22:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA02610; Mon, 27 Nov 89 19:40: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: 27 Nov 89 17:46:36 GMT From: Thant Tessman Organization: Silicon Graphics, Inc. Subject: Re: REDRAW question Message-Id: <1628@odin.SGI.COM> References: <21289@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <21289@uflorida.cis.ufl.EDU>, pff@beach.cis.ufl.edu (Pablo Fernicola) writes: > In a program that I am working on, whenever the window gets redrawn the > ghosts of the previous border stays inside the window. > > In that window I make use of writemask, but I thought that using it wouldn't > have any effects on a clear() instruction. Am I right? 'clear()' uses the current writemask. Try: case REDRAW: tmp = getwritemask(); writemask(0xfff) /* or RGBwritemask(0xffffffff) */ color(whatever); clear(); writemask(tmp); ... Have fun, thant   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11997; 27 Nov 89 23:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab11786; 27 Nov 89 23:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11730; 27 Nov 89 22:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10590; 27 Nov 89 22:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA02843; Mon, 27 Nov 89 19:44: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: 27 Nov 89 23:16:21 GMT From: "Mark D. Stadler" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: cron and logins Message-Id: <1636@odin.SGI.COM> References: <8911242042.aa26144@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911242042.aa26144@SMOKE.BRL.MIL> S090726@UMRVMA.UMR.EDU ("Bob B. Funchess") writes: >I want to set up a system on our 4D/20 where certain users can only login >at certain times, such as non-prime hours. The only way I can think of to >do this is to have cron swap /etc/passwd in and out at these times, and >frankly this frightens me a little :). Does anyone have such a setup? >Will you share your secrets? You can mail me direct at the address below... > > > < Bob S090726@UMRVMA.UMR.EDU Funchess > the last field in the /etc/passwd file is the program to exec upon logging in. usually this is /bin/sh, /bin/ksh etc... you could write your own program that validates users according to the time and kick off the appropriate shell from there. (put your validation program name in the /etc/passwd file with an argument of what to invoke if restrictions don't inhibit anything further) it means you have to write your own validation program, but you can get exactly what you want without hacking too much. -- mds [aka Mark D Stadler mds@sgi.com ...!uunet!sgi!mds (415)335-1327]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12132; 27 Nov 89 23:53 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11689; 27 Nov 89 22:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab11593; 27 Nov 89 22:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10399; 27 Nov 89 22:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA01658; Mon, 27 Nov 89 19:25:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 03:04:52 GMT From: Wiltse Carpenter Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: cron and logins Message-Id: <45294@sgi.sgi.com> References: <8911242042.aa26144@SMOKE.BRL.MIL>, <1636@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911242042.aa26144@SMOKE.BRL.MIL> S090726@UMRVMA.UMR.EDU ("Bob B. Funchess") writes: >I want to set up a system on our 4D/20 where certain users can only login >at certain times, such as non-prime hours. The only way I can think of to >do this is to have cron swap /etc/passwd in and out at these times, and >frankly this frightens me a little :). Does anyone have such a setup? >Will you share your secrets? You can mail me direct at the address below... > > > < Bob S090726@UMRVMA.UMR.EDU Funchess > Some of the solutions suggested here could have ill effects if the user was logged in at the time change. A solution that doesn't require and funny cron entries would be to write a program that performs the time checking and use it as a predicate in the /etc/profile and /etc/cshrc files. For instance, in /etc/profile do something like: if check_login_time then echo "This is not a good time to log in. Try again later." sleep 20 exit 0 fi The /etc/profile and /etc/cshrc are shell scripts that are executed by /bin/sh and /bin/csh whenever a user first logs in (or does an su - user). This is a better place to put this sort of thing than changing /etc/passwd on the fly (which has many, many potential pitfalls). -Wiltse Carpenter   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20629; 28 Nov 89 13:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18873; 28 Nov 89 12:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18784; 28 Nov 89 11:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02742; 28 Nov 89 11:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA13178; Tue, 28 Nov 89 08:37:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 16:17:04 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Outright bug in the SGI C compiler... Message-Id: <45310@sgi.sgi.com> References: <1989Nov27.234730.25669@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Nov27.234730.25669@vicom.com> steve@vicom.COM (Steve Maurer) writes: > > > While trying to polish off the ends of a project, I ended >up having to do a work-around for a mutual design deficiency between ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >our product and the SGI compiler. However, on the work around ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please send e-mail on the original compiler problem. I'd like to know what it was so I can fix it. >itself, I found another, much less forgivable bug in the SGI >compiler; an outright violation of the C standard. > > While the compiler allows pointers to functions to be >assigned, it does not allow them to be compared. It also doesn't >allow them to be cast to allow comparison. The following example >illustrates the problem. It was checked out on a number of other >C compilers (Sun being the main one), and it compiled and performs >flawlessly. But not on the SGI. Steve: The problem is that void was not handled properly in released versions of the c compiler. Change the function return types to int and the problem disappears. In the next release (after 3.2) of IRIX void and void * are properly handled. My aplogies for the inconvenience. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24945; 28 Nov 89 19:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24417; 28 Nov 89 17:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24399; 28 Nov 89 17:47 EST Received: from BU.EDU by SMOKE.BRL.MIL id aa00310; 28 Nov 89 17:36 EST Received: by BU.EDU (1.90) Tue, 28 Nov 89 17:06:15 -0500 Received: by adt.uucp (3.2/SMI-3.2) id AA17122; Tue, 28 Nov 89 13:44:39 EST Date: Tue, 28 Nov 89 13:44:39 EST From: james cerrato Message-Id: <8911281844.AA17122@adt.uucp> To: info-iris@BRL.MIL Subject: Problems with queues on 4Dxx We have an application that uses the device queues for MOUSE, KEYBD, INPUTCHANGE, and REDRAW. On the 31xx IRIS workstations this application runs fine. On the 4Dxx this same application has a problem where it inconsistently appears to hang when looking for a LEFT or MIDDLE button click. The 4Dxx machines are running IRIX 3.1g. Is there any known bug or similar problem anyone has encountered where unqdevice or qreset do not seem to work? Or that qtest is not returning correctly when a button is clicked? Thanks for any information. james@adt.uucp James Cerrato Associative Design Technology Westboro, MA   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25090; 28 Nov 89 20:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24889; 28 Nov 89 19:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24878; 28 Nov 89 19:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01565; 28 Nov 89 19:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10871; Tue, 28 Nov 89 15:50:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 22:14:54 GMT From: Arthur David Olson Organization: NIH-LEC, Bethesda, MD Subject: Wanted: help with IRIX 3.2/XV11R3 challenge (repost) Message-Id: <9206@elsie.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Elsie is our Sun 3/280 running SunOS 4.0.3. If I log in to elsie from the console of our SGI IRIS 4D/70G and try to drop pixels into an X window, things go awry--in particular, only the low-order four bits of the pixels being written seem to make it to the window. I've attached a typescript showing the problem (the incorrect results are marked with ">>>>"s). If you can tell me what I'm doing wrong, I'd appreciate hearing from you by electronic mail. -- Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex. Script started on Thu Nov 16 14:16:02 1989 elsie$ cat try.c #include #include #define WIDTH 20 #define HEIGHT 1 Display * display; int screen_number; Visual * visual; Window root_window; Window window; GC default_gc; XImage * ximage; char data[WIDTH][HEIGHT]; main() { int x, y; display = XOpenDisplay((char *) NULL); if (display == 0) abort(); root_window = DefaultRootWindow(display); screen_number = XDefaultScreen(display); visual = DefaultVisual(display, screen_number); default_gc = DefaultGC(display, screen_number); window = XCreateSimpleWindow(display, root_window, 300, 300, WIDTH, HEIGHT, 2, 0, 1); XMapWindow(display, window); XSync(display, 0); (void) printf("Tap RETURN when the window is in place.\n"); (void) getchar(); ximage = XCreateImage(display, visual, 8, ZPixmap, 0, (char *) data, WIDTH, HEIGHT, 8, 0); if (ximage == 0) abort(); for (x = 0; x < WIDTH; ++x) for (y = 0; y < HEIGHT; ++y) XPutPixel(ximage, x, y, x); XPutImage(display, window, default_gc, ximage, 0, 0, 0, 0, WIDTH, HEIGHT); ximage = XGetImage(display, window, 0, 0, WIDTH, HEIGHT, (unsigned long) ~0, ZPixmap); for (x = 0; x < WIDTH; ++x) for (y = 0; y < HEIGHT; ++y) (void) printf("data[%d][%d]\t%d\n", x, y, XGetPixel(ximage, x, y)); return 0; } elsie$ cc -g try.c -lX11 -o try elsie$ try Tap RETURN when the window is in place. data[0][0] 0 data[1][0] 1 data[2][0] 2 data[3][0] 3 data[4][0] 4 data[5][0] 5 data[6][0] 6 data[7][0] 7 data[8][0] 8 data[9][0] 9 data[10][0] 10 data[11][0] 11 data[12][0] 12 data[13][0] 13 data[14][0] 14 data[15][0] 15 >>>> data[16][0] 0 >>>> data[17][0] 1 >>>> data[18][0] 2 >>>> data[19][0] 3 elsie$ exit script done on Thu Nov 16 14:16:47 1989   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25526; 28 Nov 89 23:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25313; 28 Nov 89 22:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25305; 28 Nov 89 22:27 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02329; 28 Nov 89 20:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA15802; Tue, 28 Nov 89 17:08:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Nov 89 00:40:12 GMT From: Deb Ryan Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: floating-point exceptions Message-Id: <45357@sgi.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is a short overview of the trap handler package we plan to provide in the next release: caveat: I should not be making promises -but all the work has been done. (Edited from the man page) Background: The MIPS floating-point accelerator may raise floating-point exceptions due to five conditions: overflow, underflow, divide by zero, inexact result or invalid operand (e.g. infinity). Usually these conditions are masked, and do not cause a floating-point exception. Instead, a default value is substituted for the result of the operation, and the program continues silently. This event may be intercepted by causing an exception to be raised. Once an exception is raised, the specific conditions which caused the exception may be determined, and more appropriate action taken. Our solution: The floating point library provides two methods to unmask and handle these conditions: a subroutine interface, and an environment variable. The environment variable requires no change to user code. Both methods provide a mechanism for unmasking each condition except inexact result, for handling and classifying exceptions arising from them, and for substituting either a default value or a chosen one. They also provide mechanisms to count, trace, exit or abort on enabled exceptions. If more control is required, the subroutine interface provides the ability to call a user written routine. The environment variable is supported for Fortran, C and Pascal. The subroutine interface is supported for C and Fortran. Limitations: Some math library routines, like sqrt, are written in software and do not yet conform to IEEE standards. As a result, the square root of a negative number, for example, will produce Nan and not get caught by the trap handler until used in user code. -- -Deb deb@sgi.com Deborah Caruso @ Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25712; 28 Nov 89 23:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25601; 28 Nov 89 23:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25591; 28 Nov 89 23:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00826; 28 Nov 89 23:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26955; Tue, 28 Nov 89 20:06:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 16:40:05 GMT From: Michael Toy Organization: Silicon Graphics, Entry Systems Division Subject: Re: Outright bug in the SGI C compiler... Message-Id: <1650@odin.SGI.COM> References: <1989Nov28.000101.25845@vicom.com>, <1989Nov27.234730.25669@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I compiled and ran the example verbatim from your message, and .... it works fine for me. My guess is that you are running an older release of IRIX. Under 3.2, no such problem exists. Michael Toy   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25821; 29 Nov 89 0:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25601; 28 Nov 89 23:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab25591; 28 Nov 89 23:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00830; 28 Nov 89 23:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27142; Tue, 28 Nov 89 20:10: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: 28 Nov 89 18:50:28 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Maximum number of windows Message-Id: <1658@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Several people have questioned my statements about the maximum number of windows. I was indeed wrong. Here's the scoop. On 4D/[567]0[G] machines (internally known as Clover 1) you can have a maximum of 64 GL windows. This is the number of graphics contexts supported by the graphics controller hardware. On 4D/X0GT and 4D/XX0GTX[B] (Professional Series and Power Series) machines you can have a maximum of 256 windows. The limit comes from the size of the memory segment shared between the GL and the window server. This limit was not increased in IRIX release 3.2. On the 4D/2[05] (Personal Iris) the limit is (apparently) 50 windows, limited by the same shared memory segment. Since many PI's are shipped with only 8 MB of memory we decided to reduce the size of the segment. This is the limit I thought had been raised in 3.2 but apparently it hasn't been. In all cases you can have an unlimited number of NeWS windows and, if you are running an X window manager, an unlimited number of X windows. If you aren't running an X window manager, each X window is a GL window so the above limits apply. -- 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 aa15554; 29 Nov 89 23:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15517; 29 Nov 89 22:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15505; 29 Nov 89 22:42 EST Received: from megaron.arizona.edu by SMOKE.BRL.MIL id aa26149; 29 Nov 89 22:22 EST Received: by megaron.arizona.edu (5.59-1.7/15) id AA01028; Tue, 28 Nov 89 16:39:51 MST Received: by uazaic.SGI (5.52/5.6) id AA09955; Tue, 28 Nov 89 16:46:26 PST Date: Tue, 28 Nov 89 16:46:26 PST From: Dolata Message-Id: <8911290046.AA09955@uazaic.SGI> To: arizona!info-iris%brl.mil@cs.arizona.edu Subject: SGI KCL Over a year ago I got a copy of KCL from Texas, and a set of changes for the Iris from Raible@arville.nas.nasa.gov I didn't look at them for a year. Recently I have been trying to implement KCL on our Iris, and have run into trouble. Small things like adding include in kcl/c/file.c were no problem, I fixed the makefiles, but I have problems when the nascent kcl tries to initialize kcl/lsp/arraylib "unexpected end of file". I am a little leary of proceeding further since the process starting going wrong from the very early stages... I don't know why. I have an Iris 3130, running GL2-W3.6. Where are the SGI-diffs for KCL kept now? ANybody brought it up? Any hints? Help??? Thanks Dan uazaic!dolata@arizona.edu dolata@rvax.ccit.arizona.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00205; 29 Nov 89 9:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29336; 29 Nov 89 9:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29140; 29 Nov 89 8:43 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa05808; 29 Nov 89 8:29 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA23474; Wed, 29 Nov 89 08:30:36 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA17865; Wed, 29 Nov 89 07:44:34 -0500 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA02011; Wed, 29 Nov 89 00:24:13 EST Date: Wed, 29 Nov 89 00:24:13 EST From: Rod Paul Message-Id: <8911290524.AA02011@dasys1.UUCP> To: celia!charlie@cs.utexas.edu, info-iris@BRL.MIL Subject: Re: CCIR 601, D1, Digital Video >>I'm sorry to hear about the kludge; VideoCreator, that has just been anounced >>on this newsgroup. >>It it such a pity that SGI, who undoubtedly produce one of the finest platforms >>for high-end 3D graphics, continue to neglect the field of BROADCAST video. .... >>To get some form of decent video out, I've had to use an Abekas A60 via >>ethernet, an option that I'm sure is not within the budget of many a user. >>The one problem with the above method is the time it takes to convert RGB images >>to the digital video format, CCIR 601, which the Abekas needs as input. >> >>I must admit that dealing with digital video is the easiest, and that is why >>I wonder why SGI doesn't seem to be addressing this avenue. >Since Tektronix now offers an RGB-IN 601-OUT framebuffer in >their 88000 based workstations, and because those stations are causing >a bit of a rumble in the video world, I suspect that SGI will soon >follow suit. I know that this is not a new request -- we've been >harping on them for over a year. Hmm, anyone from SGI care to comment? Is the market too small for you guys to bother with? >If speed is a real problem, and you have an Abekas A60, you might want to >buy an A20, which is a real-time ANALOG RGB to 601 encoder. I think that >it's only about $5000. We have one, and you can snap frames onto the A60 >as fast as you can display them on a frame buffer. The quality is obviously >not quite as good as a purely digital transfer, but it sure beats waiting >around for some old tape machine to preroll and edit single frames. This is the method I use for my rough tests, fast but dirty. Thanks for the comments anyway Charlie.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10384; 29 Nov 89 15:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08303; 29 Nov 89 14:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08214; 29 Nov 89 14:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16644; 29 Nov 89 13:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16661; Wed, 29 Nov 89 10:41:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Nov 89 18:12:42 GMT From: "Scott R. Presnell" Organization: UC San Francisco, Pharmaceutical Chemistry Subject: Avenrun in IRIX 3.2 Message-Id: <12452@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi all, Avenrun seems to be available in the IRIX 3.2 kernel as an array of longs. But as in the Sun kernel it appears to need a scaling... 1024 seems about right. Does anyone know what and/or where the appropriate constant might be found? Thanks. -Scott Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13785; 29 Nov 89 16:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13371; 29 Nov 89 16:47 EST Received: from sem.brl.mil by VMB.BRL.MIL id aa13353; 29 Nov 89 16:32 EST Date: Wed, 29 Nov 89 16:31:22 EST From: Mike Muuss To: Steve Maurer cc: info-iris@BRL.MIL Subject: Re: Outright bug in the SGI C compiler... Message-ID: <8911291631.aa03560@SEM.BRL.MIL> One workaround might be to create a union between the function pointer and a long. Assign into the pointer element, compare the long element. Ugly, but it will get you going. You can probably hide it with some macros if you have to do it a lot. Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14696; 29 Nov 89 19:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14614; 29 Nov 89 18:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14595; 29 Nov 89 18:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23812; 29 Nov 89 17:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA00369; Wed, 29 Nov 89 14:10: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 Nov 89 17:40:42 GMT From: Donald Bouchard Organization: University of Pennsylvania, Philadelphia, PA Subject: 4D/240 Disk Drives Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We currently have a 4D/240GT with one 380MB ESDI drive and would like to add up to 3 more to fill the controller. We would like to find out if anyone has added 3rd party drives and if anything additional from SGI was required. Donald Bouchard Internet: bouchard@sg1.chem.upenn.edu Department of Chemistry AT&T: (215) 898 4886 University of Pennsylvania Philadelphia, PA 19104-6323 "Would you like to know what I think of the IBM?", she asked. "No ma'am, just the VAX".   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac14696; 29 Nov 89 19:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac14614; 29 Nov 89 18:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab14605; 29 Nov 89 18:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24290; 29 Nov 89 18:25 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04901; Wed, 29 Nov 89 15:18:33 -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 Nov 89 22:57:33 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: /dev/audio and Personal IRIS Message-Id: <573@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi Netlanders, Been doing a bit of playing around with the sound capabilities of the Personal IRIS, and was wondering what software is available before I start bending my own code. Also does anyone have any references on computer generated sound? Responses will be summerized and posted 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 ab15432; 29 Nov 89 22:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15365; 29 Nov 89 22:23 EST Received: from sem.brl.mil by VMB.BRL.MIL id aa15343; 29 Nov 89 22:04 EST Date: Wed, 29 Nov 89 21:55:28 EST From: Mike Muuss To: dftsrv!drax!buck@ames.arc.nasa.gov cc: info-iris@BRL.MIL Subject: Re: /dev/audio and Personal IRIS Message-ID: <8911292155.aa05870@SEM.BRL.MIL> Hi Buck - You won't be too satisfied with sound that is only 8-bits wide. That gives "telephone quality" sound. 16-bits with linear encoding (at 44,100 samples/second) will give "compact disk" quality, which is certainly NOT the end-all in sound quality. But, for playing around, it should be a bit of fun. Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18914; 30 Nov 89 8:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17462; 30 Nov 89 7:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17437; 30 Nov 89 7:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29182; 30 Nov 89 7:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA17463; Thu, 30 Nov 89 03:50:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Nov 89 19:09:00 GMT From: tank!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!kenyon@handies.ucar.edu Subject: Telnetd problem in 3.2? Message-Id: <84600002@uicbert.eecs.uic.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a problem with telnetd on 3.2? I have ksh88 running on my 4D/120GTX under 3.2. When I login at the console all works as expected. When I login from a terminal (vt100) through ethernet I get logged out when I enter a ^C ( intr = ^C). If I change the intr to anything else, eg. ^P, when I enter that command (^P) I get logged off the system. This problem started when I changed to 3.2. If I use the same version of ksh88 on a 3.1g system (4D/20) this problem is gone. Therefore to see if it was the telnetd from 3.2 I copied the telnetd from the 3.1g system to the 3.2 system and the problem is gone. If I copy the 3.2 telnetd to the 3.1g system now that system has the same problem I had with the 3.2 system. Any Ideas? Bob Kenyon 128.248.166.25   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02331; 30 Nov 89 23:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02243; 30 Nov 89 22:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02234; 30 Nov 89 22:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18735; 30 Nov 89 22:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16759; Thu, 30 Nov 89 19:27:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 04:35:41 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: 38.4Kb (again) Message-Id: <10195@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i have tried to use an SGI 4D240 to drive an rs232 line at 38.4Kb (8 bits data + 1 parity) and have some evidence that it doesn't work. (our line monitor only goes at 19.2!) does anyone drive a such a line from a 4D240 or 4D2?? (i remember someone posting a query about this a while back but no response was posted.) andrew@research.att.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16614; 30 Nov 89 3:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16434; 30 Nov 89 2:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16416; 30 Nov 89 2:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27495; 30 Nov 89 2:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04209; Wed, 29 Nov 89 23:06:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 06:49:34 GMT From: Ramani Pichumani Organization: Computer Science Department, Stanford University Subject: Xw toolkit Message-Id: <1989Nov30.064934.3993@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've recently started programming with the Xt widget set our PI but noticed that the libXw.a file is conspicuously missing from /usr/lib in Irix 3.2. Is this library normally shipped with the X11 environment? All the other X libraries seem to be there. 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 aa16740; 30 Nov 89 4:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16540; 30 Nov 89 3:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16502; 30 Nov 89 2:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27684; 30 Nov 89 2:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05851; Wed, 29 Nov 89 23:36:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 07:14:09 GMT From: Ramani Pichumani Organization: Stanford University Computer Science Department Subject: Xw toolkit again Message-Id: <1989Nov30.071409.4827@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm trying to write an X application using the Xt and widget toolkits on our PI running Irix 3.2. Unfortunately, I can't locate the libXw.a library anywhere. We seem to have all the other X libraries except for this one. Is it supposed to be part of the X11 environment on the Personal Iris? Thanks, 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 aa22852; 30 Nov 89 10:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21660; 30 Nov 89 9:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21391; 30 Nov 89 9:29 EST Received: from [192.12.31.1] by SMOKE.BRL.MIL id aa03604; 30 Nov 89 9:24 EST Date: Thu, 30 Nov 89 9:20:24 EST From: "Prof. David F. Rogers" To: info-iris@BRL.MIL Subject: Telnetd problem in 3.2 Message-ID: <8911300920.aa12491@CAD.USNA.MIL> G'day I have the same problem with ^C logging me out with 3.2 and I am using the Bourne shell so it is probably not the Korn shell. BTW where can I get the Korn shell? Dave Rogers   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23578; 30 Nov 89 10:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab22852; 30 Nov 89 10:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab22709; 30 Nov 89 9:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04207; 30 Nov 89 9:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA25507; Thu, 30 Nov 89 06:21:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 14:18:13 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Backup Method for Restore Message-Id: <374@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On a IRIS 4D/80-GT: What is the best way to backup a disk with two partitions so that I can restore the disk to its exact state should the disk become erased? Scenario: - I install system 3.2 - User's tasks break - The boss demands a return to the privious state of affairs, for now - I now have to undo the system installation and return to previous state How will I do this and what kind of tapes should I have to make it real easy to do? /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 aa25832; 30 Nov 89 12:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25504; 30 Nov 89 12:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25447; 30 Nov 89 12:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07563; 30 Nov 89 11:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04351; Thu, 30 Nov 89 08:43:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 15:59:43 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: problems with RECTRE and other little things Message-Id: <2994@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL After all the recent discussion of video thangs, it reminds me of a problem that we have yet to resolve. It goes like this: In order to make things easier (which is a subjective opinion) we had written our own routine to 'compress' a full 1280x1024 image down to TV size of (about) 640x484. To do this we used the RECTRE subroutine to read the colormap info for the whole screen into an array. We then determined what the RGB values were and went about our averaging to reduce it down to TV size and then dumped it to a file for transfer to the Abekus A60. All was fine and dandy until we had the 70GT upgraded to a 120GTX. Now, the results of RECTRE turn out really(!!) strange (yes, I've recompiled it numerous times). It seems that it now only reads in about a quarter of the screen (from 0,0 to about ~600,600 in pixels) and of that which it does read in, there are random lines where it is missing colormap information. For example, if I cleared the screen as say green, call RECTRE, then look at the array that it read the map info into, only the pixels for the lower left half of the screen show a colormap number of 2, the rest are all zero (black) with random horizontal lines also containing zero's. Here's what the program looks like: (I haven't totally learned C yet so its in fortran) INTEGER*2 SGIS(0:1310720) INTEGER*4 TEST . . graphics inits . . TEST=RECTRE(1,1,1274,1022,SGIS) WRITE(6,*)TEST WRITE(8,*)SGIS . . averaging stuff . . END The value of TEST should be the number of pixels that were read by RECTRE, this also used to work. This had worked beautifully before the upgrade but now it doesn't. In the upgrade, the OS release went from 3.1B to 3.1D, with the machine going from a single processor to a two processor unit. I couldn't imagine a rather minor OS change affecting things this much, going to two processors seems like a more probable cause, but anything can happen. *************************************** HELP!HELP!HELP!HELP!HELP! big projects are approaching their deadlines!! *************************************** While I'm on the subject of idiosyncrasies, every once and a while, I have the need to run a few graphics programs in sequential order where I don't have to do any interacting with them as they run (like averaging several images from separate programs). So its real handy to put them in a script and execute them in order (like during lunch). The problem is is that as soon as the first program initializes the graphics (like opening a window) the unix prompt is returned. Well, right away the next program starts to run. But wait! The first program isn't even half way completed yet. This continues to the point where the cpu('s) are so overloaded that virtually nothing happens. (By the way, if one processor is displaying graphics images on the screen, and the other processor tries to run a graphics program also, you never see its results anywhere. Is the second one floating in la-la land somewhere or what?) The problem is is that when the graphics mode kicks in, the system will start to accept input from std. input. *** Is there a way to prevent this???? i.e. wait until one graphics program is completely finished until the system returns to accepting input??? This is more annoying than it is a problem but nonetheless it'd be nice if it can be fixed. Any help on any of the above problems from the audience out there would be a great help. Tom Rohling CFD dude University of Cincinnati ========================================================================== 'No more heros, No more lights. No more darkness, No more fights.' - deep dark poetry attempt by myself ==========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26973; 30 Nov 89 13:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26473; 30 Nov 89 13:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26353; 30 Nov 89 13:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08899; 30 Nov 89 12:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08304; Thu, 30 Nov 89 09:44:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 17:25:31 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Telnetd problem in 3.2? Message-Id: <45462@sgi.sgi.com> References: <84600002@uicbert.eecs.uic.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <84600002@uicbert.eecs.uic.edu>, kenyon@uicbert.eecs.uic.edu writes: > > Is there a problem with telnetd on 3.2? No. > I have ksh88 running on my > 4D/120GTX under 3.2. When I login at the console all works as expected. > When I login from a terminal (vt100) through ethernet I get logged out > when I enter a ^C ( intr = ^C). If I change the intr to anything else, > eg. ^P, when I enter that command (^P) I get logged off the system. > > This problem started when I changed to 3.2. If I use the same version > of ksh88 on a 3.1g system (4D/20) this problem is gone. > > Therefore to see if it was the telnetd from 3.2 I copied the telnetd from > the 3.1g system to the 3.2 system and the problem is gone. If I copy the > 3.2 telnetd to the 3.1g system now that system has the same problem I > had with the 3.2 system. > > Any Ideas? > > > Bob Kenyon > 128.248.166.25 There were some fixes to terminal handling and such in 3.2. I'm using ksh88 right now, and log in to 3.2 systems all the time via rlogin and telnet (from terminal servers). I vaguely remember having a similar problem when first porting ksh88, so I think it's the port, not telnet. Check are that you use RAWONLY mode, I believe this may have something to do with it. Perusing the local port, the only sgi specific changes I made were 1) fixed the infinite loop bug in history.c when opening a history file, and 2) added some define's to jobs.c to make job control work. Other than that, raw mode seems to be the interesting one. -- 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 aa01757; 30 Nov 89 20:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01576; 30 Nov 89 20:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01553; 30 Nov 89 19:54 EST Received: from cypress.sgi.cs.net by SMOKE.BRL.MIL id aa17309; 30 Nov 89 19:50 EST Received: by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA27187; Thu, 30 Nov 89 16:51:10 PST Date: Thu, 30 Nov 89 16:51:10 PST From: Andrew Cherenson Message-Id: <8912010051.AA27187@sgi.sgi.com> To: info-iris@BRL.MIL Subject: Re: Telnetd problem in 3.2? In article <84600002@uicbert.eecs.uic.edu> kenyon@uicbert.eecs.uic.edu writes: > > Is there a problem with telnetd on 3.2? It's fixed in the 3.2.1 maintenance release. The 3.1F or 3.1G telnetd should suffice until then. Csh users aren't affected.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01757; 30 Nov 89 20:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01685; 30 Nov 89 20:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01616; 30 Nov 89 20:05 EST Received: from cypress.sgi.cs.net by SMOKE.BRL.MIL id aa17348; 30 Nov 89 19:55 EST Received: by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA27303; Thu, 30 Nov 89 16:55:31 PST Date: Thu, 30 Nov 89 16:55:31 PST From: Andrew Cherenson Message-Id: <8912010055.AA27303@sgi.sgi.com> To: info-iris@BRL.MIL, srp@cgl.ucsf.edu Subject: Re: Avenrun in IRIX 3.2 In article <12452@cgl.ucsf.EDU> srp@cgl.ucsf.edu (Scott R. Presnell) writes: >Hi all, > Avenrun seems to be available in the IRIX 3.2 kernel as an array of >longs. But as in the Sun kernel it appears to need a scaling... 1024 seems >about right. Does anyone know what and/or where the appropriate constant >might be found? 1024 is correct. Here's a sample program to access avenrun. ------ Cut here ---------------------------------------------- /* * loadavg.c -- * * Prints 1, 5, and 15 minute load averages for an * IRIS-4D running IRIX 3.2. * * As root, do * cc loadavg.c -lmld -o loadavg * chgrp sys loadavg * chmod 2555 loadavg * (It must be setgid sys to read /dev/kmem.) * * This file is in the public domain. * THIS FILE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND * INCLUDING THE WARRANTIES OF DESIGN, MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, * USAGE OR TRADE PRACTICE. * * This file is provided with no support and without any * obligation on the part of Silicon Graphics, Inc. to assist in * its use, correction, modification or enhancement. * * SILICON GRAPHICS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO * THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY * THIS FILE OR ANY PART THEREOF. * * In no event will Silicon Graphics, Inc. be liable for any lost * revenue or profits or other special, indirect and consequential * damages, even if Silicon Graphics has been advised of the * possibility of such damages. */ #include #include struct nlist nl[] = { { "avenrun" }, { "" }, }; main() { int kmem, i; long avenrun[3]; if ((kmem = open("/dev/kmem", 0)) < 0) { perror("/dev/kmem"); exit(1); } if (nlist("/unix", nl) < 0) { fprintf(stderr, "bad namelist\n"); exit(1); } if (nl[0].n_type == 0) { fprintf(stderr, "can't find avenrun\n"); exit(1); } if (lseek(kmem, (long)nl[0].n_value & 0x7fffffff, 0) < 0) { perror("lseek"); exit(1); } (void) read(kmem, (char *) avenrun, sizeof(avenrun)); printf("load average:"); for (i = 0; i < (sizeof(avenrun)/sizeof(avenrun[0])); i++) { if (i > 0) printf(","); printf(" %.2f", ((double) avenrun[i])/1024.0); } printf("\n"); exit(0); }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01902; 30 Nov 89 21:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01576; 30 Nov 89 20:03 EST Received: from church.csri.toronto.edu by VMB.BRL.MIL id aa01541; 30 Nov 89 19:54 EST Received: from localhost (stdin) by church.csri.toronto.edu with SMTP id 187; Thu, 30 Nov 89 19:52:58 EST To: info-iris@vmb.brl.mil Subject: Re: X libraries Date: Thu, 30 Nov 89 19:52:40 EST From: Mark Moraes Message-Id: <89Nov30.195258est.187@church.csri.toronto.edu> We've been happily running the MIT X libraries (X, Xt, Xmu, Xaw, oldX, Xext) as well as Xw for a while now -- even under 3.1. They compile fine with cc -I/usr/include/bsd and the same mods as the Mips.macros files indicate. In fact, we compiled most of the MIT X distribution's core and selected parts of contrib. Note: some versions of the MIPS C compiler have been known to dump core on compiling some files in Xw with -O. They compile fine without -O. (Works fine on 3.1 and 3.2 on SGI, anyway) On expo.lcs.mit.edu, via anonymous ftp, contrib/Xhp.R3.tar.Z contains a working Xw for R3. (Also on cs.toronto.edu in pub/X/Xhp.R3.tar.Z, on uunet.uu.net in X/contrib.R3/Xhp.R3.tar.Z, giza.cis.ohio-state.edu in pub/X.V11R3/contrib/Xhp.R3.tar.Z and many other archive sites)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02798; 1 Dec 89 0:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02716; 1 Dec 89 0:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02676; 1 Dec 89 0:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19377; 1 Dec 89 0:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA21752; Thu, 30 Nov 89 20:55: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 Nov 89 17:59:22 GMT From: "George Baciu [CGL]" Organization: U of Waterloo, Ontario Subject: X11 with IRIX 3.2 Message-Id: <12495@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We just installed 3.2 and I was glad to see the X11 images on the release tape. However, after installing all X11 images (manually) I was surprised not to find any of the standard X11 development libraries on the system. My question is, exactly what parts of X11 come bundled with 3.2? Is it the server only, and no libraries, or are the libraries supposed to be included? --- George Baciu --- ----------------------------------------------------------------- | GBaciu@watcgl.Waterloo.edu GBaciu@watcgl.UWaterloo.CA | | * Computer Graphics Lab * | | University of Waterloo - Waterloo, Ontario, Canada - N2L 3B5 | -----------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00528; 1 Dec 89 4:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00324; 1 Dec 89 3:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00314; 1 Dec 89 3:24 EST Received: from Princeton.EDU by SMOKE.BRL.MIL id aa20492; 1 Dec 89 3:18 EST Received: from gauss.Princeton.EDU by Princeton.EDU (5.58+++/2.25/mailrelay) id AA08322; Fri, 1 Dec 89 03:05:39 EST Received: by gauss.Princeton.EDU (5.61/1.95) id AA04415; Fri, 1 Dec 89 03:09:05 -0500 Date: Fri, 1 Dec 89 03:09:05 -0500 From: ams@acm.princeton.edu Message-Id: <8912010809.AA04415@gauss.Princeton.EDU> To: info-iris@BRL.MIL Subject: Re: X11 with IRIX 3.2 In an effort to keep development on the Personal Iris (and other machines that dev kits are an option), SGI has elected to make the X window development kit for 3.2 a separate option. This should hopefully contain all the missing parts allowing X window development to take place. I can't answer you specific question at this time as we have yet to receive our X dev kits due to several ordering screw-ups. This btw, is a very annoying arrangement. I sincerely hope that someday SGI will realize that X sells more Irises and if people put in the money for development kits, they should get the X stuff by default. Ordering it seperately is really stupid (having to order dev kits in the first place is also questionable). --ams _________________________________________________________________________ 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 aa01536; 1 Dec 89 13:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00424; 1 Dec 89 12:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac00188; 1 Dec 89 12:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25594; 1 Dec 89 9:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22702; Fri, 1 Dec 89 06:19: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: 1 Dec 89 01:51:16 GMT From: Stephen Kirby Organization: Mincom, Brisbane, Australia Subject: IRIX 3.2.1 maintenance release problem Message-Id: <279@mincom.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I received a maintenance release of IRIX 3.2.1 from Silicon Graphics, which was to fix some system hangs and network problems we experienced on IRIX 3.2 on our IRIS 140 4cpu server system. IRIX 3.2.1 has run for two days then it also crashed with a new type of condition. This time CPU1 went into a mode of 100% kernel activity. The CPU's 0 2 3 were basiclly idle. User consoles started to lock up. The network died. If a console which was working started a new shell it would die. The system console was active and allowed us to run osview. However we could not kill processes. And a powerdown did nothing. So we had to reset the system. SG still seem to have a problem in getting the multi processor servers to stay up for more than a day or too. We find it very difficult to work with it at the moment. We are using the server to develop software in F77 for the mining and petroleum industries. If others are also having problems please let SG know so we can get them to fix it. Thankyou Stephen Kirby MINCOM Australia.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01536; 1 Dec 89 13:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01342; 1 Dec 89 13:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01285; 1 Dec 89 13:24 EST Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa02405; 1 Dec 89 13:16 EST Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA08441; Thu, 30 Nov 89 13:24:43 -0600 Received: by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA11181; Thu, 30 Nov 89 13:11:20 cst Message-Id: <8911301911.AA11181@kailand.kai.com> From: Patrick Wolfe Date: Thu, 30 Nov 89 13:11:16 CST Organization: Kuck and Associates, 1906 Fox Drive, Champaign IL USA 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: Avenrun in IRIX 3.2 > Written by srp@babar.mmwb.ucsf.edu > Avenrun seems to be available in the IRIX 3.2 kernel as an array of > longs. But as in the Sun kernel it appears to need a scaling... 1024 seems > about right. Does anyone know what and/or where the appropriate constant > might be found? FSCALE is sometimes defined in , and on some machines it's missing. It's usually either 1 or 1000. Here's a program that displays the hostname and three load average numbers successfully on SGI Irix 3.2, Sequent Dynix V3.0, Alliant Concentrix V5.0, Concurrent RTU V5.0, and (I think) SunOS 3.0. The original load average code is from the screen program. You need read permissions on /dev/kmem to make it work. #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'loadavg.c' <<'END_OF_FILE' X/* X * loadavg.c - display system load average X * X * Original load average code from the screen V2 program by Oliver Lauman. X */ X X#include X#include X#include X#include X X#if defined(sun) || defined(sequent) || defined(sgi) X#define SUNLOADAV X#endif X X#ifdef SUNLOADAV X#include X#endif X X#undef FSCALE X#ifdef SUNLOADAV X#define FSCALE 1000.0 X#else X#define FSCALE 1.0 X#endif X X#define KMEMNAME "/dev/kmem" X X#ifdef sequent X#define KERNELPATH "/dynix" X#else X#if defined(masscomp) || defined(sgi) X#define KERNELPATH "/unix" X#else X#define KERNELPATH "/vmunix" X#endif /* masscomp or sgi */ X#endif /* sequent */ X X#ifdef alliant X#define LOADAVGSYMBOL "_Loadavg" X#else X#ifdef sgi X#define LOADAVGSYMBOL "avenrun" X#else X#define LOADAVGSYMBOL "_avenrun" X#endif /* sgi */ X#endif /* alliant */ X X#ifdef SUNLOADAV X#define LOADAVGTYPE long X#else X#ifdef alliant X#define LOADAVGTYPE long X#else X#ifdef masscomp X#define LOADAVGTYPE float X#else X#define LOADAVGTYPE double X#endif /* masscomp */ X#endif /* alliant */ X#endif /* SUNLOADAV */ X Xstatic struct nlist nl[2]; X# Alliant actually has FOUR numbers available, the last one X# being the load average over the past 60 minutes. X# We'll ignore that for portability Xstatic LOADAVGTYPE loadav[3]; Xstatic int kmemf; Xstatic char KmemName[] = KMEMNAME; Xstatic char UnixName[] = KERNELPATH; Xstatic char AvenrunSym[] = LOADAVGSYMBOL; Xstatic char hostname[64]; X Xmain () { X X /* X * get name of this host X */ X if (gethostname (hostname, 64) == -1) { X perror ("gethostname failed"); X exit (1); X } X X /* X * open kernel memory X * may require special priviledges X */ X if ((kmemf = open (KmemName, O_RDONLY)) == -1) { X perror ("open of /dev/kmem failed:"); X exit (1); X } X X /* X * locate load average numbers X */ X nl[0].n_name = AvenrunSym; X nlist (UnixName, nl); X if (nl[0].n_type == 0 || nl[0].n_value == 0) { X perror ("nlist of Unix kernel failed:"); X exit (1); X } X X /* X * seek into kmem X */ X#ifdef sgi X if (lseek (kmemf, nl[0].n_value & ~0x80000000, 0) == -1) { X#else X if (lseek (kmemf, nl[0].n_value, 0) == -1) { X#endif X perror ("lseek into /dev/kmem failed"); X exit (1); X } X X /* X * read numbers from memory X */ X if (read (kmemf, loadav, sizeof (loadav)) != sizeof (loadav)) { X perror ("read from /dev/kmem failed"); X exit (1); X } X X /* X * display the numbers X */ X X printf ("%s %04.2f %04.2f %04.2f\n", hostname, (LOADAVGTYPE)loadav[0]/FSCALE, X (LOADAVGTYPE)loadav[1]/FSCALE, (LOADAVGTYPE)loadav[2]/FSCALE); X X exit (0); X } END_OF_FILE if test 2516 -ne `wc -c <'loadavg.c'`; then echo shar: \"'loadavg.c'\" unpacked with wrong size! fi # end of 'loadavg.c' fi if test -f 'Makefile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'Makefile'\" else echo shar: Extracting \"'Makefile'\" \(377 characters\) sed "s/^X//" >'Makefile' <<'END_OF_FILE' X# uncommment for SGI X#LIBS = -lmld X XCFLAGS = -g $(INCLUDES) $(DEFINES) XBIN = /usr/local/bin XKMEMGRP = kmem XSHELL = /bin/sh X Xloadavg: loadavg.c X $(CC) $(CFLAGS) -o loadavg loadavg.c $(LIBS) X Xinstall: loadavg X rm -f $(BIN)/loadavg X cp loadavg $(BIN)/loadavg X -chgrp $(KMEMGRP) $(BIN)/loadavg X chmod 2711 $(BIN)/loadavg X Xclean: X rm -f a.out core mklog loadavg *.o END_OF_FILE if test 377 -ne `wc -c <'Makefile'`; then echo shar: \"'Makefile'\" unpacked with wrong size! fi # end of 'Makefile' fi echo shar: End of shell archive. exit 0   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01989; 1 Dec 89 14:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01022; 1 Dec 89 13:08 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa01016; 1 Dec 89 12:56 EST Received: from uxc.cso.uiuc.edu by ADM.BRL.MIL id aa14753; 1 Dec 89 12:45 EST Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA09533; Thu, 30 Nov 89 14:21:01 -0600 Received: by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA11476; Thu, 30 Nov 89 13:44:41 cst Message-Id: <8911301944.AA11476@kailand.kai.com> From: Patrick Wolfe Date: Thu, 30 Nov 89 13:44:36 CST Organization: Kuck and Associates, 1906 Fox Drive, Champaign IL USA 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: why separate getpwent routines for YP? I installed YP (Yellow Pages) on our network this week, and RCS V4.2 commands started crashing with segmentation faults. I found (from the getpwent(3) online manpage) that SGI ships two versions of the "getpw*" calls, one that understands YP and one that doesn't? Once I learned this, it was trivial to fix the Makefile and recompile, but I can't help wonder why anyone would want to ship (and maintain) two separate versions? -- Patrick Wolfe System Manager, Kuck & Associates work: pwolfe@kailand.kai.com or uunet!kailand!pwolfe home: pat@pawnix.kai.com or uunet!kailand!pawnix!pat   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18453; 4 Dec 89 7:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18121; 4 Dec 89 7:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18089; 4 Dec 89 6:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02848; 4 Dec 89 6:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27942; Mon, 4 Dec 89 03:33:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Dec 89 01:51:17 GMT From: Thant Tessman Organization: Silicon Graphics, Inc. Subject: Re: problems with RECTRE and other little things Message-Id: <1710@odin.SGI.COM> References: <2994@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2994@uceng.UC.EDU>, trohling@uceng.UC.EDU (tom rohling) writes: [first problem deleted... I try to ignore FORTRAN with the hope that it will go away] > While I'm on the subject of idiosyncrasies, [description of second problem shortened] > The problem is is > that when the graphics mode kicks in, the system will start to accept input > from std. input. *** Is there a way to prevent this???? i.e. wait until > one graphics program is completely finished until the system returns to > accepting input??? Precede your call to winopen with a call to foreground. It makes it do exactly what you want. > > Any help on any of the above problems from the audience out there would be a > great help. > > > Tom Rohling > CFD dude > University of Cincinnati > thant There are 336 dimples on the standard golf ball.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18882; 4 Dec 89 7:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18121; 4 Dec 89 7:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18085; 4 Dec 89 6:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02844; 4 Dec 89 6:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27867; Mon, 4 Dec 89 03:32:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Nov 89 21:34:34 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: Xw toolkit again Message-Id: <1698@odin.SGI.COM> References: <1989Nov30.071409.4827@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The Xw widgets are not part of the standard MIT X distribution. They are more commonly known as the HP widgets. I don't know of anyone that ships these as a supported part of their product. We do ship and support the Athena Widgets(Xaw). --Jeff   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07232; 2 Dec 89 7:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07147; 2 Dec 89 6:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07140; 2 Dec 89 6:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14917; 2 Dec 89 6:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05690; Sat, 2 Dec 89 03:29:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Dec 89 17:15:00 GMT From: tank!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!kenyon@handies.ucar.edu Subject: Re: Telnetd problem in 3.2 Message-Id: <84600003@uicbert.eecs.uic.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We, the universtiy of illinois, have license for ksh from ATT. I think the cost to universities is about $2500. However, you sould contact ATT rep for more acurate information. bob kenyon   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07399; 2 Dec 89 9:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07307; 2 Dec 89 8:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07302; 2 Dec 89 8:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15347; 2 Dec 89 8:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10912; Sat, 2 Dec 89 05:31: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: 1 Dec 89 15:46:28 GMT From: Michael Piplani Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: 3'rd Party Laser Optical Disks Message-Id: <9378@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL These will be my final comments on the INTROL 650E Read/Write Many Times Magneto/Laser Optical Disk. The reason these will be my last comments is that we had to return the drive to Introl because we couldn't squeeze it into next years budget despite my recommendations and the support of my management. We thought highly enough of this product that we were going to purchase it, and I am disappointed I won't have it around-- more 1/4" and 1/2" tape juggling to do! The disk drive comes with a driver board which is user installable, and some driver programs which must be loaded into unix. The steps to unload the tape and gen unix are very clear and straight forward. We didn't have a tape drive on our personal iris and were able to unload the tape from a remote machine with no problem and continue with the installation procedure. Once the driver software is genned in unix you plug the drive into the driver board and you are all set to format, make a filesystem, and mount. The directions on doing those operations were very clear, and examples were given. I was quit pleased with the level of their directions. I would feel very confident giving the whole package to a novice applications programmer and saying: "Here, install this". Introl supplies a set of commands to do operations on the drive, but the higher level unix commands like mkfs, mount, and tar can be used to make the drive visible to the system. Once mounted the drive is like any other unix filesystem; you can cp files to it, create directories etc... You can not tell it's any different from a normal hard disk. We wrote C code that created files and then read from them off the disk, and there were no problems, it behaved exactly the way any disk should. We display Computerized Tomography (CT) images in our programs and we saw no real performance degradation from reading from the slower access optical drive rather then the default drive, but I believe the weak (slow) link in this is we use HOOPS software to display our pixels not SGI GL software to display pixels. As far as our application was concerned there was no noticeable slow down. The optical disk can be used a raw storage device, as the target of a tar command. Formatted and mounted the drive gives about 274Meg a side. Obviously you can not archive anything bigger then that on a disk side. Your total disk storage is well above 500Meg, but you only have access to half of it at a time. The reason for this is the disks are double sided, but there is only one head in the disk drive. To get to the other side you must dismount, eject and then remount the disk (if its been formatted and a filesystem is on it already). Introl has wisely put a software lock on the eject button so that a curious user won't punch the eject button on a mounted filesystem and destroy a whole filesystem. Formatting took +45 minutes a side. The only problems I had were logistical problems in getting the drive up and running from Introl. A sales engineer was going to set things up for me and he was going to bring the drive with him, and ship the cabinet. Well some internals cables didn't make it up here with him, then when they were shipped to me they were the wrong cables so I had to open the cabinet myself and plug them right into the internal connectors. If I had been a normal customer I'm sure this wouldn't have happened. We were the first Personal Iris they installed one of their drives in and there were problems with driver software that showed up about 4 days after use. Introl fixed those problems and the drive worked very well for us over a 3 week period. Like I said earlier I was ready to spend my research groups money on it!. Michael Piplani Senior Research Support Specialist Cornell/Hospital for Special Surgery Program in Biomechanical Engineering internet: piplani@tcgould.tn.cornell.edu bitnet: piplani@crnlimap.bitnet nynex: (607)255-9101   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07510; 2 Dec 89 9:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07460; 2 Dec 89 9:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07425; 2 Dec 89 9:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15433; 2 Dec 89 9:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA11843; Sat, 2 Dec 89 05:53:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Dec 89 23:45:16 GMT From: Mahlon Stacy Organization: Mayo Clinic, Rochester, MN Subject: 3.2 Power Series Login Bug Message-Id: <1781@nic.MR.NET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have discovered a bug in 3.2 that affects logins on Power Series multiprocessor systems. It seems that systems with multiple CPU's that have continuous jobs running in the background constantly (ours is doing molecular modelling) can fail to permit the login process to complete on the console, apparently due to the process required for the login not always being guaranteed to run on CPU 0. SGI's answer for this was to back out to 3.1G. We installed 3.2 twice on this machine already, and someday get to do it again. I'm ticked! ------------------------------------------------------------- Mahlon Stacy Internet: mcs@mayo.edu Mayo Foundation Rochester, MN 55905 Minnesota Regional Network   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08995; 2 Dec 89 15:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08800; 2 Dec 89 14:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08787; 2 Dec 89 14:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17823; 2 Dec 89 14:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA25814; Sat, 2 Dec 89 11:21:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Dec 89 17:12:14 GMT From: Bill Lasher Organization: Penn State University Subject: Problem with 3.2 Message-Id: <89335.121214W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just tried installing a TEK4105 as a terminal on serial port 1 using the icon-driven system manager. The terminal didn't work, so I reverted to the 3.1 manual, and found 2 discrepancies: 1. In /etc/ttytype, the entry was ?tek4105 ttyd1. I removed the ?. 2. In /etc/inittab, the entry was t1:23:.... I changed 23 to 2. After I did this, the terminal worked fine.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08652; 2 Dec 89 14:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08539; 2 Dec 89 13:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08475; 2 Dec 89 13:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17353; 2 Dec 89 13:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22449; Sat, 2 Dec 89 10:18: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: 2 Dec 89 17:25:52 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIX 3.2.1 maintenance release problem Message-Id: <45609@sgi.sgi.com> References: <279@mincom.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <279@mincom.OZ>, stephen@mincom.OZ (Stephen Kirby) writes: > I received a maintenance release of IRIX 3.2.1 from Silicon > Graphics, which was to fix some system hangs and network > problems we experienced on IRIX 3.2 on our IRIS 140 4cpu > server system. > > IRIX 3.2.1 has run for two days then it also crashed with a > new type of condition. This time CPU1 went into a mode of > 100% kernel activity. The CPU's 0 2 3 were basiclly idle. > User consoles started to lock up. The network died. If a console > which was working started a new shell it would die. The system > console was active and allowed us to run osview. However we could > not kill processes. And a powerdown did nothing. So we had to > reset the system. > > SG still seem to have a problem in getting the multi processor > servers to stay up for more than a day or too. > > We find it very difficult to work with it at the moment. We are using > the server to develop software in F77 for the mining and petroleum industries. > > If others are also having problems please let > SG know so we can get them to fix it. > > Thankyou > > Stephen Kirby > MINCOM > Australia. There's an awful lot of assumptions in this one, and not enough information to diagnose (and repair) the problem. Please tell us more! Second, the MP servers are very reliable. Please make sure that there aren't other conditions causing these problems (which you seem to imply have always been going on). First, what is the network environment? 3.2 puts all networking activity on processor 1, so your description immediately makes one think of some problem with your network setup. For instance, constant input or output over the built-in Ethernet can do this. Since the processor is constantly servicing the Ethernet, and you are obviously running many things which depend on networking, then the system could "seem" to hang without really doing so. Perhaps pulling the Ethernet cable when the problem occurs could immediately decide this one. You may also wish to have your FE run diagnostics on the on-board Ethernet interface to check for possible hardware problems as well. -- 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 aa10547; 2 Dec 89 23:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10344; 2 Dec 89 22:46 EST Received: from church.csri.toronto.edu by VMB.BRL.MIL id aa10332; 2 Dec 89 22:34 EST Received: from localhost (stdin) by church.csri.toronto.edu with SMTP id 719; Sat, 2 Dec 89 22:35:21 EST To: info-iris@vmb.brl.mil, xpert@expo.lcs.mit.edu Subject: Re: X libraries for Iris4D Date: Sat, 2 Dec 89 22:35:06 EST From: Mark Moraes Message-Id: <89Dec2.223521est.719@church.csri.toronto.edu> In <89Nov30.195258est.187@church.csri.toronto.edu> in comp.sys.sgi, I wrote: > We've been happily running (sic) the MIT X libraries (X, Xt, Xmu, Xaw, oldX, > Xext) as well as Xw for a while now -- even under 3.1. They compile > fine with cc -I/usr/include/bsd and the same mods as the Mips.macros > files indicate. In fact, we compiled most of the MIT X distribution's > core and selected parts of contrib. Me and my big mouth! For all those who asked, on cs.toronto.edu (128.100.1.65), pub/X/iris4d.libX.tar.Z contains a sort of library/include development kit for X11 on an SGI Iris4D. compiled from the MIT X11R3 distribution (modified a bit by xhacks@csri.toronto.edu) This is provided unsupported, as-is, with no warranty whatsoever, no manuals (get them from the MIT distribution, or one of the publishers that have books on X). If you want support or lack the time/interest/xpertise to babysit this, get the X development kit from SGI. -rw-r--r-- 1 moraes 1757745 Dec 2 21:44 iris4d.libX.tar.Z This doesn't include any X binaries -- you should be enough to bootstrap the rest of the distribution, possibly with some hacking. (We did a 'make -k World > make.world' and stood back...) I think this has got everything in there needed to compile X programs that you can pick off the Internet/comp.sources.x etc. Also, this has not been tested with the SGI X server -- we use our displayless Power Iris as a compute server to drive a variety of workstations/X-terminals. This tar contains the following: bin/ contains imake (binary), ximake, cc.bsd, install and mkdirhier (shell scripts) lib/ contains libraries, and a few other files that may be useful. lib/lint contains lint libraries. include contains X11/ (standard X11 includes for the libraries) and Xw/ which contains includes for libXw. util/imake.includes contains our SGI.macros file -- it's a slightly changed Mips.macros file. Also our Imake.rules, Imake.tmpl and site.def -- you'll want to hack at least the latter. Note: Xt compiled programs will look for app-defaults in /local/share/X11/app-defaults. Either edit libXt.a to fix this, or recompile Xt with a new LIBDIR or mkdir /local/share/X11/app-defaults on your machine. ximake will look for the config information in ${xtop}/util/imake.includes. We set xtop to /local/src/X. Change it to `pwd` so that it can find ./util/imake.includes. Then use 'ximake' to generate Makefiles the first time. We were able to compile most of the MIT X11R3 distribution with this. (Possibly after some changes -- I don't feel like scanning all the RCS logs looking for them. general hint: nuke any 'extern char *sprintf()' declarations and use bin/cc.bsd) Enjoy.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11019; 3 Dec 89 1:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10836; 3 Dec 89 0:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10825; 3 Dec 89 0:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20808; 3 Dec 89 0:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27886; Sat, 2 Dec 89 21:12:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Dec 89 03:29:25 GMT From: Gunter Ahrendt Organization: University of Western Australia Subject: Optical Disks Message-Id: <1414.25790396@vaxa.uwa.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone had any experience with the Maxtor Tahiti 1 CD Erasable Disk Drive 1GB, 5.25", SCSI, 35msec Seek, 16.7msec Latency, 4MB/sec Transfer   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16048; 3 Dec 89 23:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15874; 3 Dec 89 22:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15872; 3 Dec 89 22:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00593; 3 Dec 89 22:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04511; Sun, 3 Dec 89 19:35: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: 2 Dec 89 20:32:24 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: Telnetd problem in 3.2? Message-Id: <619@voodoo.UUCP> References: <8912010051.AA27187@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912010051.AA27187@sgi.sgi.com> arc@SGI.SGI.COM (Andrew Cherenson) writes: > >It's fixed in the 3.2.1 maintenance release. The 3.1F or 3.1G telnetd should >suffice until then. > Tell me more about 3.2.1. There are two bugs that we've encountered in 3.2 that we're trying to deal with now: 1. The dial & button box does not work properly under 3.2, rendering our application next to useless for production (it doesn't impact us too much for developmenmt). The hotline says this problem is fixed for 3.3, but they haven't gotten back to us yet on what to do to fix the problem for 3.2. Is the fix in 3.2.1? 2. The same source code compiles and runs fine on 3.1, but repeatedly dumps core on 3.2 (when we do a certain sequence of events). This problem was just discovered yesterday, and I'm in the process of isolating the exact cause. Some memory is getting overwritten, but we're not sure where. When I left work last night, malloc was the current *suspect*. Any clues? I know this is vague, but these kind of problems are a real bear to track down, and any pointers would be appreciated. -- Mike York | "But first, I have to satisfy Boeing Computer Services | my sense of moral outrage" (206) 234-7724 | uw-beaver!ssc-vax!voodoo!zombie | -Roger Rabbit   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17095; 4 Dec 89 2:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16432; 4 Dec 89 1:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16418; 4 Dec 89 1:07 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa01435; 4 Dec 89 0:56 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1155; Mon, 04 Dec 89 00:57:03 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 04 Dec 89 06:45:27 Date: Mon, 4 Dec 89 06:45:14 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Compiler bugs? To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8912040056.aa01435@SMOKE.BRL.MIL> Hallo, I discovered the following two bugs in the C and f77 compiler of 3.2. I know I should report them directly to Calvin Vu, but I've lost his e-mail address. First I have the following Fortran Code: program test write(*,4177) numatm = -1 4711 format('Next comes the bug',i4) 1 numatm end The program compiles fine, but tell me where does is put the continuation line? To the format statement? That's nonsense? To the write statement? That would be the meaning, but to late and it doesn't. I found that one when I tested the IBM-VS-Fortran product for their AIX/370 system on the 25000 line MOPAC package. That compiler REALLY test the syntax of programs. It has only one small flaw. The executable isn't.... Btw. f77 on a 3100 tells me there's a syntax error following the format statement. Second, a colleague asked me to test the following c code on our 4D/70-GT. #include main() { int i=0; if (i) f(); else/*comment*/f1(); } f() {return;} f1() {return;} The code compiles fine (that's ok), but ld complains about not finding _elsef1. That means it just removes the comment without replacing it by a white space character as stated by K&R. Thats either a violation of K&Rs' definiton of comments, or a violation of the rule that comments may appear at places where white space characters are allowed whitout changing the semantics of the program. The same can be seen on a 3100 running 3.6. Enjoy Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17749; 4 Dec 89 5:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17501; 4 Dec 89 4:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17484; 4 Dec 89 3:53 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa02124; 4 Dec 89 3:47 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2363; Mon, 04 Dec 89 03:47:49 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 04 Dec 89 09:48:49 Date: Mon, 4 Dec 89 09:48:29 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Fortran bug? To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8912040347.aa02124@SMOKE.BRL.MIL> Hallo, the fortran example in my previous message is wrong. It has to be: program test numatm=-1 write(*,4177) 4711 format('No comes the bug',i4) 1 numatm end Sorry for wasting the network. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET: PS: This is for Phil: K&R state that blank, tab, nl and comments are treated collectively as "white space" character. (K&R 1978, p.179)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18368; 4 Dec 89 7:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac18121; 4 Dec 89 7:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18099; 4 Dec 89 6:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02866; 4 Dec 89 6:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27090; Mon, 4 Dec 89 03:21:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 08:02:27 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: update: RECTRE problems Message-Id: <3022@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A few days back, I posted an article about RECTRE not appearing to be functioning right. Well, here's an update. Consider this piece of code: CALL READSO(1) TEST=RECTRE(1,1,640,484,SGIS) CALL COLOR(0) CALL CLEAR CALL MAPCOL(3,255,0,255) CALL RECTWR(1,1,640,484,SGIS) DO 10 II=1,309760 IF(SGIS(II).EQ.3)THEN WRITE(6,*)II,SGIS(II) ENDIF 10 CONTINUE Here's the expanation: The window is only 640x484 in size. The window is cleared black and a few lines of large yellow(3) text are written across the window. I put the READSO there just to be safe and supress any possibilities from this. Next, it loads the array SGIS, then I cleared the screen (just to be sure), then redefine color 3 to see if it will show a change in color when I redraw the image. Then call RECTWR to redraw the same image. That works just fine, with the text appearing as magenta, so its in the array somehow. * This shows that RECTRE in functioning correctly. Now comes the strange part. I try to scan through the array and write all color 3 entries to the screen. I know there are quite a few because the text changed color when I redefined it. But nothing gets written to the screen which means (??) that there were no 3 entries in the comparison. This doesn't make any sense. The array SGIS is declared as INTEGER*2, but are the elements of that array written in some goofy fashion like hex or something? When I tried to write out the entire array, it was mostly large negative numbers (like -24000 something) but I know SGIS is correct else RECTWR wouldn't have given the correct results. What !exactly! is the format of the result of RECTRE (details!)??? Any clues?? Tom Rohling CFD dude Aerospace Eng. University of Cincinnati trohling@uceng.uc.edu ========================================================================== If your standing on the North Pole, what time is it? ==========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25422; 4 Dec 89 13:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25251; 4 Dec 89 13:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25157; 4 Dec 89 13:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12277; 4 Dec 89 12:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18890; Mon, 4 Dec 89 09:39:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 17:02:19 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: update: RECTRE problems Message-Id: <45668@sgi.sgi.com> References: <3022@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3022@uceng.UC.EDU>, trohling@uceng.UC.EDU (tom rohling) writes: > > A few days back, I posted an article about RECTRE not appearing to be > functioning right. Well, here's an update. > . . . > > What !exactly! is the format of the result of RECTRE (details!)??? > If you say "man rectread" on 3.2, you get the following NOTES section in the man page NOTES These routines are available only in immediate mode. On IRIS-4D GT and GTX models, the upper 4 bits of the 16-bit values returned by rectread are undefined, and its performance will suffer if x2 - x1 + 1 is odd. If you are running on a GT or GTX model (you didn't say, but from your problem it sounds like you are), then I think your problem is that the upper 4 bits of the 16 bit values are indeed undefined, and are probably not 0! This would make your comparison to "3" fail even though the pixel is indeed color 3. Hope this helps. -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25588; 4 Dec 89 13:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24835; 4 Dec 89 12:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24767; 4 Dec 89 12:23 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa11238; 4 Dec 89 12:14 EST Received: Mon, 4 Dec 89 09:11:23 -0800 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Mon, 4 Dec 89 12:15:19 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 4 Dec 89 12:58:58 EST by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 4 Dec 89 12:58:58 EST From: Tony Facca Message-Id: <8912041758.AA15256@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Fortran bug? Knobi der Rechnerschrat writes: > I discovered the following two bugs in the C and f77 compiler of 3.2. I know >I should report them directly to Calvin Vu, but I've lost his e-mail address. > > First I have the following Fortran Code: > > program test > numatm = -1 > write(*,4711) >4711 format('Next comes the bug',i4) > 1 numatm > end [ I did some editing, but the idea has been preserved ] > > The program compiles fine, but tell me where does is put the continuation >line? To the format statement? That's nonsense? To the write statement? That >would be the meaning, but to late and it doesn't. > The continuation line is just that: a continuation of the FORMAT statement. So, the 4th line of the program is: 4711 format ('Next comes the bug', i4) numatm That much is obvious, right? So, why doesn't the compiler complain? According to the ANSI X3.9-1978 (FORTRAN 77), Section 13.1.2 says: "Character data may follow the right parenthesis that ends the format specification, with no effect on the format specification." Looks like this piece of code conforms to the standard quite nicely. The point about it being nonsense is still debatable. But at least its FORTRAN 77 STANDARD nonsense! :-) Tony Facca & Dan Whipple -- ----------------------------------------------------------------------------- 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 aa26662; 4 Dec 89 14:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26378; 4 Dec 89 14:43 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa26372; 4 Dec 89 14:34 EST Date: Mon, 4 Dec 89 14:33:54 EST From: Phil Dykstra To: Knobi der Rechnerschrat cc: info-iris@BRL.MIL Subject: Re: Fortran bug? Message-ID: <8912041433.aa29614@SPARK.BRL.MIL> > K&R state that blank, tab, nl and comments are treated > collectively as "white space" character. (K&R 1978, p.179) Sure enough, I just looked and both the original and 2nd edition state this. However, the early Unix C compilers (and even most current ones) would replace comments by nothing at all rather than by a space [to be precise, the C preprocessor would do this]. This behavior was/is often exploited for token concatenation. ANSI adopted the original spec that comment = whitespace and thus provided the new '##' operator for concatenation. Note that one of the actions of the GNU C compiler "-traditional" flag is to: * In the preprocessor, comments convert to nothing at all, rather than to a space. This allows traditional token concatenation. So, SGI is just following the convention that most UNIX C compilers do. Strict ANSI compilers however will not do this. - Phil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27082; 4 Dec 89 15:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26030; 4 Dec 89 14:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25718; 4 Dec 89 14:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14670; 4 Dec 89 13:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA23544; Mon, 4 Dec 89 10:46:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 17:32:51 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Compiler bugs? Message-Id: <45673@sgi.sgi.com> References: <8912040056.aa01435@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912040056.aa01435@SMOKE.BRL.MIL> XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: >Hallo, > > I discovered the following two bugs in the C and f77 compiler of 3.2. I know >I should report them directly to Calvin Vu, but I've lost his e-mail address. [stuff deleted about f77] > Second, a colleague asked me to test the following c code on our 4D/70-GT. [stuff deleted] >else/*comment*/f1(); [stuff deleted] >The code compiles fine (that's ok), but ld complains about not finding >_elsef1. That means it just removes the comment without replacing it by a >white space character as stated by K&R. Thats either a violation of K&Rs' >definiton of comments, or a violation of the rule that comments may We use the traditional AT&T Reiser cpp. That cpp has, as has been mentioned many times (in other newgroups, not this one), that /* */ behavior. Since many programs depend on the erroneous behavior cpp cannot be changed. In the release after 3.2, we allow optional use of an ANSI cpp (with the -acpp flag). acpp does not exibit the behavior mentioned by Mr. Rechnerschrat. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28465; 4 Dec 89 16:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28036; 4 Dec 89 16:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27861; 4 Dec 89 16:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18600; 4 Dec 89 15:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29781; Mon, 4 Dec 89 12:26:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 20:21:51 GMT From: Mark Bradakis Organization: Univ. of Utah Computer Science Subject: Personal Iris SCSI Message-Id: <1989Dec4.132152.27617@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hope I am not trying to give mouth to mouth to a long dead horse here, but I have what I think are simple qusetions about the SCSI port on the Personal Iris. Am I correct in thinking that it is a single ended (vs. differential) async port, with sync capability in 3.2 software? Assuming the scsi_setsynch or whatever value is correct. I tried plugging a SCSI disk onto the machine, and got many many SCSI hardware errors while booting. Thanks for any info. mjb. mjb@hoosier.utah.edu "If I took a rollin' wheel, rolled it ten times 'round..."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29437; 4 Dec 89 19:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29353; 4 Dec 89 19:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29344; 4 Dec 89 18:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20989; 4 Dec 89 18:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA07647; Mon, 4 Dec 89 14:30: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: 4 Dec 89 22:26:19 GMT From: Michael Schuh- RAA Organization: NASA Ames Research Center, Mtn Vw CA 94035 Subject: 4MB simms on IRIS 4D/25 Message-Id: <37342@ames.arc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone tried 4MB simms on an IRIS 4D/25 or and IRIS 4D/70? If so: o How did they work? o What speed were they (80 or 100 nsec)? o Where did you purchase them? o How much did they cost? Thanks, Michael Schuh schuh@pioneer.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29437; 4 Dec 89 19:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29353; 4 Dec 89 19:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab29344; 4 Dec 89 18:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21020; 4 Dec 89 18:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08230; Mon, 4 Dec 89 14:39:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 22:22:05 GMT From: Eric Pepke Organization: Supercomputer Computations Research Institute Subject: 3130 Genlock <-> Lenco Message-Id: <390@fsu.scri.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anybody successfully connected an old 3130 genlock board to a Lenco sync generator/NTSC encoder? The Lenco generator has six outputs: BF, SY, HD, VD, BL, and SC. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29437; 4 Dec 89 19:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29353; 4 Dec 89 19:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac29344; 4 Dec 89 18:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21022; 4 Dec 89 18:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05106; Mon, 4 Dec 89 13:50:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 13:46:58 GMT From: Chetty Ramanathan Organization: Software Tool & Die Subject: Memory expansion on Personal Iris Message-Id: <1989Dec4.134658.4612@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a Personal Iris 4D25 with 8Mb of memory and we want to expand it to something like 12 or 16 Mb. Does anyone know of any vendor other than SGI who sells memory for the Personal Iris. -chetty ------------------------------------------------------------------------------- C.Ramanathan | Software Tool & Die, Purveyors to the Trade |chetty@world.std.com 1330 Beacon St, Brookline, MA 02146,(617)739-0202 |{xylogics,uunet}world!chetty -- -chetty ------------------------------------------------------------------------------- C.Ramanathan | Software Tool & Die, Purveyors to the Trade |chetty@world.std.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad29437; 4 Dec 89 19:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad29353; 4 Dec 89 19:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29349; 4 Dec 89 18:51 EST Received: from cypress.sgi.cs.net by SMOKE.BRL.MIL id aa21042; 4 Dec 89 18:40 EST Received: from palladium.sgi.com by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA20471; Mon, 4 Dec 89 14:56:00 PST Received: from thor.corp.sgi.com by palladium.corp.sgi.com (5.52/890711.SGI) (for adams@sgi.sgi.com) id AA02776; Mon, 4 Dec 89 14:56:06 PST Received: by thor.corp.sgi.com (5.52/890711.SGI) (for @palladium.corp.sgi.com:info-iris@BRL.MIL) id AA06387; Mon, 4 Dec 89 14:56:03 PST Date: Mon, 4 Dec 89 14:56:03 PST From: Chuck Adams Message-Id: <8912042256.AA06387@thor.corp.sgi.com> To: info-iris@BRL.MIL Subject: TeX for 4D series Cc: adams@thor.corp.sgi.com I am looking for TeX for the 4D series. Anyone with info on past, current, or future versions please send me information on your experiences, etc. A summary will be provided for the net, if enough information comes across. Thanks for you support. -- Chuck Adams, Silicon Graphics, 15280 Addison Rd., #130, Dallas, TX voice (214) 788-4122, fax (214) 788-0957, e-mail adams@sgi.com - Hey, if it was easy, everybody would be doing it! -   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01074; 5 Dec 89 0:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00858; 4 Dec 89 23:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00821; 4 Dec 89 23:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23038; 4 Dec 89 23:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27851; Mon, 4 Dec 89 19:56:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 17:32:17 GMT From: "C. Harald Koch" Organization: Alias Research, Inc., Toronto, Canada Subject: Re: why separate getpwent routines for YP? Message-Id: <664@alias.UUCP> References: <8911301944.AA11476@kailand.kai.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911301944.AA11476@kailand.kai.com> pwolfe@kailand.kai.com (Patrick Wolfe) writes: >I installed YP (Yellow Pages) on our network this week, and RCS V4.2 commands >started crashing with segmentation faults. I found (from the getpwent(3) >online manpage) that SGI ships two versions of the "getpw*" calls, one that >understands YP and one that doesn't? Once I learned this, it was trivial to >fix the Makefile and recompile, but I can't help wonder why anyone would want >to ship (and maintain) two separate versions? This brings up a question I have been meaning to ask: Does SGI compile their standard UNIX programs with YP support? login works, but it appears that csh was not compiled with YP; ~user complains "no such user" when that user's password file entry is a YP reference. -- C. Harald Koch Alias Research, Inc., Toronto ON Canada chk%alias@csri.utoronto.ca chk@gpu.utcs.toronto.edu chk@chk.mef.org "There is no problem, no matter how large or how small, that cannot be solved by a suitable application of high explosives." -Leo Graf, 2298   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01697; 5 Dec 89 1:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01517; 5 Dec 89 1:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01480; 5 Dec 89 1:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23997; 5 Dec 89 1:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04966; Mon, 4 Dec 89 21:53:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 19:55:49 GMT From: Scott_Klosterman Organization: SDRC, Cincinnati Subject: Changes to /etc/wtmp in 3.2 ?? Message-Id: <975@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have an accounting routine which scans /etc/wtmp to get login information. Since upgrading to 3.2 it has produced bills nearly 100X greater. Has there been changes to /etc/wtmp in 3.2? If I do: who /etc/wtmp there is more information than before 3.2. If some-one could send the format for the wtmp file this would prob. be enough as I don't have 3.2 manuals yet. uunet!sdrc!crscott Scott Klosterman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09265; 5 Dec 89 14:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08628; 5 Dec 89 13:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08519; 5 Dec 89 12:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06010; 5 Dec 89 12:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13746; Tue, 5 Dec 89 09:21:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 89 14:53:16 GMT From: Phil Dench Organization: Curtin University of Technology, Maths & Comp Sc Subject: News-servers that grow but never shrink. Message-Id: <124@cutmcvax.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a problem. When I 'psh' the following bit of code, the news-server grows to about 17Mb. It is probably mallocing appropriate workspace to generate the image and then most likely frees that space. Unfortunatly, the free() will not do a negative sbrk(), so we are left with a news-server taking up 17Mb of swap space. This sort of behavior is acceptable for your average sort of process. It is run, then dies and the swap space is released. But the news-server is always there (when you are), and noticabley slows down after displaying a large image. It would be nice if the news-postcript 'save' did something like... old_data_seg = sbrk( 0); and the 'restore' did something like... brk( old_data_seg); and then I could use 'save' instead of 'gsave', 'restore' instead of 'grestore'. And it looks sort of logical too. A 'restore' that really did restore the news-server to its previos state. But is there a quick fix (other than logging out and in again)? ----8<--------8<--------8<--------8<--------8<--------8<--------8<---- %! gsave /imline 8 string def /drawimage { 4 4 8 [4 0 0 -4 0 4] { currentfile imline readhexstring pop } image } def 960 768 scale drawimage 070C111423322233193A445AD998CEFF % just rubbish - nothing significant grestore ----8<--------8<--------8<--------8<--------8<--------8<--------8<---- NOTES: We are previewing postscript files using a modified 'psview' before sending them to a postscript printer. Some files include full page images. We are running 3.1D on a 4D-70GT. Phil Dench --------------------------------------------+---------------------------------- | School of Computer Science, ACSNet: architec@cutmcvax.oz | Curtin University of Technology, UUCP: ...!uunet!munnari!cutmcvax!architec | Kent Street, ARPA: architec%cutmcvax.oz@uunet.UU.NET | Bentley | Western Australia, 6102 --------------------------------------------+----------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18917; 6 Dec 89 8:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17855; 6 Dec 89 7:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab17839; 6 Dec 89 7:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19740; 6 Dec 89 7:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18578; Wed, 6 Dec 89 03:54: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: 5 Dec 89 03:32:44 GMT From: Dave Olson Subject: Re: Personal Iris SCSI Message-Id: <1791@odin.SGI.COM> References: <1989Dec4.132152.27617@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: >Hope I am not trying to give mouth to mouth to a long dead horse here, >but I have what I think are simple qusetions about the SCSI port on >the Personal Iris. Am I correct in thinking that it is a single ended >(vs. differential) async port, with sync capability in 3.2 software? >Assuming the scsi_setsynch or whatever value is correct. All SGI machines currently are single-ended SCSI. Differential might be supported some day, but there are relatively few devices today that require (or support) it. Synchronous SCSI support is in all 3.2 systems, but enabled by default only on the 4D20 and 4D25. This was due to some of our older systems SCSI cabling not being quite correct. There was concern that enabling sync mode on these systems would lead to many SCSI errors. >I tried plugging a SCSI disk onto the machine, and got many many SCSI >hardware errors while booting. Thanks for any info. >mjb. Sounds like you either had extra termination, or conflicting ID's. Internal SCSI drives are normally ID 1, the host adapter is 0, and tape drives are ID 2 (on 4D20, 25), or ID 7 on other machines. Terminators shouldn't be used on the 4D20,25 unless connected to the external SCSI port; on the other 4D machines, only the top SCSI device in the drive tower should have termination. 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 aa00980; 6 Dec 89 18:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00912; 6 Dec 89 18:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00859; 6 Dec 89 18:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10397; 6 Dec 89 18:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA28608; Wed, 6 Dec 89 14:53: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: 4 Dec 89 13:38:00 GMT From: "David M. McQueen" Organization: New York University Subject: Re: problems with RECTRE and other little things Message-Id: <17280029@acf4.NYU.EDU> References: <2994@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL With regard to your problem when running several graphics programs in sequence: by default, the program runs as a background job after graphics initialization. To prevent this from happening, place a call to foregr (in FORTRAN, or foreground, in C) before calling winopen. This will keep each job in the foreground until completion, when the next job will start up. Dave McQueen Courant Institute of Mathematical Sciences, New York University mcqueen@acf4.nyu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02240; 5 Dec 89 4:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02089; 5 Dec 89 3:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02081; 5 Dec 89 3:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24669; 5 Dec 89 3:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14283; Tue, 5 Dec 89 00:16:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Dec 89 07:38:33 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: why separate getpwent routines for YP? Message-Id: <45749@sgi.sgi.com> References: <8911301944.AA11476@kailand.kai.com>, <664@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <664@alias.UUCP>, chk@alias.UUCP (C. Harald Koch) writes: > This brings up a question I have been meaning to ask: Does SGI compile their > standard UNIX programs with YP support? login works, but it appears that csh > was not compiled with YP;... > > C. Harald Koch Alias Research, Inc., Toronto ON Canada > chk%alias@csri.utoronto.ca chk@gpu.utcs.toronto.edu chk@chk.mef.org Almost everything is linked with YP. Csh has been from the beginning, since the 4D csh started life as the 3000/2000 csh, which had YP in 3.5/2.5. (Yes, csh did get re-ported from the 4.3 tape, but that was latter.) Most of the 1000's of machines on the SGI network use csh, and we use lots of YP. You can check to see if YP is present with `strings /bin/csh | grep -i yp`. It would be good to communicate the details of your problem to the Hotline so that the bug (if any) can be fixed or the local installation difficulty (if any) fixed. The only significant exception I can think of is NeWS, which is not linked with YP. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02497; 5 Dec 89 5:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02319; 5 Dec 89 4:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02301; 5 Dec 89 4:28 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25119; 5 Dec 89 4:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16764; Tue, 5 Dec 89 01:06:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Dec 89 08:56:49 GMT From: Ramani Pichumani Organization: Stanford University Computer Science Department Subject: new ui toolkits with 3.2? Message-Id: <1989Dec5.085649.22173@Neon.Stanford.EDU> References: <8911301944.AA11476@kailand.kai.com>, <664@alias.UUCP>, <45749@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL After exploring the Workspace Manager on 3.2, I noticed that there appeared to be an impressive new user interface toolkit. My question to SGI is the following: What is the preferred, supported and documented user interface toolkit for writing applications for the 4D machines in C? The only reasonable UI toolkit I've found so far is the NeWS LiteUI package from Sun which is neither supported nor bug-free and professional enough for real applications. 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 aa04706; 5 Dec 89 8:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04008; 5 Dec 89 8:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03932; 5 Dec 89 8:06 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa27137; 5 Dec 89 7:56 EST Received: Tue, 5 Dec 89 07:58:07 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 5 Dec 89 07:58:07 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8912051558.AA18027@aero4.larc.nasa.gov> To: spdcc!xylogics!world!chetty@husc6.harvard.edu Subject: Re: Memory expansion on Personal Iris Cc: info-iris@BRL.MIL Here is a list I have compiled from info-iris mail. I don't know how good or bad any of them are we haven't ordered anything yet. Sophistecated Circuits, Seattle (206) 547-4779 Memory for 4D 20's, $310/Mb (in late April '89) Impediment, Inc., 333 Duxbury, MA 02332, (617) 837-8877 Memory for 4D 20's, $120/Mb (early October '89) Memory for 4D 200's $225/Mb (early November '89) (Have heard good things about this company, including Lifetime replacement guarantee, not 90 days like some companies) These were all I could find in my old mail. Hope this helps. If anyone has any more names to add to the list please let me know. -- 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 ac10848; 5 Dec 89 15:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10523; 5 Dec 89 15:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10402; 5 Dec 89 15:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09711; 5 Dec 89 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22858; Tue, 5 Dec 89 11:46:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Dec 89 19:03:08 GMT From: psuvm!sml108@psuvax1.cs.psu.edu Organization: Penn State University Subject: Where is 3.2 ? Message-Id: <89339.140310SML108@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, after seeing all the discussions going on about 3.2, I have a question. We have not received our upgrade yet to 3.2, and are wondering if anyone else has not received theirs.... Scott Le Grand aka SML108@PSUVM.PSU.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad10848; 5 Dec 89 15:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10523; 5 Dec 89 15:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab10402; 5 Dec 89 15:03 EST Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa09743; 5 Dec 89 14:51 EST Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA01911; Tue, 5 Dec 89 11:25:34 -0600 Received: from horizon.kai.com (horizon) by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA16549; Tue, 5 Dec 89 10:41:18 cst Received: by horizon.kai.com (4.12/kai2.5c/09-20-88) id AA20123; Tue, 5 Dec 89 10:41:16 cst Message-Id: <8912051641.AA20123@horizon.kai.com> Organization: KAI, 1906 Fox Drive, Champaign, IL 61820, (217)356-2288 From: Chris Huson Date: Tue, 5 Dec 89 10:41:12 CST X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: info-iris@BRL.MIL Subject: RE: Fortran Bug? Tony Facca writes: >Knobi der Rechnerschrat writes: > > >> I discovered the following two bugs in the C and f77 compiler of 3.2. I know >>I should report them directly to Calvin Vu, but I've lost his e-mail address. >> >> First I have the following Fortran Code: >> >> program test >> numatm = -1 >> write(*,4711) >>4711 format('Next comes the bug',i4) >> 1 numatm >> end > > [ I did some editing, but the idea has been preserved ] > >> >> The program compiles fine, but tell me where does is put the continuation >>line? To the format statement? That's nonsense? To the write statement? That >>would be the meaning, but to late and it doesn't. >> > >The continuation line is just that: a continuation of the FORMAT statement. >So, the 4th line of the program is: > > 4711 format ('Next comes the bug', i4) numatm > >That much is obvious, right? > >So, why doesn't the compiler complain? According to the ANSI X3.9-1978 >(FORTRAN 77), Section 13.1.2 says: > > "Character data may follow the right parenthesis that ends the format > specification, with no effect on the format specification." > >Looks like this piece of code conforms to the standard quite nicely. The point >about it being nonsense is still debatable. But at least its FORTRAN 77 >STANDARD nonsense! :-) The section mentioned (13.1.2) is referring to character format specifications, not format specifications in general. These are of the form ... CHARACTER * 30 carray ... carray = '(''This is the bug'',i4)' ... write(*,carray)numatm ... or the equivalent constant appearing in the same context. Though I wasn't in on the writing of the F77 standard, I believe this statement (lines 40-42 on page 13-1) just means you don't have to set the trailing end of the character array to blanks to have a legal format statement. So carray = '(3(i4))xxxyyyzzz' would be legal as a format specifier. The actual form of a format specifier is given in section 13.2. As to the original question (what statements take continuations?), the standard describes continuation lines (3.2.3), initial lines (3.2.2) and comments (3.2.1), states that comment lines may appear between an initial line and a continuation, or between two continuations, and then describes statements (3.3). Since a FORMAT is considered a statement, it follows the same rules of continuation as the WRITE statement before it (in the example given), and so gets the continuation. -- Internet : chris@kai.com UUCP : {uunet,uiucuxc}!kailand!chris -- Internet : chris@kai.com UUCP : {uunet,uiucuxc}!kailand!chris   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11169; 5 Dec 89 15:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac10523; 5 Dec 89 15:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10509; 5 Dec 89 15:06 EST Received: from uxe.cso.uiuc.edu by SMOKE.BRL.MIL id aa10027; 5 Dec 89 14:56 EST Received: by uxe.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA11401; Tue, 5 Dec 89 12:28:18 -0600 Date: Tue, 5 Dec 89 12:28:18 -0600 From: Amy Swanson Message-Id: <8912051828.AA11401@uxe.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: /usr/etc/nfsstat interpretation Cc: amys@ncsa.uiuc.edu I have a 4D/240 server that is being used as a NFS and Yellow Pages server for a lab of 20 Personal Irises. Lately, we've been experiencing a lot of problems with NFS "getattr" failures. I looked at the output of the /usr/etc/nfsstat but am not sure what I am looking for or how to determine if it is the server or a client having a problem, and if it is a client, how do I find out which of the 20 PIs is having the problem. Could someone help me interpret the following nfsstat output? Thanks! Amy rels_55% /usr/etc/nfsstat -cs Server rpc: calls badcalls nullrecv badlen xdrcall 5292246 0 0 0 0 Server nfs: calls badcalls 5292246 0 null getattr setattr root lookup readlink read 0 0% 1674964 31% 49493 0% 0 0% 1009263 19% 913 0% 1210477 22% wrcache write create remove rename link symlink 0 0% 1054781 19% 16559 0% 14286 0% 3994 0% 1405 0% 2 0% mkdir rmdir readdir fsstat 307 0% 92 0% 253719 4% 1991 0% Client rpc: calls badcalls retrans badxid timeout wait newcred 316821 322 105 9 266 0 0 Client nfs: calls badcalls nclget nclsleep 316821 322 316821 0 null getattr setattr root lookup readlink read 0 0% 30735 9% 1 0% 0 0% 32406 10% 12432 3% 180105 56% wrcache write create remove rename link symlink 0 0% 45778 14% 129 0% 129 0% 0 0% 0 0% 0 0% mkdir rmdir readdir fsstat 0 0% 0 0% 14949 4% 157 0% =============== Amy Swanson SGI/Alliant Systems Administrator NCSA - National Center for Supercomputing Applications University of Illinois @ Urbana-Champaign amys@ncsa.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14194; 5 Dec 89 17:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13854; 5 Dec 89 17:12 EST Received: from sem.brl.mil by VMB.BRL.MIL id aa13830; 5 Dec 89 17:00 EST Date: Tue, 5 Dec 89 16:46:44 EST From: Mike Muuss To: Knobi der Rechnerschrat cc: info-iris@BRL.MIL Subject: Re: Compiler bugs? Message-ID: <8912051646.aa00988@SEM.BRL.MIL> Knobi - Early (pre-ANSI) C compilers and macro pre-processors all act in the way that you report. This behavior is often depended upon to provide "token pasting" in pre-ANSI compilers. Please do not attempt to "fix" it. Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14575; 5 Dec 89 18:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14400; 5 Dec 89 18:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14385; 5 Dec 89 17:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13486; 5 Dec 89 17:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04850; Tue, 5 Dec 89 14:47:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Dec 89 21:49:19 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: Answer to RECTRE problem Message-Id: <3051@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thank's for responses on the RECTRE problem. That has been resolved. For those that may have encountered the problem now or in the future, here's the scoop (at least as I understand it): As posted by Gary Tarolli, > On IRIS-4D GT and GTX models, the upper 4 bits of the 16-bit values > returned by rectread are undefined, and its performance will suffer if > x2 - x1 + 1 is odd. This (unfortunately) was not in the manuals that we have, so I had never envisioned such an thing. To 'correct' this so that you can read what the numbers actually are, you need to clear all the bit planes with zeros to set the extra 4 bits to zero, which can be done by calling RGBCOL(0,0,0) (or rgbcolor(0,0,0)), (thank's Tom) then switch back to colormap mode and proceed as planned. -Tom P.S. What ever happened to the question about the existance of a Tex previewer for the 4D's? Anything?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14971; 5 Dec 89 21:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14907; 5 Dec 89 21:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14904; 5 Dec 89 20:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14910; 5 Dec 89 20:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16066; Tue, 5 Dec 89 17:40: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: 6 Dec 89 01:39:32 GMT From: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!sherman@tut.cis.ohio-state.edu Subject: Re: problems with RECTRE and other litt Message-Id: <39500004@m.cs.uiuc.edu> References: <2994@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Reguarding the prompt returning as soon as the graphics are initialized, try putting the Fortran equivalent of the "foreground()" call before the grinit or whatever is called. This should cause the whole program to run in the foreground, rather than the background which is what it is doing now. /************************************************************************/ /* Bill Sherman */ /* National Center for Supercomputing Applications */ /* University of Illinois */ /* Champaign-Urbana */ /* */ /* Internet: wsherman@ncsa.uiuc.edu */ /* */ /* "You want to do mankind a real service? Tell funnier jokes." */ /* Og */ /************************************************************************/   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15978; 6 Dec 89 0:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15502; 5 Dec 89 23:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15479; 5 Dec 89 23:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15898; 5 Dec 89 23:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA24624; Tue, 5 Dec 89 19:56:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 89 03:02:31 GMT From: Andrew Simms Organization: Princeton University Subject: Re: 4MB simms on IRIS 4D/25 Message-Id: <11972@phoenix.Princeton.EDU> References: <37342@ames.arc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have tested 4Mbit simms on a 4D/25 without problems. I took it all the way to 64Megabytes. However, you need to be at a certain rom revision in order for the 4mbit simms to be recognized. I believe the revision is 3.2 rev E (I would really appreciate someone at SGI confirming this). Please note the following: You cannot mix 1 megabyte simms and 4megabyte simms together. It is all or nothing. You must also add in increments of 4 simms (16 Megabytes). My vendor is Impediment, 617/837-8877. I don't have a price since I got these simms on loan for evaluation. ---------------------------------------------------------------------- Andrew Simms ams@acm.princeton.edu System Administrator Program in Applied and Computational Math Princeton University Princeton, NJ 08544 609/258-5324 or 609/258-6227 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18917; 6 Dec 89 8:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17855; 6 Dec 89 7:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17839; 6 Dec 89 7:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19711; 6 Dec 89 7:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18806; Wed, 6 Dec 89 03:58: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: 5 Dec 89 18:25:22 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: new ui toolkits with 3.2? Message-Id: <1807@odin.SGI.COM> References: <8911301944.AA11476@kailand.kai.com>, <664@alias.UUCP>, <45749@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The toolkit which was used to construct the workspace and related programs was deemed by the SGI engineering staff to be unfit for customer use. We *will* be providing a high quality user interface kit sometime during 1990... kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12104; 7 Dec 89 14:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10423; 7 Dec 89 13:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10407; 7 Dec 89 13:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25851; 7 Dec 89 12:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05190; Thu, 7 Dec 89 09:37: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: 5 Dec 89 16:49:07 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: Telnetd problem in 3.2? Message-Id: <623@voodoo.UUCP> References: <8912010051.AA27187@sgi.sgi.com>, <619@voodoo.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <619@voodoo.UUCP> zombie@voodoo.UUCP (Mike York (that's me)) writes: > >Tell me more about 3.2.1. There are two bugs that we've encountered in >3.2 that we're trying to deal with now: I go on to tell about the dial & button not working, and a suscpected problem with malloc. Well, the dial & button box still doesn't work, but malloc is no longer suspect. I have found the bug and it is us. We were inadvertently referencing an object that had been freed. This never bit us in previous releases, but our past sins have come back to haunt us in 3.2. Now, if that D&B box would just work we'd be all set... -- Mike York | "But first, I have to satisfy Boeing Computer Services | my sense of moral outrage" (206) 234-7724 | uw-beaver!ssc-vax!voodoo!zombie | -Roger Rabbit   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16775; 6 Dec 89 3:13 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16526; 6 Dec 89 2:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16503; 6 Dec 89 2:19 EST Received: from text.inria.fr by SMOKE.BRL.MIL id aa17590; 6 Dec 89 2:13 EST Received: by inria.fr with X.400; 06 Dec 89 08:15:16+0100 Received: by ch; 06 Dec 89 08:13:17+0100 Date: 06 Dec 89 08:13:17+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: 3.2.1.x.y.z. ? Message-ID: <136*doelz@urz.unibas.ch> Our version of 3.2. does some strange things, and our sales rep told us that we will receive 3.2.1 soon. Could someone tell me how many releases are distributed with the same version number and how many different upgrades will confuse the community this time before we get a runnable version :-( - Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05140; 6 Dec 89 16:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02246; 6 Dec 89 14:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02228; 6 Dec 89 14:26 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa04102; 6 Dec 89 14:03 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 0994; Wed, 06 Dec 89 13:03:24 CST Received: by UMRVMA (Mailer R2.05) id 0993; Wed, 06 Dec 89 13:03:11 CST Date: Wed, 06 Dec 89 13:00:38 CST From: Bob Funchess Subject: Gnu CC compiler To: info-iris@BRL.MIL Message-ID: <8912061404.aa04102@SMOKE.BRL.MIL> Has anyone ported gcc to IRIX? If so, where can I get it? I have a LARGE program written for gcc, and it would be easier NOT to adjust it for SG cc if that is avoidable... < Bob S090726@UMRVMA.UMR.EDU Funchess > The 'S' stands for student. Think the university shares MY opinions?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00650; 6 Dec 89 17:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00523; 6 Dec 89 17:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00476; 6 Dec 89 17:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09043; 6 Dec 89 16:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22744; Wed, 6 Dec 89 13:28:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 89 20:57:24 GMT From: "James P. Loan" Organization: V.A. Hospital, Stanford University Subject: Questions about Personal IRIS Message-Id: <12939@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a few questions about the Personal IRIS, and I'd appreciate any help. I'd ask our sales rep, but it takes us a week to reach each other. We currently have a 2400T and we are about to order a 4D/25 (prod# W-4D20G-38). We have also ordered the software development package (S5-DV01) and the X-window package (S4-X113D). The two machines will be connected by a 10Mbit Ethernet line. My questions: (1) I assume that the Personal IRIS comes standard with a 19" monitor (it doesn't say so on our quote), so we'll have the old 19" (1024x768) monitor from the 2400T as well as the new one (1280x1024). What we'd like to do is be able to run graphics programs on one (or the other) cpu and display them on either of the monitors. The scenario is that someone sits down at one of the monitors and is able to runs graphics programs located on either machine. Is this possible? If so, does something need to be done to the system before it is shipped to us? (2) We are getting the so-called Super Graphics Upgrade to give a total of 56 bitplanes. Are the 24 z-buffer planes ONLY for z-buffering, or can we use 48 for color w/o z-buffering so that we can use RGB mode in double-buffer mode? (3) Does the SGI WorkSpace software and Diagnostics software come standard? (4) Is the data cache write-through and/or virtual-addressable? Thanks in advance, Peter Loan loan%roses.stanford.edu@sunrise.stanford.edu loan@polya.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00853; 6 Dec 89 18:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00650; 6 Dec 89 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00587; 6 Dec 89 17:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09955; 6 Dec 89 17:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26882; Wed, 6 Dec 89 14:27:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 89 22:21:50 GMT From: Mark Bradakis Organization: Univ. of Utah Computer Science Subject: Personal Iris disks again Message-Id: <1989Dec6.152150.6535@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On the chance that we cannot make these HP SCSI drives work on the Iris machines we have, what are some of the available disks which DO work on the Personal Iris (running 3.2)? What sort of experiences have others had? We have had lots of experience with HP machines, little with SGI stuff. The HP disk in question is an OEM package, the 97548S/D, of which we have a couple of test units. Would be nice if they worked right out of the box! mjb. mjb@hoosier.utah.edu "If I took a rollin' wheel, rolled it ten times 'round..."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00853; 6 Dec 89 18:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00650; 6 Dec 89 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00587; 6 Dec 89 17:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09957; 6 Dec 89 17:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26075; Wed, 6 Dec 89 14:16:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 89 21:47:23 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: /usr/etc/nfsstat interpretation Message-Id: <45861@sgi.sgi.com> References: <8912051828.AA11401@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > I have a 4D/240 server that is being used as a NFS and Yellow Pages > server for a lab of 20 Personal Irises. Lately, we've been experiencing a > lot of problems with NFS "getattr" failures. I looked at the output of the > /usr/etc/nfsstat but am not sure what I am looking for or how to determine if > it is the server or a client having a problem, and if it is a client, how do > I find out which of the 20 PIs is having the problem. Could someone help me > interpret the following nfsstat output? Thanks! When you write "getattr" failures, do you mean this message came out on the client's console? NFS getattr failed for server XXX: Connection timed out If so, the client is soft-mounting the server's filesystem(s). A hard mount never times out. The nfsstat numbers confirm this: > Client rpc: > calls badcalls retrans badxid timeout wait newcred > 316821 322 105 9 266 0 0 > > Client nfs: > calls badcalls nclget nclsleep > 316821 322 316821 0 The 9 badxids suggest that the server got behind the client: old replies came back after the calling client process had timed out, and new calls waiting for their replies noted the old replies' transaction identifiers (xids) as "bad". The 266 timeouts indicate an overloaded server, sick Ethernet, or some similar problem. Try mounting with a larger initial timeout (the timeo mount(1M)/fstab(4) option), and/or retransmission attempt limit (retrans). Use netstat(1) to check for input/output errors detected by the network interface, which might indicate a sick Ethernet. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00912; 6 Dec 89 18:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00853; 6 Dec 89 18:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00833; 6 Dec 89 18:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10131; 6 Dec 89 17:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27823; Wed, 6 Dec 89 14:41:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 89 22:30:51 GMT From: Ken Chin-Purcell Organization: Minnesota Supercomputer Center Subject: Memory for 4D/240 Message-Id: <883@uc.msc.umn.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for a good 3rd party vendor of ECC memory modules for the 4D/240. SGI's prices seem a little steep. Please e-mail responses, and I'll summarize if anyone is interested. Ken Chin-Purcell (aka ken@msc.umn.edu) Minnesota Supercomputer Center 1200 Washington Ave. So. Minneapolis, MN 55415   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01517; 6 Dec 89 22:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01463; 6 Dec 89 22:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01445; 6 Dec 89 21:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12090; 6 Dec 89 21:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA11476; Wed, 6 Dec 89 18:09:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 01:35:49 GMT From: David Wong Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 4MB simms on IRIS 4D/25 Message-Id: <45879@sgi.sgi.com> References: <37342@ames.arc.nasa.gov>, <11972@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > I have tested 4Mbit simms on a 4D/25 without problems. I took it > all the way to 64Megabytes. However, you need to be at a certain > rom revision in order for the 4mbit simms to be recognized. > I believe the revision is 3.2 rev E (I would really appreciate > someone at SGI confirming this). All versions of PROM should be able to figure out the type of SIMMS you are using, either 1MB or 4MB. -- David   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01610; 6 Dec 89 22:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01566; 6 Dec 89 22:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01541; 6 Dec 89 22:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11437; 6 Dec 89 20:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08762; Wed, 6 Dec 89 17:25:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 01:14:36 GMT From: Jason Heirtzler Organization: Boston University Distributed Systems Group Subject: swapping in IRIX 3.2 -- how does it work? Message-Id: <44064@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can someone explain how swapping works in IRIX 3.2? It doesn't look like swap space is being allocated on the disk until it's actually necessary to swap a process out. This seems different than 4.{2,3} BSD, which wants to allocate space on the swapping device as you allocate physical memory. No? # /etc/swap -l path dev swaplo blocks free /dev/dsk/dks0d1s1 22,33 0 102256 102256 /dev/dsk/dks0d2s0 22,64 0 102256 102256 Does IRIX interleave swapping between multiple disks to take full advantage of the increase in I/O that is possible? jdh ------------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!harvard!bu-cs!bu-it!jdh   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01610; 6 Dec 89 22:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01566; 6 Dec 89 22:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01564; 6 Dec 89 22:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12719; 6 Dec 89 22:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA15068; Wed, 6 Dec 89 19:04:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 02:18:35 GMT From: Wiltse Carpenter Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Telnetd problem in 3.2? Message-Id: <45885@sgi.sgi.com> References: <8912010051.AA27187@sgi.sgi.com>, <619@voodoo.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <619@voodoo.UUCP>, zombie@voodoo.UUCP (Mike York) writes: > > 1. The dial & button box does not work properly under 3.2, rendering > our application next to useless for production (it doesn't impact us > too much for developmenmt). The hotline says this problem is fixed for > 3.3, but they haven't gotten back to us yet on what to do to fix the > problem for 3.2. Is the fix in 3.2.1? > The problem with the dial box in 3.2 has to do with the dbtext() function. If a program repeatedly calls dbtext() at a rate higher than the serial link to the dial box can sustain, dbtext() will leave a file descriptor open. This bug has been fixed internally. A work around for the problem would be stat(2) the file ``/dev/dialwarp'' which is a FIFO used to pass data from the application program to the dial daemon and check to see if it contains more than say 8K of data. If the FIFO is this full, then the application should pause until it empties. Note that each call to dbtext() results in only 12 bytes of data and the dial box serial line runs at 9600 baud so one needs to be calling dbtext() rapidly to see the failure. We will of course be fixing this bug in the next possible release, but it is not fixed in 3.2.1.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03077; 7 Dec 89 4:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02887; 7 Dec 89 4:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02871; 7 Dec 89 3:50 EST Received: from text.inria.fr by SMOKE.BRL.MIL id aa14814; 7 Dec 89 3:43 EST Received: by inria.fr with X.400; 07 Dec 89 09:45:48+0100 Received: by ch; 07 Dec 89 09:43:40+0100 Date: 07 Dec 89 09:43:40+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: 3.2.1. still chrashes 4D/120GTX Message-ID: <144*doelz@urz.unibas.ch> (sigh...) I'd like to report a bug in 3.2.1. and its workaround. Sorry to say but it was calimed that it should be fixed in the maintenance release but it isn't. We are running a 120GTX OS 3.2.1. The program shown below runs on two processors. The graphics manager fails to start up and the graphics is unusable (No window manager). The /usr/adm/SYSLOG says Dec 7 09:17:00 modl grcond[290]: CIO: **************************************** * ****************************** Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: IRIX System V Release 3.2.1 IP5 Version 1 0171414 Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: root on dev 0x400, swap on dev 0x401 Dec 7 09:17:00 modl grcond[290]: CIO: CPU 1 taking over time and accounting fu n ctions Dec 7 09:17:00 modl grcond[290]: CIO: gfx_wait_cx: context switch timed out Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: gm-2 (configured for IP5) 1.14+ Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:17:00 modl grcond[290]: CIO: DEBUG_NOISE at 0x9806648C Dec 7 09:17:00 modl grcond[290]: CIO: Loading PP ucode Version: @(#) PEAPOD 1 . 2 pp microcode assembler - 6/20/87 Dec 7 09:17:00 modl grcond[290]: CIO: Sat Aug 19 19:10:21 1989 user unknown re v ision(1.123CLOVER2IP5GT) Dec 7 09:17:00 modl grcond[290]: CIO: Dec 7 09:23:43 modl grcond[290]: Child process /bin/wsh exited with status 0 Dec 7 09:23:43 modl grcond[290]: Child process /etc/gl/pandora exited with sta t us 0 Dec 7 09:23:43 modl grcond[392]: In limbo Dec 7 09:23:48 modl grcond[392]: Alive Dec 7 09:23:48 modl grcond[392]: CIO: **************************************** * ****************************** Dec 7 09:23:48 modl grcond[392]: CIO: Copyright 1984 AT&T - Al l Rights Reserved Dec 7 09:23:48 modl grcond[392]: CIO: Copyright 1987 Silicon Graphics Inc - Al l Rights Reserved Dec 7 09:23:48 modl grcond[392]: CIO: RESTRICTED RIGHTS LEGEND Dec 7 09:23:48 modl grcond[392]: CIO: Use, duplication or disclosure by the Government is subject Dec 7 09:23:48 modl grcond[392]: CIO: to restrictions as set forth in subdi v ision (c)(1)(ii) of Dec 7 09:23:48 modl grcond[392]: CIO: the Rights in Technical Data and Comp u ter Software clause Dec 7 09:23:48 modl grcond[392]: CIO: at 52.227-7013. Manufacturer is Sili c on Graphics, Inc., Dec 7 09:23:48 modl grcond[392]: CIO: 2011 N. Shoreline Blvd., Mountain Vie w , CA 94039-7311. Dec 7 09:23:48 modl grcond[392]: CIO: **************************************** * ****************************** Dec 7 09:23:48 modl grcond[392]: CIO: Dec 7 09:23:48 modl grcond[392]: CIO: IRIX System V Release 3.2.1 IP5 Version 1 0171414 Dec 7 09:23:48 modl grcond[392]: CIO: Dec 7 09:23:48 modl grcond[392]: CIO: root on dev 0x400, swap on dev 0x401 Dec 7 09:23:48 modl grcond[392]: CIO: CPU 1 taking over time and accounting fu n ctions Dec 7 09:23:48 modl grcond[392]: CIO: gfx_wait_cx: context switch timed out Dec 7 09:23:48 modl grcond[392]: CIO: Dec 7 09:23:48 modl grcond[392]: CIO: gm-2 (configured for IP5) 1.14+ Dec 7 09:23:48 modl grcond[392]: CIO: Dec 7 09:23:48 modl grcond[392]: CIO: DEBUG_NOISE at 0x9806648C Dec 7 09:23:48 modl grcond[392]: CIO: Loading PP ucode Version: @(#) PEAPOD 1 . 2 pp microcode assembler - 6/20/87 Dec 7 09:23:48 modl grcond[392]: CIO: Sat Aug 19 19:10:21 1989 user unknown re v ision(1.123CLOVER2IP5GT) Dec 7 09:23:48 modl grcond[392]: CIO: ... and theresfore I conclude that the grcond is unable to start up. The IRIS is fully networked running nfs, 4DDN and TCP/IP thus eventually suffering from this. Therefore, I changed the kernel to read the network on CPU0 as follows: 107c107 < #define NBUF 100 /* # buffers in disk buffer cache */ --- > #define NBUF 400 /* # buffers in disk buffer cache */ 215c215 < #define MAXSC 26 --- > #define MAXSC 30 353c353 < int network_processor = 1; --- > int network_processor = 0; modl [/usr/sysgen/master.d] % ... did an lboot and problem solved. The fortran program is special but I wrote a dummy routine which performs the crashes: real x(100,1000), y(100,1000) seed=123456 do 100 i=1,100 do 101 ii=1,1000 x(ii,i)=rand(seed) 101 continue 100 continue write (6,*)'ran done' do 200 i=1,100 do 201 ii=1,1000 y(ii,i)=sin(x(ii,i))*cos(x(ii,i)) y(ii,i)= * (y(ii,i)**1.003)**(1-(sin(x(ii,i))/1000)) do 202 iii=1,900 y(ii,i)= * y(ii,i)**(1-(sin(x(ii,i))/1000)) 202 continue 201 continue 200 continue stop end pfa concurrentizes the 200 do loop which gives a fully paralelly running program. BTW in order to avoid the kernel you could also debug the routinge as root sending a schedctl call but I hate that. I'd like SGI to implement a suspend utility... My questions are Does the network processor really play a role in the game or does it work by accident? Did someone of you experience the same problem? Why does the graphics pipe start version 1.123 but is configured for microcode 1.14+ ? Could someone of SGI comment on that please, the Swiss SGI does not know whats going on. Reinhard ************************************************************************ * Dr. Reinhard Doelz * SWITZERLAND * * Biocomputing * * * Biozentrum * doelz%urz.unibas.ch@relay.cs.net * * Klingelbergstrasse 70 * * * CH-4056 Basel * * ************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04111; 7 Dec 89 7:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03962; 7 Dec 89 7:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03940; 7 Dec 89 6:56 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16076; 7 Dec 89 6:42 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8633; Thu, 07 Dec 89 06:43:15 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 07 Dec 89 12:45:29 Date: Thu, 7 Dec 89 12:44:11 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Hardware questions To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8912070642.aa16076@SMOKE.BRL.MIL> Hallo, can somebody please answer the following questions: a) what are the differences between the 1MB Simms for the 4D/GT and the 4D/20 and 4D/25, if there are any. b) what kind of connector is used for the external SCSI-connection on the PI? Is that connector identical to the connector of the "Extendeable SCSI Module (HU-XSCSI)" available for the G/GT series. If they are not identical, what kind of connector is used for the HU-XSCSI? Thanks in advance Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13768; 7 Dec 89 15:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11383; 7 Dec 89 14:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11325; 7 Dec 89 13:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27627; 7 Dec 89 13:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA09365; Thu, 7 Dec 89 10:38:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 17:54:43 GMT From: Jim Bennett Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Questions about Personal IRIS Message-Id: <45921@sgi.sgi.com> References: <12939@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12939@polya.Stanford.EDU>, loan@polya.Stanford.EDU (James P. Loan) writes: > > (1) I assume that the Personal IRIS comes standard with a 19" > monitor Yes. > (it doesn't say so on our quote), so we'll have > the old 19" (1024x768) monitor from the 2400T as well as > the new one (1280x1024). What we'd like to do is be able > to run graphics programs on one (or the other) cpu and display > them on either of the monitors. The scenario is that > someone sits down at one of the monitors and is able to > runs graphics programs located on either machine. > Is this possible? If so, does something need to be done > to the system before it is shipped to us? Its not possible: The 2400 doesn't support the 1280x1024 resolution. The PI will eventually support both resolutions, but currently doesn't, and the 1024x768 monitor we will support is a 14" Sony with different timing than the old 19" monitor on the 2400. > (2) We are getting the so-called Super Graphics Upgrade to > give a total of 56 bitplanes. Are the 24 z-buffer planes > ONLY for z-buffering, or can we use 48 for color w/o > z-buffering so that we can use RGB mode in double-buffer > mode? Double buffered RGB mode is supported. For this we divide the color bitplanes into two 12-bit buffers, and use hardware dithering to approximate true colors. This works surprisingly well. The Z-buffer can be used in a variety of ways, but only the color bitplanes and the overlay/underlay and popup planes can be displayed. > (3) Does the SGI WorkSpace software and Diagnostics software > come standard? Yes. > (4) Is the data cache write-through and/or virtual-addressable? The data cache works on physical addresses and is write-through with write buffers. > Thanks in advance, > Peter Loan > > loan%roses.stanford.edu@sunrise.stanford.edu > loan@polya.stanford.edu Jim Bennett bennett@esd.sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13973; 7 Dec 89 15:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13407; 7 Dec 89 15:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12900; 7 Dec 89 15:10 EST Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa00134; 7 Dec 89 14:56 EST Received: from VM.NRC.CA (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57393; Thu, 7 Dec 89 14:56:41 EST Received: by NRCVM01 (Mailer R2.05) id 4252; Thu, 07 Dec 89 14:50:02 EST Date: Thu, 7 Dec 89 14:49:20 EST From: LISE BRAMALL Subject: IFCONFIG NETMASK PROBLEM To: Iris Developers Message-Id: <89Dec7.145641est.57393@ugw.utcs.utoronto.ca> HELP, I have recently acquired a 4D20G-S17 Iris 56 bitplane workstation and am trying to attach to an existing TCPIP network. The networking people have requested that I change my netmask to 255.255.255.0.0 to satisfy their setup requirements because of the IP domain allocations. When I do this change using ifconfig ec0 netmask 255.255.255.0 the command is accepted but after I logout I cannot login again unless I specify NOGRAPHICS as this netmasking change has ruined the windowing access. I have performed the same netmask change on a SUN workstation and have had no problems. Your attention to this problem will be greatly appreciated. Please respond via BITNET. Thank You Lise Bramall LNB@NRCVM01   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14426; 7 Dec 89 16:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12527; 7 Dec 89 14:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12522; 7 Dec 89 14:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29388; 7 Dec 89 14:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA12562; Thu, 7 Dec 89 11:24: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: 7 Dec 89 19:18:33 GMT From: Scum Organization: Carnegie-Mellon University, CS/RI Subject: Another SGI graphics problem/solution to last one Message-Id: <7254@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL First, I should, since I posted the question here, answer why my system wasn't working when we got our upgrade. It turns out that, unbeknownst to me, we only got the eoe and nfs upgrades; we didn't get the development package. Thanks to the SGI people who responded to me. I really appreciate the fact that you folks read this board and try to help us with the problems here. Now, my system is a happy system once again, and running fine. Or at least it was until a new feature was added. We want to use dgl (Distributed Graphics Library) and have things appear on another monitor's screen. That works; however, on the local screen there is a problem with lighting in one of the windows, and it's pretty weird. The objects appear, and they appear in the correct material colour. However, the lighting model or the lights seem to be screwed up. The objects are just coloured flat now. No shadows, no shading, no perspective, nothing. This worked in gl, but it seems there is something missing in dgl. By the way, normals are set. I tried depth cueing and z-buffering with dgl on the local, remote and both screens, and those worked. The lighting works when I link gl, but not dgl. Of course, the graphics don't get distributed in gl. I called the graphics hotline (in fact, they're the ones who suggested these tests), and they're working on the problem. However, given as I'm desparate for time, I thought I'd post on here to see if anybody had any clues on this problem. Perhaps somebody has encountered it before, for instance. Thanks for any help. -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15126; 7 Dec 89 19:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14900; 7 Dec 89 18:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14879; 7 Dec 89 17:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04800; 7 Dec 89 17:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA25912; Thu, 7 Dec 89 14:43: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: 7 Dec 89 21:34:48 GMT From: John Mahaffy Organization: Penn State University - Center for Academic Computing Subject: xterm pf1-pf3 key map Message-Id: <89341.163448OIX@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How can I map the SGI Numlock, KP_Divide, and KP_Multiply keys to behave like the PF1, PF2, and PF3 keys on a VT100 under xterm?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15214; 7 Dec 89 19:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15126; 7 Dec 89 19:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15120; 7 Dec 89 19:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05354; 7 Dec 89 18:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29497; Thu, 7 Dec 89 15:36: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: 7 Dec 89 23:21:56 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Another SGI graphics problem/solution to last one Message-Id: <45948@sgi.sgi.com> References: <7254@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From postnews Thu Dec 7 15:18:37 1989 In article <7254@pt.cs.cmu.edu>, cycy@isl1.ri.cmu.edu (Scum) writes: > > We want to use dgl (Distributed Graphics Library) and have things appear > on another monitor's screen. That works; however, on the local screen there > is a problem with lighting in one of the windows, and it's pretty weird. The > objects appear, and they appear in the correct material colour. However, the > lighting model or the lights seem to be screwed up. The objects are just > coloured flat now. No shadows, no shading, no perspective, nothing. This worked > in gl, but it seems there is something missing in dgl. By the way, normals are > set. I tried depth cueing and z-buffering with dgl on the local, remote and > both screens, and those worked. The lighting works when I link gl, but not dgl. I think you stumbled across one of the commands that behave slightly differentlyin the GL than in the DGL. The command is lmdef, and the GL ignores the third parameter whereas the DGL requires it. People normally, by habit, put 0 as the 3rd parameter and the GL works fine. If you read the man page , the 3rd parameter is supposed to be the number of floats in the 4th argument. The DGL looks at this value to determine how many floats to send. Thus if you are like most people and set it to 0, the DGL will send 0 floats and thus lmdef wont work and the result will be just like what you are experiencing - total weirdness. There is also a slight difference in behavior if you use NULL for the 4th parameter and dont specify 0 for the 3rd. I dont suspect this is your problem, however. Check the 3rd parameter and make sure it is set correctly, that should fix your problem. -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15857; 7 Dec 89 22:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15752; 7 Dec 89 22:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15732; 7 Dec 89 22:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06974; 7 Dec 89 22:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA12274; Thu, 7 Dec 89 19:01:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 01:20:13 GMT From: Chris Shaw Organization: U. of Alberta, Edmonton, Alberta, Canada Subject: Re: 3130 Genlock <-> Lenco Message-Id: <1989Dec8.012013.2466@alberta.uucp> References: <390@fsu.scri.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <390@fsu.scri.fsu.edu> pepke@scri1.scri.fsu.edu (Eric Pepke) writes: >Has anybody successfully connected an old 3130 genlock board to a Lenco >sync generator/NTSC encoder? The Lenco generator has six outputs: BF, SY, >HD, VD, BL, and SC. What, no "Video Out" ?? Actually, all this other stuff is the NTSC signal broken into its various bits and peices, such as Horizontal Sync, Vertical Sync, Blanking, etc... So, hook Red on Iris to Red input on the Lenco, Red out on Lenco to the Red input on your monitor. Same for Green, Blue and Sync. On our CCE-850, inputs are the bottom row of 4 BNC connectors, outputs are the top row. Hook "Video Output" on the Lenco to Video input on a NTSC monitor, and it should work. Works on our 2400 & our 3130. >Eric Pepke INTERNET: pepke@gw.scri.fsu.edu -- Chris Shaw University of Alberta cdshaw@alberta.UUCP CatchPhrase: Bogus as HELL !   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16745; 8 Dec 89 2:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16584; 8 Dec 89 1:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16581; 8 Dec 89 1:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08305; 8 Dec 89 1:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA23781; Thu, 7 Dec 89 22:21:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 19:01:43 GMT From: Joe Ilacqua Organization: Software Tool & Die Subject: YP Between SGI and SUN (FYI) Message-Id: <1989Dec7.190143.25284@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just made our new 4D/25 (running 3.2.1) a YP client of a SUN (3/60, SUNOS 4.0.3). You need to merge the SUN & SGI versions of /etc/services, /etc/rpc, and /etc/protocols. Once you make these changes it works fine. One annoying thing does crop up however. We have two YP domains on the same net, and the SGI's rpc.bootparamd will respond to "Who_am_i" requests from machines in the other YP domain. The SGI tells the machine making the request that it is in the same domain as the SGI. The machines the SGI responds to are not in the bootparams map or /etc/bootparams. I don't know a lot about the protocol, but is suspect this is a bug. To work around, comment out the rpc.bootparamd line in /usr/etc/inetd.conf. -- "The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bps   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23316; 8 Dec 89 11:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22750; 8 Dec 89 10:57 EST Received: by VMB.BRL.MIL id ab22435; 8 Dec 89 10:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18108; 8 Dec 89 6:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10269; 8 Dec 89 6:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08935; Fri, 8 Dec 89 03:49:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 22:44:58 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: inst Message-Id: <10224@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL it is possible in general to ignore the horrible crap present everywhere in SGI (and MIPS and perhaps all system V's) about stupid pagers getting in the way by setting PAGER=cat. the most notable exception is inst which appears to use either its own or ignores $PAGER. can this get fixed for the next release? furthermore, it does one byte reads and thus screws up people for whom the stty fails (like coming in over a network). (for example, trying to do a manual install of everything means responding to the more? prompt with " 4\n".) i also note that installing the 3.2 tape 1 assumes you have /etc in your path (it just does a mknod).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28046; 8 Dec 89 22:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28025; 8 Dec 89 22:41 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa28022; 8 Dec 89 22:36 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa11258; 8 Dec 89 22:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04885; Fri, 8 Dec 89 19:20:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 22:10:31 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: News-servers that grow but never shrink. Message-Id: <1843@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <124@cutmcvax.OZ> Phil Dench (architec@cutmcvax.uucp) writes: > > It would be nice if the news-postcript 'save' did something like... > > old_data_seg = sbrk( 0); > > and the 'restore' did something like... > > brk( old_data_seg); > That's a great idea. Unfortunately the data segment is shared among all the light-weight processes. Thus changing the sbrk could have bad effects on other lwp's. Fixing the problem requires major changes to the way memory is allocated within the server. > > But is there a quick fix (other than logging out and in again)? Unfortunately no. -- >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 aa28246; 8 Dec 89 23:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28046; 8 Dec 89 22:56 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa28039; 8 Dec 89 22:48 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa11522; 8 Dec 89 22:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05307; Fri, 8 Dec 89 19:26:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 02:27:56 GMT From: Phil Karlton Organization: Silicon Graphics, WorkGroup Products Division Subject: Re: xterm pf1-pf3 key map Message-Id: <1847@odin.SGI.COM> References: <89341.163448OIX@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89341.163448OIX@PSUVM.BITNET>, OIX@PSUVM.BITNET (John Mahaffy) writes: > How can I map the SGI Numlock, KP_Divide, and KP_Multiply keys to behave > like the PF1, PF2, and PF3 keys on a VT100 under xterm? The command xmodmap -e "keysym Num_Lock = KP_F1" -e "keysym KP_Divide = KP_F2" \ -e "keysym KP_Multiply = KP_F3" or something like it should do the trick. The spaces within the quotes are significant PK -- Phil Karlton karlton@sgi.com Silicon Graphics Computer Systems 415-335-1557 2011 N. Shoreline Blvd. Mountain View, CA 94039   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17068; 8 Dec 89 3:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16979; 8 Dec 89 3:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16958; 8 Dec 89 2:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08983; 8 Dec 89 2:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA28708; Thu, 7 Dec 89 23:52:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 07:46:59 GMT From: Scum Organization: Carnegie-Mellon University, CS/RI Subject: Re: Another SGI graphics problem/solution to last one Message-Id: <7269@pt.cs.cmu.edu> References: <7254@pt.cs.cmu.edu>, <45948@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <45948@sgi.sgi.com>, tarolli@riva.esd.sgi.com (Gary Tarolli) writes: > In article <7254@pt.cs.cmu.edu>, cycy@isl1.ri.cmu.edu (Scum) writes: > > We want to use dgl (Distributed Graphics Library) and have things appear > > on another monitor's screen. That works; however, on the local screen there > > is a problem with lighting in one of the windows, and it's pretty weird. The > > objects appear, and they appear in the correct material colour. However, the > > lighting model or the lights seem to be screwed up. The objects are just > > coloured flat now. No shadows, no shading, no perspective, nothing. This worked > > in gl, but it seems there is something missing in dgl. By the way, normals are > > I think you stumbled across one of the commands that behave slightly differentlyin the GL than in the DGL. The command is lmdef, and the GL ignores the third > parameter whereas the DGL requires it. People normally, by habit, put 0 as > the 3rd parameter and the GL works fine. If you read the man page , the 3rd > parameter is supposed to be the number of floats in the 4th argument. The > DGL looks at this value to determine how many floats to send. Thus if you > are like most people and set it to 0, the DGL will send 0 floats and thus > Check the 3rd parameter and make sure it is set correctly, that should fix > your problem. > Gary Tarolli That was it! Actually, I had miscounted the parameters (I skipped a line in when I was counting the elements in the array) and had used 10 instead of 14 for the third parameter. Thanks a million!!!!!!!!! -- Chris. -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21703; 8 Dec 89 9:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21393; 8 Dec 89 9:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21198; 8 Dec 89 9:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13663; 8 Dec 89 9:10 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16247; Fri, 8 Dec 89 06:06:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 13:31:11 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: 3.2.? Message-Id: <1746@uvaarpa.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know when SGI will ship release 3.2.? for servers like a CS-12 or a 4D25S ? (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22216; 8 Dec 89 10:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21393; 8 Dec 89 9:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21262; 8 Dec 89 9:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13676; 8 Dec 89 9:10 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA16263; Fri, 8 Dec 89 06:06:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 13:33:16 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: X-windows for servers Message-Id: <1747@uvaarpa.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can I use Xwindows with a cheep Xwindows terminal being driven by a 4D25S or a CS-12 ? (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24350; 8 Dec 89 12:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24167; 8 Dec 89 12:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24119; 8 Dec 89 12:35 EST Received: from ames.arc.nasa.gov by SMOKE.BRL.MIL id aa19134; 8 Dec 89 12:02 EST Received: from elxsi.dfrf.nasa.gov by ames.arc.nasa.gov (5.61/1.2); Fri, 8 Dec 89 09:04:16 -0800 Received: by elxsi.dfrf.nasa.gov (5.51/5.17) id AA02216; Fri, 8 Dec 89 09:02:11 PST Date: Fri, 8 Dec 89 09:02:11 PST From: rashkin@elxsi.dfrf.nasa.gov Message-Id: <8912081702.AA02216@elxsi.dfrf.nasa.gov> Subject: re: Ada on the Iris To: info-iris@BRL.MIL We are looking at personal iris' for a front end to our Gould simulation computers. They also need to serve as our software development platform. We will have a Sun Sparcserver as our fileserver with Sparcstations on the network as well. One requirement of the simulation is that our computers run Ada. Specifically, Ada that can be linked with Fortran. Any input on Ada on the Iris would be greatly appreciated. Thank you, Susan Rashkin Nasa Ames Dryden Flight Research Facility Edwards, Ca. 805-274-2581 rashkin@elxsi.dfrf.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24505; 8 Dec 89 13:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23975; 8 Dec 89 12:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23916; 8 Dec 89 12:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18762; 8 Dec 89 11:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA24088; Fri, 8 Dec 89 08:28: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: 8 Dec 89 16:04:47 GMT From: Eric Pepke Organization: Supercomputer Computations Research Institute Subject: Re: 3130 Genlock <-> Lenco Message-Id: <395@fsu.scri.fsu.edu> References: <390@fsu.scri.fsu.edu>, <1989Dec8.012013.2466@alberta.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Dec8.012013.2466@alberta.uucp> cdshaw@pembina.UUCP (Chris Shaw) writes: >What, no "Video Out" ?? >Actually, all this other stuff is the NTSC signal broken into its various >bits and peices, such as Horizontal Sync, Vertical Sync, Blanking, etc... > >So, hook Red on Iris to Red input on the Lenco, Red out on Lenco to the >Red input on your monitor. Same for Green, Blue and Sync. On our CCE-850, >inputs are the bottom row of 4 BNC connectors, outputs are the top row. >Hook "Video Output" on the Lenco to Video input on a NTSC monitor, and >it should work. Works on our 2400 & our 3130. You misunderstand. I thought that my mention of the words "genlock" and "sync generator" should have made my problem clear. My problem is not in getting the RGB into the encoder and producing an NTSC signal. I can do that using the internal sync matching just fine, but the quality is low, and I intend to try the genlock method. My problem is getting the sync output from the sync generator into the IRIS. I only mentioned the outputs that are relevant to that problem. So, perhaps I can state the problem in a more detailed fashion. The Lenco PGE-843 is a combination sync generator and NTSC encoder, which means that it does two things--generate sync and encode RGB into NTSC. My problem is with that half of the box which generates sync and does not extend to the other half of the box, except inasmuch as there probably exists an internal connection to ensure the correctness of the phase of the chroma information. The sync generator has six sync outputs, which are sync components, and the IRIS Genlock board has two sync inputs, labeled J7 and J8, which are probably the same as what are in other places called HSYNC and VSYNC. I suspect that the solution is simple and merely involves wiring up a bridge to combine the six sync outputs of the generator into the two sync inputs to the IRIS Genlock board. However, I do not yet know the composition of said bridge, and my ignorance is compounded by the fact that my documentation to the Genlock board was lost during a move. Keith Seto, manager of the technical support group at SGI, has kindly agreed to send me a copy of some documentation, so I should be well on my way to solving this problem soon. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27417; 8 Dec 89 19:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27381; 8 Dec 89 18:49 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa27375; 8 Dec 89 18:41 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa07754; 8 Dec 89 18:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA19170; Fri, 8 Dec 89 15:00:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 89 19:40:37 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: Mathematica Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is Mathematica shipping yet for the Silicon Graphics 4D machines? I am particularly interested availability for the 4D/25.... I guess I should ask my sales rep about the price.... On a related note: Is it likely to be possible to get an X-windows front-end for Mathematica to run on a Silicon Graphics 4D? This would be in addition to the native SGI front-end. I intend to do a lot of work from a remote X-windows terminal, and don't want to be limited to the raw ascii Mathematica interface when I am away from the console.... -- 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 aa27629; 8 Dec 89 19:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27558; 8 Dec 89 19:49 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa27556; 8 Dec 89 19:41 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa08692; 8 Dec 89 19:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA24004; Fri, 8 Dec 89 16:20: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: 8 Dec 89 23:31:52 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hardware questions Message-Id: <46033@sgi.sgi.com> References: <8912070642.aa16076@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912070642.aa16076@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > b) what kind of connector is used for the external SCSI-connection on > the PI? Is that connector identical to the connector of the "Extendeable > SCSI Module (HU-XSCSI)" available for the G/GT series. If they are > not identical, what kind of connector is used for the HU-XSCSI? > > > Thanks in advance > Martin Knoblauch > The connectors are the same. The terminators are the same, as well. 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 aa27845; 8 Dec 89 21:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27802; 8 Dec 89 20:58 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa27800; 8 Dec 89 20:51 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa09734; 8 Dec 89 20:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA28709; Fri, 8 Dec 89 17:38: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: 9 Dec 89 01:29:07 GMT From: Igor Rivin Organization: Computer Science Department, Stanford University Subject: Re: Mathematica Message-Id: <1989Dec9.012907.11140@Neon.Stanford.EDU> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes: >Is Mathematica shipping yet for the Silicon Graphics 4D machines? >I am particularly interested availability for the 4D/25.... >I guess I should ask my sales rep about the price.... Yes, Mathematica Version 1.2 is shipping for SGI machines. You can buy it either from Silicon Graphics or from WRI ((217)-398-0700). > >On a related note: > >Is it likely to be possible to get an X-windows front-end for >Mathematica to run on a Silicon Graphics 4D? This would be in >addition to the native SGI front-end. Yes, Mathematica runs under X-windows. I believe X-windows itself is an extra cost product from SGI, but I could be wrong. In any case your sales rep will probably be more informed about that than I. >I intend to do a lot of work from a remote X-windows terminal, and >don't want to be limited to the raw ascii Mathematica interface when I >am away from the console.... >-- >John D. McCalpin - mccalpin@masig1.ocean.fsu.edu > mccalpin@scri1.scri.fsu.edu > mccalpin@delocn.udel.edu -- Igor Rivin Wolfram Research, Inc. rivin@Gang-of-Four.Stanford.EDU or rivin@wri.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27938; 8 Dec 89 21:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27918; 8 Dec 89 21:45 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa27910; 8 Dec 89 21:31 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa10375; 8 Dec 89 21:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA00659; Fri, 8 Dec 89 18:09:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Dec 89 01:10:43 GMT From: Wiltse Carpenter Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2.? Message-Id: <46050@sgi.sgi.com> References: <1746@uvaarpa.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1746@uvaarpa.virginia.edu>, mlj8e@dale.acc.Virginia.EDU (Michael L. Johnson) writes: > Does anyone know when SGI will ship release 3.2.? for servers like > a CS-12 or a 4D25S ? > All versions of the 4D25, including the 4D25S, are shipped with 3.2 installed. Recent shipments may also include the 3.2.1 maintenance tape in the box, but it won't be installed on the disk. Prior versions of Irix (i.e. 3.1x) do not support the 4D25 CPU board. -Wiltse   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28908; 9 Dec 89 2:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28647; 9 Dec 89 1:30 EST Date: Sat, 9 Dec 89 1:18:55 EST From: Lee A. Butler (VLD/VMB) To: info-iris@BRL.MIL Subject: Stupid NeWS question Message-ID: <8912090118.aa28627@VMB.BRL.MIL> Can anyone tell me why the NeWS/4sight cursor is sometimes red and sometimes black? I know it's not due to a colormap change. Lee   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01667; 10 Dec 89 7:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01604; 10 Dec 89 6:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01596; 10 Dec 89 6:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06134; 10 Dec 89 6:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08326; Sun, 10 Dec 89 03:35: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: 10 Dec 89 10:40:22 GMT From: usc!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!kenyon@ucsd.edu Subject: Re: Where is 3.2 ? Message-Id: <84600004@uicbert.eecs.uic.edu> References: <140310@<89339> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have yet to recieve my 3.2 upgrade as well. According to the HOTLINE people I should be getting it at the end of DEC. bob kenyon   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01742; 10 Dec 89 7:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01604; 10 Dec 89 6:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01596; 10 Dec 89 6:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06136; 10 Dec 89 6:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA08353; Sun, 10 Dec 89 03:36:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Dec 89 10:40:32 GMT From: usc!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!kenyon@ucsd.edu Subject: Re: Answer to RECTRE problem Message-Id: <84600005@uicbert.eecs.uic.edu> References: <3051@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I got a TeX system for the 4d from vgr.brl.mil via anonymous ftp. In that tar file there is a TeX previewer for the 4d. The IP number is 192.5.53.6 for vgr.brl.mil. Good luck. bob kenyon   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03263; 10 Dec 89 21:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03239; 10 Dec 89 21:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03237; 10 Dec 89 21:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12370; 10 Dec 89 21:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18754; Sun, 10 Dec 89 18:01:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Dec 89 01:48:46 GMT From: Seth Teller Organization: University of California at Berkeley Subject: font caching in 'texsgi' dvi previewer Message-Id: <20537@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i recently pulled the 'texbin.tar' binaries from vgr.brl.mil, and extracted the dvi previewer 'texsgi' for the 4d. the binary runs ok. unfortunately, the previewer is extremely slow. it appears to be reopening a font file every time the display font changes in a sequential pass through the current page. for a document with a lot of math and italics, it looks like it's doing hundreds of fopens() per page. the "-a" flag purportedly enables font caching, but produces no speedup or extra memory usage (that i can detect). can anyone tell me: 1) if the version i have (1.0) can do font caching, or, if not, 2) how to get an update of it that can? thanks much in advance. seth teller seth@miro.berkeley.edu ucbvax!miro.berkeley.edu!seth   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12808; 11 Dec 89 12:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12293; 11 Dec 89 12:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12206; 11 Dec 89 11:54 EST Received: from hydra.gatech.edu by SMOKE.BRL.MIL id aa21941; 11 Dec 89 10:34 EST Received: by hydra.gatech.edu (5.61/3.0) id AA25453; Mon, 11 Dec 89 10:34:08 -0500 Date: Mon, 11 Dec 89 10:34:08 -0500 From: "SCHREIBER, O. A." Message-Id: <8912111534.AA25453@prism.gatech.edu> To: info-iris@BRL.MIL, usc!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!kenyon@ucsd.edu Subject: Re: Answer to RECTRE problem Cc: ccsupos@prism.gatech.edu What about LaTeX? 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 aa13481; 11 Dec 89 13:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab12808; 11 Dec 89 12:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12711; 11 Dec 89 12:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24301; 11 Dec 89 12:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05454; Mon, 11 Dec 89 09:20:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Dec 89 16:03:24 GMT From: psuvm!sml108@psuvax1.cs.psu.edu Organization: Penn State University Subject: Function Keys on Iris Console Message-Id: <89345.110324SML108@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, the pF3 and pF4 keys on the system console of our IRIS 4D/220 have somehow gotten redefined to display a string of characters which looks like they were somehow taken froma text file on our system. How do I redefine them back to their old and presumably standard values ? I am running IRIX 3.2.... Scott Le Grand aka SML108@PSUVM.PSU.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13878; 11 Dec 89 13:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11926; 11 Dec 89 11:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11886; 11 Dec 89 11:32 EST Received: from mich.physics.lsa.umich.edu by SMOKE.BRL.MIL id aa22709; 11 Dec 89 11:00 EST Date: Mon, 11 Dec 89 09:24 EDT From: SEARS@mail.physics.lsa.umich.edu Subject: Interrupt response time for VME hardware interrupts. To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <8912111100.aa22709@SMOKE.BRL.MIL> I'm writing a VME hardware device driver, and have encountered the following problem. My hardware generates an interrupt, and the service routine must send a short out to the device to stop it's operation as soon as possible. It appears that there is a bit of overhead in processing an interrupt, and my service routine may not be able to respond quickly enough. I imagine that this is something intrinsic to a multitasking system, but I'd like to know if there's any way to shorten the time between when a hardware interrupt is generated and the interrupt handler code is actually executed. If it helps, the system is sleeping at splvme() when the interrupt comes in; I'm doing data logging on existing equipment, so I have to do things according to the timing constraints of the external eqpt. Thanks, Robert Sears (sears@mich.physics.lsa.umich.edu)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17739; 11 Dec 89 19:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17548; 11 Dec 89 18:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17519; 11 Dec 89 18:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03406; 11 Dec 89 18:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27133; Mon, 11 Dec 89 14:49:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Dec 89 22:42:06 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: SIGFPE Message-Id: <624@chem.ucsd.EDU> References: <8912111534.AA25453@prism.gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL With 3.2 floating point exceptions are ignored, with NaN's and Infinity's propagated through floating point exceptions, presumably according to IEEE rules. I happen to prefer that all exceptions result in SIGFPE being raised, so that a process stops right away and either aborts or calls a signal()-specified error handler. How can I achieve this? -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17804; 11 Dec 89 19:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17739; 11 Dec 89 19:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17719; 11 Dec 89 19:10 EST Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa29966; 11 Dec 89 15:25 EST Received: from VM.NRC.CA (stdin) by ugw.utcs.utcs.utoronto.ca with BSMTP id 57425; Mon, 11 Dec 89 15:23:32 EST Received: from NRCNET.NRC.CA by VM.NRC.CA (Mailer R2.05) with BSMTP id 2058; Mon, 11 Dec 89 15:23:07 EST Date: Mon, 11 Dec 89 15:05:00 EST From: Martin Serrer - Systems Manager Subject: 4DDN/DECnet , binary file transfer To: info-iris@BRL.MIL X-VMS-To: nrcnet::in%"info-iris@brl.mil" Message-Id: <89Dec11.152332est.57425@ugw.utcs.utcs.utoronto.ca> Hello all, Simple problem. I have a binary file on a VAX, VMS 5.1b (full specification follows) that I wish to copy to my IRIS 4D50/GT, IRIX 3.2 using DECnet. I have installed 4DDN right out of the box. I am getting the following error message as a result of the copy attempt. ------------------------------------------------------------------------------ %COPY-E-WRITEERR, error writing THOR"serrer password"::/usr/people/serrer/plot.d at -RMS-F-RSZ, invalid record size %COPY-W-NOTCMPLT, CROW$USER1:[SERRER.PROJECTS.MEDYNA]PLOT.DAT;1 not completely c opied ------------------------------------------------------------------------------ Are there any 4DDN parameters etc. that I should be tweaking?? or am I attempting the impossible?? Thanx in advance Martin SERRER@SYSLAB.NRC.CA ------------------------------------------------------------------------------ PLOT.DAT;1 File ID: (98,7,0) Size: 707/708 Owner: [SERRER] Created: 9-MAY-1989 10:49:17.67 Revised: 11-DEC-1989 14:46:46.08 (130) Expires: Backup: File organization: Sequential File attributes: Allocation: 708, Extend: 0, Global buffer count: 0 No version limit Record format: Variable length, maximum 1338 bytes Record attributes: None RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:, World: Access Cntrl List: None Total of 1 file, 707/708 blocks. I need this file on my IRIS 4D50/GT   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23121; 12 Dec 89 7:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22467; 12 Dec 89 7:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab22455; 12 Dec 89 7:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10966; 12 Dec 89 7:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA09909; Tue, 12 Dec 89 03:56:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Dec 89 22:54:43 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: re: Ada on the Iris Message-Id: <1912@odin.SGI.COM> References: <8912081702.AA02216@elxsi.dfrf.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912081702.AA02216@elxsi.dfrf.nasa.gov>, rashkin@ELXSI.DFRF.NASA.GOV writes: > We are looking at personal iris' for a front end to our Gould simulation > computers. They also need to serve as our software development platform. > We will have a Sun Sparcserver as our fileserver with Sparcstations > on the network as well. One requirement of the simulation is that our > computers run Ada. Specifically, Ada that can be linked with Fortran. > Any input on Ada on the Iris would be greatly appreciated. > > Thank you, > > Susan Rashkin > Nasa Ames Dryden Flight Research Facility > Edwards, Ca. > 805-274-2581 > rashkin@elxsi.dfrf.nasa.gov The Silicon Graphics Ada code can be linked with FORTRAN, C, C++, and Pascal code on the 4D (Personal Iris). The SGI Ada compiler also has a supported interface to the Graphics Library (GL). NFS is also supported (as an option) and should work well within your heterogeneous environment. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23121; 12 Dec 89 7:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab22467; 12 Dec 89 7:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac22455; 12 Dec 89 7:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10972; 12 Dec 89 7:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10228; Tue, 12 Dec 89 04:01: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: 11 Dec 89 16:55:20 GMT From: Scott Henry Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Function Keys on Iris Console Message-Id: References: <89345.110324SML108@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89345.110324SML108@PSUVM.BITNET> SML108@PSUVM.BITNET writes: SLG> Hi, the pF3 and pF4 keys on the system console of our IRIS 4D/220 have somehow SLG> gotten redefined to display a string of characters which looks like they SLG> were somehow taken froma text file on our system. How do I redefine them back SLG> to their old and presumably standard values ? SLG> I am running IRIX 3.2.... You want to read the man page on bindkey. pF3 and pF4 now default to being the same as "copy" and "send", respectively, from the wsh menu. The easiest way to get the function keys back to their "correct" state is to issue the commands: "bindkey -l f3; bindkey -l f4". Note that key bindings are *per wsh*, so you will need to do this for each and every wsh. The easiest way (if you always want the change) is to put the commands in your ~/.cshrc. BTW, I've looked, and can't find any reference to this change in the on-line release notes. SLG> Scott Le Grand aka SML108@PSUVM.PSU.EDU -- Scott Henry | Tardis Express -- when it Information Services, | absolutely, positively Silicon Graphics, Inc | has to be there -- yesterday.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23336; 12 Dec 89 7:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac22467; 12 Dec 89 7:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad22455; 12 Dec 89 7:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10974; 12 Dec 89 7:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10265; Tue, 12 Dec 89 04:01:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 89 01:23:46 GMT From: Dave Babcock Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Ada on the Iris Message-Id: <1921@odin.SGI.COM> References: <8912081702.AA02216@elxsi.dfrf.nasa.gov>, <1912@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >> We are looking at personal iris' for a front end to our Gould simulation >> computers. They also need to serve as our software development platform. >> We will have a Sun Sparcserver as our fileserver with Sparcstations >> on the network as well. One requirement of the simulation is that our >> computers run Ada. Specifically, Ada that can be linked with Fortran. >> Any input on Ada on the Iris would be greatly appreciated. >> Thank you, >> Susan Rashkin >> Nasa Ames Dryden Flight Research Facility >> Edwards, Ca. >> 805-274-2581 >> rashkin@elxsi.dfrf.nasa.gov In fact there is an Ada compiler for the Iris system which should meet your needs. It's been available for about 1 1/2 years. The most recent version (2.0) can be ordered as product number S4-ADA-2.0. It is a derivative of VADS (the Verdix Ada Development System) and was validated under ACVC 1.10 (June 26, 1989). The Ada compiler shares a common code generator with C, Fortran 77 and Pascal; it fully (and easily) supports 'Pragma Interface' to these languages. In addition to the usual VADS development tools (Ada librarian, source debugger, pretty printer, Unix system call packages, etc.) SGI provides a complete Ada interface package to our 3D color graphics hardware. I'm guessing from your application area (simulation) that graphics will play an important part. NFS runs on all members of the Iris family including the Personal Iris. In fact, I myself have a Personal Iris which I use for Ada development. Some of my Ada libraries are remote mounted from other systems on the network. Since you'll be running in a heterogeneous network you might also find our new 'Workspace' product useful. It is a standard part of system release 3.2 and provides a graphical user interface (point and click) to the system. You can easily generate your own icons which represent files and/or invoke tools either on the local system or (transparently) on any remote system. We demonstrated the Ada development tools integrated into Workspace at Tri-Ada in October and it was very favorably received. I hope that this provides you with the information you need. If not, please ask. +-----------------------------------+--------------------------------------+ | Dave Babcock | Email: daveb@wpd.sgi.com | | Silicon Graphics Computer Systems | | | P.O. Box 7311 - M/S 9U-520 | Voice: (415) 335-1547 (local) | | 2011 N. Shoreline Blvd. | (800) 442-1020 2222 (CA) | | Mountain View, CA 94039-7311 | (800) 341-1020 2222 (not CA) | +-----------------------------------+ | | ** Views expressed are my own. ** | Fax: (415) 969-2314 | +-----------------------------------+--------------------------------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02150; 12 Dec 89 13:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00825; 12 Dec 89 13:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aj00373; 12 Dec 89 13:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20297; 12 Dec 89 12:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26995; Tue, 12 Dec 89 09:02:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 89 16:53:08 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: mouse position for wsh Message-Id: <600@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are running IRIX 3.2 and whenever we open up a new window the mouse is positioned at the upper left of the outline for positioning. Prior to the upgrade the mouse was positioned at the lower left. How do I change it so that the mouse is at the lower left for positioning the windows? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02816; 12 Dec 89 14:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00825; 12 Dec 89 13:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00373; 12 Dec 89 13:21 EST Received: from pig.drea.dnd.ca by SMOKE.BRL.MIL id aa15176; 12 Dec 89 9:54 EST Received: Tue, 12 Dec 89 10:58:29 AST by pig.drea.dnd.ca (5.52/5.6) Date: Tue, 12 Dec 89 10:58:29 AST From: Jim Diamond Message-Id: <8912121458.AA20677@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: gnu emacs 18.55 Has anyone had any luck installing version 18.55 of gnu emacs on a 3130? With almost no problems I was able to compile and lint it, but upon trying to execute it I am rewarded with a core dump. Any hints would be appreciated. Jim Diamond zsd@pig.drea.dnd.ca P.S. I used s-iris3-6.h and m-sgi3000.h in config.h.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04233; 12 Dec 89 14:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00825; 12 Dec 89 13:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ah00373; 12 Dec 89 13:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19731; 12 Dec 89 11:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA25578; Tue, 12 Dec 89 08:42:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 89 16:40:21 GMT From: Bevis Y W Ip Subject: Console lock-up Message-Id: <1989Dec12.114021.26174@me.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Our 4D, running 3.1C, console will lock-up for good once a while when people previewing (possibly bad) PostScript files, the only good way that I can suggest to people is to kill -HUP the news_server. Is there any other good alternative? Thanks in advance. bevis   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00949; 13 Dec 89 12:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00088; 13 Dec 89 12:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac14175; 13 Dec 89 10:35 EST Received: from REMOTE.DCCS.UPENN.EDU by SMOKE.BRL.MIL id aa03642; 12 Dec 89 22:50 EST Return-Path: Received: from A.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA27210; Tue, 12 Dec 89 22:51:15 -0500 Message-Id: <8912130351.AA27210@remote.dccs.upenn.edu> Date: Tue, 12 Dec 89 22:50 EST From: "YATES, JOHN H." Subject: vax win/tcp -> sgi session lockup To: info-iris@BRL.MIL X-Vms-To: INFOIRIS,YATES I telnet to sgi machines (IRIX 3.2) from a vax (VMS 4.5) running win/tcp (3.2) software. A SEVERE problem is WHATEVER I map to intr causes an irrecoverable lockup of win/tcp. The only thing I can do is log into another port on the vax and kill the process to free things up. Here is my current stty line in .login. stty line 1 erase '^H' kill '^U' intr '^C' echoe ^^^^^^^^^ the problem Has anybody seen/solved this annoying problem? Please reply directly to me, I requested a subscription last week, but nothing has come through yet. Thanks, John yates@a.chem.upenn.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01511; 13 Dec 89 12:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00088; 13 Dec 89 12:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14175; 13 Dec 89 10:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02024; 12 Dec 89 20:26 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29263; Tue, 12 Dec 89 17:22:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Dec 89 01:05:06 GMT From: Deb Ryan Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SIGFPE Message-Id: <46227@sgi.sgi.com> References: <8912111534.AA25453@prism.gatech.edu>, <624@chem.ucsd.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <624@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes: > With 3.2 floating point exceptions are ignored, with NaN's and Infinity's > propagated through floating point exceptions, presumably according to > IEEE rules. I happen to prefer that all exceptions result in SIGFPE > being raised, so that a process stops right away and either aborts > or calls a signal()-specified error handler. > > How can I achieve this? > -- > > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu You two choices: 1. Wait for the trap handler, comming out in the aspen release. This will make it easy to core dump, or do anything your heart can code in a subroutine . 2. If all you really want to do is coredump, this Fortran callable C routine will show you what to do. signal (2) will also allow you to specify your own handler, but you will be pretty limited without information about the exception. ----------------------------------cut here ------------------------------------- #include #include #include /* this code uses information from the manpages fpc(3c) and signal(2) set_traps is a fortran callable subroutine which will enable foating point exceptions, and coredump upon recieving one */ set_traps_() { union fpc_csr fpstat; /* enable the floating point traps */ fpstat.fc_word = get_fpc_csr(); fpstat.fc_word |= (FPCSR_ENABLES | FPCSR_EXCEPTIONS); set_fpc_csr (fpstat.fc_word); /* abort upon recieving floating point trap */ signal (SIGFPE, SIG_DFL); } /* test routine for set_traps */ main() { float zero=0.0; float one=1.0; float result; set_traps_(); /* divide by zero */ printf( "\n\ndividing by zero:\n"); result = one/zero; printf("one/zero yields %e\n",result); } -- -Deb deb@sgi.com Deborah Ryan Caruso @ Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12085; 14 Dec 89 7:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11817; 14 Dec 89 7:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11779; 14 Dec 89 6:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02332; 14 Dec 89 6:41 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26912; Thu, 14 Dec 89 03:33: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: 13 Dec 89 01:50:58 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Stupid NeWS question Message-Id: <1950@odin.SGI.COM> References: <8912090118.aa28627@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912090118.aa28627@VMB.BRL.MIL>, butler@BRL.MIL ("Lee A. Butler", VLD/VMB) writes: > Can anyone tell me why the NeWS/4sight cursor is sometimes red and sometimes > black? I know it's not due to a colormap change. > > Lee It's because somebody changed the cursor colormap. The X server likes a black server. Sometimes things happen that stop it setting the color back to red. -- 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 aa12295; 14 Dec 89 7:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11817; 14 Dec 89 7:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab11779; 14 Dec 89 6:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02346; 14 Dec 89 6:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA26935; Thu, 14 Dec 89 03:33: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: 13 Dec 89 02:48:25 GMT From: Jack Weldon Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: YP Between SGI and SUN (FYI) Message-Id: <1952@odin.SGI.COM> References: <1989Dec7.190143.25284@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Dec7.190143.25284@world.std.com> spike@world.std.com (Joe Ilacqua) writes: > > I just made our new 4D/25 (running 3.2.1) a YP client of a SUN >(3/60, SUNOS 4.0.3). You need to merge the SUN & SGI versions of >/etc/services, /etc/rpc, and /etc/protocols. Once you make these >changes it works fine. > > One annoying thing does crop up however. We have two YP >domains on the same net, and the SGI's rpc.bootparamd will respond to >"Who_am_i" requests from machines in the other YP domain. The SGI >tells the machine making the request that it is in the same domain as >the SGI. The machines the SGI responds to are not in the bootparams >map or /etc/bootparams. I don't know a lot about the protocol, but is >suspect this is a bug. To work around, comment out the rpc.bootparamd >line in /usr/etc/inetd.conf. >-- I appologize if this has gone out twice--the first was posted 2 days ago and never showed up...We are in agreement here. Bootparamd should not answer "who_am_i" requests if the machine calling isn't in the /etc/bootparams file on the SGI. Engineering has fixed the bug and made it available to Product Support. I have installed the patched rpc.bootparamd.Z (in compressed format) on sgi.sgi.com (192.26.61.106--login: anonymous, passwd: guest) in the directory sgi/src. Don't forget to set mode to "binary" before transferring, and then uncompress the .Z file. The patch will be put into the next possible maintenence or full release. Thanks for the info!! Jack P. Weldon System Engineer--Product Support Engineering   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00949; 13 Dec 89 12:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00088; 13 Dec 89 12:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14278; 13 Dec 89 10:36 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa04811; 13 Dec 89 0:45 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0076; Wed, 13 Dec 89 00:44:31 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 13 Dec 89 06:42:14 Date: Wed, 13 Dec 89 06:40:55 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: External SCSI-Adapter on PI and HU-XSCSI To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8912130045.aa04811@SMOKE.BRL.MIL> Hallo, some mails ago a very helpful person from SGI answered to my question concerning the external SCSI connectors at the PI and the HU-XSCSI that they are identical. That was a very precious information for me. Thank you very much. If you want to increase my debts even more, could you please also answer the second (or was it first) part of my original question: what kind of connector is used? 50-pin-3row-female-d-type, 50-or-more-pin-centronics-like or others? As I have neither a PI nor the HU-XSCSI (which I ordered) at hand to look at the connector, this information would be great to obtain the correct external cable for my brand new disc-box. I probably will also need the pin assignment (just to be sure both sides have the same idea of SCSI cabling), but only if it isn't to much trouble for you to put it into the computer. Many thanks in advance Martin Knoblauch   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05351; 13 Dec 89 15:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04901; 13 Dec 89 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04760; 13 Dec 89 15:08 EST Received: from santra.hut.fi by SMOKE.BRL.MIL id aa18949; 13 Dec 89 14:22 EST Received: from vtt.fi by santra.hut.fi (5.61++/7.0/TeKoLa) id AA07631; Wed, 13 Dec 89 21:10:34 +0200 Received: by vtt.fi; id AA01176.R2.6; Wed, 13 Dec 89 21:10:00+0300 Received: by geeni.bio.vtt.fi (5.52/1.1.geeni) id AA11071; Wed, 13 Dec 89 11:05:13 GMT Date: Wed, 13 Dec 89 11:05:13 GMT From: Leif Laaksonen Message-Id: <8912131105.AA11071@geeni.bio.vtt.fi> To: info-iris@BRL.MIL Hopefully somebody from SGI is on the line. If not I appologize for wasting the network (and your time). I wonder if I'm the only one who starts to be fed up with the way SGI handles things abroad and Finland in particularly. I know the market in Finland is small (negligible in fact) but has SGI any interest in this area? Some examples: 1) If I order anything from SGI (= local SGI representative) it takes over 3 MONTHS to be delivered. That applies to everything systems, disks ... 3 months is quite much if you need a disk or some more memory now. 2) Our 4D/70GTB was out of order for over a month because the people who should take care of the system did NOT get a replace board from US or Sweden to it in 2 weeks and not to comment the other 2 weeks. If one has a service contract on the machine SGI should be able within one week (few days) to repare or replace the broken parts. 3) No information about new SGI equipment and software tools is distributed automaticly to the customers. How about the catalog "Iris software exchange". I have no. 1 summer 1988 but I have not received anything since that. Is that catalog still published? When I ask local people they say that they don't receive anything from SGI. When I phone Sweden they promise to mail me something but nothing happens. I get quite much information from HP, Sun, IBM, ... but not from SGI. (We don't have any hardware from HP, Sun or IBM). 4) I have been able to read about IRIX 3.2 in this network list already for some time but not until one week ago I got a letter from the local supplier about the new release. Ok, I can accept that but they want to charge me about $2000 for the upgrade to IRIX 3.2 and that is quite much I think. Is there any way we in Finland could be regarded as human beings trying to do our work? As it is now I will really next time we buy some graphics equipment think twice about what we really are buing. Please tell me how other small countries (small markets) have solved this problem. - Leif Laaksonen Ps. Our new disk does still not work. Everything goes nice some time after a reboot but after some time we start to get the following error (warning?) messages: Dec 11 18:43:54 geeni ips0d1: timeout. bn=29942 cmd=0x81 csr=0x4080 (command still in progress) Dec 11 18:43:54 geeni ips0d1: timeout. bn=2416 cmd=0x81 csr=0x4080 (command still in progress) Dec 11 18:43:54 geeni ips0d1: timeout. bn=2438 cmd=0x81 csr=0x4080 (command still in progress) -- **************************************************************************** Leif Laaksonen I "Is not life a hundred times too Phone: 358-0-4565105 I short for us to bore ourselves?" Fax: 358-0-4552028 I I F. Nietzsche Mail: laaksone@geeni.bio.vtt.fi I laaksone@finfun I ****************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06509; 13 Dec 89 16:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06102; 13 Dec 89 16:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06086; 13 Dec 89 16:12 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa22192; 13 Dec 89 15:52 EST Received: Wed, 13 Dec 89 12:53:06 -0800 from [128.156.1.21] by prandtl.nas.nasa.gov (5.61/1.2) Received: Wed, 13 Dec 89 15:53:30 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Wed, 13 Dec 89 16:41:05 EST by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Wed, 13 Dec 89 16:41:05 EST From: Tony Facca Message-Id: <8912132141.AA22471@lerc08.lerc.nasa.gov> To: YATES@a.chem.upenn.edu Subject: Re: vax win/tcp -> sgi session lockup Cc: info-iris%brl.mil@prandtl.nas.nasa.gov "YATES, JOHN H." writes: > I telnet to sgi machines (IRIX 3.2) from a vax (VMS 4.5) running > win/tcp (3.2) software. > > A SEVERE problem is WHATEVER I map to intr causes > an irrecoverable lockup of win/tcp. The only thing I can do > is log into another port on the vax and kill the process to > free things up. Here is my current stty line in .login. > > stty line 1 erase '^H' kill '^U' intr '^C' echoe > ^^^^^^^^^ > the problem > > Has anybody seen/solved this annoying problem? > Please reply directly to me, I requested a subscription last > week, but nothing has come through yet. I had never seen it before, as I usually telnet to the VAX from an SGI machine. However, to see if I could reproduce what you have done, I did an rlogin to VMS 5.1-1, then telnet'ed to IRIX 3.2 -- Anytime I did an intr (no matter what key I mapped it to) telnet locked up. I also tried telnet'ing to IRIX 3.1D and the same thing happened. I can't tell what version of WIN/TCP we are running on the VAX (I think its 5.0?) Have you tried anything with the -o option on the WIN/TCP telnet command? The manual says you can set the remote interrupt to something other than ^C, or override this by using a "big number" as the parameter. I couldn't figure this out easily. Also, if I first rlogin to the VAX then telnet back to the SGI machine, I can use the tilde-period (~.) abort sequence which also kills the VAX process. Just thought I'd let you know that Wollongong hasn't singled you out. I would think that a problem of this nature is probably something we are doing and not a bug in their software. Let me know if you hear anything more. Tony. -- ----------------------------------------------------------------------------- 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 aa07706; 13 Dec 89 18:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07474; 13 Dec 89 17:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07448; 13 Dec 89 17:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24053; 13 Dec 89 17:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13302; Wed, 13 Dec 89 14:20:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Dec 89 22:18:02 GMT From: tjh@cs.bu.edu Organization: Boston Univ. Computer Graphics Lab Subject: writing frontbuffer to backbuffer Message-Id: <44586@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a way to write directly from the frontbuffer to the backbuffer or the zbuffer? That is without doing a rectread and then a rectwrite. -Tim tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08596; 13 Dec 89 21:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08415; 13 Dec 89 20:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08408; 13 Dec 89 20:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26135; 13 Dec 89 20:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA23583; Wed, 13 Dec 89 16:57: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: 14 Dec 89 00:40:50 GMT From: Viktor Dukhovni Subject: Compiler void support under 3.2 Message-Id: <12190@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The following code is incorrectly rejected by the C compiler under 3.2 ------------------------- void foo() { } ; void bar() { } ; void (*z)() ; main() { z = bar ; z = (1==1) ? foo : bar ; } --------------------------------- Note that z=bar is ok, but the almost equivalent line below which should set z=foo is not. It appears the cc forgets the types of the arguments of ?: I ran into this when porting Perl (which noticed this during configure and reported incorrect handling of void function pointers.), and when porting RCS, which bombed (the configuration does not provide for broken compilers) -- Viktor Dukhovni : ARPA <...!uunet!princeton!math!viktor> : UUCP Fine Hall, Washington Rd., Princeton, NJ 08544 : US-Post +1-(609)-258-5792 : VOICE   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16348; 14 Dec 89 9:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15629; 14 Dec 89 9:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15568; 14 Dec 89 9:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06291; 14 Dec 89 9:26 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA07798; Thu, 14 Dec 89 06:23: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: 13 Dec 89 23:27:44 GMT From: Stephen Kirby Organization: Mincom, Brisbane, Australia Subject: Re: SIGFPE Message-Id: <289@mincom.OZ> References: <8912111534.AA25453@prism.gatech.edu>, <624@chem.ucsd.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <624@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes: > With 3.2 floating point exceptions are ignored, with NaN's and Infinity's > propagated through floating point exceptions, presumably according to > IEEE rules. I happen to prefer that all exceptions result in SIGFPE > being raised, so that a process stops right away and either aborts > or calls a signal()-specified error handler. > > How can I achieve this? > || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu I wish to support this request. We are attempting to develop commercial software, and are very worried that our programs don't crash during debugging when divide by zero's occur. || Stephen Kirby, MINCOM   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12145; 14 Dec 89 7:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac11817; 14 Dec 89 7:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac11779; 14 Dec 89 6:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02349; 14 Dec 89 6:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA27006; Thu, 14 Dec 89 03:34:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 10:03:43 GMT From: "What a waste it is to lose one's mind." Organization: University of Kansas Academic Computing Services Subject: any advice for SGI novice? Message-Id: <19777@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am currently in the market for a 4D/25 and am trying to decide exactly how to configure it. My priorities seem to be a bit different from most SGI users: the unit will be used primarily to develop hydrodynamic models (in Fortran), which mostly will be run on Crays. The SGI will be used to execute test jobs and perhaps some of the smaller production runs. So my main interests are adherence to the Fortran-77 standard and floating-point performance, with graphics as a *secondary* consideration. I would also like to use the SGI for analysis of the model results. The final product must be suitable for publication in professional journals. At present I plan to use a version of the NCAR graphics package available from a third-party vendor. This mostly generates simple line drawings: contour plots, vector fields, etc. A PostScript driver can be used to produce hardcopy on an Apple LaserWriter, etc. Eventually I may replace the NCAR graphics package with a more sophisticated graphics program. The main question is whether to get the 24-bit or 8-bit color graphics. The 24-bit color costs extra money, which perhaps could be better spent on more memory, disk capacity, or whatever. The hardcopy output will be in black and white. I can't afford a color hardcopy device, and besides, the journals charge $1000 or more per page to print color illustrations. Therefore it is difficult to see the need for 256 colors, much less 17 million. By getting the 8-bit graphics instead of 24-bit, would I lose anything other than a lot of superfluous colors? Fast and flexible graphics manipulations on the tube are nice, *but must be reproducible in hardcopy to be of real value for my purposes*. Thanks in advance for whatever advice you can offer. Ray Arritt Dept. of Physics and Astronomy Univ. of Kansas arritt@ukanvax.bitnet arritt@kuhub.cc.ukans.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19140; 14 Dec 89 12:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18734; 14 Dec 89 12:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18643; 14 Dec 89 11:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10689; 14 Dec 89 11:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14330; Thu, 14 Dec 89 08:17:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 15:38:40 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: Sound on PI Message-Id: <606@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi Netlanders, This is the response to my posting a while back on sound software for the PI. I had also made a posting to rec.music.synth asking about references to sound generation. Subject: Sound Generation References The book "Music Through MIDI" has a couple of chapters that give a breif introduction to sound and synthesis. From: "Kevin R. Weiner" From: Dean Swan Hal Chamberlin's "Musical Applications of Microprocessors", 2nd Ed. From: pmy@jeeves.acc.Virginia.EDU (Pete Yadlowsky) "Computer Music" by Charles Dodge and Tom Jerse is a popular text. Subject: Sound on the PI From: kelaita@wk19.nas.nasa.gov (Paul G. Kelaita) Buck, We are probably at about the same stage that you are. We plan on using the PI's /dev/audio to generate sound from CFD datasets (eventually tied into a graphics interface). I got some good example programs fax'ed over from Clint Greene at SGI's hotline, and he also emailed me the enclosed specs. Also included is our first test program (it uses the mouse as input) which gave us a couple chuckles. Let us know if you find out anything new from SGI, or others. Good Luck, Paul "Pup" Kelaita **************************************************************************** PERSONAL IRIS AUDIO CHANNEL INFORMATION Line input: +/- 2.5 v (input is AC coupled) is full scale to ADC ADC is 8-bit, 2's complement Input impedance is 22K ohms. Input gains not adjustable. Frequency response: 20 Hz - 13 KHz @ 32K/sec sampling rate 20 Hz - 6.6 KHz @ 16K/sec sampling rate 20 Hz - 3.3 KHz @ 8K/sec sampling rate Microphone input: +/- 3.8 mv (input is AC coupled) is full scale to ADC ADC is 8-bit, 2's complement Input impedance 330 ohms. Designed for use with 300 ohm microphone. Input is summed (analog) with line input. Output: With full output gain (0xff) and no load, output swings +/- 4.9 v. Reduced output gain linearly reduces swing. Output is AC coupled (~4 ohms in series with 220 uf). Can directly drive 8 ohm speaker. -- | | | ||| Clint Greene ||| | | | | | | | | ||| Silicon Graphics ||| | | | | | | | | | | | | ||| - - - - - - - ||| | | | | | | | | | | | | | ||| clint@sgi.com ||| | | | | | | | | ||| (415)335-1394 ||| | | | **************************************************************************** #include #include #include #include #include #define PI 3.1415926 #define FREQ 90. #define MAXFREQ 4096. #define RES 1024 main() { unsigned char buffer[RES]; int i, sound; float deg, max_theta, freq; if ((sound = open("/dev/audio", 2)) < 0) { printf ("cant open\n"); exit(1); } /* set audio duration, rate, gain */ ioctl(sound, AUDIOCDURATION, 5); ioctl(sound, AUDIOCSETRATE, 2); ioctl(sound, AUDIOCSETOUTGAIN, 255); while(1) { freq = (float)getvaluator(MOUSEY) / 1024. * MAXFREQ; max_theta = freq * 360.; for (i = 1; i <= RES; i++) { deg = max_theta * (float)i / (float)RES; buffer[i] = ((sin(deg * PI / 180.) * .5) + .5) * 255.0; } write(sound, buffer, RES); } } **************************************************************************** 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 aa19827; 14 Dec 89 13:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19528; 14 Dec 89 13:15 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa19525; 14 Dec 89 13:03 EST Received: from cunyvm.cuny.edu by ADM.BRL.MIL id aa29206; 14 Dec 89 12:55 EST Received: from ASUACAD.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6456; Thu, 14 Dec 89 12:54:00 EDT Received: by ASUACAD (Mailer R2.03B) id 0921; Thu, 14 Dec 89 10:54:20 MST Date: Thu, 14 Dec 89 10:52:07 MST From: Jim Howard Subject: Columbia Appletalk Package To: Info-Iris mailing list Message-ID: <8912141255.aa29206@ADM.BRL.MIL> Has anyone succesfully installed the Columbia Appletalk Package on a 4D series Iris? The package allows Mac users to view the Unix system as a file server and the Iris user the Laserwriters as Unix printers (via a Kinetics box).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20170; 14 Dec 89 13:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19960; 14 Dec 89 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19884; 14 Dec 89 13:31 EST Received: from [46.1.0.20] by SMOKE.BRL.MIL id aa13568; 14 Dec 89 13:09 EST From: phil morris Subject: g++ on an Iris To: info-iris@BRL.MIL Date: Thu, 14 Dec 89 10:00:16 PDT Mail-System-Version: Message-ID: <8912141309.aa13568@SMOKE.BRL.MIL> Hi all, Has anyone successfully put GNU G++ onto an Iris? I can create it, get the library made, but then the g++ test suite passes a few, but miserably fails the rest. Phil -------- Phil Morris (pmorris@dgi0.bbn.com) Disclaimer: ME? I'm only a non-smoking cat; can't believe a word I meow.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20170; 14 Dec 89 13:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19960; 14 Dec 89 13:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19886; 14 Dec 89 13:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13601; 14 Dec 89 13:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA20643; Thu, 14 Dec 89 10:02: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: 14 Dec 89 17:37:32 GMT From: Don Preuss Organization: National Institutes of Health Subject: Convert from PICT/TIFF to imagelib Message-Id: <1281@nih-csl.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We've gotten in some new SG 4D/XX systems running 3.2. We got a few faces scanned in at the local SGI office, but we'd like to do it ourselves. Also, it would be nice to scan the images in off a Mac and then pass them over to the SG. We've seen imaged, and "repaired" a few pictures, but it doesn't have an import feature. Is such a program already written? AdThanksVance donp -- donp@niaid.nih.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20558; 14 Dec 89 14:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac20170; 14 Dec 89 14:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20124; 14 Dec 89 13:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14628; 14 Dec 89 13:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22600; Thu, 14 Dec 89 10:31:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 17:15:29 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: writing frontbuffer to backbuffer Message-Id: <46342@sgi.sgi.com> References: <44586@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <44586@bu-cs.BU.EDU>, tjh@bu-pub.bu.edu writes: > Is there a way to write directly from the frontbuffer to the backbuffer > or the zbuffer? That is without doing a rectread and then a rectwrite. > > -Tim > tjh@bu-pub.bu.edu Rectcopy does a framebuffer to framebuffer copy without the host cpu getting too involved. the command readsource() specifies where to get the pixels from and frontbuffer(),backbuffer(), zdraw() specify where to put the pixels. You can also zoom the pixels on certain machines. Check the rectcopy man page for details... -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21019; 14 Dec 89 14:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20558; 14 Dec 89 14:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20299; 14 Dec 89 14:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14698; 14 Dec 89 13:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22608; Thu, 14 Dec 89 10:31:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 17:59:54 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: External SCSI-Adapter on PI and HU-XSCSI Message-Id: <46343@sgi.sgi.com> References: <8912130045.aa04811@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912130045.aa04811@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > please also answer the second (or was it first) part of my original > question: what kind of connector is used? 50-pin-3row-female-d-type, > 50-or-more-pin-centronics-like or others? As I have neither a PI nor > > Many thanks in advance > Martin Knoblauch > It is a 50 conductor `champ' or Centronics-style connector, female. SGI also sells an external cable, although such cables can usually be obtained from your local computer supply store. 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 aa21269; 14 Dec 89 14:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21019; 14 Dec 89 14:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20675; 14 Dec 89 14:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15035; 14 Dec 89 13:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA23724; Thu, 14 Dec 89 10:47:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 16:53:25 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: sound possibilities for the future? Message-Id: <3146@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Are there plans to include the PI's audio features on other machines than just the PI's? I think it would be real nice to see it on the larger units where all of our work is done and would tie in nicely to the graphics and computations we need to run on the larger machines. Tom Rohling trohling@uceng.uc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21810; 14 Dec 89 15:31 EST Received: by VMB.BRL.MIL id ab21549; 14 Dec 89 15:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17481; 14 Dec 89 10:49 EST Received: from vgr.brl.mil by VMB.BRL.MIL id aa14205; 14 Dec 89 8:36 EST Date: Thu, 14 Dec 89 8:34:13 EST From: Doug Gwyn (VLD/VMB) To: support@BRL.MIL cc: stay@BRL.MIL, moss@BRL.MIL, shenry@BRL.MIL Subject: Irix 3.2 (4D) ldexp() function broken Message-ID: <8912140834.aa03045@VGR.BRL.MIL> Resent-Date: Thu, 14 Dec 89 10:37:23 EST Resent-From: moss@BRL.MIL Resent-To: info-iris@BRL.MIL $ cat > foo.c #include #include main() { printf( "%g\n", ldexp( 0.0, 0 ) ); return 0; } ^D $ cc -o foo foo.c ./foo $ ./foo 1.11254e-308 $ # answer should be "0"; works properly on all other BRL UNIX systems $ # I think the problem is that they're treating true-0 as a denormalized $ # number and "rounding" it. This is RONG.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23456; 14 Dec 89 17:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22960; 14 Dec 89 16:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22837; 14 Dec 89 16:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19478; 14 Dec 89 16:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA03102; Thu, 14 Dec 89 13:06:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 20:58:21 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: FREE Color Separation Software!!!! Message-Id: <46354@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have softwre tools that may be used on IRIS 4D workstations to transform RGB images into color separations for 4 color printing. If you would like a copy of this software to use on your IRIS, please mail me a 1/4" streaming tape. Paul Haeberli Silicon Graphics Inc. 2011 North Shoreline Blvd Mountain View, CA 94039 415-962-3665 paul@sgi.com Here's a description of how the process works. . . . Creating digital color separations on the IRIS. Version 0.5 Paul Haeberli Silicon Graphics Inc. This document describes the process we've been using to convert RGB images to film for 4 color printing. We've been using this software for about 3 years now for internal publications and have processed aver 100 images. We assume you have a 4D workstation that has the ability to display images in RGB mode. Here's a brief overview of the process: 1. Calibrate your monitor. 2. Gamma correct the image to look right on your calibrated monitor. 3. Increase the contrast of the image if it needs it. 4. Decide whether you need to do apply color correction to the image. Possibly correct the image. 5. Color correct your image for printing. 6. The CT2T tape data is plotted at a constant 300 pixels per inch, so we have to scale the image to the size we want it printed 7. If this looks good, Write out the CT2T tape. 8. Contact your printer and find out some specific information about what kind of negatives they'll need. 9. Package the tape, and some other info and send this to Kedie/Orent in Sunnyvale, CA. 10. Get the film and a Chromalin(TM) proof back from Kedie/Orent and Give the film to your printer. And here's the gory detail: 1. Calibrate your monitor. For this process to work as expected, you must start out by calibrating your monitor. This is very easy to do on your IRIS. Run the program "gamcal". Make it cover about one quarter of the area of the screen. This program displays a gamma calibration test pattern. Now run the command "gamma 2.4". This sets the monitor gamma to 2.4. Now adjust your brightness and contrast controls until you can see the shade of the pattern smoothly taper off to black on the left. You should also notice that on the left side of the pattern, the average brightness of the boxes with horizontal stripes would be about the same as the solid boxes in the same column. If things look confusing, you may want to try another machine with a different monitor. I've included a printed sample image with the software tape. To see what this images looked like on the screen do: ipaste images/sample.rgb This shows the current state of the color calibration between a screen image and a print image. 2. Gamma correct your image. Now display your image using "ipaste". If your image is in a foreign file format you may be able to convert it into an IRIS image with some of the tools found in /usr/people/4Dgifts/iristools/imgtools. Check to see if the midtones of the image look too dark or too light. If you want to darken the image, use commands like: gammawarp mypic.rgb dark.rgb 1.5 ipaste dark.rgb If you want to lighten the image, use commands like: gammawarp mypic.rgb light.rgb 0.7 ipaste light.rgb The numeric argument is a power to raise the pixel values to. Values greater than 1.0 will darken the image, while values less than 1.0 will lighten the image. 3. Increase the contrast of the image if it needs it. Use the program "hist" to display a histogram of the image. This shows the distribution of pixel values in the image. Check to see where the distribution tapers off to zero near the right side. If this is much less than 255, then we can easily scale the image intensities using "imgexp" Run imgexp like this: imgexp mypic.rgb bright.rgb 0 205 ipaste bright.rgb This would rescale the pixel values so that what used to be displayed as 205 now will be full brightness. 4. Decide whether to apply color correction Try creating a soft proof of your image as is, without any color correction. To do this run: sproof mypic.rgb sproof.rgb ipaste sproof.rgb If this looks all right, and you don't mind the color shifts, then skip step 5, and zoom mypic.rgb in step 6. 5. Try color correcting your image. Use the program "corimg" to transform the colors so that when these colors are printed, the final print will closely match the colors of your original. This is only possible if your image only uses printable colors. To see what the printable colors look like on the screen do: ipaste images/printable.rgb Any color in this image, and any color that is darker, can be printed accurately with the 4 color process inks. If your original steps outside the color gamut of the 4 color process, "corimg" desaturates these colors by adding white. Since these processes are fairly slow, you may want to use "izoom" to make a smaller copy of your image to practice on. Try this sequence of steps: corimg mypic.rgb cor.rgb sproof cor.rgb corsp.rgb ipaste corsp.rgb 6. Resize the corrected image to make it print at 300 pixels per inch. When the CT2T tape transferred to film, it is plotted plotted with a resolution of exactly 300.00 pixels per inch in the X direction, and exactly 304.80 pixels per inch in the Y direction. This means that if you put an image on the tape that has 1536 pixels on each scan line, and 2014 scanlines, the printed size will be exactly 5.12000 inches by 6.60761 inches. So now you have to consider exactly how big you want the image printed, and resize the image to that size. If you came from step 4 above, resize mypic.rgb, otherwise resize cor.rgb from step 5. Resize the image like this izoom cor.rgb bigcor.rgb 23.34 23.34 7. Write out the CT2T tape. If you have an IRIS workstation with a 1/2 inch tape drive then put a tape in the drive, put it on line, and use a command like this to write the tape directly: toscitex -o /dev/rmt/xmt0d0nr.6250 bigcor.rgb This will transfer the image to the tape. A white border of 0.2 inches (60 pixels on each side) is added to the image as it is written to the tape. This border will make it easier for the printer to use the film. The program "toscitex" will write out a text file called "tapelog" in the current directory. Attach a listing of this file to the tape when you send it out. If you don't have a 1/2 inch tape drive connected to your IRIS workstation, you can use the program "toscitex" to write out a CMYK dump file, which can be transferred to tape on another machine. To do this use a command like toscitex -o out.ct2t bigcor.rgb Copy the file "out.ct2t" to the machine with the tape drive. Now use the unix program "dd" to transfer the image to the tape at 1600 or 6250 bpi. Look at the log file and get the xsize, and the ysize of the image. The number of scanlines is given by ysize. The number of pixels on each scanline is given by xsize. There are 4 bytes in each pixel, one for each C, M, Y, and B, so the number of bytes in each scanline in 4 times the xsize. Transfer the file out.ct2t to the tape using dd to write one tape block of data for each scanline in the image. For an image that is 720 by 400 (after adding the 60 pixel border) the dd command would look like this. dd if=out.ct2t of=/dev/rmt bs=2880 8. Now you must get this information from your printer: 1. The highest density of the halftone screen they can print. The preferred one is a 175 line screen. 150 line is ok. 2. Does the printer want right or wrong reading negatives. Most printers want right reading negs. 3. Does the printer want emulsion side up or emulsion side down? Most times they will want emulsion side down. 9. Create the package for Kedie/Orent Call Kedie/Orent and tell them that you would like to get a CT2T tape plotted to film. Arrange to send them the tape. You may want to agree with them on the price for this service. Here is a brief price list: Up to 4" x 5" $ 90.00 Up to 5" x 7" $120.00 Up to 8" x 10" $145.00 Up to 11" x 14" $240.00 Up to 12" x 18" $300.00 Up to 14" x 17" $335.00 . . . Up to 30" x 40" $1200.00 Put in a note saying you want the enclosed ct2t tape plotted to film. Describe the requirements of the printer with language like: "Please plot this tape with 175 line screen We want right reading negatives. We want emulsion side down." Send the tape to Kedie/Orent. The turn around should be about 3 working days. Kedie/Orent 744 San Aleso Ave Sunnyvale, CA 94086 1-408-734-9005 10. Get the tape, film, and a Chromalin(TM) proof back. If it looks good then give it to your printer.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24072; 14 Dec 89 18:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23791; 14 Dec 89 17:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23743; 14 Dec 89 17:43 EST Received: from uxe.cso.uiuc.edu by SMOKE.BRL.MIL id aa20818; 14 Dec 89 17:30 EST Received: by uxe.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA06853; Thu, 14 Dec 89 16:30:05 -0600 Date: Thu, 14 Dec 89 16:30:05 -0600 From: Amy Swanson Message-Id: <8912142230.AA06853@uxe.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: ethernet version 1 or 2 Cc: sgi@theimprov.ncsa.uiuc.edu Is there a way to tell which version of ethernet (Ethernet v.1 or v.2) your PI or Power Series machines are running? We are currently experiencing severe network problems orginating from our SGIs which we suspect are due to an incompatibility of the SGIs with the SQE (heartbeat) enabled/disabled on the ethernet transceivers. Thanks, Amy Amy Swanson SGI/Alliant Systems Administrator NCSA - National Center for Supercomputing Applications University of Illinois @ Urbana-Champaign amys@ncsa.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24384; 14 Dec 89 19:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24252; 14 Dec 89 18:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24237; 14 Dec 89 18:37 EST Received: from ucsd.edu by SMOKE.BRL.MIL id aa21599; 14 Dec 89 18:24 EST Received: from chema.ucsd.edu by ucsd.edu; id AA07113 sendmail 5.61/UCSD-2.0-sun via SMTP Thu, 14 Dec 89 15:23:25 -0800 for info-iris@BRL.MIL Received: by chem.chem.ucsd.edu (5.51) id AA25307; Thu, 14 Dec 89 15:22:59 PST Date: Thu, 14 Dec 89 15:22:59 PST From: Steve Dempsey Message-Id: <8912142322.AA25307@chem.chem.ucsd.edu> To: info-iris@BRL.MIL Subject: Re: sound possibilities for the future? In keeping with the spirit of things, the high end 4D's should have DOLBY multi-channel surround sound capabilities. After all, a machine capable of sophisticated 3D video imaging ought to support 3D AUDIO imaging as well. The first application could be a simulation of sonic booms in dogfight! Marketing types should love this. Imagine being able to claim to have the first workstation with a sub-woofer output. :-) -------------------------------------------------------------------------------- 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 aa15654; 17 Dec 89 1:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15597; 17 Dec 89 0:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15579; 17 Dec 89 0:38 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21802; 17 Dec 89 0:26 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10339; Sat, 16 Dec 89 21:17:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 89 17:24:55 GMT From: "Gavin A. Bell" Subject: Re: writing frontbuffer to backbuffer Message-Id: <1988@odin.SGI.COM> References: <44586@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL tjh@bu-pub.bu.edu writes: >Is there a way to write directly from the frontbuffer to the backbuffer >or the zbuffer? That is without doing a rectread and then a rectwrite. >-Tim tjh@bu-pub.bu.edu Sure, use the rectcopy command. See the man page for more info, but you should do something like: readsource(SRC_FRONT); backbuffer(TRUE); /* Use zbuffer(TRUE) if you want to write to z */ rectcopy(args here); --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02310; 15 Dec 89 9:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00357; 15 Dec 89 7:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00246; 15 Dec 89 7:38 EST Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa01144; 15 Dec 89 7:34 EST Received: Fri, 15 Dec 89 07:33:54 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 15 Dec 89 07:33:54 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8912151533.AA12586@aero4.larc.nasa.gov> To: sd%chem@ucsd.edu Subject: Re: sound possibilities for the future? Cc: info-iris@BRL.MIL Don't forget the stereo graphics for dogfight too. -- 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 aa06807; 15 Dec 89 14:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06083; 15 Dec 89 14:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05746; 15 Dec 89 13:55 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa01497; 15 Dec 89 13:46 EST Received: from relay2.cs.net by RELAY.CS.NET id aa00529; 15 Dec 89 12:18 EST Received: from gmr.com by RELAY.CS.NET id aa07941; 15 Dec 89 13:15 EST Date: Fri, 15 Dec 89 11:26 EST From: JORDAN%gmr.com@relay.cs.net Subject: portmap To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <8912151346.aa01497@SMOKE.BRL.MIL> I have a little background process running on my machine when I do a ps -e called portmap. Did a man on it, but no data. Anybody out there in Iris Land know what it means, or what it does? I'd like to kill it if it is affecting our attempt at a real-time environment. thanx in advance for the responses t p mugabi-jordan gm - sec 1151 crooks rd troy, mi 48084 313 280 6766   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07101; 15 Dec 89 14:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06971; 15 Dec 89 14:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06863; 15 Dec 89 14:28 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa02211; 15 Dec 89 14:16 EST Received: from relay2.cs.net by RELAY.CS.NET id ad01940; 15 Dec 89 13:16 EST Received: from gmr.com by RELAY.CS.NET id ab08793; 15 Dec 89 14:15 EST Date: Fri, 15 Dec 89 13:27 EST From: JORDAN%gmr.com@relay.cs.net Subject: exportto To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <8912151417.aa02211@SMOKE.BRL.MIL> Does anyone out there know what exportto does? Also, is there anyone out there in Warsaw? Please write... Dzien Dobry! Pozdrowienia z Ameryki z Detroit! Malgorzata Kulczycka   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07101; 15 Dec 89 14:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06971; 15 Dec 89 14:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06875; 15 Dec 89 14:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02239; 15 Dec 89 14:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14812; Fri, 15 Dec 89 08:22: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: 15 Dec 89 16:04:56 GMT From: Eric Pepke Organization: Supercomputer Computations Research Institute Subject: Re: sound possibilities for the future? Message-Id: <403@fsu.scri.fsu.edu> References: <8912142322.AA25307@chem.chem.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912142322.AA25307@chem.chem.ucsd.edu> sd%chem@ucsd.edu (Steve Dempsey) writes: >In keeping with the spirit of things, the high end 4D's should have DOLBY >multi-channel surround sound capabilities. After all, a machine capable of >sophisticated 3D video imaging ought to support 3D AUDIO imaging as well. DOLBY Schmolby. Do it like this. Include a DSP which is capable of generating at least two channels of CD quality sound at 44 KHz. This should be trivial; the NeXT can do this now, and you can buy better DSP's dirt cheap. Then, allow the user to specify sound sources in the same coordinate space as the graphics. Transform these points the same way the graphics coordinates are transformed. Then, provide some hearing transformations in the same spirit as the viewing transformations perspective and ortho. The most interesting would be binaural(headwidth); where headwidth is the width of the virtual head that follows around according to lookat and friends. This would cause the DSP automatically to calculate 1) the volume based on the distance of the sound source from the head, 2) the phase difference based on the differential beween the ears, and 3) slight frequency correcions based on a simplified model of sound absorption of the ears and the rest of the head. Next, wire the sucker into a virtual reality helmet, remove all breakable objects from the room, and provide rehabilitation for the survivors. :-) Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac07101; 15 Dec 89 14:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac06971; 15 Dec 89 14:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06923; 15 Dec 89 14:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02294; 15 Dec 89 14:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13859; Fri, 15 Dec 89 08:07:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Dec 89 12:43:39 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: X-windows Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am considering buying a 4D/25-turbo, and wondered what experiences people have had with X-windows on this box (or similar boxes). I have heard that the new machines have a faster raster chip which should help the X performance noticeably.... I want to run X so that I can get more software (NCAR graphics, NCSA XDS tools) and so that I can run the same system on remote X-windows terminals (NCD). Does the 3-D graphics system run well under X? -- 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 aa07407; 15 Dec 89 15:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05560; 15 Dec 89 13:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05402; 15 Dec 89 13:39 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa00975; 15 Dec 89 13:25 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8071; Fri, 15 Dec 89 11:49:12 CST Received: by UMRVMA (Mailer R2.05) id 8070; Fri, 15 Dec 89 11:49:09 CST Date: Fri, 15 Dec 89 11:39:50 CST From: Bob Funchess Subject: Scanned files : Mac => Iris To: info-iris@BRL.MIL Message-ID: <8912151325.aa00975@SMOKE.BRL.MIL> I tried to send this to the original poster, but it bounced... There are several PD/ShareWare programs for the Mac that allow you to convert images from one format to another. Giffer and VisionLab (my personal choice) are two that come to mind. Both are available via anonymous FTP from sumex-aim.stanford.edu (36.44.0.6) in the info-mac subdirectory, poke around to find the actual files. You can use these programs to convert your scanned images to GIF format (which has the advantage of being compressed using LZW) and then transfer the to the Iris. A program fromgif was posted here some time ago. There may be a copy in the archives; if not, we will be setting up an FTP site sometime after the first of the year, and it will be there... I will make an annoucement on the net when this occurs. That gives you a RGB data file, which you can play with using ~4Dgifts. < Bob | S090726@UMRVMA.UMR.EDU | Funchess > The 'S' stands for student. Think the university shares MY opinions?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08221; 15 Dec 89 15:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07943; 15 Dec 89 15:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07939; 15 Dec 89 15:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04204; 15 Dec 89 15:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA28137; Fri, 15 Dec 89 11:59:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Dec 89 19:59:00 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time Message-Id: <89Dec15.145750est.2273@neat.cs.toronto.edu> References: <1300@uakari.primate.wisc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL bin@primate.wisc.edu (Brain in Neutral) writes: ># if mips ># if ultrix > DECstation ># else > true MIPS ># endif ># endif Not so fast. SGI also defines "mips" on the Iris4D machines -- why not, it's the CPU they use. One possible solution, seen to work on our Iris4D (Irix3.2), our DS3100s (Ultrix3.1), and our M/120 (Riscos4.0: #ifdef mips # ifdef ultrix # define ULTRIX_MIPS # define arch "ultrix-mips" # endif # ifdef sgi # define IRIS4D # define arch "iris4d" # endif # ifndef arch /* * Must be MIPSCo MIPS. Anyone know a way to differentiate between * RISCOS4.0 and UMIPS via cpp? */ # define MIPS # define arch "mips" # endif #endif Then one can use the symbols MIPS, IRIS4D, or ULTRIX_MIPS. Note: this will presumably change once vendors start shipping truly ANSI compatible compilers -- ANSI prohibits this sort of random pollution of the namespace. (It'll be __mips__ or suchlike, and life will become even more complicated, as people try to keep code backwards compatible with things like"#if defined(mips) || defined(__mips__)")) Another solution is to stick a wrapper script around cc, and get it to define the symbols you want. The shell script I use for our SGI machines is enclosed below. *Soapbox on* It is probably much better to ifdef on specific features that one needs (eg. BSD_SIGNALS, JOB_CONTROL, DIRENT, SHMEM, etc) than on a specific vendor type, considering the way the zillion and one "standard" deviants, er, variants, of Un*x are growing warts, er, features. Relying on even the vendors operating system remaining the same is probably not portable. As for the simple distinction between BSD and SYSV, that's gone a long time ago, thanks to extensive cross-breeding... Then one can create configuration headers per machine -- s-machine.h, sysdep.h, whatever, defining specific features on a per release basis, as is sometimes necessary :-( The joys of maintaining a single source tree for multiple architectures and OS deviants! *Soapbox off* #! /bin/sh - # Fake CC driver that includes local and bsd stuff and links compatibility # bsd routines. Also defines __iris4d__ and __irix__, as well # as linking in /local/lib libraries before system defaults. # Also munges output error messages from cc to BSD format, so it can # be automatically parsed by Jove. # Mark Moraes, University of Toronto realcc=/usr/bin/cc includes= args= for i do case "$i" in -I*) includes="$includes $i";; -v) set -x;; esac done includes="$includes -I/local/include -I/usr/include/bsd" tmp=/tmp/cc.bsd.$$ trap 'rm -f $tmp; exit $status' 0 $realcc -D__iris4d__ -D__irix__ $includes -L/local/lib "$@" -lbsd 2> $tmp status=$? # Postprocess errors - cc can produce stuff on stdout, for cc -M, f'rinstance sed 's/^[^:]*: \([^:]*: \)\([^,]*\), \([^:]*: \)\(.*\)/"\2", \3\1\4/' $tmp >&2   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10004; 15 Dec 89 18:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09854; 15 Dec 89 18:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac09833; 15 Dec 89 18:16 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09280; 15 Dec 89 18:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10166; Fri, 15 Dec 89 15:06: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: 15 Dec 89 19:56:06 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: disk transfer speeds Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A few weeks ago somebody from sgi said that the 4D/25 gets very good disk transfer speeds when talking to synchronous SCSI disks. I am very interested in numbers for this. I am perfectly willing to take (almost) best case results, since my application will involve coarse-grain sequential reads of binary files. So what ballpark is it going to be in? 400 kB/s? 600 kB/s? 1000 kB/s? -- 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 aa10083; 15 Dec 89 19:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10069; 15 Dec 89 19:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10059; 15 Dec 89 19:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10091; 15 Dec 89 19:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13116; Fri, 15 Dec 89 15:53: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: 15 Dec 89 23:17:56 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Irix 3.2 (4D) ldexp() function broken Message-Id: <46455@sgi.sgi.com> References: <8912140834.aa03045@VGR.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912140834.aa03045@VGR.BRL.MIL>, gwyn@BRL.MIL (Doug Gwyn, VLD/VMB) writes: [various lines deleted for brevity] > printf( "%g\n", ldexp( 0.0, 0 ) ); > $ ./foo > 1.11254e-308 > $ # answer should be "0"; works properly on all other BRL UNIX systems > $ # I think the problem is that they're treating true-0 as a denormalized > $ # number and "rounding" it. This is RONG. Doug is right on all counts. We need to fix this. Regards, [ David B. Anderson davea Bldg-9 MS 9U500 extension 1548 ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10083; 15 Dec 89 19:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10069; 15 Dec 89 19:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10061; 15 Dec 89 19:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10098; 15 Dec 89 19:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13099; Fri, 15 Dec 89 15:53:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Dec 89 23:02:59 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Compiler void support under 3.2 Message-Id: <46452@sgi.sgi.com> References: <12190@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12190@phoenix.Princeton.EDU>, viktor@rutabaga.Princeton.EDU (Viktor Dukhovni) writes: > The following code is incorrectly rejected by the C compiler under 3.2 [spacing removed for brevity] > void foo() { } ; void bar() { } ; > void (*z)() ; > main() { > z = bar ; > z = (1==1) ? foo : bar ; > } [commentary deleted for brevity] The problems with void and void * have been corrected in ccom for the release after 3.2. 3.2 was complete before I got around to fixing this. Sorry. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11217; 16 Dec 89 0:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11080; 16 Dec 89 0:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11077; 16 Dec 89 0:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13129; 15 Dec 89 23:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29897; Fri, 15 Dec 89 20:47:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Dec 89 15:34:08 GMT From: Marius Messerli Organization: Biophysics Institute ETHZ Switzerland Subject: 4DDN Message-Id: <1853@biophys.zir.ethz.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I installed 4DDN on a SGI and was very happy to see it running ... for about two hours. Then the system got unstable. Sometimes I could not even login again and had to turn off the power. In any case the SGI was not reachable from ethernet any more. The people at SG Zuerich suggest it could be a router that causes the problem while out decnet administrator thinks its not. Does anybody have heard of this problem before and has some hints to get 4DDN running ? Thanks for any help! Marius. (messerli@kontiki.zir.ethz.ch) (messerli@czheth5a.bitnet)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15213; 16 Dec 89 22:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15177; 16 Dec 89 22:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15166; 16 Dec 89 22:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21263; 16 Dec 89 22:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA04135; Sat, 16 Dec 89 19:01:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Dec 89 02:17:36 GMT From: "Steve S. Roy" Subject: Re: X-windows Message-Id: <12268@phoenix.Princeton.EDU> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Does the 3-D graphics system run well under X? The 3-D graphics system does not run at all under X. X, at this time, is purely 2-D, and an X program running on an Iris sees ordinary X. Here is something of what is going on, as I've been able to piece it together. The Iris runs its own windowing system, 4Sight, which knows nothing of X, but it does know a lot about 3-D. To run X you start a program in the background called Xsgi and then run your program that expects an X environment. Somewhere in the initialization of your program a link is made between it and the Xsgi, which then links to 4Sight. When your program wants to draw something it executes an X command, which knows nothing of 3-D, and the request goes thru Xsgi to 4Sight and gets drawn. I do not know of any way to do both X and native drawing in the same window, but one program can open two windows, one under X and one under 4Sight and do whatever is appropriate in each. Some people are working on something called PEX (Phigs Extensions to X) which is intended to allow 3-D drawing in X, and when that's available presumably you will be able to draw in 3-D, but still not with the native calls and there will probably be a perfomance hit. I have no idea of the timescale involved with this. ---------------------------------------------------------------------- Real Name: Steve Roy e-mail: ssr@acm.princeton.edu telephone: (609)258-5324 (office) Address: office: Program of Applied and Computational Mathematics Princeton University Princetion NJ 08544-1000 ----------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15724; 17 Dec 89 1:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15654; 17 Dec 89 1:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15636; 17 Dec 89 1:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21951; 17 Dec 89 0:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA11808; Sat, 16 Dec 89 21:46:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Dec 89 04:51:56 GMT From: Ned Nowotny Organization: MCC CAD Program, Austin, TX Subject: Questions about 2200, 2300, and 2400 model IRISes. Message-Id: <4833@cadillac.CAD.MCC.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I may have the opportunity to pick up a used model 2200, 2300, or 2400. However, I have a few questions. 1) Are these models still sold and/or supported by SGI? 2) What version of the SGI operating system and development tools might be available for these machines? What are the prices for a license? 3) What level of BSD UNIX support is available in the SGI OS? 4) Do I really want one of these? How cheaply should I be able to get one for the answer to be yes? For what it is worth, I am looking into these machines with a desire for a UNIX workstation with goods graphics, good performance, and a fair amount of mass storage. I would also like a decently performing X window system for portable development in addition to 4Sight and NeWS. Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX 78720 Ph: (512) 338-3715 ARPA: ned@mcc.com UUCP: ...!cs.utexas.edu!milano!cadillac!ned ------------------------------------------------------------------------------- "We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19474; 18 Dec 89 2:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19188; 18 Dec 89 1:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19186; 18 Dec 89 1:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28033; 18 Dec 89 1:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA19713; Sun, 17 Dec 89 22:08: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: 18 Dec 89 00:48:24 GMT From: Stephen Kirby Organization: Mincom, Brisbane, Australia Subject: Re: ethernet version 1 or 2 Message-Id: <294@mincom.OZ> References: <8912142230.AA06853@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912142230.AA06853@uxe.cso.uiuc.edu>, swanson@uxe.cso.uiuc.edu (Amy Swanson) writes: > > Is there a way to tell which version of ethernet (Ethernet v.1 or v.2) your > PI or Power Series machines are running? We are currently experiencing severe > network problems orginating from our SGIs which we suspect are due to an > incompatibility of the SGIs with the SQE (heartbeat) enabled/disabled on the > ethernet transceivers. > > Amy Swanson > amys@ncsa.uiuc.edu We have a IRIS 140 and our ethernet would slow then stop to the 140, if we ran on the integrated ethernet controller. We swapped to a VME controller and the ethernet has not failed. This problem only occurred on our 4 CPU 140. the PI's give no trouble. This problem occurred in IRIX 3.2 I have not tested it under IRIX 3.2.1. Stephen Kirby MINCOM   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19922; 18 Dec 89 5:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19835; 18 Dec 89 5:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19796; 18 Dec 89 4:46 EST Received: from nac.no by SMOKE.BRL.MIL id aa28844; 18 Dec 89 4:31 EST Received: from runix.runit.sintef.no by nac.no (5.61+IDA/KTH/LTH/6.0) with SMTP id AAnac20903; Mon, 18 Dec 89 10:30:16 +0100 Received: by runix.runit.sintef.no (norunix.EARN) (1.2/7.8) id AA20896; Mon, 18 Dec 89 10:29:22 +0100 Date: 18 Dec 89 10:30 +0100 From: Finn Drablos To: info-iris@BRL.MIL Message-Id: <79*finnd@vax.runit.unit.uninett> Subject: re: 4DDN Yes, we have had problems with 4DDN. But it may depend on the IRIX level. When we first installed 4DDN on our 4D/70GT, it would run for about an hour (or even less), and then everything locked up. In some cases we could log in via telnet and do a reboot, but sometimes only the reset button worked. Since then we have upgraded IRIX two times, and are running 3.1D. We still don't like to run 4DDN for any length of time, as the IRIS after some days will start to slow down, and will need a reboot. So normally we start decnet, do the file transfer, and then kill it again. Even this seems to cause problems sometimes, so just to be safe we do a reboot at some convinient time if we have been using decnet recently. So what is the problem ? We have asked the SGI office in Sweden. They said that SGI knows about the problem, but could not give any more information. So we prefer to use ftp whenever possible. It is much easier to use. The problem is that this is mainly a VAX/VMS site, and not all machines have TCP/IP. ================== 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 aa22246; 18 Dec 89 9:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21164; 18 Dec 89 8:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21147; 18 Dec 89 8:04 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa00355; 18 Dec 89 8:01 EST Received: Mon, 18 Dec 89 08:01:14 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 18 Dec 89 08:01:14 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8912181601.AA21410@aero4.larc.nasa.gov> To: samsung!cs.utexas.edu!milano!cadillac!pebbles!ned@think.com Subject: Re: Questions about 2200, 2300, and 2400 model IRISes. Cc: info-iris@BRL.MIL 1) I don't think SGI sells any of the 2000's any more. They never supported the 3000's, so I doubt they support the 2000's. 'Officially' SGI quotes hard ware support for 2000's until about Oct '91. This is from an October '88 price list schedule. 2) I think the 2000's use 3.6 OS the same as the 3000's. SGI isn't distributing 4Sight for the 3000's or earlier models. 3) The 3.6 OS is a weak mixture of System V and BSD. 4) You might want one if it is 'dirt' cheap. I depends on what you can afford. Personally, I wouldn't buy one. I am questionable about buying an old 3000, let alone a 2000. It would probably be better to buy a bottom of the line Personal Iris or if you really don't need the color graphics buy a SUN Sparc station. -- 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 aa25221; 18 Dec 89 11:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24753; 18 Dec 89 11:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24686; 18 Dec 89 10:59 EST Received: from pig.drea.dnd.ca by SMOKE.BRL.MIL id aa06240; 18 Dec 89 10:46 EST Received: Mon, 18 Dec 89 11:37:08 AST by pig.drea.dnd.ca (5.52/5.6) Date: Mon, 18 Dec 89 11:37:08 AST From: Jim Diamond Message-Id: <8912181537.AA04622@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: SCSI connector Periodically I see notes here about "the external SCSI connector" on 4D systems. We have a 4D/50 GTB which we would like to try connecting an external SCSI device to. Unfortunately, we can't find any documentation relating to the back panel ports on our machine. Can anyone provide me with enlightenment regarding where I can find this external SCSI port (if I indeed have one)? Any related info would also be greatly appreciated. Jim Diamond zsd@pig.drea.dnd.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28647; 18 Dec 89 14:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27786; 18 Dec 89 14:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27738; 18 Dec 89 13:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11046; 18 Dec 89 13:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29210; Mon, 18 Dec 89 10:39:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 18:38:37 GMT From: Mark Bradakis Organization: University of Utah Computer Science Subject: SMD controllers on 4D/240 Message-Id: <1989Dec18.113838.27875@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL First off, thanks to those who offered their assistance with the SCSI on the PI. Still having problems, but maybe someday I'll figure it out. But now I have some questions about different disks on a different machine. We have a 4D/240gtx and we are interested in putting some SMD disks on it. Does anyone have any good or bad comments about doing this? What controllers, and how much do they cost? How is the IO throughput? I imagine that a fast machine like the 240gtx should really have no trouble with several gigabytes of disk hanging off the thing. Thanks for any info, mjb. mjb@hoosier.utah.edu "If I took a rollin' wheel, rolled it ten times 'round..."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00616; 18 Dec 89 18:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00409; 18 Dec 89 18:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00325; 18 Dec 89 17:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17409; 18 Dec 89 16:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA11758; Mon, 18 Dec 89 13:38:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 21:37:25 GMT From: Thomas Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: use of SGTTY.H and stuff involving IOCTLs Message-Id: <22483@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've been trying to port a program which uses facilities of sgtty.h, namely it uses the sgttyb structure to set CBREAK mode and turn off echoing with a call to ioctl like this: ioerr = ioctl(fileno(stdin), TIOCGETP, &tty_orig); /* get std input characteristics */ ... ttybuf = tty_new = tty_orig; /* make a copy of tty control structure */ tty_new.sg_flags = (tty_new.sg_flags & ~ECHO & ~CRMOD) | CBREAK; ... ioctl(fileno(stdin), TIOCSETP, &tty_new); /* set flags */ Is there any slick way to take out this kind of incompatibility when porting to the iris4d? I can't find any reference to CBREAK mode in the FM so RTFM is so far no good. Also, repeated reference is made to requests like TIOCSET[CP] and the like, and I have no way of knowing what the correct functions are on the iris. Any hints? Thomas Russo Center for Nonlinear Dynamics, University of Texas at Austin russo@chaos.utexas.edu or phib421@utchpc.bitnet ------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00752; 18 Dec 89 18:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00700; 18 Dec 89 18:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00629; 18 Dec 89 18:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18654; 18 Dec 89 18:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA17448; Mon, 18 Dec 89 15:03:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 22:57:46 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SCSI connector Message-Id: <46568@sgi.sgi.com> References: <8912181537.AA04622@pig.drea.dnd.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912181537.AA04622@pig.drea.dnd.ca>, zsd@PIG.DREA.DND.CA (Jim Diamond) writes: > Periodically I see notes here about "the external SCSI connector" > on 4D systems. We have a 4D/50 GTB which we would like to try > connecting an external SCSI device to. > > Unfortunately, we can't find any documentation relating to the > back panel ports on our machine. Can anyone provide me with On Professional and Power Series models, with the exception of the Power Center require an XSCSI option. Your sales person should be able to help you out to determine what flavor of this you want/need. 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 aa00820; 18 Dec 89 19:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00088; 18 Dec 89 17:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00387; 18 Dec 89 16:27 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15023; 18 Dec 89 15:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA06780; Mon, 18 Dec 89 12:23:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 19:56:53 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: ethernet version 1 or 2 Message-Id: <46547@sgi.sgi.com> References: <8912142230.AA06853@uxe.cso.uiuc.edu>, <294@mincom.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912142230.AA06853@uxe.cso.uiuc.edu>, swanson@uxe.cso.uiuc.edu (Amy Swanson) writes: > > Is there a way to tell which version of ethernet (Ethernet v.1 or v.2) your >PI or Power Series machines are running? We are currently experiencing severe > network problems orginating from our SGIs which we suspect are due to an > incompatibility of the SGIs with the SQE (heartbeat) enabled/disabled on the > ethernet transceivers. > > Amy Swanson > amys@ncsa.uiuc.edu As I recall, none of our drivers care whether heartbeat or SQE is present or absent. At one time, in what seems like ancient times, I committed an error which made unexpectedly present (or was it absent?) SQE increment the transmit error count by one for each packet transmitted on the VME board. I think this error was correct by 3.2, if not before. I figured it out at the Connectathon before last. Please note that SQE/heartbeat generally does not matter. Whether it is present or absent, you will get the same number of collisions, runt packets, bad CRC's, and so forth. Recall that SQE occurs in the dead time between packets. I have heard that putting an 802.3 transceiver (and so with SQE) upstream of some multi-port mux's can make some machines unhappy. Some (or many?) mux's send the SQE to all connected machines, not just the one which just transmitted, and some computers do not like "collision detect" (which is what SQE is) coming out of the blue. I do not think IRIS's care. In article <294@mincom.OZ>, stephen@mincom.OZ (Stephen Kirby) writes: > We have a IRIS 140 and our ethernet would slow then stop to the 140, if > we ran on the integrated ethernet controller. We swapped to a VME > controller and the ethernet has not failed. This problem only occurred > on our 4 CPU 140. the PI's give no trouble. This problem occurred in > IRIX 3.2 I have not tested it under IRIX 3.2.1. > Stephen Kirby > MINCOM The current built-in ethernet hardware on the PI and the IRIS-4D 1xx is similar, based on AMD 7990's. One difference between v.1 and v.2 is in the quiesent voltage. An ethernet that is not overly healthy can make a mismatch between v.1 and v.2/802.3 between host and transciever trash packets and so forth. I think we are may still be shipping the VME board jumpered for v.1, while the PI and MP systems are now set for v.2/802.3. (sigh) Almost all of the field problems I have heard of to date have been caused by dirty ethernets. If you see "late collision" messages or non-zero error counts from `netstat -i`, your ethernet is more or less broken. The higher layer protocols are amazingly resistent to lost or damaged ethernet packets. You can loose a large fraction, and never notice anything but many complaints from the ethernet driver(s), and reduced performance. A good ethernet will have 0 (!) "Ierrs" and "Oerrs" and no more than .15 as many "Coll" as "Opkts" reported by `netstat -i`. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00820; 18 Dec 89 19:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00752; 18 Dec 89 18:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00705; 18 Dec 89 18:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18720; 18 Dec 89 18:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18578; Mon, 18 Dec 89 15:21:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 23:01:29 GMT From: James Leong Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 4DDN Message-Id: <46569@sgi.sgi.com> References: <1853@biophys.zir.ethz.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The 4DDN release level was not mentioned, but the 4DDN system hang problem sounds familiar. There was a serious problem with the 3.1D 4DDN kernel getting into a state where mbufs were being consumed but never freed. This memory leakage eventually caused the system to hang. The bug has been fixed in 3.1G, 3.2, and 3.2.1. James Leong Silicon Graphics, Inc jleong@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00820; 18 Dec 89 19:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00752; 18 Dec 89 18:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00705; 18 Dec 89 18:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18726; 18 Dec 89 18:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18622; Mon, 18 Dec 89 15:22: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: 18 Dec 89 23:09:00 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SMD controllers on 4D/240 Message-Id: <46570@sgi.sgi.com> References: <1989Dec18.113838.27875@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Dec18.113838.27875@hellgate.utah.edu>, mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: > But now I have some questions about different disks on a different machine. > > We have a 4D/240gtx and we are interested in putting some SMD disks on it. > Does anyone have any good or bad comments about doing this? What controllers, > and how much do they cost? How is the IO throughput? I imagine that a fast > machine like the 240gtx should really have no trouble with several gigabytes > of disk hanging off the thing. > We sell a 4 port 6u controller. And we sell 1 GB SMD disks. You can expect 2+ MB/sec through EFS on sequential reads. In spite of some early bugs that needed to be fixed, this is presently a very stable product. I belive that the controller, disk in a rack, cabling and s/w is in the low $20K range today. Your sales person will have more accurate pricing information for you. As for buying and integrating your own, I don't recommend it, as you may or may not get the right rev. levels of f/w, h/w or whatever. And cable impedance is critical for these disk drives, as is the right grounding scheme, etc. I recently also heard that one of our customers mistakenly plugged a drive into the wrong voltage (easy to do) and blew up the power supply for the drive. But, that's my opinion (and in this case, maybe that of my employer...) 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 aa01344; 18 Dec 89 22:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01316; 18 Dec 89 22:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01309; 18 Dec 89 22:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20184; 18 Dec 89 22:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA02318; Mon, 18 Dec 89 19:07:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Dec 89 03:06:18 GMT From: Rayan Zachariassen Subject: Re: SMD controllers on 4D/240 Message-Id: <89Dec18.220521est.2588@neat.cs.toronto.edu> References: <1989Dec18.113838.27875@hellgate.utah.edu>, <46570@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL markb@denali.sgi.com (Mark Bradley) writes: >As for buying and integrating your own, I don't recommend it, as you may or >may not get the right rev. levels of f/w, h/w or whatever. And cable impedance >is critical for these disk drives, as is the right grounding scheme, etc. It really isn't that bad... it is hard to go wrong in hooking up an SMD drive (although when you get 220V out of 110V sockets...). The more serious problem is getting disks that work with your controller that work with your vendor-supplied or home-grown driver. We are not enamored by the default controller on SGIs, nor the preferred disks, and this combination is indeed sensitive to rev. levels just now being fielded. I would recommend using SGI's supported configuration (from SGI if you value your grey hairs, I gather) unless you have very specific needs or experiences that make you feel it is worth the hassle of listening to SGI people saying "told ya'". I do know for a fact it is possible to do everything homegrown, both an SGI-subsystem-clone configuration [which is what you're probably interested in] and a specific controller/disk combo we like to use around here on heavy timesharing Sun configurations (Ciprico Rimfire/Fujis). >I recently also heard that one of our customers mistakenly plugged a drive >into the wrong voltage (easy to do) and blew up the power supply for the >drive. >But, that's my opinion (and in this case, maybe that of my employer...) I hope so (or if its SGI speaking, hope not). Our machine was inches from the machine referred to here, and the mildest retort to that statement would label it "revisionist history". The victims may comment themselves. However, after the event we were all wondering what the point of having fool-proof socketing standards -- incompatible sockets for different voltages -- is, if they aren't applied (no, the customer didn't supply the metaphoric fool). ps: frankly, at this point, all SMD subsystems are bad relative to the speed of the rest of the system, its just that some are worse than others for various kinds of activities. If we can afford IPI subsystems or some other faster I/O technology, we'll be buying that for our machines asap when the money can be found. rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12936; 19 Dec 89 18:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12717; 19 Dec 89 18:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12715; 19 Dec 89 17:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10082; 19 Dec 89 17:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA10004; Tue, 19 Dec 89 14:35: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: 18 Dec 89 19:56:19 GMT From: Jeremy Nussbaum Organization: Prime Computer, Bedford, Ma. Subject: curses and carriage returns Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just brought up a package called index on an sgi 4d running 3.2. The package uses berkeley curses. By defining NOMACROS and a couple of other odds and ends I have it up and running, with one problem. It ignores carriage returns, and insists upon line feeds. The program is looking for "\n". What do I need to tell curses to have the enter key mapped to a \n? Characters are read in by getchar(), and the modes set upon entry are noecho and cbreak. Adding nl doesn't seem to help. Any hints would be appreciated. I could change all instances of checking for \n to check for ^m also, but there must be a better way. -- Jeremy Nussbaum jeremy@jeremy.prime.com, ...!harvard!prmcad!jeremy Prime Computer 2 Crosby Drive MS 16-2 Bedford, Ma. 01730 (617)275-1800 x6745   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14776; 20 Dec 89 4:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14633; 20 Dec 89 3:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14611; 20 Dec 89 3:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14306; 20 Dec 89 3:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14032; Tue, 19 Dec 89 23:54: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: 18 Dec 89 18:54:37 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: exportto Message-Id: <2094@odin.SGI.COM> References: <8912151417.aa02211@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912151417.aa02211@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > Does anyone out there know what exportto does? > In the posting just prior to this one, you mentioned using "ps -e" to look at the list of processes. Unfortunately, "ps -e" trucates process names to 8 characters. If you use "ps -ef", you get a more complete process command name including arguments. In your case, doing a "ps -ef" will probably show you that "exportto" is really "exporttonews". exporttonews with no arguments will put the your current environment variables in 4Sight's (the news_server's) environment. exporttonews is used by the news_server to import your environment on startup. You can use exporttonews to extend your news_server's environment while it is running if you are experimenting with NeWS applications which depend on your environment. --- Dave   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14776; 20 Dec 89 4:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14633; 20 Dec 89 3:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab14611; 20 Dec 89 3:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14310; 20 Dec 89 3:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14130; Tue, 19 Dec 89 23:56:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 21:56:08 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time Message-Id: <2103@odin.SGI.COM> References: <89Dec15.145750est.2273@neat.cs.toronto.edu>, <1300@uakari.primate.wisc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Dec15.145750est.2273@neat.cs.toronto.edu>, moraes@cs.toronto.edu (Mark Moraes) writes: > > *Soapbox on* > > It is probably much better to ifdef on specific features that one > needs (eg. BSD_SIGNALS, JOB_CONTROL, DIRENT, SHMEM, etc) than on a > specific vendor type, considering the way the zillion and one > "standard" deviants, er, variants, of Un*x are growing warts, er, > features. Relying on even the vendors operating system remaining the > same is probably not portable. As for the simple distinction between > BSD and SYSV, that's gone a long time ago, thanks to extensive > cross-breeding... > > Then one can create configuration headers per machine -- s-machine.h, > sysdep.h, whatever, defining specific features on a per release basis, > as is sometimes necessary :-( The joys of maintaining a single source > tree for multiple architectures and OS deviants! > > *Soapbox off* Yes, Yes,a thousand times yes. Even though the system vendors don't define "feature ifdefs" you can write your code as if you had them. You simply have to create a header that does all the ugly stuff (like that in the rest of the referenced article) and sets the appropriate "featuredefs". We tried to persuade the X consortium to change the ifdef's in X to a scheme like this. Their response was lukewarm.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15881; 22 Dec 89 18:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15817; 22 Dec 89 17:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15815; 22 Dec 89 17:43 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa01999; 22 Dec 89 17:37 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP id AA28948; Fri, 22 Dec 89 17:36:59 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA06972; Fri, 22 Dec 89 15:30:24 -0500 Received: by hombre.MASA.COM (smail2.5) id AA00950; 22 Dec 89 15:20:47 EST (Fri) Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA04971; Mon, 18 Dec 89 20:20:44 EST Date: Mon, 18 Dec 89 20:20:44 EST From: Rod Paul Message-Id: <8912190120.AA04971@dasys1.UUCP> To: info-iris@BRL.MIL, tjh@cs.bu.edu Subject: Re: writing frontbuffer to backbuffer The only thing I can suggest is, if you know prior to drawing a frame that the same image should be drawn in both buffers is: frontbuffer(TRUE); backbuffer(TRUE); of course you'll have to keep tabs of which buffer is being displayed and then issue: frontbuffer(FALSE); backbuffer(TRUE); or visa/versa, but come to think of it, I'm not sure if you'll need to keep tabs on which buffer is being displayed, do soe tests. Hope this helps.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12856; 19 Dec 89 18:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12273; 19 Dec 89 16:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12271; 19 Dec 89 16:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08848; 19 Dec 89 16:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05461; Tue, 19 Dec 89 13:26:33 -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: 19 Dec 89 15:59:00 GMT From: David Wood Organization: New York University Subject: fx/disks/3.2 upgrade Message-Id: <17280030@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We recently upgraded to 3.2 on our 4D/80GT. Last week we began noticing unrecovered disk errors on the disk with / and /usr. So I read the man page for fx and used fx to find the bad blocks. My mistake was using fx to forward the bad blocks while the system was up and running. The resulting sympton was that we got disk I/O errors during 'find ...' . I double checked the man page and nowhere does it say you can't do this. BE WARNED that you are supposed to use the stand alone version of fx when the system is down of course. Incidentally, we have an ESDI drive. While discussing this with SGI, one of there field service guys told me that when upgrading to 3.2, you are supposed to re-format your disks. "Really, it didn't say that anywhere in the installation guide", says I. He said it was only recently discovered that this was necessary. Has anyone else heard anything like this? ------------------------------------------------------------------------- David Wood wood@acf2.nyu.edu New York University ...!uunet!cmcl2!wood 212-998-3029 "Brain. Brain. What is brain?" Kara the Eymorg, "Spock's Brain", Stardate 5432.3 -------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13482; 19 Dec 89 21:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13173; 19 Dec 89 20:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13158; 19 Dec 89 20:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11183; 19 Dec 89 19:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA17827; Tue, 19 Dec 89 16:32: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: 19 Dec 89 23:49:01 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: Re: ethernet version 1 or 2 Message-Id: <1989Dec19.234901.23672@utzoo.uucp> References: <8912142230.AA06853@uxe.cso.uiuc.edu>, <294@mincom.OZ>, <46547@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <46547@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >... I think we are >may still be shipping the VME board jumpered for v.1... An interesting combo, since you ship them with Cabletron transceivers which are v.2! Would it be too much to ask for details on the jumpering so it can be checked? (Hardware documentation? From SGI? Perish the thought.) -- 1755 EST, Dec 14, 1972: human | Henry Spencer at U of Toronto Zoology exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13612; 19 Dec 89 22:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13326; 19 Dec 89 20:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13306; 19 Dec 89 20:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11403; 19 Dec 89 20:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA20019; Tue, 19 Dec 89 17:07: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: 20 Dec 89 00:30:20 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: fx/disks/3.2 upgrade Message-Id: <46704@sgi.sgi.com> References: <17280030@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17280030@acf4.NYU.EDU>, wood@acf4.NYU.EDU (David Wood) writes: > > We recently upgraded to 3.2 on our 4D/80GT. Last > week we began noticing unrecovered disk errors on the > disk with / and /usr. So I read the man page for fx > and used fx to find the bad blocks. My mistake was using > fx to forward the bad blocks while the system was up > and running. The resulting sympton was that we got disk > I/O errors during 'find ...' . I double checked the man page > and nowhere does it say you can't do this. BE WARNED that you > are supposed to use the stand alone version of fx when the > system is down of course. Incidentally, we have an ESDI drive. > While discussing this with SGI, one of there field > service guys told me that when upgrading to 3.2, you are > supposed to re-format your disks. "Really, it didn't say that > anywhere in the installation guide", says I. He said > it was only recently discovered that this was necessary. > Has anyone else heard anything like this? > No, no, no. One does not need to reformat when upgrading s/w. An mkfs is nice once in a great while to de-frag the filesystem in a reload from tape, but you do NOT need to reformat your drive when upgrading s/w. Key word is tape--make sure you are backed up on tape first. You CAN forward bad blocks using the run-time version of fx, but of course in trying to read data from a bad track (you know it's become bad because you get errors trying to read it, right?) , you will get errors. You have to read the data to forward it, naturally. 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 aa16074; 20 Dec 89 7:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15576; 20 Dec 89 7:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15549; 20 Dec 89 6:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15465; 20 Dec 89 6:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22600; Wed, 20 Dec 89 03:29: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: 19 Dec 89 05:09:03 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: use of SGTTY.H and stuff involving IOCTLs Message-Id: <2112@odin.SGI.COM> References: <22483@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <22483@ut-emx.UUCP>, russo@chaos.utexas.edu (Thomas Russo) writes: > > I've been trying to port a program which uses facilities of sgtty.h, > namely it uses the sgttyb structure to set CBREAK mode and turn off > echoing with a call to ioctl like this: > > ioerr = ioctl(fileno(stdin), TIOCGETP, &tty_orig); > /* get std input characteristics */ > ... > ttybuf = tty_new = tty_orig; /* make a copy of tty control structure */ > tty_new.sg_flags = (tty_new.sg_flags & ~ECHO & ~CRMOD) > | CBREAK; > ... > ioctl(fileno(stdin), TIOCSETP, &tty_new); > /* set flags */ > > Is there any slick way to take out this kind of > incompatibility when porting to the iris4d? I can't find any > reference to CBREAK mode in the FM so RTFM is so far no good. > Also, repeated reference is made to requests like TIOCSET[CP] and the > like, and I have no way of knowing what the correct functions are on > the iris. Any hints? > > > > Thomas Russo > Center for Nonlinear Dynamics, University of Texas at Austin > russo@chaos.utexas.edu or phib421@utchpc.bitnet > ------ You should be using termio instead of sgtty. As I understand it, sgtty is rather archaic (and unsupported in some environments) and termio should be used instead. See termio(7) for many details. For instance, your code should be something like: #include "termio.h" ... ioerr = ioctl(fileno(stdin), TCGETA, &tty_orig); ... tty_new.c_iflag &= ~ECHO; /* CRMOD emulation */ tty_new.c_iflag &= ~ICRNL; tty_new.c_oflag &= ~OCRNL; /* CBREAK or 4.3BSD RAW mode emulation (see termio(7) man page ** discussion of ICANON) */ tty_new.c_iflag &= ~ICANON; tty_new.c_cc[VMIN] = 1; /* MIN characters */ tty_new.c_cc[VTIME] = 1; /* TIME in tenths of seconds */ ... TIOC[GS]ETP were used to get and set the parameters. Try matching functionality by looking at the termio man page and looking at any BSD source if it is available to you. The TCGETA and TCSETA[WF] commands are their corresponding commands. TIOCSETC was used to set the special characters. termio.c_cc[] is used to get and set the special control character settings. Use TCSETA (or the TCSETAW or TCSETAF variants) to set different character bindings (and control when the bindings are set with respect to current output buffer). I hope this is all correct, I haven't tried it. I read termio(7) and looked at some BSD game source to figure this one out. If you have 4.3 BSD code available to you, look for code "#ifdef USG" which ifdefs termio versus sgtty variations in code. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17548; 20 Dec 89 8:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15627; 20 Dec 89 7:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15610; 20 Dec 89 7:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15568; 20 Dec 89 7:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA24799; Wed, 20 Dec 89 03:57:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Dec 89 01:20:22 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: curses and carriage returns Message-Id: <2140@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , jeremy@jeremy.prime.com (Jeremy Nussbaum) writes: > I just brought up a package called index on an sgi 4d running 3.2. The package > uses berkeley curses. By defining NOMACROS and a couple of other odds > and ends I have it up and running, with one problem. It ignores > carriage returns, and insists upon line feeds. The program is looking > for "\n". What do I need to tell curses to have the enter key mapped > to a \n? Characters are read in by getchar(), and the modes set > upon entry are noecho and cbreak. Adding nl doesn't seem to help. > > Any hints would be appreciated. I could change all instances of checking > for \n to check for ^m also, but there must be a better way. > The problem is that you are using stdio's getchar() instead of curses' getch(). The carriage return to newline mapping set up by nl() is not done by the tty driver, it is done by curses internals, specifically in wgetch(). Change your getchar() to getch() (which is a wrapper for wgetch(stdscr)) and I think your stuff will work for you. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15673; 20 Dec 89 7:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15627; 20 Dec 89 7:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab15610; 20 Dec 89 7:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15575; 20 Dec 89 7:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA24480; Wed, 20 Dec 89 03:53:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Dec 89 05:39:28 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: SMD controllers on 4D/240 Message-Id: <10266@alice.UUCP> References: <1989Dec18.113838.27875@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Dec18.113838.27875@hellgate.utah.edu>, mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: > We have a 4D/240gtx and we are interested in putting some SMD disks on it. > Does anyone have any good or bad comments about doing this? What controllers, > and how much do they cost? How is the IO throughput? I imagine that a fast > machine like the 240gtx should really have no trouble with several gigabytes > of disk hanging off the thing. we have a 4d/240 that came with one 1.2GB smd disk on a xylogics controller. we thought to upgrade the system ourselves by buying our own disks (i should point out at&t has serious volume discounts with imprimis.) so we bought the cables from sgi, the disks from imprimis (sabre) and installed them into the disk farm. before i got around to formatting them, we installed 3.2. so i tried to format the new three drives. one formatted okay, the others failed (too many succesive errors). (in passing, i scrogged several inodes on my system disk because fx causes the controller to reset and it looked like we lost an inode or two every time that happened. thereafter, i did this fx stuff standalone despite what the hotline says.) i mkfs'ed, fsck'ed and mounted filesystems on the new disk and very soon had a console full of hard ecc errors. having no fear and feeling no pain, i called the hotline. they very soon said that if i wanted to use third party stuff that was my problem. i said, well that's okay but at least you should tell me what firmware revision the controller, disks etc should be (after all, i had duplicated the hardware sgi sells). hotline agreed and called back sometime later. this time, hotline was apologetic and polite and said sgi doesn't do anything to the drives anyway and since we had a full maintenance contract, hotline would help. well, they still didn't have the revision numbers but i said i would try reseating all the cables etc and checking all the dip switches were the same etc. a few days later, no hotline callback so i tried imprimis. i got hold of their smd specialist and said i had problems with sabres on an sgi box. he said, 'hmmm', i heard pages flicking and then he said 'yeah, a lot of that starting around september'. well to cut an already long story short, this was a known problem with three causes: a tiny fraction was due to a bad prom on the sabres (long fixed), a bunch more problems were due to fx (these were supposedly fixed in 3.2) and the rest were due to controller problems. so i called the hotline and they asked 'well, how are things?'. i replied that i knew what the problem was and relayed the news from the imprimis guy. the hotline guy said he knew about all of that (sure! why didn't he tell e before?). he then said we needed firmware revision 2.6.2 or later on the xylogics controller. i had already pulle dthe board to find we had 2.6 and so we quickly agreed for a new board to be fedex'ed to us. i just formatted one of the new drives today. no problems (although it has not been soaked). i was not satisfied with how the hotline handled this but at least now my disks seem like they are working.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19097; 20 Dec 89 10:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18806; 20 Dec 89 9:59 EST Date: Wed, 20 Dec 89 9:49:15 EST From: Gary S. Moss (VLD/VMB) To: info-iris@BRL Subject: Re: use of SGTTY.H and stuff involving IOCTLs Message-ID: <8912200949.aa18764@VMB.BRL.MIL> Dave Ciemiewicz has got the right idea, but based on some of my code that seems to work I would make some changes. I already sent some code to Thomas, but for the benefit of other readers, take this for what its worth: < For instance, your code should be something like: < #include "termio.h" < ... < ioerr = ioctl(fileno(stdin), TCGETA, &tty_orig); < ... < tty_new.c_iflag &= ~ECHO; It is my impression that turning off echo is an orthogonal operation, not part of "CBREAK" mode. < /* CRMOD emulation */ < tty_new.c_iflag &= ~ICRNL; < tty_new.c_oflag &= ~OCRNL; Carriage return to newline processing is not disabled in CBREAK mode as far as I know. Study of tty(4) on my Sun seems to confirm this. < /* CBREAK or 4.3BSD RAW mode emulation (see termio(7) man page < ** discussion of ICANON) < */ < tty_new.c_iflag &= ~ICANON; That should be: tty_new.c_lflag &= ~ICANON; < tty_new.c_cc[VMIN] = 1; /* MIN characters */ < tty_new.c_cc[VTIME] = 1; /* TIME in tenths of seconds */ I set the VTIME field to 0, not sure if it matters, though termio(7) on my 4D says to set them both to one to simulate BSD RAW mode. Also, you want to enable signal processing. tty_new.c_lflag |= ISIG; /* Signals ON. */   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22063; 20 Dec 89 12:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21678; 20 Dec 89 12:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21598; 20 Dec 89 12:27 EST Received: from jvnca.csc.org by SMOKE.BRL.MIL id aa06113; 20 Dec 89 12:07 EST Received: from jvncf.csc.org by jvnca.csc.org id AA27096; Wed, 20 Dec 89 12:08:00 EST Return-Path: Received: by jvncf.csc.org id AA22077; Wed, 20 Dec 89 12:07:53 EST Date: Wed, 20 Dec 89 12:07:53 EST From: Richard Shaginaw lac11205 Message-Id: <8912201707.AA22077@jvncf.csc.org> To: info-iris@BRL.MIL David Wood at NYU reports that his SGI service rep has said to format the disk before an upgrade to 3.2. I had heard the same thing from a number of sources; but when I asked our service rep, he said that as long as none of the subsystems were older than 3.0, you don't need to wipe the disk. So I didn't when I installed 3.2 on our 4D/70GT, and so far so good, with pretty heavy usage (and an ESDI disk). It would be so nice if SGI could get its stories straight. -- Rich ------------------------------------------------------------------------------- The John von Neumann National Supercomputer Center -- User Services Group Richard J. Shaginaw JVNC Applications Software Analyst P.O. Box 3717 Consortium for Scientific Computing Princeton, NJ 08543 ------------------------------------------------------------------------------- Internet Address: shaginaw@jvnca.csc.org 609-520-2000 Bitnet Address: shaginaw@jvncc FAX: 609-520-1089 ===============================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24869; 20 Dec 89 15:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24785; 20 Dec 89 15:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24543; 20 Dec 89 14:56 EST Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa09077; 20 Dec 89 14:48 EST Received: from ALCANKTN.BITNET (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57459; Wed, 20 Dec 89 14:46:38 EST Date: Wed, 20 Dec 89 13:42:00 EST From: Shawn Allin - Alcan KRDC Computer Services Subject: Help needed with FTP/Telnet to and from PC running NCSA Telnet To: info-iris@BRL.MIL Message-id: <07402C62AFDF202621@ALCANKTN.BITNET> X-Envelope-to: info-iris@brl.ARPA X-VMS-To: IN%"info-iris@brl.arpa" Hello all, I have a problem getting FTP and Telnet working between our Irises and PC's running NCSA Telnet/FTP. I have the latest release from NCSA and am using it with a 3COM ethernet adapter. This configuration works fine to and from a Vax running CMU-TEK's software and the Vax also talks to the Irises fine. So basically, here's what works: IRIS <---> VAX - no probs PC <---> VAX - no probs PC <-/-> IRIS - no go. Any ideas? I have the hosts info defined, but apart from that am running with the "defaults" as configured by NCSA on the PC end and SGI on the IRIS end. Cheers, Shawn Allin Alcan International Ltd., P.O. Box 8400, Kingston, Ont., Canada K7L 5L9 (613) 541-2178 Bitnet: ACCESS@ALCANKTN Soon to be: ACCESS@KRDC.INT.Alcan.CA   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25487; 20 Dec 89 16:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23860; 20 Dec 89 14:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23824; 20 Dec 89 14:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08228; 20 Dec 89 14:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA18867; Wed, 20 Dec 89 10:55:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Dec 89 16:02:57 GMT From: Chetty Ramanathan Organization: Software Tool & Die Subject: popup menu in C Message-Id: <1989Dec20.160257.26854@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL consider the following c statement to create a menu mymenu = defpup("Menu %t |item_1 %f",foo); the function foo() gets called if item_1 is selected. The value of the argument passed to foo() will be 1. Is it possible to pass a pointer to some structure as the argument to foo(), If so how should the argument to defpup() be defined. The reason I want to do this is that I want to avoid using global variables. I came up with a rather ugly way to do it, and I'm looking for a more elegant solution. strcpy(str1,"Menu %t |item_1 %f%x"); sprintf(str2, "%s%ld", str1, &s); /* s is of type mystruct */ mymenu = defpup(str2, foo); foo(v) long v; { mystruct *s; s = v; now I can access the structure by saying rect(s->x0, s->y0,....) } -chetty ------------------------------------------------------------------------------- C.Ramanathan | Software Tool & Die, Purveyors to the Trade |chetty@world.std.com 1330 Beacon St, Brookline, MA 02146,(617)739-0202 |{xylogics,uunet}world!chetty -- -chetty ------------------------------------------------------------------------------- C.Ramanathan | Software Tool & Die, Purveyors to the Trade |chetty@world.std.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26143; 20 Dec 89 19:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25851; 20 Dec 89 17:58 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa25845; 20 Dec 89 17:42 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa22605; 20 Dec 89 17:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29234; Wed, 20 Dec 89 13:46: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: 20 Dec 89 21:36:10 GMT From: Ray Loyzaga Organization: Basser Dept of Computer Science, University of Sydney, Australia Subject: Re: Distinguishing "true" MIPS box from DECstation at compile time Message-Id: <675@cluster.cs.su.oz> References: <89Dec15.145750est.2273@neat.cs.toronto.edu>, <1300@uakari.primate.wisc.edu>, <2103@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2103@odin.SGI.COM> msc@sgi.com writes: > In article <89Dec15.145750est.2273@neat.cs.toronto.edu>, > moraes@cs.toronto.edu (Mark Moraes) writes: > > It is probably much better to ifdef on specific features that one > > needs (eg. BSD_SIGNALS, JOB_CONTROL, DIRENT, SHMEM, etc) than on a > > specific vendor type, considering the way the zillion and one > > [Deleted] > > Then one can create configuration headers per machine -- s-machine.h, > > sysdep.h, whatever, defining specific features on a per release basis, > > as is sometimes necessary :-( The joys of maintaining a single source > > tree for multiple architectures and OS deviants! > > > > *Soapbox off* > > Yes, Yes,a thousand times yes. > > Even though the system vendors don't define "feature ifdefs" you can write > your code as if you had them. You simply have to create a header that does > all the ugly stuff (like that in the rest of the referenced article) and > sets the appropriate "featuredefs". > We tried to persuade the X consortium to change the ifdef's in X to a scheme > like this. Their response was lukewarm. The only problem with this approach is that all the sources that you develop will have #includes of files that are not available on any other system, you could #ifdef the includes but on the basis of what? The bottom line is that you need to have an "include" file that defines the way the system is set up, and this file is sourced by cpp with every invocation. This file should contain the "standard defines" such as mips or sysV etc, these are currently compiled into cpp or a caller program and mean that the user must rely on the result of the output of "strings" on cpp or cc, and some guesswork, or hope that any changes are reflected in the manuals on each release. I'd be much more comfortable in reading a file such as /etc/local-system which contains -Dmips -DBSD4 etc, and having cpp doing something like #!/bin/sh /lib/cpp.real `cat /etc/local-system` "$@" The inbuilt defines couldn't be clearer and there would be no need to include any files that are unlikely to exist on other machines. We currently use such a system to communicate some kernel changes that affect the sizes of system structures to all the system sources without having to edit them.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26369; 20 Dec 89 20:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26333; 20 Dec 89 20:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26315; 20 Dec 89 20:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id ab14657; 20 Dec 89 20:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA11271; Wed, 20 Dec 89 16:53: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: 20 Dec 89 23:18:56 GMT From: Dan Dickey Organization: Minnesota Regional Network, Mpls., MN Subject: test missile cones in dog/flight? Message-Id: <1824@nic.MR.NET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Quite a while ago, someone mentioned a flag to use in either dog or flight that would enable some missile cones on the ground. Presumably to for testing. I'd like to use these to fight against, as we don't really have too many sgi's around here. What was the flag? -- Dan A. Dickey ddickey@ferrari.cray.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26503; 20 Dec 89 21:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26436; 20 Dec 89 21:16 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa26396; 20 Dec 89 20:58 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa24975; 20 Dec 89 20:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13856; Wed, 20 Dec 89 17:34:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Dec 89 01:19:15 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: use of SGTTY.H and stuff involving IOCTLs Message-Id: <46780@sgi.sgi.com> References: <8912200949.aa18764@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8912200949.aa18764@VMB.BRL.MIL> moss@BRL.MIL ("Gary S. Moss", VLD/VMB) writes: >Dave Ciemiewicz has got the right idea, but based on some of my code that >seems to work I would make some changes. I already sent some code to Thomas, >but for the benefit of other readers, take this for what its worth: >< tty_new.c_cc[VMIN] = 1; /* MIN characters */ >< tty_new.c_cc[VTIME] = 1; /* TIME in tenths of seconds */ >I set the VTIME field to 0, not sure if it matters, though termio(7) >on my 4D says to set them both to one to simulate BSD RAW mode. From the post-release-3.2 termio man page: (see also POSIX 1003.1 7.1.1.7) If MIN and TIME are both greater than 0: In this case, TIME serves as an inter-character timer activated after the first character is received, and reset upon receipt of each character. MIN and TIME interact as follows: As soon as one character is received the inter-character timer is started. If MIN characters are received before the inter-character timer expires the read is satisfied. If the timer expires before MIN characters are received the characters received to that point are returned to the user. A read(2) operation will sleep until the MIN and TIME mechanisms are activated by the receipt of the first character; thus, at least one character must be returned. --------------------- If MIN > 0, TIME = 0: In this case, because TIME = 0, the timer plays no role and only MIN is significant. A read operation is not satisfied until MIN characters are received. --------------------- If MIN = 0, TIME > 0: In this case, because MIN = 0, TIME no longer serves as an inter-character timer, but now serves as a read timer that is activated as soon as the read operation is processed (in canon). A read operation is satisfied as soon as a single character is received or the timer expires, in which case the read operation will not return any characters. --------------------- If MIN = 0, TIME = 0: In this case, return is immediate. If characters are present, they will be returned to the user. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]