Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23365; 22 Jan 90 12:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23043; 22 Jan 90 12:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22970; 22 Jan 90 12:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01173; 22 Jan 90 11:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14142; Mon, 22 Jan 90 08:28: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: 22 Jan 90 15:04:53 GMT From: Sam Fulcomer Organization: Brown University Department of Computer Science Subject: Re: A/D & D/A VME board Message-Id: <26196@brunix.UUCP> References: <9001182223.AA00486@tom.dallas.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9001182223.AA00486@tom.dallas.sgi.com> treed%tom.dallas@SGI.COM (Thomas E Reed) writes: > >Hi; > >I'm looking for any input on VME based A-to-D D-to-A boards. Get a copy of the _VMEbus Compatible Products Directory_ from: VMEbus International Trade Organization 10229 N. Scottsdale Rd, Suite E Scottsdale, AZ 85253 602-951-8866   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25766; 22 Jan 90 15:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24169; 22 Jan 90 14:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24074; 22 Jan 90 13:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02244; 22 Jan 90 12:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17377; Mon, 22 Jan 90 09:19: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: 22 Jan 90 16:29:46 GMT From: Dennis O'Neill Subject: Too Many Windows Message-Id: <3715@linus.SLCS.SLB.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We've run into a problem with the window system. If we open lots of windows we reach a threshold and get a messsage that "the winop resource is temporarily not available." It never becomes available again even if all of the extraneous windows are closed. Thanks, Dennis O'Neill ------------------------------------------------------------------------------ *Dennis M. O'Neill oneill@slcs.slb.com (512) 331-3783 * *Schlumberger Lab for CS P.O. Box 200015 Austin, TX 78720-0015* ------------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26123; 22 Jan 90 16:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25570; 22 Jan 90 15:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25496; 22 Jan 90 15:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06859; 22 Jan 90 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26656; Mon, 22 Jan 90 11:50: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: 22 Jan 90 19:14:33 GMT From: Stephen Smith Organization: NASA Ames Research Center, California Subject: NFS and bootparamd Message-Id: <6023@eos.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Could some kind soul enlighten tell me if bootparamd should be running on a diskfull nfs server/client -- all involved machines boot off their own disks? The documentation doesn't talk about server/client configurations. thanks in advance, e-mail preferred: ssmith@eos.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27420; 22 Jan 90 17:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27270; 22 Jan 90 17:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27210; 22 Jan 90 17:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11108; 22 Jan 90 16:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03872; Mon, 22 Jan 90 13:43:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jan 90 21:33:06 GMT From: Tim Hall Organization: Boston University Subject: lrectread on personal iris Message-Id: <50937@bu.edu.bu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a program that saves an image from the SGI console that uses rectread/lrectread. This program works fine on our 220's/240's but on the personal Iris lrectread only seems to save the red channel. The program was compiled on a 240 using the shared libraries. All machines are running 3.2. As a check I used 'snapshot'. On the personal Iris it saved the image incorrectly, but not the same "incorrect" as my program. Snapshot worked fine on a 220 we tried after that. I guess I'm just having Personal problems.... -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27420; 22 Jan 90 17:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27270; 22 Jan 90 17:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab27210; 22 Jan 90 17:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11120; 22 Jan 90 16:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03385; Mon, 22 Jan 90 13:36: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: 22 Jan 90 21:12:07 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: named Message-Id: <724@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9001191505.AA05861@avelon.lerc.nasa.gov> fsfacca@AVELON.LERC.NASA.GOV (Tony Facca) writes: >Mark Callow writes: > >> In article <6094@alvin.mcnc.org>, spl@mcnc.org (Steve Lamont) writes: >>> Our machine goes graphically catatonic when the nameserver dies on us. If a >> >>Both wsh and the NeWS server use the host database access routines documented >>in section 3 of the manual. These routines go to the nameserver if you >>have a /usr/etc/resolv.conf file. There is nothing that wsh or NeWS can >>do to prevent this. >>You can be sure I will modify the NeWS >>server to use this call. It will then try the /etc/hosts file when the >>nameserver fails. [simple script which toggles the network; deleted] Now I am really confused, not because of what was was said but of what I am about to say. For a long time I thought the reason that the nameserver would not work was because it could not resolve 'localhost' to '127.0.0.1 localhost.gsfc.nasa.gov' and for our domain this information was not returned by our Source of Authority (SOA) and placed in 'named.hosts.' So, to use some kind of nameserver I began to use '/usr/etc/resolv.conf'. By luck, one of the nameservers listed in in the file returned '127.0.0.1 localhost.[some-other-domain]'. This caused 'Network Security Violations' at first but I modified the RemoteHostRegistry to allow the answering nameserver access and everything was fine. In other words, 'nslookup localhost' returned '127.0.0.1 localhost.umd.edu' (umd.edu being the foreign domain.) The only other snag in the fishing line is when we can not reach the nameserver due to network problems; back to the tried and true /etc/hosts. That was a little backgound and now for the confusing part. After a while our SOA began to placing 'localhost.gsfc.nasa.gov' in the 'named.hosts' file so that when I was running 'named' the response to 'nslookup localhost' was '127.0.0.1 localhost.gsfc.nasa.gov.' Yeah! This is what I want, I think, right? However, I am still having toubles bringing up windows, occasionally, and I haven't a clue. With '/usr/etc/resolv.conf' ---------------------------------------------- % nslookup localhost Server: dftsrv.GSFC.NASA.GOV Address: 128.183.10.134 Name: localhost.gsfc.nasa.gov Address: 127.0.0.1 Windows always come up except when we cannot reach the secondary nameservers. This mode of operation is ok for the most part except when bridges, repeaters, etc., fail. With '/usr/etc/named' running ------------------------------------------------- % nslookup localhost Server: iris613 Address: 0.0.0.0 Name: localhost.gsfc.nasa.gov Address: 127.0.0.1 Not always, but occasionally enough, we cannot bring up or open any windows. When first starting NeWS we get all the chests but no windows. Here is an extract of the SYSLOG which points to the code in 'init.ps' where the failure is occurring. Once again, we have good network connections because we can ping everyone. From /usr/adm/SYSLOG ---------------------------------------------------------------------------- Jan 22 10:34:22 iris613 grcond[15294]: CIO: getsocketpeername: Can't find name for 127.0.0.1 -- connection refused Jan 22 10:34:22 iris613 grcond[15294]: CIO: Process: 0x1014B88C Error: invalidaccess Jan 22 10:34:22 iris613 grcond[15294]: CIO: Stack: file(?,W,R) file(?,W,R) Jan 22 10:34:22 iris613 grcond[15294]: CIO: Executing: `getsocketpeername' Jan 22 10:34:22 iris613 grcond[15294]: CIO: At: {200 'dict' 'begin' 'initgraphics' 'initmatrix' `newprocessgroup' /ConnectionNumber ConnectionNumber 1 'add' 'store' /ProcessGroup ConnectionNumber 'def' 'exch' 'pop' 'exch' 'pop' 'dup' *`getsocketpeername' /OriginatingHost 'exch' 'def' RemoteHostRegistry OriginatingHost 'known' NetSecurityWanted 'not' 'or' array{10} array{8} 'ifelse' `currentprocess' `killprocessgroup'} ------------------------------------------------------------------------------ What puzzles me is the error message: getsocketpeername: Can't find name for 127.0.0.1 -- connection refused What exactly does this mean and why can't I connect to myself? I think I also need a fairly detailed account of what 'getsocketpeername' is doing and what network resources it needs. What have I overlooked? BTW we had no problems running 'named' prior to 3.2. 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 aa27974; 22 Jan 90 19:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27923; 22 Jan 90 19:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27855; 22 Jan 90 18:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13354; 22 Jan 90 18:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10541; Mon, 22 Jan 90 15:33: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: 22 Jan 90 22:58:43 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Setting yacc internal array sizes? Message-Id: <48798@sgi.sgi.com> References: <6114@alvin.mcnc.org> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6114@alvin.mcnc.org>, palmer@mcnc.org (Thomas C. Palmer) writes: > I've got a problem with SGI's version of yacc. I have a very large > yacc specification that requires use of the "-Nm" option when running > on a Sun 4. This option tells yacc to override the default size for > some internal array. SGI's yacc has no such option and just responds > with the wonderfully helpful message: > > fatal error: out of space, line 581 > *** Error code 1 > > Thanks. The y.output file doesn't have any useful info either. Is > there any way to do this or is yacc totally brain dead on SGI machines? [ ] > Thomas C. Palmer North Carolina Supercomputing Center > Cray Research, Inc. Phone: (919) 248-1117 > PO Box 12732 Arpanet: palmer@ncsc.org Sorry. The compiled-in size for one particular array is 24000 entries. Unfortunately, you have exceeded this maximum. In a grammar I yacc -v'd we see near the end of y.output: ``Optimizer space used: input 5838/24000, output 2171/36000'' The 24000 is the limit you exceeded with your grammar. There are 10 different hard coded limits in yacc. There is no way for a user to override them :-( This is clearly a mistake. They should all be user-adjustable. I will file a bug report. We will get this problem fixed. Sorry for the inconvenience. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28353; 22 Jan 90 21:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28332; 22 Jan 90 21:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28330; 22 Jan 90 21:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15556; 22 Jan 90 21:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04483; Mon, 22 Jan 90 17:56: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: 23 Jan 90 01:54:34 GMT From: Robert Lansdale Organization: University of Toronto, CSRI Subject: Re: Setting yacc internal array sizes? Message-Id: <1990Jan22.205433.24958@jarvis.csri.toronto.edu> References: <6114@alvin.mcnc.org>, <48798@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <48798@sgi.sgi.com> davea@quasar.wpd.sgi.com (David B. Anderson) writes: >In article <6114@alvin.mcnc.org>, palmer@mcnc.org (Thomas C. Palmer) writes: > >Sorry. The compiled-in size for one particular array is 24000 entries. >Unfortunately, you have exceeded this maximum. > >I will file a bug report. We will get this problem fixed. I experienced the same problem when parsing my 3d renderer's parser several months ago. Realizing that there was no switch to expand Yacc's internal tables, I ported the GNU Bison parser over to our Iris/4D and have had no problems since. The only problem encountered during the port was finding an alloca() clone function, which I eventually found in the GNU Emacs source library. Hope this helps --> Rob Lansdale -- Robert Lansdale - (416) 978-6619 Dynamic Graphics Project Internet: lansd@dgp.toronto.edu Computer Systems Research Institute UUCP: ..!uunet!dgp.toronto.edu!lansd University of Toronto Bitnet: lansd@dgp.utoronto Toronto, Ontario M5S 1A4, CANADA   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28533; 22 Jan 90 22:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28257; 22 Jan 90 21:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28224; 22 Jan 90 20:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14973; 22 Jan 90 20:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA02423; Mon, 22 Jan 90 17:19: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: 22 Jan 90 23:37:27 GMT From: Paul Mielke Organization: Silicon Graphics, Inc. Subject: Re: syslogd (again) Message-Id: <3081@odin.SGI.COM> References: <10353@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10353@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: > > > after cobbling together a scheme to syslog kernel messages > (which works just fine and dandy), i thought to try and > get disk errors mailed to me. i changed my /etc/syslog.conf to > > *.debug /usr/adm/SYSLOG > *.debug andrew > > hahahahaha!!! > two copies of every message goes to /usr/adm/SYSLOG and nothing gets mailed to me. > can someone from sgi tell me what the heck IS SUPPOSED to work? > the whole syslog system as described in the man pages appears to be > an editing proof for 3.3 or some other release. of course, if we > had the code to this piece of dog's droppings we could figure it out. The 3.2 version of syslog doesn't provide the ability to send mail. The second line of your proposed syslog.conf above will cause the moral equivalent of 'write andrew' for each message that is selected by the first field. Needless to say, this is not the same thing as 'mail andrew'. In a subsequent release, we will add the ability to specify a pipeline as the destination to which messages can be delivered. With that software, you will be able to say: *.debug /usr/adm/SYSLOG *.debug |mail andrew and get the messages mailed to you, if that is what you want. Paul Mielke paulm@sgi.com Advanced Systems Division (415) 962-3447 Silicon Graphics, Inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02321; 23 Jan 90 12:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01349; 23 Jan 90 12:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01276; 23 Jan 90 11:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02423; 23 Jan 90 11:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22143; Tue, 23 Jan 90 08:14: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: 22 Jan 90 22:02:52 GMT From: john howell Organization: Deere & Co. Technical Center, Moline,IL Subject: Optical Drive for SGI? Message-Id: <155@suntc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone successfully hooked up a Optical Disk Drive (Eraseable) to their SGI 4D ? How does it work? What about speed? Thanks. ======================================================================== John Howell uucp: uunet!suntc!jrh Deere & Company MCImail: 360-4047 Technical Center CompuServe: [76666,2505] 3300 River Drive FAX: (309)765-3807 Moline, IL 61265 Voice: (309)765-3784 ========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23825; 24 Jan 90 18:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23392; 24 Jan 90 18:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23299; 24 Jan 90 17:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20665; 24 Jan 90 17:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA22577; Wed, 24 Jan 90 14:19:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jan 90 09:29:11 GMT From: "M.Gajhede Dept. Phys. Chem. HCO, Copenhagen DK" Organization: Niels Bohr Institute and Nordita, Copenhagen Subject: printing on vax running cmu tcpip ? Message-Id: <313@nbivax.nbi.dk> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thanks for the many responses to my elementary problems. Is it possible to print files from an iris on a vax running cmu tcpip ? I tried to set it up just using the toolbox but perhaps not surprising the vax refused connect. Again help would be appreciated. Michael Gajhede, Dept. Phys. Chem. Copenhagen University, Denmark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29644; 23 Jan 90 1:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29611; 23 Jan 90 1:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab29515; 23 Jan 90 1:28 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa19634; 23 Jan 90 1:17 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4194; Tue, 23 Jan 90 01:17:14 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 23 Jan 90 07:16:37 Date: Tue, 23 Jan 90 07:16:54 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Examining vmcore.n/unix.n To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <9001230117.aa19634@SMOKE.BRL.MIL> Hallo, two nights before, our 4D/70-GT went down, leaving a system-core in the swap partition. On rebooting the files vmcore.0 and unix.0 have been placed in /usr/adm/crash. As the crash left no trace in the syslog files, I am curious how to get the reason for the crash from this two files? I've found no hints in the documentation. Can anybody tell me how to examine the vmcore? Under which circumstances can I find the reason for the crash in SYSLOG? Thanks in advance Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06283; 23 Jan 90 16:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05617; 23 Jan 90 15:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05473; 23 Jan 90 15:27 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09823; 23 Jan 90 15:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12716; Tue, 23 Jan 90 11:53: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: 23 Jan 90 18:33:35 GMT From: "Loren (Buck" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center Subject: Re: named Message-Id: <730@dftsrv.gsfc.nasa.gov> References: <724@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <724@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: [[[bunch of stuff deleted]]] > >Not always, but occasionally enough, we cannot bring up or open any windows. >When first starting NeWS we get all the chests but no windows. Here is >an extract of the SYSLOG which points to the code in 'init.ps' where >the failure is occurring. Once again, we have good network connections >because we can ping everyone. We have been having similar problems, both before and after upgrade to 3.2, but it is worse after. We are part of the same domain as John, but our connection to our nameserver (dftsrv.gsfc.nasa.gov) is not as reliable as John's. Dftsrv is a Sun 3/280 and is running vanilla BIND from Berkeley (the RFC compliant version). I am not sure what our secondary name server is. Last November SGI made some suggestions that we needed to make changes to /etc/rpc on dftsrv, but the adminstrator of dftsrv said there was no equivalent file to change. I believe John's machine is a 4D/80, and mine is a 4D/20. 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 aa07226; 23 Jan 90 16:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05617; 23 Jan 90 15:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05297; 23 Jan 90 15:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09142; 23 Jan 90 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11687; Tue, 23 Jan 90 11:42: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: 23 Jan 90 18:10:49 GMT From: David Parkins Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Re: sendmail configuration file Message-Id: <9593@batcomputer.tn.cornell.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have recently tried to add our Personal iris to the mail world via sendmail. It seems that much of the stuff that SGI implies will be on the system. What I need is a copy of someones sendmail.cf file, preferably a university site similiar to ours at Cornell. Also for all you sendmail guru's out there: I have tried using sendmail.cf files from some local sun's and have been told by the sendmail that recieved files lack the begining "from" line. Any insight into this would be appreciated (sic). Send E-mail only parkins@tcgould.tn.cornell.edu Thanks in advance, dave p.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08457; 23 Jan 90 19:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08238; 23 Jan 90 18:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08201; 23 Jan 90 18:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15484; 23 Jan 90 18:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA26813; Tue, 23 Jan 90 15:04: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 Jan 90 22:56:28 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: named (solution) Message-Id: <732@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In a previous posting I wrote: >Not always, but occasionally enough, we cannot bring up or open any windows. >When first starting NeWS we get all the chests but no windows. and >What puzzles me is the error message: > getsocketpeername: Can't find name for 127.0.0.1 -- connection refused Thanks to arc%thyme.wpd@sgi.com I think I have a good working named. First, In the named.boot file I had: secondary 0.0.127.IN-ADDR.ARPA named.local where it should have read: primary 0.0.127.IN-ADDR.ARPA named.local By the way, my named.local file looks like: -------------------- cut ---------------------------------- $ORIGIN 0.127.IN-ADDR.ARPA. 0 IN SOA dftsrv.gsfc.nasa.gov. tomc.dftsrv.gsfc.nasa.gov. ( 21 3600 300 3600000 86400 ) IN NS dftsrv.gsfc.nasa.gov. $ORIGIN 0.0.127.in-addr.arpa. 1 IN PTR localhost. IN PTR localhost.0.0.127.IN-ADDR.ARPA. -------------------- cut ---------------------------------- Note: It can also look like the 'localhost.rev' file that SGI supplies so long as you change the SOA line. Second, In /usr/etc/resolv.conf I commented all nameserver lines out and left only the domain specification. From the explaination I recieved, 'getsocketpeername' uses 'resolv.conf', even when 'named' is running. It looks at the domain entry to resolve the domain. I was renaming 'resolv.conf' to something else whenever I wanted only 'named' to answer, because I thought they were mutually exclusive. What you do not want to do is have nameserver entries in 'resolv.conf' when you are running 'named.' Actually, you can have one entry; all the rest are ignored. # Try ourself nameserver 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa08996; 23 Jan 90 21:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08893; 23 Jan 90 20:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08845; 23 Jan 90 20:44 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18277; 23 Jan 90 20:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04454; Tue, 23 Jan 90 16:59: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: 24 Jan 90 00:51:01 GMT From: frederick arnold Organization: University of Delaware -- 040 Smith Sun Lab Subject: Other machines hooked to SGI Message-Id: <9011@nigel.udel.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, We're a theoretical chemistry laboratory with an Iris 4D/220GTX that would like to connect either a terminal or largepc/small workstation to our machine. The purpose being to allow greater access to the Iris for those people who's needs to not immediately require interactive 3-D graphics. We would prefer that the second machine be etherneted and have some graphics capability of its own, although those requirements are negotiable. Finally, our budget forbids a PI (unless SGI feels real generous that day). What this rather dry introduction leads to, is that we would like to know what any of you have done when you require extra access to a primary machine. We would like to know what sort of device you connected, how you selected that device and what your opinions of it are now. Thank you for any opinions you may have. P.S. I know the rep is not the best, but how well behaved are the new HP/Apollo 2500 series machines? Has anybody had any experience with them, as they seem to be fitting into our price/performance niche. -Fred /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ |God Does Not Play Dice Frederick P. Arnold Jr, | | With the Universe. University of Delaware | | A. Einstein Department of Chemistry | | Newark, DE 19716 | |You Should Not Presume | | To Tell God What to Do. ARNOLD@FREEZER.IT.UDEL.EDU | | N. Bohr | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Any opinions expressed herein are solely mine and are not shared by my employer. In fact, Very Few of my opinions seem to be shared by my employer.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10343; 24 Jan 90 1:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10241; 24 Jan 90 1:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10210; 24 Jan 90 1:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24244; 24 Jan 90 0:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21806; Tue, 23 Jan 90 21:40: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: 23 Jan 90 19:30:45 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: named Message-Id: <3122@odin.SGI.COM> References: <724@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <724@dftsrv.gsfc.nasa.gov>, merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: > What puzzles me is the error message: > getsocketpeername: Can't find name for 127.0.0.1 -- connection refused > > What exactly does this mean and why can't I connect to myself? > I think I also need a fairly detailed account of what 'getsocketpeername' is > doing and what network resources it needs. What have I overlooked? getsocketpeername calls getpeername(3) (which must be returning 127.0.0.1) followed by gethostbyaddr(3) to find the name of the host that is trying to connect. The message is printed when gethostbyaddr returns null. A PostScript "invalid access" error is also flagged at this point causing the print-out you see in SYSLOG. "connection refused" indicates that the news server is refusing the connection. I can think of 2 reasons why this call would fail: access to the name server fails or the database doesn't have an entry for a host with the given address. (Since gethostbyaddr isn't a system call it isn't clear that errno would have any useful information.) > > BTW we had no problems running 'named' prior to 3.2. > Guess what, IRIX didn't have nameserver support until 3.2. -- 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 aa10762; 24 Jan 90 3:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10713; 24 Jan 90 3:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10681; 24 Jan 90 2:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26273; 24 Jan 90 2:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28900; Tue, 23 Jan 90 23:37:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jan 90 00:24:56 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: correction on named, 3.2 etc. Message-Id: <3135@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've just found out that name server support was released as early as 3.1 Rev C. The canonicalizehostname operator was added to 4sight in 3.2. The gethostbyname that it does (especially the one 4Sight does at start up to get its hosts official name) seems to be call that fails most with the nameserver. -- 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 aa19787; 24 Jan 90 15:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18496; 24 Jan 90 14:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18323; 24 Jan 90 14:08 EST Received: from BU.EDU by SMOKE.BRL.MIL id aa12388; 24 Jan 90 13:10 EST Received: by BU.EDU (1.97) Wed, 24 Jan 90 13:10:51 EST Received: by adt.uucp (3.2/SMI-3.2) id AA27051; Tue, 23 Jan 90 15:07:32 EST Date: Tue, 23 Jan 90 15:07:32 EST From: james cerrato Message-Id: <9001232007.AA27051@adt.uucp> To: info-iris@BRL.MIL Subject: cartridge tape r/w compatability We have 4D20 4D70, and 3000 IRIS workstations, and I'm trying to determine which machines can read tapes that were written on which other machines. In the Owners Manual documentation for the 3000 and the 4D70 I found detailed specifications of the tape drive that were identical, and in practice I found they could read each others tapes. Unfortunately I could not find any documentation like this for the Personal Iris, does anyone know if it exists? I found that I can not read tapes written on the P.I. using the 4D70. I also looked at the tar man entry to see if there were any flags that control the data format that might allow the tape to be read but I had no success. If someone could describe the tape compatability story I would greatly appreciate it.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21802; 24 Jan 90 16:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21068; 24 Jan 90 16:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20885; 24 Jan 90 15:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17102; 24 Jan 90 15:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14092; Wed, 24 Jan 90 12:26: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 Jan 90 19:49:08 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: named (solution) Message-Id: <48961@sgi.sgi.com> References: <732@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <732@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: >In a previous posting I wrote: >>Not always, but occasionally enough, we cannot bring up or open any windows. >>When first starting NeWS we get all the chests but no windows. >and >>What puzzles me is the error message: >> getsocketpeername: Can't find name for 127.0.0.1 -- connection refused Unfortunately, the "connection refused" error message is wrong in this case. It's probably due to a transient failure to contact the server for the 127.1 address -- see below. >Thanks to arc%thyme.wpd@sgi.com I think I have a good working named. > >First, In the named.boot file I had: > >secondary 0.0.127.IN-ADDR.ARPA named.local > >where it should have read: > >primary 0.0.127.IN-ADDR.ARPA named.local > >By the way, my named.local file looks like: >-------------------- cut ---------------------------------- >$ORIGIN 0.127.IN-ADDR.ARPA. >0 IN SOA dftsrv.gsfc.nasa.gov. tomc.dftsrv.gsfc.nasa.gov. ( > 21 3600 300 3600000 86400 ) > IN NS dftsrv.gsfc.nasa.gov. >$ORIGIN 0.0.127.in-addr.arpa. >1 IN PTR localhost. > IN PTR localhost.0.0.127.IN-ADDR.ARPA. >-------------------- cut ---------------------------------- >Note: It can also look like the 'localhost.rev' file > that SGI supplies so long as you change the SOA line. Assuming iris613 is running named, localhost.rev should look like -------------------- cut ---------------------------------- @ IN SOA iris613.gsfc.nasa.gov. tomc.dftsrv.gsfc.nasa.gov. ( 21 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS iris613.gsfc.nasa.gov. 1 IN PTR localhost. -------------------- cut ---------------------------------- (The e-mail address "tomc.dftsrv.gsfc.nasa.gov." in the SOA line might not be appropriate.) >Second, In /usr/etc/resolv.conf I commented all nameserver lines >out and left only the domain specification. > > >From the explaination I recieved, 'getsocketpeername' uses 'resolv.conf', >even when 'named' is running. It looks at the domain entry to resolve >the domain. I was renaming 'resolv.conf' to something else >whenever I wanted only 'named' to answer, because I thought >they were mutually exclusive. What you do not want to do is have >nameserver entries in 'resolv.conf' when you are running 'named.' Actually the "domain" in resolv.conf is for gethostbyname(3N)'s benefit; gethostbyaddr(3N) doesn't use it. getsocketpeername calls gethostbyaddr to convert the peer's address into a name. With named running as a primary server for 0.0.127.IN-ADDR.ARPA, you'll always be able to create windows. If the hostname in /etc/sys_id is not the machine's "fully qualified domain name" (e.g., iris613.gsfc.nasa.gov), then put "domain gsfc.nasa.gov" in /usr/etc/resolv.conf. If you're running YP, the domain in resolv.conf can be unrelated to your YP domain (YP uses /usr/etc/yp/ypdomain). >Actually, you can have one entry; all the rest are ignored. ># Try ourself >nameserver 0 You can have up to 3 "nameserver" entries in resolv.conf. No entries means query the server on the local machine or look at /etc/hosts if it's not running. "nameserver 0" means query the local server. If named is running on your machine, the others won't be queried. If it isn't running, the others will be queried after a time-out. Note: there are plans to improve BIND documentation in the next IRIX release.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23146; 24 Jan 90 17:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22750; 24 Jan 90 17:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22619; 24 Jan 90 17:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19651; 24 Jan 90 16:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19433; Wed, 24 Jan 90 13:35: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: 24 Jan 90 18:14:42 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: 4D/25 Turbo Performance Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am in need of performance numbers for the graphics end of a 4D/25 Turbo to include in a bid spec. Does anyone have the (3D vectors/second) and (Gouraud-shaded polygons/second) numbers handy? I can't get any of my sales folks on the phone, and this needs to go out pretty quickly..... Thanks, -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24250; 24 Jan 90 18:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23146; 24 Jan 90 17:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23137; 24 Jan 90 17:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20504; 24 Jan 90 17:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21651; Wed, 24 Jan 90 14:06:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jan 90 21:23:40 GMT From: Mark VandeWettering Organization: Princeton University Subject: Window Manager Crashes Message-Id: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have had this problem off and on for a while, it seems really transient, but a new program of mine is showing symptoms, so I thought I might post a request for help. A program of mine queues up LEFTMOUSE, MOUSEX and MOUSEY events, and processes them in a loop which looks schematically like... for (;;) { while (qtest()) { switch(qread(val)) { ... } DrawBunchesOfStuff() ; while (qtest() == 0) sginap(10) ; /* prevent a hard busy wait */ } After running for a while, the window manager crashes with the following message: ----- fifo_intr: GM TIMEOUT (FIFO still > half full)! The window manager was killed by signal 15. ----- I imagine this is caused by having to full of a device queue, but I shouldn't be getting that many events. Does anyone have any ideas/suggestions? Thanks for you time and effort.... Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26032; 24 Jan 90 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25878; 24 Jan 90 20:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25863; 24 Jan 90 19:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22402; 24 Jan 90 19:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00260; Wed, 24 Jan 90 16:18: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: 24 Jan 90 22:28:03 GMT From: Bill Lasher Organization: Penn State University Subject: workspace/file transfer Message-Id: <90024.172803W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a way using the workspace/file transfer for a user to append an archive to an existing archive on tape? We're currently using tar archive, and it appears that a second archive will just re-write over the first.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27869; 25 Jan 90 0:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27278; 24 Jan 90 23:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27272; 24 Jan 90 23:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26682; 24 Jan 90 23:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15470; Wed, 24 Jan 90 20:19: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: 25 Jan 90 04:14:32 GMT From: Tim Hall Organization: Boston University Subject: Re: Window Manager Crashes Message-Id: <51074@bu.edu.bu.edu> References: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13273@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU () writes: > >I have had this problem off and on for a while, it seems really transient, >but a new program of mine is showing symptoms, so I thought I might post > >After running for a while, the window manager crashes with the following >message: > >The window manager was killed by signal 15. >----- I've run into three different bugs that cause this problem....... 1) Too many matrix push/pops. Meaning more pops than pushes or more than 32 ( matrix stack size ) pushes. 2) Corrupted matrix stack. Meaning NaN values in the top matrix of the matrix stack. 3) Bad normal vectors. Meaning NaN values in the vector given to the "n" routine. This makes me wonder what would happen with a NaN value in the point given to a "v" routine, but I haven't tried it out. Good luck... -Tim tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05338; 25 Jan 90 12:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04646; 25 Jan 90 11:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04515; 25 Jan 90 11:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13237; 25 Jan 90 11:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27899; Thu, 25 Jan 90 08:13:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jan 90 23:38:14 GMT From: Jesse Rendleman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Other machines hooked to SGI Message-Id: <3180@odin.SGI.COM> References: <9011@nigel.udel.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Have you thought of using a diskless Personal Iris? Not being a sales person, I don't know much about prices, but I know these are substantially cheaper than a "diskfull" personal iris. This would give you a consistant interface to work under, and let you use DGL for distributed graphics. The only drawback would be that it would require some of the diskspace on your 220 be dedicated to the diskless machine.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02008; 25 Jan 90 8:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01599; 25 Jan 90 8:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01422; 25 Jan 90 8:21 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa07460; 25 Jan 90 8:02 EST Received: Thu, 25 Jan 90 08:03:48 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 25 Jan 90 08:03:48 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9001251603.AA23223@aero4.larc.nasa.gov> To: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!stat!stat.fsu.edu!mccalpin@tut.cis.ohio-state.edu Subject: Re: 4D/25 Turbo Performance Cc: info-iris@BRL.MIL These are the specs. I have: 4D/25G Std.: 90K V/s, 4.5K P/s 4D/25G Turbo: 200K V/s, 20K P/s (V/s= 10 pixel,connected, full 24bit color, arbitrary orientation.) (P/s = 10x10 (100 pixel), full 24bit color, Lighted, Gouraud-shaded, Z-buffered (except for B), arbitrary orientation.) -- 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 aa03960; 25 Jan 90 10:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02597; 25 Jan 90 9:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02182; 25 Jan 90 8:57 EST Received: from relay.nswc.navy.mil by SMOKE.BRL.MIL id aa08848; 25 Jan 90 8:45 EST Date: Thu, 25 Jan 90 08:46:08 est From: mberger@relay.nswc.navy.mil To: adt!james@relay, info-iris@BRL.MIL Subject: Re: cartridge tape r/w compatability Message-ID: <9001250845.aa08848@SMOKE.BRL.MIL> I believe the 3000 and 4D series machines have low density drives, and the P.I. is high density. This explains why you can read a tape on the P.I. that was written on the 3000 or 4D, but not vice-versa. I remember that there was a tar option which allowed you to specify the density (in 3.1) but we could not get it to work. We concluded that this was an option you had to purchase. Looking through our 3.2 tar doc. I don't see the option.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04646; 25 Jan 90 11:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04353; 25 Jan 90 11:32 EST Received: from vat.brl.mil by VMB.BRL.MIL id aa04233; 25 Jan 90 11:14 EST Date: Thu, 25 Jan 90 11:09:03 EST From: "John R. Anderson" (VLD/ASB) To: info-iris@BRL.MIL Subject: Re: cartridge tape r/w compatability Message-ID: <9001251109.aa24184@VAT.BRL.MIL> Page 5-141 of the "Personal Iris Owner's Guide" has a brief discussion about the tape drive. It is a high density drive that can read the lower density tapes, but not write them. So tapes written on the low density drives can be read in the P.I. drive, but not vice-versa. -John   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06303; 25 Jan 90 13:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06132; 25 Jan 90 13:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05924; 25 Jan 90 13:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15686; 25 Jan 90 12:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03950; Thu, 25 Jan 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: 25 Jan 90 14:54:58 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Window Manager Crashes Message-Id: <3203@odin.SGI.COM> References: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13273@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU () writes: > >I have had this problem off and on for a while, it seems really transient, >but a new program of mine is showing symptoms, so I thought I might post >a request for help. > >A program of mine queues up LEFTMOUSE, MOUSEX and MOUSEY events, and >processes them in a loop which looks schematically like... > for (;;) { > while (qtest()) { > switch(qread(val)) { > ... > } > DrawBunchesOfStuff() ; > while (qtest() == 0) > sginap(10) ; /* prevent a hard busy wait */ > } >After running for a while, the window manager crashes with the following >message: >----- >fifo_intr: GM TIMEOUT (FIFO still > half full)! >The window manager was killed by signal 15. >----- >I imagine this is caused by having to full of a device queue, but I shouldn't >be getting that many events. Does anyone have any ideas/suggestions? what machine is this on/release of SW are you running? i have always seen generation of the "fifo_intr..." message boil up into a full-fledged bonafide software change request (SCR)--i.e. bug--which gets pretty fast attention/turnaround by engineering. i recommend you call the hotline, with yer machine's serial number in hand, UNLESS yer still running some version of 3.1*. IF yer already onto 3.2, then we need to have a call to track against which we can log the bug and engender the appropriate solution thru the most common channels. -- daveus rattus yer friendly neighborhood ratman "Ignacio Ellacuria and Martin Baro [Jesuit rector and vice rector] have fallen. We will continue killing communists." San Salvador, 11/17: boasting from a sound truck of the army's First Brigade   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06521; 25 Jan 90 14:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06303; 25 Jan 90 13:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06254; 25 Jan 90 13:28 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16069; 25 Jan 90 13:02 EST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0445; Thu, 25 Jan 90 13:02:24 EST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3684; Thu, 25 Jan 90 16:23:14 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 4220; Thu, 25 Jan 90 16:23:12 GM Via: UK.AC.OX.VAX; 25 JAN 90 16:04:30 GMT Date: Thu, 25 JAN 90 16:03:59 GMT From: HCART%VAX.OXFORD.AC.UK@cunyvm.cuny.edu To: INFO-IRIS@BRL.MIL Subject: 14 months ... and still waiting for manuals. Message-ID: <9001251302.aa16069@SMOKE.BRL.MIL> We bought a 3130 in December 1988, with the Fortran option, and have been running fairly problem-free since. Unfortunately, since the m/c was essentially ex-demo, it came with one manual plus a few pages, instead of the round dozen we were expecting. It took about 6 months to get the user manuals - but without Fortran. Since last summer I have been trying, unsuccessfully, to get hold of the Fortran documentation by giving gently prods to SGI and Polygen in the UK. We can run F77, but have yet to use the graphics option through Fortran. We are by no means large buyers of SG boxes, but have several in the department and (perhaps) a few more to come. Thus we have less clout than we would like, but still feel software without documentation is pretty poor - particularly after 14 months. Can any of you SGI people Stateside help? The main talent of the locals here seems to be being nice on the phone. Thanks for any help. Hugh. **************************************************************************** From: Dr. Hugh M. Cartwright Physical Chemistry Laboratory, Oxford University, South Parks Road, OXFORD, U.K. OX1 3QZ. Telephone: Oxford (0865)-275483 (direct line), (0865)-275400 (reception) Fax: Oxford (0865)-275410 JANET: HCART@uk.ac.oxford.vax BITNET: HCART@uk.ac.oxford.vax@ukacrl or HCART%VAX.OXFORD.AC.UK@CUNYVM.CUNY.EDU or HCART%vax.oxford.ac.uk@nss.ns.ucl.ac.uk ******************************************************(series no 000)*******   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06885; 25 Jan 90 14:33 EST Received: by VMB.BRL.MIL id ac06642; 25 Jan 90 14:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02903; 25 Jan 90 9:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02669; 25 Jan 90 9:11 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa09169; 25 Jan 90 8:53 EST Received: Thu, 25 Jan 90 08:55:04 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 25 Jan 90 08:55:04 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9001251655.AA23413@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Re: cartridge tape r/w compatability This subject has come up before, it sounds like your PI has a 150Mb tape drive. If you take a 600ft cartridge and use it in a 3000 or 4D/70 you get 60Mb on it and you get ~150Mb on a 4D/20,200, etc, if they have the newer drive. I know tapes written with the old tape drives can be read by the new machines, but I don't think it works the other way around. That is one of the reasons we are getting a 60Mb tape drive for our new machine, so we can transfer files between machines more easily. I was told all SGI distrubution and update tapes use the 60Mb format, so we shouldn't have an problems as far as that is concerned. I plan to use Magnetic Optical disks for back ups, instead of cartridges. -- Brent   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07619; 25 Jan 90 15:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07118; 25 Jan 90 14:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06978; 25 Jan 90 14:39 EST Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa17892; 25 Jan 90 14:06 EST Received: from uoguelph.netnorth (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57895; Thu, 25 Jan 90 13:58:18 EST Received: by UOGUELPH (Mailer R2.02A) id 6887; Thu, 25 Jan 90 13:56:17 EST Date: Thu, 25 Jan 90 13:38:23 EST From: "Len Zaifman UoGuelph (519)824-4120 xt 6566" Subject: Array boundary checking & Fortran <> C translators To: info-iris Message-Id: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca> Two problems : 1 ) In FORTRAN we compile as follows : f77 -O -check_bounds - o object_file source.f where source.f has an array x dimensioned real x(10) . If I run object_file for iterations <= 10 , the program works. If I run object_file for iterations > 10 , instead of getting an error message or warning of some type about where the problem occurred , I get a core dump. What gives ??? does check_bounds not work in f77 ???? We found this on a PI and a 120 , both running IRIX 3.2 . In addition, is there an array boundary flag in cc ?? If so, I have missed it in the documentation. How does one check that one does not iterate beyond an array boundary, or at least get a runtime error message if that occurs , in C ??? 2 ) I have never heard of on, but is there a C to FORTRAN translator available on the SGI machines ??? We have a group writing some C code that others in the same group want to work with in FORTRAN. I am not highly hopeful that I can find anything that would help , short of encouraging the programmers to be bilingual , but I would appreciate knowing of the existence of such a beast. Regards Len Zaifman Len Zaifman Information Technology Coordinator,College of Physical and Engineering Science Department of Computing Services University of Guelph Guelph,Ontario. (519)821-4120 xt 6566 email : LeonardZ@VM.UOGUELPH.CA   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08091; 25 Jan 90 15:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07779; 25 Jan 90 15:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07641; 25 Jan 90 15:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19389; 25 Jan 90 14:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11566; Thu, 25 Jan 90 11:39: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: 25 Jan 90 15:23:26 GMT From: Urs Meyer Organization: University of Zurich, Department of Computer Science Subject: group permissions and rdist (help needed) Message-Id: <1990Jan25.152326.9959@gorgo.ifi.unizh.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, I've got a problem with group permissions on directories. We have several administrators on our irises, most of them maintaining application software only, i.e., they are usually not superusers. Most of the software is installed in /usr/local/... zeus% ls -lgF /usr/local drwxrwxr-x 2 root local 512 Jan 23 17:16 bin/ drwxrwxr-x 10 root local 512 Dec 28 17:31 catman/ drwxrwxr-x 2 root local 512 Sep 13 11:39 doc/ drwxrwxr-x 3 root local 512 May 30 1989 include/ drwxrwxr-x 6 root local 512 Jan 20 14:40 lib/ drwxrwxr-x 24 root local 512 Jan 23 17:08 src/ Everybody in group "local" is thus allowed to install binaries in /usr/local/bin after he issued a "newgrp local" command. So far, so good. Now, when one tries to install some files using rdist from another machine, there are permission problems, since the users default group is not "local": (zeus is a 4D/70GT running 3.1D and gorgo is a VAX running 4.3BSD. Yes, there is a symlink for /usr/ucb on the iris): gorgo% rdist -m zeus foo updating host zeus installing: /usr/local/lib/foo rdist: zeus:/usr/local/lib/rdista03667: Permission denied To me it seems as if zeus's rdist is running using the users default group id as defined in /etc/passwd. The question: is there anything I can do to allow users in group "local" ------------ to install their stuff with rdist? BTW: There are no problems doing such things the other way 'round, since 4.3BSD grants any member of a group all permissions without any further action. On Suns (4.0.3) setting the s-bit on group execution for directories seems to have the intended effect. Urs Meyer University of Zurich, Dept of Computer Science, Multimedia Lab, CH-8057 Zurich meyer@ifi.unizh.ch [ @relay.cs.net ], {uunet,...}!mcvax!chx400!unizh!meyer   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09490; 25 Jan 90 18:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09323; 25 Jan 90 17:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09282; 25 Jan 90 17:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24675; 25 Jan 90 16:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19060; Thu, 25 Jan 90 13:39: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: 25 Jan 90 19:50:58 GMT From: "Gavin A. Bell" Subject: Re: Window Manager Crashes Message-Id: <3212@odin.SGI.COM> References: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL markv@gauss.Princeton.EDU (Mark VandeWettering) writes: >A program of mine queues up LEFTMOUSE, MOUSEX and MOUSEY events, and >processes them in a loop which looks schematically like... > for (;;) { > while (qtest()) { > switch(qread(val)) { > ... > } > DrawBunchesOfStuff() ; > while (qtest() == 0) > sginap(10) ; /* prevent a hard busy wait */ > } Well, I hope somebody else can give you some idea of why you are crashing; the problem doesn't look like you are getting too many events (the graphics FIFO is where all of your drawing commands are sent, and when the graphics system gets hosed you are likely to get the message you are getting). I'm mainly writing this to suggest a 'better' way of coding your application. I mainly object to the sginap'ping your application is doing. I always code things this way: for(;;) { if (I_should_be_constantly_redrawing_because_I'm_rotating_or _something) { while (!qtest()) DrawBunchesOfStuff(); } readinput: dev = qread(&val); swith(dev) { ... } if (qtest()) goto readinput; } It does have a goto (I hope I don't start a When is it Proper to use Gotos war...), but there is no busy loop. And, if the application doesn't need to redraw, it can set a flag and it will block at the qread(). --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09741; 25 Jan 90 18:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09490; 25 Jan 90 18:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09440; 25 Jan 90 17:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25799; 25 Jan 90 17:39 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21015; Thu, 25 Jan 90 14:09: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: 25 Jan 90 19:13:13 GMT From: Jeremy Nussbaum Organization: Prime Computer, Bedford, Ma. Subject: killing background processes on logout Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am using the monthd background demon from the month8 package to remind me about appointments. What do I need to do so that it will automatically be terminated when my login process terminates? Note that this is slightly different than "when I logout", since the window manager can terminate my csh sessions without the .logout file being executed. Is there a signal that is sent to background processes when the original process terminates? Does the supplied csh do it anyway? Any information is appreciated. -- Jeremy Nussbaum (jeremy@jeremy.prime.com) Prime Computer/2 Crosby Drive MS 16-2 /Bedford, Ma. 01730 (617)275-1800 x6745 Standard Disclaimer: The opinions expressed are mine and not my employer's.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09924; 25 Jan 90 19:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac09741; 25 Jan 90 18:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09723; 25 Jan 90 18:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26796; 25 Jan 90 18:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA24199; Thu, 25 Jan 90 14:59: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 Jan 90 21:08:07 GMT From: Thant Tessman Organization: Silicon Graphics, Inc. Subject: Re: Window Manager Crashes Message-Id: <3218@odin.SGI.COM> References: <3212@odin.SGI.COM>, <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3212@odin.SGI.COM>, gavin@krypton.sgi.com (Gavin A. Bell) writes: > I'm mainly writing this to suggest a 'better' way of coding your > application. I mainly object to the sginap'ping your application is > doing. I always code things this way: > [example deleted] > It does have a goto (I hope I don't start a When is it Proper to use > Gotos war...), but there is no busy loop. And, if the application > doesn't need to redraw, it can set a flag and it will block at the > qread(). > Gavin, I'm ashamed. Why not: for(;;) { if (qtest() || !busy) { switch(dev = qread(&val)) { /* process input */ } } draw_bunches_o_stuff(); } thant   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10145; 25 Jan 90 19:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10020; 25 Jan 90 19:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09993; 25 Jan 90 19:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27645; 25 Jan 90 18:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28412; Thu, 25 Jan 90 15:58: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 Jan 90 22:16:42 GMT From: John Eisenman Organization: Silicon Graphics, Inc. Subject: Re: workspace/file transfer Message-Id: <3221@odin.SGI.COM> References: <90024.172803W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90024.172803W0L@PSUVM.BITNET>, W0L@PSUVM.BITNET (Bill Lasher) writes: > Is there a way using the workspace/file transfer for a user to append an > archive to an existing archive on tape? We're currently using tar archive, > and it appears that a second archive will just re-write over the first. The shoft answer is no. However, if you are at all handy with shell scripts (and know a bit about tar) you should be able to create a modified version of the tar archiver that does what you want. The documentation should specify that each user can add to the transfer devices available to them by placing shell scripts in their ~/.workspace/localTransferLinks directory. The original tar archiver is located in /etc/transferDevice/ and is called tarArchive. The easiest thing to do would be to make a copy of tarArchive, place it in your locatTransferLinks directory and then modify this to do an append, rather than rewriting the tape. Than, as a user, you can select one device or the other depending upon whether you wanted to create a new tape or append to an existing tape.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10349; 25 Jan 90 20:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10292; 25 Jan 90 20:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10237; 25 Jan 90 19:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28603; 25 Jan 90 19:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01110; Thu, 25 Jan 90 16:38: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: 25 Jan 90 23:24:30 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Window Manager Crashes Message-Id: <3226@odin.SGI.COM> References: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13273@phoenix.Princeton.EDU>, markv@gauss.Princeton.EDU (Mark VandeWettering) writes: > > A program of mine queues up LEFTMOUSE, MOUSEX and MOUSEY events, and > processes them in a loop which looks schematically like... > > for (;;) { > while (qtest()) { > switch(qread(val)) { > ... > } > > DrawBunchesOfStuff() ; > > while (qtest() == 0) > sginap(10) ; /* prevent a hard busy wait */ > } > > After running for a while, the window manager crashes with the following > message: > > ----- > fifo_intr: GM TIMEOUT (FIFO still > half full)! > > The window manager was killed by signal 15. > ----- > > I imagine this is caused by having to full of a device queue, but I shouldn't > be getting that many events. Does anyone have any ideas/suggestions? This has nothing to do with input. Something that you are doing in DrawBunchesOfStuff() hung the graphics master (GM) and a timeout was triggered. The kernel then proceeds to take down all graphics processes, (including the 4sight server) by sending them signal 15, so that it can reset the GM. It could be a problem in your code or it could be a bug in the GL. -- 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 aa10588; 25 Jan 90 21:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10478; 25 Jan 90 21:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10460; 25 Jan 90 20:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29065; 25 Jan 90 20:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01619; Thu, 25 Jan 90 16:46: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: 25 Jan 90 14:19:02 GMT From: Mark Andrews Organization: Alias Research Inc., Toronto, ON Canada Subject: More Messages in /usr/adm/SYSLOG Message-Id: <724@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a 4D/25G with the Turbo option installed running Irix 3.2.1. The following messages are appearing in /usr/adm/SYSLOG with some regularity: a) grcond[18434]: CIO: /ROOTPROC marker 500 grcond[18434]: CIO: /ROOTPROC marker 510 grcond[18434]: CIO: /ROOTPROC marker 520 grcond[18434]: CIO: /ROOTPROC marker 530 grcond[18434]: CIO: /ROOTPROC marker 540 grcond[18434]: CIO: /ROOTPROC marker 550 grcond[18434]: CIO: /ROOTPROC marker 560 grcond[18434]: CIO: /ROOTPROC marker 570 grcond[18434]: CIO: /ROOTPROC marker 580 grcond[18434]: CIO: /ROOTPROC marker 590 grcond[18434]: CIO: /ROOTPROC marker 600 b) grcond[18434]: CIO: input queue lock broken! c) inetd[84]: /usr/etc/fam: exit status 0xd What does each set of errors refer to ?? Are any serious or simply for the purpose of information?? Thanks ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research, Toronto, Canada Phone: (416)-362-9181 UUCP: alias!mark@csri.utoronto.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17276; 26 Jan 90 10:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15177; 26 Jan 90 9:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15139; 26 Jan 90 9:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16417; 26 Jan 90 9:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14095; Fri, 26 Jan 90 06:10: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: 26 Jan 90 06:23:51 GMT From: Mark VandeWettering Organization: Princeton University Subject: Re: Window Manager Crashes Message-Id: <13326@phoenix.Princeton.EDU> References: <13273@phoenix.Princeton.EDU>, <3212@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3212@odin.SGI.COM> gavin@krypton.sgi.com (Gavin A. Bell) writes: [ advice about busy waiting ] I KNOW!!! I KNOW!!! Gadzooks, so I busy waited... cheesh... so give me a break. I am not cross, I just got a box full of mail which had relatively few suggestions about the nature of my problem, but tons correcting my careless use of busy waiting. For all who think I am careless, that "sginap" would someday be converted into something to do a simulation calculation which would then get drawn on the next update. So please, all you expert SGI programmers, concentrate on the question I did ask! Thanks for you advice anyway... Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20877; 26 Jan 90 14:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20016; 26 Jan 90 13:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19884; 26 Jan 90 13:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25023; 26 Jan 90 12:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27625; Fri, 26 Jan 90 09:54:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Jan 90 17:53:14 GMT From: Mark Moraes Subject: sh nices background processes? Message-Id: <90Jan26.125253est.2794@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL It seems that /bin/sh nices (+4) background processes on our 4D/240 (Irix3.2) This is not documented (anywhere I can find) and there appears to be no way to turn it off. Is there a good reason for this discrimination? The cumulative accumulation of niceness can cause a bit of unpleasantness even to non-sh users when people run stuff from an X window manager or xshell running remotely on the 4D/240 -- start up an xterm and it's now niced +4, start an emacs under that xterm and it's now +8, start a compile from within the emacs and it's at +12, and doesn't get very far...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06683; 28 Jan 90 16:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06625; 28 Jan 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06566; 28 Jan 90 16:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18536; 28 Jan 90 16:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05089; Fri, 26 Jan 90 19:09: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: 27 Jan 90 01:30:26 GMT From: Paul Jackson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Trapping SIGTSTP from /bin/sh Message-Id: <3283@odin.SGI.COM> References: <4954@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL To: roy@prism.gatech.edu Subject: Re: Trapping SIGTSTP from /bin/sh Newsgroups: comp.sys.sgi In-Reply-To: <4954@hydra.gatech.EDU> Organization: Silicon Graphics, Inc., Mountain View, CA Cc: Bcc: roy@prism.gatech.edu (Roy Mongiovi) writes: | I'm trying to prevent a SIGTSTP with the command: | | trap "" 21 | | but sh complains: | | 21: bad trap Our sources for /bin/sh have compiled in the "knowledge" that there are just signals 1-19. Try trap with any other number >= 20 and you will get the same error. Looks like a minor bug to me. Thanks, take care ... Paul Jackson (pj@asd.sgi.com), x1373   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac06683; 28 Jan 90 16:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac06625; 28 Jan 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab06566; 28 Jan 90 16:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18545; 28 Jan 90 16:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA08083; Fri, 26 Jan 90 19:54: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: 27 Jan 90 03:02:33 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: PostScript pictures inside psroff Message-Id: <661@chem.ucsd.EDU> References: <155@suntc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I need to put PostScript-described picture inside a document created with psroff. I have tried saving the pre-psroff junk with "save", then at the point where I want to insert a picture I restore this and insert my postscript but none of the postscript stuff prints. For example, the following test input does not work. %!PS-Adobe-1.0 %% ... /$DITroff 140 dict def $DITroff begin /PreDitroffState save def % I inserted this line ... % lots of junk generated by psroff %%EndProlog %%Page: 1 1 10 s 0 xH 0 xS 1 f 8 s 10 s 32(--)Y 4323(--)X 776 672(This)N 938(is)X 1011(a)X 1067(test)X 1198(line,)X 1358(processed)X 1695(by)X 1795(psroff.)X 0 6360(--)N 4323(--)X % NOW I INSERT SOME OF MY OWN POSTSCRIPT TO DRAW A LINE save PreDitroffState restore 200 300 moveto 300 400 lineto stroke restore 1 p %%Trailer xt xs So what am I doing wrong? Is it just impossible to suspend the ditroff stuff so I can draw my own picture? I thought that's what store/restore were all about. -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad06683; 28 Jan 90 16:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ae06625; 28 Jan 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06575; 28 Jan 90 16:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18669; 28 Jan 90 16:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28691; Fri, 26 Jan 90 17:26:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Jan 90 23:37:11 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: (again) where is TeX? Message-Id: <372@meritaus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sorry to keep pestering about older messages... where is the FTP site from which I can obtain TeX? Does that version still run on 3.1? And how about 3.2? Also, what is the approximate disk capacity needed to use it? thanks again,-- dan haug ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan ``When all you have is a hammer, everything begins to look like a nail.''   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06796; 28 Jan 90 16:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad06625; 28 Jan 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06573; 28 Jan 90 16:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18589; 28 Jan 90 16:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07661; Fri, 26 Jan 90 19:49: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: 26 Jan 90 17:22:08 GMT From: Ashton Delahousaye Organization: Hewlett Packard -- Fort Collins, CO Subject: SGI Leasing Company ??? Message-Id: <17450002@hpfcdj.HP.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anyone refer me to a company that leases SGI equipment. I'd like to lease a 4D/25 until the one I have ordered arrives. Ashton   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07062; 28 Jan 90 17:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07010; 28 Jan 90 17:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06938; 28 Jan 90 17:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20032; 28 Jan 90 17:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA04085; Fri, 26 Jan 90 11:34: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: 26 Jan 90 19:23:45 GMT From: Tom Haapanen Organization: WATMIMS Research Group, University of Waterloo Subject: who, /etc/utmp and biff Message-Id: <843@watserv1.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A potpourri of questions... First of all, it appears that sometimes a (usually ftp) login does not indicate to /etc/utmp that it is no longer there. Hence, old entries remain, and right now our 'who -u' output looks like: tom ttyd2 Jan 26 13:24 . 25740 sytek #2 alan console Jan 26 12:35 old 25751 ftp 128.214.2.1 Dec 18 07:39 3748 alan ttyq2 Jan 26 12:35 0:03 25752 ftp apollo.mont Jan 5 22:16 21015 ftp 192.42.239. Jan 22 16:33 15535 alan ttyq3 Jan 26 12:41 0:06 25780 Obviously the ftp connections are old... but they didn't time out either, at least not the latest ones (which are still in the SYSLOG). What could be causing this? Oh yes -- thumbs up to SGI for reliability: our system has been up continuously for 40 days since our OS upgrade! I'd also like to find biff(1) for our Iris; it's a BSD program, and so I wouldn't expect it to have AT&T copyrights in it. It's also mentioned in /etc/services: biff 512/udp comsat ...but it's nowehere to be found, nor are the sources on uunet. Does anyone have it? Or is it going to be included in 3.3/4.0 (or another future release)? \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo "I don't even know what street Canada is on" -- Al Capone   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07062; 28 Jan 90 17:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07010; 28 Jan 90 17:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab06938; 28 Jan 90 17:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20037; 28 Jan 90 17:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18340; Fri, 26 Jan 90 14:55: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: 26 Jan 90 22:08:20 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: who, /etc/utmp and biff Message-Id: <49107@sgi.sgi.com> References: <843@watserv1.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <843@watserv1.waterloo.edu>, tom@mims-iris.waterloo.edu (Tom Haapanen) writes: > A potpourri of questions... First of all, it appears that sometimes > a (usually ftp) login does not indicate to /etc/utmp that it is no longer > there.... I think this bug has been fixed for the next release. > I'd also like to find biff(1) for our Iris;... > Or is it going to be included in 3.3/4.0 (or another > future release)? > "now, you didn't really expect tom@mims-iris.waterloo.edu > my views to have anything to do watmims research group > with my employer's, did you?" university of waterloo Internally, we have a fancy graphics gadget, that is far nicer than the old biff blast to the "terminal" (whatever that means on a workstation). I have the impression that "mailbox" might ship in the next release. Of course, it is not too useful on dumb terminal to a graphic-less server. It is possible to cobble something like biff with nothing more than shell scripts running in the background. The trivial trick is to periodically compare atime and mtime on your /usr/mail/user mailbox, and to babble as desired. It might be useful to look for "comsat" on uunet. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06683; 28 Jan 90 16:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06625; 28 Jan 90 16:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06564; 28 Jan 90 16:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18493; 28 Jan 90 16:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15799; Fri, 26 Jan 90 22:03:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jan 90 05:45:18 GMT From: "Steven H. Izen" Organization: Case Western Reserve University, Cleveland, OH Subject: xdvi crashing Xsgi Message-Id: <4639@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I recently built TeX on my 4D/25. For a previewer, I tried running xdvi, which I had previously built successfully on my 386 unix box. Xdvi compiled with no trouble, but when I start it up to preview a document it gets thru the first letter on the document and crashes the X server, blowing away any other X applications that are running (for example emacs and xbiff). The error message says something about connection reset by peer. Has anyone successfully run xdvi on a 4D? I also tried taking the dvips output and sending it to psview, but that didn't work either. Using the NeWS debugger I determined that the error was a 'dictful' error. What can I patch to get this working? Actually, any advice on getting a working TeX previewer would be appreciated. Thanx. -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve%izen386.uucp@skybridge.scl.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | My other computer is a Personal IRIS.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06867; 28 Jan 90 17:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06543; 28 Jan 90 16:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06511; 28 Jan 90 16:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18410; 28 Jan 90 15:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15791; Fri, 26 Jan 90 22:03: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: 27 Jan 90 05:35:06 GMT From: "Steven H. Izen" Organization: Case Western Reserve University Subject: Convergence problems with my monitor? Message-Id: <4638@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Two weeks after becoming the proud owner of a 4D25, I became aware that text appearing in the upper right corner of my screen was a bit fuzzy. I contacted the hotline and was put in contact with the field service people who had me run the convergence confidence test. Sure enough, the 4x4 array in the upper right corner was slightly out of alignment. So, upon heraing that the SGI engineer shipped me a new replacement monitor. Well, the second monitor was even worse than the first. Before I have SGI try again with a third monitor, I'd like to ask all the people on the net usiing these nice 19 inch monitors: Were your monitors shipped with slight convergence problems? Am I just being picky? If it appears that what I have is in the center of the bell curve, then I certainly can live with the monitor, but if a large fraction of you have perfect screens, then I'll continue to insist on getting a replacement. BTW, The hotline has, for the most part been very helpful. I've found the people at SGI very responsive. -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve%izen386.uucp@skybridge.scl.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | My other computer is a Personal IRIS.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19122; 29 Jan 90 14:44 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18559; 29 Jan 90 14:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18546; 29 Jan 90 14:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14599; 29 Jan 90 13:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27617; Mon, 29 Jan 90 10:27: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: 29 Jan 90 18:00:49 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: P4-XSCSI Message-Id: <49177@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sorry I did not respond to the original post with its original contents, but the gist of the question was 'Why not put a drive in this optional module?'. The primary reason, functionally, is that there is no cooling fan in the module, hence your drive could overheat and yield disastrous results by dying in the midst of something. This module also would require a different internal cable (not a big deal) and the removal of the dummy front panel. This module was designed as a way to bring SCSI outside of the tower on systems that had not other SCSI devices (eg. ESDI, QIC02). It was also a conscious decision not to put a fan in the module in an effort to discourage the notion that SGI would be able to officially support the addition of new devices to this module. (see cabling and previous discussions of termination, Hotline Support, etc. for background). SGI understands that there ARE people out there who can competently add new devices and who are not concerned about support issues, but we also understand that for every 1 of these there are 10 more who will break themselves in attempting this and later demand support for it. The best way to add devices is to get HU-XSCSI and hook up a shoebox sort of arrangement that includes its own power supply, fan, fuse, connectors, cables, FCC and UL, CSA, etc. approvals--IMHO. These can be purchased from most PC stores at reasonable prices. Best of all, buy your peripherals from SGI! 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 aa22229; 29 Jan 90 18:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21822; 29 Jan 90 17:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21719; 29 Jan 90 17:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22590; 29 Jan 90 17:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10451; Mon, 29 Jan 90 13:55: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: 29 Jan 90 20:32:54 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: More Messages in /usr/adm/SYSLOG Message-Id: <3332@odin.SGI.COM> References: <724@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <724@alias.UUCP>, mark@alias.UUCP (Mark Andrews) writes: > We have a 4D/25G with the Turbo option installed running Irix 3.2.1. The > following messages are appearing in /usr/adm/SYSLOG with some regularity: > > b) grcond[18434]: CIO: input queue lock broken! This message indicates that a lock on the input distribution queue in the 4Sight (NeWS) server was held for too long and so was broken by the server. Such locks are used by light weight processes in the server to block distribution of events. The lwp's typically are going to do something that will affect how the input events are interpreted and want to block events until they are ready. This message is advisory. It is not serious nor even important. -- 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 aa22895; 29 Jan 90 20:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22415; 29 Jan 90 19:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22381; 29 Jan 90 19:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24283; 29 Jan 90 19:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17786; Mon, 29 Jan 90 15:47: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: 29 Jan 90 22:28:22 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: PostScript pictures inside psroff Message-Id: <3336@odin.SGI.COM> References: <661@chem.ucsd.EDU>, <155@suntc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <661@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes: > I need to put PostScript-described picture inside a document created with > psroff. I have tried saving the pre-psroff junk with "save", then at the > point where I want to insert a picture I restore this and insert my postscript > but none of the postscript stuff prints. For example, the following > test input does not work. > > > So what am I doing wrong? Is it just impossible to suspend the > ditroff stuff so I can draw my own picture? I thought that's > what store/restore were all about. > -- Try using gsave and grestore. Psroff actually supports what you want to do. I suppose it's documented somewhere but since I've never seen the transcript documentation I can't be sure. The following comes from an SGI letterhead that Ciemo did some time ago. I hacked this for my own uses resulting in a bigger logo centered in the page. ================================================================ .\" A sample troff document file . \"LH - SGI Logo Letterhead .de LH .br .rs .sp |4.2i .po 4.2625i .cf sgilogo.ps .sp |0 .po .. .\" if you want this to print anything .LH ================================================================ The PostScript file included by the .cf request ================================================================ %PB % % Parametric SGI logo path for clipping, filling, and stroking % % (c) Copyright 1988, Silicon Graphics, Inc. % % Hacked together by Dave Ciemiewicz % /SGILogoPath { % - = - % Path definition removed in the interests of clarity and brevity } def % Print logo gsave 29 29 scale SGILogoPath .5 0 .5 setrgbcolor fill grestore PE . ================================================================= Note: there's a "." at the start of the last line of the PostScript file. -- 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 aa06406; 30 Jan 90 19:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06255; 30 Jan 90 19:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06253; 30 Jan 90 18:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21456; 30 Jan 90 18:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07931; Tue, 30 Jan 90 15:08: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: 30 Jan 90 22:57:39 GMT From: "Steven H. Izen" Organization: Case Western Reserve University Subject: rgb -> color postscript Message-Id: <4692@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just hacked up ~4Dgifts/iristools/imgtools/tops.c to a create color postscript version of an RGB image file. While it works, (at least with Freedom of Press on my 4D/25), the code could still use some improvement, like provisions for setting the different colorscreens and reversing white and black regions. Please e-mail me if you would like a copy. If there is enough interest I'll post the diffs. -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve%izen386.uucp@skybridge.scl.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | My other computer is a Personal IRIS.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09899; 31 Jan 90 7:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09587; 31 Jan 90 6:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09585; 31 Jan 90 6:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26512; 31 Jan 90 5:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA17797; Wed, 31 Jan 90 02:02:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Jan 90 03:10:52 GMT From: Mason Woo Organization: Silicon Graphics, Inc., Mountain View, CA Subject: 1990 schedule for Customer Training courses at Silicon Graphics Message-Id: <49357@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is the schedule for training courses at Silicon Graphics for 1990. We have 2 major training centers: in Mountain View, California and in Bethesda, Maryland. This schedule is subject to change. If there is not enough demand, we may cancel courses. However, the phone has been ringing off the hook, so we may add courses, if demand continues to increase. For up-to-date information, call (800) 356-9492 and speak with a Training Coordinator. ------------------ Graphics Programming (Mountain View, CA) February 12 March 19 May 14 June 25 July 23 August 20 October 1 November 5 Graphics Programming (Bethesda, MD) February 5 April 2 April 30 June 4 July 9 September 17 November 5 Advanced Graphics Programming--Graphics II (Mountain View, CA) March 26 April 23 July 30 October 8 Advanced Graphics Programming--Graphics II (Bethesda, MD) February 12 May 7 July 16 September 24 System Accelerator (Mountain View, CA) April 2 June 4 August 6 September 17 October 15 December 3 System Accelerator (Bethesda, MD) March 5 April 9 June 11 July 23 August 20 October 1 November 26 System Administration (Mountain View, CA) April 9 June 11 August 13 September 24 December 10 System Administration (Bethesda, MD) March 12 June 18 August 27 October 8 Network Administration (Mountain View, CA) April 16 August 20 December 17 Network Administration (Bethesda, MD) March 19 October 15 Parallel (Multi-Processor) Programming (Mountain View, CA only) February 12 March 12 May 21 July 23 October 22 System Maintenance--10 day course (Mountain View, CA) June 11 October 22 System Maintenance--10 day course (Bethesda, MD) April 16 July 30 December 3 Personal IRIS Maintenance (Mountain View, CA only) April 9 August 13 Multi-processor IRIS GTX Maintenance (Mountain View, CA only) March 26 June 25 November 5 -- Mason ("Bo Knows Graphics") Woo (415) 962-3314 Silicon Graphics Computer Systems Internet: woo@SGI.COM UUCP: {ames,ucbvax,decwrl,sun}!sgi!woo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14201; 31 Jan 90 11:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13799; 31 Jan 90 11:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13738; 31 Jan 90 11:07 EST Received: from mcs.nlm.nih.gov by SMOKE.BRL.MIL id aa04666; 31 Jan 90 10:24 EST Received: from ncbi.nlm.nih.gov by mcs.nlm.nih.gov (5.59/1.14) id AA03766; Wed, 31 Jan 90 10:28:27 EST Received: by tech.nlm.nih.gov (4.0/SMI-4.0) id AA02225; Wed, 31 Jan 90 10:22:29 EST Date: Wed, 31 Jan 1990 10:22:28 EST From: Peter Karp To: info-iris@BRL.MIL Cc: landsman%tech@mcs.nlm.nih.gov Subject: Columbia-MM on Iris? Message-Id: Is anyone out there running the Columbia version of the MM mail program on the Iris? If so I would like to find out what modifications you made to MM to accomplish this; please respond to me directly (pkarp@ncbi.nlm.nih.gov). Peter   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14574; 31 Jan 90 11:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14201; 31 Jan 90 11:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14190; 31 Jan 90 11:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04800; 31 Jan 90 10:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05520; Wed, 31 Jan 90 07:24: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: 31 Jan 90 15:11:14 GMT From: James Zurlo Organization: Mechanical Engineering, Carnegie Mellon, Pittsburgh, PA Subject: Console doesn't work on PI Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The Console window refuses to give a prompt on our Personal Iris. It's one of those weird errors where it works fine for several days and then it stops giving a prompt. A reboot will sometimes solve the problem. Any ideas? Please respond to: mc@batman.nist.gov Thanks   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15086; 31 Jan 90 12:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14717; 31 Jan 90 12:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14677; 31 Jan 90 12:05 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06128; 31 Jan 90 11:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07374; Wed, 31 Jan 90 07:54: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: 31 Jan 90 15:48:18 GMT From: Tom Fairgrieve Organization: Department of Computer Science, University of Toronto Subject: floating point exceptions Message-Id: <90Jan31.104722est.10528@ephemeral.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am using an SGI Iris 4D/240, running IRIX sys. V release 3.2 and am interested in determining what I need to do so that any floating point overflow, divide by zero or invalid operand occurring during the execution of my Fortran programs is trapped. For example, I'd like the following program: real a, b, c a = 1.0 b = 0.0 c = a / b print *, "c = ", c stop end to trap the zero divide, and not print "c = Inf". I have tried inserting calls to signal and sigset, but haven't been able to get the desired results. Does anyone have any suggestions? We are using release 1.31 of the f77 compiler. Thanks. Tom Fairgrieve tff@na.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15496; 31 Jan 90 13:15 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab15150; 31 Jan 90 12:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab15131; 31 Jan 90 12:35 EST Received: from zorac.dciem.dnd.ca by SMOKE.BRL.MIL id aa06118; 31 Jan 90 11:02 EST Received: by zorac.dciem.dnd.ca (5.59/25-eef) id AA19735; Wed, 31 Jan 90 10:00:41 EST Date: Wed, 31 Jan 90 10:00:41 EST From: Tim Pointing Message-Id: <9001311500.AA19735@zorac.dciem.dnd.ca> To: info-iris@BRL.MIL Subject: Re: info-iris request Just a short reminder to people that the correct address for administrative requests for the info-iris mailing list is: info-iris-request@vmb.brl.mil Requests to the mailing list itself may or may not be effective for these purposes. Thanks, Tim Pointing, DCIEM tim@ben.dciem.dnd.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16008; 31 Jan 90 13:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15496; 31 Jan 90 13:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15153; 31 Jan 90 12:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07977; 31 Jan 90 12:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11719; Wed, 31 Jan 90 09:00: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: 31 Jan 90 15:54:42 GMT From: Andrew Simms Organization: Applied Math, Princeton University Subject: Request for lpr DIFFS Message-Id: <13434@phoenix.Princeton.EDU> References: <12013@csli.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A while back someone posted a set of DIFFs to Berkeley's lpd spooler that would enable it to run on an Iris. Could someone please post the name of the site? Thanks.--ams Andrew Simms ams@acm.princeton.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16874; 31 Jan 90 14:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16416; 31 Jan 90 14:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16139; 31 Jan 90 13:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09932; 31 Jan 90 13:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16131; Wed, 31 Jan 90 10:03: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: 31 Jan 90 17:28:06 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: Console doesn't work on PI Message-Id: <3408@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The most common bug that causes the console to break is to have some program running which has the console open, and then to log out and log in again... Try doing this: fuser /dev/console next time it happens. On my 3.2.1 PI, I see that "/etc/gl/grcond2" is the only process with /dev/console open. I believe that is the correct answer. I you find other processes open, they will almost certainly break things badly when you log in again. kipp   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac16874; 31 Jan 90 14:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16416; 31 Jan 90 14:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab16139; 31 Jan 90 13:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10039; 31 Jan 90 13:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16461; Wed, 31 Jan 90 10: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: 31 Jan 90 17:44:57 GMT From: Deb Ryan Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: floating point exceptions Message-Id: <49378@sgi.sgi.com> References: <90Jan31.104722est.10528@ephemeral.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Jan31.104722est.10528@ephemeral.ai.toronto.edu>, tff@na.toronto.edu (Tom Fairgrieve) writes: > I am using an SGI Iris 4D/240, running IRIX sys. V release 3.2 and am > interested in determining what I need to do so that any floating point > overflow, divide by zero or invalid operand occurring during the execution of > my Fortran programs is trapped. For example, I'd like the following program: > > (stuff deleted) > > Thanks. > Tom Fairgrieve > tff@na.toronto.edu This seems to ba a popular question. I'll repost the answer. You have two choices: 1. Wait for the trap handler, comming out in the next software release. This will make it easy to core dump, trap to a user subroutine, print a count of traps, traceback, replace values, or do anything your heart can code in a subroutine . In this release, man fsigfpe or man sigfpe will tell you what you need to know. 2. If all you really want to do is coredump, this Fortran callable C routine will show you what to do. signal (2) will also allow you to specify your own handler, but you will be pretty limited without information about the exception. ----------------------------------cut here ------------------------------------- #include #include #include /* this code uses information from the manpages fpc(3c) and signal(2) set_traps is a fortran callable subroutine which will enable floating point exceptions, and coredump upon receiving one */ set_traps_() { union fpc_csr fpstat; /* enable the floating point traps */ fpstat.fc_word = get_fpc_csr(); fpstat.fc_word |= (FPCSR_ENABLES | FPCSR_EXCEPTIONS); set_fpc_csr (fpstat.fc_word); /* abort upon receiving floating point trap */ signal (SIGFPE, SIG_DFL); } /* test routine for set_traps */ main() { float zero=0.0; float one=1.0; float result; set_traps_(); /* divide by zero */ printf( "\n\ndividing by zero:\n"); result = one/zero; printf("one/zero yields %e\n",result); } -Deb deb@sgi.com Deborah Ryan Caruso @ Silicon Graphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17206; 31 Jan 90 14:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16874; 31 Jan 90 14:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16729; 31 Jan 90 14:06 EST Received: from ux1.cso.uiuc.edu by SMOKE.BRL.MIL id aa10721; 31 Jan 90 13:31 EST Received: from uxh.cso.uiuc.edu by ux1.cso.uiuc.edu with SMTP (5.61+/IDA-1.2.8) id AA18510; Wed, 31 Jan 90 12:31:43 -0600 Received: by uxh.cso.uiuc.edu (5.51/9.7) id AA03646; Wed, 31 Jan 90 12:29:29 CST Date: Wed, 31 Jan 90 12:29:29 CST From: Luke Lin Message-Id: <9001311829.AA03646@uxh.cso.uiuc.edu> To: info-iris@BRL.MIL Subject: Parking Heads on an Iris We are planning to move an Iris 3130 from one building to another. What can we do to park the heads on the hard drive? Luke Lin S. W. Lee University of Illinois Urbana, IL   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18132; 31 Jan 90 15:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17644; 31 Jan 90 15:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17470; 31 Jan 90 15:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12898; 31 Jan 90 14:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA21475; Wed, 31 Jan 90 11:27: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: 31 Jan 90 19:13:02 GMT From: Dan Nadir Organization: General Dynamics, San Diego Subject: Unix backup utility Message-Id: <1990Jan31.191302.19809@gdwest.gd.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are considering purchasing a package called backup.unet. Does anyone have any experience with it? The people at Unitech (the company who makes it) claim that you can run backups during the day with no data corruption minimal network load. We need to backup Silicon Graphics workstations and Suns to 8mm tape drives. My main question is: Can this software do what Unitech claims it can???? They have been very reluctant to discuss how their product is ACTUALLY working out in a real environment. Thanks for any info. Daniel Nadir -- Daniel Nadir General Dynamics Data Systems Division Internet: dan@gdwest.gd.com Western Center, San Diego UUCP: {ucsd|ucbvax}!sdsu!gdwest!dan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19738; 31 Jan 90 17:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19554; 31 Jan 90 17:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19524; 31 Jan 90 17:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16377; 31 Jan 90 16:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28941; Wed, 31 Jan 90 13:19: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: 31 Jan 90 20:36:16 GMT From: Mark VandeWettering Organization: Princeton University Subject: C++ for SGI 4D? Message-Id: <13441@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We would like to use C++ for a new graphics project on our Silicon Graphics 4D machines. Does anyone know of a vendor that sells a C++ compiler for the 4D series. I know of g++, but I am not really convinced of its robustness, and attempts to get it to compile on the SGI have been unsuccessful. I would be interested in hearing from people with other experience. Thanks in advance. Mark VandeWettering (markv@acm.princeton.edu)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20192; 31 Jan 90 19:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20102; 31 Jan 90 18:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20094; 31 Jan 90 18:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18732; 31 Jan 90 18:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06458; Wed, 31 Jan 90 15:08: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: 31 Jan 90 22:31:49 GMT From: "Steven H. Izen" Organization: Case Western Reserve University, Clevelan, OH Subject: diffs for rgb -> color postscript Message-Id: <4709@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL O.K. folks, my mail box is full... Here are the diffs for my routine to convert an rgb image file to color postscript. Warnings: This program could really use some additional features, like inverting black and white, or the capability to set the color screens. Also, it doesn not generate cymk images, just rgb images. This program has only been tested on images captured with the snaphot utility. The ouput ps is know to work with the Freedom of Press Postscript interpreter. It should work on genuine os printers, but someone else will have to do that testing. To make, apply the diffs to ~4Dgifts/iristools/imgtools/tops.c, then compile with the following line: cc -o tocolps tocolps.c -lc_s -limage It should be used the same way as tops is. If anyone adds any improvements, I'd love to hear about it. Oh, does anyone at SGI know whether it's kosher to post the complete source here? Ie, are there any copyright problems as far as SGI is concerned? Steve Izen -------------------------snip snip snip--------------------------- 2,3c2,3 < * tops - < * Convert a color or black and white image to PostScript. --- > * tocolps - > * Convert a color image to color PostScript. 9c9 < * tops blat.rgb | lp --- > * tocolorps blat.rgb | lp 14a15,16 > * Adapted from P. H.'s tops.c to work with color by Steven Izen > * January, 1990. 16,17c18,19 < #include "image.h" < #include "math.h" --- > #include > #include 20,22c22 < short rbuf[4096]; < short gbuf[4096]; < short bbuf[4096]; --- > int reverse_flag = 0; 34c34 < fprintf(stderr,"usage: tops inimage [-b bitsperpixel]\n"); --- > fprintf(stderr,"usage: tocolps inimage [-b bitsperpixel]\n"); 38a39 > fprintf(stderr," [-r]\n"); 86a88,90 > case 'r': > reverse_flag = 1; /* not implemented yet */ > break; 98c102 < register int x, y, n, i, val; --- > register int x, y, n, i, val, plane; 126a131,132 > putchar('%'); > printf("Output by tocolps\n"); 138c144,146 < printf("/picstr %d string def\n",picstrlen); --- > printf("/rpicstr %d string def\n",picstrlen); > printf("/gpicstr %d string def\n",picstrlen); > printf("/bpicstr %d string def\n",picstrlen); 145,147c153,156 < printf("{ currentfile\n"); < printf("picstr readhexstring pop}\n"); < printf("image\n"); --- > printf("{ currentfile\n rpicstr readhexstring pop}"); > printf("{ currentfile\n gpicstr readhexstring pop}"); > printf("{ currentfile\n bpicstr readhexstring pop}"); > printf("true 3 colorimage\n"); 149c158 < /* send out the picute */ --- > /* send out the picure */ 151c160,161 < getbwrow(image,buf,y); --- > for (plane=0;plane<3;++plane) { > getrow(image,buf,y,plane); 201a212 > } 227,248d237 < getbwrow(image,buf,y) < IMAGE *image; < char *buf; < int y; < { < if(image->zsize<3) { < getrow(image,buf,y,0); < } else { < getrow(image,rbuf,y,0); < getrow(image,gbuf,y,1); < getrow(image,bbuf,y,2); < rgbrowtobw(rbuf,gbuf,bbuf,buf,image->xsize); < } < } < < static rgbrowtobw(rbuf,gbuf,bbuf,obuf,n) < register unsigned short *rbuf, *gbuf, *bbuf, *obuf; < register int n; < { < while(n--) < *obuf++ = (77*(*rbuf++) + 150*(*gbuf++) + 28*(*bbuf++))>>8; < } -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve@izen386.math.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | Klein bottle for sale - Enquire within.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20395; 31 Jan 90 20:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20347; 31 Jan 90 19:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20344; 31 Jan 90 19:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19310; 31 Jan 90 19:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA11457; Wed, 31 Jan 90 16:25: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: 1 Feb 90 00:12:14 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Parking Heads on an Iris Message-Id: <49426@sgi.sgi.com> References: <9001311829.AA03646@uxh.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9001311829.AA03646@uxh.cso.uiuc.edu>, lukelin@UXH.CSO.UIUC.EDU (Luke Lin) writes: > > > We are planning to move an Iris 3130 from one building to another. What > can we do to park the heads on the hard drive? > Power the system down after you do `sync;reboot'. That's about it. 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 aa20854; 31 Jan 90 21:16 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20781; 31 Jan 90 21:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ar20567; 31 Jan 90 20:48 EST Received: from relay.cs.net by SMOKE.BRL.MIL id ab19659; 31 Jan 90 20:17 EST Received: from relay2.cs.net by RELAY.CS.NET id aa12323; 31 Jan 90 12:23 EST Received: from gmr.com by RELAY.CS.NET id ac11336; 31 Jan 90 12:17 EST Date: Wed, 31 Jan 90 11:34 EST From: JORDAN%gmr.com@relay.cs.net Subject: Proper TERM via telnet To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <9001312017.ab19659@SMOKE.BRL.MIL> From time to time, I access my 4D70 via telnet with a VaxStation 3500. Does anyone out there know how the proper tset configuration so that when I login via telnet, the terminal type will be vt100. Presently on the Vax when I do a "tset -", it returns "unknown". thanx. tp mugabi-jordan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22580; 1 Feb 90 3:01 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22513; 1 Feb 90 2:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22502; 1 Feb 90 2:37 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23122; 1 Feb 90 2:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07227; Wed, 31 Jan 90 23:31: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: 31 Jan 90 20:30:03 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: Re: elementary problems Message-Id: <381@texhrc.UUCP> References: <9001161923.aa03052@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL does anybody know of an icon-builder "tool" that is available for the iris? a 60x60 bit-map editor would be great...... michael Zeitlin at uunet!nuchat!texhrc!mjz thanks....   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23350; 1 Feb 90 6:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23067; 1 Feb 90 5:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23046; 1 Feb 90 5:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24410; 1 Feb 90 5:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18026; Thu, 1 Feb 90 02:18:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 03:37:44 GMT From: "Michael L. Takayama" Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: Window Manager Crashes Message-Id: <65904@aerospace.AERO.ORG> References: <13273@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13273@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU () writes: > ...Stuff deleted... >After running for a while, the window manager crashes with the following >message: > >----- >fifo_intr: GM TIMEOUT (FIFO still > half full)! > >The window manager was killed by signal 15. >----- > We used to get this problem all of the time in one of our big programs and, after a lot of headaches, tracked it down to passing double precision values to the v3f() commands. Funny thing is that this *will* work for a random period until enough points have been pushed down the graphics pipeline - then it croaks with the above-mentioned *super-informative* error message. I recommend checking your data types - a *lot* of the GL routines are not very happy with being passed the wrong data types [Type-checking in C? What a concept... :-) ]. We also ran into the NaN problem with n3f(). Very bad stuff with very useless error messages... Good luck - Michael L. Takayama Computer-Aided Engineering Department The Aerospace Corporation   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27243; 1 Feb 90 11:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26648; 1 Feb 90 10:54 EST Received: by VMB.BRL.MIL id aa26538; 1 Feb 90 10:32 EST Received: from tbd.brl.mil by VMB.BRL.MIL id aa24718; 1 Feb 90 8:34 EST Date: Thu, 1 Feb 90 8:38:24 EST From: "John A. Condon" (BDB) To: info-iris@BRL.MIL cc: jac@BRL.MIL Subject: Iris 4D/80GTB Video Stuff Message-ID: <9002010838.aa03871@TBD.BRL.MIL> Hi there, Are there any hackers out there who have used the video options on their Iris. My problem is this: I was finally able to compile and run the "cg2.c" program in the "/video" directory which displayed my screen on a remote RS 170 composite video monitor and allowed me to toggle back to my high resolution 60 Hz graphics monitor. The problem [or what I believe to be a problem with a solution] is that the colors are not exactly the same on the video monitor as the graphics monitor. I've read the documentation "Programming the Genlock Composite Video Option" a dozen times (no kidding!) but I am still not sure if there is a way to solve this problem. Any ideas [or solutions!] are greatly appreciated. John (alias,..the Jersey Renegade)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27435; 1 Feb 90 11:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26944; 1 Feb 90 11:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26729; 1 Feb 90 10:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02253; 1 Feb 90 10:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA05401; Thu, 1 Feb 90 07:30:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 15:26:32 GMT From: Thomas Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: Sendmail version and vulnerability Message-Id: <23981@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What version number of sendmail does SGI ship with its 4D systems and if it is not the latest version (which I believe is 5.6something) are there any plans to ship the latest version with the next release? Near as I can tell, SGIs sendmail is version 5.52. Is this correct? I have recently read in comp.security.announce that the latest version might have fixed some holes. It might be nice to see the new version from SGI. On top of that, we occasionally (say, every 3 or 4 months) get into a state where our sendmail starts spewing forth many many children until the process table fills up. Many moons ago I posted to our local network ops bboard and they told me "try porting sendmail 5.6? to your system. We had that happen with some old versions." I tried to do the port, but it stepped on too many bsdisms. Today I had 60 sendmails running, so I post again: Has anyone else ever found there sendmail forking too many children? If so, have you identified the source? Have you found a cure? Answers to any subset of the questions in the above post would be greatly appreciated. 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 aa29211; 1 Feb 90 13:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28565; 1 Feb 90 13:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28429; 1 Feb 90 12:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06631; 1 Feb 90 12:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12036; Thu, 1 Feb 90 09:10:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 15:59:14 GMT From: Thant Tessman Organization: Silicon Graphics, Inc. Subject: Re: elementary problems Message-Id: <3458@odin.SGI.COM> References: <381@texhrc.UUCP>, <9001161923.aa03052@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <381@texhrc.UUCP>, mjz@texhrc.UUCP (Michael Zeitlin) writes: > > does anybody know of an icon-builder "tool" that is available > for the iris? > a 60x60 bit-map editor would be great...... > michael Zeitlin at uunet!nuchat!texhrc!mjz Check out 'imged'. You should have an online manual page for it. thant   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00190; 1 Feb 90 14:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28874; 1 Feb 90 13:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28689; 1 Feb 90 12:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06713; 1 Feb 90 12:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12018; Thu, 1 Feb 90 09:09:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 15:14:40 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: diffs for rgb -> color postscript Message-Id: <3457@odin.SGI.COM> References: <4709@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4709@amelia.nas.nasa.gov> izen@cwru.cwru.edu (Steven H. Izen) writes: ...stuff about modifying ~4Dgifts/iristools/imgtools/tops.c to convert an an rgb image file to color postscript... >Oh, does anyone at SGI know whether it's kosher to post the complete source >here? Ie, are there any copyright problems as far as SGI is concerned? Steve: as the "psuedo" 4Dgifts "manager-type" for SGI, i can confirm for you that there are no copyright problems as far as SGI is concerned. this stuff is wide-open as far as posting complete versions of modified source, comparing notes, etc. to quote from a piece of the ~4Dgifts/README file: ...we welcome your feedback/ideas/requests for additions/changes (and even bug-fixes)... i for one would appreciate the opportunity to see yer complete file version (altho i'm not sure where in-house we have any color postscript printers... will have to investigate). posting it here in its entirety would be great. i was one of those primarily responsible for getting 4Dgifts going on the 4D machines back in 1988 as a reincarnation of the 2/3000 machine subtree known as /usr/people/gifts. altho this was about a year and a half late (it should have been planned for/implemented when the 4D family line was originally being put on rails in the beginning of 1987), it was nevertheless a very helpful resource both for user's as well as all of us here in support engineering (aka the hotline) as a means of more quickly isolating where something might be going wrong when someone called in with a question/problem/etc.. since there's never enuff time in a day, 4Dgifts' potential as a whole is always only about one third to one half (in my opinion) realized, but due to time constraints, well, more always needs to be done. so altho the ~4Dgifts/README file might not be explicit enuff, we DO welcome user's ideas/suggestions/etc for ways to increase the usefulness of this resource. -- daveus rattus yer friendly neighborhood ratman KOYAANISQATSI ko.yan.nis.qatsi (from the Hopi Language) n. 1. crazy life. 2. life in turmoil. 3. life out of balnace. 4. life disintegrating. 5. a state of life that calls for another way of living.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02085; 1 Feb 90 17:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01824; 1 Feb 90 16:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01809; 1 Feb 90 16:38 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15521; 1 Feb 90 16:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27487; Thu, 1 Feb 90 13:03: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: 1 Feb 90 20:53:56 GMT From: Mona Organization: Dartmouth College, Hanover, NH Subject: Re: Window Manager Crashes Message-Id: <19007@dartvax.Dartmouth.EDU> References: <13273@phoenix.Princeton.EDU>, <65904@aerospace.AERO.ORG> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <65904@aerospace.AERO.ORG> tak@aero.UUCP (Michael L. Takayama) writes: >In article <13273@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU () writes: >> > ...Stuff deleted... > >>After running for a while, the window manager crashes with the following >>message: >>----- >>fifo_intr: GM TIMEOUT (FIFO still > half full)! >>The window manager was killed by signal 15. >>----- >We used to get this problem all of the time in one of our big programs >and, after a lot of headaches, tracked it down to passing double >precision values to the v3f() commands. Funny thing is that this Well I have learned this from EXPERIENCE. I had written lots of code andwas integrating them. Everything seemed to work fine when tested seperately. I was desperate for a week chasing a bug. I crashed the system a trillion times, later I discovered that I was calling a library routine without the brackets. If you wanna sabotage somebody's code just remove the () from endline, endpolygon etc and you would be having real fun :-) >Michael L. Takayama krish mohan mona@eleazar.dartmouth.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03263; 1 Feb 90 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03108; 1 Feb 90 19:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03075; 1 Feb 90 19:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18218; 1 Feb 90 19:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09840; Thu, 1 Feb 90 16:10: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: 1 Feb 90 23:49:11 GMT From: Al Broderick Organization: Rutgers Univ., New Brunswick, N.J. Subject: Flight source code on 4D/70 -- missing file "gobj.h" Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi, I have a 4D/70 and the source code to FLIGHT. I would like to compile this program and play/learn with it. I seem to be missing a file called "gobj.h" because when I try to compile it I get an error message that says: cpp: error ./flight.h:20: Can't find include file gobj.h Could someone send me this file or tell me what I am doing wrong? I have looked all over the disk for this file, but I cannot find it. Thanks! Alfred Broderick broderic@topaz.rutgers.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03263; 1 Feb 90 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03182; 1 Feb 90 20:00 EST Received: by VMB.BRL.MIL id ad03073; 1 Feb 90 19:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00629; 1 Feb 90 15:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11314; 1 Feb 90 14:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20350; Thu, 1 Feb 90 11:13:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 18:19:06 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Sendmail version and vulnerability Message-Id: <49461@sgi.sgi.com> References: <23981@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <23981@ut-emx.UUCP>, russo@chaos.utexas.edu (Thomas Russo) writes: > > What version number of sendmail does SGI ship with its 4D systems and > if it is not the latest version (which I believe is 5.6something) are > there any plans to ship the latest version with the next release? > Near as I can tell, SGIs sendmail is version 5.52. Is this correct? 5.52 with debug and test of worm fame turned off. > I have recently read in comp.security.announce that the latest version > might have fixed some holes. It might be nice to see the new version > from SGI. The recent flap concerned an "improvement" made by a solar outfit its recent version. It applies only to their stuff. > On top of that, we occasionally (say, every 3 or 4 months) get into > a state where our sendmail starts spewing forth many many children > until the process table fills up. Many moons ago I posted to our > local network ops bboard and they told me "try porting sendmail 5.6? > to your system. We had that happen with some old versions." I tried > to do the port, but it stepped on too many bsdisms. Today I had 60 > sendmails running, so I post again: Has anyone else ever found there > sendmail forking too many children? If so, have you identified the source? > Have you found a cure? > > Thomas Russo > Center for Nonlinear Dynamics, University of Texas at Austin > russo@chaos.utexas.edu or phib421@utchpc.bitnet Boiling sendmails can happen as a result of many things. The most common cases I have seen result when a remote machine has trouble completing a transaction, and keeps retrying. That can be caused by sendmail.cf bugs on either end. A somewhat less common class of cases results from local sendmail.cf bugs which cause each sendmail to go off the deep end rewriting without expanding forever. A third case can happen if you run `ypserv -i` and your name server and ypserv get to screaming at each other. There is a fix for the last problem in a previous or immediately forthcoming release--I've forgotten which. The sympthom of the first case is helped by changing the notion of "load" that sendmail computes to pay attention to its forks. That change, which requires squashing many extra forks and adding a counter, may already be in IRIX 3.2. These boiling problems apply to all versions of sendmail, including 5.61. Unfortunately, the stuff in sendmail.cf is a program. There is no alternative to debugging it. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03263; 1 Feb 90 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03182; 1 Feb 90 20:01 EST Received: by VMB.BRL.MIL id af03073; 1 Feb 90 19:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02292; 1 Feb 90 17:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16214; 1 Feb 90 16:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29903; Thu, 1 Feb 90 13:38: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: 1 Feb 90 20:33:05 GMT From: John Buchanan Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Crashing the window manager ( Yet another way to do it) Message-Id: <6619@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The recent postings about programs that crash the window server has prompted me to try to produce the following gem. We are running an application which requires interrupt handling. The problem is that trying to do some graphics after an interrupt (SIGINT) has occurred crashes the machine. The original program showed this problem in a somewhat non deterministic fashion, the program that follows crashes the machine after the first interrupt. In attempting to solve this problem we tried to work around the problem in a couple of ways. 1st we simply reinitialized the window after each interrupt, but this led to problems after about 50 interrupts. The other approach was to enclose the lrectwrite call as follows . . signal(SIGINT,SIG_IGN); lrectwrite(.....); signal(SIGING,HandleInterrupt); /* see the code for */ . /* more details */ . This had the effect of making it almost impossible to interrupt the program. The following shar file contains both the program and the Makefile. If any one can either tell me what we are doing wrong or what the bug is then I would be happy. At the end of this posting I include the relevant(?) SYSLOG entries for both the personal Iris and a 4D/70 iris. One interesting thing that I just noticed is that this program runs considerably faster on a personal iris than on a 4D/70. Hmmmmm ?????? #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # Makefile # crash.c # This archive created: Tue Jan 30 16:59:43 1990 export PATH; PATH=/bin:$PATH echo shar: extracting "'Makefile'" '(53 characters)' if test -f 'Makefile' then echo shar: will not over-write existing file "'Makefile'" else sed 's/^X//' << \SHAR_EOF > 'Makefile' Xcrash: crash.c X cc -g -o crash -g crash.c -lgl_s -lm SHAR_EOF if test 53 -ne "`wc -c < 'Makefile'`" then echo shar: error transmitting "'Makefile'" '(should have been 53 characters)' fi fi # end of overwriting check echo shar: extracting "'crash.c'" '(863 characters)' if test -f 'crash.c' then echo shar: will not over-write existing file "'crash.c'" else sed 's/^X//' << \SHAR_EOF > 'crash.c' X#include X#include X#include X Xjmp_buf JumpBuffer; Xlong nrand48(); X X XHandleInterrupt () X { X (void) signal(SIGINT,HandleInterrupt); X longjmp(JumpBuffer,0); X } X Xmain() X { X (void) signal(SIGINT,HandleInterrupt); /* Catch signals */ X foreground(); /* Run in foreground */ X prefsize(256,256); X winopen("crash"); X RGBmode(); X gconfig(); X (void) setjmp(JumpBuffer); /* Save stack */ X while (1) X Scan(); /* Do something */ X } X XScan() X X { X int foo[3]; X int i; X unsigned char p_red = (unsigned char) nrand48(foo); X unsigned char p_green = (unsigned char) nrand48(foo); X unsigned char p_blue = (unsigned char) nrand48(foo); X long scan[256]; X X /* X * setup the scan line X */ X for(i=0; i< 256; i++) X scan[i] = p_red | p_green << 8 | p_blue << 12; X X /* X * fill the window X */ X for(i= 0; i < 256; i++) X lrectwrite(0,i,255,i,scan); X } X SHAR_EOF if test 863 -ne "`wc -c < 'crash.c'`" then echo shar: error transmitting "'crash.c'" '(should have been 863 characters)' fi fi # end of overwriting check # End of shell archive exit 0 Follows SYSLOG entries for personal Iris and 4D/70 This is the entry for the personal Iris. Jan 30 09:08:53 abbott.cs.ubc.ca grcond[556]: Child process /bin/wsh terminated by signal 15 Jan 30 09:08:53 abbott.cs.ubc.ca grcond[556]: Child process /etc/gl/pandora terminated by signal 15 Jan 30 09:08:54 abbott.cs.ubc.ca grcond[556]: Restoring PROM textport microcode Jan 30 09:09:00 abbott.cs.ubc.ca grcond[1162]: In limbo Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: Alive Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: *********************************************************************** Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Copyright 1984 AT&T - All Rights Reserved Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Copyright 1987 Silicon Graphics Inc - All Rights Reserved Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: RESTRICTED RIGHTS LEGEND Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Use, duplication or disclosure by the Government is subject Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: to restrictions as set forth in subdivision (c)(1)(ii) of Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: the Rights in Technical Data and Computer Software clause Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: at 52.227-7013. Manufacturer is Silicon Graphics, Inc., Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: 2011 N. Shoreline Blvd., Mountain View, CA 94039-7311. Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: *********************************************************************** Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: IRIX System V Release 3.2.1 IP6 Version 10171414 Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: WARNING: gr1_ge_intr: GE initialization interrupt (microcode error) Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: WARNING: Graphics error: GE PC = 522 Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: WARNING: gr1_ge_intr: GE initialization interrupt (microcode error) Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: WARNING: Graphics error: GE PC = 522 Jan 30 09:09:04 abbott.cs.ubc.ca grcond[1162]: CIO: Jan 30 09:09:29 abbott.cs.ubc.ca grcond[1162]: CIO: Foo =>: Load failed due to error in file. This is the SYSLOG entry for the 4D/70, it took three interrupts to generate this one. Jan 30 08:07:26 chico.cs.ubc.ca timeslave[106]: recvfrom(date read): Connection refused Jan 30 09:10:52 chico.cs.ubc.ca grcond[5684]: Child process /bin/wsh terminated by signal 15 Jan 30 09:10:52 chico.cs.ubc.ca grcond[5684]: Child process /etc/gl/pandora terminated by signal 15 Jan 30 09:11:04 chico.cs.ubc.ca grcond[5684]: Restoring PROM textport microcode Jan 30 09:11:05 chico.cs.ubc.ca grcond[7070]: In limbo Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: Alive Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: s: Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: writing microcode Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: done writing microcode Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: 2b constants Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: bitplanes: 24 Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: zbuffer board installed Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Finished loading master. Entering dispatch Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: trap status 0x7, pipe status 0x104 Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: GE 0 trapped Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: GE 1 trapped Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: GE 2 trapped Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: HEAD GA trapped Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Context = 4 Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: PANIC: GE trap Blamo!! Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Process 6299 [clock] sent SIGBUS due to VME Bus Timeout Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: ^Iat 0x18904000 PC:0xF034454 ep:0xFFFFC0F0 Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: Jan 30 09:11:07 chico.cs.ubc.ca grcond[7070]: CIO: NOTICE: GF3 infinite high water interrupt Jan 30 09:15:28 chico.cs.ubc.ca grcond[7070]: CIO: Foo =>: Load failed due to error in file. ========================================================================= | |===============================| | John Buchanan (juancho) | buchanan@cs.ubc.ca | | Imager Manager |===============================| | Imager | (604) 228-2218 | | Department of Computer Science |===============================| | University of British Columbia | Standard disclaimer | | Vancouver, BC, Canada | included in this | | | box, right here. | ========================================================================= -- ========================================================================= | |===============================| | John Buchanan (juancho) | buchanan@cs.ubc.ca | | Imager Manager |===============================|   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03703; 1 Feb 90 20:53 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03500; 1 Feb 90 20:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03482; 1 Feb 90 20:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18591; 1 Feb 90 20:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13036; Thu, 1 Feb 90 17:02: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: 2 Feb 90 00:59:56 GMT From: "Lonhyn T. Jasinskyj" Organization: NASA Ames Research Center, Moffett Field, CA Subject: Bash on 4Ds Message-Id: <4736@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone tried/been successful in compiling bash (Born again Shell) on Iris 4Ds? I just recently migrated to an Iris from a Sun and miss a shell with proper command line editing (was originally spoiled by ksh in this respect). I suppose tcsh would be acceptable if bash can't be done. Anyone out there tried either of these. I might be missing something but it looks like the port is not at all trivial. What about mh, g++? Help... Lonnie -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Email to: lonhyn@ew01.nas.nasa.gov Human at: 415-604-3989 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00239; 2 Feb 90 3:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00090; 2 Feb 90 3:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04089; 1 Feb 90 22:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19608; 1 Feb 90 22:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20862; Thu, 1 Feb 90 19:06:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 02:57:37 GMT From: Phil Budne Organization: Disinformation Technology, Boston University, Boston, MA, USA Subject: Re: Request for lpr DIFFS Message-Id: <51559@bu.edu.bu.edu> References: <12013@csli.Stanford.EDU>, <13434@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13434@phoenix.Princeton.EDU> ams@acm.princeton.EDU (Andrew Simms) writes: >A while back someone posted a set of DIFFs to Berkeley's lpd spooler >that would enable it to run on an Iris. Could someone please post the >name of the site? Thanks.--ams I posted such a beast... look in bu.edu:~ftp/src/PRINTING/SGI-LPR-LPD.SHAR I didn't put in local printers (ie; use of termio rather then sgtty) but someone else did! I saved THAT posting in the same dir as AUX-lpd -Phil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05406; 2 Feb 90 10:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04737; 2 Feb 90 10:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04645; 2 Feb 90 10:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07628; 2 Feb 90 9:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25884; Fri, 2 Feb 90 06:26:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 17:15:12 GMT From: "Michael L. Takayama" Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: Array boundary checking & Fortran <> C translators Message-Id: <65973@aerospace.AERO.ORG> References: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If you are calling Fortran subroutines from C, you may want to be aware of the following problem which I ran into: In certain cases, floats do *not* pass correctly to REALs. This problem does not occur with ints to INTEGERs nor with doubles to DOUBLE PRECISIONs. Example code: *** main.c *** main() { double a; float b; int c; a = 1234.5678; /* Assign values. */ b = 9876.1234; c = 121162; /* Call C routine which calls Fortran routine. */ subtestc(a, b, c); } *** subtest.c *** subtestc(a, b, c) double a; float b; int c; { float temp; temp = b; /* This is my work-around. */ /* Call the Fortran routine. */ subtest_(&a, &b, &c, &temp); } *** subtest.f *** SUBROUTINE SUBTEST(A,B,C,TEMP) C DOUBLE PRECISION A REAL B,TEMP INTEGER C C C JUST WRITE OUT THE VALUES C WRITE(*,*) A WRITE(*,*) B WRITE(*,*) C WRITE(*,*) TEMP C RETURN END The output of this program is: 1234.567800000000 <<---- ok for double -> DOUBLE PRECISION 6.102790 <<---- WRONG for real -> FLOAT 121162 <<---- ok for int -> INTEGER 9876.123 <<---- ok for real -> FLOAT using a temporary variable in subtestc() Maybe I am doing something illegal here and just got lucky with the ints and doubles passing correctly (I don't think so - I have about 60 routines mixing C and Fortran which *do* work correctly), but I notified the Hotline and they think it is an undiscovered bug in the Fortran compiler. With deepest sympathies to my fellow multi-lingual programmers - Michael L. Takayama Computer-Aided Engineering Department The Aerospace Corporation   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06192; 2 Feb 90 11:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05406; 2 Feb 90 10:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04774; 2 Feb 90 10:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08102; 2 Feb 90 9:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25882; Fri, 2 Feb 90 06:26:24 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Feb 90 16:33:52 GMT From: "Michael L. Takayama" Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: 1990 schedule for Customer Training courses at Silicon Graphics Message-Id: <65968@aerospace.AERO.ORG> References: <49357@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL For all new IRIS graphics programmers - I took both the Graphics I and Advanced Graphics courses at the Mountain View facility and would rate them among the best training courses I have taken. The Graphics I course is a *very* good intro to 3D graphics for those of you who have had little or no previous experience with 3D (I would rate it as a 9.0 on the 1-10 scale; of course, I learned 3D from Jim Blinn at Caltech [10+] - all things *are* relative!). The facilities were excellent, the instructers were extremely competent and helpful (Carolyn, Linda, and, of course, Mason!), and the food was pretty good. Only black mark I could come up with was that the room was either too cold or too warm! Now, if only the Hotline was as good... An unsolicited round of applause from - Michael L. Takayama Computer-Aided Engineering Department The Aerospace Corporation   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00600; 2 Feb 90 4:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00554; 2 Feb 90 4:16 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa00546; 2 Feb 90 4:01 EST Date: Fri, 2 Feb 90 3:57:47 EST From: Phil Dykstra To: "Lonhyn T. Jasinskyj" cc: info-iris@BRL.MIL Subject: Re: Bash on 4Ds Message-ID: <9002020357.aa00381@SPARK.BRL.MIL> A tcsh for the 4D's is available by anonymous ftp in the info-iris archives on ftp.brl.mil (a.k.a. vgr.brl.mil). I have not tried to compile bash on the 4D's. - Phil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03207; 2 Feb 90 9:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02549; 2 Feb 90 8:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02504; 2 Feb 90 8:42 EST Received: from phvax.smithkline.com by SMOKE.BRL.MIL id aa04506; 2 Feb 90 8:30 EST Received: from PHVAX.DECnet MAIL11D_V3 by smithkline.com (5.57/Ultrix2.4-C) id AA01542; Fri, 2 Feb 90 08:22:15 EST Date: Fri, 2 Feb 90 08:22:14 EST Message-Id: <9002021322.AA01542@smithkline.com> From: dixons%phvax.dnet@smithkline.com To: "amelia!ew01!lonhyn@ames.arc.nasa.gov %INET.dnet"@smithkline.com Cc: "info-iris@brl.mil %INET.dnet"@smithkline.com Subject: Re: Bash on 4Ds "Lonhyn T. Jasinskyj" writes >Has anyone tried/been successful in compiling bash (Born again Shell) >on Iris 4Ds? I just recently migrated to an Iris from a Sun and miss >a shell with proper command line editing (was originally spoiled by ... Here is a context diff to get Bash 1.04 to run on 4Ds. I have been using it for several months without problem. Thanks to Jim Barton at SGI for giving me the secret to getting job control to work. Scott Dixon (dixons@smithkline.com) --------------------cut----------------cut------------------------------ *** ../bash-orig/Makefile Sat Nov 4 12:36:18 1989 --- Makefile Tue Nov 14 22:52:06 1989 *************** *** 45,56 **** # Use i386 for PC type 386 boxes. (Compaq, etc.) # SUN3, SUN4, SUN386i, VAX, SONY, CONVEX, HP, HP9KS300, i386, NeXT, AIX, # ATT3B, ATT386 ! TARGET = SUN3 # The name of the target operating system. There isn't such a big # difference between SUNOS3 and Bsd. But there might be in the future. # SUNOS3, SUNOS4, SYSV, Bsd, HPUX, UNIXPC ! OS = SUNOS4 # You only need this if you are hacking the shell in a location # that doesn't do enough backups, or does a poor job. In that --- 45,56 ---- # Use i386 for PC type 386 boxes. (Compaq, etc.) # SUN3, SUN4, SUN386i, VAX, SONY, CONVEX, HP, HP9KS300, i386, NeXT, AIX, # ATT3B, ATT386 ! TARGET = IRIS4D # The name of the target operating system. There isn't such a big # difference between SUNOS3 and Bsd. But there might be in the future. # SUNOS3, SUNOS4, SYSV, Bsd, HPUX, UNIXPC ! OS = SYSV # You only need this if you are hacking the shell in a location # that doesn't do enough backups, or does a poor job. In that *************** *** 71,92 **** # HP-UX compilation requires the BSD library. #LOCAL_LIBS = -lBSD # Xenix requires -ldir -lx. It is also required in the readline Makefile. #LOCAL_LIBS = -ldir -lx ! GCC_SUNOS4_FLAG = -Bstatic DEBUG_FLAGS = $(PROFILE_FLAGS) -g $(GCC_SUNOS4_FLAG) LDFLAGS = $(DEBUG_FLAGS) ! CFLAGS = $(DEBUG_FLAGS) -D${TARGET} -DTARGET=${TARGET} -D${OS} CPPFLAGS= -I$(LIBSRC) # If you don't have Bison use "yacc". Otherwise use "bison -y". ! #BISON = yacc ! BISON = bison -y # If you don't have Gcc use cc. ! CC = gcc -traditional #################################################################### --- 71,97 ---- # HP-UX compilation requires the BSD library. #LOCAL_LIBS = -lBSD + #Iris needs sun and bsd libs + LOCAL_LIBS = -lsun -lbsd # Xenix requires -ldir -lx. It is also required in the readline Makefile. #LOCAL_LIBS = -ldir -lx ! #GCC_SUNOS4_FLAG = -Bstatic DEBUG_FLAGS = $(PROFILE_FLAGS) -g $(GCC_SUNOS4_FLAG) LDFLAGS = $(DEBUG_FLAGS) ! CFLAGS = $(DEBUG_FLAGS) -D${TARGET} -DTARGET=${TARGET} -D${OS} -DVOID=int CPPFLAGS= -I$(LIBSRC) + #Iris requires another include area for some files + CFL2 = -I/usr/include/bsd # If you don't have Bison use "yacc". Otherwise use "bison -y". ! BISON = yacc ! #BISON = bison -y # If you don't have Gcc use cc. ! #CC = gcc -traditional ! CC = cc #################################################################### *************** *** 114,120 **** MALLOC = $(ALLOC_SOURCE)malloc.o MALLOC_FLAGS = -Drcheck -Dbotch=programming_error #MALLOC= $(ALLOC_SOURCE)malloc.o ! #ALLOCA= $(ALLOC_SOURCE)alloca.o ALLOC_HEADERS = $(ALLOC_SOURCE)getpagesize.h ALLOC_FILES = $(ALLOC_SOURCE)malloc.c $(ALLOC_SOURCE)alloca.c\ --- 119,125 ---- MALLOC = $(ALLOC_SOURCE)malloc.o MALLOC_FLAGS = -Drcheck -Dbotch=programming_error #MALLOC= $(ALLOC_SOURCE)malloc.o ! ALLOCA= $(ALLOC_SOURCE)alloca.o ALLOC_HEADERS = $(ALLOC_SOURCE)getpagesize.h ALLOC_FILES = $(ALLOC_SOURCE)malloc.c $(ALLOC_SOURCE)alloca.c\ *************** *** 230,238 **** (cd $(RLIBSRC); $(MAKE) $(MFLAGS) CC='$(CC)'\ CFLAGS='$(CFLAGS) -DSHELL') ! $(TERMCAP): $(TERMCAP_SOURCE) ! (cd $(LIBSRC); $(MAKE) $(MFLAGS) CC='$(CC)'\ ! CFLAGS='$(CFLAGS) -I.') shell.o: shell.h flags.h shell.c $(CC) $(CFG_FLAGS) $(CFLAGS) $(CPPFLAGS) -c shell.c --- 235,243 ---- (cd $(RLIBSRC); $(MAKE) $(MFLAGS) CC='$(CC)'\ CFLAGS='$(CFLAGS) -DSHELL') ! #$(TERMCAP): $(TERMCAP_SOURCE) ! # (cd $(LIBSRC); $(MAKE) $(MFLAGS) CC='$(CC)'\ ! # CFLAGS='$(CFLAGS) -I.') shell.o: shell.h flags.h shell.c $(CC) $(CFG_FLAGS) $(CFLAGS) $(CPPFLAGS) -c shell.c *************** *** 247,260 **** $(CC) -I$(ALLOC_SOURCE) $(CFLAGS) $(MALLOC_FLAGS) -c $*.c &&\ mv `basename $*`.o $(MALLOC) ! #$(ALLOCA): $(ALLOC_FILES) ! # $(CC) -I$(ALLOC_SOURCE) $(CFLAGS) -o $(ALLOCA) -c $*.c ! # mv `basename $*`.o $(ALLOCA) bashline.o: bashline.c config.h $(RLIBSRC)readline.h variables.h builtins.h jobs.o: jobs.c nojobs.c jobs.h config.h version.o: version.h version.c .build general.o: general.c shell.h y.tab.h: y.tab.c alias.o: alias.h alias.c subst.o: subst.c shell.h --- 252,267 ---- $(CC) -I$(ALLOC_SOURCE) $(CFLAGS) $(MALLOC_FLAGS) -c $*.c &&\ mv `basename $*`.o $(MALLOC) ! $(ALLOCA): $(ALLOC_FILES) ! $(CC) -I$(ALLOC_SOURCE) $(CFLAGS) -o $(ALLOCA) -c $*.c ! mv `basename $*`.o $(ALLOCA) bashline.o: bashline.c config.h $(RLIBSRC)readline.h variables.h builtins.h jobs.o: jobs.c nojobs.c jobs.h config.h + $(CC) $(CFLAGS) $(CFL2) -c jobs.c version.o: version.h version.c .build general.o: general.c shell.h + $(CC) $(TRADITIONAL) $(CFLAGS) $(CFL2) -c general.c y.tab.h: y.tab.c alias.o: alias.h alias.c subst.o: subst.c shell.h *** ../bash-orig/builtins.c Mon Oct 30 23:06:14 1989 --- builtins.c Tue Nov 14 22:43:11 1989 *************** *** 3257,3264 **** } else { /* Must be a job spec. Check it out. */ - int oldmask = sigblock (sigmask (SIGCHLD)); int job = get_job_spec (list); if (job < 0 || job >= job_slots || !jobs[job]) { --- 3257,3264 ---- } else { /* Must be a job spec. Check it out. */ int job = get_job_spec (list); + int oldmask = sigblock (sigmask (SIGCHLD)); if (job < 0 || job >= job_slots || !jobs[job]) { *** ../bash-orig/config.h Thu Sep 21 20:41:17 1989 --- config.h Tue Nov 14 22:43:11 1989 *************** *** 2,8 **** #ifndef _CONFIG_ #define _CONFIG_ - #ifndef VOID #define VOID void #endif --- 2,7 ---- *************** *** 35,41 **** #define JOB_CONTROL /* Note that System V machines don't support job control. */ ! #if defined (SYSV) && !defined (HP9KS300) #undef JOB_CONTROL #endif /* SYSV && !HP9KS300 */ --- 34,40 ---- #define JOB_CONTROL /* Note that System V machines don't support job control. */ ! #if defined (SYSV) && !defined (HP9KS300) && !defined (IRIS4D) #undef JOB_CONTROL #endif /* SYSV && !HP9KS300 */ *** ../bash-orig/glob.c Sat Sep 23 00:35:45 1989 --- glob.c Wed Nov 15 12:16:18 1989 *************** *** 21,27 **** #include ! #if defined(USGr3) || defined(DIRENT) #include #define direct dirent #define D_NAMLEN(d) strlen((d)->d_name) --- 21,27 ---- #include ! #if defined(USGr3) || defined(DIRENT) || defined(SYSV) #include #define direct dirent #define D_NAMLEN(d) strlen((d)->d_name) *************** *** 34,40 **** # endif /* USG. */ #endif /* USGr3 or DIRENT. */ ! #ifdef USG #include #include #define bcopy(s, d, n) ((void) memcpy ((d), (s), (n))) --- 34,40 ---- # endif /* USG. */ #endif /* USGr3 or DIRENT. */ ! #if defined(USG) || defined(SYSV) #include #include #define bcopy(s, d, n) ((void) memcpy ((d), (s), (n))) *** ../bash-orig/jobs.c Sat Nov 4 11:54:16 1989 --- jobs.c Wed Nov 15 11:44:23 1989 *************** *** 35,40 **** --- 35,59 ---- #include #include "shell.h" #include "jobs.h" + #ifdef IRIS4D + #define setpgrp BSDsetpgrp + #include + #define getpgrp BSDgetpgrp + # define ioctl jioctl + # define TIOCGETD 50000 + # define TIOCSETD 50001 + # define TIOCGETP 50002 + # define TIOCSETP 50003 + # define TIOCSETN 50004 + # define FIOCLEX 50005 + # define OTTYDISC 0 + # define CNSUSP 26 + # define VSUSP VSWTCH + #define signal sigset + #ifndef sigmask + #define sigmask(x) (1 << ((x)-1)) + #endif + #endif /* Not all systems define errno in errno.h. */ extern int errno; *************** *** 265,272 **** /* Delete all DEAD jobs that the user had received notification about. */ cleanup_dead_jobs () { - int oldmask = sigblock (sigmask (SIGCHLD)); register int i; for (i = 0; i < job_slots; i++) if (jobs[i] && JOBSTATE (i) == JDEAD && jobs[i]->notified) --- 284,291 ---- /* Delete all DEAD jobs that the user had received notification about. */ cleanup_dead_jobs () { register int i; + int oldmask = sigblock (sigmask (SIGCHLD)); for (i = 0; i < job_slots; i++) if (jobs[i] && JOBSTATE (i) == JDEAD && jobs[i]->notified) *************** *** 702,708 **** --- 721,731 ---- /* When we end a job abnormally, or if we stop a job, we set the tty to the state kept in here. When a job ends normally, we set the state in here to the state of the tty. */ + #ifdef IRIS4D + static struct termio shell_tty_info; + #else static struct sgttyb shell_tty_info; + #endif /* Fill the contents of shell_tty_info with the current tty info. */ get_tty_state () *************** *** 863,869 **** --- 886,896 ---- if (child->running || ((job != NO_JOB) && (JOBSTATE (job) == JRUNNING))) { + #ifdef IRIS4D + sigpause(SIGCHLD); + #else sigpause (0); + #endif goto wait_loop; } *************** *** 1040,1048 **** start_job (job, foreground) int job, foreground; { - int oldmask = sigblock (sigmask (SIGCHLD)); int already_running = jobs[job]->state == JRUNNING; register PROCESS *p; if (!foreground && already_running) { --- 1067,1075 ---- start_job (job, foreground) int job, foreground; { int already_running = jobs[job]->state == JRUNNING; register PROCESS *p; + int oldmask = sigblock (sigmask (SIGCHLD)); if (!foreground && already_running) { *************** *** 1109,1115 **** jobs[job]->notified = 1; killpg (jobs[job]->pgrp, SIGCONT); } - sigsetmask (oldmask); if (foreground) { --- 1136,1141 ---- *************** *** 1132,1141 **** kill_pid (pid, signal, group) int pid, signal, group; { - int old_mask = sigblock (SIGCHLD); register PROCESS *p = find_pipeline (pid); int job = find_job (pid); int result; if (group) { --- 1158,1167 ---- kill_pid (pid, signal, group) int pid, signal, group; { register PROCESS *p = find_pipeline (pid); int job = find_job (pid); int result; + int old_mask = sigblock (SIGCHLD); if (group) { *************** *** 1434,1439 **** --- 1460,1468 ---- } original_pgrp = shell_pgrp; + #ifdef IRIS4D + setpgrp(0,getpid()); + #endif shell_pgrp = getpid (); give_terminal_to (shell_pgrp); setpgrp (0, shell_pgrp); *************** *** 1454,1460 **** job_control = arg; if (job_control) ! signal (SIGCHLD, flush_child); else signal (SIGCHLD, SIG_DFL); } --- 1483,1490 ---- job_control = arg; if (job_control) ! {signal (SIGCHLD, flush_child); ! } else signal (SIGCHLD, SIG_DFL); } *************** *** 1532,1534 **** --- 1562,1656 ---- } } #endif /* JOB_CONTROL */ + + #ifdef IRIS4D + #undef ioctl + #include + + static int + jioctl(fd, cmd, arg) + int fd; + int cmd; + long arg; + { + struct termio tb; + + switch (cmd) { + case FIOCLEX: + fcntl(fd, F_SETFD, 1); + break; + case TIOCGETD: + ioctl(fd, TCGETA, &tb); + *((int *) arg) = tb.c_line; + break; + case TIOCSETD: + ioctl(fd, TCGETA, &tb); + tb.c_line = *((int *) arg); + ioctl(fd, TCSETA, &tb); + break; + case TIOCGETP: + return(ioctl(fd, TCGETA, arg)); + case TIOCSETP: + return(ioctl(fd, TCSETA, arg)); + case TIOCSETN: + return(ioctl(fd, TCSETAF, arg)); + default: + return(ioctl(fd, cmd, arg)); + } + return(0); + } + + /* + * This is how one sends a signal to a process group in system V. + */ + killpg(pgrp, signo) + int pgrp; + int signo; + { + if (pgrp < 0) + pgrp = -pgrp; + kill(-pgrp, signo); + } + + + + int sigheld = 0; /* Mask of held signals */ + + int sigblock (sigs) + int sigs; + { + int i,old; + for (i = 0; i < NSIG; i++) + if (sigs & sigbit (i)) + sighold (i); + old = sigheld; + sigheld |= sigs; + return(old); + } + + sigsetmask(sigset) + int sigset; + { + int newheld,newrel,tmp; + newheld = sigset & ~sigheld; + newrel = sigheld & ~sigset; + tmp = sigblock(newheld); + sigfree(newrel); + } + + sigfree (sigs) + int sigs; + { + int i; + for (i = 0; i < NSIG; i++) + if (sigs & sigbit (i)) + sigrelse (i); + sigheld &= ~sigs; + } + + sigbit (i) + int i; + { + return 1 << (i - 1); + } + #endif *** ../bash-orig/jobs.h Sun Aug 20 22:29:49 1989 --- jobs.h Tue Nov 14 22:43:13 1989 *************** *** 2,7 **** --- 2,10 ---- #include "quit.h" + #ifdef IRIS4D + #include + #endif #if !defined (SYSV) || defined (UNIXPC) #include #else *** ../bash-orig/trap.c Sat Aug 5 11:27:10 1989 --- trap.c Tue Nov 14 22:43:13 1989 *************** *** 60,65 **** --- 60,78 ---- "SIGUSR2", "SIGCLD", "SIGPWR", + #ifdef IRIS4D + "SIGSTOP", /* sendable stop signal not from tty */ + "SIGTSTP", /* stop signal from tty */ + "SIGPOLL", + "SIGIO", /* input/output possible signal */ + "SIGURG", /* urgent condition on IO channel */ + "SIGWINCH", /* window changed */ + "SIGVTALRM", /* virtual time alarm */ + "SIGPROF", /* profiling time alarm */ + "SIGCONT", /* continue a stopped process */ + "SIGTTIN", /* to readers pgrp upon background tty read */ + "SIGTTOU", /* like TTIN for output if (tp->t_local<OSTOP) */ + #endif #if NSIG == 23 "SIGJUNK1", "SIGJUNK2", *** ../bash-orig/variables.c Sun Sep 17 20:02:43 1989 --- variables.c Tue Nov 14 22:43:14 1989 *************** *** 27,33 **** --- 27,35 ---- #include "version.h" #ifdef SYSV + #ifndef IRIS4D struct passwd *getpwuid (), *getpwent (); + #endif #endif /* The list of shell variables that the user has created, or that came from *** ../bash-orig/version.h Sat Nov 4 12:40:00 1989 --- version.h Tue Nov 14 23:38:08 1989 *************** *** 4,7 **** /* The distribution version number of this shell. */ #define DISTVERSION 1.04 /* The last built version of this shell. */ ! #define BUILDVERSION 1 --- 4,7 ---- /* The distribution version number of this shell. */ #define DISTVERSION 1.04 /* The last built version of this shell. */ ! #define BUILDVERSION 2 *** ../bash-orig/alloc-files/malloc.c Wed Sep 13 20:02:16 1989 --- alloc-files/malloc.c Tue Nov 14 22:43:26 1989 *************** *** 144,149 **** --- 144,152 ---- #include "config.h" #endif /* emacs */ + #ifdef IRIS4D + #define USG + #endif #ifdef HPUX #define USG #endif *** ../bash-orig/readline/readline.c Sat Nov 4 08:42:01 1989 --- readline/readline.c Wed Nov 15 00:06:55 1989 *************** *** 63,70 **** --- 63,72 ---- #include #ifdef SYSV + #ifndef IRIS4D struct passwd *getpwuid (), *getpwent (); #endif + #endif #define HACK_TERMCAP_MOTION *************** *** 133,139 **** /* If on, then readline handles signals in a way that doesn't screw. */ #define HANDLE_SIGNALS ! #if defined (SYSV) #ifdef HANDLE_SIGNALS #undef HANDLE_SIGNALS #endif --- 135,141 ---- /* If on, then readline handles signals in a way that doesn't screw. */ #define HANDLE_SIGNALS ! #if defined (SYSV) && !defined (IRIS4D) #ifdef HANDLE_SIGNALS #undef HANDLE_SIGNALS #endif   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02300; 2 Feb 90 8:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01278; 2 Feb 90 7:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01242; 2 Feb 90 7:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02562; 2 Feb 90 7:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA16514; Fri, 2 Feb 90 03:49:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 08:49:40 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Convert TIFF image files to IRIS image file format Message-Id: <49544@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL 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`````:`````````&P```!(` M```,```'P````!L````3````#```"``````;````%`````P```A`````&P`` M`!4````,```(@````!L````6````#```",`````;````%P````P```D````` M&P```!P````,```)0````!L````=````#```"8`````;````'@````P```G` M````&P```!\````,```*`````!P````#````!_____T````<`````P````;_ M___^````'`````,````#_____P```!P````!`````0`````````<`````@`` M``,````!````'`````(````&`````@```!P````"````!P````,````<```` M`0````,```/H````'`````$````$```'T$9A>#,H861D=&]H87-H*0!&871A M;"!H87-H(&-O;&QI#-0 M#,@"`E9"D`1F%X,T1E8V]D93H@4')E;6%T=7)E($5/3"!A M="!S8V%N;&EN92`E9"`H>"`E9"D`1F%X,T1E8V]D93H@0F%D(&-O9&4@=V]R M9"`H;&5N("5D(&-O9&4@)60I(&%T('-C86YL:6YE("5D("AX("5D*0!&87@S M1&5C;V1E.B!"860@=&%B;&4@:60@*"5D*2!A="!S8V%N;&EN92`E9"P@*'@@ M)60I````"`<&!@4%!04$!`0$!`0$!`,#`P,#`P,#`P,#`P,#`P,"`@("`@(" M`@("`@("`@("`@("`@("`@("`@("`@("`@$!`0$!`0$!`0$!`0$!`0$!`0$! M`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````0$!`0$!`0$!`0$!`0$! M`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$!`0$! M`0$!`0("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`P,#`P,#`P,# M`P,#`P,#`P0$!`0$!`0$!04%!08&!PA3;W)R>2P@8V%N(&YO="!H86YD;&4@ M,BUD($9!6"!E;F-O9&EN9P!&87@S4')E16YC;V1E`"5S.B!-=7-T(&AA=F4@ M,2!B:70O#-0#,@ M"`E9``E7,`````5$E&1D%P<&5N9%1O4W1R:7`````E'R`A(B,D)28G*"DJ M*RPM+B\P,3(S-#4V-S@Y.CL\/3X_0&%B8V1E9F=H:6IK;&UN;W!Q'EZ6UQ=7E]@04)#1$5&1TA)2DM,34Y/4%%24U155E=865I[?'U^?P`````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````!#2%)#3$%34P`` M```O;&EB+V-H Organization: Univ. of Cincinnati, College of Engg. Subject: imged Message-Id: <3523@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The other day I saw what sounded like a neat little icon editor called 'imged'. The problem is is that I can only find the man page but no binary. The man page says see 'ipaste' as well. I found that, its in /usr/sbin but there was no 'imged'. Any clues???? For the stats: we got a 120GTX running 3.2. Gratas, Tom Rohling   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10395; 2 Feb 90 15:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10038; 2 Feb 90 14:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10017; 2 Feb 90 14:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18659; 2 Feb 90 13:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12105; Fri, 2 Feb 90 10:33:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 18:18:37 GMT From: Keith Bierman - SPD Advanced Languages Organization: Sun Microsystems Subject: Re: Array boundary checking & Fortran <> C translators Message-Id: References: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca>, <65973@aerospace.AERO.ORG> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <65973@aerospace.AERO.ORG> tak@aerospace.aero.org (Michael L. Takayama) writes: If you are calling Fortran subroutines from C, you may want to be aware of the following problem which I ran into: In certain cases, floats do *not* pass correctly to REALs. This problem does not occur with ints to INTEGERs nor with doubles to DOUBLE PRECISIONs. .... Maybe I am doing something illegal here and just got lucky with the ints and doubles passing correctly (I don't think so - I have ... The problem is that K&R C implementations traditionally promote all floats to doubles for both computational and parameter passing purposes. ANSI C "fixes" this, by allowing one to create function prototypes which say explicitly what you want. SunC (pre-ANSI) fixed this with a compiler option (dangerous, breaks linkage to many basic C libraries) and via special macros for the C programmer. Other vendors have provided other solutions over the years. Those doing multi-lingual coding on Unix (pre V.4) may chose to work around the issue by only attempting to pass double and integer data types around. -- Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM It's Not My Fault | MTS --Only my work belongs to Sun* kbierman%eng@sun.com I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10882; 2 Feb 90 15:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10395; 2 Feb 90 15:07 EST Received: from tbd.brl.mil by VMB.BRL.MIL id aa10112; 2 Feb 90 14:36 EST Date: Fri, 2 Feb 90 14:35:50 EST From: "John A. Condon" (BDB) To: info-iris@BRL.MIL cc: jac@BRL.MIL Subject: Screen size Message-ID: <9002021435.aa23460@TBD.BRL.MIL> Hello users! Do any of you know how to reset the screen size of your graphics monitor? I believe the command is "viewport" but where is the program that it's in? What I want to do is show my graphics from the high resolution monitor (60 Hz) on a RS 170 NTSC video monitor. What happens now is that portions of the graphics are "cut-off" when I display them on the smaller-sized video screen. ........help!! - John (alias, ..the Jersey Renegade)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11611; 2 Feb 90 16:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11338; 2 Feb 90 16:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11219; 2 Feb 90 15:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22731; 2 Feb 90 15:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18904; Fri, 2 Feb 90 12:14: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: 2 Feb 90 19:22:19 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Crashing the window manager ( Yet another way to do it) Message-Id: <3522@odin.SGI.COM> References: <6619@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <6619@ubc-cs.UUCP>, buchanan@cs.ubc.ca (John Buchanan) writes: > > The recent postings about programs that crash the window server has prompted > me to try to produce the following gem. We are running an application which > requires interrupt handling. The problem is that trying to do some graphics > after an interrupt (SIGINT) has occurred crashes the machine. The original > program showed this problem in a somewhat non deterministic fashion, the > program that follows crashes the machine after the first interrupt. This is no suprise. If you are busy sending graphics down the pipe then asre interrupted by a signal and start sending unrelated and unexpected graphics down the pipe you are bound to crash it. Imagine you and inside a bgnpolygon(), endpolygon() pair when you are interrupted and your interrupt routine does a rectf or a winset. The correct way to deal with signals is to have the signal handlers set flags which your main loop checks regularly at times known to be safe. This is a fairly common UNIX coding practice (especially with System V signals) regardless of graphics. -- 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 ab11611; 2 Feb 90 16:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11338; 2 Feb 90 16:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab11219; 2 Feb 90 15:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22794; 2 Feb 90 15:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA18873; Fri, 2 Feb 90 12:13:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 19:43:58 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Array boundary checking & Fortran <> C translators Message-Id: <49566@sgi.sgi.com> References: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca>, <65973@aerospace.AERO.ORG> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <65973@aerospace.AERO.ORG> tak@aero.UUCP (Michael L. Takayama) writes: [stuff deleted, some text below rearranged to save space....] >In certain cases, floats do *not* pass correctly to REALs. This >problem does not occur with ints to INTEGERs nor with doubles to >DOUBLE PRECISIONs. >main() >{ double a; float b; int c; > a = 1234.5678; /* Assign values. */ > b = 9876.1234; > c = 121162; > /* Call C routine which calls Fortran routine. */ > subtestc(a, b, c); >} >*** subtest.c *** >subtestc(a, b, c) >double a; >float b; >int c; >{ float temp; > temp = b; /* This is my work-around. */ > /* Call the Fortran routine. */ > subtest_(&a, &b, &c, &temp); >} [stuff deleted] >Maybe I am doing something illegal here and just got lucky with the ^^^^^^^^^^^^^^^^^^^^^^^ Yes, you are. >ints and doubles passing correctly (I don't think so - I have >about 60 routines mixing C and Fortran which *do* work correctly), but I >notified the Hotline and they think it is an undiscovered bug in >the Fortran compiler. No bug here. The problem is the way automatic conversions of float to double are treated in K&R C (See K&R 1, page 205 ``formal parameters declared float have their declaration adjusted to read double''). Parameter b in subtestc is called a float but *is really a double*. Thus, subtest_(&a,&b,&c,&temp) passes a pointer (&b) which appears to be a pointer to a float but is really a pointer to a double. Consequently dereferencing the pointer results in garbage. In ANSI C, the behaviour is required to be different: your code would work with an ANSI C compiler. The reason is that while there would be an argument which was a float-converted-to-double, b would be a float and the compiler would generate an assignment in subtestc's entry to assign and convert the argument to the float b. (ANSI sec 3.5.4.3, 3.7.1, 3.3.2) Hope this helps. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12049; 2 Feb 90 17:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11884; 2 Feb 90 16:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11769; 2 Feb 90 16:33 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23225; 2 Feb 90 15:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19928; Fri, 2 Feb 90 12:29:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 19:15:52 GMT From: "Frank J. Henigman" Organization: U. of Waterloo, Ontario Subject: Re: Array boundary checking & Fortran <> C translators Message-Id: <13215@watcgl.waterloo.edu> References: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca>, <65973@aerospace.AERO.ORG> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Your problem arises from the fact that the C compiler does not allow floats as formal parameters - they are converted to doubles. Thus, the variable "b" in "subtestc" is actually a double even though it is declared as float. The following code demonstrates this behaviour. ----------------------------------------------------------------------------- bar(fp) float *fp; { printf("%f <--- `wrong'\n", *fp); } foo(fpf) float fpf; { bar(&fpf); } main() { float f = 9876.1234; printf("%f <--- right\n", f); foo(f); } ----------------------------------------------------------------------------- 9876.123047 <--- right 6.102790 <--- `wrong' -- fjhenigman@watcgl.uwaterloo.ca Computer Graphics Lab fjhenigman@watcgl.waterloo.edu Frank J. Henigman University of Waterloo ...!watmath!watcgl!fjhenigman Waterloo, Ontario, Canada   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12798; 2 Feb 90 19:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab12754; 2 Feb 90 19:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12748; 2 Feb 90 19:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26941; 2 Feb 90 19:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA01310; Fri, 2 Feb 90 15:26:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 22:52:36 GMT From: Andrew Myers Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: imged Message-Id: <3529@odin.SGI.COM> References: <3523@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3523@uceng.UC.EDU> trohling@uceng.UC.EDU (tom rohling) writes: > > The other day I saw what sounded like a neat little icon editor called >'imged'. The problem is is that I can only find the man page but no binary. >The man page says see 'ipaste' as well. I found that, its in /usr/sbin but >there was no 'imged'. Any clues???? For the stats: we got a 120GTX running >3.2. > >Gratas, > >Tom Rohling You probably didn't install it off of the 3.2 tape. If I remember correctly, imged is installed in the "eoe2.sw.moregltools" package, which is not installed by default. You can install it by going into Manual mode in the installation procedure, and then selecting this package. In future release, imged will be installed by default. Andrew   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab12798; 2 Feb 90 19:39 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac12754; 2 Feb 90 19:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab12748; 2 Feb 90 19:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26945; 2 Feb 90 19:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA29955; Fri, 2 Feb 90 15:06:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 11:53:03 GMT From: Urs Meyer Organization: University of Zurich, Department of Computer Science Subject: Re: Proper TERM via telnet Message-Id: <1990Feb2.115303.12899@gorgo.ifi.unizh.ch> References: <9001312017.ab19659@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9001312017.ab19659@SMOKE.BRL.MIL> JORDAN@gmr.COM writes: >From time to time, I access my 4D70 via telnet with a VaxStation 3500. >Does anyone out there know how the proper tset configuration so that >when I login via telnet, the terminal type will be vt100. > >Presently on the Vax when I do a "tset -", it returns "unknown". >thanx. tp mugabi-jordan Below is the beginning of my .login file. We use qterm (comp.sources.unix, Volume 11) to query (intelligent) Terminals for their types. This kind of settings expects that the term variables are correctly set when you login using telnet. Some programs propagate them. I'm using almost the same .login file on 4.3BSD, SunOS 4.0.3 and Ultrix, except for the stty line. PS: Unfortunately, iris-ansi terminals do no longer answer the ANSII query escape code. (I think it worked with mex, not sure about 4sight 1.0) ------ stty line 1 erase '^H' kill '^U' intr '^C' echoe if ( ! ${?term} ) set term = `tset - -I -Q` if ( $term == "unknown" || $term == "network" ) then set term = `/usr/local/bin/qterm -a` endif if ( $term == dumb ) then set noglob; eval `tset -s -Q '?concept'`; unset noglob else set noglob; eval `tset -s -Q`; unset noglob endif ------ Urs Meyer ---------- meyer@ifi.unizh.ch, {uunet,...}!mcsun!cernvax!unizh!meyer University of Zurich, Dept of Computer Science, Multimedia Lab, CH-8057 Zurich   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13110; 2 Feb 90 20:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13029; 2 Feb 90 20:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab12998; 2 Feb 90 20:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27449; 2 Feb 90 20:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06783; Fri, 2 Feb 90 16:53:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 90 21:40:42 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: Re: imged Message-Id: <376@meritaus.UUCP> References: <3523@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL strange... I'm in just the opposite situation. I have the binary to 'imged', but don't have the man page for it... -- dan haug ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan ``When all you have is a hammer, everything begins to look like a nail.''   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01355; 4 Feb 90 3:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01313; 4 Feb 90 2:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01293; 4 Feb 90 2:40 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04963; 4 Feb 90 2:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09208; Sat, 3 Feb 90 23:24: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: 4 Feb 90 07:23:19 GMT From: Eddy Wong Organization: University of Toronto Computing Services Subject: IRIS 4D/20 memory upgrade Message-Id: <1990Feb4.072319.13990@gpu.utcs.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I want to upgrade an IRIS 4D/20 from 8 Meg to 16 Meg. However, I do not know what kind of memory is suitable for the upgrade. Could someone please tell me what kind of memory I need for the upgrade ? Eddy Wong ewong@gpu.utcs.utoronto.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00494; 4 Feb 90 8:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00204; 4 Feb 90 8:02 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa00183; 4 Feb 90 7:48 EST Date: Sun, 4 Feb 90 3:39:21 EST From: Mike Muuss To: Info-Iris@BRL.MIL Subject: Bug in CU Message-ID: <9002040339.aa01568@SPARK.BRL.MIL> This evening I tried sending a file to another machine with CU, and encountered a nasty problem that has existed since 3.1: ~%debug ~%put file.c call tilda(%put file.c) call _dopercen("put file.c") call _mode(2) stty -echo;(cat - >file.c)||cat - >/dev/null;stty echo r Can't transmit special character `012' call _mode(1) + File transmission interrupted after 4 bytes 4 characters $ The first few characters of this particular file were slash star newline space star newline space star, ie, /* * * stuff... Very odd that CU won't send newlines! This problem exists (at least) on a PI (4D/25) running 3.2.1 Another one for the E-mail hotline. Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01591; 4 Feb 90 16:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01463; 4 Feb 90 15:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01458; 4 Feb 90 15:38 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09964; 4 Feb 90 15:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14455; Sun, 4 Feb 90 12:24:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Feb 90 20:19:23 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Saving a file with a dialog box Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have written a small program to rotate 3D graphical objects with the mouse and I would like to save a rotation matrix into a file with a menu option. My (possibly naive) question is how do I get the program to prompt and read the file name from the user? Should I use a wsh window for text I/O? What then happens if the application was not launched from a wsh window in the first place? What I would really like to do is the equivalent of the Macintosh routine SFPutFile, but on a Silicon Graphics Iris 4D/120 GTX. For example, in saving a file on the Macintosh, you would do something like this: SFPutFile(SFPutPoint, 'Save File as ...', title, NIL, theReply); where a standard dialog box asking for a file name to save a file into appears. The user can type a file name or cancel (e.g. IF theReply.good THEN ...). The filename would be returned in theReply.fname. How does one create such a dialog box with buttons and a text field in 4Sight using the GL/DGL interface? George Elkins   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03140; 5 Feb 90 1:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02915; 5 Feb 90 0:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02900; 5 Feb 90 0:22 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13561; 5 Feb 90 0:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13277; Sun, 4 Feb 90 21:09: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: 5 Feb 90 05:06:52 GMT From: Ken Lalonde Organization: Department of Computer Science, University of Toronto Subject: IRIX 3.2 C compiler bug Message-Id: <90Feb5.000622est.4918@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On a 4D/240S running 3.2: % cat t.c main() { double a,b,c; b = 1.0; c = 2.0; a = b==c; printf("a=%f\n",a); } % cc t.c % ./a.out a=2147469288.000000   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07874; 5 Feb 90 11:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06878; 5 Feb 90 10:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06803; 5 Feb 90 10:13 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22927; 5 Feb 90 10:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13599; Mon, 5 Feb 90 06:54: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: 5 Feb 90 14:37:07 GMT From: Mark VandeWettering Organization: Princeton University Subject: Re: IRIX 3.2 C compiler bug Message-Id: <13583@phoenix.Princeton.EDU> References: <90Feb5.000622est.4918@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Feb5.000622est.4918@neat.cs.toronto.edu> ken@cs.toronto.edu (Ken Lalonde) writes: >On a 4D/240S running 3.2: > % cat t.c > main() > { > double a,b,c; > > b = 1.0; > c = 2.0; > a = b==c; > printf("a=%f\n",a); > } > % cc t.c > % ./a.out > a=2147469288.000000 Just what did you expect this to return? Unless I am mistaken, ANSI C still doesn't any distinction about what number is returned, only that it is NOT zero, which is certainly the case for your code here. It is probably also true that comparison of floating point numbers is an inherently dicey proposition. It is also probably bad practice to use a "double" to receive the results of a comparison, the result is usually concieved as an integer quantity. The implicit conversion in the statement above is a little strange and misleading. If I have a complaint, it is that compilers tend not to warn someone of such inherently unportable code. I guess the maxim would be "A correct compiler shouldn't have to compile incorrect programs". Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11423; 5 Feb 90 15:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11128; 5 Feb 90 15:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11046; 5 Feb 90 14:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00154; 5 Feb 90 13:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27864; Mon, 5 Feb 90 10:42: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: 5 Feb 90 18:40:44 GMT From: Conrad Huang Subject: Re: IRIX 3.2 C compiler bug Message-Id: <12999@cgl.ucsf.EDU> References: <90Feb5.000622est.4918@neat.cs.toronto.edu>, <13583@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >>On a 4D/240S running 3.2: >> % cat t.c >> main() >> { >> double a,b,c; >> >> b = 1.0; >> c = 2.0; >> a = b==c; >> printf("a=%f\n",a); >> } >> % cc t.c >> % ./a.out >> a=2147469288.000000 >Just what did you expect this to return? Unless I am mistaken, ANSI C >still doesn't any distinction about what number is returned, only that >it is NOT zero, which is certainly the case for your code here. It is probably >also true that comparison of floating point numbers is an inherently dicey >proposition. Say what!? In K&R, Appendix A, page 189, Section 7.6, "The operators < (less than), > (greater than), <= (less than or equal to) and >= (greater than or equal to) all yield 0 if the spricified relation is false, and 1 if it is true" and on page 190, Section 7.7, "The == (equal to) and the != (not equal to) operators are exactly analogous to the relation operators except for their lower precedence." Please tell me if ANSI C has revoked these statements! So... In the first place, the program ought to print 0, since 1.0 == 2.0 is *false*. In the second place, even if they were equal, it should print 1.000000. Conrad   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11423; 5 Feb 90 15:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11128; 5 Feb 90 15:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11124; 5 Feb 90 14:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01386; 5 Feb 90 14:24 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28626; Mon, 5 Feb 90 10:53:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Feb 90 18:17:45 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIX 3.2 C compiler bug Message-Id: <49687@sgi.sgi.com> References: <90Feb5.000622est.4918@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90Feb5.000622est.4918@neat.cs.toronto.edu>, ken@cs.toronto.edu (Ken Lalonde) writes: > double a,b,c; > b = 1.0; > c = 2.0; > a = b==c; The cc bug is in assigning the required 1 or 0 to a double where the conditional involves doubles: int i; i = (a==c); and if(a ==c) .... etc.... work ok. It has been fixed for the release after 3.2. Sorry for the inconvenience. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12158; 5 Feb 90 15:44 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10470; 5 Feb 90 14:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10342; 5 Feb 90 13:53 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29122; 5 Feb 90 13:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA25792; Mon, 5 Feb 90 10:13: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: 5 Feb 90 15:39:17 GMT From: dave "who can do? ratmandu!" ratcliffe Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Saving a file with a dialog box Message-Id: <3569@odin.SGI.COM> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article elkins@topaz.rutgers.edu (George Elkins) writes: ...stuff about a Mac dialog box programming call... >How does one create such a dialog box with buttons and a text field in >4Sight using the GL/DGL interface? not sure this will really give you all you want, (no "buttons" in this implementation--just a carriage return to signal "i'm done") but IF you have 3.2, run /usr/sbin/snapshot and check out the way i programmed the little "textport" window that comes up when you specify via the mouse that you wish to change the filename you want to save yer image out to. (see ~4Dgifts/iristools/imgtools/snapshot.c for the source). a more rudimentary version of this "textport" derives from ~4Dgifts/examples/grafix/prompt.c which has a main that simply invokes the psuedo-textport routine. -- daveus rattus yer friendly neighborhood ratman KOYAANISQATSI ko.yan.nis.qatsi (from the Hopi Language) n. 1. crazy life. 2. life in turmoil. 3. life out of balnace. 4. life disintegrating. 5. a state of life that calls for another way of living.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13455; 5 Feb 90 16:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12933; 5 Feb 90 16:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12913; 5 Feb 90 16:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04406; 5 Feb 90 15:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA06155; Mon, 5 Feb 90 12:44: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: 5 Feb 90 19:13:03 GMT From: "Gavin A. Bell" Subject: Re: Saving a file with a dialog box Message-Id: <3581@odin.SGI.COM> References: , <3569@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >In article elkins@topaz.rutgers.edu (George Elkins) writes: >>How does one create such a dialog box with buttons and a text field in >>4Sight using the GL/DGL interface? Well, I thought up this little hack just two or three weeks ago, so I can't guarantee that it is perfect yet. However, it is a very good starting point. Let me give you the code, then explain what exactly it is doing: --------- code follows -------- /* * s is the string the user's response will be put into * len_s is the length of s (so we won't overflow it) * m is the message prompt */ void GetInputFromUser(char *s, int len_s, const char *m) { char launchline[300]; FILE *fp; sprintf(launchline, "launch -h echo -m \"%s\"", m); if ((fp = popen(launchline, "r")) != NULL) { fgets(s, len_s, fp); pclose(fp); /* Strip off trailing newline */ if (s[0] != '\0' && s[strlen(s)-1] == '\n') { s[strlen(s)-1] = '\0'; } } else s[0] = '\0'; } ----------- end of code ---------- This code uses the 'launch' command to do all of the dirty work. It launches an 'echo' command, which will just echo back whatever the user types, which is sent back to the program through the magic of popen(). Good things about this code: It is short and easy. The launch command allows you to edit the field in lots of ways, including using Copy/Paste and the mouse. Bad things about this code: The program will ignore all events while the prompter is up; if the user moves either window, an ugly display is likely to result. This won't work unless the user is on the graphics console (an OK assumption if this is a graphics program that requires mouse/keyboard input). This won't work with the Distributed Graphics Library. The 'launch' command is in version 3.2 of the OS; I don't know if it was around before then. You might also want to check out the 'confirm' and 'inform' commands... --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14568; 5 Feb 90 17:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14159; 5 Feb 90 17:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14044; 5 Feb 90 16:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05130; 5 Feb 90 16:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA07415; Mon, 5 Feb 90 13:04:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Feb 90 20:03:01 GMT From: Mark VandeWettering Organization: Princeton University Subject: Re: IRIX 3.2 C compiler bug (Mark Gets Pie in the Face) Message-Id: <13600@phoenix.Princeton.EDU> References: <90Feb5.000622est.4918@neat.cs.toronto.edu>, <13583@phoenix.Princeton.EDU>, <12999@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <12999@cgl.ucsf.EDU> conrad@cgl.ucsf.edu (Conrad Huang) writes: >Say what!? In K&R, Appendix A, page 189, Section 7.6, > > "The operators < (less than), > (greater than), <= (less than or > equal to) and >= (greater than or equal to) all yield 0 if the > spricified relation is false, and 1 if it is true" Gadzooks. I went back and looked this up, and you were right. I had always operated on the assumption that the only thing you knew about TRUE was that it wasn't zero. Oh well, pie in my face number one. >In the first place, the program ought to print 0, since 1.0 == 2.0 is *false*. >In the second place, even if they were equal, it should print 1.000000. Actually, if we wanna get really technical about it, this program shouldn't work at all, because you passed a double to the printf, when in fact it wants a float argument. This usually works out, but I have had it fail on various machines (particularly mips based ones) in very odd ways, so one should be careful. But ignoring that, you are of course correct. It should return 0.0000 and doesn't. Pie in the face #2 for me. That's what I get for posting late at night. Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15173; 5 Feb 90 18:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15130; 5 Feb 90 18:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15128; 5 Feb 90 18:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06601; 5 Feb 90 17:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13061; Mon, 5 Feb 90 14:27:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Feb 90 22:08:51 GMT From: pa1081 Organization: University of California, San Diego Subject: rtar, rdump on SGI's Message-Id: <7032@sdcc6.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to do central administration on our SGI's by backing them up and doing all tape operations through our alliant FX/80 which has a 1/2" tape drive. When I called sgi customer support, they informed me that this would not be possible (due to byte swaps and such). The question is, does anyone know of a way or public domain routines that allow tape operations over the network between SGI Personal IRIS's and 4.3bsd systems like the Alliant? Please let me know.... Steve Diggs {uunet, ucsd}!photon!steve   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15263; 5 Feb 90 19:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15173; 5 Feb 90 19:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15169; 5 Feb 90 18:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07055; 5 Feb 90 18:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14919; Mon, 5 Feb 90 14:55:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Feb 90 22:42:02 GMT From: Jeremy Webber Organization: Digital Arts Film and Television Subject: Key mappings under 4Sight 1.0 Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have just started using a Personal Iris with 4Sight, and wish to change some of the key mappings, specifically (in decreasing order of importance): Make the key labelled "Backspace" return a DEL Make the key labelled "Caps Lock" act like a Control key Make the key labelled "Control" act like a META key These are needed so I can make GNU Emacs work sensibly in a wsh(1) window. Does anyone have the code necessary to insert into the "user.ps" file? Can anyone tell me how to remap keys in general under 4sight? Yes, I have read TFM (the 4sight guides), and tried to wade through the megabytes of postscript it seems to be necessary to be intimate with in order to customize this window system. -jeremy -- -- Jeremy Webber ACSnet: jeremy@chook.ua.oz Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au 60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430 Australia Papernet: +61 8 272 2774 (FAX)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15416; 5 Feb 90 20:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15368; 5 Feb 90 19:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15348; 5 Feb 90 19:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08275; 5 Feb 90 19:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19698; Mon, 5 Feb 90 16:08: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: 5 Feb 90 23:55:50 GMT From: John H Merritt Organization: Goddard Space Flight Center Climate and Radiation Branch Subject: Re: Key mappings under 4Sight 1.0 Message-Id: <816@dftsrv.gsfc.nasa.gov> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article jeremy@cs.ua.oz.au (Jeremy Webber) writes: >I have just started using a Personal Iris with 4Sight, and wish to change some >of the key mappings, specifically (in decreasing order of importance): > > Make the key labelled "Backspace" return a DEL > Make the key labelled "Caps Lock" act like a Control key > Make the key labelled "Control" act like a META key > >These are needed so I can make GNU Emacs work sensibly in a wsh(1) window. > >Does anyone have the code necessary to insert into the "user.ps" file? Can >anyone tell me how to remap keys in general under 4sight? Yes, I have read TFM >(the 4sight guides), and tried to wade through the megabytes of postscript it >seems to be necessary to be intimate with in order to customize this window >system. > > -jeremy >-- >-- >Jeremy Webber ACSnet: jeremy@chook.ua.oz >Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au >60 Hutt St, Adelaide 5001, Voicenet: +61 8 223 2430 >Australia Papernet: +61 8 272 2774 (FAX) %! %%I forget where I got this, but it works great... %% %%Optionally modify the call to replacekeys, then put it in your user.ps. %% %% /replacekeys { % origkeyvals_array changedkeyvals_array -> - { /changedvals exch def /origvals exch def /keysdict origvals length dict def keysdict begin 0 1 origvals length 1 sub { dup origvals exch get changedvals 3 2 roll get def } for end createevent dup begin /Name origvals def /Priority 2 def /Exclusivity true def end expressinterest { awaitevent dup dup begin /Name get keysdict exch get /Name exch def end redistributeevent } loop } fork pop pop pop } def % Capslock becomes CTRL % Right CTRL becomes Capslock % backspace becomes delete % delete becomes backspace [28420 28561 28477 28478] [28419 28420 28478 28477] replacekeys % 28423 Escape % 28562 F1 % 28563 F2 % 28564 F3 % 28565 F4 % 28566 F5 % 28567 F6 % 28568 F7 % 28569 F8 % 28570 F9 % 28571 F10 % 28572 F11 % 28573 F12 % 28574 Print Screen % 28575 Scroll Lock % 28576 Pause % 28471 ` and ~ % 28424 1 and ! % 28430 2 and @ % 28431 3 and # % 28438 4 and $ % 28439 5 and % % 28446 6 and ^ % 28447 7 and & % 28454 8 and * % 28455 9 and ( % 28462 0 and ) % 28463 - and _ % 28470 = and + % 28477 Backspace % 28577 Insert % 28578 Home % 28579 Page Up % 28582 Keypad Num Lock % 28583 Keypad / % 28584 Keypad * % 28492 Keypad - % 28425 Tab and Backtab % 28426 q % 28432 w % 28433 e % 28440 r % 28441 t % 28448 y % 28449 u % 28456 i % 28457 o % 28464 p % 28465 [ and { % 28472 ] and } % 28473 \ and | % 28478 Delete % 28580 End % 28581 Page Down % 28483 Keypad 7 % 28484 Keypad 8 % 28491 Keypad 9 % 28585 Keypad + % 28420 Caps Lock % 28427 a % 28428 s % 28434 d % 28435 f % 28442 g % 28443 h % 28450 j % 28451 k % 28458 l % 28459 ; and : % 28466 ' and " % 28467 Enter % 28479 Keypad 4 % 28485 Keypad 5 % 28486 Keypad 6 % 28422 Shift (left side) % 28436 z % 28437 x % 28444 c % 28445 v % 28452 b % 28453 n % 28460 m % 28461 , and < % 28468 . and > % 28469 / and ? % 28421 Shift (right side) % 28497 uparrow % 28474 Keypad 1 % 28480 Keypad 2 % 28481 Keypad 3 % 28498 Keypad Enter % 28419 Ctrl (left side) % 28559 Alt (left side) % 28499 Spacebar % 28560 Alt (right side) % 28561 Ctrl (right side) % 28489 leftarrow % 28490 downarrow % 28496 rightarrow % 28475 Keypad 0 % 28482 Keypad . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 aa15717; 5 Feb 90 20:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15570; 5 Feb 90 20:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15547; 5 Feb 90 20:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08718; 5 Feb 90 20:21 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA23671; Mon, 5 Feb 90 17:11:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Feb 90 00:39:46 GMT From: Robert Adsett Organization: University of Waterloo, Waterloo Ontario, Canada Subject: Re: IRIX 3.2 C compiler bug (Mark Gets Pie in the Face) Message-Id: <971@watserv1.waterloo.edu> References: <13583@phoenix.Princeton.EDU>, <12999@cgl.ucsf.EDU>, <13600@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13600@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU (Mark VandeWettering) writes: >In article <12999@cgl.ucsf.EDU> conrad@cgl.ucsf.edu (Conrad Huang) writes: >> >>In the second place, even if they were equal, it should print 1.000000. > >Actually, if we wanna get really technical about it, this program shouldn't >work at all, because you passed a double to the printf, when in fact it >wants a float argument. This usually works out, but I have had it fail >on various machines (particularly mips based ones) in very odd ways, so >one should be careful. No, floats get expanded to doubles when they are passed. Printf expects to receive a double. If this fails on some machines then either their compiler or library is broken. In ANSI C when a prototype indicates a float parmaeter then there is no implicit conversion. -- Robert Adsett Dept. of Phys, Univ. of Waterloo, Waterloo Ont. Canada   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16013; 5 Feb 90 22:12 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15919; 5 Feb 90 22:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15903; 5 Feb 90 21:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09753; 5 Feb 90 21:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA27680; Mon, 5 Feb 90 18:13: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: 5 Feb 90 17:38:04 GMT From: "Michael L. Takayama" Organization: The Aerospace Corporation, El Segundo, CA Subject: Re: Array boundary checking & Fortran <> C translators Message-Id: <66244@aerospace.AERO.ORG> References: <90Jan25.135818est.57895@ugw.utcs.utoronto.ca>, <65973@aerospace.AERO.ORG>, <49566@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Thanks for the reminder... guess that it is time to re-read the ol' K&R! Verification, please - automatic conversion of float to double occurs in the parameter declaration of a function in C. When calling a Fortran routine from C, this conversion does *not* occur, i.e. a float passed from C to Fortran should be correctly interpreted as a REAL? Example: subtestc() { float a; a = 1234.5678; subtestf_(&a); } SUBROUTINE SUBTESTF(A) REAL A WRITE(*,*) A RETURN END Thanks again (wish you guys were on the Hotline!) - Michael L. Takayama Computer-Aided Engineering Department The Aerospace Corporation   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02602; 6 Feb 90 8:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02368; 6 Feb 90 8:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02033; 6 Feb 90 7:56 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa15000; 6 Feb 90 7:27 EST Received: Mon, 5 Feb 90 09:41:26 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 5 Feb 90 09:41:26 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <9002051741.AA18360@aero4.larc.nasa.gov> To: elkins@topaz.rutgers.edu Subject: Re: Saving a file with a dialog box Cc: info-iris@BRL.MIL The way I do things like that is to "winpush" the application back, open a null window using "noport", then close the window. The window you executed the program from will now be ready for input, just do standard keyboard i/o. I have to do this on our 3130, I don't know if all this is necessary on a 4D or not. We have a 4D/240 for evaluation and the programs I have ported there use this technique. -- 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 aa17149; 6 Feb 90 2:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17016; 6 Feb 90 2:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17003; 6 Feb 90 2:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12713; 6 Feb 90 2:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA15092; Mon, 5 Feb 90 23: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: 6 Feb 90 06:24:11 GMT From: "Steven H. Izen" Organization: Case Western Reserve University Subject: Re: Key mappings under 4Sight 1.0 Message-Id: <4795@amelia.nas.nasa.gov> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article jeremy@cs.ua.oz.au (Jeremy Webber) writes: >I have just started using a Personal Iris with 4Sight, and wish to change some >of the key mappings, specifically (in decreasing order of importance): > > Make the key labelled "Backspace" return a DEL > Make the key labelled "Caps Lock" act like a Control key > Make the key labelled "Control" act like a META key > >These are needed so I can make GNU Emacs work sensibly in a wsh(1) window. I am currently dealing with figuring this out myself, but for me it's low priority right now. However, I do have an excellent workaround if your goal is to get a sensible emacs. Assuming, that your PI has Xsgi running on it, and the X development kit, just build emacs to run under X. I tried this, and to my astonishment the alt-key worked as the meta-key with no prodding on my part. Then the rest of your changes become somewhat standard emacs hacks (see gnu.emacs for details-don't ask me for help with lisp...) -- Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner: or steve@izen386.math.cwru.edu / or izen@cwru.cwru.edu /-------------------------/ My second bike is a car. | Klein bottle for sale - Inquire within.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02602; 6 Feb 90 8:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01639; 6 Feb 90 7:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01462; 6 Feb 90 7:43 EST Received: from [192.12.62.50] by SMOKE.BRL.MIL id aa15125; 6 Feb 90 7:35 EST Received: Tue, 6 Feb 90 08:19:54 AST by pig.drea.dnd.ca (5.52/5.6) Date: Tue, 6 Feb 90 08:19:54 AST From: Jim Diamond Message-Id: <9002061219.AA12580@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: Anyone know SCSI disks? We have a 4D/50 GTB running 3.2. Due to lack of disk space, we are testing out a second disk drive, but I have a few concerns which I hope some kind soul can help me out with. (Yes, I would have rather just bought a drive from SGI, but by plugging in my own I can save about $9000 or $10,000. I realize that the extra money goes toward the support of such questions, but I don't have that sort of money. Nuff said?) Basically, my concerns fall into 3 categories: 1) Are the default drive parameters below correct for a CDC Wren V disk (model 94181-702)? In particular, should I set it to (a) transfer bad blocks; (b) do auto reallocation of bad blocks (c) enable drive read-ahead and are the read- and write-buffer ratios appropriate? Are the tracks/zone and alternate sectors/zone reasonable? 2) How many cylinders at the end should I not allocate to file systems? The SGI disk (apparently) uses 25 cylinders, which strikes me as excessive. On the other hand, I must admit to a lack of knowledge of SCSI disks. 3) When 4Sight fires up, it complains CIO: dks0d2s10 volume header not valid (see below). Should I worry about this? If so, how do I fix it? I realize there are a lot of questions here, but any light that anyone could shed on even a subset of these questions would be most appreciated. Thanks. Jim Diamond zsd@pig.drea.dnd.ca ----------------------------------------------------------------------- Here's the parameters for the SGI-supplied system disk. # fx fx version 1.2; Sat Aug 19 11:05:46 PDT 1989 fx: "device-name" = (dksc) fx: ctlr# = (0) fx: drive# = (1) ...opening dksc(0,1,) ...controller test...OK Scsi drive type == TOSHIBA MK156FB . . . fx/label/show> 6 ----- current drive parameters ----- Error correction enabled Enable data transfer on error Don't report recovered errors Do delay for error recovery Do transfer bad blocks Do auto reallocation of bad blocks Err retry count = 27 Tracks/zone = 8270 Sect/track = 36 Alt sect/zone = 1 Interleave = 1 Cylinders = 827 Alt track/volume = 20 Cylinder skew = 10 Heads = 10 Alt track/zone = 20 Track skew = 0 Data bytes/sect = 578 Cert Pattern = 14799 ----- partitions ----- part type base+size (sectors) 0: efs 6+91 (32760) 6: efs 297+505 (181800) 1: rawdata 97+200 (72000) 7: efs 6+796 (286560) 2: efs 297+505 (181800) 8: volhdr 0+6 (2160) 5: efs 297+505 (181800) 10: entire 0+802 (288720) ----- bootinfo ----- root partition = 0 swap partition = 1 bootfile = /unix ----- directory entries ----- 0: sgilabel block 360 size 280 4: ktbl_us block 367 size 1024 1: ktbl_de block 361 size 1024 5: sash block 369 size 175104 2: ktbl_fr block 363 size 1024 6: symmon block 1214 size 50176 3: ktbl_uk block 365 size 1024 ----- sgi-info ----- serial = 0000 name = TOSHIBA MK156FB . . . ---------------------------------------------------------------- And here's what I have for the new disk. # fx fx version 1.2; Sat Aug 19 11:05:46 PDT 1989 fx: "device-name" = (dksc) fx: ctlr# = (0) fx: drive# = (1) 2 ...opening dksc(0,2,) ...controller test...OK Scsi drive type == CDC 94181-15 . . . fx/label/show> 6 ----- current drive parameters ----- Error correction enabled Enable data transfer on error Don't report recovered errors Do delay for error recovery Don't transfer bad blocks Don't auto reallocation of bad blocks Drive read-ahead disabled Read buffer ratio 4/256 Write buffer ratio 4/256 Err retry count = 27 Tracks/zone = 1 Sect/track = 52 Alt sect/zone = 1 Interleave = 1 Cylinders = 1546 Alt track/volume = 30 Cylinder skew = 19 Heads = 15 Alt track/zone = 0 Track skew = 2 Data bytes/sect = 512 Cert Pattern = 0 ----- partitions ----- part type base+size (sectors) 0: efs 4+42 (32130) 5: efs 923+611 (467415) 1: rawdata 46+133 (101745) 6: efs 179+1355 (1036575) 2: efs 4+131 (100215) 7: efs 4+1530 (1170450) 3: efs 135+394 (301410) 8: volhdr 0+4 (3060) 4: efs 529+394 (301410) 10: entire 0+1534 (1173510) ----- bootinfo ----- root partition = 0 swap partition = 1 bootfile = /unix ----- directory entries ----- 0: sgilabel block 1 size 280 ----- sgi-info ----- serial = 083316 name = CDC 94181-702 ----- please choose one of ----- 1) parameters/ 3) sgiinfo 5) directory 2) partitions 4) bootinfo 6) all fx/label/show> .. ----- please choose one of ----- 1) readin/ 2) show/ fx/label> .. ----- please choose one of ----- 1) exit 2) badblock/ 3) debug/ 4) exercise/ 5) label/ fx> 1 ---------------------------------------------------------------------- Here's 4Sight's complaints about the new disk. # tail -30 /usr/adm/SYS* . . . Feb 6 07:43:36 hog grcond[2323]: CIO: Feb 6 07:43:36 hog grcond[2323]: CIO: IRIX System V Release 3.2 IP4 Version 08231838 Feb 6 07:43:36 hog grcond[2323]: CIO: Feb 6 07:43:36 hog grcond[2323]: CIO: root on dev 0x1620, swap on dev 0x1621 Feb 6 07:43:36 hog grcond[2323]: CIO: dks0d2s10 volume header not valid Feb 6 07:43:36 hog grcond[2323]: CIO: . . .   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02602; 6 Feb 90 8:27 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02368; 6 Feb 90 8:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02113; 6 Feb 90 8:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15446; 6 Feb 90 7:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA00716; Tue, 6 Feb 90 04:40:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Feb 90 12:38:49 GMT From: Jean-Francois Lamy Subject: Re: rtar, rdump on SGI's Message-Id: <90Feb6.073833est.6187@neat.cs.toronto.edu> References: <7032@sdcc6.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL pa1081@sdcc13.ucsd.edu (pa1081) writes: >The question is, does anyone know of a way or public domain routines >that allow tape operations over the network between SGI Personal >IRIS's and 4.3bsd systems like the Alliant? Please let me know.... Tar and friends should be easy, since you can always resort to tar cf - blah | rsh remote -n 'dd of=/dev/ninetracktape obs=126b' where the options to dd allow you to byteswap to your heart's content and reblock to a reasonable size. Strike one for customer support. With respect to rdump, the problem is that SGI's file systems are not BSD, so you need a version of dump that understands EFS. It is easiest to use a different output format than the normal 4.3BSD, and have a restore program that reads that format (the program be compiled on non-SGI machines to restore SGI partitions elsewhere). The person who wrote it here mumbled something about being able to generate straight 4.3BSD format at some cost in programming and overhead, but his current dump and restore are good enough for our purposes (a couple dozen diskful machines from n manufacturers dumped over the net to a pair of exabytes -- heck, even Apple supports rdump :-) We can't give away what we have here because of the terms of our source license, but one would hope that eventually SGI will come to its senses and support what is a common practice in organizations where it is unfeasible to have "everyone expected to manage their own diskful workstation". The official party line appears to be "bru to a private tape drive". If that's not what you want, by all means tell SGI. At least we're not alone :-) My sinuses are congested and my head is going to explode, Jean-Francois Lamy lamy@cs.utoronto.ca, uunet!cs.utoronto.ca!lamy Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01832; 6 Feb 90 11:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01527; 6 Feb 90 11:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01072; 6 Feb 90 11:01 EST Received: from [128.252.120.1] by SMOKE.BRL.MIL id aa19022; 6 Feb 90 9:54 EST Received: from castor.wustl.edu by wugate.wustl.edu with SMTP (5.61++/IDA-1.2.8) id AA10067; Tue, 6 Feb 90 08:53:33 -0600 Received: by castor.wustl.edu (5.52/890607.SGI) (for @wugate.wustl.edu:purdy@beulah) id AA21668; Tue, 6 Feb 90 08:48:37 CST Date: Tue, 6 Feb 90 08:48:37 CST From: "Martin S. Weinhous" Message-Id: <9002061448.AA21668@castor.wustl.edu> To: info-iris@BRL.MIL Subject: Disk compatibility query Cc: drzymala@pollux.wustl.edu, harms@pollux.wustl.edu, purdy@castor.wustl.edu, weinhous@castor.wustl.edu We are about to buy an ESDI disk for our 4D120GTX. A distributor has offered an Hitachi DK515-78 (780MB, ESDI, 20MHz) at an attractive price. Our Iris has an Interphase (sp?) model 3201 ESDI controller. We are running Irix 3.2.1 and fx "knows" the "Hitachi 515-78." *** Question *** Can the Interphase 3201 controller properly com- municate with this particular Hitachi drive? *** Question *** Is the fx designation of "Hitachi 515-78" sufficient for our initiallizing, formatting and using the disk. Any help would be greatly appreciated. Thanks in advance! -- Marty Weinhous weinhous@castor.wustl.edu Radiation Oncology, Washington U. !uunet!wucs1!dinorah!weinhous St. Louis, MO 63105, 314/362-2600   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01832; 6 Feb 90 11:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01527; 6 Feb 90 11:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01450; 6 Feb 90 11:06 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa20622; 6 Feb 90 10:52 EST Received: from HGRRUG52.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7259; Tue, 06 Feb 90 10:51:12 EST Date: Tue, 6 Feb 90 11:28 N From: TORDA%HGRRUG52.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: Key mappings under 4Sight 1.0 To: INFO-IRIS@BRL.MIL X-Original-To: INFO-IRIS@BRL.MIL Message-ID: <9002061052.aa20622@SMOKE.BRL.MIL> On 5-feb, Jeremy Webber writes about remapping keys under wsh in order to run GNU emacs happily. Is this the best way ? Remapping at that level is bound to confuse anything else running under the wsh. Perhaps it would be better to remap keys in you .emacs file, so for example (global-set-key "\b" 'delete-backward-char) Note that you then have to bind the help functions to another key of your choice. The above line for remapping is described in the file called PROBLEMS in the top level directory in the emacs distribution. I also think that, for happy editing, it is more important to define the arrow keys and then the page up/down and so on. Aside from defining an escape-key-map, I also found it necessary to put an (enable-arrow-keys) in the .emacs file. Finally, you should make this stuff dependent on the type of terminal being used, so people can still come in to the iris with other terminal types and be able to edit properly. In the lisp/term subdirectory, there are several sophisticated examples for this kind of thing. -Andrew Torda (bitnet) torda@hgrrug52   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02364; 6 Feb 90 19:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02192; 6 Feb 90 18:59 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02190; 6 Feb 90 18:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01661; 6 Feb 90 18:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA10651; Tue, 6 Feb 90 15: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: 6 Feb 90 22:40:43 GMT From: 4614 Organization: Control Data Corp., Arden Hills, MN Subject: Immediate respone to a pick hit Message-Id: <15732@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to get an immediate response, while in select mode, to a selection hit. That is: 1) I enter select mode 2) I traverse my display list drawing entities one at a time 3) After drawing each entity I check a flag; If a hit has occured the flag is set and I can stop traversing my display list 4) After getting a hit I exit select mode and process my pick_buffer Anybody tried this? Anybody have any ideas?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02671; 6 Feb 90 21:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02615; 6 Feb 90 20:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02605; 6 Feb 90 20:37 EST Received: from dukempd.phy.duke.edu by SMOKE.BRL.MIL id aa02563; 6 Feb 90 20:30 EST Received: from physics.phy.duke.edu by dukempd.phy.duke.edu (5.59/1.1/2.10) id AA09384; Tue, 6 Feb 90 20:29:19 EST Received: by physics.phy.duke.edu (4.0/2.1/4.0) id AA12557; Tue, 6 Feb 90 20:29:15 EST Date: Tue, 6 Feb 90 20:29:15 EST From: "Robert G. Brown" Message-Id: <9002070129.AA12557@physics.phy.duke.edu> To: info-iris@BRL.MIL Subject: Power for Power Series Hi, there. I am a system administrator with a somewhat unusual (but perhaps not uncommon) problem. We just obtained an SG-220S in the big rack mount. I was somewhat surprised to learn, upon delivery, that the rack requires 220V SINGLE PHASE power, which is virtually non-existent in the United States. We are trying to install it in the physics department, where we have an abundance of three-phase 240 (which works out, if you connect across any two "hot" leads, to be around 208V peak with a Pi/6 phase shift). We might be able to find 240 two-phase (if we go back to the transformer). But there just is no 220 single phase (that is, one 220V hot, one current-carrying neutral, and one cold ground) around. SG is "installing" it for us, but the installation man has gone off to school (literally) for a week to learn how to install it, and I would like to at least have power for it when he returns and when he left he was clueless as to its real power needs. If anyone out there has: a) installed a power series rack on a three phase line; b) installed a power series rack on a two phase line; c) blown up a power series rack while trying to do either one; I'd love to hear from you. A wiring diagram of any working solutions would also be appreciated (the rack has a three prong plug -- hot, neutral, cold). I should note that we did try the three phase power (as a physicist, I know that the system should NOT be able to see any real difference between a hot-neutral pair at 208V and a hot-hot pair at 208V with a phase difference -- unless it uses the current-carrying "neutral" as a pseudo-ground, which is dumb). When we did it, the machine seemed to boot, but the prom monitor did not come up on port 1 (or 2,3 or 4). We have no graphics monitor, it is a server--only configuration at this time. When we put a scope on the backplane and on the serial line itself we got very unusual things. The serial line showed a .15V, 60Hz triangular waveform on ALL pins but 1 and 2. 1 had a more attenuated 60Hz signal, and 2 was (relatively) quiet. Obviously this is not at all like what we found on a functioning serial line. So: Is our power supply bad? Is our power bad? Are any or all of the boards bad? Are the serial ports bad? Or do we need to "flick that little switch over there"? Thanks, Rob Brown rgb@physics.phy.duke.edu Duke University Physics Dept. Durham, NC 27706   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02792; 6 Feb 90 21:21 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02524; 6 Feb 90 20:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab02486; 6 Feb 90 20:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02340; 6 Feb 90 19:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA14266; Tue, 6 Feb 90 16:08: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: 6 Feb 90 22:38:03 GMT From: James Helman Organization: Stanford University Subject: Re: IRIS 4D/20 memory upgrade Message-Id: References: <1990Feb4.072319.13990@gpu.utcs.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I prefer to buy memory that the third-party manufacturer claims works on a machine, rather than taking chances with stuff off the shelf at the local electronics shop. That way you can always send it back if it doesn't work as promised. Also, lifetime warranties are valuable, especially on board level products. Clearpoint sells memory for the 4D/20 through 4D/80. Helios sells memory for the 4D/2x0 series. Clearpoint's number is 1-800-CLEARPT. I don't have Helios' number. Or contact any reasonable size memory/ peripheral distributor. Among the ones in Northern California, we've found CITA in Sacremento (916) 344-5558 to have good prices and service. 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 aa03703; 7 Feb 90 0:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03634; 7 Feb 90 0:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id af03461; 7 Feb 90 0:01 EST Received: from relay.cs.net by SMOKE.BRL.MIL id ar04046; 6 Feb 90 23:34 EST Received: from relay2.cs.net by RELAY.CS.NET id ad26679; 6 Feb 90 13:53 EST Received: from gmr.com by RELAY.CS.NET id ac24352; 6 Feb 90 14:52 EST Date: Tue, 6 Feb 90 14:32 EST From: JORDAN%gmr.com@relay.cs.net Subject: c beautifier source To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <9002062334.ar04046@SMOKE.BRL.MIL> Anybody out there have any c-beautifier source code? tp mugabi-jordan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03833; 7 Feb 90 0:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03703; 7 Feb 90 0:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03701; 7 Feb 90 0:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04735; 7 Feb 90 0:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA03646; Tue, 6 Feb 90 21:17:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Feb 90 23:01:00 GMT From: David Wood Organization: New York University Subject: Re: rtar, rdump on SGI's Message-Id: <17280031@acf4.NYU.EDU> References: <7032@sdcc6.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The other option which has been mentioned here before is to get a hold of gnutar. We use it here and were able to recover from a pretty much fully wiped out disk. You can pick up the compressed tar with anonymous ftp from cmcl2.nyu.edu (128.122.128.2) in pub/iris/sgigtar.tar.Z. I forget, the binary may already be included. If it is, it was compiled on a 4D/80GT under 3.1B. We haven't had to recompile under 3.2 though. Good luck. ------------------------------------------------------------------------- David Wood wood@acf2.nyu.edu New York University ...!uunet!cmcl2!wood 212-998-3029 "Brain. Brain. What is brain?" Kara the Eymorg, "Spock's Brain", Stardate 5432.3 -------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12278; 7 Feb 90 14:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10754; 7 Feb 90 12:52 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa10711; 7 Feb 90 12:39 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa15066; 7 Feb 90 12:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA13531; Wed, 7 Feb 90 09:09: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: 7 Feb 90 16:00:14 GMT From: "Thomas D. Schardt" Organization: NSESCC, Goddard Space Flight Center, Greenbelt MD Subject: Turning Off Ipforwarding on Irix 3.2 Message-Id: <818@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Our network management wants all UNIX workstations that are not performing routing functions (99.9% of the machines on base) to turn off ipforwarding. Unforunately, SGI sets ipforwarding as the default. I have read "Kernal Configuration" in the Irix 3.2 System Administrator's Guide, and I have determined that the following procedure should rebuild the kernal with ipforwarding off: % su # cd /usr/sysgen/master.d # cp bsd bsd.old # vi bsd change int ipforwarding = 1; to int ipforwarding = 0; ZZ # cd /usr/sysgen/boot # cp bsd.a bsd.a.old # lboot -u /unix.install # cd / # cp unix unix.orig # sync # sync # reboot When /etc/rc2.d/S95autoconfig is run and the following prompt appears, answer 'y': Automatically reconfigure the operating system? Is this the correct procedure? Also is there any way of determining if the ipforwarding flag is off in a given kernal file? 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 ab12278; 7 Feb 90 14:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11186; 7 Feb 90 13:33 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa11116; 7 Feb 90 13:15 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa14654; 7 Feb 90 12:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA12526; Wed, 7 Feb 90 08:55:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Feb 90 16:18:37 GMT From: Sam Fulcomer Organization: Brown University Department of Computer Science Subject: Re: rtar, rdump on SGI's Message-Id: <28319@brunix.UUCP> References: <7032@sdcc6.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <7032@sdcc6.ucsd.edu> pa1081@sdcc13.ucsd.edu (pa1081) writes: >I would like to do central administration on our SGI's by backing >them up and doing all tape operations through our alliant FX/80 >which has a 1/2" tape drive. When I called sgi customer support, >they informed me that this would not be possible (due to byte swaps >and such). Huh? Why? What do they think byteorder(3N) does? Accessing a remote bsd-tape from an SGI is a lot more straightforward than reading random foreign tapes on local drives. eg, tar cf - /unix | rsh sun dd of=/dev/rst0 rsh sun tf /dev/rst0 rsh sun dd if=/dev/rst0 | tar tf - tar cf - /unix | rsh sun tar tf - all work thanks to byteorder(3N). What's the problem?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14335; 7 Feb 90 16:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13908; 7 Feb 90 16:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13798; 7 Feb 90 15:45 EST Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa04510; 7 Feb 90 14:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20808; Wed, 7 Feb 90 10:57:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Feb 90 18:18:56 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Power for Power Series Message-Id: <49972@sgi.sgi.com> References: <9002070129.AA12557@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002070129.AA12557@physics.phy.duke.edu>, rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: > Hi, there. I am a system administrator with a somewhat unusual > (but perhaps not uncommon) problem. We just obtained an SG-220S > in the big rack mount. I was somewhat surprised to learn, upon > delivery, that the rack requires 220V SINGLE PHASE power, which is > virtually non-existent in the United States. The plug is a NEMA 5-15. The wiring of the power distribution box expects 110 on each of the hot and `neutral'. So it should look like this: 110VAC--- | | ---110VAC O ---GND in the USA, with the 110's 180 degrees out of phase. 220VAC single phase is what they have in Europe. We ship a different plug to Europe, too. 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 aa14576; 7 Feb 90 16:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13908; 7 Feb 90 16:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13731; 7 Feb 90 15:44 EST Received: from forsythe.Stanford.EDU by SMOKE.BRL.MIL id aa03973; 7 Feb 90 14:32 EST Received: by Forsythe.Stanford.EDU; Wed, 7 Feb 90 10:31:50 PST Received: by SLACVM (Mailer R2.03B) id 7797; Wed, 07 Feb 90 10:32:42 PST Date: Wed, 07 Feb 1990 10:21 PST From: Len Sweeney To: uc!shamash!mcad@tut.cis.ohio-state.edu Cc: info-iris@BRL.MIL Subject: Re: Immediate respone to a pick hit Message-ID: <9002071433.aa03973@SMOKE.BRL.MIL> In-Reply-To: uc!shamash!mcad@tut.cis.ohio-state.edu -- 02/06/90 16:29 I did try watching the pick buffer array, hoping that hits would appear as they occurred. No such luck. Is there a nice way to make a whole character string pickable? getcpos() doesn't seem to return useful information when in gselect mode.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14904; 7 Feb 90 16:46 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac13908; 7 Feb 90 16:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab13798; 7 Feb 90 15:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04593; 7 Feb 90 14:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA20837; Wed, 7 Feb 90 10:58: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: 7 Feb 90 18:29:49 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Power for Power Series Message-Id: <49977@sgi.sgi.com> References: <9002070129.AA12557@physics.phy.duke.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9002070129.AA12557@physics.phy.duke.edu>, rgb@PHY.DUKE.EDU ("Robert G. Brown") writes: > I should note that we did try the three phase power (as a physicist, I > know that the system should NOT be able to see any real difference > between a hot-neutral pair at 208V and a hot-hot pair at 208V with a > phase difference -- unless it uses the current-carrying "neutral" as a > pseudo-ground, which is dumb). > > When we did it, the machine seemed to boot, but the prom monitor did > not come up on port 1 (or 2,3 or 4). We have no graphics monitor, it > is a server--only configuration at this time. When we put a scope on > the backplane and on the serial line itself we got very unusual > things. The serial line showed a .15V, 60Hz triangular waveform on > ALL pins but 1 and 2. 1 had a more attenuated 60Hz signal, and 2 was > (relatively) quiet. Obviously this is not at all like what we found > on a functioning serial line. > > So: Is our power supply bad? Is our power bad? Are any or all of > the boards bad? Are the serial ports bad? Or do we need to "flick > that little switch over there"? I replied a bit too quickly, it seems, as I did not address the rest of your questions. 220, neutral and ground will work too--you're correct on that one. As to your triangular waveforms on the serial lines; it sounds like something is wrong. Power supply is not likely to be the problem; there is no switch to flick, to my knowledge; and maybe the cabling/breakout board for the serial lines has a problem. The prom monitor *should* only come up on one port, though, and there may be no problem at all. Once the system is up, try `man getty' for info on your serial ports. 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 aa15291; 7 Feb 90 17:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14904; 7 Feb 90 16:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14865; 7 Feb 90 16:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07022; 7 Feb 90 16:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA28756; Wed, 7 Feb 90 12:52: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: 7 Feb 90 17:15:38 GMT From: Daniel Haug Organization: Merit Technology Austin Div. Subject: need help getting TeX Message-Id: <378@meritaus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I do not have FTP access and instead had a friend attempt to get the TeX distribution from vgr.brl.mil. She tried for a week without success (even during the night) due to continuous time-out problems. Would someone be willing to write it to tape for me and mail it to me? I will mail the tape to you, and include postage for the return trip. Much thanks. Please reply by phone or email. -- dan haug ==================================================================== Phonenet: (512)338-2450 Internet: execu!sequoia!meritaus!dan@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu, texbell}!sequoia!meritaus!dan ``When all you have is a hammer, everything begins to look like a nail.''   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16439; 7 Feb 90 19:22 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16198; 7 Feb 90 19:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16171; 7 Feb 90 18:42 EST Received: from [128.112.129.117] by SMOKE.BRL.MIL id aa08703; 7 Feb 90 17:08 EST Received: from acm.Princeton.EDU by Princeton.EDU (5.58+++/2.29/mailrelay) id AA03580; Wed, 7 Feb 90 17:06:44 EST Received: from fourier.Princeton.EDU by acm.Princeton.EDU (5.61/1.98) id AA13418; Wed, 7 Feb 90 17:08:06 -0500 Received: by fourier.Princeton.EDU (5.61/1.95) id AA03235; Wed, 7 Feb 90 17:08:03 -0500 Date: Wed, 7 Feb 90 17:08:03 -0500 From: ams@acm.princeton.edu Message-Id: <9002072208.AA03235@fourier.Princeton.EDU> To: info-iris@BRL.MIL, sgi!markb%denali.sgi.com@ucbvax.berkeley.edu Subject: Re: Power for Power Series Ok guys, which is it? Mark Bradly writes: > The plug is a NEMA 5-15. The wiring of the power distribution box > expects 110 on each of the hot and `neutral'. So it should look like > this: > > 110VAC--- | | ---110VAC > > O ---GND > > in the USA, with the > 110's 180 degrees out of phase. 220VAC single phase is what they have in > Europe. We ship a different plug to Europe, too. On page 1-1, under "Site Electrical Requirements": ALL POWER CENTER MODELS REQUIRE A DEDICATED 220 Volt single phase 30 amp power line. A dedicated line must provide 220 current in the following range: o 195-240 Volts of single phase AC o 47-63Hz A POWER Center can draw a maximum of 24 amps from the 220 Volt line (depending on configuration of the POWER Center). The POWER Center has a maximum VA of 5280. The NEMA receptacle (for domestic installations) must have the following characteristics: o NEMA L6 - 30R (250V @ 30 amps) Twist Lock This excerpt comes from "POWER Center Site Preparation" Version 1.0, Document Number 007-5310-110. --ams p.s. Markb--I don't think a 110vac on both sides of a three prong plug is a code violation. All US 220 standards I am familiar with are twist lock (circular) or triangular pattern (like on the "average family electric clothes dryer).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16562; 7 Feb 90 19:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16439; 7 Feb 90 19:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16263; 7 Feb 90 19:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09898; 7 Feb 90 18:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA09187; Wed, 7 Feb 90 15:23: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: 7 Feb 90 23:11:05 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Turning Off Ipforwarding on Irix 3.2 Message-Id: <50023@sgi.sgi.com> References: <818@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <818@dftsrv.gsfc.nasa.gov>, tom@fangorn.gsfc.nasa.gov (Thomas D. Schardt) writes: > [procedure used to turn off ipforwarding] > # cd /usr/sysgen/boot > # cp bsd.a bsd.a.old I don't see any point in making a backup copy of bsd.a. Lboot doesn't touch it, it merely calls ld to link from it. > # lboot -u /unix.install > # cd / > # cp unix unix.orig You can do the lboot after making the backup copy of /unix by invoking /etc/init.d/autoconfig This is probably "safer" and likelier to work in the future. If you had rebooted without running lboot, this script would have been run via its /etc/rc2.d/S95autoconfig link (ain't System V.3 aesthetic?), and lboot would have noticed the new-ness of the /usr/sysgen/master.d/bsd file and reconfigured a kernel. > # sync > # sync > # reboot Sync before reboot is a superstition on modern Unixes. The reboot system call code does an extremely effective internal sync (and if it doesn't, it is broken and we want to know!). > When /etc/rc2.d/S95autoconfig is run and the following prompt appears, > answer 'y': > > Automatically reconfigure the operating system? > > Is this the correct procedure? Also is there any way of determining if > the ipforwarding flag is off in a given kernal file? Try 'dbx -k /unix /dev/kmem' and then 'p ipforwarding' to dbx. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21436; 8 Feb 90 7:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21347; 8 Feb 90 7:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21278; 8 Feb 90 7:19 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16619; 8 Feb 90 6:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19757; Thu, 8 Feb 90 03:42:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Feb 90 23:51:43 GMT From: Michael Zeitlin Organization: Texaco Houston Res. Cntr Hou, Tx Subject: Turbo graphics and Xwindows Message-Id: <382@texhrc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm considering upgrading my 4d/25 with the turbo graphics, but before I spend mucho bucks, will SGI's implementation of the X server take advantage of the chip upgrade?? This is important for anyone considering upgrading their graphics performance of their Iris.... m.j. Zeitlin at uunet!nuchat!texhrc!mjz   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21651; 8 Feb 90 7:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21347; 8 Feb 90 7:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ad21278; 8 Feb 90 7:20 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16642; 8 Feb 90 6:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.41) id AA19641; Thu, 8 Feb 90 03:41: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: 7 Feb 90 15:04:29 GMT From: Mark Andrews Organization: Alias Research Inc., Toronto, ON Canada Subject: Use of snoop(7P) Message-Id: <739@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have been playing with the snoop(7P) protocol on a variety of 4D's (4D/60,70, 20, 25) running Irix 3.2. My program was constructed using the examples in the manual page: #include #include #include #define ETHERHDRPAD RAW_HDRPAD(sizeof(struct ether_header)) struct etherpacket { struct snoopheader snoop; char pad[ETHERHDRPAD]; struct ether_header ether; char data[ETHERMTU]; }; main() { int s; struct sockaddr_raw sr; struct snoopfilter sf; struct etherpacket ep; int cc, on = 1; s = socket(AF_RAW, SOCK_RAW, RAWPROTO_SNOOP); bzero(sr.sr_ifname, RAW_IFNAMSIZ); /* * If the family is not set (not specified in manual page), bind * fails due to unsupported address family. */ sr.sr_family = AF_RAW; sr.sr_port = 0; if (bind(s, &sr, sizeof sr) < 0) { /* Error */ } bzero((char *) &sf, sizeof sf); if (ioctl(s, SIOCADDSNOOP, (struct snoopfilter *)&sf) < 0) { perror("Adding snoop filter"); exit(1); } < .... > ----------------------------------------------------------------------------- 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. ------------------------------------------------------------------------------ Mark Andrews Systems Programmer, Alias Research, Toronto, Canada Phone: (416)-362-9181 UUCP: mark%alias@csri.utoronto.ca