Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20854; 8 Feb 90 6:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20668; 8 Feb 90 6:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab20638; 8 Feb 90 5:49 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa15797; 8 Feb 90 5:35 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6463; Thu, 08 Feb 90 05:26:21 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 08 Feb 90 11:18:24 Date: Thu, 8 Feb 90 07:44:44 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Network questions To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <9002080535.aa15797@SMOKE.BRL.MIL> Hallo, I have a question for the network people. Since three years I operate an ethernet based LAN with 5 IRIS 3100's, one 4D/70, three PC's and 6 terminal servers. Since that time we never saw any single network error. Two month ago we got a fibre optic link to our university network. That link connects via a bridge to our coax based yellow-cable. Since that I see lots of Ierrs and Collisions on the 'netstat -i' output of our IRIS'es. My question is: Is there a simple way to get more information about the reason and source of this errors? The errors occur during phases of "high" load on the ethernet (about 10-15% of the bandwith). It follows a snapshoot of 'netstat -i': Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll enp0 1500 130.83 pc4 501286 36 96730 0 240 lo0 4208 loopback localhost 174370 0 174370 0 0 Any comments are welcome. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20967; 8 Feb 90 6:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20668; 8 Feb 90 6:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20638; 8 Feb 90 5:49 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa15796; 8 Feb 90 5:35 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6461; Thu, 08 Feb 90 05:26:04 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 08 Feb 90 11:18:19 Date: Thu, 8 Feb 90 07:38:25 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: F77 minor problem To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <9002080535.aa15796@SMOKE.BRL.MIL> Hallo, there seems to be a minor problem in the f77 documentation (and the compiler). Five month ago we upgraded our software (includng f77) to IRIX 3.2. For f77 we got replacements of the "Languagereference manual", the "reference Manual Pages" and the "Release Notes". The "Programmer's Guide" was not updated and is still Rev 1.0. On page 1-11 of that manual the options "-C" and "-check_bounds" are referenced. Both cope (as stated) with subscript-range checking at runtime. "-C" (wich is also documented in the Rev 2.0 Manual Pages) works fine. If you use "-check_bounds", you get: a) a very small executable b) a very unexecutable executable; For me it seems "-check_bounds" is obsolete in Rev 2.0 and the reference should be removed from future releases of the "pogrammer's guide" and (thats the sw-bug) it shouldn't be accepted by the f77-command. Try to compile the appended test-program and see what happens if you compile it severall ways: f77 -g t.f -o t f77 -C -g t.f -o t f77 -check_bounds -g t.f -o t Have fun Martin Knoblauch ----------------------------t.f------------------------------------------ program test dimension a(10) do 10 i=1,12 a(i) = i 10 continue end -------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29989; 8 Feb 90 17:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29684; 8 Feb 90 17:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29619; 8 Feb 90 16:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01708; 8 Feb 90 15:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21395; Thu, 8 Feb 90 12:23:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Feb 90 18:59:38 GMT From: Jack Weldon Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Use of snoop(7P) Message-Id: <3797@odin.SGI.COM> References: <739@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <739@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes: > >I have been playing with the snoop(7P) protocol on a variety of > >When the program attempts to add the snoopfilter to the socket, the ioctl() >fails with the error ``Invalid argument'' and the following message appears >on the console of the machine (4D/80S in this case): > > enp0: promisc. mode failed: no firmware support > >Is this going to be fixed on a future release ? I was hoping to use some >of the above code to port tcpdump to Irix. > If your system is under a support contract, contact the Geometry Hotline and request that the newer PROMS be installed in your 4D{50,60,70,80}. These PROMS support both snoop and 4DDN protocols. The information is contained in FB 87 (Field Bulletin 87). This is only required in CMC (enpX) boards found in the above machines. Neither the PI or the GTX series requires this type of upgrade--the newer PROM support is already installed. If you are curious as to whether your machine has the newer PROM installed, run 'hinv' from a shell. The correct output will show version 4 (SGI) PROMS: CMC ENP-10 Ethernet controller 0, firmware version 4 (SGI) Before all of the readers of this newsgroup go and call for PROM upgrades, please realize that this is not required for normal ethernet operation, but is required for snoop or 4DDN use. Future tools based on snoop may also require the upgrade, which will be fully documented in Release Notes if it IS required. Hope this helps. Cheers, Jack P. Weldon (jweldon@sgi.com) Fish and guests grow stale after 3 days SGI Product Support M.F.K. Fisher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01004; 8 Feb 90 19:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00946; 8 Feb 90 19:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00943; 8 Feb 90 19:34 EST Received: from [130.18.176.2] by SMOKE.BRL.MIL id aa04526; 8 Feb 90 19:09 EST Received: by Icarus2.AE.MsState.Edu (4.1/5.0s); id AA02660; Thu, 8 Feb 90 18:12:08 CST Date: Thu, 8 Feb 90 18:12:08 CST From: Larry Thorne Message-Id: <9002090012.AA02660@Icarus2.AE.MsState.Edu> To: info-iris@BRL.MIL Subject: 2500 Status Light Display We have an old SGI 2500 that has been sick for several months (runs fine for days, then corrupts its filesystems and/or crashs), but now has died & won't boot. The halt light is on and the status display is "7". Pressing the reset button causes the status to go to "0" momentarily and then immediately back to "7" - nothing is displayed on the console and the halt light remains on. Does anyone know what the problem is, or the meaning of the status display numbers? I can find nothing in the manuals about this display. Any help or suggestions will be greatly appreciated! Larry Thorne, Sys. Mgr. Research Center for Advanced Scientific Computing Mississippi State University Drawer A Mississippi State, MS 39762 601/325-3623 email: larryt@ae.msstate.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01676; 8 Feb 90 21:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01467; 8 Feb 90 21:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01375; 8 Feb 90 21:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05361; 8 Feb 90 21:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09314; Thu, 8 Feb 90 16:58:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Feb 90 23:56:16 GMT From: Jesse Rendleman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Network questions Message-Id: <3822@odin.SGI.COM> References: <9002080535.aa15797@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002080535.aa15797@SMOKE.BRL.MIL> XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: >Hallo, > >IRIS'es. My question is: Is there a simple way to get more information >about the reason and source of this errors? The errors occur during Yes, there are several additional ways to peek at what's happening on your network. One would be to use "netstat -s" to get a little more info on what sort of errors are occuring. Also, on 3.2 4D's you can use "netsnoop" to trace network traffic. good luck,   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01676; 8 Feb 90 21:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01467; 8 Feb 90 21:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01375; 8 Feb 90 21:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05363; 8 Feb 90 21:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09353; Thu, 8 Feb 90 16:59:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Feb 90 23:57:43 GMT From: Jack Weldon Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Use of snoop(7P) Message-Id: <3823@odin.SGI.COM> References: <739@alias.UUCP>, <3797@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3797@odin.SGI.COM> jweldon@renegade.sgi.com (Jack Weldon) writes: >> >>on the console of the machine (4D/80S in this case): >> >> enp0: promisc. mode failed: no firmware support >> >> >If your system is under a support contract, contact the Geometry Hotline >and request that the newer PROMS be installed in your 4D{50,60,70,80}. >These PROMS support both snoop and 4DDN protocols. The information is >contained in FB 87 (Field Bulletin 87). This is only required in CMC (enpX) >boards found in the above machines. Neither the PI or the GTX series >requires this type of upgrade--the newer PROM support is already installed. >If you are curious as to whether your machine has the newer PROM installed, >run 'hinv' from a shell. The correct output will show version 4 (SGI) PROMS: > >CMC ENP-10 Ethernet controller 0, firmware version 4 (SGI) > >Before all of the readers of this newsgroup go and call for PROM upgrades, >please realize that this is not required for normal ethernet operation, but >is required for snoop or 4DDN use. Future tools based on snoop may also >require the upgrade, which will be fully documented in Release Notes if it >IS required. > An SGI development engineer dropped me a note asking me to clarify the above statement, so here goes: You do not need to upgrade ANY firmware/PROMs in your ethernet board unless your machine has CMC ENP-10 Ethernet Cards in it and they are of Revision 0. It is possible that a PI or a GTX could have a CMC ENP-10 as a secondary/"gateway" board. In his words: "only if you have a CMC ENP-10 (interface name enp) and you want to snoop or do 4DDN and hinv says revision 0" do you need an upgrade. If they want to snoop on all interfaces, they will need to upgrade down-rev CMC proms." Hope this clarifies things. Cheers, Jack P. Weldon (jweldon@sgi.com) Fish and guests grow stale after 3 days SGI Product Support M.F.K. Fisher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02012; 8 Feb 90 23:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01854; 8 Feb 90 22:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01843; 8 Feb 90 22:28 EST Received: from dinorah.wustl.edu by SMOKE.BRL.MIL id aa05719; 8 Feb 90 21:44 EST Return-Path: Date: Thu, 8 Feb 90 15:57:01 CST From: art@dinorah.wustl.edu Message-Id: <9002082157.AA17032@dinorah.wustl.edu> To: info-iris@BRL.MIL Subject: Access to current signal mask Cc: art@dinorah.wustl.edu, weinhous@castor.wustl.edu Greetings all, I am writing some code that needs to run on several different platforms and that plays with signals and the process's signal mask, (flames and pity to /dev/null 8^) ) and I would like to be polite and restore the signal mask to its previous state when I am done. Unfortunately, I can find no way to get at the signal mask under Irix. There are broad hints in /usr/include/sys/signal.h that it exists, but it appears to be buried inaccessably deep in the kernal. Ideally what I would like to find are the POSIX standard signal handling routines, since that is what my "portable" code uses. In particular, I would like to find sigprocmask(), sigaction(), sigsuspend() and the sigset_t operators. I would be almost as happy to find any set of routines that would let me implement these POSIX routines. I would even be willing to do some mucking around in the kernal, if I knew how and where to muck. If anyone has any gems of wisdom on this topic, I would love to hear from you. I do not follow comp.sys.sgi regularly, and am not on the info-iris mailing list (though one of my coworkers is), so please (also) send any responses to me directly by e-mail. Thanks in advance! I am -art smith (art@dinorah.wustl.edu or ...!uunet!wucs1!dinorah!art)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02108; 8 Feb 90 23:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01962; 8 Feb 90 23:01 EST Received: by VMB.BRL.MIL id aa01897; 8 Feb 90 22:38 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa00660; 8 Feb 90 18:14 EST Received: from [128.32.133.1] by ADM.BRL.MIL id aa26283; 8 Feb 90 18:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28080; Thu, 8 Feb 90 14:09:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Feb 90 13:27:39 GMT From: "Thomas D. Schardt" Organization: NSESCC, Goddard Space Flight Center, Greenbelt MD Subject: Re: Turning Off Ipforwarding on Irix 3.2 Message-Id: <824@dftsrv.gsfc.nasa.gov> References: <818@dftsrv.gsfc.nasa.gov>, <50023@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sorry folks...Andrew Cherenson of SGI pointed out that ipforwarding is only used if more than one Ethernet controller is online. I know, "Read the comments more closely that's what we put them there for." Thanks for the quick reply Andrew. Tom Schardt Bitnet: K4TDS at SCFVM NASA/Goddard Space Flight Center Internet: K4TDS@SCFVM.GSFC.NASA.GOV Code 632 Opinions expressed are my own and do not Greenbelt, MD 20771 necessarily reflect the opinions of my employer   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09844; 9 Feb 90 11:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09570; 9 Feb 90 11:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09538; 9 Feb 90 11:25 EST Received: from tank.uchicago.edu by SMOKE.BRL.MIL id aa01130; 9 Feb 90 10:55 EST Received: from shiva.uchicago.edu by tank.uchicago.edu Fri, 9 Feb 90 09:45:04 CST Received: by shiva.uchicago.edu (5.52/890607.SGI) (for @tank.uchicago.edu:info-iris@brl.arpa) id AA00705; Fri, 9 Feb 90 09:38:41 CST Date: Fri, 9 Feb 90 09:38:41 CST From: William Collins Message-Id: <9002091538.AA00705@shiva.uchicago.edu> To: info-iris@BRL.MIL Subject: 3D image & data display prod's Our group at the University of Chicago Geophysical Sci. Dept. needs to display the output from global climate models. The output typically consists of 3D vector and scalar fields on a spherical grid evaluated at fixed time-step intervals. We need a way to display this (with option for stereo projection) using animation and a database capable of handling both pixel data from satellites and the fields from the models. The database must be optimized for large amounts of data (multiple gigabytes). Any suggestions for software products that offer these capabilities would be appreciated. Bill Collins University of Chicago email:bill@shiva.uchicago.edu or bill@oddjob.uchicago.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10269; 9 Feb 90 12:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10078; 9 Feb 90 12:12 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa09854; 9 Feb 90 11:51 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa16390; 9 Feb 90 11:40 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01807; Fri, 9 Feb 90 08:25:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 90 15:46:29 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!ria!uwovax!33141_6622@tut.cis.ohio-state.edu Subject: Message-Id: <4951.25d29f85@uwovax.uwo.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm a new SGI user and one of the things I haven't been able to find is a driver for a Postscript printer. I would like to be able to print out some of the images that I have created, on my NEC postscript printer. Is there some public domain software that will do this? What about the newest version of the operating system (which I haven't received yet), does it have a postscript printer driver? -- Ivan Vesely, Ph.D. John P. Robarts Research Institute P.O. Box 5015 London, Ontario, Canada N6A 5K8 I.Vesely@uwovax.uwo.ca I.Vesely@uwovax.bitnet vesely@engiris.rri.uwo.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14645; 9 Feb 90 16:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14468; 9 Feb 90 16:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14092; 9 Feb 90 16:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06395; 9 Feb 90 15:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18420; Fri, 9 Feb 90 12:47:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 90 15:37:08 GMT From: Jesse Rendleman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: correction Message-Id: <3858@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL My apologies to anyone who spent time looking for the "netsnoop" command on their system. This command is still in development/testing, and not currently available. Again, I'm sorry for any wasted time my misinformation caused.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15296; 9 Feb 90 17:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14994; 9 Feb 90 17:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14957; 9 Feb 90 16:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06972; 9 Feb 90 16:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20374; Fri, 9 Feb 90 13:16:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 90 20:55:47 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: gcc on IRIX 3.2 Message-Id: <850@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm trying to fire up 'gcc' and I get the following compile error when I make. cc -c -g -I. -I. -I./config expr.c ccom: Warning: expr.c, line 1574: illegal pointer combination size.var = rounded; } else if (size.constant < 32) size.constant = 32; }; --------------------------------------------------------------^ ccom: Warning: expr.c, line 4281: illegal pointer combination gs_size.constant = 0; args_size.var = rounded; } else if (args_ size.constant < 32) args_size.const ant = 32; }; -------------------------------------------------------------------------- --------------- =========================================================================== Looking at the tm-iris.h file I can see that tracking this down will take some effort. If anyone has been to the grindstone on this, I would like to see the your solution for avoiding this complier error. Thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ab15296; 9 Feb 90 17:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14994; 9 Feb 90 17:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab14957; 9 Feb 90 16:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06990; 9 Feb 90 16:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19475; Fri, 9 Feb 90 13:02:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 90 19:40:15 GMT From: "James P. Loan" Organization: Computer Science Department, Stanford University Subject: Personal IRIS order delay Message-Id: <1990Feb9.194015.11824@Neon.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I heard a rumor that SGI has delayed shipment of 4D/20's for 6 weeks because they're short on some parts. Is this true? And what parts are they missing (are they critical)? I'm not sure I can wait 6 weeks for my PI... Peter Loan loan@neon.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15686; 9 Feb 90 17:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14030; 9 Feb 90 16:14 EST Date: Fri, 9 Feb 90 15:52:30 EST From: "Lee A. Butler" To: info-iris@BRL.MIL Subject: 4Sight PaintRoot Message-ID: <9002091552.aa13720@VMB.BRL.MIL> Has anyone been able to modify the NeWS routine "PaintRoot" to display a bitmap from a file? One of the things I enjoyed about Xwindows was having an image for a desktop. I'd like to be able to do this with NeWS. Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17346; 10 Feb 90 0:18 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa17023; 9 Feb 90 23:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16990; 9 Feb 90 23:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12068; 9 Feb 90 23:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16560; Fri, 9 Feb 90 20:09:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 90 17:46:43 GMT From: Scott Henry Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Key mappings under 4Sight 1.0 Message-Id: References: , <4795@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a hack to /usr/NeWS/lib/NeWS/UI.ps that makes the Alt keys act like Meta keys to GNU Emacs (it was posted to the net a while ago, I forgot by who). However, there is a big GOTCHA with this patch -- everything else on the system which looks for the Alt keys won't find them, including X11! Not being a NeWS hacker, I wasn't able to make it work as both. I am including a context diff of the 3.2 UI.ps (put the patched version in ~/NeWS/UI.ps so as not to screw-up anybody else who may use your system, and to have a backup if it fails in a future release). Disclaimer: this is public domain and is not supported in any way by SGI. *** /usr/NeWS/lib/NeWS/UI.ps Thu Mar 9 16:51:01 1989 --- UI.ps Wed Mar 8 09:39:49 1989 *************** *** 318,326 **** --- 318,358 ---- } ifelse } def + % new code for meta key + /MetaDown false def % true when either alt key is down + + { + createevent dup begin % gobble alt key + % Do not eat the right ctrl key. + % We will need it to swap with capslock + % in user.ps. + /Name [28419 28560 28559] def % first one is left ctrl key + /Priority 4 def + /Exclusivity true def + end + expressinterest + { + awaitevent + dup /Action get /DownTransition eq + {/MetaDown true store} % downtrans -> set flag + {/MetaDown false store} % uptrans -> clear flag + ifelse + } loop + } fork + %end new code + /deliver_keyboard_to_focus { % event => - dup dup begin % ev ev sgi_translatekey % ev (string) + % new code for meta key + dup dup type /stringtype eq % if there's a string + exch length 0 ne and % of nonzero length + MetaDown and % and meta is down + Action /DownTransition eq and % and ev is a keypress + {dup dup 0 get 128 or % then ior 128 into + 0 exch put % the 1st char in the string + } if + % end new code /ClientData exch def % ev end InteractionLock monitorlocked MenuBusy 0 ne or { ********************* remember, this is an either/or patch -- you can't have it both ways! -- Scott Henry | These are my | Tardis Express -- when it Information Services, | Opinions only!| absolutely, positively Silicon Graphics, Inc | Whose else? | has to be there -- yesterday.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19813; 10 Feb 90 14:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19681; 10 Feb 90 13:51 EST Received: by VMB.BRL.MIL id ab19672; 10 Feb 90 13:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19054; 10 Feb 90 9:44 EST Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa17183; 10 Feb 90 9:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14966; Sat, 10 Feb 90 06:28:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Feb 90 01:15:48 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: X and the single iris Message-Id: <383@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was adding some colors (my own) to the rgb.txt file in /usr/lib/X11 directory but was unable to find the rgb program that's needed to update the database. any idea where it might be?? Does SGI support this feature? On a slightly separate topic, What about Motif? I want it... (pretty please.....)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03548; 11 Feb 90 6:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03288; 11 Feb 90 5:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03276; 11 Feb 90 5:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25548; 11 Feb 90 5:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16207; Sun, 11 Feb 90 02:25:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Feb 90 07:04:42 GMT From: Venkat Viswanathan Organization: University of Houston Subject: X on the Personal Iris Message-Id: <22195@uhnix1.uh.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am writing some code using Xlib and the athena widgets on a Personal Iris ( IRIX 3.2 ) and am running into a few problems. 1) Doing an xdpyinfo and using macros I get the info. that the server does use a backing store and does save unders. But my applications keep getting expose events and the screen flash is quite irritating. Also expose events for widgets specify the entire area of the widget instead of the exposed area. I have specified save unders explicitly for my popups. 2) Xsgi keeps crashing on a regular basis and dumps core onto the root partition. It regenerates itself automatically though. Anybody experienced similar problems? Any and all help welcome. ------------------------------------------------------------------------ Venkat Viswanathan venkat@cs.uh.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16926; 12 Feb 90 15:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15602; 12 Feb 90 13:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15557; 12 Feb 90 13:16 EST Received: from sgi.com by SMOKE.BRL.MIL id aa16645; 12 Feb 90 12:29 EST Received: from tom.dallas.sgi.com by sgi.sgi.com via UUCP (5.52/891101.SGI) for info-iris@brl.mil id AA19096; Mon, 12 Feb 90 09:30:21 PST Received: from tom.dallas.sgi.com by sgidal.dallas.sgi.com (5.52/891101.SGI) for sgi!BRL.MIL!info-iris id AA03398; Mon, 12 Feb 90 11:28:11 CST Received: by tom.dallas.sgi.com (5.52/890619.SGI) (for @sgidal.dallas.sgi.com:info-iris@BRL.MIL) id AA17444; Mon, 12 Feb 90 11:24:01 CST Date: Mon, 12 Feb 90 11:24:01 CST From: Thomas E Reed Message-Id: <9002121724.AA17444@tom.dallas.sgi.com> To: info@tom.dallas.sgi.com Subject: FFT's on 4D/2XX systems Hi: I'm looking for any FFT software that is available and runs on the 4D/2XX products. The faster the better especially if it is parallel code or has been parallelized. If there is interest let me know and I'll post any and all info. Thanks -- Tom Reed SGI - Dallas email: treed@sgidal.dallas.sgi.com vmail: 8705 phone: 214-788-4122   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18198; 12 Feb 90 16:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17467; 12 Feb 90 15:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17367; 12 Feb 90 15:34 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa22106; 12 Feb 90 14:55 EST Received: from relay2.cs.net by RELAY.CS.NET id ad13697; 12 Feb 90 13:33 EST Received: from gmr.com by RELAY.CS.NET id aa02609; 12 Feb 90 14:30 EST Date: Mon, 12 Feb 90 12:52 EST From: JORDAN%gmr.com@relay.cs.net Subject: Building files from other files To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <9002121455.aa22106@SMOKE.BRL.MIL> We work in a real time environment, and have noticed something strange in a particular "driving" loop. We have two files, exactly the same (visually). Let's call them a.c, and a.copy. a.copy was made from a.c by: cp a.c a.copy Then some extra info was added to a.copy from b.c: cat b.c >> a.copy This added info ruined the performance of the environment so b.c was deleted from a.copy. Therefore, a.copy looks the same as a.c. The Problem? a.copy still has the bad performance as if b.c were still a part of the code. A "diff a.c a.copy" outputs nothing; therefore, no difference. HELP!! TP MUGABI-JORDAN GM - SYSTEMS ENGR CENTER 1151 CROOKS ROAD TROY, MI 48084 (313)280-6766   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18387; 12 Feb 90 16:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17988; 12 Feb 90 16:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17921; 12 Feb 90 16:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22973; 12 Feb 90 15:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03474; Mon, 12 Feb 90 12:16:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Feb 90 19:01:30 GMT From: "Lonhyn T. Jasinskyj" Organization: NASA Ames Research Center, Moffett Field, CA Subject: X on SGI 4Ds Message-Id: <4876@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Could somone please enlighten me on the status of X on Irises. There appears to be no server code for SGI machines under X11R4. Has this not been done? Has someone ported the R3 server and made the source publicly available? I assume the X that comes with Irix 3.2 is not a public domain port, is that true? Will R4 be available under 3.3 or do we need to wait for 3.4 for it to be part of the official release? Any answers, hints, allegations, rumors, etc. would be appreciated. I am trying to decide whether or not to invest major amounts of time into porting/bringing up servers and clients. Lonnie -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Email to: lonhyn@ew01.nas.nasa.gov Human at: 415-604-3989 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18387; 12 Feb 90 16:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18198; 12 Feb 90 16:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17990; 12 Feb 90 16:12 EST Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa23553; 12 Feb 90 15:49 EST Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA21651; Mon, 12 Feb 90 14:52:20 CST Date: Mon, 12 Feb 90 14:52:20 CST From: Mike Goss Message-Id: <9002122052.AA21651@snow-white.merit-tech.com> To: treed%tom.dallas@sgi.com Subject: Re: FFT's on 4D/2XX systems Cc: info-iris@BRL.MIL In reply to the message from Tom Reed: > Date: Mon, 12 Feb 90 11:24:01 CST > From: Thomas E Reed > Message-Id: <9002121724.AA17444@tom.dallas.sgi.com> > To: info@tom.dallas.sgi.com > Subject: FFT's on 4D/2XX systems > . > . > . > I'm looking for any FFT software that is available and runs on the > 4D/2XX products. The faster the better especially if it is parallel code or > has been parallelized. > . > . > . The book "Numerical Recipes in C" (also available in FORTRAN and Pascal versions) has several good FFT routines, although not in a parallelized form. I'd recommend this book for any numerical work. It has lots of useful code, ready to run, and good explanations of the algorithms involved. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20089; 12 Feb 90 20:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20046; 12 Feb 90 20:49 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa20027; 12 Feb 90 20:31 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa09283; 12 Feb 90 20:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22118; Mon, 12 Feb 90 17:08:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 00:08:25 GMT From: Bron Campbell Nelson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: FFT's on 4D/2XX systems Message-Id: <50467@sgi.sgi.com> References: <9002121724.AA17444@tom.dallas.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002121724.AA17444@tom.dallas.sgi.com>, treed%tom.dallas@SGI.COM (Thomas E Reed) writes: > I'm looking for any FFT software that is available and runs on the > 4D/2XX products. The faster the better especially if it is parallel code or > has been parallelized. > Kuck and Associates, Inc (KAI) has several numerical libraries that are optimized for the SGI multi-processor. I do not know for *sure* that they include FFT's, but I believe they do. The libraries are parallelized to take advantage of SGI's multiprocessor machines. They can be reached at 1906 Fox Drive; Champaign, IL 61820 (217)356-2288. I believe Ms. Davida Bluhm is their marketing person. They are also on the net: I believe [d]bluhm@kai.com works, but I won't guarentee it. I have no benchmarks or pricing information. All possible disclaimers apply; this is posted purely for informational purposes. -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron These statements are my own, not those of Silicon Graphics.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20570; 12 Feb 90 23:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20461; 12 Feb 90 23:23 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa20455; 12 Feb 90 23:13 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa11153; 12 Feb 90 22:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02140; Mon, 12 Feb 90 19:38:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 03:27:39 GMT From: James Helman Organization: Stanford University Subject: SGI's X (Re: X on the Personal Iris) Message-Id: References: <22195@uhnix1.uh.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL venkat@csun4.cs.uh.edu (Venkat Viswanathan) writes: 2) Xsgi keeps crashing on a regular basis and dumps core onto the root partition. It regenerates itself automatically though. Yes, it does crash a lot, doesn't it. But count yourself lucky that the IRIX 3.2 version doesn't crash as often as previous versions did. Another big plus: text is always printed right side up now. Seriously, SGI's X is a lot faster and a lot more usable now than ever before. But it is still too buggy for a real product. I'm amazed that products like this could get throuch QC. Most of the worst bugs in SGI's X server, in this and in previous releases, have shown up within 5 minutes of use. Perhaps, their beta sites have to sign an agreement to only use xterm and have no more than one window open at a time. ;-) The question that I would REALLY like the answer to (besides the obvious, when can I get a better release) is whether the SGI stuff on the X11R4 tape runs better or worse than the stuff shipped with IRIX 3.2. Any answers from SGI? Any experience from the real world? BTW, don't bother trying to get anyplace with the hotline on this. I've been going around with them for over a year about X. The best they can do is put you on the "hot list" for the next release. The support "engineer" who answered my latest X call, after making a couple pointless digressions, focussed on THE REAL PROBLEM, asking whether the final "b" in "exit status: 0x8b" was capitalized or not. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26387; 13 Feb 90 11:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26210; 13 Feb 90 11:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26147; 13 Feb 90 11:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11805; 13 Feb 90 10:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12788; Tue, 13 Feb 90 07:07:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 14:51:04 GMT From: Fisher Organization: David Taylor Research Center, Carderock, MD Subject: 1/4 inch tape drive Message-Id: <993@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Who is the manufacturer of the 1/4 inch tape drive for the Iris? I have heard that they also make a 300 MB drive. Is that true? Steve E-Mail: scfisher@dtoa1.dt.navy.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27992; 13 Feb 90 12:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26387; 13 Feb 90 11:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26326; 13 Feb 90 11:22 EST Received: from sgi.com by SMOKE.BRL.MIL id aa12019; 13 Feb 90 10:45 EST Received: from tom.dallas.sgi.com by sgi.sgi.com via UUCP (5.52/891101.SGI) for info-iris@brl.mil id AA01845; Tue, 13 Feb 90 07:27:06 PST Received: from tom.dallas.sgi.com by sgidal.dallas.sgi.com (5.52/891101.SGI) for sgi!BRL.MIL!info-iris id AA04912; Tue, 13 Feb 90 09:30:28 CST Received: by tom.dallas.sgi.com (5.52/890619.SGI) (for sgidal.dallas.sgi.com!sgi!decwrl.dec.com!shelby!helens!bauhaus!jim) id AA20393; Tue, 13 Feb 90 09:25:40 CST Date: Tue, 13 Feb 90 09:25:40 CST From: Thomas E Reed Message-Id: <9002131525.AA20393@tom.dallas.sgi.com> To: decwrl.dec.com!shelby!helens!bauhaus!jim@sgi.com Subject: Re: SGI's X (Re: X on the Personal Iris) Cc: info@tom.dallas.sgi.com HI: It sounds like you are doing more serious X development that the average SGI user. If you would care to share your "SPECIFIC" problems with SGI's X-server I'm sure the engineers responsible for the Quality of that product would be greatful to here them. You can mail them to me and I'll forward them on, or you could post them on this mailing list as I'm sure most if not all of the engineers subscripe to it. Making blanket statements without supplying DETAILS of fact does little to enlighten others or to help provide the Quality of Product you and other deserve. The same holds true for the hotline. These statements are my own ..etc.... -- Tom Reed SGI - Dallas email: treed@sgidal.dallas.sgi.com vmail: 8705 phone: 214-788-4122   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01333; 13 Feb 90 16:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29454; 13 Feb 90 14:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29416; 13 Feb 90 14:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18491; 13 Feb 90 14:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25806; Tue, 13 Feb 90 10:35:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 18:03:46 GMT From: cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!ria!uwovax!weimei@tut.cis.ohio-state.edu Subject: rdump again Message-Id: <4984.25d805b2@uwovax.uwo.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL It seemed I have only caught the tail part of the "rtar & rdump" discussion. Can any kind soul out there tell me: Is there a public domain rdump for SGI? If YES, where can i get it? Thanks in advance! WEI MEI Phone: (519) 679-2111 ext. 6043 CCS NSC WEIMEI@uwovax.uwo.ca WEIMEI@UWOVAX.BITNET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03197; 13 Feb 90 20:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02587; 13 Feb 90 18:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02543; 13 Feb 90 18:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19757; 13 Feb 90 14:41 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29905; Tue, 13 Feb 90 11:32:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 19:29:48 GMT From: Seth Teller Organization: University of California at Berkeley Subject: Re: SGI's X (Re: X on the Personal Iris) Message-Id: <22066@pasteur.Berkeley.EDU> References: <22195@uhnix1.uh.edu>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article jim@bauhaus.Stanford.EDU (James Helman) writes: > > ... non-specific X complaints deleted ... > then continues with this: > BTW, don't bother trying to get anyplace with the hotline on this. > I've been going around with them for over a year about X. The best > they can do is put you on the "hot list" for the next release. The > support "engineer" who answered my latest X call, after making a > couple pointless digressions, focussed on THE REAL PROBLEM, asking > whether the final "b" in "exit status: 0x8b" was capitalized or not. > > Jim Helman > Department of Applied Physics P.O. Box 10494 > Stanford University Stanford, CA 94309 > (jim@thrush.stanford.edu) (415) 723-4940 i'm sure there are those working at sgi who would like to respond to your posting in kind; however, good sense and discretion prevent them. since i am unfortunate enough to have the benefit of neither, you'll kindly allow me a few words. this sort of public castigation of hotline people is unwarranted, unfair, and in my (not entirely disinterested) opinion, borders on abusive. at best, the responses you'll get will be like mine (of protest), or frustrated silence (from those at sgi who are offended but unable to respond, unless they do so with enormous tact-- something which many may not be able to justify the time or patience for after reading your post). what effect did you expect it to have? frantic, subservient hotline people jamming your phone lines with offers of more help? netgroup readers stuffing your mailbox with detailed descriptions of work- arounds? you didn't detail any problems! look, at any company, there are going to be times when hotline people are left casting about in deep water by circumstances, whether they be development/release schedules, communication failures with engineers, or just the general finiteness of their resources, time, and energy. rather than direct criticism _at_ them, why not direct it _to_ those who allocate training, resources, and support to the hotline itself? and in a real letter, on paper (these seem still to be so much more effective than any ephemeral posting). i'm sure i've said more than my share. sincerely yours, seth teller   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03197; 13 Feb 90 20:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03069; 13 Feb 90 20:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ae02972; 13 Feb 90 19:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01536; 13 Feb 90 19:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18503; Tue, 13 Feb 90 16:22:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 23:39:56 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 1/4 inch tape drive Message-Id: <50620@sgi.sgi.com> References: <993@nems.dt.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <993@nems.dt.navy.mil>, scfisher@dtoa1.dt.navy.mil (Fisher) writes: > Who is the manufacturer of the 1/4 inch tape drive for the Iris? > I have heard that they also make a 300 MB drive. Is that true? > Which Iris? We currently source 2 vendors and 4 different drives. Archive and Cipher. The drive you are referring to is probably an Archive 320 MB unit. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson ******************************************************************************** * Disclaimer: Anything I say is my opinion. If someone else wants to use it, * * it will cost... * ********************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03683; 13 Feb 90 21:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03611; 13 Feb 90 21:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac03568; 13 Feb 90 21:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02344; 13 Feb 90 21:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23425; Tue, 13 Feb 90 17:38:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 01:12:11 GMT From: James Helman Organization: Stanford University Subject: X & hotline Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In response to my note on SGI's hotline and X, I've received both flames for criticizing the hotline and messages from people who related similar frustration with the SGI "Cold"Line (not my phrase). After my posting, I got a polite (more than I deserved) call from the hotline and got to talk with an engineer in the X group! Anyone else remember the time SGI announced it was pulling X out of the next IRIX release, and wouldn't tell us whether it would ever come back or not? Or when it only had one X engineer working on a product used by thousands of people? Well, after talking with an X engineer, I'm convinced that things have changed a lot. Now I know there's at least one engineer, probably more, who is strongly committed to making SGI's X product top notch. It certainly was not at all fair for me to heap up a year and a half's worth of my X frustrations and flame out at the hotline. I apologize to everyone associated with the hotline. My snap judgement of the support engineer was way off base. In the future there may be a better way. I was told that SGI might set up something to provide a target for meta-hotline expressions of praise, criticism, opinion, etc. Hopefully, this will provide a mechanism for a more productive expression of frustrations. If it works, it should be great, because then at least someone will get to hear how much frustration and wasted time bugs and poor hardware QC can cause, and allocate engineering resouces accordingly. No company should be without such a feedback loop. AS FOR X itself, I was told that the clients on the X11R4 release will build on 4D's, but the server won't. As for server bugs, the word is the usual "wait for the next IRIX release." The new server has improvements linked to the new OS, so there's little hope for a fixed server before then. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03874; 13 Feb 90 22:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03839; 13 Feb 90 22:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03821; 13 Feb 90 22:29 EST Received: from dukempd.phy.duke.edu by SMOKE.BRL.MIL id aa03115; 13 Feb 90 22:23 EST Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA06640; Tue, 13 Feb 90 22:22:57 EST Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA05845; Tue, 13 Feb 90 22:22:52 EST Date: Tue, 13 Feb 90 22:22:52 EST From: "Robert G. Brown" Message-Id: <9002140322.AA05845@physics.phy.duke.edu> To: info-iris@BRL.MIL Subject: Power for Iris 220S Cc: rgb@phy.duke.edu Thanks to all the nice people who responded, and the folks at SG who (eventually) arrived at the One True Word. For we mortals who are confused by a wiring specification that calls for 220V single phase (ground, neutral, hot) power for a machine sold in a country where there ain't no such beast (or at least, where it is extremely rare) there follows a short Discourse on Wiring: Feeding the Beast The receptacle for the 220S Power Series Rack is a Nema 6L 30R, twist lock. Its specification is for "30A, 195-240V, 50-60Hz single phase" or words to that effect. The plug has three prongs: |_ Ground Neutral \ / 220V that are >>supposed<< to carry the potentials indicated in an ideal world. Ground (for those ignorant of the Code), is supposed to be real, live (or actually dead) >>ground<<. It should be connected to the moral equivalent of the plumbing, or the steel girders in a building that go deep into the ground. It should >>never<< (intentionally) carry current. When you touch something connected to ground, you should be as safe (electrically) doing so as when you touch the plumbing. Ground is >>very important<< to computers as a signal shield, too, so your ground should be electrically "quiet" in higher frequencies. "Neutral" in your 110 V household wiring is the white one in the white, black, and copper triplet in standard three-wire cable. It, too, is connected to ground, but >>it carries current<<. In fact, all the current that flows "out" the black (hot) wire flows "back" to ground on the white neutral line. Since it carries current, it is easy to electrocute yourself on a neutral line. In the days before the code, standing on a wet bathroom floor and flicking on a light switch shorted to the neutral wire was more than adequate to get the 10 mA or so through the torso needed to defibrillate the heart. (Today, a "ground fault" protected switch compares the current on the black and white wires and if it is not equal -- because some of it is being diverted through your torso, for example -- it cuts off the line). "Hot" in a 110V circuit or the 220V circuit shown above has a potential difference of 110 or 220V >>relative to a grounded wire at the transformer<>fourth<< wire to serve as a current carrying neutral which can be used to split the line into two 110V circuits. Note that the potential difference between the poles is: 110V sin(wt) - 110V sin(wt + Pi) = 220V sin(wt) at 60 cycles. Also acceptable to the power series rack is: |_ Ground 120V sin(wt) \ / 120V sin(wt + 2Pi/3) ============================================ (not used) X 120V sin(wt + 4Pi/3) This wiring uses two out of three legs of a "three phase 220" circuit. This is typical output of a "Wye" transformer and is common in Universities and offices. Again, there may or may not be a current carrying neutral allowing it to be split into three 120V lines. The potential difference is: 120V sin(wt) - 120V sin(wt + 2Pi/3) = 207.8V sin(wt + Pi/3) where the phase shift is completely unimportant (when >>did<< time start, anyway ;-). This (208V) is well withing spec for the 220S. The reasons for running 220V lines in this way are to minimize risk -- unless you touch two lines simultaneously you can only get a 110V shock -- and to allow appliances to draw 30A or 45A in circumstances where each 120V or 110V line is fused to draw no more than 15A. 15A is code for 14 Gauge wire up to 50 feet from the distribution panel and 12 Gauge up to 100 feet. I recall that 20A can run on 12 for 50 feet, and 30A requires 8 or 10 Gauge, but I don't have a reference handy and don't quote me on that. The power cable for the 220S is 10 Gauge, three wire. One reason for the confusion is that >>electricians<< call all three wirings of the above plug/receptacle combo "single phase" 220V AC! God only knows what they would call two phase or three phase. I'm going to wrap it up here, without telling you the story of the Ground Loop, boys and girls. That's what you get (sort of) if you treat a current carrying "neutral" as ground and connect it to something that is a bit closer to "true" ground for the circuit. This is surprisingly easy to do, especially in a machine that is running several lines of power with different phases and a reference neutral. In the week or so since I've posted, I've heard lots of funny stories about blowing up coffee pots plugged into Vax power strips, blowing up Vaxes by connecting them when they were plugged into different phases on different sides of the room, and lots of other stuff. The moral of the story is: beware ground loops. I suspect that SG made the power 220 only in order to avoid this very problem. The bad news, of course, is that our machine doesn't work (still) and it isn't the power :-( But maybe by tomorrow the nice man from SG will swap our boards and get us going.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03937; 13 Feb 90 23:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03874; 13 Feb 90 22:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03864; 13 Feb 90 22:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03332; 13 Feb 90 22:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00391; Tue, 13 Feb 90 19:22:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 22:08:37 GMT From: Gretchen Helms Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SGI's X Message-Id: <4060@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Jim Helman writes: >The question that I would REALLY like the answer to (besides the >obvious, when can I get a better release) is whether the SGI stuff on >the X11R4 tape runs better or worse than the stuff shipped with IRIX >3.2. Any answers from SGI? Any experience from the real world? Clients and libraries and such should work fine. I have been informed by one of our X engineers that the server from the X11R4 tape will *not* build. >BTW, don't bother trying to get anyplace with the hotline on this. >I've been going around with them for over a year about X. The best >they can do is put you on the "hot list" for the next release. The >support "engineer" who answered my latest X call, after making a >couple pointless digressions, focussed on THE REAL PROBLEM, asking >whether the final "b" in "exit status: 0x8b" was capitalized or not. Many times when a call comes in that is not a request for information, the best policy for our customers is to have in hand a list that contains the sequence of events that caused the problem, the behaviour exhibited by the machine as it crashes or bombs, and the specific error codes produced at that time. This allows us to search through our database to locate the same error and cross-reference a previous call to see if it could impact the current one. Unfortunately, many of the error codes are somewhat obscure. Frequently a missing digit or the difference between uppercase and lowercase can be crucial in pinpointing the problem. For example, the difference between "aborted with" and "killed by" often lets us know whether a program caught an internal error or was terminated before it had a chance to progress past a given point. For this reason, we ask for your patience when we request more information on the error codes or symptoms that are described. G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00246; 14 Feb 90 3:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00090; 14 Feb 90 3:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad00232; 14 Feb 90 1:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05075; 14 Feb 90 1:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09664; Tue, 13 Feb 90 22:09:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 04:33:43 GMT From: Paul Jackson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Building files from other files Message-Id: <4094@odin.SGI.COM> References: <9002121455.aa22106@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002121455.aa22106@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: (to paraphrase) | We work in a real time environment, and have noticed something strange | in a particular "driving" loop. | a.c # a.c has OK performance | cp a.c a.copy # a.copy has OK performance | cat b.c >> a.copy # now a.copy has slow performance | "delete b.c from a.copy" # a.copy still has slow performance How did you delete b.c from a.copy? Unix has no way to shorten a file while it is in place on the disk. I presume you deleted b.c by using an editor (such as vi). All editors work by making copies of the file, applying the changes and linking or copying the result back. This reallocates the disk space used for that file. I would guess perhaps that a.copy, after b.c was added, spanned multiple extents. And I would also guess that after "deleting b.c ...", a.copy still took multiple extents. That it still took multiple extents is a little surprising, as our (yes - I work for SGI) Extent-based File System does a pretty good job of keeping files together that are written in one open-write-write-...-close sequence. But it certainly is possible. To further improve this guess, one would need to know the sizes of the files, and how much space was free on the disk partition after each of the above steps. Allocating contiguous extents is harder on a nearly full disk. Why don't you try calling our Geometry Hotline (800) 345-0222. These folks do a real fine job of handling such questions. I use them myself. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02207; 14 Feb 90 8:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01945; 14 Feb 90 8:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01913; 14 Feb 90 8:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09845; 14 Feb 90 7:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25900; Wed, 14 Feb 90 04:55:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Feb 90 23:40:01 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: Re: X on SGI 4Ds Message-Id: <385@texhrc.UUCP> References: <4876@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL AMEN!! to Lonnie's question! There are lot's of us out here waiting to hear about xR4.... All my SUN colleagues are happily using R4. Is it o.k. to take the M.I.T distribution tape and load it on an Iris... I got the impression that that was not a good idea from SGI, and to wait...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02996; 14 Feb 90 9:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02643; 14 Feb 90 9:30 EST Received: from tbd.brl.mil by VMB.BRL.MIL id aa02551; 14 Feb 90 9:10 EST Date: Wed, 14 Feb 90 9:02:49 EST From: "John A. Condon" (BDB) To: info-iris@BRL.MIL cc: jac@BRL.MIL Subject: Iris 4D - 80 GTB interface with a PC Message-ID: <9002140902.aa12205@TBD.BRL.MIL> Hello! Does anyone out there know how to connect a pc to the Iris 4D? I don't want to go over the ethernet so I want to be hardwired utilizing one of the ports on the I/O panel on the Iris. The question is which port is the right one to use if I want to copy a file on one of the 4D's removable disks to my pc's Bernoulli box? Help !!!!!!!!!! John (the Jersey Renegade)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03058; 14 Feb 90 12:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02615; 14 Feb 90 11:56 EST Received: by VMB.BRL.MIL id ad02287; 14 Feb 90 11:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02529; 14 Feb 90 9:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11569; 14 Feb 90 8:56 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29518; Wed, 14 Feb 90 05:50:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 13:29:05 GMT From: Chuck Musciano Organization: Advanced Technology Dept., Harris Corp., Melbourne, Fl. Subject: Re: SGI's X (Re: X on the Personal Iris) Message-Id: <3207@trantor.harris-atd.com> References: <22195@uhnix1.uh.edu>, , <22066@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <22066@pasteur.Berkeley.EDU> seth@miro.Berkeley.EDU (Seth Teller) writes: >this sort of public castigation of hotline people is unwarranted, >unfair, and in my (not entirely disinterested) opinion, borders >on abusive. Hear, hear! Every experience I have had with the hotline people has been exemplary. They were well versed in the technical details of the machine, knew exactly how to fix my problem, and didn't treat me like an idiot. They followed up with several phone calls until they were sure that everything was OK. I couldn't ask for more. Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} The answers to life's problems aren't at the bottom of a bottle, they're on TV! -- Homer Simpson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03698; 14 Feb 90 15:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03356; 14 Feb 90 15:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03194; 14 Feb 90 15:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23067; 14 Feb 90 14:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18796; Wed, 14 Feb 90 10:59:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 16:49:52 GMT From: usenet news poster Organization: National Library of Medicine, Bethesda, Md. Subject: Help with GNU Emacs for SGI Message-Id: <11434@nlm-mcs.arpa> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've managed to compile GNU emacs 18.55 for the SGI (I have a personal Iris), but to make this reasonable, I need a /emacs/lisp/term file for the iris-ansi terminal type. Does anybody have one? I called SG and they told me to buy their version of emacs; Stallman wouldn't like that, I'm sure.... I need advice on making it recognize mouse clicks and selections. It would also be nice not to have to cons up the entire set of key definitions from scratch. Surely someone must have done this, right? Help is much appreciated: mail to hunter@nlm.nih.gov Thanks! Larry Hunter National Library of Medicine (301) 496-9300 hunter@nlm.nih.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03698; 14 Feb 90 15:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03356; 14 Feb 90 15:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03218; 14 Feb 90 15:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23224; 14 Feb 90 14:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18547; Wed, 14 Feb 90 10:55:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 18:13:49 GMT From: Jim Blue Organization: National Institute of Standards & Technology, Gaithersburg, MD Subject: shademodel Message-Id: <2548@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just got my Personal Iris and was trying to run the examples in the Graphics Library Programming Guide. The very first example bombed with Segmentation Error. The offending line is shademodel(FLAT); If I take out this line, it works. Doing shademodel((long)FLAT); doesn't help. Does shademodel work for others?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03698; 14 Feb 90 15:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03356; 14 Feb 90 15:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03323; 14 Feb 90 15:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23464; 14 Feb 90 14:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15919; Wed, 14 Feb 90 10:14:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 15:55:24 GMT From: "D. Christopher Dunlap" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: X & hotline Message-Id: <4103@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article jim@baroque.Stanford.EDU (James Helman) writes: > >In the future there may be a better way. I was told that SGI might >set up something to provide a target for meta-hotline expressions of >praise, criticism, opinion, etc. Hopefully, this will provide a >mechanism for a more productive expression of frustrations. > For now, consider that "target" to be me. Although I read comp.sys.sgi regularly (As does most of the staff here), I always appreciate direct comments. My address is below. thanks, chris ------------------------------------------------------------------------ D. Christopher Dunlap Product Support Customer Support Division email: dunlap@sgi.com Silicon Graphics Computer Systems or: dunlap@csd.sgi.com D. Christopher Dunlap Product Support Customer Support Division email: dunlap@sgi.sgi.com Silicon Graphics Computer Systems   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad03698; 14 Feb 90 15:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae03356; 14 Feb 90 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac03323; 14 Feb 90 15:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23513; 14 Feb 90 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16085; Wed, 14 Feb 90 10:17:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 16:56:04 GMT From: Sam Fulcomer Organization: Brown University Department of Computer Science Subject: Re: FFT's on 4D/2XX systems Message-Id: <29265@brunix.UUCP> References: <9002122052.AA21651@snow-white.merit-tech.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002122052.AA21651@snow-white.merit-tech.com> goss@SNOW-WHITE.MERIT-TECH.COM (Mike Goss) writes: >In reply to the message from Tom Reed: >> I'm looking for any FFT software that is available and runs on the >> 4D/2XX products. The faster the better especially if it is parallel code or > >The book "Numerical Recipes in C" (also available in FORTRAN and Pascal >versions) has several good FFT routines, although not in a parallelized form. Well, _Numerical_Recipes_ is ok, and I haven't bothered to try to p'ize the f77 codes yet, however it might be worthwhile (I haven't poked them much). It's quite possible that PFA won't like them much. Many numerical packages (IMSL in particular) aren't very adaptable to parallel arches. Another problem with all current (although NAG is working on it, as may be others) numerical packages is that they are not optimized for big-memory problems on cache machines (ie, as matrix size goes up data cache hits go down, as does performance). Algorithms optimized for processing address-regions of data in blocks are the solution to this problem (although monster data caches are another). The important thing to understand when trying to get performance out of a multi-proc SGI is to exactly typify the use which it's seeing when you want the performance. Parallelized code will run well (on a 4-proc system) if it is the only (or nearly only) thing running on the system. If you've got 2 of the beasts running you _may_ still be getting better than single proc performance, but don't bet on it. Don't even bother running if you don't have (effectively) 2 idle processors. I haven't bothered using the PFA since we typically have 2 or 3 things going on at any given time on our 4D/240GTX (64MB) with someone running 4Sight. My experience with it has been limited to bitching at people who've run multi-proc jobs on a busy system (and helping them PFA their code). I am very pleased with the things performance on single proc jobs, though. On an idle system the machine will run 4 copies of the same computation in the same time that only one takes (wall clock). A one-processor job (heavy FPU) seems to take about 2-3 times as much CPU time as on a 3090 with vector proc (the program vectorized on the 3090).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04042; 14 Feb 90 15:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad03356; 14 Feb 90 15:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab03323; 14 Feb 90 15:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23493; 14 Feb 90 14:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16168; Wed, 14 Feb 90 10:18:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 17:56:41 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Power for Iris 220S Message-Id: <50719@sgi.sgi.com> References: <9002140322.AA05845@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002140322.AA05845@physics.phy.duke.edu>, rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: [ Lot's of information about electrical deleted ] > > The bad news, of course, is that our machine doesn't work (still) and > it isn't the power :-( But maybe by tomorrow the nice man from SG will > swap our boards and get us going. I hope so. Thanks very much for the informative posting. As I recall, the info I posted referred to the power distribution unit receptacles in the rear of the unit. Hope that was not too confusing. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson ******************************************************************************** * Disclaimer: Anything I say is my opinion. If someone else wants to use it, * * it will cost... * ********************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04397; 14 Feb 90 16:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04042; 14 Feb 90 15:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03990; 14 Feb 90 15:41 EST Received: from sgi.com by SMOKE.BRL.MIL id aa24886; 14 Feb 90 15:27 EST Received: from relay.sgi.com by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA24472; Wed, 14 Feb 90 12:28:10 PST Received: from forest.sgi.com by relay.sgi.com (5.52/891101.SGI) for @sgi.sgi.com:info-iris@brl.mil id AA19872; Wed, 14 Feb 90 12:28:03 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @relay.sgi.com:info-iris@brl.mil id AA00594; Wed, 14 Feb 90 12:28:02 PST Message-Id: <9002142028.AA00594@forest.sgi.com> To: info-iris@BRL.MIL Subject: Re: X & hotline Date: Wed, 14 Feb 90 12:28:01 PST From: baskett%forest@sgi.com Some of us believe that one of the several useful purposes that info-iris (or comp.sys.sgi) serves is as a sympathetic listener when we want to get some of our frustrations off our chest. Details about problems are desireable to those of us who what to fix them but sometimes they interfere with the release of emotional energy. Of course, apologizing afterward is also nice. Jim Helman is OK. Forest Baskett   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05020; 14 Feb 90 16:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04675; 14 Feb 90 16:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04528; 14 Feb 90 16:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25402; 14 Feb 90 15:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25615; Wed, 14 Feb 90 12:36:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 19:30:33 GMT From: James Helman Organization: Stanford University Subject: Re: SGI's X (Re: X on the Personal Iris) Message-Id: References: <22195@uhnix1.uh.edu>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Ahh luv the smell of napalm in the morning. Be forewarned, I even start my barbie with a blow torch. Seriously. I find it is much more effective than lighter fluid. I won't go into the litany of the "non-specific" problems we've had in several areas. But they were substantial and have a long history. Now that I know where I can send them, I've submitted them to SGI. Hopefully, resolution is just a short release away. I would like to share one divine revelation though. The New Testament says there is one sin which can never be forgiven, but never names it. But, it has been revealed to me. The blackest depths of hell are reserved for those who violate The First Law of Window Systems: A window server shall never dump core except in case of hardware failure or nuclear war. I suppose, DOD might take exception with the latter exclusion. But anyone who has used buggy window systems will agree, that when a window server dies, it's a very bad thing. All that context, jobs in progress, network connections, my very stateful 25MB of LISP and data with two hours of processing time, all go down the toilet. If it happens enough times, it can adversely affect your personality. "Experimental" stuff like MIT's X10R3 server dumped core rather frequently. As did MIT's X11R2 before all the patches made it out. We completely skipped X11R1 because of its reputation. But, at least on our Sun-3's, I don't think I ever got dumped on by MIT's X10R4, X11R3 or X11R4 server. Not bad for code that isn't even commercially supported. Similarly SunView (ok. so it's not a server.) never bombed on me. The same can not be said of any of SGI's X releases to date, although, as I said they are getting better: the MTBD is down by at least factor of ten. Similarly, in all prior 4Sight releases (I haven't seen it yet in 3.2), if you tickled GL the wrong way or even did normal operations on a heavily paging system, grcond would choke, and you would get bombed back to the login prompt. Miss Manners would not approve. As I said about SGI's X. It is now faster and more usable than ever before. The OS is incomparably better than in the IRIS 1400 days, aka the stone age. But if Silicon Graphics aspires to be a big guy, (in the long term, there will only be big guys in the workstation market), it needs not only to offer leading edge performance (which they do better than anyone else) but also offer absolutely top notch software and support. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940 Waiting for perfection, in the meantime: "Man is not at all good. So hit him on the head. If you hit him on the head enough, then perhaps he will become good" - Brecht, The Threepenny Opera   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05487; 14 Feb 90 17:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05293; 14 Feb 90 16:45 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa05221; 14 Feb 90 16:35 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa14522; 14 Feb 90 16:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28990; Wed, 14 Feb 90 13:26:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 14:23:53 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: Power for Iris 220S Message-Id: <883@dftsrv.gsfc.nasa.gov> References: <9002140322.AA05845@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002140322.AA05845@physics.phy.duke.edu> rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: Thanks for the description [[[mostly deleted]]]. >The reasons for running 220V lines in this way are to minimize risk -- >unless you touch two lines simultaneously you can only get a 110V >shock ... In a prior life (before college) I was a marine electrician. The ships I worked on had "two phase" 110V lines. 55V on neutral, and 55V on hot. Again this is for the above saftey reason. The only problem with this is the modifications that needed to be made to convert commercial electrical equipment (radios, coffee pots, etc.) safe (well, actually just a bit more sailor proof :-}). 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 aa05887; 14 Feb 90 17:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05487; 14 Feb 90 17:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05356; 14 Feb 90 16:44 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26040; 14 Feb 90 16:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27945; Wed, 14 Feb 90 13:10:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 20:29:39 GMT From: Viktor Dukhovni Subject: /dev/mmem 666 out of the box. Why? Message-Id: <13851@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Awaiting enlightenment, (but changed it to 640 in the interim!) -- Viktor.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06729; 14 Feb 90 18:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06548; 14 Feb 90 18:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06540; 14 Feb 90 17:49 EST Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa00824; 14 Feb 90 17:46 EST Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA26074; Wed, 14 Feb 90 16:48:45 CST Date: Wed, 14 Feb 90 16:48:45 CST From: Mike Goss Message-Id: <9002142248.AA26074@snow-white.merit-tech.com> To: jac@BRL.MIL Subject: Re: Iris 4D - 80 GTB interface with a PC Cc: info-iris@BRL.MIL In answer to the message: > Date: Wed, 14 Feb 90 9:02:49 EST > From: "John A. Condon" (BDB) > To: info-iris@BRL.MIL > Cc: jac@BRL.MIL > Subject: Iris 4D - 80 GTB interface with a PC > Message-Id: <9002140902.aa12205@TBD.BRL.MIL> > Status: R > > Hello! > > Does anyone out there know how to connect a pc to the Iris 4D? > I don't want to go over the ethernet so I want to be hardwired > utilizing one of the ports on the I/O panel on the Iris. The > question is which port is the right one to use if I want to copy > a file on one of the 4D's removable disks to my pc's Bernoulli > box? Help !!!!!!!!!! > > John (the Jersey Renegade) > For hardware, you need a null modem cable for direct connect, or else a pair of modems. One of the IRIS installation/operation manuals has a diagram of the pin assignments for the IRIS serial port connectors (there are normally 4 ports, numbered 1-4. you can use any one of the 4). Note that the pin assignments on the IRIS are not the same as on the PC, even though the connector is the same type. Once you have the cable, you'll need to have your system administrator enable the getty for the line (in /etc/inittab) and set the speed (I suggest 19200; I've used speed this with no problems). You'll also need a terminal emulator and file transfer protocol. I suggest Kermit because a) UNIX Kermit comes with the IRIS (see 4Dgifts) and b) Kermit is available free for just about any flavor PC (IBM, Mac, Amiga, etc.). If you don't have PC kermit, you can get it via FTP from Columbia University (let me know if you need details). The Kermit protolcol will handle text and binary files. Good Luck! ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06817; 14 Feb 90 18:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06804; 14 Feb 90 18:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06798; 14 Feb 90 18:30 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01403; 14 Feb 90 18:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05380; Wed, 14 Feb 90 14:58:04 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Feb 90 22:30:09 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: shademodel Message-Id: <50750@sgi.sgi.com> References: <2548@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2548@fs1.cam.nist.gov>, blue@cam.nist.gov (Jim Blue) writes: > I just got my Personal Iris and was trying to run the examples in the > Graphics Library Programming Guide. The very first example bombed with > Segmentation Error. The offending line is > shademodel(FLAT); > If I take out this line, it works. Doing > shademodel((long)FLAT); > doesn't help. > > Does shademodel work for others? The usual explanation for this is that you called shademodel() before winopen. Only a few of the window hints are legal to call before winopen. The others require that there be a current window. From your description I cannot tell if this is what you did, but it sure sounds like it. -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07133; 14 Feb 90 20:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07005; 14 Feb 90 20:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06986; 14 Feb 90 19:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01973; 14 Feb 90 19:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12567; Wed, 14 Feb 90 16:42:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 00:13:27 GMT From: "Scott R. Presnell" Subject: Tcpdump / snoop Message-Id: <13096@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've managed to get tcpdump up under IRIX using the snoop(7) interface. If you're interested drop me a line. Note that this is not quite a complete port, there is some nasty casting going on that RISC machines don't like (alignment problems). Consequently, the "net" options don't work. But I think everything else does. If enough people want it, I'll make it available for ftp'ing. Scott Presnell srp@cgl.ucsf.edu 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 aa07280; 14 Feb 90 21:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07205; 14 Feb 90 20:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07194; 14 Feb 90 20:46 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa02616; 14 Feb 90 20:36 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 9722; Wed, 14 Feb 90 19:01:32 CST Received: by UMRVMA (Mailer R2.05) id 9721; Wed, 14 Feb 90 19:01:28 CST Date: Wed, 14 Feb 90 18:50:59 CST From: Bob Funchess Subject: Re: interfacing a PC to a 4D machine To: info-iris@BRL.MIL Message-ID: <9002142036.aa02616@SMOKE.BRL.MIL> The information you need to connect your PC to one of the serial ports on the Iris is located in the owner's manual (of all places...) which is the one that looks different from all the rest, or the ONLY one you get if you don't buy the development system (or so I have heard). It's towards the back. Essentially you need a null modem cable to physically connect the computers, then set up /etc/inittab properly (documented in the manual), at which point you should be all set up for file transfer (use Kermit, it's free for both machines and has worked well for us... MS-Kermit also is a terminal emulation package). 9600 baud works fine, I don't think 19200 does, but I could be wrong about that. HOWEVER... trying to back up a file system over this is going to be an overnight affair at 9600 baud, even if you're only filling one Bernoulli cartridge. 40 MB will take approximately 8 hours at 9600 baud, ignoring protocol overhead. :( < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Be reasonable: if the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07373; 14 Feb 90 21:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07280; 14 Feb 90 21:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07260; 14 Feb 90 20:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02727; 14 Feb 90 20:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16195; Wed, 14 Feb 90 17:36:15 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 00:58:59 GMT From: James Helman Organization: Stanford University Subject: Re: Help with GNU Emacs for SGI Message-Id: References: <11434@nlm-mcs.arpa> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If you really want to make GNU emacs slick and useful, compile it with the X11 support. You'll need to order the X developer's kit, because SGI (unfortunately) unbundled the X include files and libraries from IRIX. Or try using the X11R4 libraries and clients. (I have not tried these with GNU emacs, but it should work.) Don't be discouraged by the extra effort. Having mouse bindings and meta-keys is well worth the hassle of ordering the kit. I also understand that a similar package is available for GNU emacs which allows it to directly use NeWS, but I know next to nothing about it. As for your real question. I don't know enough about wsh's terminal emulation to comment, but I suspect getting mouse events is next to impossible. However, if the function keys generate escape codes, it shouldn't be too hard to hack up an existing "term" file to produce some useful binding. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07574; 14 Feb 90 22:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07543; 14 Feb 90 22:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07511; 14 Feb 90 22:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03205; 14 Feb 90 21:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21193; Wed, 14 Feb 90 18:54:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 02:50:35 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: Screen Snapshot -> how? Message-Id: <22278@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to take a snapshot of the screen, to include in my thesis. Is there anyway to make a screen dump to a file (in PostScript ??)? If you know of any archive with FTP access that has such a program, please let me know. I had to remove our 4Dgifts directory, for lack of space. Is there such a program in there? -- 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. MS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07766; 14 Feb 90 23:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07725; 14 Feb 90 23:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07713; 14 Feb 90 23:16 EST Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa03429; 14 Feb 90 23:02 EST Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA14728; Wed, 14 Feb 90 21:01:40 -0600 Received: by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA08836; Wed, 14 Feb 90 14:28:16 cst Message-Id: <9002142028.AA08836@kailand.kai.com> Organization: KAI, 1906 Fox Drive, Champaign, IL 61820, (217-356-2288) From: Debbie Carr Date: Wed, 14 Feb 90 14:28:11 CST X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: info-iris@BRL.MIL Subject: FFTs on 4D/2XX systems In article <9002121724.AA17444@tom.dallas.sgi.com>, treed%tom.dallas@SGI.COM (Thomas E Reed) writes: > I'm looking for any FFT software that is available and runs on the > 4D/2XX products. The faster the better especially if it is parallel code or > has been parallelized. > Kuck and Associates does have numerical libraries that are optimized for the SGI multiprocessor computers. Our SIGpack library contains more than 165 signal processing routines. These routines are implemented with parallel algorithms tuned specifically to the SGI multiprocessor architecture. The algorithms include: real and complex vector operations, integration, interpolation, merging and polynomial evaluation. SIGpack algorithms also include parallel routines for basic signal and image processing, such as: convolution and correlation, complex and real FFTs (inplace and not inplace), conversion to decibels, and two-dimensional FFTs, convolutions and correlations. The CLASSpack library contains linear algebra and eigenvalue problem solvers. They are blocked parallel algorithms tuned specifically to the SGI multiprocessor architecture with an intermediate fast data cache. The CLASSpack library contains BLAS 1, iterative sparse-matrix and direct skyline solvers, and a general dense out-of-core solver in addition to being completely Linpack and Eispack compatible. Highly-tuned BLAS 2 and BLAS 3 routines are embedded in the library, and will soon be available as a standalone library. Version 1.0 of SIGpack and CLASSpack for SGI multiprocessor machines is currently available. For more technical information, performance data and introductory price quotes, please contact Ms. Debra Carr (dcarr@kai.com), Kuck and Associates, 1906 Fox Drive, Champaign, Illinois, 61820. Tel. (217) 356-2288, FAX (217) 356-5199. -- Debra Carr dcarr@kai.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08087; 15 Feb 90 0:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08044; 15 Feb 90 0:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07913; 15 Feb 90 0:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03612; 14 Feb 90 23:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27313; Wed, 14 Feb 90 20:37:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 04:36:43 GMT From: Jean-Francois Lamy Subject: Re: rdump again Message-Id: <90Feb14.233620est.6765@neat.cs.toronto.edu> References: <4984.25d805b2@uwovax.uwo.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL weimei@uwovax.uwo.ca writes: > It seemed I have only caught the tail part of the > "rtar & rdump" discussion. Can any kind soul out > there tell me: > Is there a public domain rdump for SGI? > If YES, where can i get it? Yes there is an rdump, and no you can't get it for free. We usually gladly give away stuff that does not require access to the source to be written. But given that we had to shell out big bucks (for us) to get the SGI source, it does seem unfair that we should pay for the source and then freely distribute work we couldn't have done without having access to source. We are increasingly aware of this now that a SGI salesperson inquired about the availability of our BSD/SunOS/GNU emulations and/or ports so that he could point someone at another BSD/SunOS shop at us for that software, in an effort to woo them and sell them SGI boxes. So you'll have to wait until SGI sees the light and supports this, which they may be convinced to do in due course, or give us something we consider to be of value so we aren't subsidizing you by providing you with our work. Contact lab@cs.toronto.edu if you are willing to do so. Hmm. Maybe a Toronto Software Distribution for SGIs... Jean-Francois Lamy lamy@cs.utoronto.ca, uunet!cs.utoronto.ca!lamy Department of Computer Science, University of Toronto, Canada M5S 1A4 non-disclaimer: The opinions expressed here are *not* mine alone.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17528; 15 Feb 90 15:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17274; 15 Feb 90 15:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17247; 15 Feb 90 14:46 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa20818; 15 Feb 90 14:37 EST Received: Wed, 14 Feb 90 06:18:57 -0800 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Wed, 14 Feb 90 09:18:42 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Wed, 14 Feb 90 09:38:51 EST by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Wed, 14 Feb 90 09:38:51 EST From: Tony Facca Message-Id: <9002141438.AA26677@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: 1/4 inch tape drive Cc: iris-admin@lerc08.lerc.nasa.gov As long as we're on the subject... Has anyone ever used (or heard of anyone who has ever used) a 1/4 tape drive unit from Wangtek ("Where Good Ideas Get Delivered."), model 5150ES in a Personal Iris?? They are claiming to be a low priced ($950) replacement for the drive used by SGI. I have more specs on this unit than I do on the one SGI provides, and it appears to be a viable alternative. Breifly: Max formatted capacity: 250 MB Data cartridge type: DC 6250 Recording Tracks: 18 Track Serpentine Recording Formats: QIC-150, QIC-120 Read Compatibility: QIC-120, QIC-24 R/W Speed: 90ips Recording Code: GCR Transfer Rate: 1.8 MB per second Data Buffer Size: 64 KB Search/Rewind Speed: 90ips Non-recoverable read error rate: no more than 1 in 10^11 bits MTBF > 15,000 POH, 15% tape motion MTTR < 30 minutes [ there's more, but its environmental and power requirements ] Physical: 5.25" half-height 1.625"H x 5.750"W x 8.300"D x 2.4 lbs. I'd appreciate any TECHNICAL comments on why this drive may not be appropriate. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11023; 15 Feb 90 8:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09690; 15 Feb 90 7:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09515; 15 Feb 90 7:02 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa05899; 15 Feb 90 6:51 EST Received: from DBTHRZ5.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3515; Thu, 15 Feb 90 06:50:30 EST Date: 15 FEB 90 12:51-MEZ From: BTP801%DBTHRZ5.BITNET@cunyvm.cuny.edu To: INFO-IRIS@BRL.MIL Subject: keyboard repetition rate Message-ID: <9002150651.aa05899@SMOKE.BRL.MIL> Date: 15-FEB-1990 12:50:16.55 From: BTP801 AT DBTHRZ5 To: BITNET::"info-iris@BRL.MIL" Subj: keyboard repetition rate Is there a way to speed up the boring slow repetition rate of the keyboard of a PI. We have a 4D70 too, on this keyboard the repetition rate is ok. Harald Kaul Experimentalphysik IV Universitaet Bayreuth   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15383; 15 Feb 90 12:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15098; 15 Feb 90 12:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15054; 15 Feb 90 12:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15461; 15 Feb 90 11:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08524; Thu, 15 Feb 90 08:54:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 16:52:42 GMT From: Steve Hayman Organization: Computer Science Department, Indiana University Subject: Status of 'flight' source Message-Id: <35941@iuvax.cs.indiana.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I recently came across a version of 'flight', 'dog' et al that had been ported to Suns. It runs reasonably well on a colour GX Sparcstation although it doesn't fill the polygons so a lot of the realism is lost. Whoever did this port (there is no author listed in the code) implemented a simple library to emulate SGI graphics. The rest of the source seems to be the real 'flight' source. I'm sure that this would be an extremely popular program if I were to install it on our public Sparcstation cluster. What disturbs me is comments like this in the original source: /************************************************************************** * * * Copyright (C) 1983, Silicon Graphics, Inc. * * * * These coded instructions, statements, and computer programs contain * * unpublished proprietary information of Silicon Graphics, Inc., and * * are protected by Federal copyright law. They may not be disclosed * * to third parties or copied or duplicated in any form, in whole or * * in part, without the prior written consent of Silicon Graphics, Inc. * * * **************************************************************************/ Does anybody know whether this source really is something that can be distributed? I'm a strong believer in copyright protection and don't want to install this if the code really is proprietary. Thanks for any advice. Please respond by mail and I'll summarize. Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16990; 15 Feb 90 14:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15571; 15 Feb 90 12:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15509; 15 Feb 90 12:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16228; 15 Feb 90 12:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09997; Thu, 15 Feb 90 09:17:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 14:46:29 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: interfacing a PC to a 4D machine Message-Id: <899@dftsrv.gsfc.nasa.gov> References: <9002142036.aa02616@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We use Sun PC-NFS on a pair of PC clones, and on an Amiga all running over ethernet. The hard disk of the IRIS appears as one (or more) disk drives on the clone or Amiga. I haven't done any timing tests, but the NFS drives seem slightly slower than the local hard disks. The single biggest problem (aside from never having enough disk space :-) is the PC wants and the IRIS uses only . I just wish the other problems we have were as easy to solve. I have no finacial interest in Sun, any other PC-NFS vendor, SGI, Commodore, IBM, clone manufacutures, ... 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 aa18794; 15 Feb 90 17:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18667; 15 Feb 90 17:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18649; 15 Feb 90 17:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25670; 15 Feb 90 17:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27653; Thu, 15 Feb 90 13:58:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 09:05:28 GMT From: Scott Henry Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Help with GNU Emacs for SGI Message-Id: References: <11434@nlm-mcs.arpa> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL LH> I've managed to compile GNU emacs 18.55 for the SGI (I have a personal LH> Iris), but to make this reasonable, I need a /emacs/lisp/term file for LH> the iris-ansi terminal type. Does anybody have one? I called SG and LH> they told me to buy their version of emacs; Stallman wouldn't like LH> that, I'm sure.... LH> I need advice on making it recognize mouse clicks and selections. It LH> would also be nice not to have to cons up the entire set of key definitions LH> from scratch. Surely someone must have done this, right? LH> Help is much appreciated: mail to hunter@nlm.nih.gov LH> Thanks! Shortly after I got GNU Emacs up on my 4D, I hacked up term/vt100.el to work within a wsh window using wsh as a terminal emulator. It doesn't support mouse-stuff except that which a wsh supports. Place the following in lisp/term as iris-ansi.el, and make a hard link as iris-ansi-net.el. I did try porting NeWS-mode, but 4Sight is sufficiently different from Sun's NeWS (and I am definitely NOT a NeWS hacker) that I coudn't get it ported in the time I had available. The X11 interface works fine (if you add the recently posted patch to reduce the (*&^(*&^) beep volume, but I miss the extra arrow-key bindings. ;; term/iris-ansi.el ;; term/iris-ansi-net.el ;; Map Iris 4D function key escape sequences from a wsh ;; into the standard slots in function-keymap. ;; This is just a hacked-up version of vt100.el so as to use the 4D ;; keyboard escape sequences (and some added keys). ;; This software is in the public domain. ;; It is not supported by Silicon Graphics, Inc. ;; Hacker: Scott Henry (require 'keypad) (defvar Iris-CSI-map nil "The Iris-CSI-map maps the CSI function keys on the Iris 4D keyboard. The CSI keys are the arrow keys.") (if (not Iris-CSI-map) (progn (setq Iris-CSI-map (lookup-key global-map "\e[")) (if (not (keymapp Iris-CSI-map)) (setq Iris-CSI-map (make-sparse-keymap))) ;; [ commands (setup-terminal-keymap Iris-CSI-map '(("A" . ?u) ; up arrow ("B" . ?d) ; down-arrow ("C" . ?r) ; right-arrow ("D" . ?l) ; left-arrow ("H" . ?h) ; home key ("161q" . ?P) ; shift up arrow ("164q" . ?N) ; shift down arrow ("158q" . ?1) ; shift left arrow ("167q" . ?3) ; shift right arrow ("150q" . ?P) ; page up key ("154q" . ?N) ; page down key ("159q" . ?\C-a) ; control left arrow ("168q" . ?\C-b) ; control right arrow ("139q" . ?0) ; insert key ("162q" . ?7) ; control up arrow ("165q" . ?9) ; control down arrow ("146q" . ?\C-c) ; end key ("147q" . ?f) ; shift end key ("P" . ?\C-d) ; shift delete ("142q" . ?k) ; control delete ("143q" . ?u) ; shift home ("144q" . ?u) ; control home )))) (defun enable-arrow-keys () "Enable the use of the VT100 arrow keys for cursor motion. Because of the nature of the VT100, this unavoidably breaks the standard Emacs command ESC [; therefore, it is not done by default, but only if you give this command." (interactive) (global-set-key "\e[" Iris-CSI-map)) -- Scott Henry | These are my | Tardis Express -- when it Information Services, | Opinions only!| absolutely, positively Silicon Graphics, Inc | Whose else? | has to be there -- yesterday.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18885; 15 Feb 90 18:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18667; 15 Feb 90 17:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18642; 15 Feb 90 17:22 EST Received: from CS.NPS.NAVY.MIL by SMOKE.BRL.MIL id aa25625; 15 Feb 90 17:08 EST Received: by cs.nps.navy.mil (5.51/1.26) id AA05667; Thu, 15 Feb 90 14:09:25 PST Date: Thu, 15 Feb 90 14:09:25 PST From: Roger Dixon Message-Id: <9002152209.AA05667@cs.nps.navy.mil> To: info-iris@BRL.MIL Subject: AI on IRIS Cc: zyda@cs.nps.navy.mil I am a master's student at the Naval Postgraduate School currently working on a defense planner using an IRIS 4D/70G as the interface. I was wondering if anyone knows of a full implementation of Common Lisp or a version of Prolog that currently works on a 4D. Please send E-mail. Thanks in advance. Roger Dixon dixon@cs.nps.navy.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19139; 15 Feb 90 18:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18349; 15 Feb 90 17:04 EST Date: Thu, 15 Feb 90 16:54:26 EST From: "Lee A. Butler" To: info-iris@BRL.MIL Subject: Compiler error under 3.2 Message-ID: <9002151654.aa18319@VMB.BRL.MIL> I have some code that will cause the C compiler to bomb with the following "self explanatory" message: Fatal error in: /usr/lib/ccom - core dumped The odd thing is that the problem with the file is a typographical error in a parameter structure pointer declaration. Ordinarily, I would expect something a little more graceful (if not more explanatory) to happen. If anyone at SGI is interested in getting a copy of this file and looking into the reasons for the "problem" I would be more than happy to help. Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19407; 15 Feb 90 19:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19340; 15 Feb 90 19:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19317; 15 Feb 90 19:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27197; 15 Feb 90 19:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06743; Thu, 15 Feb 90 16:12:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Feb 90 21:09:37 GMT From: Gretchen Helms Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: shademodel Message-Id: <4196@odin.SGI.COM> References: <2548@fs1.cam.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL (Jim Blue) writes: >I just got my Personal Iris and was trying to run the examples in the >Graphics Library Programming Guide. The very first example bombed with >Segmentation Error. The offending line is > shademodel(FLAT); >If I take out this line, it works. Doing > shademodel((long)FLAT); >doesn't help. If you are referring to the sample program "red.c" on page I-5 in the Introduction, that is what we refer to as a "documentation bug", and already has a bug report filed on it by myself. >Does shademodel work for others? Essentially, the call to shademodel(FLAT) MUST occur AFTER the call to winopen. If you call it BEFORE winopen, it will toss its cookies and die. I will do my best to get this fixed in the next documentation update. G. "Murdock" Helms A host is a host & from coast to coast Silicon Graphics No one will talk to a host that's close Product Support Engineer Unless the host (that isn't close) ghelms@sgi.sgi.com Is busy, hung or dead. -D. Lesher   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19508; 15 Feb 90 20:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19407; 15 Feb 90 19:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19380; 15 Feb 90 19:38 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27313; 15 Feb 90 19:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06795; Thu, 15 Feb 90 16:13:54 -0800 Received: from USENET by 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 Feb 90 00:12:33 GMT From: Ken Lalonde Organization: Department of Computer Science, University of Toronto Subject: IRIX 3.2: new directory blocks not zeroed? Message-Id: <90Feb15.191156est.6155@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Unused space in newly created directories under IRIX 3.2 appears to contain data leftover from recently removed files. When I run the following a few times on two of our 4D machines and one PI (all with /tmp on the root SCSI disk), the "cat -v foo" prints part of the passwd file. % cd /tmp % cp /etc/passwd . # any large text file will do % rm passwd % mkdir foo % cat -v foo Bad news if you care about filesystem security.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20730; 16 Feb 90 0:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20635; 16 Feb 90 0:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20601; 16 Feb 90 0:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00903; 15 Feb 90 23:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24704; Thu, 15 Feb 90 20:54:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 90 04:31:41 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: IRIX 3.2: new directory blocks not zeroed? Message-Id: <905@dftsrv.gsfc.nasa.gov> References: <90Feb15.191156est.6155@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Feb15.191156est.6155@neat.cs.toronto.edu> ken@cs.toronto.edu (Ken Lalonde) writes: > > % cd /tmp > % cp /etc/passwd . # any large text file will do > % rm passwd > % mkdir foo > % cat -v foo > >Bad news if you care about filesystem security. Poor example, but the point is illustrated. I could not read the Ex.... files that 'vi' uses with the above technique. What I could do was read part of someone elses (mode 600) file that was placed there and removed. So we need a deamon that sits in /tmp waiting for files to be deleted :-), How do we monitor /tmp files? No! No! No! don't answer this; this discussion showed up in comp.unix.wizards. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa27897; 16 Feb 90 13:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26780; 16 Feb 90 12:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26695; 16 Feb 90 12:08 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa10870; 16 Feb 90 11:42 EST Received: from HGRRUG52.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2369; Fri, 16 Feb 90 11:41:35 EST Date: Fri, 16 Feb 90 17:48 N From: TORDA%HGRRUG52.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Batch system NQS for iris and others To: INFO-IRIS@BRL.MIL X-Original-To: INFO-IRIS@BRL.MIL Message-ID: <9002161142.aa10870@SMOKE.BRL.MIL> A question about the availability of a batch sytem: There is a batch system called Network Queueing Service (NQS) which is either available for new iris's or will be soon. It is running on many machines and works well on our convex C-220. It is written by Sterling software, I believe under commission from NASA. Our intention would be to run it on a new iris server. My question is the following: From some scanty documentation it would seem possible to set this thing up so a little workstation could feed a queue running on one of the iris servers. This would require NQS to run on the little machine. Does anyone know more about this product ? Is it possible to feed an Iris queue from another vendor machine ? Is there a specific name and address for someone at either NASA or Sterling software who would know more ? Thanks for any advice or pointers to more info. -Andrew Torda (bitnet) torda@hgrrug52   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28558; 16 Feb 90 14:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28262; 16 Feb 90 14:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28093; 16 Feb 90 14:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13363; 16 Feb 90 13:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06402; Fri, 16 Feb 90 09:53:19 -0800 Received: from USENET by 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 Feb 90 17:48:30 GMT From: Steve Hayman Organization: Computer Science Department, Indiana University Subject: Re: Status of 'flight' source Message-Id: <36080@iuvax.cs.indiana.edu> References: <35941@iuvax.cs.indiana.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thank you to everyone who replied. I even got a phone call from the author of 'flight'. It's pretty obvious that this source is not supposed to be publically available. SGI will let their customers have the source but the customers must sign a non-disclosure agreement. Somebody out there has ignored this agreement and made their Sparcstation version of 'flight' publically available. I've deleted the program from our machines here and have urged the site I ftp'd it from to do the same. It was fun while it lasted. 'flight' is a great program. Although we don't have any Irises here at the moment, we had one where I used to work. My heart would really start pounding when I tried to land the F-18. Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00331; 16 Feb 90 16:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29594; 16 Feb 90 16:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29552; 16 Feb 90 16:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16796; 16 Feb 90 15:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16092; Fri, 16 Feb 90 12:28:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 90 15:20:33 GMT From: Michael Johnson Organization: University of Virginia Subject: pcnfs>backup>exabyte Message-Id: <1990Feb16.152033.9741@murdoch.acc.Virginia.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just observed a problem and thought that I would post it and see if anyone has solved it. I am attempting to backup my IBM-PC disk to the tapedrive on my SGI. The software I am using is SUN's pc-nfs with the lifeline backup option. It all works fine as long as I write to the cartridge tape (tps0d7ns). However, it fails to write to our 8 mm tape, i.e. SGI supported exabyte drive (tps0d6ns). The error message is "LL011F : Write failed". Also the SGI can read and write to the exabyte with no problems. The SGI is a Turbo-16 server (4D-80) running 3.1D of operating system. Presumeably, the problem is the long start and stop time of the exabyte drive. Any ideas on how to solve the problem? -- (804)-924-8607 Michael L. Johnson mlj8e@mljsg.pharm.Virginia.EDU Pharmacology Dept. mlj8e@Virginia.BITNET Box 448; Univ. of Va. Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01529; 16 Feb 90 19:20 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01333; 16 Feb 90 18:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01199; 16 Feb 90 18:02 EST Received: from ANCHOR.RUTGERS.EDU by SMOKE.BRL.MIL id aa19998; 16 Feb 90 17:46 EST Date: Fri, 16 Feb 90 14:52 EST From: STEARNS@BIOVAX.RUTGERS.EDU Subject: Public Line Printer Spooler To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <9002161746.aa19998@SMOKE.BRL.MIL> Has anyone brought up this software from Prof. Powell at the University of Minnesota on an SGI? If so, how were the changes from curses.h to termio.h, which appear in print_support.c, handled? Thanks for any help -- Tim Stearns   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02078; 16 Feb 90 21:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01984; 16 Feb 90 21:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01956; 16 Feb 90 21:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21670; 16 Feb 90 20:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05724; Fri, 16 Feb 90 17:35:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 90 20:29:08 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: keyboard repetition rate Message-Id: <4256@odin.SGI.COM> References: <9002150651.aa05899@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002150651.aa05899@SMOKE.BRL.MIL>, BTP801@DBTHRZ5.BITNET writes: > Subj: keyboard repetition rate > Is there a way to speed up the boring slow repetition rate of the keyboard > of a PI. We have a 4D70 too, on this keyboard the repetition rate is ok. > > Harald Kaul The next major (x.y) software release has user-settable software repeat because of this problem. I'm hopeful that future hardware will not make the same mistake. -- 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 aa02538; 16 Feb 90 23:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02232; 16 Feb 90 22:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02203; 16 Feb 90 21:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22166; 16 Feb 90 21:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AB09588; Fri, 16 Feb 90 18:37:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Feb 90 02:27:21 GMT From: Mike Thompson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIX 3.2: new directory blocks not zeroed? Message-Id: <51058@sgi.sgi.com> References: <90Feb15.191156est.6155@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Feb15.191156est.6155@neat.cs.toronto.edu>, ken@cs.toronto.edu (Ken Lalonde) writes: > Unused space in newly created directories under IRIX 3.2 appears to > contain data leftover from recently removed files. When I run the > following a few times on two of our 4D machines and one PI (all with > /tmp on the root SCSI disk), the "cat -v foo" prints part of the passwd file. > > % cd /tmp > % cp /etc/passwd . # any large text file will do > % rm passwd > % mkdir foo > % cat -v foo > > Bad news if you care about filesystem security. Yes, bad news. This has been fixed in the next-release software. Mike Thompson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04434; 17 Feb 90 7:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04245; 17 Feb 90 6:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04235; 17 Feb 90 6:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25710; 17 Feb 90 6:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07252; Sat, 17 Feb 90 03:23:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 90 22:41:50 GMT From: Michael Fong Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Compiler error under 3.2 Message-Id: <4274@odin.SGI.COM> References: <9002151654.aa18319@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Syntax errors which cause ccom to core dump, huh? The nice thing about such bugs is that they are easy to isolate and submit as a tidy little test case. Please phone it into the Customer Support Hotline so we can fix it. ~ mjf@sgi.com Michael Fong ~ ~ ____ ~ ~ /_|__\--, ~ ~ "my books, my beautiful books" []Oo. `0-----0' ~   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04981; 17 Feb 90 11:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04788; 17 Feb 90 10:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04778; 17 Feb 90 9:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26718; 17 Feb 90 9:27 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14483; Sat, 17 Feb 90 06:17:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 90 14:05:59 GMT From: Tracy Schuhwerk Organization: SDRC, Cincinnati Subject: Just got an IRIS 4D/80GT Message-Id: <1141@sdrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just got an IRIS 4D/80GT in my office yesterday and now I am lacking in toys/nifty applications/stuff (but the trade was pretty good... an IBM PC/RT for the 4D/80GT!). I was wondering if some of the SGI fans out there would see fit to mail me nice PD applications that they can find the time to scrape up. I have all of the nifty demo stuff and a few other things but not much other than that. I am looking for a VT100 emulator (so I can use the IRIS to get on the VAXs and edit things). Thanks in advance! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________ / / / | UUNET: / (___ _ /_ /_ _ __ /_/ | uunet!sdrc!evtracy / . _____)__(__/ /__/_/_/ /__/_/_/__(/__/ (__/ \ +------------------- Mobius Recursive Software - Making Yesterday's Tomorrows Today(tm) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01324; 18 Feb 90 14:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01041; 18 Feb 90 13:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01032; 18 Feb 90 13:02 EST Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa05493; 18 Feb 90 12:32 EST Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA02972; Sun, 18 Feb 90 11:26:33 CST Date: Sun, 18 Feb 90 11:26:33 CST From: Mike Goss Message-Id: <9002181726.AA02972@snow-white.merit-tech.com> To: info-iris@BRL.MIL, sdrc!evtracy@uunet.uu.net Subject: Re: Just got an IRIS 4D/80GT Regarding the message: > Date: 16 Feb 90 14:05:59 GMT > From: Tracy Schuhwerk > Organization: SDRC, Cincinnati > Subject: Just got an IRIS 4D/80GT > Message-Id: <1141@sdrc.UUCP> > > . > . > . > > I just got an IRIS 4D/80GT in my office yesterday and now I am lacking > in toys/nifty applications/stuff (but the trade was pretty good... an > IBM PC/RT for the 4D/80GT!). I was wondering if some of the SGI fans > out there would see fit to mail me nice PD applications that they can > find the time to scrape up. I have all of the nifty demo stuff and a > few other things but not much other than that. I am looking for a > VT100 emulator (so I can use the IRIS to get on the VAXs and edit things). > . > . > . There are two ways to get VT100 emulation. If you have a network hookup to your VAX, you can just use telnet (or whatever the DECNET equivalent is, if you have DECNET on your Iris) from a wsh window. Wsh does a reasonably good emulation of a VT100. If you are using a serial port hookup, look in your 4Dgifts directory, where you'll find a copy of Kermit. I think Kermit will allow you to do an outgoing serial port connection emulating a VT100. It will also do ASCII and binary file transfers. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00094; 18 Feb 90 17:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01426; 18 Feb 90 15:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01408; 18 Feb 90 14:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06121; 18 Feb 90 14:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12761; Sun, 18 Feb 90 11:31:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Feb 90 19:28:01 GMT From: Seth Teller Organization: University of California at Berkeley Subject: help with 4d/70 kernel panic Message-Id: <22232@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL on a 4D/70 gt w/ 16 meg, which sits quiet for a day or so, we get a kernel panic: PANIC: Kernel Fault PC: 0x80068808 'Read Address Error' Bad Addr: 0x19 Cause: 0x300000010 SR: 0xFF34 has anyone seen this before? what would be some likely suspects (particular microcode, a rarely-woken but corrupt daemon, etc.)? also, what can be done with the files written to /usr/adm/crash? i tried cd'ing there, renaming vmcore.n to core, and running dbx on the unix.n i found there. but this doesn't seem right, and in any case doesn't produce any noticeably useful effect. thanks much for any help you can offer, seth teller   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02358; 19 Feb 90 6:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02008; 19 Feb 90 4:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01997; 19 Feb 90 4:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09836; 19 Feb 90 3:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26726; Mon, 19 Feb 90 00:44:22 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 90 06:49:53 GMT From: Stephen Samuel Organization: U. of Alberta: Biochemistry , Edmonton, AB Subject: Re: shademodel Message-Id: <1990Feb19.064953.2125@cs.UAlberta.CA> References: <2548@fs1.cam.nist.gov>, <50750@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <50750@sgi.sgi.com>, tarolli@riva.esd.sgi.com (Gary Tarolli) writes: > In article <2548@fs1.cam.nist.gov>, blue@cam.nist.gov (Jim Blue) writes: > > I just got my Personal Iris and was trying to run the examples in the > > Graphics Library Programming Guide. The very first example bombed with > > Segmentation Error. The offending line is > > shademodel(FLAT); > > The usual explanation for this is that you called shademodel() before winopen. > Only a few of the window hints are legal to call before winopen. The others > -- > Gary Tarolli Yep, this sounds like the right explanation, but what really bothers me is WHY CAN'T WE GET MEANINGFUL ERROR MESSAGES????? Something like 'Illegal call with no window open' would help users to solve a problem without beating their head against a wall or calling the hotline. If it's possible to identify the graphics call that's blowing up, then this helps even more. Since your documentation doesn't always clearly state what can, or cannot be called before a window open (hint, hint!), there is even more reason to encourage reasonable error messages. Stephen samuel (userzxcv@ualtamts.bitnet or alberta!obed!steve) -- Stephen samuel (userzxcv@ualtamts.bitnet or alberta!obed!steve)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04630; 19 Feb 90 14:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03868; 19 Feb 90 13:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03841; 19 Feb 90 13:16 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13318; 19 Feb 90 12:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23385; Mon, 19 Feb 90 09:33:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 90 16:57:22 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: shademodel Message-Id: <51153@sgi.sgi.com> References: <2548@fs1.cam.nist.gov>, <50750@sgi.sgi.com>, <1990Feb19.064953.2125@cs.UAlberta.CA> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL . . . > Yep, this sounds like the right explanation, but what really bothers me is > WHY CAN'T WE GET MEANINGFUL ERROR MESSAGES????? > Something like 'Illegal call with no window open' would help users to > solve a problem without beating their head against a wall or calling the > hotline. If it's possible to identify the graphics call that's blowing > up, then this helps even more. > > Since your documentation doesn't always clearly state what can, or cannot > be called before a window open (hint, hint!), there is even more reason > to encourage reasonable error messages. > The graphics call that blew up can be identified by using dbx on the core file. A stack track should readily identify the offending routine. As for the error messages, here's the reason. Some of the GL calls, eg. v3f have to be called at a very rapid rate (> 1 million per second) to achieve the graphics performance the hardware can deliver. Putting in something as simple as an "if" test and worse yet a subroutine call (even if its not taken it will make the routine a non-leaf routine which adds lots of code to the procedure's entry and exit code), will seriously degrade performance. Although there are many routines that are not performance critical, there are also many many things to test for. The code would not be easy to implement - imagine the problem of checking for a valid pointer - you should really try to access the data while catching segv signals - but what if the user is also catching segv signals? etc etc. However, your point is valid - we need better error messages and parameter checking. Rather than add code to the GL, most of us would prefer to build an alternate GL that could be used for debugging. THus the performance of the real GL would not be affected. This debugging GL would only be used while debugging. It could be implemented as a separate library, for those who don't use the shared lib, or as a "somehow switchable" part of the shared library that could be activated when desired, or as a DGL filter. We have many options here, however I cannot promise anything soon. Make your voice heard by calling the HOTLINE and requesting 2 things: 1) a GL error message/debugging guide, preferrably 50-100 pages worth 2) a version of the GL library that does error checking as described above. -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05872; 19 Feb 90 15:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05710; 19 Feb 90 15:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05684; 19 Feb 90 15:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14199; 19 Feb 90 15:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02932; Mon, 19 Feb 90 12:08:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 90 20:04:33 GMT From: Tim Hall Organization: Boston University Computer Graphics Lab Subject: Event Queue Message-Id: <52418@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How can I get the INPUTCHANGE event to occur when a mouse button is being held down? Is it possible at all? If the above is not possible, I can determine which of my windows the cursor is in. ( MOUSEX/MOUSEY still generate events with a mouse button down ) However if the cursor is in an area where two windows overlap how do I know which window is on top, and thus which window the cursor is in? I know I could force it using winpush/winpop but that's rather ugly. -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09048; 19 Feb 90 18:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08707; 19 Feb 90 18:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08541; 19 Feb 90 18:28 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15620; 19 Feb 90 18:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13148; Mon, 19 Feb 90 15:05:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 90 22:39:19 GMT From: Paul Jackson Organization: Silicon Graphics, Research & Development Subject: Re: Batch system NQS for iris and others Message-Id: <4330@odin.SGI.COM> References: <9002161142.aa10870@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002161142.aa10870@SMOKE.BRL.MIL>, TORDA@HGRRUG52.BITNET writes: > A question about the availability of a batch sytem: > There is a batch system called > Network Queueing Service (NQS) > which is either available for new iris's or will be soon. > Our intention would be to run it on a new iris server. > My question is the following: > From some scanty documentation it would seem possible to set this > thing up so a little workstation could feed a queue running on one of > the iris servers. This would require NQS to run on the little machine. > Does anyone know more about this product ? > Is it possible to feed an Iris queue from another vendor machine ? > -Andrew Torda (bitnet) torda@hgrrug52 We at Silicon Graphics anticipate releasing a port of NQS as an option later this year. The product has begun testing at limited sites. It supports network queuing, from a workstation to a server. The results of our interoperability testing with other vendor's machines are not available yet - we're hopeful but no promises yet. Contact Dan Vivoli (danv@sgi.com) for information. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10810; 20 Feb 90 0:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10489; 19 Feb 90 23:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10471; 19 Feb 90 23:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17397; 19 Feb 90 23:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00793; Mon, 19 Feb 90 19:58:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 90 03:54:29 GMT From: Brian Sturgill Organization: University of Utah CS Dept Subject: Security questions, suggestions, and concerns. Message-Id: <1990Feb19.205429.21987@hellgate.utah.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am looking for ways to make our SGI machines have a reasonable level of security. This is currently not the case because:: 1) The out-of-the-box setup makes it trivial for any user to become super-user just by booting the machine to the single user init level. 2) There may be functions in the diagnostic/software installation menus provided in the monitor that may allow similar breaches of security. (However, I know of none at this time.) 3) A lack of caution in the design of suid programs causes at least one major hole that could be exploited without rebooting. (Sorry for being vague, but being the least bit explicit would give the bug away to the "bad guys" too... If you want details send me mail identifing yourself as a responsible individual, the message should come from root. The machine you send the root mail from should be a machine I can recognize as belonging to a reputable place. I will then send a message back to root that will explain the problem.) 4) A ridiculous limit on group user lists, limiting them to not more than 200 characters makes it impossible to use group protection schemes for groups of more than around 20 people. Problem (1) bothers us the most at the moment; we have thought of several possible ways to deal with the problem but would like to see if better ways exist. It would also be nice if a discussion about such problems in general would ensue, hopefully resulting in SGI taking security issues a bit more seriously. So far, SGI has not been very helpful with this sort of problem. For example when (4) was reported here is a sample of the kind of response I got: ---------------- > you are right. > in libsun, getpwent and getgrent (etc.) use a 200 char buffer > instead of libc's 8k. SGI reduced the size in order to close a > bug that complained about inordinately large data segments in > small programs--claimed it resulted in bad virtual memory usage... > perhaps 200 is too small. > could you give me an idea of what a better upper bound would be? --------------- > hi. > i just filed SCR #8931. > that's the bug number. > i requested that the buffer be raised to 1K. > > refer to that number--give the bug report about a month-- > and cb in. at that time it will have a response-- added to it. > the response will say if there is a fix and what release it will > be included on. > > i will close out the call C0030. --------------- (After griping about the "We'll tell you if-and-when a --------------- month from now") The final answer from SGI was: > hello. > you will need to wait for the next release of software to > get the fix you requested. > it was not included in the 3.2.2 fixes tape. the 3.2.2 fixes tape > is not out the door yet, but is frozen. > > as a workaround, make the long groups (reada1, execa1) have no members. > newgrp won't be necessary to access files owned by those groups, just > a matching effective group-id or owner or other perm. matches. > > the drawback is that anyone can then "newgrp reada1', not just the users > in the long list. you could put a passwd on group--but it's not well > supported. (see newgrp(1M). ---------------- The "workaround" suggested is absurd, it defeats the whole purpose of having the groups in the first place. On my own I worked-out a partial solution... Make two groups X and Y that have the same group id, where X is the name of the original group. Split the original members of X between X and Y. Have X appear first in /etc/group. This works for most purposes. (Though if you run YP, I am not sure that X ought necessarily appear first in the file, as YP uses a hashing scheme). Due to this kind of response I have not yet bothered to report (3), but instead fixed it by making my own version of the offending program. Solutions considered for (1) include: a) Making a fake /etc/init that intercepts single user boots and requires the entry of the super user password before execing the real /etc/init. b) Modifying the /etc/init binary /bin/zz instead of /bin/sh for single user boots, so that /bin/zz can first require the super-user password. c) Perhaps an entry in inittab could be used to get the required password. I have not tried any of these yet as it involves guess work, and would have to be redone every time a new distribution came out. My hope is that either there is a better way I have missed, or else that SGI will decide to put in an option similar to Sun's, so that if the console does not have "secure" in /etc/ttytab then the super-user password is required before the single-user shell is available. Brian Sturgill brian@cs.utah.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00393; 21 Feb 90 10:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29595; 21 Feb 90 10:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa29508; 21 Feb 90 9:56 EST Received: from uunet.UU.NET by SMOKE.BRL.MIL id aa18843; 21 Feb 90 9:44 EST Received: from lsr-vax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA07354; Wed, 21 Feb 90 09:45:44 -0500 Received: from lsr-sund. by (4.1/SMI-4.0) id AA15320; Mon, 19 Feb 90 17:31:16 EST Date: Mon, 19 Feb 90 17:31:16 EST From: Art Hays - PSTAFF Message-Id: <9002192231.AA15320@> To: uunet!brl.mil!info-iris@uunet.uu.net Subject: Re: Power for Iris 220S Cc: art@uunet.uu.net "Robert G. Brown" writes: > This wiring uses two out of three legs of a "three phase 220" > circuit. This is typical output of a "Wye" transformer and is common > in Universities and offices. Again, there may or may not be a current > carrying neutral allowing it to be split into three 120V lines. The > potential difference is: > 120V sin(wt) - 120V sin(wt + 2Pi/3) = 207.8V sin(wt + Pi/3) While on the subject of power, another interesting topic is neutral heating due to switching power supplies. The typical three phase wye transformer has the same guage wire for the phases and neutral. The assumption is that if the loads on all the phases are equal, there will be very little current flow in the neutral. Panels have all three phases in them, and the breakers alternate which phase they connect to. The current waveform of a switching power supply is far from a sine wave. It draws current in brief periods near the peak of the voltage waveform. For various reasons (which I dont claim to fully understand) this creates currents in the neutral of the three phase wye. I believe this problem is being addressed in the electrical codes now. There are various derating factors to apply in calculating loads on the distribution transformer to prevent neutral heating when much of the load is from switching power supplies. Even measuring load isnt easy, as I recently discovered. I wanted to measure our current load in the computer room to buy a UPS. The normal clamp on ammeter isnt sufficient. Inexpensive ones read out in RMS current, but measure AVERAGE current. They assume the current waveform is a sine wave, and apply the factor to convert average to rms. If the current waveform is not a sine wave (such as with a switching power supply) this type of meter will read low. One must use a true rms meter with a wide frequency response (I used a Fluke true rms handheld with their widest freq. response current clamp. Amprobe has a computerized meter that works also). What I measured in my computer room was: phase 1: 21 amps phase 2: 17.3 amps phase 3: 17.0 amps neutral: 30 amps Note how the neutral is carrying much more than would be expected from the phase imbalances. An average reading meter would have been off by more than a factor of 2. Art Hays, Nat. Eye Institute, uunet!lsr-vax!art Nat. Institutes of Health, Bethesda, MD (301) 496-7143   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20351; 20 Feb 90 13:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18996; 20 Feb 90 12:30 EST Date: Tue, 20 Feb 90 12:15:56 EST From: Gary S. Moss (VLD/VMB) To: Gary Tarolli cc: info-iris@BRL.MIL Subject: Re: shademodel Message-ID: <9002201215.aa18894@VMB.BRL.MIL> [Gary Tarolli writes:] < A stack track should readily identify the offending routine. As for < the error messages, here's the reason. Some of the GL calls, eg. v3f have < to be called at a very rapid rate (> 1 million per second) to achieve the < graphics performance the hardware can deliver. Putting in something as simple < as an "if" test and worse yet a subroutine call (even if its not taken it will < make the routine a non-leaf routine which adds lots of code to the procedure's < entry and exit code), will seriously degrade performance. Although there are < many routines that are not performance critical, there are also many many < things to test for. Well, I understand that in general you don't want the overhead, but many of the one time window configuration GL calls, like shademodel() could benefit from a simple test for a NULL pointer. Even a failed assertion (using assert()) would be better than letting a segmentation violation occur. It may be that the design of the code does not permit this, but that would be a bad design. < The code would not be easy to implement - imagine the < problem of checking for a valid pointer - you should really try to access < the data while catching segv signals - but what if the user is also catching < segv signals? etc etc. Checking a pointer's validity is trivial if pointers are initialized to NULL *and* reset to NULL once invalidated by winclose() or whatever. Permitting an uninitialized variable to be used as a pointer is sloppy coding. < However, your point is valid - we need better error messages and parameter < checking. Rather than add code to the GL, most of us would prefer to build < an alternate GL that could be used for debugging. THus the performance of < the real GL would not be affected. This debugging GL would only be used < while debugging. It could be implemented as a separate library, for those < who don't use the shared lib, or as a "somehow switchable" part of the < shared library that could be activated when desired, or as a DGL filter. A method that we find useful and easy to maintain is to frame any such code segments that either impact performance or are inappropriate for production use (i.e. assert() calls) with #ifdef DEBUG ... #endif compiler directives so that a debugging version can be easily compiled and made available without having to maintain separate sources.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24908; 20 Feb 90 19:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24817; 20 Feb 90 18:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24756; 20 Feb 90 18:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09244; 20 Feb 90 18:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02294; Tue, 20 Feb 90 15:04:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 90 22:52:38 GMT From: Thomas Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: canonicalize hostname and a gnu-emacs question. Message-Id: <24825@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm trying to port gnu emacs to a friend's new 4D/25, running 3.2.1. I have already gotten it running on our 4D/{80,20,25}s running 3.2. In trying this I ran into a problem -- the thing drops core inside XDisplayOpen (actually, well inside --- inside the call to gethostbyname) In hunting down the problem we set him up to use remote nameservice. Now his nameserver returns his domain in uppercase, and the newsserver complains about security violations. SO: A) I remember reading something about using canonicalizehostname to solve this sort of problem. What were the fixes B) Has anyone gotten emacs 18.55 running under 3.2.1 with X? It runs just fine if I use the IP address of the display instead of its hostname, but crashes with this stack : > 0 .kill.kill(0x1045c34, 0x0, 0xb, 0x0, 0x7fff990f, 0x486990) ["kill.s":17, 0x 4886b4] 1 fatal_error_signal(sig = 11) ["emacs.c":143, 0x419fb4] 2 .index.index(0x100290e4, 0x1002dde0, 0x0, 0x0, 0x7fffc7f1, 0x0) ["in_ntoa.c ":24, 0x47ce1c] 3 .res_init.res_init(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["res_init.c":117, 0x47a4c 0] 4 res_search(0x0, 0x0, 0x0, 0x0, 0x400, 0x0) ["res_query.c":131, 0x47a83c] 5 _gethostbyname_named(0x7fffc240, 0x4701bc, 0x0, 0x0, 0x0, 0x470214) ["getho stnam.c":239, 0x4791dc] 6 gethostbyname(0x2, 0x0, 0x0, 0x0, 0x0, 0x0) ["gethostwrap.c":18, 0x4786bc] 7 _XConnectDisplay(0x7fffc7f1, 0x7fffc57c, 0x7fffc47c, 0x7fffc478, 0x7fffc44c , 0x7fffc448) ["XConnDis.c":579, 0x470210] 8 XOpenDisplay(0x0, 0x0, 0x0, 0x43b218, 0x0, 0x0) ["XOpenDis.c":178, 0x466338 ] 9 x_term_init() ["x11term.c":1534, 0x4155c8] 10 init_display() ["dispnew.c":1411, 0x4032e0] 11 main(argc = 1, argv = 0x7fffc784, envp = 0x7fffc78c) ["emacs.c":354, 0x41a4 40] Does this mean anything to anybody? 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 aa25497; 20 Feb 90 20:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25056; 20 Feb 90 19:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24991; 20 Feb 90 19:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09600; 20 Feb 90 18:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04178; Tue, 20 Feb 90 15:36:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 90 20:01:38 GMT From: psuvm!sml108@psuvax1.cs.psu.edu Organization: Penn State University Subject: 3.2 bug from H E double Toothpick Message-Id: <90051.150138SML108@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Warning: I have just encountered a rather nasty and merciless bug in 3.2. I clicked on a folder to open it up under workspace and it simply disappeared. No query, no appearance in the dumpster, just vaporized... Nice going to whoever included to this option... Scott Le Grand   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25760; 20 Feb 90 21:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25155; 20 Feb 90 20:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25092; 20 Feb 90 19:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09695; 20 Feb 90 18:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04385; Tue, 20 Feb 90 15:40:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 90 23:34:14 GMT From: Thomas Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: More on that emacs-X problem in 3.2.1 Message-Id: <24829@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Ok. I just read the emacs "PROBLEMS" file, and seems like some people have had this same "gethostbyname bombs if display is hostname:0" problem too: * Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. Some people have found that Emacs was unable to connect to the local host by name, as in DISPLAY=prep:0 if you are running on prep, but could handle DISPLAY=unix:0. Here is what tale@rpi.edu said: Seems as though gethostbyname was bombing somewhere along the way. Well, we had just upgrade from SunOS 3.5 (which X11 was built under) to SunOS 4.0.1. Any new X applications which tried to be built with the pre OS-upgrade libraries had the same problems which Emacs was having. Missing /etc/resolv.conf for a little while (when one of the libraries was built?) also might have had a hand in it. The result of all of this (with some speculation) was that we rebuilt X and then rebuilt Emacs with the new libraries. Works as it should now. Hoorah. So, is there a chance that 3.2.1 broke X libraries in some strange way? Has anybody ever run across such problems? 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 aa26944; 21 Feb 90 2:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26763; 21 Feb 90 2:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26719; 21 Feb 90 1:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13764; 21 Feb 90 1:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28038; Tue, 20 Feb 90 22:31:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 90 02:17:15 GMT From: Tad Guy Organization: Old Dominion University, Norfolk, VA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: References: <90051.150138SML108@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90051.150138SML108@psuvm.psu.edu> SML108@psuvm.psu.edu writes: > Warning: I have just encountered a rather nasty and merciless bug in 3.2. > I clicked on a folder to open it up under workspace and it simply > disappeared. No query, no appearance in the dumpster, just > vaporized... I've a similar problem... I double click on a folder, a window appears. For the briefest of moments, the contents of the folder appear, then the window becomes empty (actually, it looks like the contents scroll away, yet the scrollbar shows that the whole window is being displayed). The ``listing'' version of the window claims no entries. Weird... It only happens to some (few) of my folders. Most work without problems. Any ideas? ...tad   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26894; 21 Feb 90 2:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26763; 21 Feb 90 2:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26716; 21 Feb 90 1:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13639; 21 Feb 90 1:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27704; Tue, 20 Feb 90 22:25:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 90 05:14:05 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <51272@sgi.sgi.com> References: <90051.150138SML108@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to hear more about what happened when you clicked on the folder and it disappeared. Was it a single click, or a double click? ( Just to let you know, workspace has been released in-house in heavy use for the last 16 months, and released to the field for the last 6, where it also seems to be in heavy use, and no one has ever reported this problem ) I wonder if the following happened. click on the folder, while moving the mouse, and inadvertantly drop the folder into another one. ( this may be in combination with an inadvertant name change of the folder, so that when you did a 'find' command, your folder name did not turn up.) The above scenario did happen to one user, who justifiably irately announced that WorkSpace had eaten his folder, but, upon prompting, found that the folder had been dropped inside another one. Please try doing a find command on some of the contents of the missing folder. I understand how upset you must be, but I reiterate, look in your tree for the contents of the directory. WorkSpace has been in heavy use for a long time and there has never been a case of lost data reported.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27707; 21 Feb 90 6:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27444; 21 Feb 90 6:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27435; 21 Feb 90 6:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14948; 21 Feb 90 5:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11969; Wed, 21 Feb 90 02:31:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 90 09:31:02 GMT From: Jon Genetti Organization: Texas A&M University, College Station, Texas Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <4292@helios.TAMU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >I double click on a folder, a window appears. > >For the briefest of moments, the contents of the folder appear, then >the window becomes empty (actually, it looks like the contents scroll >away, yet the scrollbar shows that the whole window is being >displayed). The ``listing'' version of the window claims no entries. >Weird... > >It only happens to some (few) of my folders. Most work without problems. We had the same problems with some of our folders. It seems if you have the world does not have read access to a folder, then the workspace is not able to read it. Open a folder that the contents disappear and then change the protection on that directory from a shell and the files in that directory will appear in that window. jon genetti. p.s. folks at sgi - is this a bug or a feature?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04749; 21 Feb 90 15:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04118; 21 Feb 90 14:59 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa04112; 21 Feb 90 14:47 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa14184; 21 Feb 90 14:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11081; Wed, 21 Feb 90 11:06:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 90 18:39:40 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <6242@hydra.gatech.EDU> References: <90051.150138SML108@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > > Warning: I have just encountered a rather nasty and merciless bug in 3.2. > I clicked on a folder to open it up under workspace and it simply > disappeared. No query, no appearance in the dumpster, just > vaporized... > > Nice going to whoever included to this option... > This could be caused by using the workspace on an NFS mounted directory that's exported from a non-SGI server. I noticed this problem before, tracked it down to the fact that the disappearing directory's mode was 0700 and was on an NFS filesystem. The workspace uses a daemon process running in the background to update the directory views and that process runs as root and root can't normally see into mode 0700 directories on an NFS filesystem. One exception is that SGI NFS servers do allow root on client workstations to see into mode 0700 directories. I called the hotline to report the problem. They said that the workspace was working as designed and if you want to see into NFS directories, they have to be something like mode 0755 (world-readable). Which means you can't have secure directories and still be able to use them from the workspace. When I asked the hotline why root on client workstations can access mode 0700 NFS directories, they looked through the NFS server code and discovered a bug and said it would be fixed in the next release. We'll see. robert --- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08496; 21 Feb 90 19:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08181; 21 Feb 90 17:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08125; 21 Feb 90 17:45 EST Received: from TACOM-EMH2.ARMY.MIL by SMOKE.BRL.MIL id aa01215; 21 Feb 90 17:29 EST Received: (from user GJACKSON) by tacom-emh2.army.mil; 21 Feb 90 17:31:35 EDT Subject: PIC files to Targa or rla format To: info-iris@BRL.MIL From: GJACKSON@tacom-emh2.army.mil Date: 21 Feb 90 17:31:35 EDT Message-ID: <9002211729.aa01215@SMOKE.BRL.MIL> Does anyone out their have a convertor that would turn Macintosh PIC files into a Targa (tga) or rla format that I could use with Wavefront on my SGI machine? gjackson@tacom-emh2.army.mil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08742; 21 Feb 90 20:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08440; 21 Feb 90 18:54 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa08438; 21 Feb 90 18:45 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa20404; 21 Feb 90 18:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27148; Wed, 21 Feb 90 15:12:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 90 18:27:43 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <51303@sgi.sgi.com> References: <90051.150138SML108@psuvm.psu.edu>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >I double click on a folder, a window appears. > >For the briefest of moments, the contents of the folder appear, then >the window becomes empty (actually, it looks like the contents scroll >away, yet the scrollbar shows that the whole window is being >displayed). The ``listing'' version of the window claims no entries. >Weird... > >It only happens to some (few) of my folders. Most work without problems. Are these badly behaved directories mounted over NFS from a foreign machine? There is a bug in 3.2 workspace (fixed in next release) where files that are mounted from foreign machines, that have some read restrictions on them, and that are exported without root privelege, display the behaviour you describe. Can you let me know more details? Betsy Zeller betsy@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08805; 21 Feb 90 20:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08701; 21 Feb 90 20:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08687; 21 Feb 90 19:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02454; 21 Feb 90 19:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01699; Wed, 21 Feb 90 16:35:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 00:00:23 GMT From: Bruce Karsh Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <51352@sgi.sgi.com> References: <90051.150138SML108@psuvm.psu.edu>, <51272@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <51272@sgi.sgi.com> betsy@vesuvius.UUCP (Betsy Zeller) writes: >I wonder if the following happened. > click on the folder, while moving the mouse, and inadvertantly > drop the folder into another one. ( this may be in combination > with an inadvertant name change of the folder, so that when > you did a 'find' command, your folder name did not turn up.) I don't know what happened in this case either. Other possibilities besides the one Betsy suggested are: 1. The file was NFS mounted and the mount machine went down. 2. Some other process (perhaps another user) removed or renamed the directory. If you can give us any more information on this occurence, please let us know.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15496; 22 Feb 90 10:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13108; 22 Feb 90 9:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12960; 22 Feb 90 8:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08857; 22 Feb 90 8:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11746; Thu, 22 Feb 90 05:38:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 01:27:38 GMT From: Tad Guy Organization: Old Dominion University, Norfolk, VA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: References: <4292@helios.TAMU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4292@helios.TAMU.EDU> genetti@photon.tamu.edu (Jon Genetti) writes: > We had the same problems with some of our folders. It seems if you have > the world does not have read access to a folder, then the workspace > is not able to read it. Open a folder that the contents disappear > and then change the protection on that directory from a shell and > the files in that directory will appear in that window. This is exactly what I discovered today. In a letter in response to a correct answer via email from SGI: | This was the correct answer, thanks. | | I don't know if I mentioned it in my posting, but the machine is | someone else's, so I don't often get a chance to experiment with it. | However, today the machine's owner was away and at the same time a | person from the local SGI office was around, so we looked at the | problem and on a whim I tried changing the directory permissions and | the files quickly returned to the window. He's reported it back to | the office... | | Thanks again... > p.s. folks at sgi - is this a bug or a feature? I consider it a bug, or at least an unfortunate design decision -- the problem (as gleaned from another posting) appears to be that the directory reading process is uid 0 (instead of having my permissions), which isn't trusted over NFS... The work around of making my directories world readbable clearly isn't the right solution... :-) ...tad   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14883; 22 Feb 90 10:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13520; 22 Feb 90 9:34 EST Received: from vat.brl.mil by VMB.BRL.MIL id aa13156; 22 Feb 90 9:08 EST Date: Thu, 22 Feb 90 9:05:48 EST From: "John R. Anderson" (VLD/ASB) To: info-iris@BRL.MIL Subject: PI Problems Message-ID: <9002220905.aa28986@VAT.BRL.MIL> I have recently encountered two problems with our P.I.'s: 1. The other day, I changed the net addresses on our PI's, and at the same time I happened to place a notice to the user's in /etc/motd. Afterwards, "rcp" no longer worked correctly. I spent considerable time checking and rechecking the addresses on all the machines. It was very strange that I could do "rlogin", but not "rcp". Finally, I removed the notice from "/etc/motd", and amazingly, "rcp" started workin again. Imagine how frustrated one must be for "rcp doesn't work, so I'll empty /etc/motd" to seem reasonable. My question is: How can I post a notice to users of a PI without breaking "rcp"??? 2. We would like users without "root" priviledges to be able to do "shutdown". I assigned different passwords to the "root" and "sysadm" accounts. When executing "System Shutdown" from the "System" menu, it requests the "System Administrator" password. I took that to mean the "sysadm" account, but in fact it will only accept the "root" password. Is there a way to enable users without the "root" password to perform a shutdown??? Thanks, -John   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17945; 22 Feb 90 11:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16454; 22 Feb 90 11:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16305; 22 Feb 90 11:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14170; 22 Feb 90 11:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17710; Thu, 22 Feb 90 07:50:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 15:26:58 GMT From: Sam Fulcomer Organization: Brown University Department of Computer Science Subject: Re: Stardent's Application Visualization System (AVS) on SGI boxes ?? Message-Id: <30229@brunix.UUCP> References: <1423@merlin.bhpmrl.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1423@merlin.bhpmrl.oz> ianh@merlin.bhpmrl.oz (Ian Hoyle) writes: >At last I'm finally going to get my very own 240 GTX to do some volume >visualization work and more general stuff. I have already asked this group >Having just read through Stardent's glossy blurb on their AVS (Application >Visualization System), > >a) has anyone ported this to an SGI machine (probably GTX architecture) since > >b) does SGI have any plans to provide such a higher level visualization tool (a) Well, now that the version of AVS (2) is out that's really usable we're considering it. The question that we have is at what level to actually "port" and where to do function emulation. AVS is based on the Stellar native PHIGS+ (for the most part) GL. I'm not sure that it makes sense to spend the time wrapping the SGI GL to fit Stellar's GL, and I don't want to spend the money on an SGI PHIGS only to wrap the ugly stuff anyway. What I'm leaning toward right now (at least until I see the AVS code) is using the AVS UI and data-flow on top of Wavefront's Visual C. (b) Well..., it seems to me that it was someone at SGI who had a paper on data-flow paradigms published in ACM Graphics back in (?) '84. Where do think AVS came from? (:-)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17945; 22 Feb 90 11:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16454; 22 Feb 90 11:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16308; 22 Feb 90 11:24 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa14313; 22 Feb 90 11:06 EST Received: Thu, 22 Feb 90 08:06:24 -0800 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Thu, 22 Feb 90 11:07:11 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Thu, 22 Feb 90 11:32:58 EST by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Thu, 22 Feb 90 11:32:58 EST From: Tony Facca Message-Id: <9002221632.AA10920@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: PI Problems "John R. Anderson" (VLD/ASB) writes: > > I have recently encountered two problems with our P.I.'s: > > [ very strange rcp question deleted ] > > 2. We would like users without "root" priviledges to be able to > do "shutdown". I assigned different passwords to the "root" and "sysadm" > accounts. When executing "System Shutdown" from the "System" menu, it > requests the "System Administrator" password. I took that to mean the > "sysadm" account, but in fact it will only accept the "root" password. > Is there a way to enable users without the "root" password to perform > a shutdown??? > How about a line like: shutdown::0:0:shutdown the system:/:/etc/shutdown in your /etc/passwd file. you can password protect the shutdown id so that only selected users can do this. actually, reboot would probably be a better program to use if security is an issue as its not interactive. -- ..ahead, warp factor...two + * + * + * - - - - -------======<<<<<{{{{{{[[[[[[ TONY FACCA fsfacca@avelon.lerc.nasa.gov + + * * * "Its hard to work in groups -- especially when you're omnipotent" --Q   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18100; 22 Feb 90 12:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17945; 22 Feb 90 11:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16743; 22 Feb 90 11:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14504; 22 Feb 90 11:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18724; Thu, 22 Feb 90 08:11:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 15:34:09 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: f77 dumped core Message-Id: <975@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL f77 could not digest the following program; it handled it fine when I have the declaration of the character variable. -------------------- cut --------------------------------- program test * character*80 inpfile * inpfile = '10-28-86' open(1,file="/usr/local/lib/"//inpfile, * status='old',err=111,form='unformatted', *access='direct',recl=5752) print*,'Open SUCCESSFUL' stop 111 print*,'Open FAILED' stop end -------------------- cut --------------------------------- Here is the response I received for 'f77 test.f': Fatal error in: /usr/lib/fcom - core dumped Signal 139 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa19971; 22 Feb 90 14:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19756; 22 Feb 90 14:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19721; 22 Feb 90 13:46 EST Received: from ANCHOR.RUTGERS.EDU by SMOKE.BRL.MIL id aa17187; 22 Feb 90 13:16 EST Date: Thu, 22 Feb 90 11:40 EST From: STEARNS@BIOVAX.RUTGERS.EDU Subject: Updating 4.2 stty definitions to 4.3 -- To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <9002221316.aa17187@SMOKE.BRL.MIL> Some software we hope to use for remote printing to a Vax has a series of definitions referring to terminal control as defined in 4.2 BSD: "tchars", "ltchars", "sttygb" ... TANDEM, EVENP, LN0HANG; TIOCGETP, TIOCGLTC, etc. Does anyone have a list or header file giving the translations of 4.2's ioctl.h material into 4.3's termio.h/curses.h? In Irix 3.2.1 the include file rpcsvc/rex.h also refers to the (nonexistant) tchars, ltchars, and sttygb.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id ac01955; 24 Feb 90 0:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ab00690; 23 Feb 90 20:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22469; 22 Feb 90 16:43 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa22554; 22 Feb 90 16:02 EST Received: Thu, 22 Feb 90 13:03:04 -0800 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Thu, 22 Feb 90 16:03:48 EST by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Thu, 22 Feb 90 16:29:44 EST by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Thu, 22 Feb 90 16:29:44 EST From: Tony Facca Message-Id: <9002222129.AA11696@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Stardent's AVS on SGI boxes [ stuff about porting AVS to SGI deleted ] Before you spend too much time thinking about how to port AVS, you may want to call Stardent (actually, the Stellar half of Stardent) and ask them how they are progressing in their efforts to port it. Last time I talked to the guys at Stardent (last week), they had purchased an Iris and had a version of AVS running (albeit "like a pig") on it. I have no details about which Iris it is but they were working on making run faster. I think they ported Dore to the Iris which was relatively easy, and then ported AVS on top of Dore. So you have AVS --> Dore --> GL. Not to mention X Windows. No wonder its a bit slow. -- ..ahead, warp factor...two + * + * + * - - - - -------======<<<<<{{{{{{[[[[[[ TONY FACCA fsfacca@avelon.lerc.nasa.gov + + * * * "Its hard to work in groups -- especially when you're omnipotent" --Q   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id ad01955; 24 Feb 90 0:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ae00690; 23 Feb 90 20:48 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa23319; 22 Feb 90 18:43 EST Received: from dukempd.phy.duke.edu by ADM.BRL.MIL id aa14401; 22 Feb 90 18:28 EST Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA07048; Thu, 22 Feb 90 18:16:47 EST Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA17932; Thu, 22 Feb 90 18:16:43 EST Date: Thu, 22 Feb 90 18:16:43 EST From: "Robert G. Brown" Message-Id: <9002222316.AA17932@physics.phy.duke.edu> To: info-iris@BRL.MIL Subject: jove, other makes Cc: rgb@phy.duke.edu I am having a pretty fair degree of difficulty porting jove, ntp, and a few other useful public utilities onto a new SG 220S. Most of the difficulty revolves around Irix not quite knowing if it is V or 4.3 or neither, running down the libraries, running down the include files, etc. In both these cases, however, I have run into a core of objects needed by the source that are just not to be found. Has anyone ported jove, TeX, and all the useful unix software available via ftp to the SG's, resolving in makefile/source form all of these difficulties? Is there a ftp repository of them through which I can browse? Does anyone out there have any rules of experience to share concerning ports (such as always using -I/usr/include/bsd as a compile switch)? Note that the other machines where this software is installed on our LAN are mostly 4.3BSD (or thereabouts) Suns. Robert Brown   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id ae01955; 24 Feb 90 0:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id af00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id af00690; 23 Feb 90 20:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24261; 22 Feb 90 22:15 EST Received: from [35.1.1.91] by SMOKE.BRL.MIL id aa26100; 22 Feb 90 22:04 EST Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) id AA07347; Thu, 22 Feb 90 22:03:11 -0500 Date: Thu, 22 Feb 90 22:02:32 EST From: Tim_Buxton@um.cc.umich.edu To: info-iris@BRL.MIL Message-Id: <5720309@um.cc.umich.edu> Subject: Call for Comments on Nexpert Object Hi! Nexpert Object is a package for producing rule-based Expert Systems produced by Neuron Data. It has been on the Macintosh II and PC-AT for 2-3 years now, and has recently been ported to the IRIS. We are potentially very interested in Nexpert Object, but are daunted somewhat by the price ($8000 for the package, $600 for a "Crippled Demo" version). We would appreciate it if some people with experience with this or other systems would comment on: 1. Capability and Speed Performance of the program, and on what IRIS models this is based. Comparison with the "micro" versions would be helpful if known. 2. Quality of support from Neuron Data. Is their SGI version competent or an afterthought? Are you able to get help when you need it? Nexpert Object is listed in the Geometry Partners book, but the salesman we contacted seemed to have knowledge which was sketchy to nil about the SGI version. Thanks for any information you can give us. -Tim Buxton OptiMetrics, Inc. Tim_Buxton@um.cc.umich.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aj02289; 24 Feb 90 0:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02128; 24 Feb 90 0:16 EST Received: by VMB.BRL.MIL id aa01955; 24 Feb 90 0:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23661; 22 Feb 90 20:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25120; 22 Feb 90 19:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14253; Thu, 22 Feb 90 16:44:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 00:18:32 GMT From: Ian Hoyle Organization: none Subject: X question under Irix 3.2 Message-Id: <1430@merlin.bhpmrl.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Posted for a colleague doing some X development: How can X be setup to have a visual of alt class "Direct Color" ie 24 bit color on the Personal Iris under Irix 3.2 ?? Using the command xdpyinfo gives number of visuals 2 . . Visual 1 . . class Static Color . . Visual 2 . . class Pseudo Color thanx in advance, ian -- Ian Hoyle /\/\ / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02943; 24 Feb 90 1:58 EST Received: by VMB.BRL.MIL id ab02867; 24 Feb 90 1:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id aa00690; 23 Feb 90 20:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22465; 22 Feb 90 16:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22477; 22 Feb 90 15:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02659; Thu, 22 Feb 90 12:46:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 20:16:41 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2 bug from H E double Toothpick Message-Id: <51453@sgi.sgi.com> References: <4292@helios.TAMU.EDU>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Just a few words to clarify workspace behaviour. Any problems viewing directories occur only when all three of the following conditions are true. i) the problem directories are NFS mounted ii) the directories are exported without root privelege iii) there is no read/execute permission for others on these directories. This bug has been addressed for the next release. If any undesirable directory viewing behaviour has occurred when all three of the above conditions were not true, it would be really helpful for us to hear about it.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02943; 24 Feb 90 1:58 EST Received: by VMB.BRL.MIL id ad02867; 24 Feb 90 1:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ac00690; 23 Feb 90 20:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22483; 22 Feb 90 16:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id ab22875; 22 Feb 90 16:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02446; Thu, 22 Feb 90 12:42:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 17:41:06 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: using wsh with telnet to VAX/VMS - window wrap at 80chars Message-Id: <4434@odin.SGI.COM> References: <2824@umbc3.UMBC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL wsh emulates an ANSI terminal, not a vt100...Some see that as a virtue....There has been a long standing request to make a variation of wsh that had some of the obscurities of vt100's, including the funky wrap mode that vt100's do. Someday it might even be done... kipp hickman silicon graphic inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02943; 24 Feb 90 1:58 EST Received: by VMB.BRL.MIL id ae02867; 24 Feb 90 1:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ad00690; 23 Feb 90 20:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab22526; 22 Feb 90 16:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23295; 22 Feb 90 16:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04494; Thu, 22 Feb 90 13:21:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Feb 90 20:29:35 GMT From: "Calvin H. Vu" Subject: Re: f77 dumped core Message-Id: <4444@odin.SGI.COM> References: <975@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <975@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: >f77 could not digest the following program; it handled it fine when >I have the declaration of the character variable. >-------------------- cut --------------------------------- > program test >* character*80 inpfile >* inpfile = '10-28-86' > open(1,file="/usr/local/lib/"//inpfile, > * status='old',err=111,form='unformatted', > *access='direct',recl=5752) > print*,'Open SUCCESSFUL' > stop > 111 print*,'Open FAILED' > stop > end >-------------------- cut --------------------------------- >Here is the response I received for 'f77 test.f': >Fatal error in: /usr/lib/fcom - core dumped > Signal 139 This has been fixed our next release which will give the appropriate error message: Error on line 4 of open.f: concatenation of nonchar data >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >John H. Merritt # Yesterday I knew nothing, >Applied Research Corporation # Today I know that. >merritt@iris613.gsfc.nasa.gov # Sorry about the trouble, -Calvin Vu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03578; 24 Feb 90 4:01 EST Received: by VMB.BRL.MIL id ad03544; 24 Feb 90 3:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ag00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ag00690; 23 Feb 90 20:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24478; 22 Feb 90 23:27 EST Received: from [131.151.1.4] by SMOKE.BRL.MIL id aa26336; 22 Feb 90 22:28 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4736; Thu, 22 Feb 90 21:24:56 CST Received: by UMRVMA (Mailer R2.05) id 4735; Thu, 22 Feb 90 21:24:49 CST Date: Thu, 22 Feb 90 21:18:41 CST From: Bob Funchess Subject: 4.3 BSD (in)compatibility To: info-iris@BRL.MIL Message-ID: <9002222228.aa26336@SMOKE.BRL.MIL> By a strange coincidence, I was trying to do exactly the same thing (i.e., figure out what TIOCGETC was) when the previous letter arrived. I also am interested in knowing what I SHOULD have done (what I did was comment out the offending code... hardly a viable option in most circumstances). Also, some BSD sources come with their #includes in the wrong order for SG (it's generally bad when you get "error in /usr/include/sys/*.h" header files... I ALMOST reloaded the system from tape). < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Disclaimer: If the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03578; 24 Feb 90 4:01 EST Received: by VMB.BRL.MIL id ae03544; 24 Feb 90 4:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ah00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ah00690; 23 Feb 90 20:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24484; 22 Feb 90 23:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26670; 22 Feb 90 22:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22817; Thu, 22 Feb 90 19:53:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 03:02:13 GMT From: Jeff Weinstein Organization: Silicon Graphics Inc. Subject: Re: X question under Irix 3.2 Message-Id: <4469@odin.SGI.COM> References: <1430@merlin.bhpmrl.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The X server shipped with 3.2 doesn't support any 24 bit visual. Sorry. --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 aa00963; 23 Feb 90 21:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00483; 23 Feb 90 20:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00461; 23 Feb 90 19:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14148; 23 Feb 90 15:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08802; Fri, 23 Feb 90 12:42:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 19:32:32 GMT From: Michael Lesh Organization: UCSF, Computer Center Subject: Help with workspace Message-Id: <2786@ucsfcca.ucsf.edu> References: <22232@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are using dirview() to input few data files to our program. After reading the input I want to stow the dirview from within the program only. I gues for that I need the Graphics window identifier. Does anybody know how to get hold of it of a window you haven't opened, but the system has opened it for you. Any help would be highly appreciated. please email your replies to goel@cardio.ucsf.edu ps-- or is there a way to open up a window and have the files displayed in it.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id af01955; 24 Feb 90 0:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id al00712; 23 Feb 90 21:08 EST Received: by VMB.BRL.MIL id al00690; 23 Feb 90 20:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05238; 23 Feb 90 14:10 EST Received: from tank.uchicago.edu by SMOKE.BRL.MIL id aa08974; 23 Feb 90 12:54 EST Received: from shiva.uchicago.edu by tank.uchicago.edu Fri, 23 Feb 90 11:57:08 CST Received: by shiva.uchicago.edu (5.52/890607.SGI) (for @tank.uchicago.edu:info-iris@brl.mil) id AA01049; Fri, 23 Feb 90 11:52:00 CST Date: Fri, 23 Feb 90 11:52:00 CST From: William Collins Message-Id: <9002231752.AA01049@shiva.uchicago.edu> To: info-iris@BRL.MIL Subject: recent iris mail Is recent iris-info correspondence (<1 yr. old) being archived in a publicly readable file? The mail stored in the info-iris directory on vgr.brl.mil does not contain much of the last year's discussion of video equipment for 200-series GTX machines. If someone has been filing this mail (including discussion on frame-grabbing, video recorder output, etc.), I would appreciate knowing how to get a copy if possible. Thanks in advance. Bill Collins University of Chicago Dept. of Geophysics bill@shiva.uchicago.edu or bill@ulysses.uchicago.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id ag01955; 24 Feb 90 0:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id am00712; 23 Feb 90 21:08 EST Received: by VMB.BRL.MIL id am00690; 23 Feb 90 20:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05249; 23 Feb 90 14:12 EST Received: from ux1.cso.uiuc.edu by SMOKE.BRL.MIL id aa09550; 23 Feb 90 13:08 EST Received: by ux1.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA07896; Fri, 23 Feb 90 12:10:32 -0600 Date: Fri, 23 Feb 90 12:10:32 -0600 From: Jonathon Sivier Message-Id: <9002231810.AA07896@ux1.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: polf errors on 4D 70 GT Has anyone else noticed anything like this? I am displaying a large number of objects on a Iris 4D 70 GT. There are at least several hundred polygons on the screen at any given time. As I move my POV around various of the polygons will have their centers clipped out. The left and right ends are displayed correctly but the center portions are not there. These polygons tend to be long and thin, but not extremely so. They are in objects and were created using polfi. I tried making them with floating point coords using polf but it had no effect. I have backfacing on. If anyone has any suggestions I would like to hear them, could this be a hardware problem. I also notice this problem on the flight demo program, but it isn't as pronounced. Thanks Jonathan Sivier jsivier@ux1.cso.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id af02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id ah01955; 24 Feb 90 0:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id an00712; 23 Feb 90 21:08 EST Received: by VMB.BRL.MIL id an00690; 23 Feb 90 20:50 EST Date: Fri, 23 Feb 90 15:23:04 EST From: "Lee A. Butler" To: info-iris@BRL.MIL cc: acst@BRL.MIL Subject: 4sight cut/paste buffer bogosity Message-ID: <9002231523.aa05724@VMB.BRL.MIL> It turns out that the contents of the cut/paste buffer of the 4sight window manager survive log-out. This is because the cut/paste buffer is stored in /tmp/.cutbuffer and is not zeroed or deleted on logout. Security minded folks should redefine the function "exitcleanly" in thier user.ps, or (better still) get the system manager to modify the function definition in: /usr/NeWS/lib/NeWS/init.ps to be something like the following: /exitcleanly { % wipe out the cut/paste buffer % new LAB/BRL (cp /dev/null /tmp/.cutbuffer) forkunix % new LAB/BRL % Destroy all windows that know /destroy {/destroy self send} AllWin % Wait 3 seconds for console to die 0.05 sleep % Terminate the server ^C } def This will work until we can get SGI and/or SMI to make the window manager handle this directly. For the ambitious hacker, check out the other files that 4sight leaves in /tmp and see if you can figure out what to do with the information there ;-). In case you haven't heard, you need to secure your tftp server daemon (either disable it or make it run chroot'ed to someplace harmless). As delivered from SGI, tftp can be used to copy ANY world readable files on the system, including /etc/passwd. Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ah02289; 24 Feb 90 0:27 EST Received: by VMB.BRL.MIL id aj01955; 24 Feb 90 0:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ap00712; 23 Feb 90 21:08 EST Received: by VMB.BRL.MIL id ar00690; 23 Feb 90 20:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07185; 23 Feb 90 16:58 EST Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa14681; 23 Feb 90 16:13 EST Received: Fri, 23 Feb 90 13:13:36 -0800 from vat.brl.mil by prandtl.nas.nasa.gov (5.61/1.2) Date: Fri, 23 Feb 90 16:13:25 EST From: "John R. Anderson" (VLD/ASB) To: Tony Facca Cc: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: PI Problems Message-Id: <9002231613.aa04636@VAT.BRL.MIL> Tony Facca writes: >"John R. Anderson" (VLD/ASB) writes: >> >> I have recently encountered two problems with our P.I.'s: >> >> [ very strange rcp question deleted ] >> >> 2. We would like users without "root" priviledges to be able to >> do "shutdown". I assigned different passwords to the "root" and "sysadm" >> accounts. When executing "System Shutdown" from the "System" menu, it >> requests the "System Administrator" password. I took that to mean the >> "sysadm" account, but in fact it will only accept the "root" password. >> Is there a way to enable users without the "root" password to perform >> a shutdown??? >> > >How about a line like: > > shutdown::0:0:shutdown the system:/:/etc/shutdown > >in your /etc/passwd file. you can password protect the shutdown id so that >only selected users can do this. actually, reboot would probably be a better >program to use if security is an issue as its not interactive. Great idea, but it doesn't work. Even with the correct options to "shutdown" indicating no grace period and no interaction, it still won't work. I finally did get it to work with an entry as Tony suggested, but I had to modify the shutdown script slightly so that no grace period and no interaction are the defaults. O.K. in our case, but may not be reasonable in some situations. Thanks for the inspiration, Tony. -John   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02593; 24 Feb 90 0:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02128; 24 Feb 90 0:16 EST Received: by VMB.BRL.MIL id ab01955; 24 Feb 90 0:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00710; 23 Feb 90 20:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17399; 23 Feb 90 19:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19079; Fri, 23 Feb 90 16:03:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 21:55:03 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: Re: Power for Iris 220S Message-Id: <1990Feb23.215503.17868@utzoo.uucp> References: <9002192231.AA15320@> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002192231.AA15320@> art@lsr-vax.UUCP (Art Hays - PSTAFF) writes: >The typical three phase wye transformer has the same guage wire for >the phases and neutral. The assumption is that if the loads on >all the phases are equal, there will be very little current flow in the >neutral... The current waveform of a switching power supply is far from >a sine wave. It draws current in brief periods near the peak of the >voltage waveform. For various reasons (which I dont claim to fully understand) >this creates currents in the neutral... It's not hard to understand. If the current waveforms are sine waves and all lead/lag the voltage waveforms by the same amount so they are 120 degrees apart like the voltages, then the sum of the current waveforms is zero. For example, when one of them is at maximum positive current, the others are mildly negative (one has recently gone negative, the other is about to go positive). However, this doesn't work for an arbitrary waveform. In particular, in the example, if the loads draw current only in the middle of the cycle, then when load #1 is at max positive current, the other two will be at zero instead of being mildly negative. Help is on the way, because the way to get maximum power while staying within a given current limit is to draw current over the entire sine wave rather than just the peaks, and the power-supply manufacturers see a considerable market for supplies that get the most out of an ordinary 15-amp circuit in particular. But for a while this will be premium technology applied only in things that really need it. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02593; 24 Feb 90 0:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ai02289; 24 Feb 90 0:36 EST Received: by VMB.BRL.MIL id ak01955; 24 Feb 90 0:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01332; 23 Feb 90 22:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19575; 23 Feb 90 22:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27479; Fri, 23 Feb 90 18:49:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 02:35:09 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: real to character converter Message-Id: <3743@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody have a real good real*8 or real*4 to character converter subroutine (maybe) that can do the following, (or something like it): 1) Send it a real number to be converted to a character variable that can be forwarded to a graphics lib call like 'fmprstr'. 2) Specify how many decimals you would like to retain. For example, if I have a real*8, I don't want to have all 16 digits in the character variable, but say only keep two. Here's the application: we've got some CFD visualization software we wrote ourselves and the routine (above) we wrote eons ago in the days of F66 is lately doing some weird voodoo on our code. I figured that there's got to be a more elegent way to accomplish it. Any donations/suggestions would be welcomed. =========================================================================== Tom Rohling "Infinity is where things happen trohling@uceng.uc.edu that don't" -Anonymous or rohling@afiris.ase.uc.edu ===========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae02943; 24 Feb 90 1:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02870; 24 Feb 90 1:47 EST Received: by VMB.BRL.MIL id aa02867; 24 Feb 90 1:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00703; 23 Feb 90 20:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17298; 23 Feb 90 19:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16746; Fri, 23 Feb 90 15:19:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 22:34:32 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: PI Problems Message-Id: <51649@sgi.sgi.com> References: <9002220905.aa28986@VAT.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002220905.aa28986@VAT.BRL.MIL>, jra@BRL.MIL ("John R. Anderson", VLD/ASB) writes: > 1. The other day, I changed the net addresses on our PI's, and > at the same time I happened to place a notice to the user's in /etc/motd. > Afterwards, "rcp" no longer worked correctly. I spent considerable time > checking and rechecking the addresses on all the machines. It was very > strange that I could do "rlogin", but not "rcp". Finally, I removed the > notice from "/etc/motd", and amazingly, "rcp" started workin again. > Imagine how frustrated one must be for "rcp doesn't work, so I'll empty > /etc/motd" to seem reasonable. My question is: How can I post a notice > to users of a PI without breaking "rcp"??? The BSD rcp protocol is fragile: as the friendly manual page says in its BUGS section: [Rcp is] confused by any output generated by commands in a .login, .profile, or .cshrc file on the remote host. The problem is not having a non-empty /etc/motd on the remote host, but the fact that the remote user's .profile or .cshrc file cats /etc/motd (the above-quoted warning about .login is erroneous -- the remote half of rcp uses does not involve a login shell, so .login is not sourced). Csh users can cat motd-like files from their .login files. But users of any shell shouldn't need to cat /etc/motd, as /etc/profile and /etc/cshrc do so for all login shells upon startup. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03237; 24 Feb 90 2:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03177; 24 Feb 90 2:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03155; 24 Feb 90 2:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22620; 24 Feb 90 1:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08006; Fri, 23 Feb 90 22:29:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 04:54:32 GMT From: Ian Hoyle Organization: none Subject: Re: X question under Irix 3.2 Message-Id: <1435@merlin.bhpmrl.oz> References: <4469@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From article <4469@odin.SGI.COM>, by jsw@xhead.SGI.COM (Jeff Weinstein): > > The X server shipped with 3.2 doesn't support any 24 bit > visual. Sorry. > > --Jeff rats :-( This will throw the development work of the group in question into a tail spin for the moment. They are doing code development for an image processing application for minerals exploration and they _need_ the 24 bit colour. Will it be supported in the next release of the X server, and if so could an interim patch be done? (I guess there are others who would like 24 bit also). thanx for the reply Jeff, ian -- Ian Hoyle /\/\ / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03578; 24 Feb 90 4:01 EST Received: by VMB.BRL.MIL id af03544; 24 Feb 90 4:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ai00712; 23 Feb 90 21:07 EST Received: by VMB.BRL.MIL id ai00690; 23 Feb 90 20:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27598; 23 Feb 90 7:50 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa00531; 23 Feb 90 7:26 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6392; Fri, 23 Feb 90 05:15:43 CST Received: by UMRVMA (Mailer R2.05) id 6390; Fri, 23 Feb 90 05:15:41 CST Date: Fri, 23 Feb 90 05:10:30 CST From: Bob Funchess Subject: NNTP / other news software To: info-iris@BRL.MIL Message-ID: <9002230726.aa00531@SMOKE.BRL.MIL> Has anyone ported nntp or anything like it to the 4D platform? What do the people in this newsgroup use to get their news? Also, in general, I suppose that #include in a source file means "you may as well rewrite this one, it's not going to work with any trivial substitutions or compiler flags"... < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Disclaimer: If the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03699; 24 Feb 90 4:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad03578; 24 Feb 90 4:08 EST Received: by VMB.BRL.MIL id al03544; 24 Feb 90 4:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01552; 23 Feb 90 23:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14570; 23 Feb 90 16:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07848; Fri, 23 Feb 90 12:23:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Feb 90 19:52:47 GMT From: Nicholas Tarnoff Organization: National Institute of Standards and Technology Subject: SIMPLE way to define location and state of startup windows??? Message-Id: <3171@marvin.cme.nist.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am looking for a simple way to define the locations and state of windows after login without having to learn PostScript! Something similar to Sun's toolplaces > .suntools seems like an essential feature that saves a lot of time after login. However, I found nothing in SGI manuals. All I want to do is record the placement and state (iconic or not) of my windows and use that record as my default startup layout. Please email me any information you have. Thank you ! -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 aa04197; 24 Feb 90 5:58 EST Received: by VMB.BRL.MIL id ad04168; 24 Feb 90 5:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aq00712; 23 Feb 90 21:08 EST Received: by VMB.BRL.MIL id as00690; 23 Feb 90 20:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04013; 23 Feb 90 13:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08111; 23 Feb 90 12:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28313; Fri, 23 Feb 90 09:15:54 -0800 Received: from USENET by 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 Feb 90 16:34:40 GMT From: dave who can do? ratmandu! ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: PIC files to Targa or rla format Message-Id: <4475@odin.SGI.COM> References: <9002211729.aa01215@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002211729.aa01215@SMOKE.BRL.MIL> GJACKSON@TACOM-EMH2.ARMY.MIL writes: >Does anyone out their have a convertor that would turn >Macintosh PIC files into a Targa (tga) or rla format that >I could use with Wavefront on my SGI machine? > >gjackson@tacom-emh2.army.mil not sure if this is useful, but IF the mac PIC format is a subset of TIFF image files, then try this: Article 2052 of comp.sys.sgi: >From: paul@manray.sgi.com (Paul Haeberli) Newsgroups: comp.sys.sgi Subject: Convert TIFF image files to IRIS image file format Message-ID: <49544@sgi.sgi.com> Date: 2 Feb 90 08:49:40 GMT Sender: paul@manray.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 2120 The folowing uuencoded program converts most tiff files into IRIS image files for manulation, printing, or display on 4D IRIS workstations. This message may be truncated before it reaches you. Make sure this file has about 2120 lines, and ends with a line that says "end". To get this swell program: 1. Save this message as fromtiff.uu 2. Run the command uudecode < fromtiff.uu 3. Run the command fromtiff input.tif output.rgb 4. Run the command ipaste output.rgb If this doesn't work for you, please let me know. Paul Haeberli paul@sgi.com 415-962-3665 begin 777 fromtiff M`6``"27)1K8````````````X``+@0"-1``(EXR! M`B0-``.OK0`8KZL`$">%@#(D!@$!)`<``PP0!D"OK``4CZ0`+)>%@0"7AH$" M#!`!!J^"@0R/I``L#!`BQ`````"/A($,#!`(3``````,$$?D```@(8^_`"0G MO0`P`^``"``````GO?_HKZ0`&*^F`""OOP`4KZ<`)(^F`!B/A($,#!`(U``` M."&/A($,CZ4`((^F`!@,$`C4)`<``8^$@0R/I0`DCZ8`&`P0"-0D!P`"C[\` M%">]`!@#X``(`````">]_["OI0!4CZX`5*^_`!ROI`!0``YX0*^F`%BOKP`H M#^`$@@'@("&/I``H#^`$@J^"@2"/I``H#^`$@J^"@22/I`!0KX*!*"0%`08, M$!M?)X:!"!1``":/I`!0EX*!!B0!``$000`')`$``Q!!``@D`0`$$$$`!R09 M``(0```'`````"08``$0```+IYB!""09``(0```(IYF!"#P$$``\!1``)*4% M@0_@!%0DA#9P$```[```$"&7B($()`$``A4!``,`````$````R>&@#0\!A`` M),8%VCP$$``\!1``)*4%J`_@!%0DA#9PCZ0`4"0%`1@,$!M?)Z8`3!1```./ MI`!0IZ``3(^D`%`D!0$9#!`;7R>F`$@40``&`````)>)@00D"@`!`2I8!"5L M__^GK`!($```EZ^@`$"7K0!,`````!6@``:7KP!(EZX`2"0!`/\1P0"O`$B7N`!,``````'X$",`0#`AKZ8`,`_@!((D1``!CZ8`,!1```FOH@!` M/`00`#P&$``DQ@7G)(0V<`_@!%0GA8`X$```L```$"&7F8$(`````!<@`!H` M````!,``+P``*"$`!AH``&88(P!`("$`9@`:)*4``13```(```````<`#20! M__\4P0`$/`&``!1A``(```````8`#0#%""HD8_\!)(0``0``0!*@B/__$"#_ M[P`````0```8``````3``!8``"@A``8J``"F*",``!@A`$`@(0!F`!HDA``! M%,```@``````!P`-)`'__Q3!``0\`8``%&$``@``````!@`-)&,`_P"C""H` M`%`2H(K__Q`@__``````EXF!!"0!``@1(0!1CZ0`4)>+@0@D`0`"$6$`38^D M`%"/I`!`#!`$SP````"/I`!`#^`$@``````0``!$KZ``0(^D`%`GC($'@1@40``(`````#P$$``\!1``)*4&$0_@!%0DA#9P M$```7```$"&7C8$$)`X``0&N$`0H00`"%"``+B1#__\``Q!`CX^!%#0!__\! MXA@AE'@`````````&,H``R$`&P``0!*D:```CXJ!&``````!0B`AE(D````` M````"5H``6$`&P``8!*DC```CXZ!'``````!PB@AE*T``"1"__X`#7H``>$` M&RA!``(``,`2I+@``!`@_^,`````$```#H^D`%"7F8$(`````"\A``00(``( M```````9R(`\`1```#D((8PY`````````R``"`````"/I`!0)`4!'`P0&U\G MI@!$EZ@`1"0!``(5`0`*CZ0`4(^D`%"/I0!`CZ8`6(^G`%0,$`-F`````!`` M``BOH@`\CZ0`4(^E`$"/I@!8CZ<`5`P0`E(`````KZ(`/(^J`$``````$4`` M`P`````/X`2``4`@(8^$@2`/X`2``````(^$@20/X`2``````(^$@2@/X`2` M`````(^B`#P`````C[\`'">]`%`#X``(`````">]_^"OOP`4KZ4`)"0%`1(, M$!M?)X:!"A1```,`````)`X``:>.@0J7CX$*`````"7X__\O`0`($"``'``` M````&,"`/`$0```X""&,.``0``````,```@`````/`00`#P%$``DI08S#^`$ M5"2$-G`D&0`$IYF!"A````ROH```!`F"$9P`#M``"@(:^U`"@D%0`(CZ0`<`)`*"$"@#`A M#!`&+```."$$00#+`````(^U`"@0``#BC[,`,"8C__\`8$@A$@``%@)`*"$: M(``4`````)"O``"0J@`!`@_`(9,9```""E@AH+D``)%L``"0K0`"H*P``0(- M<"&1SP```2`@(:"O``*7F($&)2G__QR`__``N"@A`D`H(0!@2"&/@X$@CX>! M)(^(@2@:(``1`&`P(9"Y```!("`AI-D``)"J``$DQ@`"I.H``)"K``(DYP`" MI0L``)>,@08E"``")2G__QR`__,`K"@ACX.!(`````"/AH$DCX>!*`)@("$, M$`#O`&`H(1```)\`````)B/__P!@2"$2```7`D`0(1H@`!4`````E$T``)18 M``("#7`AD<\```(8R"&D3P``DRH``)1+``2D2@`"`@M@(9&-```!("`AI$T` M!)>.@08E*?__``YX0!R`_^\`3Q`A`&!((0)`$"&/@X$@CX>!)(^(@2@:(``2 M`&`P(918```!("`AI-@``)19``(DQ@`"I/D``)1*``0DYP`"I0H``)>+@08E M"``"``M@0`!,$"$<@/_R)2G__X^#@2``````CX:!)(^'@2@"8"`A#!``[P!@ M*"$0``!H`````)>$@00`````$)7_D20!`!`0@?_$`````!```&``````CX.! M((^'@22/B($H`D`H(28I__\:(``8`&`P(9"C``"/C8$4``,00`&B<"&5SP`` M`2`@(:3/``"/F($8)*4``0,"R"&7*@``),8``J3J``"/BX$<).<``@%B8"&5 MC0``)0@``B4I__\<@/_LI0W__H^#@2``````CX:!)(^'@2@"8"`A#!``[P!@ M*"$0```[`````)>$@00`````%)4`'@````"/@X$@CX>!)(^(@2@"0"@A)BG_ M_QH@`!``8#`AD*X```$@("$"#G@AD>(``"2E``&DP@``I.(``"3&``(DYP`" M)0@``B4I__\<@/_TI0+__H^#@2``````CX:!)(^'@2@"8"`A#!``[P!@*"$0 M```:`````(^#@2`"("@A`D`P(0P0!5L`8#@ACX.!(`)@("$`8"@A`&`P(0P0 M`.\`8#@A$```#0````"7F($(`````"\!``00(``(```````8P(`\`1```#@( M(8PX`#```````P``"`````"7F8$*)`$``1":4``$6BO\9`F28(8^U`"@`````C[,`,(^T`"PD`@`!C[\`)(^P`!B/ ML0`CZ0` MH(^B`*"/HP"$"/I@"8`$"P(0!/J"$`0Z`A`L"`(0*`B"$"H)`A M`H`H(0P0!BPD!P`!!$``^0````"/I`"HCZ8`F`*@*"$,$`8L)`<``@1!`)<` M````$```\`````"/AX$@CX6!)(^&@2@:X``0)NC__Y(8```!`"`AI/@``)(Y M```F$``!I+D``))*```DYP`")C$``22E``(F4@`!),8``B4(__\<@/_RI,K_ M_H^%@2"/AH$DCX>!*`P0`.\#P"`A$```U0````"/AX$@CX6!)(^&@2@:X`!N M``!`(3+I``,1(``>``AX0``(6$``"&!```AH0`*M("$"C!@A`LL0(91.```E M"``!`FYX(9'X```DYP`"I/C__I1Y```DI0`"`GE0(9%+```DQ@`"I*O__I2, M```D0@`"`FQH(9&N```D8P`")(0``A4H_^VDSO_^$1<`3P``````"'A```C` M0``(R$`"N2`A`I@8(0+/$"&42@``).<``@)J6"&1;```)*4``J3L__Z4;0`` M),8``@)M<"&1SP``).<``J2O__Z4F```)*4``@)XR"&3*@``)0@`!*3*__Z4 M2P`"),8``@)K8"&1C0``)$(`"*3M__Z4;@`").<``@)N>"&1^```)&,`"*2X M__Z4F0`")*4``@)Y4"&12P``)(0`"*3+__Z43/_\),8``@)L:"&1K@`````` M`*3N__Z4;__\).<``@)OP"&3&0```````*2Y__Z4BO_\)*4``@)J6"&1;``` M`````*3,__Z43?_^),8``@)M<"&1SP```````*3O__Z4>/_^``````)XR"&3 M*@```````*2J__Z4B__^``````)K8"&1C0``%1?_N:3-__Z/A8$@CX:!)(^' M@2@,$`#O`\`@(1```%P`````EX2!!"0!``@0@?]I)`$`$!"!_X(`````$``` M5`````"/AX$@CX6!)(^&@2B/J0"@&N``%B;H__^1(P``CXZ!%``#$$`!PG@A ME?@```$`("&D^```CYF!&"4I``$#(E`AE4L``"3G``*DJP``CXR!'"2E``(! M@F@AE:X``"3&``(E"/__'(#_[*3.__Z/A8$@CX:!)(^'@2@,$`#O`\`@(1`` M`#(`````EX2!!"0!``@4@0`7CZ8`H(^'@2"/HP"@&N``"B;H__^4;P```0`@ M(0)OP"&3`@``)&,``B3G``(E"/__'(#_^*3B__Z/F8$@`\`@(0,@*"$#(#`A M#!``[P,@."$0```9`````(^F`*"/AX$@#!`%6P+@*"&/BH$@`\`@(0%`*"$! M0#`A#!``[P%`."$0```-`````)>+@0@`````+6$`!!`@``@```````M8@#P! M$```*P@AC"L`0``````!8``(`````)>,@0HD`0`!%8$`!"0$``$0```")`3_ M_R0$``&/H@"8CZT`L"1"``$#Q/`A%$W^W:^B`)B/L`!`C[$`/(^R`#B/M``T MC[4`,(^V`"P`````CZ0`H``````0@``$C[\`)`_@!(``````C[\`)(^S`!B/ MMP`]`*@#X``()`(``9>.@00D#P`(`>X`&P"`,"$GO?_HK[\`%!7` M``(```````<`#:^F`!@``"`2``0B``_@!((DA`0`CZ8`&!1```RO@H$0/`00 M`#P%$``DI0:@)(0V<`_@!%2OI@`8CZ8`&`P01^0D!``!CZ8`&`````"/@H$0 M```8(0``("$D!0`!)`<``B0(``0D"0$`)$($`(^8@1```````P3((1```%6O M(@````-1PS%+``$`RV`AD8T````#>8,Q[@`!`,[`(:!-``"3&0````-10S%+ M``$`RV`AH%D``9&-`````WD#,>X``0#.P"&@30`"DQD````#4,,Q2P`!`,M@ M(:!9``.1C0````-X@S'N``$`SL`AH$T`!),9`````U!#)$(``3%+``$D0@`! M`,M@(:!9``.1C0``)$(``21"``$P;P`!)$(``0#/<"&@30`!D=@``"1"``$D M0@`!)$(``1```"V@6/__``/)@S,J``,`RE@AD6P````#:0,QKP`#`,]P(:!, M``"1V`````/(@S,J``,`RE@AH%@``9%L```P;0`#)$(``0#->"&@3``!D>X` M`"1"``$D0@`!)$(``1```!6@3O__``/!`S,9``\`V5`AD4L``#!L``\`S&@A MH$L``)&O```D0@`!)$(``1````F@3___EXZ!!``````1Q?^J``-1PQ''_]@` M`\F#$] M__`HH0`(%"``9@"@$"&0SP``CXZ!$``/P(`!V,@ACR,``"3G``*0:```)&,` M`:3H__Z0:0``).<``J3I__Z0:@`!)&,``:3J``"0:P`!).<``J3K``"0;``" M)&,``:3L``*0;0`").<``J3M``*0;P`#)&,``23G``*D[P`"D&X``R1C``$D MYP`")$+_^"1C``$DYP`"*$$`""3&``$D8P`!).<``A`@_]FD[O_^$```/9#+ M```HH0`$%"``.0"@$"&0V0``CYB!$``90(`#"$@AC2,``"3G``*0:@``)$+_ M_*3J__Z0:P`!).<``J3K__Z0;``")&,``:3L``"0;0`")&,``23G``(H00`$ M),8``21C``$DYP`"$"#_Z:3M__X0```@D,L``"BA``(4(``<`*`0(9#.``"/ MCX$0``[(@`'YP"&/`P``)$+__I!H```DYP`"I.C__I!I``$H00`"),8``23G M``(D8P`!$"#_\:3I__X0```+D,L``"0!``$0@?^?)`$``A"!_\HD`0`$$('_ MYBBA``*/H@`$`````)#+``"/BH$0``M@@`%,:"&-HP``&$``!P````"0;@`` M)$+__R1C``$DYP`"'$#_^Z3N__X#X``()[T`$">]_^"OOP`4)Z8`'`P0&U\D M!0$"%$``#Y>O`!PD#@`!$```"Z>N`!P\!!``/`40`)>F`!PDI0;!#^`$5"2$ M-G`,$$?D)`0``1````^/OP`4EZ\`'``````E^/__+P$`$!`@__$``````!C` M@#P!$```.`@AC#@`4``````#```(`````(^_`!27H@`<`^``"">]`"`GO?_@ MK[\`%">F`!P,$!M?)`4!%1!```0`````EZ8`'!````\D`0`!$```#"0&``$\ M!!``/`40`"2E!NDDA#9P#^`$5*>F`!P,$$?D)`0``9>F`!P0```)C[\`%"0! M``$0P0`%)`$``Q#!``,D`0`$%,'_[P````"/OP`4)[T`(`/@``@`P!`A)[W_ MZ*^D`!BOI0`] M`!@#X``()`(``2>]_]BOI0`LKZ8`,`#@&"&/K@`XCZ\`/(^X`$"OI``HCZ4` M*(^G`#"/I@`LK[\`)```("&OHP`0KZX`%*^O`!@,$`9JK[@`'(^_`"0GO0`H M`^``"``````GO?_8KZ8`,`#@&"&/K@`XCZ\`/(^X`$"OI0`LCZ8`+(^G`#"O MOP`D```H(:^C`!"OK@`4KZ\`&`P0!FJON``]`"@#X``(`````">] M_]BOOP`4KZ0`*"0$`)BOL``0KZ4`+*^F`#`/X`2"KZ<`-`!`@"$`0"`A#^`$ M$"0%`)B/K@`P`````)'/``$`````.?@`*R\8``$3```(K[@`(#P$$``\!1`` M)*4'(`_@!%0DA#9P#!!'Y"0$``&/N0`P)`$`=Y,H````````%0$`78^K`"R/ MI@`L`````!#``!2/J@`H`,`@(0P01_`D!0&VCZD`(*^B`"@1(``*``````1` M``@`````CZ0`*`P01_@`````CZ0`+`P02``D!0`"KZ(`*(^F`"P`````CZH` M*``````%00`)CZ(`.#P$$``\!1``)*4'2`_@!%0DA#9P#!!'Y"0$``&/H@`X M)`L!VJ8+``"/K``T)`,``:8,``*/K0`\+$$``J8#``JF`P`(%"``!*8-``:/ MK@!``````*8.``@L00`#%"``!`````"/KP!$`````*8/``J6&``*`````!<# M``@D"0`#E@@`""09``(5`P`%IAD`!!````.F`P`$)`D``Z8)``0\"@"8-4J6 M@*X*``RN```0`@`@(0P0"J`GA8!`K@``%*8``'*/I``H`@`H(0P02`@D!@"8 M)`$`F!!!`%6/JP`@/`00`#P%$``DI0=L#^`$5"2$-G`,$$?D)`0``1```$R/ MJP`@CZL`+``````18``-CZT`*(^L`"``````$8``!```*"$0```")`4``@`` M*"&/I``L#!!(``````"OH@`HCZT`*``````%H0`$CZ0`*!```-```!`ACZ0` M*`(`*"$,$$@0)`8`F"0!`)@000`(`````#P$$``\!1``)*4'E`_@!%0DA#9P M#!!'Y"0$``&6!@``)`$!VC#/`/\`#\(```9R`@'8R"47(0`'`````"0(``&F M"`!R#!`(&@(`("$0```#E@8``*8``'*6!@``)`$!VA#!``@`````/`00`#P% M$``DI0>\#^`$5"2$-G`,$$?D)`0``98"``0`````+$$``Q`@``4L00`")`D` M`98"``2F"0`*+$$``A`@``2/JP`@)`H``:8*``B/JP`@`````!%@``6/K0`P M)`P`@!````RF#`!PCZT`,"0!`'*1KP```````!'A``4D&``!)`X``A````.F M#@!P)!@``:88`'"6&0`")`$!`#,H_P`5`0!S`````)8)``B6"@`*``````$J M`!D``!`2``(0@`!`("$/X`2"KZ(`'*X"`)"/I``<#^`$@@````"."P"0K@(` ME!%@``4`````C@P`E``````5@``)CZT`'#P$$``\!1``)*4'X`_@!%0DA#9P M#!!'Y"0$``&/K0`<)`$`=P`->$`E[@(`K@X`C(^X`#``````DQD````````7 M(0`9CZ0`*)8(``B6"0`*```P(0$)`!D``"@2&*``10```````!`A``4@@"0# M__^."@"0``````%"6"&M8```C@P`E``````!@F@A)$(`!`!$""H4(/_VK:,` M`!```#:F``!ZCZ0`*"0%`@`,$$@8```P(8^D`"B.!0"0CZ8`'`P02!`````` MCZ\`'``````03P`(`````#P$$``\!1``)*4(``_@!%0DA#9P#!!'Y"0$``&& M#@!R`````!'```:/I``HC@0`D(^E`!P,$`@!`````(^D`"B.!0"4CZ8`'`P0 M2!``````C[@`'``````06``(`````#P$$``\!1``)*4()`_@!%0DA#9P#!!' MY"0$``&&&0!R`````!,@``4`````C@0`E(^E`!P,$`@!`````*8``'JN``!\ MK@``@`P0!\\"`"`ACZ0`*"0(`@"N"`"(I@``=*8``':F``!XK@(`A"0%`@`` M`#`A#!!(&*X$`&P"`!`AC[\`%(^P`!`#X``()[T`*">]_^"OOP`4`(`8(91B M``8```````)Q@@'"("$/X`2"``0@@!1```BOH@`]`"``!'H",?C_```$=@(`!$(` M/`$`_P$!2"0!V,@E`RE0)0`$7@`#X``(`4L0)0`%$$,`@#`A&$``#```&"&4 MQ```)&,``0`#'````QP#``1R`@`$>@`!S\`E`&((*J38```4(/_V),8``@/@ M``@```````40@P"`,"$80``4```8(3P'`/\``W"``,XH(8RD```D8P`!``3" M`C,9_P``!'X"``1*``$G4"0!^4`E``,<```#'`,!"E@E``1F``%L:"4`8@@J M%"#_[ZRM```#X``(`````">]_^BOI``8CZ0`&*^_`!0,$`?P)`4`#(^D`!@D M!0`,#!`(`22$``R/I``8)`4`!`P0"`$DA`!HC[\`%">]`!@#X``(`````">] M_^"OOP`4KZ4`)">%@$@,$`9`KZ8`*!1```BOH@```-P`` M``"&&`!R`````!,```0"`"`A#!`(&@(`("$"`"`A`@`H(0P0"PXD!@"8AAD` M<@`````3(``#``````P0"!H"`"`AE@@``B0!`0`Q"?\`%2$`(@`````"`"`A M#!`+2B0%`@"6"@`(E@L`"@`````!2P`9``!@$@`,:("OK0`]_^BOOP`4E(X`<``` M```QSP`"$>``&(^_`!2,A0"``````!"@`!2/OP`4C)@`?``````3```0C[\` M%(2&`':$AP!X#!`(U*^D`!B/I``8`````)29``8`````$%D`!H^_`!24B`!P M`````#4)`""DB0!PC[\`%">]`!@#X``(`````````````````````">]_\BO ML``8`("`(:^_`!R6#@!P`*!0(3'/`((`P&`A%>```P#@6"$0``$3)`+__Y8" M``0`````+$$``Q`@``,L00`"``!8(2Q!``(0(``"````````8"&6`P`"```` M`#!B_P`40`!U)`$!`!```&HP8@#_E@0`!HX(``R."0`0C@,`A`"`$"$!0"@A M$$``$B2$__^4N```)*4``J!X``"08@````````$B""L0(``#`$@(*P!`2"$` M2`@K$"```@``````0$`A`(`0(22$__\40/_P)&,``:X(``RN"0`0`@`@(0&` M*"$,$`JL`6`P(98"``:.!0"$`@`@(0P0"PX`0#`AE@(`!A```-R/OP`C`!@3 M(``$`````(^D`"P,$`?P`&`H(98"``80``!8C[\`%#P$$``\!1``)*4(Y`_@ M!%0DA#9P#!!'Y"0$``$0``!/C[\`%"0!``$0H?_'`````"0!``(0H?_?```` M`!``__``````)`$!`!1!`#P`````$```,C!E`/\,$`MH`@`@(8X%`(0``C0` M``8T`PP0"RP"`"`AC@0`A(^F`"PD!0`!#!`-_"0'``*6`@`&$```,X^_`!0, M$`MH`@`@(0`"'`".!0"$``,<`P`"-```!C0#IZ,`&`P0"RP"`"`AA@@`C M`!@1```$`````(X$`(0,$`?P`&`H(8X$`(2/I@`L)`4``@P0#?PD!P`"E@(` M!A```!J/OP`4/`00`#P%$``DI0CX#^`$5"2$-G`,$$?D)`0``1```!&/OP`4 M)`$``1"A_\T`````)`$``A"A_]D`````$`#_\``````\!!``/`40`"2E"0P/ MX`14)(0V<`P01^0D!``!C[\`%(^P`!`#X``()[T`*``````GO?_HK[\`%`"` M&"$D9``8#^`$R"0&`%"/OP`4)[T`&`/@``@``````^``"*R%`&@GO?_HK[\` M%`"@."$`X"@AKZ<`'*^D`!@,$`KLKZ8`((^D`!B/I@`@CZ<`')2#``*D@`!T M,&+_`*2&`'@40``6I(<`=I2"``:4CP`(`,(`&3!I`/\``'`2```````````! MSP`9``#`$@```````````.(`&0``R!(#.$`A``````$)`!D``"@2#!`+2B2E M`@`0```8C[\`%"0!`0`400`-`````)2+``B,B@"0`,L`&0``8!(!AV@A``UP M@`%.>"&-Y0``#!`+2@`````0```)C[\`%#P$$``\!1``)*4),`_@!%0DA#9P M#!!'Y"0$``&/OP`4)[T`&`/@``@`````)[W_Z*^_`!0`@!@AE&X`"`"@0"$! M#@@K$"``!@#`."&4;P`*``````#O""L4(``3C[\`%#P$$``\!1``)*4)3"2$ M-G`!`#`A#^`$5*^C`!B/HP`8/`00`#P%$`"49@`(E&<`"B2E"70/X`14)(0V M<`P01^0D!``!C[\`%">]`!@#X``(`````">]_^"OI``@CZX`(*^F`"BOOP`4 MCZ8`*(W$`&P,$$@(`````(^O`"BOH@`<$$\`"8^C`"`\!!``/`40`"2E"8@/ MX`14)(0V<`P01^0D!``!CZ,`((^Y`"B,>`"(``````,90"&L:`"(C[\`%(^B M`!P#X``()[T`(">]_^"OI``@CZX`(*^F`"BOOP`4CZ8`*(W$`&P,$$@0```` M`(^O`"BOH@`<$$\`"8^C`"`\!!``/`40`"2E":0/X`14)(0V<`P01^0D!``! MCZ,`((^Y`"B,>`"(``````,90"&L:`"(C[\`%(^B`!P#X``()[T`(">]_^BO MOP`4`(`8(8QN`(@`````$<4`$H^_`!2,9`!LK&4`B*^E`!P,$$@8```P(01! M``F/I0`]`!@#X``(`*`0(0```````````````">]_^"OOP`4E(\`"(2.`'B$AP!V M`<\`&8R)`)0``,`2`P?((0`90(`!*%`AC48````````$P0`,C[\`%#P$$``\ M!1``)*4)X"2$-G`/X`14KZ8`'`P01^0D!``!CZ8`'`````"/OP`4)[T`(`/@ M``@`P!`A)[W_Z*^F`""OI0`P$@*"$`X"`A).<``@#H""L0(``7`````)#B__^0[__^`````!7B``4````` MD/@````````06``.`````"3G``$`Z`@K$"``"@````"0XO__D/G__@`````7 M(O_X`````)#J````````%$K_]``````DY__^`.0P(Q#``#8`````*,$`?Q0@ M``0`!AP`$````R0#`'X`!AP```,<`S1K`(`H80`)H*L```##,",4(``9)*4` M`9",```D8__XH*P``)"-``$``QP`H*T``9".``(``QP#H*X``I"/``,H80`) MH*\``Y"8``0DI0`(H+C__)"9``4DA``(H+G__9"*__X`````H*K__I"+__\0 M(/_IH*O__P!@$"$D8___``,<`!!```H``QP#`&`0(9",```D8___``,<```# M'`,DA``!)*4``11`__B@K/__%,#_S2C!`'\`X"`A).<``0#H""N0X___$"`` M#@#D,".0[0```&`0(16B``H`Y#`C).<``0#H""L0(``&`.0P(Y#N```````` M$<+_^0``````Y#`C$,``$`#H""L`8!`A*,$`?Q0@``0`!AP`$````R0#`'X` M!AP```,<`P##,".@HP``)*4``22E``$4P/_TH*+__P#H""L4(/^(`.`@(22E M``$`J1`C$``!OJ"@__\08@`$)`4``A```(PD!0`")`4``A3E`(D`````CZ\` M*`"`."$`CT`A`(@(*Q`@`'L!("@A`.`@(23G``(`Z`@K$"``%P````"0XO__ MD/C__@`````7`@`%`````)#Y````````$%D`#@`````DYP`!`.@(*Q`@``H` M````D.+__Y#J__X`````%4+_^`````"0ZP```````!1+__0`````).?__@#D M,",0P``V`````"C!`'\4(``$``8<`!````,D`P!^``8<```#'`,T;`"`*&$` M":2L````PS`C%"``&22E``*0C0``)&/_^*2M``"0C@`!``,<`*2N``*0CP`" M``,<`Z2O``20F``#*&$`":2X``:0F0`$)*4`$*2Y__B0B@`%)(0`"*2J__J0 MB__^`````*2K__R0C/__$"#_Z:2L__X`8!`A)&/__P`#'``00``*``,<`P!@ M$"&0C0``)&/__P`#'````QP#)(0``22E``(40/_XI*W__A3`_\THP0!_`.`@ M(23G``$`Z`@KD./__Q`@``X`Y#`CD.X```!@$"$5P@`*`.0P(R3G``$`Z`@K M$"``!@#D,".0[P```````!'B__D``````.0P(Q#``!``Z`@K`&`0(2C!`'\4 M(``$``8<`!````,D`P!^``8<```#'`,`PS`CI*,``"2E``(DI0`"%,#_]*2B M__X`Z`@K%"#_B`#@("$DI0`"`*D0(P1!``(`0`@A)"$``0`!$$,0``$OI*#_ M_A1E`)``````%.(`C@````"/N``H`(`X(0`8R$``F4`A`(@(*Q`@`(,!("@A M`.`@(23G``0`Z`@K$"``%P````"4XO_^E.K__``````50@`%`````)3K```` M````$$L`#@`````DYP`"`.@(*Q`@``H`````E.+__I3L__P`````%8+_^``` M``"4[0```````!1-__0`````).?__`#D,",$P0`"`,`((20A``$``3!#$,`` M-@`````HP0!_%"``!``&'``0```#)`,`?@`&'````QP#-&X`@"AA``F@K@`` M`,,P(Q0@`!DDI0`!E(\``"1C__B@KP``E)@``@`#'`"@N``!E)D`!``#'`.@ MN0`"E(H`!BAA``F@J@`#E(L`""2E``B@J__\E(P`"B2$`!"@K/_]E(W__``` M``"@K?_^E([__A`@_^F@KO__`&`0(21C__\``QP`$$``"@`#'`,`8!`AE(\` M`"1C__\``QP```,<`R2$``(DI0`!%$#_^*"O__\4P/_-*,$`?P#@("$DYP`" M`.@(*X3C__X0(``.`.0P(Y3X````8!`A%P(`"@#D,",DYP`"`.@(*Q`@``8` MY#`CE/D````````3(O_Y``````#D,",$P0`"`,`((20A``$``3!#$,``$`#H M""L`8!`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`P##,".@HP``)*4` M`22E``$4P/_TH*+__P#H""L4(/^``.`@(22E``$`J1`C$```GJ"@__\490"4 M`````!3E`)(`````CZH`*`"`."$`"EA``(M`(0"(""L0(`"#`2`H(0#@("$D MYP`$`.@(*Q`@`!<`````E.+__I3L__P`````%8(`!0````"4[0```````!!- M``X`````).<``@#H""L0(``*`````)3B__Z4[O_\`````!7"__@`````E.\` M```````43__T`````"3G__P`Y#`C!,$``@#`""$D(0`!``$P0Q#``#8````` M*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`S1X`(`H80`)I+@```##,",4 M(``9)*4``I29```D8__XI+D``)2*``(``QP`I*H``I2+``0``QP#I*L`!)2, M``8H80`)I*P`!I2-``@DI0`0I*W_^)2.``HDA``0I*[_^I2/__P`````I*__ M_)28__X0(/_II+C__@!@$"$D8___``,<`!!```H``QP#`&`0(929```D8___ M``,<```#'`,DA``")*4``A1`__BDN?_^%,#_S2C!`'\`X"`A).<``@#H""N$ MX__^$"``#@#D,".4Z@```&`0(15"``H`Y#`C).<``@#H""L0(``&`.0P(Y3K M````````$6+_^0``````Y#`C!,$``@#`""$D(0`!``$P0Q#``!``Z`@K`&`0 M(2C!`'\4(``$``8<`!````,D`P!^``8<```#'`,`PS`CI*,``"2E``(DI0`" M%,#_]*2B__X`Z`@K%"#_@`#@("$DI0`"`*D0(P1!``(`0`@A)"$``0`!$$,0 M```)I*#__CP$$``\!1``)*4*`"2$-G`/X`14`&`P(0P01^0D!``!C[\`%">] M`!@#X``(`````">]_^@`H!@A)`(``:^_`!0`@$`A%&(`5`#`2"$4X@!2```` M``$`,"$!(!`AD,0``"3&``$PA0!_,*7__Q"@`56/OP`4,(X`@!'``"H````` M+*$`"!0@`!H`H!@AD,\``"2E__B@3P``D-@``3"E__^@6``!D-D``BRA``B@ M60`"D,H``R1"``B@2O_[D,L`!"3&``B@2__\D,S__0````"@3/_]D,W__@`` M``"@3?_^D,[__Q`@_^F@3O__`*`8(22E__\08/_9,*7__P"@&"&0SP``)*7_ M_S"E__\DQ@`!)$(``11@__F@3___$`#_T)#$``"0Q```+*$`"!0@``XDQ@`! M)*7_^#"E__\LH0`(H$0``*!$``&@1``"H$0``Z!$``2@1``%H$0`!J!$``<0 M(/_T)$(`"`"@&"$DI?__$&#_NC"E__\`H!@A)*7__S"E__^@1```%&#_^R1" M``$0`/^SD,0``!!B``0D!``"$```520$``(D!``"%.0`4@`````!`#`A`2`0 M(9#$```DQ@`!,(4`?S"E__\0H`#]C[\`%#"8`(`3```J`````"RA``@4(``: M`*`8(9#9```DI?_XI%D``)#*``$PI?__I$H``I#+``(LH0`(I$L`!)#,``,D M0@`0I$S_]I#-``0DQ@`(I$W_^)#.__T`````I$[_^I#/__X`````I$___)#8 M__\0(/_II%C__@"@&"$DI?__$&#_V3"E__\`H!@AD-D``"2E__\PI?__),8` M`21"``(48/_YI%G__A``_]"0Q```D,0``"RA``@4(``.),8``22E__@PI?__ M+*$`"*1$``"D1``"I$0`!*1$``:D1``(I$0`"J1$``RD1``.$"#_]"1"`!`` MH!@A)*7__Q!@_[HPI?__`*`8(22E__\PI?__I$0``!1@__LD0@`"$`#_LY#$ M```49`!4`````!3B`%(``````0`P(0$@$"&4Q```),8``C"%`'\PI?__$*`` MJ(^_`!0PB@"`$4``*@`````LH0`(%"``&@"@&"&4RP``)*7_^*!+``"4S``" M,*7__Z!,``&4S0`$+*$`"*!-``*4S@`&)$(`"*!.__N4SP`(),8`$*!/__R4 MV/_Z`````*!8__V4V?_\`````*!9__Z4RO_^$"#_Z:!*__\`H!@A)*7__Q!@ M_]DPI?__`*`8(93+```DI?__,*7__R3&``(D0@`!%&#_^:!+__\0`/_0E,0` M`)3$```LH0`(%"``#B3&``(DI?_X,*7__RRA``B@1```H$0``:!$``*@1``# MH$0`!*!$``6@1``&H$0`!Q`@__0D0@`(`*`8(22E__\08/^Z,*7__P"@&"$D MI?__,*7__Z!$```48/_[)$(``1``_[.4Q```%&0`5``````4Y`!2``````$` M,"$!(!`AE,0``"3&``(PA0!_,*7__Q"@`%./OP`4,(P`@!&``"H`````+*$` M"!0@`!H`H!@AE,T``"2E__BD30``E,X``C"E__^D3@`"E,\`!"RA``BD3P`$ ME-@`!B1"`!"D6/_VE-D`""3&`!"D6?_XE,K_^@````"D2O_ZE,O__`````"D M2__\E,S__A`@_^FD3/_^`*`8(22E__\08/_9,*7__P"@&"&4S0``)*7__S"E M__\DQ@`")$(``A1@__FD3?_^$`#_T)3$``"4Q```+*$`"!0@``XDQ@`")*7_ M^#"E__\LH0`(I$0``*1$``*D1``$I$0`!J1$``BD1``*I$0`#*1$``X0(/_T M)$(`$`"@&"$DI?__$&#_NC"E__\`H!@A)*7__S"E__^D1```%&#_^R1"``(0 M`/^SE,0``#P$$``\!1``)*4*("2$-G`/X`14`&`P(0P01^0D!``!C[\`%">] M`!@#X``(`````*^D````@#@A)`X``:3N``BLX`#8)`\`_ZSO`-PT&/__K/@` MY"09__^L^0#H)`C__ZSH`.RLX`#`K.``T*S@`-0D`4U-%*$`#0`````D"0`8 MK.D`Q"0*`!"LZ@#,%,``!0````"$ZP`*`````#5L`!"D[``*$```"0````"L MX`#$K.``S!#```4`````A.T`"@`````UK@`0I.X`"A````$``````^``"``` M```GO?_`K[\`'*^D`$"OI0!$K[``&(^N`$0`````D=```!```"(`````KZ`` M.(^O`$0D`0`KD?@``0`````7`0`#`````"09``*ON0`X$```(@`````D"`$" MKZ@`.(^I`$0D`0!WD2H````````500`%`````(^K`#@`````-6P"`*^L`#@0 M```4`````#P$$``\!1``CZ8`1"2E"FP,$"5$)(0*8!```1P``!`A)`$`81(! M_^@`````)`$``````(^N`#P`````A=@`"@`````S#P`0 M$>``!P````"/I`!`/`40``P0)40DI0LZ$```$0````"/I``\#!`7IP`````4 M0``#`````!````H`````CZ(`/!```!$`````)`$`81(!_^<`````)`$`]`$`GO?_X)(X`%*^N``2/KP`$`````)7X``:5^0`" M``````,9`!D``$`2KZ@```````"/J0`$)`$``94J`"X`````%4$`"0````"/ MK``$CZL``)6-`!(``````6T`&0``]``@GO?^`K[\` M/*^D`("OM``XK[(`,*^S`#2OL``HK[$`+.>U`"#GM``D``"0(:^@`'"OH`!8 MCZX`@`````"-SP`0`````*W/``R/N`"``````(\9``P`````%R```P`````0 M``/O```0(8^H`(```#`AA00`!(T%``P,$$@8`````(^I`(``0)@AC2H`#``` M```2:@`(`````(^K`(`\!1``C60```P0)40DI1-I$``#W```$"&/K`"`)Z4` M8(6$``0,$$@0)`8``@!`F"$D`0`"$F$`"`````"/K0"`/`40`(VD```,$"5$ M)*43C1```\P``!`ACZ\`@`````"%[@`*`````#'8`!`3```#``````P0)6@G MI`!@AZ0`8```````@`@A``$@@`"!(",/X`2"``0@@*^B`'"/N0!P`````!<@ M``@`````CZ@`@#P%$`"-!```#!`E1"2E$Z\0``.P```0(8>F`&"/J0"``,`( M(0`!,(``P3`CCZ4`<(4D``0,$$@0``8P@(>J`&``0)@A``I8@`%J6",`"UB` M$FL`"`````"/K`"`/`40`(V$```,$"5$)*43SQ```XX`````CZT`@"0&``2% MI``$#!!($"6E`!``0)@A)`$`!!)A``0`````CZ\`@`````"MX``0CZX`@``` M``"%V``*`````#,9`!`3(``$`````(^D`(`,$"5W)(0`$(^H`(`D`?_WA0D` M"@`````!(5`DI0H`"H^R`(``````)E(`%(^K`(``````C6P`#(UM`+P````` M$8T`!P````"/I`"`#!`78@`````"0"`A#^`$$"0%`*2/I`"`#!`7IP````"/ MI`"`)`4!'`P0%\TD!@`!/`\0`"7O#-B/L`!PA[$`8*^O`&0:(`#Q`````(^N M`(``````A=@`"@`````S&0`0$R``!P`````"`"`A#!`ECR0%``(F!``$#!`E MI"0%``*/J@!DE@D``)5(`````````2@(*Q`@``\`````CZL`6``````58``( M`````(^L`(`\!1``C80```P0)?0DI1/K)`T``:^M`%@\#Q``)>\,V*^O`&2/ MK@!D/!@0`"<8#^@!V`@K$"``%P````"5V0``E@H````````#*@@K$"``$0`` M``"/J0!D`````"4H`!"OJ`!DCZL`9#P,$``EC`_H`6P(*Q`@``<`````E6T` M`)8/`````````:\(*Q0@__$`````C[@`9#P.$``ES@_H`PX(*Q`@``8````` MEQD``)8*````````$RH`"P````"/J0"`/`40`)8&``"6!P``C20```P0)?0D MI10JI@```!```)H`````CZ@`9#0!__^5#``(`````!6!``0`````I@```!`` M`)$`````CZT`9)8+``*-KP`$`````!%O`"``````CZX`9``````EV``0K[@` M9(^Y`&0\"A``)4H/Z`,J""L0(``&`````)X`!``````5;O_B`````)83```0``!7`````(^J`&2/N`"`E5D`""0+ M``$`&4E"``E`@`,(8"&-C0"@,R\`'P'K<`0!KE`EK8H`H!```%L`````CZD` M@"0!34V5.`"X`````!UP!A````D!R)@DE@L``H^Y`(``"VB``RUX(8WJ`-B. M"0`(``````$JF"2/I`"`E@4```P0%\T"8#`A%$```P`````0``*@`````!`` M`#<`````CZP`@"0!34V5F`"X`````!0#`C@T`"`&*P"&/#@#8`RUX!A````D![I@DE@L``H^H`(``"VB` M`0W((8\I`-B.#``(``````&)F"2/I`"`E@4```P0%\T"8#`A%$```P`````0 M``)\`````!```!,`````)`$!`1)A_[8`````)`$!$1)A_Z4`````)`$!%1)A M_[``````)`$!%A)A_]$`````)`$!%Q)A_YP`````)`$!'!)A_Z<`````)C'_ M_R80``P>(/\1`````(^J`(``````C5@`H``````S#P`!%>``!P````"/I`"` M/`40``P0%1(DI11V$``"5P````"/K@"`/`$`"(W+`*```````6%`)!4```<` M````CZ0`@#P%$``,$!42)*44@A```DH`````CZT`@#P!@`"-N0"@``````,A M8"05@``'`````(^D`(`\!1``#!`5$B2E%)80``(]`````(Y)`!@D`?__%2$` M!0`````D"@`!KDH`E!````TD$P`!EE@`!(Y/`!B.2``8`P]P(27+__\!:``; M%0```@``````!P`-``"@$JY4`)0"@)@ACDT`E`````"N30"8EED`+B0!``(7 M(0`(`````(Y,`)B620`2``````&)`!D``%`2KDH`F`````"/L`!PA[$`8``` M```:(`&,`````)88````````%P```P`````0``&"`````)8/``(D`0`"%>$` M'@````".#@`$`````!'``!@`````C@0`!`_@!((DA``!KZ(`7(^K`%P````` M$6``#@````"/I`"``@`H(0P0%2(!8#`A$$``"`````"/I`"`E@4``(^F`%P, M$!?-`````!1```,`````$``!\0`````0``%A`````)8(``(D`0`%%0$`$0`` M``"/I`"`#!`5D@(`*"%&(`4&1`>@`$0&J`"/I`"`E@4```P0%\T`````%$`` M`P`````0``'=`````!```4T`````EA,``!```/8`````C@T`!"0!``$5H0`G M`````(^Y`(`D`4U-ERP`N``````5@0`.`````)8)``*6"``"``E0@`,JP"$` M"&B`CP\`P(X.``@#+6`AC8D`V`'N6`8!:5`D$```"J^J`&B6#@`"C[@`@``. M>(`##T`AC1D`V(X-``@``````;E@)*^L`&B/I`"`CZ8`:`P0%\TD!0$#%$`` M`P`````0``&P`````!```2``````CZ0`@`(`*"$,$!7=)Z8`:!!```@````` MCZ0`@)8%``"/I@!H#!`7S0`````40``#`````!```9\`````$``!#P````"/ MI`"`CD8`F`(`*"$,$!9Q)D<`G!1```,`````$``!E`````"/JP"`/`&``(UI M`*```````2%0):UJ`*`0``#^`````(^D`(".1@"8`@`H(0P0%G$F1P"@%$`` M`P`````0``&#`````(^N`(`\`2``C=@`H``````#`7@EK<\`H!```.T````` M$```ZP````"62``&)`T``0$-R`0`&6!`KZP`:)8)```D`0$C%2$`!`````"/ MLP!H$```!@````"/LP!H``````)@""$``9B``F&8(P_@!(("8"`AKZ(`7(^J M`%P`````%4```P`````0``%?`````(^K`%R/N`!HCZ0`@``8>$"6!0```6]P M(:^N`!`!8#`A#!`7S0%X."$00``'`````(^D`("/I@!<#!`5(@(`*"$40``# M`````!```4L`````$```NP````"/I`"`)D4`0`P0%<,"`#`ACZT`@#P!!`"- MJ`"@``````$!R"6MN0"@$```KP````"OH`!HCZP`@"0!34V5B0"X`````!4A M``T`````E@H``I89``(`"L"``9A8(0`9:("-;P#`C@X`"`&-2"&-*@#8`>Y` M!A````D!"I@DE@L``H^X`(``"W"``PYX(8WY`-B.#``(``````&9F"00```) M`````"0-``&OK0!H$```"P`````D"0`"KZD`:!````<`````)`$``A)A__8` M````)`$``Q)A__<`````CZ0`@)8%``"/I@!H#!`7S0`````40``#`````!`` M`0D`````$```>0````"/J`"`)`%-394*`+@`````%4$`#0````"6"P`"E@T` M`@`+P(`!&'`A``U(@(W/`,".#``(`0E0(8U+`-@![,@&$```"0,KF"26#@`" MC[@`@``.8(`##'@AC>T`V(X(``@``````0V8)(^D`("6!0``#!`7S0)@,"$4 M0``#`````!```.4`````$```50`````D`0$7$F'_50`````N80$8$"``)P`` M```D`0$#$F'_`P`````N80$$$"``$0`````D`0$!$F'_6@`````N80$"$"`` M!@`````D`0#_$F'_D@`````0`/_&`````"0!`0(28?\<`````!``_\$````` M)`$!%1)A_TH`````+F$!%A`@``8`````)`$!$1)A_R(`````$`#_M@`````D M`0$6$F'_/P`````0`/^Q`````"0!`2,28?\\`````"YA`200(``1`````"0! M`1D28?\!`````"YA`1H0(``&`````"0!`1@28?[[`````!``_Z``````)`$! M'!)A_RD`````$`#_FP`````D`0$M$F'_)@`````N80$N$"``!@`````D`0$I M$F'_4``````0`/^0`````"0!`4`28?\;`````!``_XL`````$`#_B0`````F M,?__)A``#!X@_G8`````CZD`@#P!(`"-*@"@``````%!R"07(`!8`````(Y+ M`)@`````+6$``A0@``<`````CZ0`@#P%$``,$!42)*44HQ```'D`````#!`7 M/"0$`1>/K@"``$"8(8YF``P\!1``C<0```P0)?0DI12S#^`$@B0$``0`0)@A MKE,`H(>X`&```````!A@@`&88",`#&"`)8\`#J^O`$2/L`!PA[$`8``````: M(``:`````)8-``(\"A````U(@`%)4"&-2A+XC@@`!``````!"@`9``#($J^Y M`$``````CZL`0``````M80`%%"``!@````"/K@!$C[@`0``````!V&`AKZP` M1"8Q__\F$``,'B#_Z`````"/KP"``````(7D``0,$"78`````(^M`$2.2`"@ M`$"8(0)M2".M"0``CZH`@#P!(`"-60"@``````,A6"6M2P"@CZX`@#P!``&- MV`"@``````,!8"05@``$`````)9/``0`````KD\`&(^M`'``````$:``!``` M``"/I`!P#^`$@`````"/J0"`/`$`!(TH`*```````0'()!<@``8`````EDL` M!B0*``$!:G`$)=C__ZY8`""/K`"``````(V/`*``````,>T`0!6@``4````` MCZ0`@"0%`0,,$!?-)`8``8^H`(`D"?__K0D`\(^J`(`D&?__K5D`](^D`(`, M$!#9`````(^K`(``0)@AK7,!'!````PD`@`!CZX`<``````1P``$`````(^D M`'`/X`2``````!````,``!`A$````0````"/OP`\Q[4`(,>T`"2/L``HC[$` M+(^R`#"/LP`TC[0`.`/@``@GO0"`)[W_Z*^_`!2OI``8KZ4`'(^N`!@\!1`` MCZ8`'(W$```,$"5$)*44_Q````$`````C[\`%">]`!@#X``(`````">]_]"O MOP`]`#`GO?_0K[\` M'*^D`#"OI0`TK[``&(^D`#"/I0`T#!`5(B>F`"@40``%`````,>!@!#'@(`4 M$```'P````"/K@`L`````!7``!$`````CZ\`-`````"5Y```#!`7/`````"/ MN``P`$"`(8X&``P\!1``CP0```P0)40DI150QX&`$,>`@!00```+`````(^Y M`"B/J``L1)D@`$2(0`!&@"&A1H!"H1````-&*C`#$````0````"/OP`D``HWJ``@`"0```P0)40DI165$```%```$"&/J@`T`````"5-``&OK0`TCZX`1(^K`#2- MR0`$``````%I""L4(/_@`````)>X`#B/J`!(`````*T8```0```#)`(``1`` M``$`````C[\`)(^P`!B/L0`0` M``P0%SP`````CZX`2`!`B"&.)@`,/`40`(W$```,$"5$)*46`A```(H``!`A MC[@`5`````"/$````````"09``&ON0!`CZ@`3"0!``.5"0`"`````!4A`&<` M````CZH`3`````"-2P`$`````"UA``,4(``^`````(^L`$P\#Q``C>\3!(V- M``0``````:\`&0``(!(/X`2"`````*^B`#B/K@`X`````!7```\`````C[@` M3`````"7!```#!`7/`````"/N0!(`$"((8XF``P\!1``CR0```P0)40DI18: M$```6P``$"&/I`!(CZ4`3(^F`#@,$!4B`````*^B`$"/J`!``````!$``!,` M````C[(`.`````"/J0!0``````$@B"$E*O__&B``"Z^J`%"62P``)E(``B80 M``2N"__\CZP`4``````!@(@A)8W__QX@__>OK0!0CZ0`.`_@!(``````$``` M(0````"/KP!()`%-397N`+@`````%<$`#P````"/N`!,)A``!(\9``@````` M`!E$`JX(__R/J0!,`````(TJ``@`````,4O__ZX+```0```-`````(^L`$PF M$``$C8T`"``````QK___K@___(^N`$P`````C=@`"```````&,P"KAD``!`` M`!,`````CZ@`3`````"-"0`$`````"TA``(4(``'`````(^D`$B/I0!,#!`5 M(@(`,"$0```&KZ(`0(^J`$P`````C4L`"`````"N"P``CZ(`0!````,````` M$````0````"/OP`LC[``((^Q`"2/L@`H`^``"">]`$@GO?_8K[\`'*^D`"BO ML``8/!`0`"80#-@\#A``)F`"HDI0N9#!`E1"2$"XP,$$?D)`3__Q````$`````C[\`'(^P`!@#X``( M)[T`*">]_]BOOP`'`)!,```0`````C@0`3`_@!(``````C[D`*#P!$`"/*`"@``````$! M2"01(``*`````(X$`%`/X`2``````(X$`%@/X`2``````(X$`%0/X`2````` M`(^J`"@`````C4L`I``````Q;``!$8``"@````".!`!<#^`$@`````".!`!D M#^`$@`````".!`!@#^`$@`````".#0"<`````!&@``0`````C@0`G`_@!(`` M````C@X`H``````1P``$`````(X$`*`/X`2``````!````$`````C[\`'(^P M`!@#X``()[T`*">]_]BOOP`X`""08``:ON``H$``"T@````"/N0`P)`'__""2OKP`PC?C__(^Y`#0````` MIS@`$"0(``ZOJ``H$``"-@````"/J0`P)`'__"4J``0```P0)40DI0O[$``"0@````"/N``LC[D` M-`````"G.``2)`@`#Z^H`"@0``(3`````(^I`#`D`?_\)2H`!P%!6"2OJP`P MC6S__`````"OK``LCZT`+``````5H``#`````!```B$`````CZX`+(^O`#0` M````K>X`&"08`!"ON``H$``!_0````"/N0`P)`'__"'` M)*^X`#"/&?_\CZD`-#,H__^M*``@)`H`$J^J`"@0``'C`````(^K`#`D`?_X M)6P`#P&!:"2OK0`PQ:3__,6E__B/K@`T1B`AH.7&`"0D#P`"KZ\`*!```=4` M````C[@`,"0!__@G&0`/`R%`)*^H`##%"/_\Q0G_^(^I`#1&($*@Y2H`*"0* M``*OJ@`H$``!QP````"/JP`P)`'__"5L``OJP`H$``!9P````"/K``P)`'_ M_"6-``$`````$```B0`````D`0$/$@'^'0`````0``"$```` M`"0!`142`?Y,`````"H!`180(`!^`````"0!`1(2`?XY`````!```'D````` M)`$!&Q(!_J(`````*@$!'!`@`!$`````)`$!&1(!_H$`````*@$!&A`@``8` M````)`$!&!(!_FX`````$```:``````D`0$:$@'^@P`````0``!C`````"0! M`1T2`?ZJ`````"H!`1X0(``&`````"0!`1P2`?Z4`````!```%@`````)`$! M'A(!_JP`````$```4P`````D`0$M$@'_)P`````J`0$N$"``)P`````D`0$E M$@'^Y``````J`0$F$"``$0`````D`0$C$@'^Q``````J`0$D$"``!@`````D M`0$B$@'^L0`````0```\`````"0!`202`?[&`````!```#<`````)`$!*1(! M_N@`````*@$!*A`@``8`````)`$!*!(!_M4`````$```+``````D`0$L$@'^ M\P`````0```G`````"0!`3P2`?VA`````"H!`3T0(``1`````"0!`3(2`?V. M`````"H!`3,0(``&`````"0!`3$2`?W)`````!```!8`````)`$!.Q(!_78` M````$```$0`````D`0%`$@'_!``````J`0%!$"``!@`````D`0$]$@'_'0`` M```0```&`````#0!@.,2`?\E`````!````$`````CZ\`*``````%X``6```` M`(^Y`"B/N``X``````D`#X,$!<\`````(^Y`#@`0(`AC@<`##P%$`"/I@`LCR0```P0 M)40DI0P9$````P``$"$0```!`````(^_`!R/L``8`^``"">]`#@GO?_(K[\` M'*^D`#BOI0`\KZ8`0*^G`$2OL0`8K[``%(^N`#@`````)<\`%*^O`#`\$!`` M)A`,V#P8$``G&`_H`A@(*Q`@``X`````EAD``(^H`#P`````%R@``P`````0 M```'`````"80`!`\"1``)2D/Z`()""L4(/_T`````#P*$``E2@_H`@H(*Q0@ M``D`````/`00`#P%$`"/I@`\)*4,/0P0)40DA`PP$```'P``$"&6#``(CZL` M.``,:4*6&0`(``UP@`%N>"&-^`"@)`D``3,H`!\!"5`$`PI@)!&```X````` M)ZT`/"6K``] M__@0``&,`*`X(23&``X``!```.\`````),8`!R0!__P`P3`D MC-G__(R8`*``````KS@``!```.8`````),8`!R0!__P`P3`DC,G__)2(`$@` M````I2@``!```-T`````)`$!'Q#A_U0`````*.$!(!`@`(4`````)`$!%A#A M_P\`````*.$!%Q`@`%,`````)`$!"A#A_J8`````*.$!"Q`@`"<`````)`$! M`A#A_GP`````*.$!`Q`@`!$`````)`$!`!#A_F0`````*.$!`1`@``8````` M)`$`_A#A_E4`````$```N@`````D`0$!$.'^8@`````0``"U`````"0!`080 MX?YX`````"CA`0<0(``&`````"0!`0,0X?YI`````!```*H`````)`$!!Q#A M_G8`````$```I0`````D`0$0$.'^N0`````HX0$1$"``$0`````D`0$.$.'^ MH0`````HX0$/$"``!@`````D`0$-$.'^=P`````0``"4`````"0!`0\0X?Z? M`````!```(\`````)`$!$A#A_K4`````*.$!$Q`@``8`````)`$!$1#A_X\` M````$```A``````D`0$5$.'^LP`````0``!_`````"0!`1L0X?[;`````"CA M`1P0(``7`````"0!`1D0X?[#`````"CA`1H0(``,`````"0!`1@0X?ZT```` M`"CA`1D0(`!M`````"0!`1<0X?]\`````!```&@`````)`$!&A#A_KL````` M$```8P`````D`0$=$.'^XP`````HX0$>$"``!@`````D`0$<$.'^P@`````0 M``!8`````"0!`1X0X?[&`````!```%,`````)`$!+1#A_R(`````*.$!+A`@ M`"<`````)`$!)1#A_O$`````*.$!)A`@`!$`````)`$!(Q#A_MD`````*.$! M)!`@``8`````)`$!(A#A_LH`````$```/``````D`0$D$.'^UP`````0```W M`````"0!`2D0X?[M`````"CA`2H0(``&`````"0!`2@0X?[>`````!```"P` M````)`$!+!#A_O(`````$```)P`````D`0$\$.'^(``````HX0$]$"``$0`` M```D`0$R$.'^$0`````HX0$S$"``!@`````D`0$Q$.'^.``````0```6```` M`"0!`3L0X?W]`````!```!$`````)`$!0!#A_O<`````*.$!01`@``8````` M)`$!/1#A_P@`````$```!@`````T`8#C$.'_'@`````0```!`````!````$` M`````^``"">]``@GO?_8K[\`'*^D`"BOI0`LKZ8`,*^G`#2OL``8)ZX`+"7/ M``'`)*^X`"2/I``HCZ4`+(^F`"0,$!NO``````!`@"$0```!```` M`(^_`!R/L``8`^``"">]`"@GO?^8K[\`)*^D`&BOL@`@K[``&*^Q`!R/K@!H M`````(7/``8`````%>```P`````0``*6)`(``8^X`&@`````)QD`%*^Y`$2O MH`!'2>F`%"/J`!,CZP`2)4.````````I8X``(^I M`$@D"P`"I2L``H^D`%`/X`3"`````(^J`$@`0(`A)@T``:U-``2/N`!(CZ0` M:(^F`%`G#P`,KZ\`2`P0(9H#`"@A%$```P`````0``'D`````(^Y`$PGJP!H MER@`""08``$`"'%"``Y@@`&+2"$Q"@`?C2W_S`%8>`0!X,@G`;EP)*TN_\P0 M``&+`````(^L`$P`````E9``"!```6\`````CZL`3"0!`!^5:``(`````!4! M``8`````C[@`1`````"/$`"<$```!0````"/J@!$`````(U0`*``````CZ\` M3(^M`$B/I`!HE>4``"6Y``RON0!(`@`X(0P0(6T!H#`A%$```P`````0``&T M`````!```5L`````CZX`3(^L`$B5R0```````*6)``"/J`!()`L``Z4+``*/ MN`!$C[D`2)<*``8D#P`!`4]H!*\M``2/K@!(CZD`1(^D`&@ES``,C28`3*^L M`$@,$"&:`<`H(11```,`````$``!F``````0``$_`````(^K`$R/N`!(E6@` M``````"G"```CZH`2"0/``.E3P`"CZT`1(^L`$B5N0`&)`D``0,I<`2MC@`$ MCXN`T`````"OJP`\CZ@`3"0!`4"5&````````!8`7`P0(9H`````$$``$0````"/J@!$CZ0`:(^E`$B-1@!@#!`AF@`` M```00``)`````(^M`$2/I`!HCZ4`2(VF`&0,$"&:`````!1```,`````$``! M90`````0```;`````(^I`$2/I`!HCZ4`2(TF`%`,$"&:`````!!``!$````` MC[D`1(^D`&B/I0!(CR8`5`P0(9H`````$$``"0````"/K@!$CZ0`:(^E`$B- MQ@!8#!`AF@`````40``#`````!```4D`````CZP`2`````"-BP`$```````+ M0(`!"T`CK8@`!(^X`#R/KP!(`````*WX``@0``#E`````(^M`$@D"@$`I:H` M`(^Y`$@D"0`#IRD``H^K`$@D#@`!K6X`!(^H`&@D`4U-E0P`N``````5@0`+ M`````(^X`$2-"@#DEP\``HT)`,R/N0!(`>IH)`$MB`0"((`A$```":\Q``B/ MK@!$CZP`:)7+``*-F`#DCZ\`2`%XD"0"0(`AK?(`"(^J`$@`````)4@`#*^H M`$B/J0!()`T!`:4M``"/K@!()!D``Z79``*/JP!()`P``:UL``2/N`!H)`%- M39$`"P````"/J@!$CPT`Y)5(``2/&0#,CZX`2`$-2"0#*8@$ M`B"`(1````FMT0`(CZP`1(^O`&B5BP`$C>H`Y(^H`$@!:I`D`D"`(:T2``B/ MK0!(`````"6X``RON`!($```F0````"/J0!(C[D`1(^D`&@E+@`,CR<`,*^N M`$@D!0$>#!`@W@$@,"$00``,`````(^L`$B/KP!$CZ0`:"6+``R-YP`TKZL` M2"0%`1\,$"#>`8`P(11```,`````$```V``````0``!_`````(^J`$B/J`!$ MCZ0`:"5-``R-!P`DKZT`2"0%`1H,$"#>`4`P(1!```P`````C[@`2(^Y`$2/ MI`!H)PD`#(\G`"BOJ0!()`4!&PP0(-X#`#`A%$```P`````0``"^`````!`` M`&4`````CZX`3(^D`$25Q0``#!`>'2>F`&"/KP!,CZP`2(^D`&B'IP!@E>4` M`"6+``ROJP!(#!`A#0&`,"$40``#`````!```*H`````$```40````"/J`!, MCZT`2)4*````````I:H``(^Y`$R/J0!(AS@`!@````"E.``"CZX`3(^L`$B% MSP`"`````*V/``2/JP!,)`$``XUH``0`````%0$`)@````"/J@!,CZ0`1)5% M```,$!X=)Z8`8(^M`&@D`4U-E;D`N``````7(0`.`````(^X`$B'JP!@EPD` M`@``````"7"``:YX(8WL`-B-Z@#``6Q`)`%(B`0"((`A$```#*\1``B/J0!( MC[D`:)4M``*'KP!@``UP@`,N6"&-;`#8``````'LD"0"0(`AK3(`"!````<` M````CZ@`3(^F`$B/I`!$E04```P0'ATDQ@`(CZH`2``````E6``,K[@`2!`` M``L`````+@$`(1`@_[@``````!!H@#P!$```+0@AC"T`D``````!H``(```` M`(^Y`$PGK`!HERX`""08``$`#EE"``MX@`'L2"$QR@`?C2C_S`%8:`0!H,@G M`1E8)*TK_\R/KP!,`````"7L`!"OK`!,CZX`3#P8$``G&`_H`=@(*Q0@_B<` M````CZH`:```,"&%1``$C44`#`P02!@``````$"`(8^M`%P`````IZT`9(^H M`&@GI0!DA00`!`P02`@D!@`"`$"`(20!``(2`0`(`````(^Y`&@\!1``CR0` M``P0)40DI0QZ$```)P````"/JP!HCZ4`5(^F`%B%9``$#!!("`````"/J0!8 M`$"`(1()``@`````CZ\`:#P%$`"-Y```#!`E1"2E#)@0```6`````(^L`&@D M!@`$A80`!`P02`@EA0`0`$"`(20!``02`0`(`````(^N`&@\!1``C<0```P0 M)40DI0RY$```!@````"/I`!4#^`$@``````0```()`(``8^D`%0/X`2````` M`!````,``!`A$````0````"/OP`DC[``&(^Q`!R/L@`@`^``"">]`&@GO?_@ MK[\`%*^D`""OI0`DKZ8`**^G`"R7K@`FCZ\`*`````"E[@``C[D`*"08``6G M.``"CZD`*"0(``&M*``$QZ0`+,>)@!C'B(`<1@`AH48H,H)$2O@`1$KX```` M```U00`#."$``D3!^```````1B!4)$0+@`!$RO@`KZL`&``````D#"<0KZP` M'(^D`""/I0`H#!`AFB>F`!@0```#`````!````$`````C[\`%">]`"`#X``( M`````">]_]"OL``8K[\`'*^D`#"OI0`TKZ8`.`#`@"&OIP`\CZX`,`````"5 MSP`F`````*^O`""7N``V`````*88```D&0`#IAD``H^H`"``````K@@`!(^I M`"``````*2$``Q`@`"4`````CZH`,"0!34V52P"X`````!5A`!``````AZP` M/@``````#&P`K@T`"(^N`"`D`0`"%<$`!@````"'N``^C@\`"#,9__\!^4`E MK@@`"!````X`````AZD`/@`````Q*O__K@H`"(^K`"`D`0`"%6$`!@````"' MK0`^C@P`"``-=``!CL`EKA@`"!```!\D`@`!KZ``)(^O`"2/N0`@``````'Y M""H0(``0`````(^I`"2'J``^``E00`.J6"&E:``HCZT`)``````EK``!KZP` M)(^N`"2/N``@``````'8""H4(/_R`````(^D`#`"`"@A#!`AFB>F`"@0```# M`````!````$`````C[\`'(^P`!@#X``()[T`,">]_^BOOP`4KZ0`&*^E`!RO MI@`@KZ<`))>N`!Z/KP`@`````*7N``"/N0`@)!@`!*]`!@#X``(`````">]_]"OOP`]_\BOL``8K[\`)*^D`#BOL@`@`("`(:^Q`!R&!``$ M```H(0P02!@D!@`"`$"((28N``$D`?_^`<%X)*X/``R.&`"\`````!<``!D` M````CAD`#`````"N&0"\A@0`!```*"$,$$@8```P(0!`B"&&!``$)@4`N`P0 M2`@D!@`(`$"((20!``@2(0`'`````(X$```\!1``#!`E1"2E$B00``!0```0 M(1```$XD`@`!C@@`O`````"OJ``PA@0`!(^E`#`,$$@8```P(8^I`#``0(@A M%BD`"0````"&!``$)Z4`-`P02!`D!@`"`$"0(20!``(200`(`````#P$$``\ M!1``)*424`P0)40DA!'H$```-```$"&'I0`TA@0`!`"@""$``2B``*$H(P`% M*(`,$$@8)`8``88$``0GI0`P#!!($"0&``0`0(@A)`$`!!(A``@`````/`00 M`#P%$``DI1*"#!`E1"2$$>@0```=```0(8^J`#``````%4#_SP````"&!``$ M)`7__`P02!@D!@`!`$"((88$``0F!0`,#!!(""0&``0`0(@A)`$`!!(A``@` M````/`00`#P%$``DI1*I#!`E1"2$$>@0```%```0(1````,D`@`!$````0`` M``"/OP`DC[``&(^Q`!R/L@`@`^``"">]`#@GO?_(K[``&*^_`"2OI``XKZ4` M/*^R`"``@(`AK[$`'(X.`+P`````KZX`,(^O`#P``````>"((27X__\:(``_ MK[@`/(^Y`#``````$R``.P````"&!``$CZ4`,`P02!@``#`ACZ@`,`!`B"$6 M*``)`````(8$``0GI0`T#!!($"0&``(`0)`A)`$``A)!``D`````/`00`#P% M$`".!@``)*43)`P0)40DA!,0$```+```$"&'I0`TA@0`!`"@""$``2B``*$H M(P`%*(`,$$@8)`8``88$``0GI0`P#!!($"0&``0`0(@A)`$`!!(A``D````` M/`00`#P%$`".!@``)*431PP0)40DA!,0$```%```$"&/J0`\``````$@B"$E M*O__&B``!:^J`#R/JP`P`````!5@_\<`````CZP`,`````"N#``0#!`1``(` M("$0```#`````!````$`````C[\`)(^P`!B/L0`]_]BOL``4K[\`'*^D`"BOI0`LKZ8`,*^G`#0`@(`AK[$`&(8.``8D M`0`!%<$`!P````".!```/`40``P0)40DI1:0$```'R0"__^/I0`PCZ8`-`P0 M(S("`"`AKZ(`)(^O`"0`````$>``"P````".&`$`CZ4`+(X&`1P#`/@)`@`@ M(:^B`"2.&0#P`````"]_]BO ML``4K[\`'*^D`"BOI0`LKZ8`,`"`@"&OL0`8)A$`%(^N`"R6+P`$``````'/ M""L4(``)`````(X$```\!1``CZ8`+)8G``0,$"5$)*46JA```&P``!`AEC@` M+B0!``(7`0`A`````(^Y`#"6*``2``````,H""L4(``)`````(X$```\!1`` MCZ8`,)8G`!(,$"5$)*46QQ```%H``!`ACZD`,(XJ`)2/K``L`2H`&8XM`!@` M````%:```@``````!P`-``!8$@```````````8T`&P``]_]BO MOP`!*OKP`T`````(^D`"B/I0`L#!`DF``````00``,`````(^Y`"B/I0`PCS@! M`(^F`#0#`/@)`R`@(1!```0`````C[``-!````(`````)!#__Q````,"`!`A M$````0````"/OP` M)`+__X^N`"2/N``LC<\`H``8R(`!^4`AC0H```````"OJ@`@CZD`((^K`#0` M`````6D(*Q`@``0`````CZP`-`````"OK``@/`T0`"6M%UB/I``HCZ4`+(^F M`#"/IP`@#!`D6*^M`!`0```#`````!````$`````C[\`'">]`"@#X``(```` M`">]_]"OOP`DKZ0`,*^E`#2OI@`XKZ<`/*^P`""/K@`PC[@`-(W/`+``&,B` M`?E`(8T%``"%Q``$#!!(&```,"&/J0`PCZL`-(TJ`+``"V"``4QH(8VN```` M0(`A$@X`#`````"/N``PCZ\`-(^D`$`\!1``CP8``(\'`/`DI1>E#!`E1*^O M`!`0```9)`+__X^Y`#"/I0`XCZ8`/(]`#`GO?_(K[\`)*^D`#BO MI0`\K[``((^N`#@`````)<\`%*^O`#2/N``TCZ@`/(\9`*``"$B``RE0(8U+ M````````KZL`,(^M`#B/K``PC:X!)``````!S`@K$"``,P````"/N``X)`__ M_Z\/`/2/J``X`````(T9`2``````$R``"0````"/J0`X`````(TD`2`/X`2` M`````(^J`#@`````K4`!((^K`#"/KP`X)6T#_P`-8H(`#'*`K>X!)(^X`#@` M````CP0!)`_@!((`````CZ@`.`!`@"&M$`$@C[D`.`````"/*0$@`````!4@ M``X`````CZH`.#P$$``\!1``C48``(U'`/`DI1?\#!`E1"2$%^R/JP`X```` M`*U@`200```D```0(8^M`#@\#!``)8P7[(^E`#R/IP`PC:8!(*^L`!`,$"18 M`:`@(8^N`#``0(`A$@X``P`````0```5```0(8^O`#2/J``XE?@`#H49``@` M````$QD`!@````"/J0`XCZ4`,(TD`2`,$"7!`````(^D`#B/I0`\#!`E"0`` M```0```#`````!````$`````C[\`)(^P`"`#X``()[T`.">]_]BOL``4K[\` M'*^D`"BOI0`L`("`(:^Q`!@F#@`4KZX`)(^O`"P`````K@\`](^Y`"2/N``L MCR@`E(\J`!@#"``;%0```@``````!P`-``!($````````````2H`&0``6!*N M"P#P`````(X,`2``````K@P!*(^M`"2/KP`LC:X`H``/P(`!V$`AC1D````` M``"N&0$LC@(`_``````L0@`!%$``!P````"."0#\`@`@(0$@^`D``````$"( M(0`1$"L0```#`````!````$`````C[\`'(^P`!2/L0`8`^``"">]`"@````` M)[W_X*^_`!2OI``@KZ4`)*^F`"BOIP`LCZX`(``````1P``&`````#P$$`"/ MI@`@)(0V<`_@!%0GA8!P)Z\`)"7X``%@'40```!`````(^_`!0GO0`@`^`` M"```````````)[W_^`"`*"&0K@`!`````*^N``"0KP```````*"O``&/N``` M`````*"X```0```!``````/@``@GO0`()[W_^`"`*"&0K@`#`````*^N``"0 MKP```````*"O``./N````````*"X``"0N0`"`````*^Y``"0J``!`````*"H M``*/J0```````*"I``$0```!``````/@``@GO0`()[W_\*^E`!0`H#`A`,!( M(1D@``PDQO__`(`X(9#H``$`````D.X```````"@[@`!H.@``"2$``(`P$@A M'2#_]B3&__\0```!``````/@``@GO0`0)[W_\*^D`!"OI0`4`(`P(0"@."$` MX%`A&4``$B3G__\`P$`AD0D``P````"1#@```````*$.``.A"0``D0D``@`` M``"1#P`!`````*$/``*A"0`!),8`!`#@4"$=0/_P).?__Q````$``````^`` M"">]`!`GO?_XKZ0`"*^E``P`@#`A`*`X(0#@0"$9```*).?__Y#.```\#Q`` M`>YX(9'O&&PDQ@`!H,___P#@0"$=`/_X).?__Q````$``````^``"">]``@` M`````````">]_[BOOP`]`$@````````````````GO?_@K[\`%*^D`""OI0`D MKZ8`**^G`"R/K@`@`````!'```8`````/`00`(^F`"`DA#9P#^`$5">%@(`\ M!!``/`40`"2E&;`/X`14)(0V<">O`"0E^``')`'__`,!R"2ON0``X(1````,``!`A M$````0````"/OP`] M_^"OL``8K[\`'*^D`""OI0`D`("`(:^F`"B.#@$LCZ\`*(X9`20!S\`A`S@( M*A`@``<`````#!!'8@(`("$40``#`````!```!0D`O__CZ0`)(X%`2B/I@`H M#^`$#`````"."`$HCZD`*``````!"5`AK@H!*(X+`2R/K``H``````%L:"&N M#0$L$````R0"``$0```!`````(^_`!R/L``8`^``"">]`"`GO?_8K[``&*^_ M`!ROI``HKZ4`+`"`@"&OI@`PC@X!+(^O`#```````<\(*A`@``@`````C@0` M`#P%$`".!@#P#!`E1"2E&K`0```N```0(8X$`2B/I0`LCZ8`,`_@!`P````` MAA@`"@`````S&0`0$R``%@`````F"``4KZ@`)(^I`"0`````E2H`!@`````M M00`)%"``#0`````M00`1$"``"@````"/I0`PCZ0`+``````$H0`"`*`((20A M``$``2A##!`ECP````"."P$HCZP`,``````!;&@AK@T!*(X.`2R/KP`P```` M``'/P".N&`$L$````R0"``$0```!`````(^_`!R/L``8`^``"">]`"BOI``` M`(`P(8S/`1R,S@$H`*\`&0``P!(!V,@AK-D!*(S)`1R,R`$L`*D`&0``4!(! M"E@CK,L!+!````,D`@`!$````0`````#X``(`````````````````````">] M_^BOOP`4KZ0`&(^N`!@\!1``/`80`(W$```DQALH#!`E1"2E&P`0```#```0 M(1````$`````C[\`%">]`!@#X``(`````">]_^BOOP`4KZ0`&(^N`!@\!1`` M/`80`(W$```DQAMZ#!`E1"2E&U(0```#```0(1````$`````C[\`%">]`!@# MX``(`````#P.`$$ESJ'8K(X!`#P/`$$E[YTPK(\!"`/@``@D`@`!`^``"``` M```#X``(`````">]_Z"OL``8K[\`-*^D`&"OI0!DKZ8`:*^V`#"OM``HK[4` M+*^R`""OLP`D`,"`(:^Q`!R/K@!@`````(W1`2@`````CZ\`8`````"-^`$@ MC?D!)``````#&4`AKZ@`2*^@`$P``)`A&@``]P````"/J0!D)A#__Y$T```E M*@`!KZH`9"03``$:```4`````(^K`&0`````D6P````````6C``.`````"9S M``&/K0!D)A#__R6N``&OK@!D&@``!P````"/KP!D`````)'X````````$IC_ M]`````"/N0!()B@``@$9""L4(`!$`````(^I`$PD`0`!$2$`!``````D`0`# M%2$`*P`````",E`CKZH`1(^K`&``````C6T!*(UL`2P"37`C`8YX(:UO`2R/ MI`!@#!!'8@`````40``#`````!```,XD`O__C[@`8`````"/$0$H`````(^Y M`$0``````R"H(2]`&`GO?^PK[``&*^Q`!RO MOP`TKZ0`4*^E`%2OI@!8K[8`,*^T`"BOM0`LK[(`(`#`B"$`H(`AK[,`)(^N M`%``````C=(!*`````"/KP!0`````(WU`2P`````&J``+P`````:(``M```` M`))3```F4@`!,G@`@!,```,`````)`'_``)AF"4D`0"`%F$`!``````FM?__ M$```'``````&80`1`````"09``$#,Y@C)K7__P(SB".25```)E(``0)@L"$: MP``&)G/__Z(4```F$``!`F"P(1[`__PF<___$```"@`````F^IN*R/`0`\&`!!)QBSW*R8`00\&0!!)SFVC*R9`0@\"`!!)0BX MD*R(`0P\"0!!)2FYW*R)`10#X``()`(``0/@``@``````^``"``````GO?_8 MK[\`'*^D`"BOI0`LKZ8`,*^G`#2OL``8CZX`,``````!P(`A)<___Q(``#"O MKP`PC[@`+(^H`#2/JP`XCQD`"(\*``0#*$@A`4M@(0$L`!DD`0/]``!H$@`` M`````````:$`&@``] M_\BOOP`OJP`0)*4B M&"8$#_PD!@!`#!`H]"0'`2400``5`````#P%$``D#`J'KZP`$"2E)A@F!`_\ M)`8`&PP0*/0D!P$E$$``"P`````\!1``)`T*AZ^M`!`DI2?()@0/_"0&``T, M$"CT)`]_\BOOP`DKZ0`.*^E`#ROI@!`KZ<`1*^P`""/K@`\ MCZ\`1(^Y`$"/J`!(`<_`(0,H2"$#"0`9)`$#_0``4!(```````````%!`!H` M`%@0KZL`-`````"/K``T`````"V!`_T4(``,`````(^M`#0\!!``/`40`(^F M`#R/IP!`)*4I^22$*>H,$"5$KZT`$!```!T``!`ACZ\`-(^N`#@`#\B``=E` M(8T8````````K[@`,(^I`#``````$2``#0````"-*@`(CZL`/``````52P`( M`````(TL``2/K0!``````!6-``,`````$````@$@@"$``(`A$````P(`$"$0 M```!`````(^_`"2/L``@`^``"">]`#@GO?_8K[\`%*^D`"BOI0`LKZ8`,(^D M`"R/I0`P#^`$$`````"/K@`H`````(W/`1P`````KZ\`)(^X`"@`````EQD` M%@````"ON0`8CZ@`+`````"OJ``@CZD`,`````"OJ0``````"0.`/^0[0```0YX!S'X`/\!N%`EH.H``"3G``$`",@C`3E((R4I M__@I(0`(%"``"``````D"P#_H.L``"3G``$E*?_X*2$`"!`@__H`````/`X0 M``')<"&1SBH@D.P````````!CG@EH.\``!````$``````^``"``````GO?^@ MK[\`+*^D`&"OI0!DKZ8`:*^R`"BOL``@K[$`)(^N`&``````C<\!&`````"O MKP!``"@````"/N`!@/`40`(^G`%"/!```CP8`\`P0)40DI2HL$```Z0``$"$D M$`"`C[D`8`````"/*`$HCRD!*)$1```E*@`!KRH!*(^K`$@```````M@0*^L M`$@",&@D$:``!0````"/K@!(`````#7/``&OKP!(`!"`0X^X`$P`````)P@` M`:^H`$R/J0!(`````!D@_]0`````CZH`3``````I00`,%"``%`````"/N0!( M)`$``1``$0````"/J`!`CZD`/``````!"5`F$4``!@`` M``"/I`!DCZ4`4(^F`$0,$"JJ`````(^Y`%"/JP!$``````,K8"&OK`!0KZ`` M1*^@`$BOH`!,CZT`0``````MK@`!KZX`0!```"P`````CZ\`.(^X`$2-Z``, M``````,(2"&OJ0!$KZ``2*^@`$P0```B`````(^Y`#B/J@!$CRL`#``````! M2V`AKZP`1*^@`$BOH`!,$```&`````"/K0!@CZX`.(^O`%`\!1``C:0``(VG M`/"-Q@``)*4JS0P0)42OKP`0$```(P``$"$F6/_I+P$`!1`@__$``````!C` M@#P!$```.`@AC#@!,``````#```(`````(^H`%"/J0!H``````$)""H4(/\9 M`````(^Y`%P`````KS$``(^J`%P`````K5``!(^D`&`,$"DX`````(^K`%"/ MK`!H``````%L$"80```#+$(``1````$`````C[\`+(^P`""/L0`DC[(`*`/@ M``@GO0!@)[W_V*^_`!ROI``HKZ4`+*^P`!B/K@`H`````(W/`1@`````KZ\` M)(^X`"P`````$P``"`````"/N0`D`````(\H``"/*0`$``````$)4"6O*@`` MCZL`)`````"-;``$```````,:$.M;0`$CZX`)`````"-SP`$`````!7@`"4` M````C[@`*`````"/"`$LCPD!)``````!"0@J%"``!0````"/I``H#!!'A0`` M````0(`ACZH`)(^L`"B-60``C8T!*`````"AN0``CZL`*`````"-;@$H```` M`"7/``&M;P$HC[@`*`````"/"`$L`````"4)``&O"0$LCZH`)`````"M0``` MC[D`)"0,`("O+``$$````0````"/OP``````!4@``D`````/`H0`"5**P2N"@`(/`L0`"5K M+`2N"P`,$```!P`````\#!``)8PL!*X,``@\#1``):TK!*X-``PD#@"`K@X` M!*X```"/KP`P`````(WX`/0`````%P``!`````"/I``P#!`LO@`````0```# M)`(``1````$`````C[\`'(^P`!2/L0`8`^``"">]`#`GO?_PKZ4`%*^F`!@` MH#@A`,!`(8R)````````,.X`!Q'``!:OK@`$C[@`!)$O```D&0`(`SA8(P%O M8`0QC0#_`0UP(9'*```E*0`!C[D`!``````!60@J$"```P`````0```F`4`0 M(8^J``0``````.HX(Q````(```````!0(2CA``@4(``8`````)$X```````` M`1AX(9'K````````KZL``(^L`````````4Q0(8^M`````````.TX(X^N```` M````*<$`"!`@``,`````$```!0`````E*0`!*.$`"!`@_^H`````K(D``!`` M``,!0!`A$````0`````#X``()[T`$">]_]BOOP`4KZ0`**^E`"ROI@`PCZX` M*`````"-SP$8`````*^O`"2/N``P```````8R,"ON0`0`,$"Q5 M`?@H(8^Y`!P`````%R```P`````0```R`````(^H`"2/I0`]`"@#X``(`````">] M_^"OOP`4KZ0`((^N`"``````C<\!&`````"OKP`]_^BOOP`4KZ0`&(^N`!@\!1`` MC<0```P0)40DI2V<$````P``$"$0```!`````(^_`!0GO0`8`^``"``````\ M#@!!)^ZL*R/`0@#X``()`(``0/@``@``````^``"``` M```GO?_HK[\`%*^D`!BOI0`YX(8WO+A```````H^@(3*4``\RMP`!$N``!R:U``&2&```,ID`_P,9 M0"6B"```$````R80``$`%$D`H@D``#)6``0`````D`0"`$N'_O``````D`0#`$N'_Z``````:8``&```` M`(^J`$0``````JH(*A0@_T8`````CZL`8`````"M<0$HCZP`8`````"MDP$L MCZT`1``````2K0`5`````(^N`$0``````JX(*A`@``0`````/!<0`!````,F M]RZ0/!<0`";W+IN/KP!@/`40`(WD``"-YP#PK[4`$"2E+E@,$"5$`N`P(1`` M``4``!`A$````R0"``$0```!`````(^_`#R/L``*R.`/P\#P!! M)>_.)*R/`00\&`!!)QC07*R8`0@\&0!!)SGUA*R9`10#X``()`(``0/@``@` M`````^``"``````GO?_8K[\`'*^D`"BOL``8CZX`*`````"5T``:$```%@`` M``"/N``H/`\`027OP#"O#P$`$```&`````"/J``H/!D`02J`%PD"P`!IZL`7`(S""L0(`%*`````!J``4@` M````DBP``9(N````#&H``:YX):>O`%0F,0`"A[@`5``````S&0__)RD``:>I M`%"'J`!4```````(4P,`"JP``!6L`Q```2:GJ@!8AZL`4``````!8*@A)6S_ M_QJ@`%JGK`!0DBT``"8Q``$EK@`!IZX`3(>O`%PGN`!(`?B0(8>U`%P0```3 M`````)(Y```F4O__)C$``:)9``"2*0``)E+__R8Q``&B20``DB@``"92__\F M,0`!HD@``)(J```F4O__)C$``:)*```0```,`````":K__\M80`$$"``"``` M````"UB`/`$0```K""&,*P%0``````%@``@`````AZP`3``````"C*`C)[(` M2(>M`$P``````:"H(26N__\:H``CIZX`3(>V`%P0```/`````))/``,F$``! MH@___Y)8``(F$``!HAC__Y)9``$F$``!HAG__Y))```F$``!H@G__Q````P` M````)LC__RT!``00(``(```````(0(`\`1```"@((8PH`6```````0``"``` M``"'J@!,``````%`J"$E2___'J#_WZ>K`$R'K`!0``````&`J"$EC?__'J#_ MJ*>M`%`0``#0`````(>N`%```````HZ@(X>O`%"'N`!<``````'X`!D``,@2 MI[D`4`````"'J0!0``````$@J"$E*/__&J``"Z>H`%"2*@``)C$``280``&B M"O__AZL`4``````!8*@A)6S__QZ@__>GK`!0$```M`````"2+0``)C$``:.M M`$B'K@!0``````'`J"$ES___&J``6J>O`%"2.```)C$``2<9``&GN0!,AZD` M7">H`$@!*)`AA[4`7!```!,FM?__DBH``"92__\F,0`!HDH``)(K```F4O__ M)C$``:)+``"2+```)E+__R8Q``&B3```DBT``"92__\F,0`!HDT``!````P` M````)J[__RW!``00(``(```````.<(`\`1```"X((8PN`7```````<``"``` M``"'KP!,``````*/H",GL@!(A[@`3``````#`*@A)QG__QJ@`".GN0!,A[8` M7!````\`````DDD``R80``&B"?__DD@``B80``&B"/__DDH``280``&B"O__ MDDL``"80``&B"___$```#``````FS/__+8$`!!`@``@```````Q@@#P!$``` M+`@AC"P!@``````!@``(`````(>M`$P``````:"H(26N__\>H/_?IZX`3(>O M`%```````>"H(27X__\>H/^HI[@`4!```%``````DCD``">R`$@F,0`!HED` M`(>I`%```````HF@(X>H`%```````0"H(24*__\:H``JIZH`4(>U`%P0```3 M)K7__Y(K```F,0`!)A```:(+__^2+```)C$``280``&B#/__DBT``"8Q``$F M$``!H@W__Y(N```F,0`!)A```:(.__\0```,`````":O__\MX0`$$"``"``` M````#WB`/`$0```O""&,+P&0``````'@``@`````DE@``"80``&B&/__A[D` M4``````#(*@A)RG__QZ@_]BGJ0!0$```&`````"/J`!P/`00`(T*`/`\!1`` MAZ<`6(T&```DI2\()(0N_`P0)42OJ@`0$```*P``$"$FJ___+6$`!!`@__$` M``````M8@#P!$```*P@AC"L!H``````!8``(``````(S""L0(``#`````!Z` M_KH`````CZP`<`````"-C@$HC8T!+`(N>",!K\`CK9@!+(^Y`'``````KS$! M*!J```L`````CZD`<#P$$``\!1``C28``(TG`/`DI2\M#!`E1"2$+OP0```% M```0(1````,D`@`!$````0````"/OP`\C[``((^Q`"2/L@`HC[,`+(^T`#"/ MM0`TC[8`.`/@``@GO0!P)[W_B*^P`""OOP`\KZ0`>*^E`'ROI@"`K[8`.*^T M`#"OM0`TK[(`**^S`"P`H(`AK[$`)(^N`'@`````C=(!*`````"/KP!X```` M`(WX`2P``````EB8(8^Y`'@`````ES0`%@````"/J`!X)`$``94)`$(````` M%2$`!`````"5"@`F$````Z>J`&0D"P`!IZL`9`)3""L0(`&=`````!J``9L` M````DDP``9).````#&H``:YX):>O`%PF4@`"A[@`7``````S&0__)RD``:>I M`%B'J`!<```````(4P,`"JP``!6L`Q```7FGJ@!@AZL`6``````!8*@A)6S_ M_QJ@`&JGK`!8DDT``9)/````#7(``<_`)2<9``&GN0!4)E(``H>I`&0GJ@!, M``E`0`$*B"&'M0!D$```'P````"23``!DDL````,:@`!;7`EIB[__B8Q__XF M4@`"DE@``9)/````&,H``?E():8I__XF,?_^)E(``I)*``&22`````IB``$, M6"6F*__^)C'__B92``*23@`!DDT````.P@`!N'@EIB___B8Q__XF4@`"$``` M#``````FN?__+R$`!!`@``@``````!G(@#P!$```.0@AC#D!L``````#(``( M`````(>I`%0``````HF@(R>Q`$R'J@!4``````%`J"$E2/__&J``(Z>H`%2' MM@!D$```#P````"6+``&)A```J8,__Z6*P`$)A```J8+__Z6+@`")A```J8. M__Z6+0``)A```J8-__X0```,`````";8__\O`0`$$"``"```````&,"`/`$0 M```X""&,.`'```````,```@`````AZ\`5``````!X*@A)?G__QZ@_]^GN0!4 MAZD`6``````!(*@A)2K__QZ@_YBGJ@!8$``!$P````"'J`!8``````*(H".' MK`!8``````&`J"$EB___&J``,Z>K`%B'M@!D$```'P````"230`!DDX````- MP@`!V'@EI@\``"80``(F4@`"DDD``9)9````"5(``RI`):8(```F$``")E(` M`I)+``&23`````MJ``&-<"6F#@``)A```B92``*23P`!DE@````/2@`#"<@E MIAD``"80``(F4@`"$```#``````FRO__+4$`!!`@``@```````I0@#P!$``` M*@@AC"H!T``````!0``(`````(>H`%@``````0"H(24+__\>H/_/IZL`6!`` M`-8`````DDT``9),````#7(``8YX):>O`$PF4@`"A[@`6``````#`*@A)PG_ M_QJ@`&JGJ0!8DED``9)(````&5(``4A8)25M``&GK0!4)E(``H>L`&0GKP!, M``QP0`'/B"&'M0!D$```'R:U__^220`!DE@````)R@`#&5`EIBK__B8Q__XF M4@`"DDL``9)(````"VH``0U@):8L__XF,?_^)E(``I)/``&23@````]*``') MP"6F./_^)C'__B92``*22@`!DED````*6@`#*T`EIBC__B8Q__XF4@`"$``` M#``````FK?__+:$`!!`@``@```````UH@#P!$```+0@AC"T!X``````!H``( M`````(>L`%0``````HR@(R>Q`$R'KP!4``````'@J"$E[O__&J``(Z>N`%2' MM@!D$```#P````"6*0`&)A```J8)__Z6.``$)A```J88__Z6*@`")A```J8* M__Z6.0``)A```J89__X0```,`````";+__\M80`$$"``"```````"UB`/`$0 M```K""&,*P'P``````%@``@`````AZ@`5``````!`*@A)0W__QZ@_]^GK0!4 MAZP`6``````!@*@A)8___QZ@_YBGKP!8$```7P````"220`!DDX````)P@`G ML0!,`=A0):8J```F4@`"A[D`6``````"F:`CAZL`6``````!8*@A)6C__QJ@ M`#:GJ`!8A[4`9!```!\FM?__DDP``9)-````#'H``:]():8)```F$``")E(` M`I)8``&23@```!A2``'*R"6F&0``)A```B92``*22``!DDL````(8@`!;&@E MI@T``"80``(F4@`"DDD``9)/````"<(``?AP):8.```F$``")E(``A````P` M````)JK__RU!``00(``(```````*4(`\`1```"H((8PJ`@```````4``"``` M``"6.0``)A```J89__Z'J`!8``````$`J"$E"___'J#_S*>K`%@0```8```` M`(^L`'@\!!``C8T`\#P%$`"'IP!@C88``"2E+V`DA"]4#!`E1*^M`!`0```K M```0(2:I__\M(0`$$"#_\0``````"4B`/`$0```I""&,*0(0``````$@``@` M`````E,(*Q`@``,`````'H#^9P````"/KP!X`````(WN`2B-^`$L`DY0(P,* MR".M^0$LCZ@`>`````"M$@$H&H``"P````"/JP!X/`00`#P%$`"-9@``C6<` M\"2E+X4,$"5$)(0O5!````4``!`A$````R0"``$0```!`````(^_`#R/L``@ MC[$`)(^R`"B/LP`LC[0`,(^U`#2/M@`X`^``"">]`'@GO?_(K[``%*^_`"2O MI``XK[,`(*^R`!P`@(`AK[$`&(X.`1@`````$<```P`````0``!Z)`(``98/ M`!HD`0`($>$`#0````"6&``:)`$`$!,!``D`````/`00`#P%$`"6!@`:)*4O MM0P0)40DA"^I$```:@``$"$/X`2")`0`1`!`D"&N$@$8CAD!&``````7(``( M`````#P$$``\!1``)*4OWPP0)40DA"_3$```6P``$"&.!`$8#^`$$"0%`$2. M$0$8`````)8(`$(D`0`!%0$`'`````"6"0`F`````*XI`!26$@`F`````"I! M``04(``#KC(`&"0*``.N*@`8E@L`7``````18``)`````)83`"8`````)G/_ M_P`3G```$YP#IC,`#!````0"8)`A)`P``Z8L``PD$@`#$```!@`````D#0`! M)`X``:XN`!2N+0`8IB``#)8/`!H`````+>$`"1`@``0`````)!@``1````JO MN``PEAD`&@`````O(0`1$"```P`````0```")!(``B02``2OL@`PCB@`%(^I M`#```````0D`&0``4!*N*@`4`````(XK`!B/K``P``````%L`!D``&@2KBT` M&`````".#@$@C@\!)(XY`!0!S\`A`QE`(R4)__VN*0```````"#\`AK[@` M1(^Y`'``````CS$!*`````"/J`!P)`$``94)`$(`````%2$`#0````"/J@!P M`````)5+`"8`````KZL`7(^L`'``````E8T`7`````"OK0!8$```!``````D M#@`!KZX`7*^@`%@F3P`TKX^`["98`#ROF(#H)ED`)*^9@.0F2``LKXB`X(9* M``R/B8#L``I80`$K8"&E@```AD\`#(^.@.@`#\!`-`W__P'8R"&G+0``)`C_ M_:^H`&"/J@!$``````(*""L0(`55`````(^)@.P`````KZD`0(^+@.@````` MKXN`[(^L`$``````KXR`Z(^/@.0`````KZ\`/(^.@.``````KXZ`Y(^X`#P` M````KYB`X"0-``FOK0!DCYF`Z`````"ON0!4CXB`[`````"OJ`!0CXJ`X``` M``"OJ@!(CZD`<"0!``B5*P`:`````!5A`'<`````C[,`7!```&<`````D@P` M`(^O`%0F$``!I>P``(^N`%"/K0!4E=,``"78``*ON`!0E;D````````2>0`" M`````*^@`&2/J`!4CZD`2)4*````````H2H``(^O`$B/JP!4)>X``25L``*O MK`!4KZX`2)(8``"/K0!4)A```:6X``"/N0!0CZH`5)X``J^N`%2O MK0!(C[D`3(^J`%27*````````*5(``"/J0!,`````"4K``*OJP!,CZP`4(^N M`%25DP``)8\``J^O`%"5V````````!)X``(`````KZ``9(^M`%2/J`!(E;D` M``````"A&0``CZH`2``````E20`!KZD`2(^K`%2/K@!(E6P`````````#'H" MH<\``(^Y`$B/N`!4)R@``2<-``*OK0!4KZ@`2(^J`$R/JP!4E4D```````"E M:0``CZP`3``````ECP`"KZ\`3(^N`%"/K0!4E=,``"78``*ON`!0E;D````` M```2>0`"`````*^@`&2/J`!4CZD`2)4*````````H2H``(^K`$@`````)6P` M`:^L`$B/KP!4CZT`2)7N``````````["`J&X``"/J@!(C[D`5"5)``$G*``" MKZ@`5*^I`$B/JP!,CZ\`5)5L````````I>P``(^N`$P`````)=@``J^X`$R/ MK0!0CZ@`5)6S```EN0`"K[D`4)4*````````$FH``@````"OH`!DCZD`5(^L M`$B5*P```````*&+``"/KP!(`````"7N``&OK@!(C[@`5(^H`$B7#0`````` M```-R@*A&0``CZL`2(^J`%0E;``!)4D``J^I`%2OK`!($```#``````F;___ M+>$`!!`@``@```````]X@#P!$```+P@AC"\",``````!X``(`````(^P`$P` M````AE@`#(9)``R/CH#LCXJ`Z``8:$``"5A``@``998``@` M````$P```P`````0``/3``````)`H"&6DP`(`````"9S__\R<___II,`"(Y. M``0`````H=,``)9-``B.20`$``W*`J$Y``$0```1`````(Y4``0`````DI,` M```````FPD`O__$```;@````"&2``* M`````"4/``&F3P`*KE$`!"08``&B.```)C$``8^Y`'`D`0`0ERT`&@`````5 MH0`%`````"0)``&F20`(HB```"8Q``&/BX#@`````*^K`$B.4P`4$```2P`` M``"/K@!()C$``9',````````HBS__X^J`$@`````)4@``:^H`$B/KP!()C$` M`9'X````````HCC__X^Y`$@`````)RT``:^M`$B/J0!()C$``9$K```````` MHBO__X^N`$@`````)"&MSP$LCZ0`<`P01V(` M````%$```P`````0``4E)`+__X^Y`'`D&``!K[@`8(\E`2@D!@`!#!`\%`,@ M("$`0(@A%B```P`````0``49)`+__Q```&``````ADT`"@`````EJ0`!IDD` M"H^+@.0`````KZL`2(Y3`!00``!+`````(^J`$@F,0`!D4P```````"B+/__ MCZ@`2``````E#P`!KZ\`2(^N`$@F,0`!D=@```````"B./__C[D`2``````G M+0`!KZT`2(^I`$@F,0`!D2L```````"B*___CZH`2``````E3``!KZP`2(^H M`$@F,0`!D0\```````"B+___CZX`2``````EV``!K[@`2(^Y`$@F,0`!DRT` M``````"B+?__CZD`2``````E*P`!KZL`2(^J`$@F,0`!D4P```````"B+/__ MCZ@`2``````E#P`!KZ\`2(^N`$@F,0`!D=@```````"B./__C[D`2``````G M+0`!KZT`2(^I`$@F,0`!D2L```````"B*___CZH`2``````E3``!KZP`2!`` M``P`````)FC__RT!``@0(``(```````(0(`\`1```"@((8PH`F```````0`` M"``````0``)6`````(^O`'`D`0`0E>X`&@`````5P0`C``````)`H"&6DP`( M`````"9S``$R<___II,`"(Y8``0`````HQ,``)99``B.20`$`!EJ`J$M``&6 M2P`(`````!%@``,`````$``"/0`````"0*`AEI,`"``````F<___,G/__Z:3 M``B.2@`$`````*%3``"63``(CD\`!``,0@*AZ``!$```$0````".5``$```` M`)*3````````)G,``3)S`/\28``#HI,``!```B0`````CDX`!`````"1V``` M`````"<9__^AV0``)`W__*^M`&`0``(:``````P0/4X"0"`A)`G__Z^I`&`0 M``(4`````(Y+`"```````7$(*Q`@`"(`````CZH`<`````"-1`$8#!`]3@`` M``"/K`!P`````(V/`2B-B`$L`B_`(P$8R"&MF0$LCZ0`<`P01V(`````%$`` M`P`````0``1<)`+__X^M`'`D#@`$KZX`8(VE`2@D!@`$#!`\%`&@("$`0(@A M%B```P`````0``10)`+__Q```&X`````ADD`"@`````E*P`!IDL`"JY1``0D M"@`!HBH``"8Q``&/KP!P)`$`$)7H`!H`````%0$`!0`````D&``!IE@`"*(@ M```F,0`!CYF`X`````"ON0!(CE,`&!```$L`````CZP`2"8Q``&1C@`````` M`*(N__^/K0!(`````"6I``&OJ0!(CZL`2"8Q``&1:@```````*(J__^/KP!( M`````"7H``&OJ`!(C[@`2"8Q``&3&0```````*(Y__^/K`!(`````"6.``&O MK@!(CZT`2"8Q``&1J0```````*(I__^/JP!(`````"5J``&OJ@!(CZ\`2"8Q M``&1Z````````*(H__^/N`!(`````"<9``&ON0!(CZP`2"8Q``&1C@`````` M`*(N__^/K0!(`````"6I``&OJ0!(CZL`2"8Q``&1:@```````*(J__^/KP!( M`````"7H``&OJ`!(C[@`2"8Q``&3&0```````*(Y__^/K`!(`````"6.``&O MK@!($```#``````F;?__+:$`"!`@``@```````UH@#P!$```+0@AC"T"@``` M```!H``(`````"0)``2OJ0!@$``!?0`````,$#U.`D`@(20+``./I`!PKZL` M8`(@*"$,$#P4)`8``P!`B"$6(``#`````!```]`D`O__$``!;@`````,$#U. M`D`@(20*``&/I`!PKZH`8`(@*"$,$#P4)`8``0!`B"$6(``#`````!```\$D M`O__$``!7P`````,$#U.`D`@(20/``2/I`!PKZ\`8`(@*"$,$#P4)`8`!`!` MB"$6(``#`````!```[(D`O__$``!4`````".2``@``````$1""L0(``B```` M`(^X`'``````CP0!&`P0/4X`````C[D`<`````"/+@$HCRP!+`(N:",!C4@A MKRD!+(^D`'`,$$=B`````!1```,`````$``#F"0"__^/J@!P)`L``Z^K`&"- M10$H)`8``PP0/!0!0"`A`$"((18@``,`````$``#C"0"__\0``!@`````(9/ M``H`````)>@``:9(``J/F(#D`````*^X`$B.4P`8$```2P````"/K@!()C$` M`9',````````HBS__X^M`$@`````):D``:^I`$B/N0!()C$``9,K```````` MHBO__X^J`$@`````)4\``:^O`$B/J`!()C$``9$8````````HCC__X^N`$@` M````)H``:^J`$B/J`!()C$``9$8````````HCC__X^K`$@`````)6X``:^N M`$B/K`!()C$``9&-````````HBW__X^I`$@`````)3D``:^Y`$B/KP!()C$` M`9'J````````HBK__X^H`$@`````)1@``:^X`$B/JP!()C$``9%N```````` MHB[__X^L`$@`````)8T``:^M`$B/J0!()C$``9$Y````````HCG__X^O`$@` M````)>H``:^J`$@0```,`````"9H__\M`0`($"``"```````"$"`/`$0```H M""&,*`+```````$```@`````#!`]3@)`("$D&/__K[@`8!```#X`````)`O_ M_Z^K`&`0```Z`````(^N`%@`````$<``!``````D#``$$````Z^L`&`D#0`" MKZT`8(^D`'"/I@!@#!`\%`(@*"$`0(@A%B```P`````0``*()`+__Q```"8` M````)`D``X^D`'"OJ0!@`B`H(0P0/!0D!@`#`$"((18@``,`````$``">R0" M__\0```9`````"09``&/I`!PK[D`8`(@*"$,$#P4)`8``0!`B"$6(``#```` M`!```FXD`O__$```#``````FCP`$+>$`-A`@``@```````]X@#P!$```+P@A MC"\"X``````!X``(`````(^J`$0``````@H(*Q0@^JT`````C[,`8!```CX` M````$``"1P````".2``<``````$1""L0(``A`````(^X`'``````CP0!&`P0 M/4X`````CZL`<`````"-;`$HC6X!+`(L:",!S4@AK6D!+(^D`'`,$$=B```` M`!1```,`````$``"/R0"__^/N0!PKZ``8(\E`2@``#`A#!`\%`,@("$`0(@A M%B```P`````0``(T)`+__Q```&H`````AD\`"@`````EZ@`!IDH`"J(@```F M,0`!CZ@`<"0!`!"5&``:`````!H!+`(HP",!6&`AK>P!+(^D`'`,$$=B`````!1```,````` M$``!KR0"__^/K@!PKZ``8(W%`2@``#`A#!`\%`'`("$`0(@A%B```P`````0 M``&D)`+__Q```&``````ADT`"@`````EJ0`!IDD`"H^+@.``````KZL`2(Y3 M`!00``!+`````(^Y`$@F,0`!DR@```````"B*/__CZH`2``````E6``!K[@` M2(^L`$@F,0`!D8\```````"B+___CZX`2``````ES0`!KZT`2(^I`$@F,0`! MD2L```````"B*___C[D`2``````G*``!KZ@`2(^J`$@F,0`!D5@```````"B M./__CZP`2``````ECP`!KZ\`2(^N`$@F,0`!DT!*(WN`2P"+4@C`)`+__Q````P````` M)FP`!"V!``D0(``(```````,8(`\`1```"P((8PL!#@``````8``"``````, M$#U.`D`@(8^M`'``````C:X!*(VH`2P"+D@C`0E8(:VK`2R/KP!P`````*WQ M`2@0```#)`(``1````$`````C[\`+(^P`!B/L0`]`'`GO?_(K[``%*^_`"2OI``XKZ4`/*^F`$"OLP`@K[(`'`"@@"&OL0`8 MCZX`.`````"-T0$8`````(XO`!P``````?`(*Q`@`!,`````C[@`.`````"/ M"`$HCQD!+`((2",#*5`AKPH!+(^D`#@,$$=B`````!1```,`````$``!$P`` M$"&/JP`X`````(UP`2@`````AZP`0@````"N+``0IB``"JXP```F$``"A[,` M0A```/@`````)`T``:XM`!"/DH#@`````(XS`!00```C`````)).```F4@`! M)A```:(.__^23P``)E(``280``&B#___DD@``"92``$F$``!H@C__Y)9```F M4@`!)A```:(9__^220``)E(``280``&B"?__DDH``"92``$F$``!H@K__Y)8 M```F4@`!)A```:(8__^22P``)E(``280``&B"___$```#``````F;/__+8$` M"!`@``@```````Q@@#P!$```+`@AC"P$7``````!@``(`````!```,P````` MAZT`0B0!``(5H0`/`````*XP``0D#@`!H@X``"80``&/KP`X)`$`$)7H`!H` M````%0$`!0`````D&0`!ICD`"*(````F$``!CY*`Y`````".,P`4$```(P`` M``"220``)E(``280``&B"?__DDH``"92``$F$``!H@K__Y)8```F4@`!)A`` M`:(8__^22P``)E(``280``&B"___DDP``"92``$F$``!H@S__Y)-```F4@`! M)A```:(-__^23@``)E(``280``&B#O__DD\``"92``$F$``!H@___Q````P` M````)FC__RT!``@0(``(```````(0(`\`1```"@((8PH!'P``````0``"``` M```0``"&`````(^9@.2.*0`8``````,ID"&.*@`4CC@`&!```",!6)@CDDL` M`"92``$F$``!H@O__Y),```F4@`!)A```:(,__^230``)E(``280``&B#?__ MDDX``"92``$F$``!H@[__Y)/```F4@`!)A```:(/__^22```)E(``280``&B M"/__DED``"92``$F$``!HAG__Y))```F4@`!)A```:()__\0```,`````"9J M__\M00`($"``"```````"E"`/`$0```J""&,*@2<``````%```@`````A[@` M0B0!``07`0`/`````*XP``0D"P`!H@L``"80``&/K``X)`$`$)6-`!H````` M%:$`!0`````D#@`!IBX`"*(````F$``!CY*`Y`````".,P`8$```(P````"2 M3P``)E(``280``&B#___DD@``"92``$F$``!H@C__Y)9```F4@`!)A```:(9 M__^220``)E(``280``&B"?__DDH``"92``$F$``!H@K__Y)8```F4@`!)A`` M`:(8__^22P``)E(``280``&B"___DDP``"92``$F$``!H@S__Q````P````` M)FW__RVA``@0(``(```````-:(`\`1```"T((8PM!+P``````:``"``````0 M```+`````"YA``40(``(```````3<(`\`1```"X((8PN!-P``````<``"``` M```0```#`@`0(1````$`````C[\`)(^P`!2/L0`8C[(`'(^S`"`#X``()[T` M.*^D````@"@AC*\`$(2N``H`#\,``=C():2Y``J$J``*C*H````(2@.A20`! MA*L`"HRL````````H8L``!````$``````^``"``````GO?_HK[\`%*^D`!B/ MK@`8`````(W/`1@`````$>``"0````"/N``8`````(\$`1@/X`2``````(^Y M`!@`````KR`!&!````,D`@`!$````0````"/OP`4)[T`&`/@``@````````` M```````\#@!!)<[V:*R.`0`\#P!!)>_V(*R/`0@#X``()`(``0/@``@````` M`^``"``````GO?_HK[\`%*^D`!BOI0`#_H/_WKZT` M1(^L`&``````C9(!*``````0```3`````(^N`&``````C`/\"```` M`(^J`$PD`0`!$4$`!``````D`0`#%4$`!0````"230```````#6L`("B3``` MCZL`8`````"->`$HC6\!+`(XR",!^7`AK6X!+(^H`&``````K1$!*!````,D M`@`!$````0````"/OP`TC[``&(^Q`!R/L@`@C[,`)(^T`"B/M0`LC[8`,`/@ M``@GO0!@)[W_J*^P`!2OOP`TKZ0`6*^E`%ROI@!@K[<`,*^V`"ROM0`HK[0` M)*^S`""OL@`<`,"`(:^Q`!B/K@!8`````(W3`2P`````CZ\`6`````"5^``: M`````"\!``D0(``V`````(^Y`%@`````CS0!*`````"/M0!<`````!I@`"D` M````&@``)P````"2D@``)I0``29S__\D`?]_`D&()!8@``,`````$```&@`` M```R2`"`$0``"P`````"@"`A`J`H(0_@!`P"(#`A`K&H(0(1@","D:`A`G&8 M(Q````T`````DI(``":4``$F<___`A&`(P(@L"$:P``&)C'__Z*R```FM0`! M`B"P(1[`__PF,?__&F```P`````>`/_;`````(^I`%@`````K30!*!```$$` M````CZH`6`````"-5P$H`````(^K`%P`````KZL`.!I@`#4`````&@``,P`` M``"6\@``)O<``B9S__\D`?]_`D&()!8@``,`````$```)@`````R3`"`$8`` M$0````"/I0`X`N`@(0_@!`P`$3!`CZT`.``1<(`!KG@AKZ\`.``1P$`"&(`C M`!'(@`+YN"$`$4!``FB8(Q```!,`````EO(``";W``(F<___`!%(0`()@"," M(+`A&L``"R8Q__^/J@`X`````*52``"/JP`X`````"5L``*OK``X`B"P(1[` M__`/_/`````(^M`%@`````K;8`\`P0)40DI3",$```!0``$"$0```# M)`(``1````$`````C[\`-(^P`!2/L0`8C[(`'(^S`""/M``DC[4`*(^V`"R/ MMP`P`^``"">]`%@\#@!!)\#(*R/`0`\&`!!)Q@'B*R8 M`00\&0!!)SD(B*R9`0@\"`!!)0@+!*R(`0P\"0!!)2D/W*R)`10#X``()`(` M`0/@``@``````^``"``````GO?_(K[\`)*^D`#BOL@`@K[``&*^Q`!R/K@`X M`````(W0`1@`````%@``%P`````/X`2")`1U;(^O`#@`0)`AK?(!&(^X`#@` M````CQD!&``````7(``(`````#P$$``\!1``)*4Q`0P0)40DA##T$```*0`` M$"&/J``X`````(T0`1@`````I@``!"0)``FF"0`&)`H!_ZX*``@D$0#_!B`` M!@`````"$5@AH7$G+B8Q__\&(?_\`````"0,`0*N#``4K@``#(^M`#@````` MC:X!)`````"N#@`0C@\`$```````#\#`)QG_]:X9`!`F"#X(*A`@``,````` M$```3B0"`0&,N``4C+D`"``````#.`@J$"``$0````"4J@`&`````"5+``&D MJP`&E*P`!@`````M@0`-%"```P`````D#0`,I*T`!I2N``8D#P`!`<_`!"<9 M__^LN0`(E*H`!``````Q2P`!$6``"0`````D#``))`T!_ZRM``BDK``&E*\` M!``````Q[O_^I*X`!(RH``P`````E*<`!@````",F`$@``C(PP,92"$Q"``' MD2H``"4I``$!"C`&``A8(P#K.",DY__X)`P`"`&(0",HX0`(%"``!P````"1 M+0``)2D``0$->`0`SS`E)0@`""3G__@\&!```P?`(9,8,.B1+@````````'8 MR"0!&5`$`,HP)8RK``R4K``&``````%L:"&LK0`,$````P#`$"$0```!```` M``/@``@GO0`8)[W_V*^_`!ROI``HK[$`&*^P`!2/K@`H`````(W0`1@````` M%@``%P`````/X`2")`1U;(^O`"@`0(@AK?$!&(^X`"@`````CQD!&``````7 M(``(`````#P$$``\!1``)*4Q5@P0)40DA#%)$```'P``$"&/J``H`````(T0 M`1@`````I@``!*X``!PD"2<0K@D`&"0*``DD"P'_K@L`"*8*``8D#`$"K@P` M%*X```R/K0`H`````(VN`20```````YXP"7X__6N&``0#!!#TP(`("$D&?__ MKAD``!````,D`@`!$````0````"/OP`]_[BO MOP`LKZ0`2*^E`$ROI@!0K[4`**^T`"2OLP`@K[(`'*^Q`!BOL``4CZX`2``` M``"-T`$8`````!8```,`````$```A```$"&.%````````"0!__\6@0`5```` M`(^O`%``````&>``$0````"/I`!(#!!"WR0%`0"/N`!,`````),4```G&0`! MK[D`3(^H`%``````)0G__Z^I`%"."@`@`````"5+``&N"P`@CZP`4``````9 M@`!B`````(^M`$P`````D;,``"6N``&OK@!,CZ\`4``````E^/__K[@`4(X9 M`"``````)R@``:X(`"``$TL``32((0`340`!5)`F`!)8@`(+8"&-C0`H```` M`!6Q``<``````!)P0`(.>"&%]$Y4`````!```$$``````!+`@`(8R"&/*``H M``````4``!P`````)`D3BP$RJ",60``"`````"05``$"59`C!D$``@`````F M4A.+`!)0@`(*6"&-;``H`````!61``<``````!)H0`(-<"&%U$Y4`````!`` M`"8``````!)X@`(/P"&/&0`H``````]_^"OOP`4KZ0`((^N`"``````C<\!&`````"OKP`]`"`#X``(`````">]_[BOOP`LKZ0`2*^E M`$ROM0`HK[0`)*^S`""OL@`"$##P@J$"``)``````R.0`' M$R``%0````"/J0!(`!%`PZTH`2R/J@!(`````(U+`2"-3`$L``````%LH"&/ MI`!(#!!'A0``````0*@ACZX`2)*-``"-SP$@`````*'M```0```%`````(^D M`$@,$$>%``````!`J"&/N`!(`````(\4`2``````,C$`!ZX1``P0```'```` M`(^Y`$@`$4C#CR@!(``````!":`A,C$`!SP+$``\#1```;%H(0%Q6"&1:S#H MD:TPW)**```",W`$`]`"@GO?_P)(5.5"0'__\D!A-[K*?_P*RG_\2LI__( MK*?_S*RG_]"LI__4K*?_V*RG_]RLI__@K*?_Y*RG_^BLI__LK*?_\*RG__2L MI__XK*?__"2E_\`DQO_P!,'_[0`````DQ@`0&,``!@`````DI?_\K*<``"3& M__\

]`!`GO?_HK[\`%*^D`!B/K@`8```` M`(W/`1@`````$>``"0````"/N``8`````(\$`1@/X`2``````(^Y`!@````` MKR`!&!````$`````C[\`%">]`!@#X``(````````````````)[W_T*^P`!2O MOP```#0`````\!1``)*4Q MH`P01DH"`"`A%$```P`````0``#?)`+__X88``H`````-QD`!*89``HF$0`4 MCZ@`.)8I``0``````0D(*Q0@`!$`````EBH`+B0!``(500`'`````(X$```\ M!1``#!`E1"2E,;00``#*)`+__X^K`#@`````)6P``:8L``0D#0`!KZT`()8N M`"XD`0`"%<$`(0````"/KP`\EC@`$@`````!^`@K%"``"0````".!```/`40 M`(^F`#R6)P`2#!`E1"2E,>P0``"R)`+__X^Y`#R.*`"4CZH`.`,H`!F.*P`8 M`````!5@``(```````<`#0``2!(```````````%+`!L``&`2`2QH(:^M`"@0 M```+`````(^N`#B.+P`8``````'/`!L5X``"```````'``T``,`2K[@`*``` M``"/N0`HC@@`]``````3*``^`````(X*`2P`````&4``!P`````,$$=B`@`@ M(11```,`````$```AR0"__^/JP`H`````*X+`/2/J0`HCBP`E``````!+`@K M%"``$0````"/K0`@`````!&@``T`````EBX`!(XO`!B.*``8`<_`(2<9__\# M*``;%0```@``````!P`-``!0$JXJ`)0`````CZL`*(XI`)2.+0`8`6D`&Q4@ M``(```````<`#0``8!````````````&-`!D``'`2K@X`\`````".#P$$```` M`!'@``D`````CA@!!`(`("$#`/@)`````!1```,`````$```5"0"__^/N0`H MCB@`F``````#*`@K%"``"@`````\!A``),8QH`(`("$,$$:`)`4``11```,` M````$```120"__^/J@`XC@L`\``````12P`Q`````(X)`1``````$2``)P`` M``"/K``XC@T`\``````!C0@K$"``$@````"/K@`HCB\`E(XY`!@!SP`;%>`` M`@``````!P`-``#`$````````````QD`&0``0!*N"`#P`````(X*`2`````` MK@H!*(^K`#B."0#PC@P!$`(`("$!@/@)`6DH(Q1```,`````$```&R0"__^/ MK0`X`````*X-`/`0```'`````(X$```\!1``#!`E1"2E,@P0```0)`+__XX. M`0B/I0`TC@8!'`'`^`D"`"`AKZ(`)(X/`/``````)?@``:X8`/"/H@`D$``` M`P`````0```!`````(^_`!R/L``4C[$`&`/@``@GO0`P)[W_V*^P`""OOP`D MKZ0`**^E`"ROI@`P`("`(:^G`#0\!1``)*4R1`P01;4"`"`A%$```P`````0 M``!:)`+__X^N`"R.#P"L``````'/""L4(``,`````(X8`*P\!!``/`40`(X& M``"/IP`L)*4R7"2$,D0,$"5$K[@`$!```$DD`O__AAD`"@`````S*``$%0`` M#0`````\!1``)*4R1`P01DH"`"`A%$```P`````0```\)`+__X8)``H````` M-2H`!*8*``J/JP`L`````*X+`/2.#`$,`````!&```D`````C@T!#`(`("$! MH/@)`````!1```,`````$```*0``$"&.#@$(CZ4`,(^F`#0!P/@)`@`@(11` M``,`````$```(```$"&6#P`BAA@`"``````1^``%`````(X$`2".!0$L#!`E MP0````".&0$L`````!L@``H`````CZ4`+(X&`2".!P$L#!!&WP(`("$40``# M`````!````HD`O__K@`!+(X(`2``````K@@!*(^B`#00```#`````!````$` M````C[\`)(^P`"`#X``()[T`*">]_]"OOP`DKZ0`,*^E`#2OI@`XKZ<`/*^P M`""/I``P/`40``P01;4DI3*`%$```P`````0```D)`+__X^O`#"/K@`TC?@` MK``````!V`@K%"``#0````"/N0`P/`00`(\H`*P\!1``CZ<`-(\F```DI3*4 M)(0R@`P0)42OJ``0$```$20"__^/I``PCZ4`-(^F`#B/IP`\#!!&WP`````0 M0``#`````!````,D$/__C[``/``````0```#`@`0(1````$`````C[\`)(^P M`"`#X``()[T`,">]_\BOL``4K[\`)*^D`#BOI0`\K[,`(*^R`!P`@(`AK[$` M&(8.``8`````%<``"`````"/I``\/`40`(X&```,$"5$)*4RMA```'L``!`A MA@\`"@`````Q^``(%P``<@````".&0"@`````#,H``$5```(`````(^D`#P\ M!1``C@8```P0)40DI3+4$```:@``$"&."0"@/`$`"`$A4"050``(`````(^D M`#P\!1``C@8```P0)40DI3,"$```7@``$"&."P"P`````!5@`%(`````)A$` M%(XL`!@D`?__$8$`!0````"6+0`$`````!6@``4`````)`X``:XN`)00```- M)!(``98O``2..``8CBD`&`'XR"$G*/__`0D`&Q4@``(```````<`#0``F!*N M,P"4`F"0(8XJ`)0`````KBH`F)8K`"XD`0`"%6$`"`````".+`"8EBT`$@`` M```!C0`9``!P$JXN`)@`````CB0`F`_@!((`!""``$"0(:XR`)R.)`"8#^`$ M@@`$((``0)`AKC(`H(XO`)P`````$>``!0````"..`"@`````!<```D````` MKB``F(^D`#P\!1``C@8```P0)40DI3,Y$```&0``$"&.)0"8CB0`G`_@!!`` M!2B`CB4`F(XD`*`/X`00``4H@(X9`*`\`8```R%`):X(`*"."0"@/`$@``$A M4"6N"@"@A@L`"@`````U;``(I@P`"A````,D`@`!$````0````"/OP`DC[`` M%(^Q`!B/L@`]`"@GO?_8K[\`'*^D`"BO MI0`LKZ8`,*^G`#2OL``8CZX`*``````ESP`4KZ\`)(^X`"2/J``LCQD`G``( M2(`#*5`AC4L````````18``'`````(^L`"@`````C8T`^``````5H``^```` M`(^N`"2/N``LC<\`G``80(`!Z,@ACRD````````1(``@`````(^K`"2/K0`L MC6P`G(^J`"@`#7"``8[`(8\%``"%1``$#!!(&```,"&/KP`DC[D`+(WH`)P` M&4B``0E0(8U+````0(`A$@L`"P````"/K0`H/`00`#P%$`"-I@``C:<`\"2E M,^@,$"5$)(0SU!```$```!`A$```#0````"/K``H```H(86$``0,$$@8)`8` M`H^N`"2/KP`LC=@`G``/R(``0(`A`QE`(:T0``"/J0`DCZL`+(TJ`)P`"VB` M`4U@(8V.``"/KP`H`````*WN`/B/N``HCZ4`,(^F`#2'!``$#!!("`````"/ MN0`T`$"`(1(9``L`````CZ@`*#P$$``\!1``C08``(T'`/`DI30&#!`E1"2$ M,]00```5```0(8^I`"B/J@`TC2L`^``````!:F@AK2T`^(^L`"2/KP`LC8X` MH``/P(`!V,@ACR@``(^K`#0``````0M0(:\J```0```#)`(``1````$````` MC[\`'(^P`!@#X``()[T`*">]_^BOOP`4KZ0`&(^N`!@`````A<\`"@`````Q M^``(%P```P`````0```4```0(8^Y`!@`````CR@!#``````1```'``````$` M^`D#("`A%$```P`````0```(```0(8^D`!@,$$>%`````!````,`````$``` M`0````"/OP`4)[T`&`/@``@`````)[W_X*^P`!BOOP`<`("`(:^D`""6#@`B MA@\`"``````1SP`%`````(X$`2".!0$L#!`EP0````".!0#TC@8!((X'`2P, M$$;?`@`@(11```,`````$```"0``$"&N``$LCA@!(`````"N&`$H$````R0" M``$0```!`````(^_`!R/L``8`^``"">]`"`GO?U8`(`8(20.__^OK@`<%&`` M$:^_`!0\!!``#^`$;"2$-C000``%`$`8(9!/````````%>``"`````"3F("0 M`````!,```,`````$```(P``$"$G@X"4/`40`"2E-D"C@("0)Z0"*`_@!+RO MHP*HCZ,"J">D`C8/X`2\`&`H(2>D`B@,$$@````H(01``!$`0"`A)Z4`)B0& M`@(,$$@0KZ0`("0!`@(400`(CZ0`(#P$$``DA#0P)Z4`)@_@!(PD!@("KZ`` M'(^D`"`,$$?X`````(^B`!P`````C[\`%">]`J@#X``(```````````GO?_H MK[\`%`_@!#ZOI``8CZ0`&`P02(@`````C[\`%">]`!@#X``(```````````D M`@/P````#!#@``,`````"!!(C``````#X``(`````"0"`^X````,$.```P`` M```($$B,``````/@``@``!`A)`(#[0````P0X``#``````@02(P``````^`` M"``````D`@/L````#!#@``,`````"!!(C``````#X``(`````"0"`^L````, M$.```P`````($$B,``````/@``@`````)`(#^P````P0X``#``````@02(P` M`````^``"``````D`@0$````#!#@``,`````"!!(C``````#X``(```0(2>] M_^"OL@`8/!(0`*^Q`!2OI0`D/`40``#`B"$F4CXWK[\`'*^P`!"OI``@)`0` M`@)`@"$D!@`2#!!(""2E/D"/I``@#^`$P@````"/I0`@)`0``@P02`@`0#`A M)`0``B>%@+`,$$@()`8`!X^D`"0/X`3"`````(^E`"0D!``"#!!("`!`,"$D M`B<0)`0``0(B`!H40``"```````'``TD`?__%$$`!#P!@``6(0`"```````& M``T``!@2%&``!B1N`#`6$@`$)&X`,!1$``0`````)&X`,*(.```F$``!`B(` M&A1```(```````<`#20!__\400`$/`&``!8A``(```````8`#20!``H``(@0 M````````````00`:```0$A1`_]L`````/!$0`"0/``JB#P``)C$^,"80``$" M("`A#^`$PJ(````D!``"`B`H(0P02`@`0#`A#!!(D`````"/OP`]`"```````````"0"`^D````,`^``"``````\`1``K"(_ M7`/@``@D`O__)[W_Z*^_`!0D!``&#!!)$```*"$00``%`$`H(0P021`D!``& M$```"`````"/@H#`)`$``21"``$400`#KX*`P`_@!#X`````#!!),``````` M0"`A#!!)*"0%``:/OP`4)[T`&`/@``@``````````#P#$`",8SYD)`(#^0"# M("$````,%.``!0`````\`1``K"0^9`/@``@`8!`A"!!(C``````\`A``C$(^ M8```````@@@K$"```@``````0"`A)`(#^0````P4X/_T`````#P!$`"L)#YD M`^``"```$"$8@`!6`````"B!`!\0(`!3`````#2$`@`D`@08````#!#@``,` M````"!!(C``````#X``(`````!B``$@`````*($`'Q`@`$4`````-(0$`"0" M!!@````,$.```P`````($$B,``````/@``@`````&(``.@`````H@0`?$"`` M-P`````TA`@`)`($&`````P0X``#``````@02(P``````^``"``````8@``L M`````"B!`!\0(``I`````#2$$``D`@08````#!#@``,`````"!!(C``````# MX``(`````!B``!X`````*($`'Q`@`!L`````/`8`023&)(0TA`$`)`($&``` M``P0X``#``````@02(P``````^``"``````8@``.`````"B!`!\0(``+```` M`#P&`$$DQB2$)`($&`````P0X``#``````@02(P``````^``"``````($$B, M)`(`%B>]_^@`X/@)KZ8`$(^D`!`D`@1`````#``````D`@0-````#!#@``,` M````"!!(C``````#X``(```0(20"`_P````,$.```P`````($$B,``````/@ M``@``````````````````````````#P"$``D0C0P/`$/P*PB```\`@!!)$(B ML#P!#\"L(@`4/`(`021"(N0\`0_`K"(`&#P"$``D0C]0/`$/P*PB`!`\`A`` M)$(_7#P!#\"L(@``!`%]0`0!=X M`$`7>`!`%W@`0!=X`$`7>`!`%W@`0!=X`$`7U`!`?E@`0("H`$!_\`!`?X@` M0("H`$"`6`!`@*@`0("H`$"`J`!`@*@`0("H`$"`J`!`@*@`0("H`$"`J`!` M@*@`0("H`$"`6`!`@%@`0("H`$"`J`!`@*@`0'R``$"`J`!`@*@`0("H`$"` MJ`!`@*@`0'SP`$!\"`!`@*@`0'P(`$!\\`````````````````!`GS@`0)^\ M`$"@3`!`H,@`0*Y,`$"O"`!`KDP`0*\(`$"O,`````````````````!`P9`` M0,&``$#!<`!`P6``0,(L`$#"(`!`PA0`0,((`$##D`!`PX``0,-P`$##8`!` MQ"P`0,0@`$#$%`!`Q`@`0,44`$#%!`!`Q/0`0,3D`$#"I`!`P2``0,2D`$## M%`!`R!@`0,?\`$#'X`!`Q\0`0,C``$#(M`!`R*@`0,B<`$#)O`!`R:``0,F$ M`$#):`!`RN@`0,K,`$#*L`!`RI0`0,N0`$#+A`!`RW@`0,ML`$#,J`!`S(P` M0,QP`$#,5`!`R3@`0,=T`$#,"`!`RBP`0-,X`$#2U`!`TG``0-(,`$#5R`!` MU2@`0-2(`$#3Z`!`V>@`0-G$`$#9H`!`V7P`0-E8`$#9-`!`V1``0-CL`$#< M_`!`W-@`0-RT`$#`!`\V@`0/-8 M`$#S2`!`\S@`0/,H`$#S&`!`])@`0/2(`$#T>`!`]&@`0/18`$#T2`!`]#@` M0/0H`$#Q"`!`\>``0/'@`$#R^`!`\O@`0/@H`$#X.`!`^%0`0/AP`$#[^`!` M_'@`0/T0`$#]B'5S86=E.B!F`H``&EO<&5N.B!E7!E"@!I;6=L:6(Z(')O=R!N=6UB97(@;W5T(&]F(')A;F=E M("5D("5D"@``:6UA9V4@'!A;F0Z(&)A9"!B<'`Z("5D("5D"@``````0"@C*71I9E]O<&5N M+F,),2XQ-2`Q,B\R.2\X.0````!4249&3W!E;@`````B)7,B.B!"860@;6]D M90`E"D`3F]T(&$@5$E&1B!F:6QE+"!B860@=F5R`!#86YN;W0@=W)I=&4@9&ER96-T M;W)Y+"!O=70@;V8@``$````%``,``!``$6,!'P`!````!0`#```0`!&/`2#__P`` M``3__P``$``1F0$A__\````$__\``!``$:4!(@`!`````P`5```0`!&T`2/_ M_P````,`%@``$``1Q0$D``$````$`!<``!``$=&5L`%)O=W-097)3=')I<`!2;W=S4&5R M4W1R:7``4W1R:7!">71E0V]U;G1S`$UI;E-A;7!L959A;'5E`$UA>%-A;7!L M959A;'5E`%A297-O;'5T:6]N`%E297-O;'5T:6]N`%!L86YA5)E2!L:6YK`$1A=&54:6UE`$AO0`````E0!#86X@;F]T(')E860@5$E& M1B!D:7)E8W1O0!#86X@;F]T(')E860@5$E&1B!D:7)E8W1O3L@=&%G"D`5W)O;F<@9&%T82!T>7!E("5D(&9O2!IF5R;R!D96YO;6EN871O<@!);F-O2!T;R!F971C:"!F:65L9"`B)7,B```````````` M0"@C*71I9E]C;&]S92YC"3$N-R`V+S@O.#D``%1)1D9#;&]S90`````````` M````0"@C*71I9E]R96%D+F,),2XQ.2`Q,B\R.2\X.0````!&:6QE(&YO="!O M<&5N(&9O"`E9`!#;VUP7MX^OG[^`8%!P2&A8>$1D5'1,;%Q\0F)2?D%A47% M):5EY1655=4UM77U#8U-S2VM;>T=G5W=/;U]_0.#0\,CHV/C$Y-3TS.S<_,+ MBTO+*ZMKZQN;6]L[NWO[!X='QR>G9^<7EU?7-[=W]P^/3\\OKV_O'Y]?WS^_ M?_\`````0"@C*71I9E]C;VUP870N8PDQ+C(@,3(O,CDO.#D```!`*",I=&EF M7W=A"5X*0```````````````$`H(RET:69? M9FQU````&0```&D````,````'P```!D```!J```` M#````"`````9````:P````P````A````&0```-(````,````(@```!D```#3 M````#````",````9````U`````P````D````&0```-4````,````)0```!D` M``#6````#````"8````9````UP````P````G````&0```&P````,````*``` M`!D```!M````#````"D````9````V@````P````J````&0```-L````,```` M*P```!D```!4````#````"P````9````50````P````M````&0```%8````, M````+@```!D```!7````#````"\````9````9`````P````P````&0```&4` M```,````,0```!D```!2````#````#(````9````4P````P````S````&0`` M`"0````,````-````!D````W````#````#4````9````.`````P````V```` M&0```"<````,````-P```!D````H````#````#@````9````6`````P````Y M````&0```%D````,````.@```!D````K````#````#L````9````+`````P` M```\````&0```%H````,````/0```!D```!F````#````#X````9````9P`` M``P````_````&@````\````*````0````!H```#(````#````(`````:```` MR0````P```#`````&@```%L````,```!`````!H````S````#````4`````: M````-`````P```&`````&@```#4````,```!P````!H```!L````#0```@`` M```:````;0````T```)`````&@```$H````-```"@````!H```!+````#0`` M`L`````:````3`````T```,`````&@```$T````-```#0````!H```!R```` M#0```X`````:```` Organization: The Temple of Eris (tm) Subject: Building C++ 2.0 on SGI 4D Message-Id: <987@contex.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone out there brought up C++ 2.0 on the Silicon Graphics 4D series (the MIPS chipset)? If so, I'd like to hear from you -- any tips, pointers, etc. Thanks! bill -- Bill {aka William F} Phillips | uunet!contex!bill | [also wfp@well.sf.ca.us] Systems Development Group | Xyvision Design Systems | Wakefield, MA, USA *PLEASE MAKE NOTE OF NEW ADDRESS* "Two thoughts with but a single mind."(tm)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad02943; 24 Feb 90 1:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02870; 24 Feb 90 1:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02789; 24 Feb 90 1:30 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22382; 24 Feb 90 1:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07249; Fri, 23 Feb 90 22:12:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 05:27:49 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: executable size Message-Id: <3747@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On a related note to my other article, can the size of an executable be reduced while still being an executable? I noticed that the size of the exec for some of the demos and such are very small but any extensive graphics thing I do is easily over 800k in size so something must have been done to 'em right? Any ideas? =========================================================================== Tom Rohling "Infinity is where things happen trohling@uceng.uc.edu that don't." -Anonymous or rohling@afiris.ase.uc.edu ===========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04516; 24 Feb 90 6:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04477; 24 Feb 90 6:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04471; 24 Feb 90 6:18 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa24406; 24 Feb 90 5:38 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3265; Sat, 24 Feb 90 04:36:49 CST Received: by UMRVMA (Mailer R2.05) id 3261; Sat, 24 Feb 90 04:36:46 CST Date: Sat, 24 Feb 90 04:29:38 CST From: Bob Funchess Subject: Mac <> TIFF To: info-iris@BRL.MIL Message-ID: <9002240539.aa24406@SMOKE.BRL.MIL> Macintosh PICT is not a subset of TIFF, BUT there is a public domain Mac program capable of turning PICT files into TIFF files (among other things. LOTS of other things :)> ) that is called "Image". This is NOT NCSA Image, which is a different beast. It is available from alw.nih.gov, is freely copyable, and source code is available (I believe it's Pascal) from the same place (anonymous FTP, natch). I don't know how easy/hard it would be to move the file reader/writer part to an Iris. < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Disclaimer: If the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04713; 24 Feb 90 7:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04690; 24 Feb 90 7:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04687; 24 Feb 90 7:18 EST Received: from kwai.inria.fr by SMOKE.BRL.MIL id aa25079; 24 Feb 90 7:02 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 24 Feb 90 13:04:20+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 24 Feb 90 13:01:56+0100 Date: 24 Feb 90 13:01:56+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: C++ and C Message-ID: <205*doelz@urz.unibas.ch> Hi , we are about rewriting our graphics application in order to tune code. We have some own object-oriented modules which would fit pretty nicely in C++ structures. However, as tuning is the ultimate target, does anyone know about * C++ performance in comparison to 'plain' C modular structures * possibility to complile/link/debug/pixie C++/C mixed code * Optimizer issues: problems with O3? * System resources: more than 'usual' - ? (We got only 16 megs on a 120). * C++ and power vision calls I'd appreciate any hints. Regards, Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05475; 24 Feb 90 11:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05376; 24 Feb 90 11:13 EST Received: from vat.brl.mil by VMB.BRL.MIL id aa05333; 24 Feb 90 11:02 EST Date: Sat, 24 Feb 90 5:23:01 EST From: "John R. Anderson" (VLD/ASB) To: tom rohling cc: info-iris@BRL.MIL Subject: Re: real to character converter Message-ID: <9002240523.aa01589@VAT.BRL.MIL> From Tom Rohling: > Does anybody have a real good real*8 or real*4 to character converter >subroutine (maybe) that can do the following, (or something like it): > > 1) Send it a real number to be converted to a character variable > that can be forwarded to a graphics lib call like 'fmprstr'. > > 2) Specify how many decimals you would like to retain. For example, > if I have a real*8, I don't want to have all 16 digits in the > character variable, but say only keep two. How about something like: character*24 strg real*8 number integer length write( strg , 100 ) number 100 format( 'f10.2' ) c Use a function that returns the index of the last c non-blank character in the string c I'm not sure of the name of the routine length = lnblank( strg ) call fmprstr( ..., strg(1:length) , ... )   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06012; 24 Feb 90 13:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05946; 24 Feb 90 13:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05930; 24 Feb 90 13:04 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27541; 24 Feb 90 12:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04767; Sat, 24 Feb 90 09:17:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 14:18:00 GMT From: "David M. McQueen" Organization: New York University Subject: Re: executable size Message-Id: <17280032@acf4.NYU.EDU> References: <3747@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > On a related note to my other article, can the size of an executable >be reduced while still being an executable? I noticed that the size of the >exec for some of the demos and such are very small but any extensive >graphics thing I do is easily over 800k in size so something must have been >done to 'em right? > > Any ideas? > >=========================================================================== >Tom Rohling "Infinity is where things happen >trohling@uceng.uc.edu that don't." -Anonymous > or >rohling@afiris.ase.uc.edu >=========================================================================== /* ---------- */ Two ways I have found to reduce the size of executables are: 1) compile using shared graphics libraries. As an example (Fortran, but similar and even greater reductions are possible with C programs): With f77 program.f -lfgl -lgl : 652704 bytes With f77 program.f -lfgl -lgl_s : 453440 bytes a reduction of about 200 Kbytes 2) again in Fortran, if you are using large arrays, place those arrays in labelled common blocks. =============================================================================== Disclaimer: The above is just my opinion. God Alone Knows. David M. McQueen,Courant Institute of Mathematical Sciences,New York University "The difference between long-distance commuting and long-distance computing is that with long-distance computing you can stay in your office and get stuck in traffic."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06804; 24 Feb 90 17:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06775; 24 Feb 90 17:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06770; 24 Feb 90 17:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29830; 24 Feb 90 17:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17502; Sat, 24 Feb 90 14:02:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 21:17:46 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: executable size Message-Id: <4529@odin.SGI.COM> References: <17280032@acf4.NYU.EDU>, <3747@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17280032@acf4.NYU.EDU>, mcqueen@acf4.NYU.EDU (David M. McQueen) writes: > /* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > > > On a related note to my other article, can the size of an executable > >be reduced while still being an executable? I noticed that the size of the > >exec for some of the demos and such are very small but any extensive > >graphics thing I do is easily over 800k in size so something must have been > >done to 'em right? > > > > Any ideas? > > > >=========================================================================== > >Tom Rohling "Infinity is where things happen > >trohling@uceng.uc.edu that don't." -Anonymous > > or > >rohling@afiris.ase.uc.edu > >=========================================================================== > /* ---------- */ > > Two ways I have found to reduce the size of executables are: > > 1) compile using shared graphics libraries. As an example (Fortran, but > similar and even greater reductions are possible with C programs): > > With f77 program.f -lfgl -lgl : 652704 bytes > With f77 program.f -lfgl -lgl_s : 453440 bytes > > a reduction of about 200 Kbytes > > 2) again in Fortran, if you are using large arrays, place those arrays > in labelled common blocks. > > > =============================================================================== > Disclaimer: The above is just my opinion. God Alone Knows. > > David M. McQueen,Courant Institute of Mathematical Sciences,New York University > > "The difference between long-distance commuting and long-distance computing is > that with long-distance computing you can stay in your office and get stuck in > traffic." The MIPS compilers used on SGI, MIPS, and other competitor's workstations generate a lot of symbol information in executables, even if no debugging is selected. This symbol info includes function names, globals, and line number information. This level of detail allows you to dbx an executable (too a limited extent) or use pixie for profiling. If you are satisfied that you do not want or need any of this symbol info in you code (i.e. if you are shipping it to customers), you can strip your executable using the program strip(1). This should reduce the size of your executables by possible a couple hundred 'k'. Don't go stripping your libraries though -- you won't be able to link to them. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07525; 24 Feb 90 20:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07454; 24 Feb 90 20:42 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa07445; 24 Feb 90 20:29 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa21093; 24 Feb 90 20:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26409; Sat, 24 Feb 90 17:13:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 23:56:12 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: Re: NNTP / other news software Message-Id: <1990Feb24.235612.14732@utzoo.uucp> References: <9002230726.aa00531@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002230726.aa00531@SMOKE.BRL.MIL> S090726@UMRVMA.UMR.EDU (Bob Funchess) writes: >Has anyone ported nntp or anything like it to the 4D platform? What >do the people in this newsgroup use to get their news? I'm pretty sure there are folks here at U of T running NNTP on 4Ds. I know C News runs on the 4D series -- a 4D/60T is one of our test systems. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07578; 24 Feb 90 21:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07525; 24 Feb 90 21:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07504; 24 Feb 90 20:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00900; 24 Feb 90 18:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22031; Sat, 24 Feb 90 15:42:24 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 23:05:33 GMT From: George Seibel Organization: Computer Graphics Lab, UCSF Subject: Re: real to character converter Message-Id: <13170@cgl.ucsf.EDU> References: <3743@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3743@uceng.UC.EDU> trohling@uceng.UC.EDU (tom rohling) writes: > > Does anybody have a real good real*8 or real*4 to character converter >subroutine (maybe) that can do the following, (or something like it): > > 1) Send it a real number to be converted to a character variable > that can be forwarded to a graphics lib call like 'fmprstr'. Use an internal write: (it's ANSI f77, not an extension) subroutine RtoCh(rvar,cvar) real rvar character*(*) cvar write(cvar,'(f8.3)') rvar return end > 2) Specify how many decimals you would like to retain. For example, > if I have a real*8, I don't want to have all 16 digits in the > character variable, but say only keep two. For this just use a different format, like f8.2. George Seibel, UCSF seibel@cgl.ucsf.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07578; 24 Feb 90 21:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac07525; 24 Feb 90 21:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07509; 24 Feb 90 20:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01519; 24 Feb 90 20:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25686; Sat, 24 Feb 90 16:57:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 00:56:56 GMT From: Mark Moraes Subject: possible compiler bug in Irix3.2? Message-Id: <90Feb24.195555est.1012@church.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The program giftoppm in the pbmplus distribution (part of X.V11R4, in contrib/pbmplus) when compiled with -O, doesn't work on any of the six GIF images I tried, but produces an error like: ./giftoppm: ../../K3900204.GIF is a corrupt GIF file (unblock) When just the file ppm/giftoppm.c is compiled with -g (all the libraries are still with -O), it works fine. [I can send you the source code, and a sample GIF file if you can't reproduce this] Mark.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07788; 24 Feb 90 22:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07747; 24 Feb 90 22:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07734; 24 Feb 90 21:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01849; 24 Feb 90 20:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27467; Sat, 24 Feb 90 17:34:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 01:31:18 GMT From: dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!sherman@uunet.uu.net Subject: Re: polf errors on 4D 70 GT Message-Id: <19400001@ux1.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* Written 12:10 pm Feb 23, 1990 by jsivier@UX1.CSO.UIUC.EDU */ > Has anyone else noticed anything like this? I am displaying a large > number of objects on a Iris 4D 70 GT. There are at least several hundred > polygons on the screen at any given time. As I move my POV around various of > the polygons will have their centers clipped out. The left and right ends are > displayed correctly but the center portions are not there. These polygons Sounds to me like the near clipping plane needs to be nearer. Did you try this Jon? > > Thanks > > Jonathan Sivier > jsivier@ux1.cso.uiuc.edu /************************************************************************/ /* Bill Sherman */ /* National Center for Supercomputing Applications */ /* University of Illinois */ /* Champaign-Urbana */ /* */ /* Internet: wsherman@ncsa.uiuc.edu */ /* */ /* "You want to do mankind a real service? Tell funnier jokes." */ /* Og */ /************************************************************************/   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09465; 25 Feb 90 7:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09438; 25 Feb 90 7:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09421; 25 Feb 90 7:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06226; 25 Feb 90 6:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23777; Sun, 25 Feb 90 02:41:22 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 20:13:35 GMT From: Avinash Chopde Organization: Xyvision Design Systems, Wakefield MA Subject: viewport (scrmask also) clipping problems with lrectwrite() Message-Id: <989@contex.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Help! I have this program segment which uses rectzoom(), sets a viewport(), and then uses lrectwrite(). It works correctly most of the time, but fails for the program given below -- it draws the clipped part correctly, but also draws the same stuff on 100 pixels on the left part of the screen (some sort of "folding" around). What makes matters worse, can't seem to figure out the condition under which it fails -- have exprimented a bit with it. Any help with regards to pointing out errors in the program, or description of known bugs in the case of lrectwrite() clipping would be greatly appreciated. (Program fails on IRIX 3.2.1 as well as 3.2) ----------------- cut here --------------------------------- #include main() { long lrect_buffer[XMAXSCREEN+1]; unsigned char uc[4]; int i; ginit(); RGBmode(); gconfig(); RGBcolor(0,0,0); clear(); uc[0] = 0; uc[1] = uc[2] = uc[3] = 128; for (i = 0; i <= XMAXSCREEN; i ++) { lrect_buffer[i] = *(long *)uc; } rectzoom(2.0, 2.0); viewport((Screencoord)(700), (Screencoord)(1100), /* x limits */ (Screencoord)(200), (Screencoord)(800)); /* y limits */ for (i = 799; i >= 200; i -= 2) { lrectwrite((Screencoord)(0), (Screencoord)(i), /* lower left */ (Screencoord)(599), (Screencoord)(i), /* upper right */ lrect_buffer); } gflush(); sleep(5); } ----------------- end of cut --------------------------------- -- --------------------------- Avinash Chopde home : 508 470 1190 contex!avinash@uunet.uu.net office : 617 245 9004 x5582   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09465; 25 Feb 90 7:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09438; 25 Feb 90 7:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab09421; 25 Feb 90 7:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06279; 25 Feb 90 6:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23796; Sun, 25 Feb 90 02:41:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 90 22:03:08 GMT From: Avinash Chopde Organization: Xyvision Design Systems, Wakefield MA Subject: Re: viewport (scrmask also) clipping problems with lrectwrite() Message-Id: <990@contex.UUCP> References: <989@contex.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL With reference to my previous posting (lrectwrite() not clipping correctly to the viewport()), seems like the graphics boards are the key to the problem. Given program fails on machines with this (hinv) "Graphics board: GR1.1 ..." while it works correctly on machines with "Graphics board: GR1.2 ..." So, does anybody know of a workaround for the problem for GR1.1 machines ? Any pointers will be greatly appreciated. -- --------------------------- Avinash Chopde home : 508 470 1190 contex!avinash@uunet.uu.net office : 617 245 9004 x5582   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17024; 26 Feb 90 10:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16484; 26 Feb 90 10:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16422; 26 Feb 90 9:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22194; 26 Feb 90 8:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12669; Sun, 25 Feb 90 22:25:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 03:23:01 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: X - xinit Message-Id: <390@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anyone help explain or provide a work-around for an unusual problem i'm having with the X server...on my P.I. when I do an "xinit" from a wsh terminal an x-login window is created in a normal way. I usually invoke an X client on my colleagues sun (xbif) that displays on my Iris. when I'm finished I ususally log off (all at once) and go home.... When I log in again and try to invoke X (via xinit) I get no response. I found out that Xsgi from my previous session was still running and blocking my new Xinit request. Until I kill Xsgi from the previous session, new Xevents are not processed.... What's happening... I would like the X-server to shut down when I log off. Sometimes it seems to as I don't always find Xsgi running when i log back in. could my sun application have something to do with this behavior.? I can be reached at convex!texhrc!mjz or here... thanks Michael Zeitlin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09088; 25 Feb 90 5:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09042; 25 Feb 90 5:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09004; 25 Feb 90 5:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04050; 25 Feb 90 1:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11995; Sat, 24 Feb 90 22:28:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 06:27:35 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: jove, other makes Message-Id: <90Feb25.012627est.613@smoke.cs.toronto.edu> References: <9002222316.AA17932@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: >Has anyone ported jove, TeX, and all the useful unix software available >via ftp to the SG's, resolving in makefile/source form all of these >difficulties? Is there a ftp repository of them through which I can >browse? Does anyone out there have any rules of experience to share >concerning ports (such as always using -I/usr/include/bsd as a compile >switch)? Dunno about all the useful unix software, but about jove and TeX, on cs.toronto.edu: pub/moraes/jove4.14.1.shar.Z is a version of Jove that has been made portable enough to compile without change on Irix3.2, SunOS, A/UX and Ultrix. Still some unresolved problems -- eg. interactive processes use pipes, not ptys, because SGI ptys are so different, and because Jove assumes that a machine with ptys automatically has BSD style terminal ioctls. Sigh. pub/TeX is the version of TeX that we use on Irix3.2, SunOS and Ultrix. As for portability rules for C programs, you're right about the pain and grief caused by programs that assume the world to be either SysV or BSD with no shades of gray in between. The main areas of pain are signals (hopefully will be relieved in Irix3.3), termio, ptys. Not to mention the problems of porting shell scripts because of the lack of little things like echo -n, (for which you have to fix sh) the wide difference between the output formats of various commands (fixable by various options -- we have a /local/bin/bsd43 which contains one line scripts like "exec /usr/bin/size -B $@") Some utilities are "enhanced|broken" to the point where we install stuff from 4.3tahoe or GNU src to compensate. (tar, make, diff, ls, ln) It would be nice if SGI would add more BSD compatibility -- perhaps something like the stuff MIPS has done in RISCos4.0 with a separate /bsd43/{bin,usr/{include,lib}} so people who want the BSD world can get it without needing to learn different options for different machines. I've compiled many programs with -DBSD43 (or suchlike) on RISCos4.0 and they work just fine, which is a great help for those of us that have heterogeneous collections of machines. Mark.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09308; 25 Feb 90 6:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08947; 25 Feb 90 5:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08924; 25 Feb 90 4:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04193; 25 Feb 90 1:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12592; Sat, 24 Feb 90 22:41:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 06:40:25 GMT From: Mark Moraes Subject: getlogin()? Message-Id: <90Feb25.013913est.447@smoke.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Why does getlogin() on Irix3.2 return either "rlogin" or some random user name if the pty you're running on does not have a utmp entry? (Sometimes, I run an xterm that isn't setuid root because it's experimental, or do not advertise a utmp in all my windows so system messages don't beep me all over the place) It would seem a better solution for getlogin() to return NULL so that programs can then follow the manual page and call getpwuid(). Mark.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10690; 25 Feb 90 18:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10519; 25 Feb 90 18:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10497; 25 Feb 90 17:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10600; 25 Feb 90 17:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16067; Sun, 25 Feb 90 14:05:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 21:50:48 GMT From: "Robert E. Minsk" Organization: Georgia Institute of Technology Subject: Genlock and Colormap Message-Id: <6397@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am working on an IRIS 120GTX with a Genlock board running 3.2 and have the following problem. For some reason when I am using the Genlock with de3 set to RS 170 changing entries in the colormap table do not work correctly, without Genlock it works fine. I copied the code directly out of cg2.c to change the mode. To see an example of what I'm talking about (only if you have a Genlock board with a TV attached) run /usr/4Dgifts/examples/video/cg2 and while in Genlock mode run /usr/demos/old/light (light makes heavy use of the colormap.) Is there a way to work around this problem without going to rgbmode? -- Robert E. Minsk - Office of Computing Services | Save the whales... | ARPA: ccoprrm@prism.gatech.edu | Collect the whole set | uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccoprrm Georgia Institute of Technology, Atlanta Georgia, 30332   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10690; 25 Feb 90 18:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10519; 25 Feb 90 18:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab10497; 25 Feb 90 17:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10605; 25 Feb 90 17:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16217; Sun, 25 Feb 90 14:08:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 90 20:14:48 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: C++ and C Message-Id: <4534@odin.SGI.COM> References: <205*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <205*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard Doelz) writes: > Hi , > we are about rewriting our graphics application in order to tune code. > We have some own object-oriented modules which would fit > pretty nicely in C++ structures. However, as tuning is the > ultimate target, does anyone know about > > * C++ performance in comparison to 'plain' C modular structures It really does depend on your application and how you implement your C++ classes and how you previously implemented the same data abstractions in 'plain' C. For instance, the use of C++ derived classes and virtual member functions can produce faster code than might be equivalently implemented using a data type tag and switch statement in C. Judicious use of C++ inline functions can also speedup some code. Unfortunately, no one can give you a pat answer one way or another. There have been some claims made on comp.lang.c++ though I haven't followed those discussions in awhile. > > * possibility to complile/link/debug/pixie C++/C mixed code > > * C++ and power vision calls C++ was designed to be fairly compatible with existing C++ code. C++ code can directly call the C-GL routines for instance, including the new POWERVision calls. The IRIX dbx has been extended to provide help in debugging C++ code. For instance, it does name-demangling of member variables. It doesn't do name demangling of function names though for SGI's C++ 1.0 (AT&T v1.2.1). We have used pixie extensively in-house in conjunction with in-house developed C++ applications like the IRIS WorkSpace(TM) and wsh, the window shell. > > * Optimizer issues: problems with O3? The AT&T C++ Translator from SGI just produces C code. There should not be any problems with using -O3 optimization. > > * System resources: more than 'usual' - ? (We got only 16 megs on a 120). C++ tends to be very data intensive. Experience with C++ shows that sometimes people over develop classes and throw unnecessary information into the classes. After a couple of levels of derivation, an instance of a class can be larger than you would expect. This requires the programmer to think about their data abstractions a little more than they might of in the past. Another area to be aware of is text space locality. C++ derived classes are typically implemented in there own files. After a couple layers of derivation, a call to a member function of a derived might be implemented to make references to base class functions. This is usually true of class constructors and destructors. This can sometimes result in less than optimal VM paging performance. Of course, this is true of any application which calls functions in many different modules. Some performance gains can be made by using pixie(1) and cord(1) to rearrange the functions in text space so that functions which call each other a lot are next to (or close to) each other. This can reduce the VM resident set size requirements of any application, not just applications written in C++. > > I'd appreciate any hints. > Regards, > Reinhard I'm personally involved in a development project here at SGI using C++. I also have friends at other companies who are doing development in C++. All of them agree that you don't just learn C++ overnite, even with an extensive background in C. There is a learning curve associated with the transition to C++. This includes understanding efficiency design considerations. However, almost all of them prefer working in C++ versus 'plain' for object-oriented development. Good luck! --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11940; 25 Feb 90 22:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11909; 25 Feb 90 22:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11900; 25 Feb 90 21:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12561; 25 Feb 90 21:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26995; Sun, 25 Feb 90 17:33:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 00:32:57 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: C++ and C Message-Id: <4537@odin.SGI.COM> References: <4534@odin.SGI.COM>, <205*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL After some sanity checking by a fellow engineer, I must clarify a few points. In article <4534@odin.SGI.COM>, ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) writes: > In article <205*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard > Doelz) writes: > > Hi , > > we are about rewriting our graphics application in order to tune code. > > We have some own object-oriented modules which would fit > > pretty nicely in C++ structures. However, as tuning is the > > ultimate target, does anyone know about > > > > * C++ performance in comparison to 'plain' C modular structures > > It really does depend on your application and how you implement your C++ > classes and how you previously implemented the same data abstractions in > 'plain' C. For instance, the use of C++ derived classes and virtual member > functions can produce faster code than might be equivalently implemented > using a data type tag and switch statement in C. Judicious use of C++ inline > functions can also speedup some code. > > Unfortunately, no one can give you a pat answer one way or another. There > have been some claims made on comp.lang.c++ though I haven't followed those > discussions in awhile. Including me. The sanity check of a test program definitely showed me that switch statements can produce faster code than using virtual functions and not as I claimed in the prior message. However, maintaining the code which uses the virtual functions is easier. By-the-by, I just proved this to myself using C++ and pixie. Sigh. More proof you can't rely on hearsay to see that one thing is faster than another. The proof is in the profile. > > > > * Optimizer issues: problems with O3? > > The AT&T C++ Translator from SGI just produces C code. There should not be > any problems with using -O3 optimization. > There is an issue concerning -O3 optimization. -O3 and -c are mutually exclusive with the MIPS cc. The C++ translator uses the -c flag in the creation of object code. Hence, you will need to have C++ generate the intermediate ..c files and then manually compile them together using cc -O3. Ugly, but it will still provides the -O3 optimization. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19985; 26 Feb 90 13:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19540; 26 Feb 90 13:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19330; 26 Feb 90 13:19 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa13400; 25 Feb 90 22:41 EST Received: from UMRVMA.UMR.EDU by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8687; Sun, 25 Feb 90 21:39:46 CST Received: by UMRVMA (Mailer R2.05) id 8686; Sun, 25 Feb 90 21:39:43 CST Date: Sun, 25 Feb 90 21:23:16 CST From: Bob Funchess Subject: sendmail.cf To: info-iris@BRL.MIL Message-ID: <9002252241.aa13400@SMOKE.BRL.MIL> All right, I give up. What is the sendmail.cf file supposed to look like? The SG supplied one (yes, I reloaded from tape) won't build the aliases (also the one supplied). This disturbs me somehow. Our situation is: 1 Silicon Graphics Personal Iris 4D/20, on Ethernet, name blumiris.chem.umr.edu. It does NOT have modems. All I want is for it to send outgoing mail to an SMTP forwarder (in this case, umrvmb.umr.edu) to be passed along, and for it to receive incoming mail for @blumiris.chem.umr.edu. I don't need anything fancy like forwarding to UUCP sites, etc. By editing the GA Tech sendmail.cf file from comp.sources.unix, I have managed to get OUTGOING mail working. INCOMING mail gets to the machine and bounces with setsender: can't even parse postmaster! which gets prepended to the message and zapped back to the original sender. Yes, the local user does exist (root). The mail is obviously getting to the Iris, since that is noted in the bounced message. The only thing that I know of that is weird in the .cf file is the fact that I want forwarding to be handled at a level which is technically one up from ours (.umr.edu instead of .chem.umr.edu). Our domain is defined as umr.edu, and the machine is defined as blumiris.chem. Is this the source of the problem? If so, how can I work around it? < Bob | S090726@UMRVMA.UMR.EDU | Funchess > University of Missouri - Rolla Disclaimer: If the university shared my opinions, would I have an ID like S090726 ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15413; 26 Feb 90 8:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14083; 26 Feb 90 8:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13978; 26 Feb 90 7:43 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa17645; 26 Feb 90 3:35 EST Received: from kwai.inria.fr by RELAY.CS.NET id aa02351; 26 Feb 90 2:36 EST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 26 Feb 90 09:37:39+0100 X400-Received: by /PRMD=ch/ADMD=/C=/; Relayed; 26 Feb 90 09:35:15+0100 Date: 26 Feb 90 09:35:15+0100 From: Reinhard Doelz To: info-iris%BRL.mil@relay.cs.net MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-ID: <211*doelz@urz.unibas.ch> Subject: RE: Genlock and Colormap I have encountered exactly the same problem on PAL. It has been reported to SGI (Switzerland) without anything happening yet. *workaround*: Do a quick switch to the standard (console) 60 HZ video, define your color- map, and go back to NTSC. The colormap is apparently written only if you are in standard video mode. The switching proves to work with home-made software but is certainly not applicable if you don't have source on hand. Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15413; 26 Feb 90 8:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14784; 26 Feb 90 8:37 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa14760; 26 Feb 90 8:27 EST Received: from cunyvm.cuny.edu by ADM.BRL.MIL id aa00258; 26 Feb 90 7:27 EST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0355; Mon, 26 Feb 90 05:07:31 EST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0591; Mon, 26 Feb 90 09:30:21 GMT Received: Via: UK.AC.MRC.NIMR; 26 FEB 90 9:30:10 GMT Via: uk.ac.mrc.nimr; Mon, 26 Feb 90 09:30:20 GMT Date: Mon, 26 Feb 90 09:30:20 GMT From: NMR Center Users Message-Id: <9002260930.AA25112@uk.ac.mrc.nimr> To: info-iris@BRL.MIL Subject: Well, How about it ? Hello, I have recently seen the specs for the new Motorola 68040 - it looks as if it could be at least as powerful as the MIPS chips used in the Iris 4D series. How aout SGI offering an upgrade to the 68040 for their neglected 3000/3100 series users. As far as I can tell, the chip is object-code compatible with the 68020/68881 set, so the software department at SGI would not be overstretched. Although the chip is not pin-compatible, a small daughter-board with a clock doubler to 32MHz would surely suffice. I guess that would not take more than a few days of an engineers time to design. Furthermore, with SGI's progressive pricing policy they could sell a $50 cicuit board for $1000 dollars and let users buy their own 68040. And there would be rejoicing in the world ..... Well, how about it ??? Yours Chris Bauer.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17465; 26 Feb 90 10:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17024; 26 Feb 90 10:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16965; 26 Feb 90 10:20 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa21063; 26 Feb 90 8:07 EST Received: Mon, 26 Feb 90 08:09:46 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 26 Feb 90 08:09:46 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9002261609.AA20841@aero4.larc.nasa.gov> To: uceng!trohling@iuvax.cs.indiana.edu Subject: Re: real to character converter Cc: info-iris@BRL.MIL I don't know of any way to do it in FORTRAN, however, I noticed some C routines that might do what you want: ecvt,fcvt,gcvt. Check section 3 of your UNIX manuals. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20367; 26 Feb 90 14:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19985; 26 Feb 90 14:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19798; 26 Feb 90 13:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00424; 26 Feb 90 12:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15938; Mon, 26 Feb 90 09:17:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 17:16:37 GMT From: Seth Teller Organization: University of California at Berkeley Subject: latex -> previewable postscript? Message-Id: <22430@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL it's very frustrating. latex produces a dvi file (previewable, but with no figures). dvi2ps produces postscript (with figures, but not previewable). does anyone know if or how dvi2ps output may be filtered so that it doesn't totally confuse sgi's _psview_ previewer? and, to sgi: please, can we have a working _psview_? think of all the trees that would be spared. sincerely, seth teller p.s. psh can't display this postscript either (but it prints fine).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20861; 26 Feb 90 14:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20367; 26 Feb 90 14:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20289; 26 Feb 90 14:11 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02652; 26 Feb 90 13:27 EST Received: Mon, 26 Feb 90 13:29:35 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 26 Feb 90 13:29:35 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9002262129.AA22772@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Re: real to character converter Please disregard first part of my original reply. I completely forgot about using a character variable inplace of an unit number in a FORTRAN write statement. I tried to make a simple problem more complex than it was. Got to remember KISS (keep it simple and stupid). -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23280; 26 Feb 90 16:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22985; 26 Feb 90 16:26 EST Received: by VMB.BRL.MIL id ae22122; 26 Feb 90 16:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20761; 26 Feb 90 14:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02392; 26 Feb 90 13:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17634; Mon, 26 Feb 90 09:41:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 17:19:10 GMT From: "Allan J. Nathanson" Organization: Georgia Institute of Technology Subject: Re: NNTP / other news software Message-Id: <6420@hydra.gatech.EDU> References: <9002230726.aa00531@SMOKE.BRL.MIL>, <1990Feb24.235612.14732@utzoo.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002230726.aa00531@SMOKE.BRL.MIL> S090726@UMRVMA.UMR.EDU (Bob Funchess) writes: >Has anyone ported nntp or anything like it to the 4D platform? What >do the people in this newsgroup use to get their news? I've got (r)rn working on our PI's. There were some gotcha's in "Configure" but once they were resolved everything put together well. Allan J. Nathanson allan@prism.gatech.edu Office of Computing Services ...!gatech!prism!allan Georgia Insitute of Technology Atlanta, Georgia 30332-0275 (404)894-4831   Received: from VMB.BRL.MIL by VMB.brl.MIL id ab24122; 26 Feb 90 17:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23883; 26 Feb 90 17:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23728; 26 Feb 90 17:10 EST Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa07605; 26 Feb 90 15:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26091; Mon, 26 Feb 90 11:47:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 18:04:58 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: C++ and C Message-Id: <4556@odin.SGI.COM> References: <205*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We did some performance tests with C++, running the most recent version of the dhyrstone tests through the C++ compiler. The results were identical to the standard C numbers. We even tweaked the tests to use C++ language features and were able to improve the numbers. The trick with C++ is to use it "effectively". There are pieces of your code that aren't performance critical - you can use C++ fully here, without worry. Other sections of your code will be highly critical - use C++, but use it carefully, so that it is generating the same old fast C code. A good thing to avoid if you have a performance critical section is subroutines. (this is true for C too) The mips compilers will optimize the #@$(&#@&$ out of the code, as long as a subroutine isn't called (that way it knows it can safely put memory cells into registers, etc.). Hope this helps. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24464; 26 Feb 90 18:05 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa24122; 26 Feb 90 17:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24008; 26 Feb 90 17:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09606; 26 Feb 90 16:12 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00850; Mon, 26 Feb 90 12:55:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 20:15:22 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: real to character converter Message-Id: <1008@dftsrv.gsfc.nasa.gov> References: <9002261609.AA20841@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002261609.AA20841@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > I don't know of any way to do it in FORTRAN, however, I noticed >some C routines that might do what you want: ecvt,fcvt,gcvt. Check >section 3 of your UNIX manuals. Use an internal write! character *80 cnum x = 1.2345 write(cnum,'(f10.3)') x and for C use sprintf. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ab24874; 26 Feb 90 18:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24731; 26 Feb 90 18:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24708; 26 Feb 90 18:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10235; 26 Feb 90 16:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02567; Mon, 26 Feb 90 13:22:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 20:28:23 GMT From: "Bernard J. Duffy" Organization: University of Maryland, Baltimore County Subject: Re: PI Problems Message-Id: <2836@umbc3.UMBC.EDU> References: <9002220905.aa28986@VAT.BRL.MIL>, <51649@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <51649@sgi.sgi.com> brendan@illyria.wpd.sgi.com (Brendan Eich) writes: >In article <9002220905.aa28986@VAT.BRL.MIL>, jra@BRL.MIL ("John R. Anderson", VLD/ASB) writes: >> 1. The other day, I changed the net addresses on our PI's, and >> at the same time I happened to place a notice to the user's in /etc/motd. >> ... some of this deleted .... > >The BSD rcp protocol is fragile: as the friendly manual page says in its >BUGS section: > > [Rcp is] confused by any output generated by commands in a .login, > .profile, or .cshrc file on the remote host. > >The problem is not having a non-empty /etc/motd on the remote host, but >the fact that the remote user's .profile or .cshrc file cats /etc/motd >(the above-quoted warning about .login is erroneous -- the remote half of >rcp uses does not involve a login shell, so .login is not sourced). > >Csh users can cat motd-like files from their .login files. But users of >any shell shouldn't need to cat /etc/motd, as /etc/profile and /etc/cshrc >do so for all login shells upon startup. But what about X-term users. I noticed that xterminal sessions (logins) into the SGI machines don't have the benifit of /etc/cshrc (don't know about /etc/profile for sh users.. don't have any). And not only does that not get executed, neither does the .login ! So, the only way to get /etc/motd is to do it in the ~.cshrc as I've done below to get once : if ($?prompt) then # Prompt was set... for interactive session/ not process command if !($?BJD_ETC_CSHRC) then if ($?DISPLAY) then source /etc/cshrc endif setenv BJD_ETC_CSHRC 1 endif #... endif > >Brendan Eich >Silicon Graphics, Inc. >brendan@sgi.com This isn't an SGI-only problem, I've noticed this with DEC's Ultrix as well, but had an easier time working the .cshrc since SGI's setup of the DISPLAY is a bit sloppy (sets DISPLAY even thought there's no Xterm... convience for the "console" user to run x programs while in wsh). There may be a solution to this, but I haven't accidently run acrossed it yet. Bernie Duffy. -- Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25007; 26 Feb 90 19:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24874; 26 Feb 90 18:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24766; 26 Feb 90 18:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11064; 26 Feb 90 17:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04405; Mon, 26 Feb 90 13:50:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 20:27:42 GMT From: Robert Skinner Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: executable size Message-Id: <4566@odin.SGI.COM> References: <17280032@acf4.NYU.EDU>, <3747@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17280032@acf4.NYU.EDU>, mcqueen@acf4.NYU.EDU (David M. McQueen) writes: > /* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > > Two ways I have found to reduce the size of executables are: > > 1) compile using shared graphics libraries. As an example (Fortran, but > similar and even greater reductions are possible with C programs): > > With f77 program.f -lfgl -lgl : 652704 bytes > With f77 program.f -lfgl -lgl_s : 453440 bytes > don't forget to link with the shared C library also (-lc_s). This results in an additional savings for any program, graphics or not. Robert Skinner robert@sgi.com Whoa Homer, don't have a cow. - Bart Simpson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03370; 1 Mar 90 7:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03323; 1 Mar 90 7:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03286; 1 Mar 90 6:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05195; 1 Mar 90 5:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13734; Mon, 26 Feb 90 16:01:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 23:42:42 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: PI Problems Message-Id: <51830@sgi.sgi.com> References: <9002220905.aa28986@VAT.BRL.MIL>, <51649@sgi.sgi.com>, <2836@umbc3.UMBC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2836@umbc3.UMBC.EDU>, bernie@umbc3.UMBC.EDU (Bernard J. Duffy) writes: > This isn't an SGI-only problem, I've noticed this with DEC's Ultrix as well, > but had an easier time working the .cshrc since SGI's setup of the DISPLAY > is a bit sloppy (sets DISPLAY even thought there's no Xterm... convience > for the "console" user to run x programs while in wsh). > There may be a solution to this, but I haven't accidently run acrossed it > yet. It seems xterm doesn't start a login shell (one with an initial "-" in its argv[0] basename). Only a login C-shell reads /etc/cshrc and .login, similarly for sh and /etc/profile & .profile. I don't know much about X; perhaps there's an xterm option for logging in (creating a login shell, updating /etc/utmp). Sub-shells and "automatic" shells such as the remote half of rcp uses are not login shells, and should not result in /etc/motd or unintended noise on standard output. Brendan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03370; 1 Mar 90 7:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03323; 1 Mar 90 7:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03297; 1 Mar 90 7:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05218; 1 Mar 90 5:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29053; Mon, 26 Feb 90 20:12:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 90 04:04:38 GMT From: George Hartzell Organization: MCD Biology, University of Colorado, Boulder Subject: Re: PI Problems Message-Id: <17463@boulder.Colorado.EDU> References: <51649@sgi.sgi.com>, <2836@umbc3.UMBC.EDU>, <51830@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <51830@sgi.sgi.com>, brendan@illyria (Brendan Eich) writes: >It seems xterm doesn't start a login shell (one with an initial "-" in >its argv[0] basename). Only a login C-shell reads /etc/cshrc and .login, >similarly for sh and /etc/profile & .profile. I don't know much about X; >perhaps there's an xterm option for logging in (creating a login shell, >updating /etc/utmp). From the xterm man page on my MIPS: -ls This option indicates that the shell that is started in the xterm window be a login shell (i.e. the first character of argv[0] will be a dash, indicating to the shell that it should read the user's .login or .profile). g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09555; 1 Mar 90 11:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09252; 1 Mar 90 11:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08880; 1 Mar 90 10:55 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09900; 1 Mar 90 9:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11152; Mon, 26 Feb 90 15:26:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Feb 90 23:04:55 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: another f77 core dump Message-Id: <1010@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Another program which produces an f77 core dump. Yes, I know rules of use :-) block data junk common/junk/ a end Again the message: Error on line 3 of test.f: junk cannot be a common block name Fatal error in: /usr/lib/fcom - core dumped Signal 139 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #