Received: from vmb.brl.mil by VMB.BRL.MIL id aa00435; 6 Sep 90 10:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad00095; 6 Sep 90 10:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01342; 6 Sep 90 10:05 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa14737; 6 Sep 90 9:59 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06615; Thu, 6 Sep 90 06:57:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 08:13:01 GMT From: Bruno Pape Organization: Silicon Graphics S.A., Zuerich, Switzerland Subject: About SMD's and IPI's, again. Message-Id: <1990Sep6.081301.1179@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In response to my recent posting about the differences between the 1.2GB SMD and IPI drives I received the following two replies from people at SGI Mountian View. ------------------------------------------------------------------------------- as far as i can tell, all you need to do is change the controller and the cables. I believe the drive will stay the same It's a Sabre V ------------------------------------------------------------------------------- SMD and IPI drives look the same, but are actually quite different. The only areas which might be similar are the power supplies, but I don't know for sure. In general, we are treating them as completely different drives, much as we treat a 780 and 380 from the same manufacturer differently. ------------------------------------------------------------------------------- Would someone like to submit a third opinion? I could use it as a tie breaker, if it is not radically different. Do we know what we will need to do to upgrade a machine with SMD disks to IPI disks? How about spare parts numbers for IPI disks and controlers? Thanks again, Bruno   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00856; 6 Sep 90 11:07 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00660; 6 Sep 90 10:56 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00482; 6 Sep 90 10:44 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa14810; 6 Sep 90 10:13 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06787; Thu, 6 Sep 90 07:00:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 09:45:08 GMT From: Stephen Boyd Gowing II Organization: SOCS, University of Technology, Sydney, Australia Subject: Cleaning bit-planes Message-Id: <18308@ultima.socs.uts.edu.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How do I clean up unused bit-planes behind windows? -- ======================================================================= Stephen Boyd Gowing sbg@ultima.socs.uts.edu.au snafu =======================================================================   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01236; 6 Sep 90 11:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00660; 6 Sep 90 10:56 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ac00482; 6 Sep 90 10:44 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa14837; 6 Sep 90 10:28 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08354; Thu, 6 Sep 90 07:18:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 13:28:54 GMT From: Yan Xiao Organization: UTCS Public Access Subject: KeyMapping on 3000 Message-Id: <1990Sep6.132854.15753@gpu.utcs.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There have been a lot of discussion on re-binding keys on 4D serials, but does anybody know how to do the same thing for 3000? We have an IRIS3120 (sounds antique) and would like to have the ability of re-mapping the keyboard and defining keys like arrow keys. Any help will be appreciated. xiao   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01692; 6 Sep 90 11:33 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac01236; 6 Sep 90 11:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01077; 6 Sep 90 11:13 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa14978; 6 Sep 90 10:58 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10665; Thu, 6 Sep 90 07:44:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 14:29:04 GMT From: Patrick-Gilles Maillot Organization: Sun Microsystems, Mountain View Subject: Re: SGI's migration to X Message-Id: <141923@sun.Eng.Sun.COM> References: , <1990Sep4.213844.9865@odin.corp.sgi.com>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On the net yesterday: > >From what Mark says, I take it that Sun's DGA does not allow XGL and X >drawing calls to be made in the same window. Basically then, it just >allows XGL and X/NeWS windows to share the same screen without trouncing >on each other. > You should not rely on SGI to get information about the capabilities of XGL, Sun's DGA, or Sun in general... XGL and X calls CAN be made in the same window. Obviously, XGL calls are using DGA and therefore will be much faster in terms of rendering speed. It's time we start an Sun/XGL news group. -Patrick-Gilles Maillot   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04094; 6 Sep 90 14:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03574; 6 Sep 90 14:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03563; 6 Sep 90 13:59 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15437; 6 Sep 90 13:45 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20312; Thu, 6 Sep 90 10:20:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 16:52:19 GMT From: Thant Tessman Organization: Silicon Graphics Inc. Subject: Re: Alpha blending ... Message-Id: <1990Sep6.165219.11745@odin.corp.sgi.com> References: <1990Sep5.151623.12906@ux1.cso.uiuc.edu>, <1990Sep5.171056.23011@odin.corp.sgi.com>, <1990Sep5.190659.14015@ux1.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep5.190659.14015@ux1.cso.uiuc.edu>, gautamm@kandinsky.ncsa.uiuc.edu (Gautam Mehrotra) writes: > > I am sorry I didn't make myself very clear -- I am trying to > do transparent( translucent ) surfaces -- therefore the alpha > blending. The problem is that if I use the z-buffer ( which I am > using), parts of intersecting polygons are not rendered at all ( the > part which lies behind values in the z-buffer). I can get this > portion if I re-render the polygon with the zfunction changed to > test for values of z GREATER than the values in the z-buffer. > However, I haven't been able to get the alpha values right. Does > anyone have any experience with this ? The 'hack' that the SGI demos use is to draw all of the solid stuff normally, and then turn on the z-buffer write mask (using zwritemask) and draw all the alpha-blended stuff. It will z-buffer correctly against the solid stuff without putting anything in the z-buffer to mess up subsequent alpha-blended stuff. This isn't correct, but it looks okay for highly transparent stuff and where the colors of the transparent polygons don't vary too much. The 'correct' way is to turn off the z-buffer and depth-sort the transparent stuff (painter's algorithm (maybe via BSPTree)). This is a hard problem. There are some other tricks that give good approximations, but I don't know enough about them to comment. > > thanks, > gautam thant   Received: from vmb.brl.mil by VMB.BRL.MIL id ab04094; 6 Sep 90 14:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab03574; 6 Sep 90 14:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab03563; 6 Sep 90 13:59 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15455; 6 Sep 90 13:46 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18951; Thu, 6 Sep 90 09:57:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 16:32:15 GMT From: Christopher Gunn Organization: University of Kansas Academic Computing Services Subject: Sources for 3rd-party SGI disk drives? Message-Id: <25438.26e633bf@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've been carefully archiving posts on sources for 3rd-party SGI- compatible memory, but have not been as alert about reports on sources for SGI-compatible disks. Can anybody out there recommend reliable and/or cheap vendors for such drives? Our immediate needs are for 5.25" 760Mb-1.2Gb SCSI add-on external drives with housing/power and cabling, but if a certain grant comes through we might be looking at faster SMD- or ISI- type drives. I'll try to summarize responses back to the net in form similar to memory summarys that crop up frequently. I've been slapping raw drives in VAXes (and PDP-11s in the dark ages) for a good long time now, but I are Unix-illiterate and would really be grateful for either a true plug&play solution or drives that come with instructions suitable for an ape. Since SG's disk prices (with academic discounts) are only about 1.5 times the market, we'll probably wind up buying our IRIS boxes with a built-in SGI system disk. But I'd really rather not pay extra for drives 2,...,N. Our immediate need for this information stems from the fact that we may need to encumber funds and start a bid process for drives 2 to 4 months before the money shows up for the IRISes. But I have access to some running 4D/25s that I could use to test and torture external SCSI drives in the interim. Christopher Gunn Molecular Graphics and Modeling Lab SPAN--KUPHSX::GUNN Department of Medicinal Chemistry, Malott Hall 913-864-4428 or -4495 University of Kansas, Lawrence, KS 66045   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04345; 6 Sep 90 14:49 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03849; 6 Sep 90 14:21 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03601; 6 Sep 90 14:00 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15485; 6 Sep 90 13:48 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16839; Thu, 6 Sep 90 09:26:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 15:43:49 GMT From: Robert Skinner Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: New IBM Graphics Workstations Message-Id: <1990Sep6.154349.10690@odin.corp.sgi.com> References: <1990Jul25.155350.10192@athena.mit.edu>, <17450006@hpfcdj.HP.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17450006@hpfcdj.HP.COM>, kuba@hpfcdj.HP.COM (Kathy Kuba) writes: |> > / hpfcdj:comp.sys.sgi / ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) / 12:10 pm Jul 30, 1990 / |> > |> > > For comparison, SGI says a base IRIS 4D/50 with 8 bit planes does |> > > 140K vectors/sec and 5.5K polygons/sec. An IRIS with GTX graphics is |> > > supposed to do 475K vectors/sec and 100K polygons/sec. |> > |> |> 2D or 3D vectors? |> |> Kathy unlike some other companies nearby, SGI's benchmarks are *always* for *fully transformed and clipped 3D* vectors. Robert Skinner robert@sgi.com Fish, he got a hook in his throat. Fish, he got problems. - Genesis   Received: from vmb.brl.mil by VMB.BRL.MIL id ab04345; 6 Sep 90 14:49 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac04094; 6 Sep 90 14:38 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03958; 6 Sep 90 14:25 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15620; 6 Sep 90 14:14 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23156; Thu, 6 Sep 90 11:07:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 18:02:29 GMT From: Frank Eeckman Organization: Lawrence Livermore National Laboratory Subject: Re: ... Message-Id: <67625@lll-winken.LLNL.GOV> References: <1990Sep5.171056.23011@odin.corp.sgi.com>, <1990Sep5.190659.14015@ux1.cso.uiuc.edu>, <1990Sep6.165219.11745@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody know if there is an NCSA imagetool program for the SGI ? If so where can I get it, if not is there some analogous software available ? Thanks FHE eeckman@mozart.llnl.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04440; 6 Sep 90 15:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab03849; 6 Sep 90 14:21 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03821; 6 Sep 90 14:14 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15594; 6 Sep 90 14:04 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19085; Thu, 6 Sep 90 10:00:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 16:16:32 GMT From: Thant Tessman Organization: Silicon Graphics Inc. Subject: Re: What is your StereoView aspect ratio? Message-Id: <1990Sep6.161632.11329@odin.corp.sgi.com> References: <9009010113.AA17280@chem.chem.ucsd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The only thing I can think of is that the settings on your monitor aren't right. I checked again, and so far, two different Mitsubishi monitors stretch the image vertically. Here's the program I used to work out my aspect ratio stuff: Note: With 3.3 the is_stereo() can be replaced with a call to getgdesc(GD_STEREO) stereo.h ------------------------------------------------ /* stereo.h */ #ifndef STEREO_H #define STEREO_H #define YMAXSTEREO 491 #define YOFFSET 532 #endif grid.h -------------------------------------------------- #include #include #include #include "stereo.h" #define LEFT 1 #define RIGHT 2 main() { int dev, val; int monitor; noborder(); prefposition(0, XMAXSCREEN, 0, YMAXSCREEN); winopen("grid"); monitor = getmonitor(); if (is_stereo()) setmonitor(STR_RECT); qdevice(ESCKEY); qdevice(MIDDLEMOUSE); qdevice(WINQUIT); draw_test(); while (1) { switch (dev=qread(&val)) { case ESCKEY: if (val) break; case WINQUIT: setmonitor(monitor); exit(); case REDRAW: draw_test(); break; } } } draw_test() { viewport(0, XMAXSCREEN, 0, YMAXSCREEN); color(BLACK); clear(); color(RED); viewport(0, XMAXSCREEN, 0, YMAXSTEREO); draw_grid(); cmov2i(180, 0); charstr("right"); color(BLUE); viewport(0, XMAXSCREEN, YOFFSET, YOFFSET+YMAXSTEREO); draw_grid(); cmov2i(-200, 0); charstr("left"); } draw_grid() { int i; ortho2(0, XMAXSCREEN.5, 0, YMAXSTEREO.5); recti(0, 0, XMAXSCREEN, YMAXSTEREO); translate(XMAXSCREEN/2.0, YMAXSTEREO/2.0, 0.0); scale(2.0, 1.0, 1.0); for (i = -128; i<=128; i+=32) { move2i(i, -128); draw2i(i, 128); } for (i = -128; i<=128; i+=32) { move2i(-128, i); draw2i(128, i); } circ(0.0, 0.0, YMAXSTEREO/2.0); circ(0.0, 0.0, 8.0); } /* define a way to check if stereo is installed. */ /* For now, use getvideo and setvideo: */ #include #include int is_stereo() { int RV1 = TRUE; long rw1, rw2; int i; /* test to see if DER1_STEREO bit is read/write or read-only */ /* if it is read-only, stereo is installed. */ /* loop makes SURE the bit really behaves as a read/write bit. */ for ( i = 1; i < 10; i++) { rw1 = getvideo(DE_R1); rw1 = rw1 ^ DER1_STEREO; /* flip the stereo bit */ rw2 = rw1; setvideo(DE_R1, rw2); rw2 = getvideo(DE_R1); RV1 = (rw1 == rw2) ? TRUE : FALSE; if (!RV1) break; /* failed to flip the bit */ rw2 = rw2 ^ DER1_STEREO; /* flip the stereo bit back*/ rw1 = rw2; setvideo(DE_R1, rw2); rw2 = getvideo(DE_R1); RV1 = (rw1 == rw2) ? TRUE : FALSE; if (!RV1) break; /* failed to flip the bit back*/ } return (RV1 == TRUE) ? FALSE : TRUE; }   Received: from vmb.brl.mil by VMB.BRL.MIL id ab04440; 6 Sep 90 15:00 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad04094; 6 Sep 90 14:39 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03979; 6 Sep 90 14:26 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15630; 6 Sep 90 14:15 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22992; Thu, 6 Sep 90 11:05:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 17:13:13 GMT From: Kurt Akeley Organization: sgi Subject: Re: GL Lighting POSITION Message-Id: <1990Sep6.171313.12512@odin.corp.sgi.com> References: <17450005@hpfcdj.HP.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17450005@hpfcdj.HP.COM>, kuba@hpfcdj.HP.COM (Kathy Kuba) writes: |> I recently received my SGI 210GTX workstation (running 3.3) and began |> porting code from my 120GTX (3.2). All went well, except that my light |> sources did not illuminate my objects. Upon further investigation, I |> discovered that moving my POSITION from 0 0 1 0 to 0 0 -1 0 fixed the |> problem. Has any one else seen this?? I really don't want to do keep |> different versions of code for each machine. The SGI Hotline graphics |> expert I talked with said they "fixed" the light sources so backface |> lighting would work properly. All other SGI graphics workstations I've |> used have the positive z axis pointing out of the screen, so a light |> at 0 0 1 0 is shining from behind to the origin. If they believe this |> is really a "fix", then why didn't they make it transparent to the user? |> The answer I received, "change your code", is not acceptable. Comments |> suggestions, and alternate solutions welcome! |> |> |> Kathy You have received some misinformation. The object coordinate system has been and remains right handed - positive Z will always extend out of the screen toward you. The default light position is and will remain 0,0,1,0. You don't need to specify this to get it. Probably the most common problem encountered with lighting is that light positions are transformed by the current ModelView matrix when the light is bound (i.e. when lmbind(LIGHTn,foo) is called). As a result you must be very careful about what ModelView matrix is present when a light is bound. In releases previous to 3.3, the ModelView matrix was undefined until it was first loaded (typically with an identity matrix). In release 3.3, the ModelView matrix is initialized to identity when mmode(MVIEWING) is first called (putting the GL into multimatrix mode, required for lighting and many other advanced GL features). It is likely that some error has been made in the matrix/lmbind sequence, and that this error is affected by the differences between the 3.2 and 3.3 software releases. Of course there really may be a bug in the GTX 3.3 lighting code, but I haven't noticed any problems with my machine (a 3.3 GTX), so it's worth going over your code carefully. -- kurt   Received: from vmb.brl.mil by VMB.BRL.MIL id ab05122; 6 Sep 90 15:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac04907; 6 Sep 90 15:27 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa04882; 6 Sep 90 15:20 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa15925; 6 Sep 90 15:16 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26806; Thu, 6 Sep 90 12:09:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:01:50 GMT From: Michael Mcneill -Visualization Organization: National Center for Supercomputing Applications Subject: Re: Sources for 3rd-party SGI disk drives? Message-Id: <1990Sep6.190150.10510@ux1.cso.uiuc.edu> References: <25438.26e633bf@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here's a list of SCSI disk vendors that may be helpful. Note: This list is provided purely as a service. I don't have affiliations with any of these companies. =========================================================================== Apunix Computer Services (619) 484-0074 Simon Meth American Computers & Engineers (213) 820-8998 Andataco Computer Perhipherals (800) 334-9191 Peter Bille Artecon (619) 931-5500 ext 135 Stacey A. Wildenberg Arkay Engineering Sales (216) 836-8497 Richard Kuhar Cita Technologies (216) 524-8735 David Thompson Computer Upgrade Corporation (714) 630-3457 Robert J Allen Cranel (800) 288-3475 James M. Huffman Danford Corporation (213) 514-9334 Scott M. Johnson Delta Microsystems, Inc. (415) 449-6881 General Microsystems Inc. (206) 644-2233 Earl W. Overstreet Helios Systems (408) 432-0292 Interscience Computer Corp. (818) 707-2000 Miran Apikian Mar-Con Associates Inc. (708) 675-6450 Sue Hyosaka MDB Systems, Inc. (714) 998-6900 National Peripherals (312) 325-4151 Ken Been North Central Peripherals (612) 881-2302 Ken Nickell Parity Systems (408) 378-1000 Solflower Computer Inc (408) 452-5780 Janet Doan Unison Information Systems (508) 898-0072 ===========================================================================   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00121; 6 Sep 90 20:53 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00546; 6 Sep 90 20:02 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00496; 6 Sep 90 19:51 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00183; 6 Sep 90 19:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08001; Thu, 6 Sep 90 15:02:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 20:38:28 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: About SMD's and IPI's, again. Message-Id: <1990Sep6.203828.15588@odin.corp.sgi.com> References: <1990Sep6.081301.1179@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.081301.1179@sgzh.uucp>, root@sgzh.uucp (Bruno Pape) writes: > In response to my recent posting about the differences between the 1.2GB > SMD and IPI drives I received the following two replies from people at > SGI Mountian View. > > ------------------------------------------------------------------------------- > > as far as i can tell, all you need to do is change the controller > and the cables. I believe the drive will stay the same > > It's a Sabre V > > ------------------------------------------------------------------------------- > > SMD and IPI drives look the same, but are actually quite different. The only > areas which might be similar are the power supplies, but I don't know for > sure. In general, we are treating them as completely different drives, much > as we treat a 780 and 380 from the same manufacturer differently. > > ------------------------------------------------------------------------------- > > Would someone like to submit a third opinion? I could use it as a tie breaker, > if it is not radically different. > > Do we know what we will need to do to upgrade a machine with SMD disks to > IPI disks? > > How about spare parts numbers for IPI disks and controlers? > Ack!! Is a SCSI and an ESDI drive the same cause they are both 5 1/4" form factor?? No, SMD and IPI are in no way similar except that they are both 8" form factor (and may share some common manufactured components). Most importantly the disk data protocol is completely different (serial instead of parallel) so cables etc are not the same. Second the IPIs are parallel head while the SMD are not, etc.etc.etc. The only way to 'upgrade' is to remove your SMD controller, drives, cables and installa new controller, drive, cables Chris   Received: from vmb.brl.mil by VMB.BRL.MIL id ac00121; 6 Sep 90 20:53 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00546; 6 Sep 90 20:02 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab00496; 6 Sep 90 19:51 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00187; 6 Sep 90 19:01 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07980; Thu, 6 Sep 90 15:01:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:35:27 GMT From: "Jack P. Weldon" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: PC-NFS problems Message-Id: <1990Sep6.193527.14866@odin.corp.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article robert@juno.ee.uwa.oz (Roberto Togneri) writes: >Our setup consists of three IRISes running 3.1d and NFS. Connected >to these are PC's running PC-NFS 3.0.1. The IRISes are cross-mounted >via NFS and the PC's mount each root filesystem of the IRISes on >separate drive letters. [deleted info concerning hanging PC-nfs requests and lp spooling vi PC-nfs] >Has anybody come across these problems? Yes, the hanging issue was fixed in IRIX 3.2.3 (and 3.3 of course). As far as being able to spool to SGI machines, one must remember that Sun has a vested interest in selling Suns (just as SGI does for IRIS machines), so Sun PC-nfs uses BSD print spooling in pcnfsd. SGI has made available a "fixed" version of pcnfsd that will spool to IRIS local printers. It is available by sending a 1/4" tape and a postage-paid return envelope with your request for the pcnfsd executable to: SGI, Attn: Monica Schulze, 2011 North Shoreline Blvd., Mountain View, CA 94039. This is provided as a service to our customers that have nfs, have some form of PC-nfs on their PC, and prefer not to port the pcnfsd.c to IRIX. It is *not* supported by the Hotline. Another solution would be to use the BSD print spoolers available in 3.3, but this solution has other pros and cons. >Another problem which I think has been covered is the incompatibility >of NFS between IRISes and Suns. We can mount a Sun filesystem happily >enough but the Suns can't mount the IRIS filesystems. The mount >program returns a version mismatch diagnostic. Is this correct? >Any solutions? Is this problem related to the above problem? Sorry, but it is a *SUN* bug, not an IRIX bug, and may have bitten other vendors that have ported Sun's newest nfs code (I've heard that MIPS and the newest IBM 6000's may have the same mount(1) bug, but this is *not* confirmed) Here's a repost: From: jweldon@renegade.sgi.com (Jack P. Weldon) Newsgroups: comp.sys.sgi Subject: Sun nfs bug with SGI servers (revisited) Date: 18 Jun 90 21:18:12 GMT This is just to clarify the situation concerning the SunOS 4.1 bug that keeps Sun clients from mounting SGI nfs servers. Sun has resolved the bug and will ship a patched mount(1) to any customer with a support contract. The bug numbers previously posted have apparently been consolidated into a NEW bug number. The info I have is as follows: New Bug Report ID: network/nfs 1036952 Title: SunOS 4.1 clients cannot mount SGI nfs servers due to version mismatch. >The above is very annoying because one of the Suns has an Exabyte drive >and if the IRIS filesystems were mounted then they could be >archived easily using dump. Normally this is not necessary since a >remote dump can be performed but a dump/restore facility does not >seem to be provided with the IRISes. Someone else should comment on the dump/restore issues. Suffice it to say that dump/restore is BSD, and not an industry standard, though it is widely used. -- Cheers, Jack P. Weldon (jweldon@csd.sgi.com)   Received: from vmb.brl.mil by VMB.BRL.MIL id ad00121; 6 Sep 90 20:53 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad00546; 6 Sep 90 20:02 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00517; 6 Sep 90 19:56 EDT Received: from vm.uoguelph.ca by VGR.BRL.MIL id aa00296; 6 Sep 90 19:39 EDT Received: from VM.UoGuelph.CA by vm.uoguelph.ca (IBM VM SMTP R1.2.2MX) with BSMTP id 0181; Thu, 06 Sep 90 19:42:05 EST Received: by UOGUELPH (Mailer R2.07) id 1934; Thu, 06 Sep 90 19:42:04 EST Date: Thu, 06 Sep 90 19:38:15 EST From: Peter Jaspers-Fayer Subject: 3.3.1 fixes fortran bugs To: Iris mailing list Message-ID: <9009061939.aa00296@VGR.BRL.MIL> Apologies to SGI: 3.3.1 fixes both of our Fortran bugs (both the logical*1 always true, and the core dump when doing read, rewind write, read ... more than once). A quick recompile and they went away. Thanks, I now have 2 happy (happier anyway) users. /PJ SofPJF@VM.UoGuelph.Ca (Probably also reachable (until ?) at SOFPJF@UOGUELPH.BITNET) Klein bottle for rent, apply within.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00359; 6 Sep 90 21:04 EDT Received: by VMB.BRL.MIL id ab00126; 6 Sep 90 20:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00097; 6 Sep 90 19:04 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05959; 6 Sep 90 16:55 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa16270; 6 Sep 90 16:43 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02764; Thu, 6 Sep 90 13:40:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:59:00 GMT From: James Helman Organization: Stanford University Subject: Re: SGI's migration to X Message-Id: References: <208@voodoo.UUCP>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL jim@baroque.Stanford.EDU (James Helman) writes: ... Vicom's new image processor ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just FYI, this must be the Pixar hardware. Pixar sold their hardware division to Vicom. Right idea, wrong acquisition. Within the past 18 months, Vicom bought Gould's Imaging and Graphics Division as well as Pixar's hardware division. Their new image processor originated at the former. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Voice: (415) 723-9127   Received: from vmb.brl.mil by VMB.BRL.MIL id ac00359; 6 Sep 90 21:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00121; 6 Sep 90 20:53 EDT Received: by VMB.BRL.MIL id aa00565; 6 Sep 90 19:59 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00278; 6 Sep 90 18:57 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa16524; 6 Sep 90 17:43 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05908; Thu, 6 Sep 90 14:30:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 21:27:26 GMT From: "David R. Blythe" Organization: EECG, University of Toronto Subject: Re: ... Message-Id: <1990Sep6.172726.18663@jarvis.csri.toronto.edu> References: <1990Sep5.190659.14015@ux1.cso.uiuc.edu>, <1990Sep6.165219.11745@odin.corp.sgi.com>, <67625@lll-winken.LLNL.GOV> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <67625@lll-winken.LLNL.GOV> eeckman@mozart.llnl.gov (Frank Eeckman) writes: >Does anybody know if there is an NCSA imagetool program for the SGI ? >If so where can I get it, if not is there some analogous software >available ? >Thanks >FHE >eeckman@mozart.llnl.gov The NCSA tools for X windows kind of work under 3.2 (for 10 or 15 minutes at a time) and probably work okay under 3.3 (don't have 3.3 yet). They also have a program for the iris for displaying 2 dimensional bivariate data as height-colour images. This stuff is ftp'able from zaphod.ncsa.uiuc.edu You can get an AVS-like program called apE from the Ohio Supercomputer centre for approx $75. Send mail to michelle@osgp.osc.edu for more details. SGI ships a stripped down version of VoxelView from Vital Images with the higher-end machines (i.e. everythign but PI's) which is useful for volume data. They also ship a stripped down version of some of wavefront's software called the personal visualizer. From arizona theres a program called IRISPLOT which can plot surfaces and what not and let you manipulate it interactively. ftp from connemara.math.arizona.edu There are various public domain ray-tracing packages available (rayshade and dkb are worth looking at) ftp from cs.uoregon.edu BRL has a comprehensive package, BRL-CAD. you can get more information about it from vgr.brl.mil. Others have mentioned raytracers customized for molecular modelling etc, but I haven't seen any ftp addresses yet. There's other stuff available, but this should keep you busy for a while. david blythe ontario centre for large scale computation drb@clsc.utoronto.ca   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00472; 6 Sep 90 21:20 EDT Received: by VMB.BRL.MIL id aa00327; 6 Sep 90 21:08 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00097; 6 Sep 90 19:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05961; 6 Sep 90 16:55 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa16274; 6 Sep 90 16:44 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02700; Thu, 6 Sep 90 13:39:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 16:17:12 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: New IBM Graphics Workstations Message-Id: <1990Sep6.161712.29956@relay.wpd.sgi.com> References: <17450006@hpfcdj.HP.COM>, <1990Jul25.155350.10192@athena.mit.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17450006@hpfcdj.HP.COM>, kuba@hpfcdj.HP.COM (Kathy Kuba) writes: > > / hpfcdj:comp.sys.sgi / ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) / 12:10 pm Jul 30, 1990 / > > > > > For comparison, SGI says a base IRIS 4D/50 with 8 bit planes does > > > 140K vectors/sec and 5.5K polygons/sec. An IRIS with GTX graphics is > > > supposed to do 475K vectors/sec and 100K polygons/sec. > > > > Don't forget the VGX system's 1M vps and 1M pps. This board uses the GL > > unlike IBM's top-o'-the-line. > > > > > It is not obvious how to compare the figures, however. The IBM > > The graphics performance numbers for the Personal Iris and GT graphics systems > > vps are based on 10 pixel, connected, full 24-bit color, arbitrary orientation > > > > 2D or 3D vectors? > > Kathy 3D, of course. Sorry for the missing detail. --- Ciemo   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00472; 6 Sep 90 21:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad00359; 6 Sep 90 21:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00274; 6 Sep 90 20:54 EDT Received: from vm.uoguelph.ca by VGR.BRL.MIL id aa00490; 6 Sep 90 20:38 EDT Received: from VM.UoGuelph.CA by vm.uoguelph.ca (IBM VM SMTP R1.2.2MX) with BSMTP id 0194; Thu, 06 Sep 90 20:40:42 EST Received: by UOGUELPH (Mailer R2.07) id 2350; Thu, 06 Sep 90 20:40:42 EST Date: Thu, 06 Sep 90 20:18:57 EST From: Peter Jaspers-Fayer Subject: Re: Rampaging Software Installation To: Andrew Hume , Iris mailing list In-Reply-To: Message of 5 Sep 90 01:29:13 GMT from Message-ID: <9009062038.aa00490@VGR.BRL.MIL> You beat me to it, Andrew. I was in the midst of composing a similar query/complaint (being less experienced, I was expressing it more along the lines of "Hey, what did we do wrong?"), when I spotted your mail. We too had our non-standard /dev/dsk/ipi0d0s[n] devices removed. As one of these (with associated link) were to describe our /usr filesystem (on a non-boot/root disk), the results were somewhat spectacular. We too didn't like it! We spent some time discussing how this could best be circumvented in the future and came up with a work-around and a better solution: 1) The work around is that install should have make it clearer that it was monkeying around with our devices and allowed us to fix up the damage before booting. But if there are a lot of them (even 4 is a lot: mknod, chmod, ln, then to /dev/rdsk and do it all over again) it's a pain, so I would like to propose: 2) MKDEV should call a MKDEV.local, which could describe locally defined devices, their protection/ownership flags, and associated links. This file should, of course be never be over-written! (as MKDEV was during the install) The documentation for MKDEV and mknod should be changed to warn people that unless changes to /dev are coded in MKDEV.local, a future install may mess you up. /PJ SofPJF@VM.UoGuelph.Ca (Probably also reachable (until ?) at SOFPJF@UOGUELPH.BITNET) Klein bottle for rent, apply within.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00571; 6 Sep 90 21:35 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac00546; 6 Sep 90 20:02 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ac00496; 6 Sep 90 19:51 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00190; 6 Sep 90 19:01 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07572; Thu, 6 Sep 90 14:55:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 21:53:01 GMT From: "David R. Blythe" Organization: EECG, University of Toronto Subject: Re: SGI's migration to X Message-Id: <1990Sep6.175301.18898@jarvis.csri.toronto.edu> References: , , <1990Sep6.010419.1573@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.010419.1573@odin.corp.sgi.com> msc@sgi.com writes: > >Even if it's possible, we don't recommend doing it. Trying to image into >the same window using both X and the GL raises a bunch of nasty issues of >which one of the nastiest is synchronizing the drawing. Has the GL finished >drawing this polygon so I can have X draw this line? Who's on first so to >speak. Ugh!! > It would be really really really really nice if whatever X toolkit/UIMS/etc gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. That is to say, I want to learn *one* subroutine library for popups, pulldowns, radio knobs, other crap that can be used in both a GL window and an X window. This would seem like a good reason to have X requests and GL requests work together, rather than making a GL version of the same library. If a client is local can't it use the same direct paths to the hardware as GL (i.e. have X built on top of or in conjunction with GL (either through the X server, or bypassing it when possible) rather than a separate entity)? Remote requests would have to go through a serializer, so the remote guy may pay some performance penalty in extra overhead but it seems worth it to keep the local stuff fast and integrated. drb@clsc.utoronto.ca >-- >From the TARDIS of Mark Callow >msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00571; 6 Sep 90 21:35 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac00472; 6 Sep 90 21:24 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00442; 6 Sep 90 21:12 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00568; 6 Sep 90 20:59 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19892; Thu, 6 Sep 90 17:58:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:27:32 GMT From: John Edelson Organization: Silicon Graphics, Inc. Subject: Want more software on your IRIS? Message-Id: <1990Sep7.002732.19261@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm working with independent software vendors trying to help them consider whether the IRIS makes sense for them as a platform to develop for or port to. Basically, I recruit software partners. Rather than doing this in a void, I'd like more feedback about what software IRIS users would like to have on their system. So, I'm looking for IRIS users to give me feedback on the software that they want: - either specific applications available on other vendors systems (ie SPSS) - or categories of software (ie a good wysiwig word processor) I will use this feedback to guide me efforts and approaches to different vendors. RSVP to: John Edelson Manager, Developers Relations Silicon Graphics 2011 N. Shoreline Blvd Mountain View, CA 94039 415 335-1532 fax 415 962-9601 edelson@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00822; 6 Sep 90 22:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00760; 6 Sep 90 22:21 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00741; 6 Sep 90 22:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00774; 6 Sep 90 21:44 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22714; Thu, 6 Sep 90 18:38:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 16:39:57 GMT From: Yukio Yagi Organization: Solbourne Computer, Inc. Subject: Re: Questions about Personal IRIS Message-Id: <1990Sep6.163957.7048@Solbourne.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have posted the question about performance of Personal IRIS, and I've got 2 same answers. I want to say "thank you" to those who gave me answers. I appreciate your kindness. Yukio Yagi Solbourne Computer Inc. yagi@solbourne.com or uunet!stan!yagi   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00822; 6 Sep 90 22:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00760; 6 Sep 90 22:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab00741; 6 Sep 90 22:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00779; 6 Sep 90 21:44 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22734; Thu, 6 Sep 90 18:38:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 19:26:23 GMT From: Mark Bradley Organization: Solbourne Computer Systems Subject: Re: About SMD's and IPI's, again. Message-Id: <1990Sep6.192623.12955@Solbourne.COM> References: <1990Sep6.081301.1179@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.081301.1179@sgzh.uucp> root%sgzh.uucp@uunet.uu.net (Bruno Pape) writes: >In response to my recent posting about the differences between the 1.2GB >SMD and IPI drives I received the following two replies from people at >SGI Mountian View. > >Do we know what we will need to do to upgrade a machine with SMD disks to >IPI disks? > >How about spare parts numbers for IPI disks and controlers? > >Thanks again, >Bruno The IPI and SMD disk drives are very different. The SMD drive is a one head/data path unit, while the IPI is a 2HP (2-head parallel). The interfaces are very different, as well, one being the age-old SMDE and the other being IPI level 2. They are not interchangable at any field level. The entire drive must be replaced. Cabling and controllers are, of course, entirely different as well. Don't try this at home, kids..... :{) They are very different products. markb -- Mark Bradley (DoD#1100) Faster, faster, until the thrill I/O Subsystems of speed overcomes the fear of death. Solbourne Computer, Inc. --Hunter S. Thompson   Received: from vmb.brl.mil by VMB.BRL.MIL id ac00388; 7 Sep 90 1:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00122; 7 Sep 90 1:27 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01023; 6 Sep 90 23:16 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa00940; 6 Sep 90 23:04 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0448; Thu, 06 Sep 90 23:03:18 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Thu, 6 Sep 90 14:50 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:vjs@sgi.com) id AA00565; Thu, 6 Sep 90 14:52:59 DSD Date: Thu, 6 Sep 90 14:52:59 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: RTS-CTS bad on ttyf?? To: info-iris@BRL.MIL, vjs@sgi.com Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009062152.AA00565@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil, vjs@sgi.com Vernon Schryver was kind enough to bring to my attention the sgi specs for hardware serial port handshake. After more than a few days, I find that, at least on my machine, a 70G, the following IS NOT TRUE!! I am sitting here with a breakout box lit up on top of the machine to my right, and jumpers affixed to RTS-CTS and DCD-DTR. >Each IRIX tty port has three aliases, distinquished by the two most >significant bits of the minor device number, or by the /dev/tty[dmf]* name. > >ttyd* use pins 2,3, & 7. Thus, the system simply babbles the output, > subject at most to XON/XOFF flow control. At high speeds, either the > system or the printer will loose ^S or ^Q characters and bad things > will happen. This always works, only at high speeds (> 9600) it drops characters, i assume because XON-XOFF is not fast enough. >ttym* use 2,3,7,8, and 9/20. The system will refuse to complete an open(2) > until pin 8, DCD, is true. Otherwise, ttym* are the same as ttyd*. A > handy hack is to connect pins 8 and 9/20, to make a ttym* that is > really connected to a dumb, 3-wire device complete an open(2). Yes, this checks out. The open does hang until DCD is asserted on all ports. >ttyf* use 2,3,4,5,7,8, and 9/20. A port under its ttyf name behaves the > same as under its ttym name, except that it honors CTS as required by > RS-232-C, and expects the device honor RTS as in the de facto standard > "hardware flowcontrol". WRONG ! . These ports should open, but no characters should move until CTS is engaged. I don't know about newer machines, but the CTS pin seems to be GROUNDED, as I can't get the breakout box led to light up when it is connected to +BATTERY, or low when -BATTERY. I am also finding that the kermit I use does a core dump on trying to open ttyf[1,2] with handshake engages. After a while, I am getting messages about streams being out of resourses. I will reboot the machine to clear the streams kernel, but this does not look good. The /dev/tty{d,m}4 (I only tested 4, and don't want to spend more time on this) do NOT do RTS-CTS, as expected. the /dev/tty{f}4 lines does asssert RTS, and drops it as its buffer fills. It does NOT listen to CTS. Indeed, I think that that line is shorted someplace judging from the behavior of the break out box LEDs'. I can use RTS-CTS between the host and the peripheral device. The host can tell the peripheral to stop transmitting, but the peripheral can not tell the host to be quiet. For my application (verbose peripheral limited by host), that is fine. However, since I can't get a signal from the hosts CTS, loopback testing of the host RTS-CTS does NOT work. Indeed, my experience with RTS-CTS signaling is that the host should not transmit unless CTS is held high. It seems that sgi does not respect CTS, and holds RTS up except when it does not want characters. The tty{m}4 properties seem to work as expected. The machine would send a HANGUP (or at least kermit said somthing) signal when DCD was disconnected. This may explain my problems with running laser printers at 19200 and higher speeds (verbose host limited by peripheral). There, the host has to respect CTS, as the host is doing all of the talking. My particular problem is with a peripheral that is always talking, so I can get this project running at high speed. My expectation is that RTS-CTS would permit faster overall performance than XON-XOFF or NO HANDSHAKE. I find that for short polled messages, performance is WORSE. I don't lose characters on short messages, as the buffers seen fast enough not to loose characters. The threshold for triggering RTS as the communications circular buffers fill is set too low. The machine is dropping RTS far too often, when without hanshaking, no characters are lost. It there a way to set a high water mark on the comm buffers ? I hope that this problem is limited only to my machine, and is not a problem on newer systems. This would be most apparent with high speed serial printers, not with high speed serial digitizers. For your information, I am using a breakout box with jumpers to loopback TD-RD, RTS-CTS, and DCD-DTR . I have tested the 9-25 wire cables, and verified things on all (/dev/tty{d,m,f}{1,2,3,4} ports. This stuff has been driving me crazy. I can't seem to get the speed up on a number of serial devices because the hardware handshake is not working properly. I have an old dunn video camera I gave up on and run at 300 baud attached to a 50GT machine. I suspect that the problem may also extend to that machine too, but has crashed and burned, and is awaiting a service call. uname -a mcirps2 mcirps2 3.3 06011629 IP4 hinv 1 12 MHZ IP4 Processor FPU: MIPS R2010 VLSI Floating Point Chip Revision: 2.0 CPU: MIPS R2000 Processor Chip Revision: 5.0 Data cache size: 32 Kbytes Instruction cache size: 64 Kbytes Main memory size: 16 Mbytes ENP-10 Ethernet controller 0, firmware version 0 (CMC) Graphics option installed Interphase 3201 2-drive ESDI disk controller 0 ESDI Disk drive: unit 0 on Interphase controller 0 Integral SCSI controller 0: Version WD33C93 Tape drive: unit 7 on SCSI controller 0: QIC 24 I hope that this problem is unique to my configuration. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00473; 7 Sep 90 1:53 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00388; 7 Sep 90 1:43 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00205; 7 Sep 90 1:22 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00977; 6 Sep 90 23:14 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27942; Thu, 6 Sep 90 20:01:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 23:41:34 GMT From: Tim Anderson Organization: Open Communication Forum Subject: Looking for a source for 150 meg tapes... Message-Id: <1990Sep6.234134.27265@agora.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What EXACTLY do I do to get ahold of some tapes for this machine? (a 4D/20 with a 150 meg tape drive). Coming from the DOS world, I haven't a clue as to whom I should call to have these things delivered. I'm sure that INMAC has them, but I don't particularly feel like paying INMAC prices! Do I have to order a particular type? Brian at SGI in Bellevue said 'remember to get 3M 600 foot 12,500 FTPI tapes'. So is this for the 60 meg ones, or for both the 60 and 150 meg ones? I want to back up all of the neato demo's that are on this machine before I blow them all away to get some disk space... It appears that I have 'more than the average' amount of demo stuff on here... If I order the 'Sun' tapes from GNU, I have to get them 'DD' formatted, correct? Any other incantations that I should know about? Are there any decent editors out there that won't break my bank? Seeing as how I was bloody lucky enough to get this machine, begging the boss for another $400 to get the 'AMES editor' is real, real likely... Maybe if the afore mentioned uemacs fixes ever made it out to the real world... Thanks! tima@agora.hf.intel.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00580; 7 Sep 90 2:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00388; 7 Sep 90 1:43 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id af00205; 7 Sep 90 1:24 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01260; 7 Sep 90 0:29 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02475; Thu, 6 Sep 90 21:15:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 03:27:02 GMT From: psuvm!rie@psuvax1.cs.psu.edu Organization: Penn State University Subject: NCAR Graphics 3.0 Message-Id: <90249.232702RIE@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We wish to run NCAR Graphics version 3.0 on a Personal Iris. If you have experience in compiling NCAR Graphics on an Iris, please let me know the necessary modifications to be made -especially the makefiles. Any suggestions/help will be highly appreciated. Subhransu Roy Penn State University Email: s3r@ecl.psu.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01623; 7 Sep 90 6:07 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01328; 7 Sep 90 5:57 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01309; 7 Sep 90 5:50 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01866; 7 Sep 90 5:44 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21061; Fri, 7 Sep 90 02:40:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 01:09:44 GMT From: Owen Baker Organization: RMIT Computer Centre, Melbourne Australia. Subject: Opening console automatically? Message-Id: <5570@minyos.xx.rmit.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know if it is possible to open the console window automatically when a user first logs in? Our users keep forgetting and hence dont see any error messages. Any help appreciated, thanks. +-------------------------------+-------------------------------------------+ | Owen Baker | Communication Services Unit | | rxcob@minyos.xx.rmit.oz.au | RMIT - Victoria University of Technology | | (61) (3) 660-2038 | Melbourne, Victoria, Australia | +-------------------------------+-------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01894; 7 Sep 90 7:34 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01858; 7 Sep 90 7:24 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01832; 7 Sep 90 7:17 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02031; 7 Sep 90 7:01 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23945; Fri, 7 Sep 90 03:41:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:40:52 GMT From: Trevor Coulson Organization: RUNX Unix Timeshare. Sydney, Australia. Subject: Help: 32MB in PI25 Message-Id: <2245@runxtsa.runx.oz.au> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a Personal Iris 4D/25 & would wish to upgrade the machine to 32MB. Currently, it is populated with 1MB (9x1mb) SIMM modules. I understand that 2MB SIMM modules are required to expand the machine up to 32MB. A local supplier of memory was unfamiliar with 2MB SIMM modules & needed more more information about them:- Do they contain 18x1mb chips? If so, is there 18 on one side on the module or 9 on each side? What is the part No? Alternatively, a reference to a supplier (& current prices) would be greatly appreciated (A US source would be fine). Silicon Graphics (Australia) is an obvious supplier - however, a 32MB upgrade is in excess of A$20000 or US$16000. I am aware that PROM revison 7 (at least) is required to support 32MB of memory. Any help would be greatly appreciated. Cheers Trevor.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01675; 8 Sep 90 2:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01263; 8 Sep 90 1:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01240; 8 Sep 90 1:06 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00635; 8 Sep 90 1:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03902; Fri, 7 Sep 90 22:00:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 90 23:22:05 GMT From: Gary Trimble Organization: Lockheed AI Center, Menlo Park Subject: Programmatic gclear call... Message-Id: <877@laic.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a programmatic way to get the same results as gclear? I'd like to use it on my 4D/GT in a C program. Mail or Post....Thanks in advance. Gary Trimble   Received: from vmb.brl.mil by VMB.BRL.MIL id aa10546; 13 Sep 90 4:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09933; 13 Sep 90 3:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09900; 13 Sep 90 2:56 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05335; 13 Sep 90 2:51 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06660; Wed, 12 Sep 90 23:38:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 00:53:56 GMT From: "Peter S. Shenkin" Organization: Columbia University Subject: Backup utility; was: Re: PC-NFS problems Message-Id: <1990Sep7.005356.10012@cunixf.cc.columbia.edu> References: , <1990Sep6.193527.14866@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.193527.14866@odin.corp.sgi.com> jweldon@sgi.com (Jack P. Weldon) writes: >Someone else should comment on the dump/restore issues. Suffice it to say that >dump/restore is BSD, and not an industry standard, though it is widely used. So, is there an industry standard for UNIX backup? -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00715; 7 Sep 90 2:41 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00662; 7 Sep 90 2:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00644; 7 Sep 90 2:16 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01413; 7 Sep 90 1:59 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08409; Thu, 6 Sep 90 22:55:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 05:12:13 GMT From: Senol Kucuk Organization: University of Pittsburgh, EE Dept. Subject: GNU interface to NeWS (ps-emacs) problem... Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL [machine: IRIS4D] [system: IRIX System V Release 3.2 IPG Version ...] [problem: GNU Emacs NeWS interface (ps-emacs)] Hi. I have a request from those who have (if any) installed the ps-emacs (tut.cis.ohio-state:/pub/gnu/emacs/ps-emacs.tar.Z). I tried applying the pathces described in the ps-emacs distribution to GNU emacs 18.55 (tut.cis.ohio-state.edu:/pub/gnu/emacs/18.55/emacs-18.55.tar.Z). I used m-iris4d.h and s-iris3-6.h as instructed in etc/MACHINES for a IRIS4D machine. The patches for the ps-emacs worked fine but i had problem compiling NeWS.c which gave errors to line if (!updating && outputstarted == 0) blockinputmask = sigblock (sigmask (SIGIO)); saying that SIGIO was not defined. The include file /usr/include/sys/signal.h defines SIGIO by #define SIGIO 23 /* input/output possible signal */ However the file s-iris3-6.h undefines the SIGIO variable saying that although iris defines SIGIO it does not use it. So I commented that line which gave me a running emacs with -nw option (do not create a NeWS window) but which does nothing but wait when run as emacs (requesting its own NeWS window). Has anybody else had this kind of problem? Any suggestions? Thanks in advance. -- -- Senol Kucuk, Department of Electrical Engineering, University of Pittsburgh {senol,snkst4,kucuk}@{{unix,vms}.cis.pitt.edu,pitt{vms,unix}.bitnet}   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00820; 7 Sep 90 3:06 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00790; 7 Sep 90 2:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ac00761; 7 Sep 90 2:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01533; 7 Sep 90 2:32 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10198; Thu, 6 Sep 90 23:27:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 06:09:22 GMT From: George Phillips Organization: University of British Columbia, Vancouver, B.C., Canada Subject: igif 2.0 part 1/2 Message-Id: <9468@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is the latest version of igif, a program for displaying GIF images on SGI machines. The README file below outlines some of the new features. I've testing it on an 8 plane personal Iris and on a 24 plane machine. It should run on anything with 24 planes and on any 8 plane machine running 4Sight (NeWS). A little hacking could make it run on machines in-between. Igif has some mininal GIF version 89a support, but some day I plan to extend that and maybe even throw in support for other image file formats. So have fun and send in any bug reports, etc. -- George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips #! /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: # README # igif.1 # Makefile # igif.c # This archive created: Thu Sep 6 22:51:22 1990 export PATH; PATH=/bin:$PATH echo shar: extracting "'README'" '(1375 characters)' if test -f 'README' then echo shar: will not over-write existing file "'README'" else sed 's/^X//' << \SHAR_EOF > 'README' XHere is igif, a program for displaying GIF images on SGI machines. X XThe new version has the following features: X - displays all images in a GIF file and multiple GIF files at once X - uses much less memory X - incremental refresh and displays images while loading X - can be made to stay in the foreground X - displays as much of the image as possible (for corrupt files) X - window label changes to indicate the GIF file displayed X - works on 8 bit displays and machines without lrectwrite automatically X - menu for selecting from multiple GIF files X - incremental reading of images for fast response X XIgif is also available via anonymous ftp from cs.ubc.ca: /src/igif2.shar.Z. X X XCopyright 1989,1990 by George Phillips X XPermission to use, copy, modify, and distribute this software and its Xdocumentation for any purpose and without fee is hereby granted, provided Xthat the above copyright notice appear in all copies and that both that Xcopyright notice and this permission notice appear in supporting Xdocumentation. This software is provided "as is" without express or Ximplied warranty. X XThe GIF LZW decoder was written by someone else who's copyright notice Xis contained in decode.c. X XThe Floyd-Steinberg dithering code was based on ppmquant from Jef XPoskanzer's PBM+ package. X XGeorge Phillips XDepartment of Computer Science XUniversity of British Columbia SHAR_EOF fi # end of overwriting check echo shar: extracting "'igif.1'" '(2648 characters)' if test -f 'igif.1' then echo shar: will not over-write existing file "'igif.1'" else sed 's/^X//' << \SHAR_EOF > 'igif.1' X.TH IGIF 1 "5 September, 1990" X X.if n .ds Q \&" X.if n .ds U \&" X.if t .ds Q `` X.if t .ds U '' X X.SH NAME Xigif \- display GIF images on SGI machines X X.SH SYNOPSIS X.B igif X[ \-d \-e \-f \-l \-t \-2 ] { file.gif } X X.SH DESCRIPTION X.I igif Xreads the GIF files given and displays them in a window. If no files are Xgiven, X.I igif Xreads a GIF image from standard input. Some options control how the GIF Ximages are displayed. X X.TP X.B \-d XDither the image before displaying it. This option has no effect on Xmachines with 24 bit displays. X X.TP X.B \-e XErase the window entirely before moving to a new image. X X.TP X.B \-f XStay in the foreground. This is useful for scripts which want to Xwait for X.I igif Xto finish before they continue. X X.TP X.B \-l XDo not use lrectwrite. X.I igif Xshould detect when lrectwrite is not availble, but this option will give Xyou a workaround if it guesses wrong. This option only applies to machines Xwith 24 bit displays. X X.TP X.B \-t XDisplay the image in true colour. This may not always be possible and it Xmay have adverse affects on other applications running. This option has Xno effect on machines with 24 bit displays. X X.TP X.B \-2 XDisplay the images twice as wide and high. This is nice for those itsy-bitsy X320 x 200 GIF images. X X.SH "WINDOW INTERFACE" XIf you are displaying more than one image, X.I igif Xgives you three ways to select which images to display. Pressing the left Xmouse button or the \*Qn\*U key will move forward to the next image. Pressing Xthe middle mouse button or the \*Qp\*U key will move backward to the Xprevious image. The right mouse button will display a menu of images to Xselect from. Since X.I igif Xtries to bring images up as quickly as possible, you may select an image which Xhas not been loaded. In this case nothing will happen. XWhen the numbers no longer appear on the left of the Xwindow title bar, all the images will be loaded. X XPressing the \*Qq\*U key will quit the program. X X.SH BUGS XIf some program has munged the \*Qstandard\*U 8 plane colourmap, the images Xwill not look too good. Either run makemap (/usr/sbin/makemap, perhaps) Xor use the -t flag. X.I igif Xmay itself wipe out the colourmap if you kill it. X X.PP XAuto-dection of a missing lrectwrite(\|) may not work on all systems. XI'll be happy to apply a fix if you have one. X X.PP XInterlaced GIF files are dithered as they are loaded instead of waiting Xuntil we have all the lines in the right order. This is wrong. X X.PP XDither should be done after enlarging the image. It isn't so using \-d Xand \-2 may give a poor result. X X.SH AUTHOR XGeorge Phillips X.br XDepartment of Computer Science X.br XUniversity of British Columbia SHAR_EOF fi # end of overwriting check echo shar: extracting "'Makefile'" '(1093 characters)' if test -f 'Makefile' then echo shar: will not over-write existing file "'Makefile'" else sed 's/^X//' << \SHAR_EOF > 'Makefile' XCFLAGS=-g X X# If this doesn't work, try LIB=-Zg XLIB=-lgl_s X Xigif: igif.o decoder.o newsmap.o floydstein.o X cc $(CFLAGS) -o igif igif.o decoder.o newsmap.o floydstein.o $(LIB) X X#igif: igif.u decoder.u newsmap.u floydstein.u X# cc $(CFLAGS) -o igif igif.u decoder.u newsmap.u floydstein.u $(LIB) X Xclean: X rm -f igif a.out core Makefile.old igif2.shar igif2.1.shar igif2.2.shar X rm -f *.o X Xshar: X shar -pX -v README igif.1 Makefile igif.c decoder.c newsmap.c floydstein.c \ X errs.h std.h mem_image.h newsmap.h imgfile.h > igif2.shar Xshar2: X shar -pX -v README igif.1 Makefile igif.c > igif2.1.shar X shar -pX -v decoder.c newsmap.c floydstein.c \ X errs.h std.h mem_image.h newsmap.h imgfile.h > igif2.2.shar X X# If you put something after here, makedep will destroy it! Xdecoder.o: errs.h mem_image.h std.h Xerrs.h: X touch errs.h Xfloydstein.o: mem_image.h newsmap.h Xigif.o: errs.h imgfile.h mem_image.h newsmap.h Ximgfile.h: X touch imgfile.h Xmem_image.h: X touch mem_image.h Xnewsmap.o: newsmap.h Xnewsmap.h: X touch newsmap.h Xstd.h: X touch std.h X.PRECIOUS: errs.h imgfile.h mem_image.h newsmap.h std.h SHAR_EOF fi # end of overwriting check echo shar: extracting "'igif.c'" '(27914 characters)' if test -f 'igif.c' then echo shar: will not over-write existing file "'igif.c'" else sed 's/^X//' << \SHAR_EOF > 'igif.c' X/* X * igif.c -- display GIF images on the personal iris and other SGI machines. X * X * usage: igif [ -d -e -f -l -t -2 ] { file.gif } X * X * If no images are specified, a GIF image is read from standard input. X * flags: X * X * -d Dither the images before displaying it. X * -e Erase the entire previous image before going to the next one. X * -f Stay in the foreground; this is useful for 3 line browsers: X * foreach f (*.gif) X * igif -f $f X * end X * -l Force igif to not use lrectwrite. This may be faster and it X * may be necessary for it to work ('though some autodection is done). X * -t Display true colours on colour-mapped displays. On displays with X * only 8 planes, igif will change the colours of images to fit the X * standard NeWS colourmap. This option makes igif display the true X * colours; even if that means that other programs will get their X * colours (temporarily) stomped on. It tries hard to be as X * inconspicuous as possible, but if you gotta have 256 colours... X * -2 Display the images in double height and double width mode. A X * cheap hack, but it saves some eyestrain on those itsy-bitsy X * 320 x 200 GIFs. X * X * When in igif, the left and middle mouse buttons (or the n and p keys) X * move to the next and previous images respectively. The right mouse X * button brings up a menu of the images. The q key will quit igif. X * Until all the images are loaded, you may not see the image even if you X * move to it. When no numbers appear to the left of the title bar all X * images should be loaded. X * X * Bugs: X * If some program has munged the "standard" 8 plane colourmap, the images X * won't look too good. Either run makemap (/usr/sbin/makemap, perhaps) X * or use the -t flag. Igif may itself wipe out the colourmap if you X * kill it. X * Auto-dection of a missing lrectwrite() may not work on all systems. X * I'll be happy to apply a fix if you have one. X * Dithering should be done after doubling the image. It isn't and the X * results are not too pretty. X * X * TODO list: X * - we can't dither interlaced GIFs right away (but we do anyways!) X * - support GIF89a fully X * - work on displays without RGB but > 8 planes. Not too hard, X * but _I_ can't test it. X * - true colour mode should check if a local colourmap is in fact the same. X * - set NeWS colourmap on startup? X * - display meaninful information if an image is not yet loaded. X * - transmogrification into a generalized image viewer which supports X * lots of different formats, perhaps in concert with PBM+. X * - generalize the magnification (esp. to correct aspect ratio) X * - options to perform gamma correction of images X * - clean up the code X * X * Copyright 1989,1990 by George Phillips X * X * Permission to use, copy, modify, and distribute this software and its X * documentation for any purpose and without fee is hereby granted, provided X * that the above copyright notice appear in all copies and that both that X * copyright notice and this permission notice appear in supporting X * documentation. This software is provided "as is" without express or X * implied warranty. X * X * The GIF LZW decoder was written by someone else who's copyright notice X * is contained in decode.c. X * X * The Floyd-Steinburg dithering code was based on ppmquant from Jef X * Poskanzer's PBM+ package. X * X * George Phillips X * Department of Computer Science X * University of British Columbia X */ X X#include X#include X#include X#include X X#include "errs.h" X#include "mem_image.h" X#include "imgfile.h" X#include "newsmap.h" X Xint bad_code_count; X Xstruct imgfile* imf_list = NULL; Xstruct imgfile** imf_ins = &imf_list; Xstruct mem_image* cur_img = NULL; X Xint stay_in_foreground = 0; Xint mag = 1; Xint use_lrectwrite = 1; Xint true_colours = 0; Xint dither = 0; Xint erase_all = 0; Xint timing = 0; X Xenum disp_mode_type { RGB_LRECT, RGB_WRITE, CMAP_NEWS, CMAP_TRUE }; Xstatic enum disp_mode_type disp_mode; Xstatic int win_width; Xstatic int win_height; Xint redrawing = 0; Xint redraw_line = 0; Xstruct imgfile* cur_imf = NULL; Xlong imgmenu; X Xint loading; X Xchar* image_title(); X Xmain(argc, argv) Xint argc; Xchar* argv[]; X{ X FILE* fp; X int argn; X int i; X int maxwidth; X int maxheight; X struct imgfile* imf; X X argn = 1; X for (argn = 1; argn < argc && argv[argn][0] == '-'; argn++) { X if (!strcmp(argv[argn], "-f")) X stay_in_foreground = 1; X else if (!strcmp(argv[argn], "-l")) X use_lrectwrite = 0; X else if (!strcmp(argv[argn], "-t")) X true_colours = 1; X else if (!strcmp(argv[argn], "-d")) X dither = 1; X else if (!strcmp(argv[argn], "-e")) X erase_all = 1; X else if (!strcmp(argv[argn], "-2")) { X mag = 2; X } X else if (!strcmp(argv[argn], "-T")) X timing = 1; X else { X fprintf(stderr, "igif: unknown option '%s'\n", argv[argn]); X exit(1); X } X } X X if (true_colours && dither) { X fprintf(stderr, "igif: only one of -t and -d may be specified; -t assumed\n"); X dither = 0; X } X X if (argn == argc) X setup_file("standard input", stdin); X else X for (i = argn; i < argc; i++) X setup_file(argv[i], (FILE*)NULL); X X loading = 0; X maxwidth = 10; X maxheight = 10; X for (imf = imf_list; imf != NULL; imf = imf->next) { X loading++; X if (imf->width > maxwidth) X maxwidth = imf->width; X if (imf->height > maxheight) X maxheight = imf->height; X } X X if (loading == 0) { X fprintf(stderr, "igif: no images to display\n"); X exit(1); X } X X screen_init(maxwidth, maxheight); X if (dither && (disp_mode == RGB_LRECT || disp_mode == RGB_WRITE)) X dither = 0; X X for (imf = imf_list; imf != NULL; imf = imf->next) { X if (imf->stream != NULL || (fp = fopen(imf->filename, "r")) != NULL) { X if (cur_imf == NULL) { X cur_imf = imf; X wintitle(image_title(imf)); X } X if (imf->stream != NULL) X load_gif(imf, imf->stream, imf->width, imf->height); X else { X load_gif(imf, fp, -1, -1); X fclose(fp); X } X loading--; X update_loadinfo(); X } X } X X update_loadinfo(); X screen_handle(1); X exit(0); X} X Xsizeof_gif(name, fp, width, height) Xchar* name; XFILE* fp; Xint* width; Xint* height; X{ X unsigned char buf[10]; X X if (fread(buf, 10, 1, fp) != 1) { X fprintf(stderr, "igif: %s is too short\n", name); X return(0); X } X if (strncmp(buf, "GIF", 3)) { X fprintf(stderr, "igif: %s is not a GIF file\n", name); X return(0); X } X if (strncmp(buf + 3, "87a", 3) && strncmp(buf + 3, "89a", 3)) { X buf[6] = '\0'; X fprintf(stderr, "igif: %s is an unsupported GIF file version\n", name); X return(0); X } X *width = buf[6] + (buf[7] << 8); X *height = buf[8] + (buf[9] << 8); X return(1); X} X Xstatic int err = 0; Xstatic int i_y; Xstatic int pass; X X#define error(x) printf("%s at byte %d\n", x, ftell(fp)); return(0) X#define reterr(x) if (err != 0) { error(x); } X#define reteof() reterr("Unexpected EOF") X#define skipbyte(x) getbyte(x); reteof() X Xint* gif2rgb(); Xstruct mem_image* add_image(); Xvoid adjust_colourmap(); X Xsetup_file(filename, stream) Xchar* filename; XFILE* stream; X{ X FILE* fp; X int width, height; X struct imgfile* imf; X char* p; X char* lastslash; X X if (stream != NULL) X fp = stream; X else if ((fp = fopen(filename, "r")) == NULL) { X fprintf(stderr, "can't open '%s'\n", filename); X return; X } X X if (sizeof_gif(filename, fp, &width, &height)) { X imf = (struct imgfile*)malloc(sizeof(struct imgfile)); X if (imf == NULL) X no_mem(); X imf->filename = filename; X imf->stream = stream; X imf->width = width; X imf->height = height; X X for (p = filename, lastslash = filename - 1; *p; p++) X if (*p == '/') X lastslash = p; X X imf->name = lastslash + 1; X imf->imglist = NULL; X imf->next = NULL; X *imf_ins = imf; X imf_ins = &(imf->next); X } X if (stream == NULL) X fclose(fp); X} X Xload_gif(imf, fp, s_width, s_height) Xstruct imgfile* imf; XFILE* fp; Xint s_width; Xint s_height; X{ X static unsigned char buf[4096]; X int s_control, back; X int i_top, i_left, i_width, i_control, i_height; X int ch; X int i, j; X int* global_colourmap; X int* local_colourmap; X struct mem_image* img; X struct mem_image** img_ins; X X img_ins = &(imf->imglist); X X if (s_width == -1) { X /* read signature */ X if (fread(buf, 3, 1, fp) != 1) { X error("File too short"); X } X X if (strncmp(buf, "GIF", 3)) { X error("Not a GIF file"); X } X X if (fread(buf, 3, 1, fp) != 1) { X error("File too short"); X } X X if (strncmp(buf, "87a", 3) && strncmp(buf, "89a", 3)) { X buf[3] = '\0'; X printf("unknown version '%s'\n", buf); X return(0); X } X X /* read screen descriptor */ X s_width = getword(fp); reteof(); X s_height = getword(fp); reteof(); X } X X s_control = getbyte(fp); reteof(); X back = getbyte(fp); reteof(); X skipbyte(fp); X X if (s_control & 128) { /* global colour map */ X global_colourmap = gif2rgb(fp, 2 << (s_control & 7)); X } X X for (;;) { X ch = getbyte(fp); X reterr("no terminator"); X switch (ch) { X case ',': /* image follows */ X i_left = getword(fp); reteof(); X i_top = getword(fp); reteof(); X i_width = getword(fp); reteof(); X i_height = getword(fp); reteof(); X i_control = getbyte(fp); reteof(); X X if (i_control & 128) { /* local colour map */ X local_colourmap = gif2rgb(fp, 2 << (i_control & 7)); X img = add_image(i_width, i_height, 2 << (i_control & 7), X s_width, s_height); X img->colourmap = local_colourmap; X img->maplen = 2 << (i_control & 7); X } X else { X img = add_image(i_width, i_height, 2 << (s_control & 7), X s_width, s_height); X img->colourmap = global_colourmap; X img->maplen = 2 << (s_control & 7); X } X img->x_off += i_left * mag; X img->y_off += i_top * mag; X img->gif_interlaced = i_control & 64; X img->background = back; X img->imf = imf; X *img_ins = img; X img_ins = &(img->next); X adjust_colourmap(img); X if (img->imf == cur_imf && img->imf->imglist == img) X paint_background(img); X bad_code_count = 0; X i_y = 0; X pass = 0; X decoder(fp, img); X /* ignore rest of blocks used by decoder */ X skipblocks(fp); reterr("Bad block in image"); X break; X case ';': /* terminator ... */ X return(0); X case '!': /* extension block */ X skipbyte(fp); /* function code */ X skipblocks(fp); reterr("Bad block in extension block"); X break; X default: X /* Supposed to ignore any unknown characters up to the image X * separator, but I prefer to be tight about these things because X * there are many corrupt images out there. X */ X printf("Unknown block type '%c' (%d) at byte %d\n", X ch, ch, ftell(fp)); X return(0); X } X } X} X X/* X * Read the GIF colourmap from the given file and convert it into X * the format used by lrectwrite. X * X * GIF colourmap is a byte stream: rgbrgbrgb X * lrect format is in 4 byte words: abgr abgr abgr X * (the a is alpha, which should be zero) X */ Xint* gif2rgb(fp, len) XFILE* fp; Xint len; X{ X register int i; X int* rgb; X X if ((rgb = (int*)malloc(len * sizeof(int))) == NULL) X no_mem(); X X /* very loose about EOF, oh well */ X for (i = 0; i < len; i++) { X rgb[i] = fgetc(fp); X rgb[i] |= fgetc(fp) << 8; X rgb[i] |= fgetc(fp) << 16; X } X return(rgb); X} X Xstatic int pass_width[] = { 8, 8, 4, 2 }; Xstatic int pass_start[] = { 0, 4, 2, 1 }; X Xchar* out_line(img) Xstruct mem_image* img; X{ X if (dither) X floydstein(img, i_y); X X if (disp_mode == CMAP_TRUE) X true_cmap(img, i_y); X X if (cur_imf == img->imf) { X switch (disp_mode) { X case CMAP_TRUE: X case CMAP_NEWS: X cmap_incr_redraw(img, i_y); X break; X case RGB_LRECT: X incr_redraw(img, i_y); X break; X case RGB_WRITE: X nonrect_incr_redraw(img, i_y); X break; X } X } X screen_handle(0); X X if (!img->gif_interlaced) X return(img->data + ++i_y * img->width); X X i_y += pass_width[pass]; X if (i_y >= img->height) { X pass++; X i_y = pass_start[pass]; X } X return(img->data + i_y * img->width); X} X Xint getbyte(fp) XFILE* fp; X{ X int ch; X X err = 0; X if ((ch = fgetc(fp)) == EOF) { X err = 1; X return(READ_ERROR); X } X return(ch & 255); X} X Xint getword(fp) XFILE* fp; X{ X int c1, c2; X X err = 0; X if ((c1 = fgetc(fp)) == EOF) { X err = 1; X return(0); X } X if ((c2 = fgetc(fp)) == EOF) { X err = 1; X return(0); X } X return(((c2 & 255) << 8) | (c1 & 255)); X} X Xskipblocks(fp) XFILE* fp; X{ X int len; X static char buf[256]; X X err = 0; X X for (;;) { X len = getbyte(fp); X reterr("EOF in blocks"); X X if (len == 0) X return(0); X X if (fread(buf, len, 1, fp) != 1) { X puts("EOF in blocks"); X err = 1; X return(0); X } X } X} X Xvoid set_display_mode(); Xvoid save_colourmap(); Xvoid set_colourmap(); Xvoid toggle_colourmap(); Xvoid restore_colourmap(); X Xscreen_init(maxwidth, maxheight) Xint maxwidth; Xint maxheight; X{ X struct imgfile* imf; X X init_newsmap(); X X if (stay_in_foreground) X foreground(); X X prefsize(win_width = maxwidth * mag, win_height = maxheight * mag); X if (winopen("igif") < 0) { X fprintf(stderr, "igif: couldn't open a window.\n"); X exit(1); X } X set_display_mode(); X X if (disp_mode == RGB_LRECT || disp_mode == RGB_WRITE) X RGBmode(); X X gconfig(); X X if (disp_mode == RGB_LRECT) X rectzoom((float)mag, (float)mag); X X if (disp_mode == CMAP_TRUE) X save_colourmap(); X X rectf(0, 0, win_width - 1, win_height - 1); X X qdevice(REDRAW); X qdevice(PIECECHANGE); X qdevice(WINQUIT); X qdevice(LEFTMOUSE); X qdevice(MIDDLEMOUSE); X qdevice(INPUTCHANGE); X X qdevice(NKEY); X qdevice(PKEY); X qdevice(QKEY); X X qdevice(MENUBUTTON); X imgmenu = newpup(); X addtopup(imgmenu, "images %t"); X for (imf = imf_list; imf != NULL; imf = imf->next) X addtopup(imgmenu, imf->name); X} X Xscreen_handle(block) Xint block; X{ X short data; X int i; X struct imgfile* imf; X X if (block) X update_loadinfo(); X X do { X while (qtest()) { X switch (qread(&data)) { X case MENUBUTTON: X if ((i = dopup(imgmenu)) <= 0) X break; X for (cur_imf = imf_list; i > 1; i--) X cur_imf = cur_imf->next; X new_imf(); X break; X case PKEY: X case MIDDLEMOUSE: X if (data == 0) X break; X for (imf = imf_list; imf != NULL; imf = imf->next) X if (imf->next == cur_imf || X (imf->next == NULL && cur_imf == imf_list)) X break; X X cur_imf = imf; X new_imf(); X break; X case NKEY: X case LEFTMOUSE: X /* no need to redraw if we have only one image */ X if (imf_list->next == NULL || data == 0) X break; X if ((cur_imf = cur_imf->next) == NULL) X cur_imf = imf_list; X new_imf(); X break; X case REDRAW: X case PIECECHANGE: X if (cur_imf != NULL) { X cur_img = cur_imf->imglist; X if (cur_img != NULL) { X redrawing = 1; X redraw_line = 0; X paint_background(cur_img); X } X else X redrawing = 0; X } X break; X case QKEY: X case WINQUIT: X if (disp_mode == CMAP_TRUE) X restore_colourmap(); X exit(0); X case INPUTCHANGE: X if (disp_mode == CMAP_TRUE && cur_imf->imglist != NULL) X toggle_colourmap(cur_imf->imglist); X break; X default: X break; X } X } X if (redrawing) { X switch (disp_mode) { X case CMAP_TRUE: X case CMAP_NEWS: X redraw_line = cmap_incr_redraw(cur_img, redraw_line); X break; X case RGB_LRECT: X redraw_line = incr_redraw(cur_img, redraw_line); X break; X case RGB_WRITE: X redraw_line = nonrect_incr_redraw(cur_img, redraw_line); X break; X } X X if (redraw_line >= cur_img->height) { X cur_img = cur_img->next; X if (cur_img == NULL) X redrawing = 0; X else X redraw_line = 0; X } X } X } while (block); X} X Xnew_imf() X{ X wintitle(image_title(cur_imf)); X cur_img = cur_imf->imglist; X if (cur_img != NULL) { X if (disp_mode == CMAP_TRUE) X set_colourmap(cur_img); X paint_background(cur_img); X redrawing = 1; X redraw_line = 0; X } X else X redrawing = 0; X} X Xupdate_loadinfo() X{ X if (cur_imf != NULL) X wintitle(image_title(cur_imf)); X} X Xno_mem() X{ X fprintf(stderr, "out of memory\n"); X exit(1); X} X X Xstruct mem_image* add_image(width, height, depth, scr_width, scr_height) Xint width; Xint height; Xint depth; Xint scr_width; Xint scr_height; X{ X struct mem_image* img; X X if ((img = (struct mem_image*)malloc(sizeof(struct mem_image))) == NULL) X no_mem(); X X img->width = width; X img->height = height; X img->depth = depth; X img->colourmap = NULL; X img->mapmap = NULL; X img->gif_interlaced = 0; X img->seq = -1; X X img->x_off = (win_width - scr_width * mag) / 2; X img->y_off = (win_height - scr_height * mag) / 2; X /*img->state = LOADING;*/ X X if ((img->data = malloc(width * height)) == NULL) X no_mem(); X X bzero(img->data, width * height); X X img->next = NULL; X X return(img); X} X Xchar* image_title(imf) Xstruct imgfile* imf; X{ X static char title[256]; X char lbuf[32]; X X sprintf(lbuf, "%d ", loading); X X sprintf(title, "%s%s", X loading > 0 ? lbuf : "", X imf->name); X X return(title); X} X X Xpaint_background(img) Xstruct mem_image* img; X{ X int xleft, xright, ytop, ybottom; X X switch (disp_mode) { X case RGB_LRECT: X RGBcolor(img->colourmap[img->background] & 255, X (img->colourmap[img->background] >> 8) & 255, X (img->colourmap[img->background] >> 16) & 255); X break; X case RGB_WRITE: X RGBcolor(*((char*)img->colourmap + img->background), X *((char*)img->colourmap + img->maplen + img->background), X *((char*)img->colourmap + img->maplen * 2 + img->background)); X break; X case CMAP_NEWS: X color(rgb2newsmap(img->colourmap[img->background] & 255, X (img->colourmap[img->background] >> 8) & 255, X (img->colourmap[img->background] >> 16) & 255)); X break; X case CMAP_TRUE: X if (img->mapmap[img->background] >= 0) X color(img->mapmap[img->background]); X else { X int m; X X /* we haven't mapped any colours yet so collision isn't possible */ X m = rgb2newsmap(img->colourmap[img->background] & 255, X (img->colourmap[img->background] >> 8) & 255, X (img->colourmap[img->background] >> 16) & 255); X img->mapmap[img->background] = m; X color(m); X } X } X X if (erase_all) { X rectf(0, 0, win_width, win_height); X return; X } X X if (img->imf->width >= win_width && img->imf->height >= win_height) X return; X X xleft = (win_width - img->imf->width * mag) / 2; X xright = win_width - img->imf->width * mag - xleft; X ybottom = (win_height - img->imf->height * mag) / 2; X ytop = win_height - img->imf->height * mag - ybottom; X X rectf(0, 0, win_width - 1, ybottom); X rectf(0, 0, xleft, win_height - 1); X rectf(0, win_height - ytop, win_width - 1, win_height - 1); X rectf(win_width - xright, 0, win_width - 1, win_height - 1); X} X Xint incr_redraw(img, line) Xregister struct mem_image* img; Xregister int line; X{ X static int argb_buf[XMAXSCREEN]; X register char* p; X register int* argb; X X p = img->data + line * img->width + img->width - 1; X argb = argb_buf + img->width - 1; X X while (argb >= argb_buf) X *argb-- = img->colourmap[*p--]; X X lrectwrite(img->x_off, X (win_height - (line + 1) * mag) - img->y_off, X img->width /* * mag */ - 1 + img->x_off, X (win_height - (line + 1) * mag) - img->y_off, X argb_buf); X X return(line + 1); X} X X X/* This is based on code From: moss@BRL.MIL ("Gary S. Moss", VLD/VMB) */ X Xint nonrect_incr_redraw(img, line) Xregister struct mem_image* img; Xregister int line; X{ X static unsigned char Red_pixels[XMAXSCREEN]; X static unsigned char Green_pixels[XMAXSCREEN]; X static unsigned char Blue_pixels[XMAXSCREEN]; X register short i; X register char* p; X register char* red_map; X register char* green_map; X register char* blue_map; X X p = img->data + line * img->width; X X red_map = (char*)img->colourmap; X green_map = (char*)img->colourmap + img->maplen; X blue_map = (char*)img->colourmap + img->maplen * 2; X X for (i = 0; i < img->width * mag; i++, p++) { X Red_pixels[i] = red_map[*p]; X Green_pixels[i] = green_map[*p]; X Blue_pixels[i] = blue_map[*p]; X if (mag == 2) { X Red_pixels[++i] = red_map[*p]; X Green_pixels[i] = green_map[*p]; X Blue_pixels[i] = blue_map[*p]; X } X } X X cmov2i(img->x_off, (win_height - (line + 1) * mag) - img->y_off); X writeRGB(img->width * mag, Red_pixels, Green_pixels, Blue_pixels); X if (mag == 2) { X cmov2i(img->x_off, (win_height - (line + 1) * mag) - img->y_off + 1); X writeRGB(img->width * mag, Red_pixels, Green_pixels, Blue_pixels); X } X X return(line + 1); X} X Xint cmap_incr_redraw(img, line) Xregister struct mem_image* img; Xregister int line; X{ X static unsigned short cmap[XMAXSCREEN]; X register short i; X register char* p; X X p = img->data + line * img->width; X X for (i = 0; i < img->width * mag; i++, p++) { X cmap[i] = img->mapmap[*p]; X if (mag == 2) X cmap[++i] = img->mapmap[*p]; X } X X cmov2i(img->x_off, (win_height - (line + 1) * mag) - img->y_off); X writepixels(img->width * mag, cmap); X if (mag == 2) { X cmov2i(img->x_off, (win_height - (line + 1) * mag) - img->y_off + 1); X writepixels(img->width * mag, cmap); X } X X return(line + 1); X} X X/* auto-dectection code From: */ X Xvoid set_display_mode() X{ X char buf[32]; X X gversion(buf); X X if (getplanes() <= 8) X disp_mode = true_colours ? CMAP_TRUE : CMAP_NEWS; X else if (strncmp(buf, "GL4D-", 5) || !use_lrectwrite) X disp_mode = RGB_WRITE; X else X disp_mode = RGB_LRECT; X} X Xstruct map_entry { X int orig_index; X int abgr; X int screen_index; X int used; X}; X Xstatic int colour_used[256]; X Xint map_ent_cmp(a, b) Xstruct map_entry* a; Xstruct map_entry* b; X{ X if (!a->used) X return(1); X if (!b->used) X return(-1); X return(a->abgr - b->abgr); X} X Xstatic int abs(x) X{ X if (x < 0) return(-x); X return(x); X} X X/* X * Depending on how the images will be displayed, we may wish to X * change the colour maps in our images into a more convenient form. X * Lrectwrite() is the default, but writeRGB would rather have 3 X * tables. For screens with colour maps, we can either map the X * images colour map into the screen colour map or load the screen X * colour map with the image colour map. In the latter case we'll X * want to compress the colourmap as much as possible to minimize X * on-screen weirdness. It would also be nice to put the image X * colours into screen map entries that won't change a lot when X * they are re-loaded. We could also change the image data to X * avoid a colourmap to colourmap conversion, but it probably isn't X * worth it. X * X * This should really be 3 or 4 separate functions :-( X */ Xvoid adjust_colourmap(img) Xstruct mem_image* img; X{ X int i, r, g, b; X int mindiff, best; X unsigned char* red; X unsigned char* green; X unsigned char* blue; X int new; X char* p; X int workspace[256]; X struct map_entry map[256]; X X if (disp_mode == RGB_LRECT) X return; X X if (disp_mode == RGB_WRITE) { X /* do it for writeRGB */ X for (i = 0; i < img->maplen; i++) X workspace[i] = img->colourmap[i]; X red = (unsigned char*)img->colourmap; X green = (unsigned char*)img->colourmap + img->maplen; X blue = (unsigned char*)img->colourmap + img->maplen * 2; X for (i = 0; i < img->maplen; i++) { X *red++ = workspace[i] & 255; X *green++ = (workspace[i] >> 8) & 255; X *blue++ = (workspace[i] >> 16) & 255; X } X return; X } X X /*img->mapmap = (int*)malloc(img->maplen * sizeof(int));*/ X /* Don't necessarily need 256, but ... */ X img->mapmap = (int*)malloc(256 * sizeof(int)); X if (img->mapmap == NULL) X no_mem(); X X /* colourmapped display */ X if (disp_mode == CMAP_NEWS) { X if (!dither) { X for (i = 0; i < img->maplen; i++) { X img->mapmap[i] = rgb2newsmap( X r = img->colourmap[i] & 255, X g = (img->colourmap[i] >> 8) & 255, X b = (img->colourmap[i] >> 16) & 255 X ); X } X } X else { X /* we're going to change all the indicies anyways... */ X for (i = 0; i < 256; i++) X img->mapmap[i] = i; X init_floydstein(img); X } X return; X } X X /* disp_mode == CMAP_TRUE */ X X /* A little kludge here. The basic idea is that all the images X * which use a global colourmap should have the same mapmap. What X * is not so pretty is that maybe the first image didn't use the X * global map. X */ X if (img->imf->imglist != img && X img->imf->imglist->colourmap == img->colourmap) { X int qq; X X img->mapmap = img->imf->imglist->mapmap; X for (i = 0; i < 256; i++) X colour_used[i] = 0; X X for (i = 0; i < 256; i++) X if (img->mapmap[i] >= 0) X colour_used[img->mapmap[i]] = 1; X return; X } X X for (i = 0; i < 256; i++) { X img->mapmap[i] = -1; X colour_used[i] = 0; X } X X#ifdef OLD X /* disp_mode == CMAP_TRUE */ X /* ok, let's crank */ X for (i = 0; i < img->maplen; i++) { X map[i].orig_index = i; X map[i].abgr = img->colourmap[i]; X map[i].screen_index = -1; X map[i].used = 0; X } X X for (p = img->data, i = img->width * img->height; i > 0; i--) X map[*p++].used = 1; X X qsort(map, img->maplen, sizeof(struct map_entry), map_ent_cmp); X X for (i = 1; i < img->maplen; i++) { X if (!map[i].used) X break; /* 'cause all the unused ones are at the end */ X if (map[i].abgr == map[i - 1].abgr) X map[i].used = -1; X } X X for (i = 0; i < 256; i++) X workspace[i] = 0; /* i.e., we haven't used this screen colour */ X X for (i = 0; i < img->maplen; i++) { X if (!map[i].used) X break; X if (map[i].used == -1) X continue; X new = rgb2newsmap(map[i].abgr & 255, X (map[i].abgr >> 8) & 255, X (map[i].abgr >> 16) & 255 X ); X if (workspace[new] == 0) { X workspace[new] = 1; X map[i].screen_index = new; X } X } X X new = 0; X for (i = 0; i < img->maplen; i++) X if (map[i].used && map[i].screen_index == -1) X new++; X printf("%d hard colours to map\n", new); X X#ifdef SIMPFIT X /* X * allocate entries for the guys who collided; I should do some sort of X * best fitting, but for now just start from the top. The only best X * fit algorithm I can think of is rather expensive. X */ X new = 255; X for (i = 0; i < img->maplen; i++) { X if (!map[i].used) X break; X if (map[i].screen_index != -1) X continue; X while (workspace[new]) X new--; X workspace[new] = 1; X map[i].screen_index = new; X } X#endif X X for (i = 0; i < img->maplen; i++) { X int d; X short r,g,b; X if (!map[i].used) X break; X if (map[i].screen_index != -1) X continue; X best = 0; X mindiff = 10000; X for (new = 0; new < 256; new++) { X if (workspace[new]) X continue; X getmcolor(new, &r, &g, &b); X d = abs(r - ((map[i].abgr & 255))) + X abs(g - ((map[i].abgr >> 8) & 255)) + X abs(b - ((map[i].abgr >> 16) & 255)); X if (d < mindiff) { X best = new; X mindiff = d; X } X } X workspace[best] = 1; X map[i].screen_index = best; X } X X /* finally, re-define the image's colourmap. Don't forget about those X * duplicate entries. X */ X for (i = 0; i < img->maplen; i++) X img->mapmap[i] = -1; X X for (i = 0; i < img->maplen; i++) { X if (!map[i].used) X break; X if (map[i].used == -1) X img->mapmap[map[i].orig_index] = X img->mapmap[map[i - 1].orig_index]; X else X img->mapmap[map[i].orig_index] = map[i].screen_index; X } X#endif X} X Xstatic short orig_colourmap[256 * 3]; Xstatic int orig_cmap_inst = 1; X Xtrue_cmap(img, line) Xstruct mem_image* img; Xint line; X{ X register unsigned char* p; X register int i; X register int try; X short r,g,b; X X for (p = img->data + img->width * line, i = img->width; i >= 0; p++, i--) { X if (img->mapmap[*p] >= 0) X continue; X try = rgb2newsmap(r = img->colourmap[*p] & 255, X g = (img->colourmap[*p] >> 8) & 255, X b = (img->colourmap[*p] >> 16) & 255 X ); X if (colour_used[try]) { X int mindiff, d, j; X X try = 255; X mindiff = 10000; X for (j = 255; j >= 0; j--) { X if (colour_used[j]) X continue; X if ((d = abs(r - orig_colourmap[j * 3]) + X abs(g - orig_colourmap[j * 3 + 1]) + X abs(b - orig_colourmap[j * 3 + 2])) < mindiff) { X try = j; X mindiff = d; X } X } X } X img->mapmap[*p] = try; X colour_used[try] = 1; X if (!orig_cmap_inst && img->imf == cur_imf) X mapcolor(try, r, g, b); X } X} X Xvoid save_colourmap() X{ X short* p; X int i; X X for (i = 0, p = orig_colourmap; i < 256; i++, p += 3) X getmcolor(i, p, p + 1, p + 2); X} X Xvoid set_colourmap(img) Xstruct mem_image* img; X{ X int i; X X for (i = 0; i < img->maplen; i++) X if (img->mapmap[i] >= 0) X mapcolor(img->mapmap[i], X img->colourmap[i] & 255, X (img->colourmap[i] >> 8) & 255, X (img->colourmap[i] >> 16) & 255 X ); X orig_cmap_inst = 0; X} X Xvoid toggle_colourmap(img) Xstruct mem_image* img; X{ X if (orig_cmap_inst) X set_colourmap(img); X else X restore_colourmap(); X} X Xvoid restore_colourmap() X{ X short* p; X int i; X X for (i = 0, p = orig_colourmap; i < 256; i++, p += 3) X mapcolor(i, p[0], p[1], p[2]); X orig_cmap_inst = 1; X} SHAR_EOF fi # end of overwriting check # End of shell archive exit 0   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00820; 7 Sep 90 3:06 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00790; 7 Sep 90 2:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab00761; 7 Sep 90 2:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa01525; 7 Sep 90 2:30 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10196; Thu, 6 Sep 90 23:26:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 06:10:35 GMT From: George Phillips Organization: University of British Columbia, Vancouver, B.C., Canada Subject: igif 2.0 part 2/2 Message-Id: <9469@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL And here's part 2 ... #! /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: # decoder.c # newsmap.c # floydstein.c # errs.h # std.h # mem_image.h # newsmap.h # imgfile.h # This archive created: Thu Sep 6 22:51:24 1990 export PATH; PATH=/bin:$PATH echo shar: extracting "'decoder.c'" '(11341 characters)' if test -f 'decoder.c' then echo shar: will not over-write existing file "'decoder.c'" else sed 's/^X//' << \SHAR_EOF > 'decoder.c' X/* DECODE.C - An LZW decoder for GIF X * Copyright (C) 1987, by Steven A. Bennett X * X * Permission is given by the author to freely redistribute and include X * this code in any program as long as this credit is given where due. X * X * In accordance with the above, I want to credit Steve Wilhite who wrote X * the code which this is heavily inspired by... X * X * GIF and 'Graphics Interchange Format' are trademarks (tm) of X * Compuserve, Incorporated, an H&R Block Company. X * X * Release Notes: This file contains a decoder routine for GIF images X * which is similar, structurally, to the original routine by Steve Wilhite. X * It is, however, somewhat noticably faster in most cases. X * X * GWP: I've hacked this around to make a somewhat cleaner interface... X */ X X#include X X#include "std.h" X#include "errs.h" X X#include "mem_image.h" X XIMPORT TEXT *malloc(); /* Standard C library allocation */ X X/* IMPORT INT get_byte() X * X * - This external (machine specific) function is expected to return X * either the next byte from the GIF file, or a negative number, as X * defined in ERRS.H. X */ XIMPORT INT get_byte(); X X/* IMPORT INT out_line(pixels, linelen) X * UBYTE pixels[]; X * INT linelen; X * X * - This function takes a full line of pixels (one byte per pixel) and X * displays them (or does whatever your program wants with them...). It X * should return zero, or negative if an error or some other event occurs X * which would require aborting the decode process... Note that the length X * passed will almost always be equal to the line length passed to the X * decoder function, with the sole exception occurring when an ending code X * occurs in an odd place in the GIF file... In any case, linelen will be X * equal to the number of pixels passed... X */ Xextern char* out_line(); X X/* IMPORT INT bad_code_count; X * X * This value is the only other global required by the using program, and X * is incremented each time an out of range code is read by the decoder. X * When this value is non-zero after a decode, your GIF file is probably X * corrupt in some way... X */ XIMPORT INT bad_code_count; X X#define MAX_CODES 4095 X X/* Static variables */ XLOCAL WORD curr_size; /* The current code size */ XLOCAL WORD clear; /* Value for a clear code */ XLOCAL WORD ending; /* Value for a ending code */ XLOCAL WORD newcodes; /* First available code */ XLOCAL WORD top_slot; /* Highest code for current size */ XLOCAL WORD slot; /* Last read code */ X X/* The following static variables are used X * for seperating out codes X */ XLOCAL WORD navail_bytes = 0; /* # bytes left in block */ XLOCAL WORD nbits_left = 0; /* # bits left in current byte */ XLOCAL UTINY b1; /* Current byte */ XLOCAL UTINY byte_buff[257]; /* Current block */ XLOCAL UTINY *pbytes; /* Pointer to next byte in block */ X XLOCAL LONG code_mask[13] = { X 0, X 0x0001, 0x0003, X 0x0007, 0x000F, X 0x001F, 0x003F, X 0x007F, 0x00FF, X 0x01FF, 0x03FF, X 0x07FF, 0x0FFF X }; X X X/* This function initializes the decoder for reading a new image. X */ XLOCAL WORD init_exp(size) X WORD size; X { X curr_size = size + 1; X top_slot = 1 << curr_size; X clear = 1 << size; X ending = clear + 1; X slot = newcodes = ending + 1; X navail_bytes = nbits_left = 0; X return(0); X } X X/* get_next_code() X * - gets the next code from the GIF file. Returns the code, or else X * a negative number in case of file errors... X */ XLOCAL WORD get_next_code(fp) XFILE* fp; X { X WORD i, x; X ULONG ret; X X if (nbits_left == 0) X { X if (navail_bytes <= 0) X { X X /* Out of bytes in current block, so read next block X */ X pbytes = byte_buff; X if ((navail_bytes = fgetc(fp)) == EOF) X return(READ_ERROR); X else if (navail_bytes) X { X if (fread(byte_buff, navail_bytes, 1, fp) != 1) X return(READ_ERROR); X } X } X b1 = *pbytes++; X nbits_left = 8; X --navail_bytes; X } X X ret = b1 >> (8 - nbits_left); X while (curr_size > nbits_left) X { X if (navail_bytes <= 0) X { X X /* Out of bytes in current block, so read next block X */ X pbytes = byte_buff; X if ((navail_bytes = fgetc(fp)) == EOF) X return(READ_ERROR); X else if (navail_bytes) X { X if (fread(byte_buff, navail_bytes, 1, fp) != 1) X return(READ_ERROR); X } X } X b1 = *pbytes++; X ret |= b1 << nbits_left; X nbits_left += 8; X --navail_bytes; X } X nbits_left -= curr_size; X ret &= code_mask[curr_size]; X return((WORD)(ret)); X } X X X/* The reason we have these seperated like this instead of using X * a structure like the original Wilhite code did, is because this X * stuff generally produces significantly faster code when compiled... X * This code is full of similar speedups... (For a good book on writing X * C for speed or for space optomisation, see Efficient C by Tom Plum, X * published by Plum-Hall Associates...) X */ XLOCAL UTINY stack[MAX_CODES + 1]; /* Stack for storing pixels */ XLOCAL UTINY suffix[MAX_CODES + 1]; /* Suffix table */ XLOCAL UWORD prefix[MAX_CODES + 1]; /* Prefix linked list */ X X/* WORD decoder(linewidth) X * WORD linewidth; * Pixels per line of image * X * X * - This function decodes an LZW image, according to the method used X * in the GIF spec. Every *linewidth* "characters" (ie. pixels) decoded X * will generate a call to out_line(), which is a user specific function X * to display a line of pixels. The function gets it's codes from X * get_next_code() which is responsible for reading blocks of data and X * seperating them into the proper size codes. Finally, get_byte() is X * the global routine to read the next byte from the GIF file. X * X * It is generally a good idea to have linewidth correspond to the actual X * width of a line (as specified in the Image header) to make your own X * code a bit simpler, but it isn't absolutely necessary. X * X * Returns: 0 if successful, else negative. (See ERRS.H) X * X */ X XWORD decoder(fp, img) XFILE* fp; Xstruct mem_image* img; X { X FAST UTINY *sp, *bufptr; X FAST WORD code, fc, oc, bufcnt; X WORD c, size, ret; X X /* Initialize for decoding a new image... X */ X if ((size = fgetc(fp)) == EOF) X return(READ_ERROR); X if (size < 2 || 9 < size) X return(BAD_CODE_SIZE); X init_exp(size); X X /* Initialize in case they forgot to put in a clear code. X * (This shouldn't happen, but we'll try and decode it anyway...) X */ X oc = fc = 0; X X /* Set up the stack pointer and decode buffer pointer X */ X sp = stack; X bufptr = img->data; X bufcnt = img->width; X X /* This is the main loop. For each code we get we pass through the X * linked list of prefix codes, pushing the corresponding "character" for X * each code onto the stack. When the list reaches a single "character" X * we push that on the stack too, and then start unstacking each X * character for output in the correct order. Special handling is X * included for the clear code, and the whole thing ends when we get X * an ending code. X */ X while ((c = get_next_code(fp)) != ending) X { X X /* If we had a file error, return without completing the decode X */ X if (c < 0) { X return(0); X } X X /* If the code is a clear code, reinitialize all necessary items. X */ X if (c == clear) X { X curr_size = size + 1; X slot = newcodes; X top_slot = 1 << curr_size; X X /* Continue reading codes until we get a non-clear code X * (Another unlikely, but possible case...) X */ X while ((c = get_next_code(fp)) == clear) X ; X X /* If we get an ending code immediately after a clear code X * (Yet another unlikely case), then break out of the loop. X */ X if (c == ending) X break; X X /* Finally, if the code is beyond the range of already set codes, X * (This one had better NOT happen... I have no idea what will X * result from this, but I doubt it will look good...) then set it X * to color zero. X */ X if (c >= slot) X c = 0; X X oc = fc = c; X X /* And let us not forget to put the char into the buffer... And X * if, on the off chance, we were exactly one pixel from the end X * of the line, we have to send the buffer to the out_line() X * routine... X */ X *bufptr++ = c; X if (--bufcnt == 0) X { X bufptr = out_line(img); X bufcnt = img->width; X } X } X else X { X X /* In this case, it's not a clear code or an ending code, so X * it must be a code code... So we can now decode the code into X * a stack of character codes. (Clear as mud, right?) X */ X code = c; X X /* Here we go again with one of those off chances... If, on the X * off chance, the code we got is beyond the range of those already X * set up (Another thing which had better NOT happen...) we trick X * the decoder into thinking it actually got the last code read. X * (Hmmn... I'm not sure why this works... But it does...) X */ X if (code >= slot) X { X if (code > slot) X ++bad_code_count; X code = oc; X *sp++ = fc; X } X X /* Here we scan back along the linked list of prefixes, pushing X * helpless characters (ie. suffixes) onto the stack as we do so. X */ X while (code >= newcodes) X { X *sp++ = suffix[code]; X code = prefix[code]; X } X X /* Push the last character on the stack, and set up the new X * prefix and suffix, and if the required slot number is greater X * than that allowed by the current bit size, increase the bit X * size. (NOTE - If we are all full, we *don't* save the new X * suffix and prefix... I'm not certain if this is correct... X * it might be more proper to overwrite the last code... X */ X *sp++ = code; X if (slot < top_slot) X { X suffix[slot] = fc = code; X prefix[slot++] = oc; X oc = c; X } X if (slot >= top_slot) X if (curr_size < 12) X { X top_slot <<= 1; X ++curr_size; X } X X /* Now that we've pushed the decoded string (in reverse order) X * onto the stack, lets pop it off and put it into our decode X * buffer... And when the decode buffer is full, write another X * line... X */ X while (sp > stack) X { X *bufptr++ = *(--sp); X if (--bufcnt == 0) X { X bufptr = out_line(img); X bufcnt = img->width; X } X } X } X } X ret = 0; X if (bufcnt != img->width) X out_line(img); /* buf, (linewidth - bufcnt));*/ X return(ret); X } X SHAR_EOF fi # end of overwriting check echo shar: extracting "'newsmap.c'" '(2217 characters)' if test -f 'newsmap.c' then echo shar: will not over-write existing file "'newsmap.c'" else sed 's/^X//' << \SHAR_EOF > 'newsmap.c' X/* X * newsmap.c -- convert an RGB triplet into a nearby value from the X * NeWS 8 plane colourmap. X * X * Note: I could hard code the inverse tables, but this is not so X * inscrutable in case it should be changed. Besides, the true X * colour mode could use this information in fitting the colour X * collisions to a next-best choice. X */ X X#include "newsmap.h" X X#define gray_base (32) Xshort gray_level[] = { X 0, 10, 20, 30, 40, 51, 61, 71, 81, 91, 102, 112, 122, 132, X 142, 153, 163, 173, 183, 193, 204, 214, 224, 234, 244, 255 X}; X#define gray_run (sizeof(gray_level) / sizeof(short)) X#define gray_black (56) X#define gray_white (255) X X#define colourbase (56) Xshort red_level[] = { 0, 63, 127, 191, 255 }; Xshort green_level[] = { 0, 36, 72, 109, 145, 182, 218, 255 }; Xshort blue_level[] = { 0, 63, 127, 191, 255 }; X X#define nreds (sizeof(red_level) / sizeof(short)) X#define ngreens (sizeof(green_level) / sizeof(short)) X#define nblues (sizeof(blue_level) / sizeof(short)) X Xshort gray_inverse[256]; Xshort red_inverse[256]; Xshort green_inverse[256]; Xshort blue_inverse[256]; X Xstatic void run_ramp(); X Xvoid init_newsmap() X{ X int i; X X run_ramp(gray_run, gray_level, gray_inverse); X for (i = 0; i < 256; i++) { X if (gray_inverse[i] == 0) X gray_inverse[i] = gray_black; X else if (gray_inverse[i] == gray_run - 1) X gray_inverse[i] = gray_white; X else X gray_inverse[i] += gray_base - 1; X } X X run_ramp(ngreens, green_level, green_inverse); X run_ramp(nreds, red_level, red_inverse); X for (i = 0; i < 256; i++) X red_inverse[i] *= ngreens; X X run_ramp(nblues, blue_level, blue_inverse); X for (i = 0; i < 256; i++) X blue_inverse[i] *= ngreens * nreds; X} X Xstatic void run_ramp(n, level, inverse) Xint n; Xshort level[]; Xshort inverse[]; X{ X int i; X int closest = 0; X X for (i = 0; i < 256; i++) { X if (abs(i - level[closest]) > abs(i - level[closest + 1])) X closest++; X inverse[i] = closest; X if (closest == n - 1) X break; X } X for (; i < 256; i++) X inverse[i] = closest; X} X Xstatic int abs(n) Xint n; X{ X if (n < 0) X return(-n); X return(n); X} X Xint rgb2newsmap(r, g, b) Xint r; Xint g; Xint b; X{ X if (r == g && g == b) X return(gray_inverse[r]); X X return(red_inverse[r] + green_inverse[g] + blue_inverse[b] + colourbase); X} SHAR_EOF fi # end of overwriting check echo shar: extracting "'floydstein.c'" '(5035 characters)' if test -f 'floydstein.c' then echo shar: will not over-write existing file "'floydstein.c'" else sed 's/^X//' << \SHAR_EOF > 'floydstein.c' X/* X * floydstein.c -- perform Floyd-Steinberg dithering on an in-memory image. X * X * This is designed around the NeWS colour map and is for colour mapped X * images. Beware. X * X * This code is based on ppmquant from Jef Poskanzer's PBM+ package which is X * X * Copyright (C) 1989 by Jef Poskanzer. X * X * Permission to use, copy, modify, and distribute this software and its X * documentation for any purpose and without fee is hereby granted, provided X * that the above copyright notice appear in all copies and that both that X * copyright notice and this permission notice appear in supporting X * documentation. This software is provided "as is" without express or X * implied warranty. X*/ X X#include X#include X X#include "mem_image.h" X#include "newsmap.h" X Xlong* long_alloc(); X Xunsigned char red[256], green[256], blue[256]; Xunsigned short news_red[256]; Xunsigned short news_green[256]; Xunsigned short news_blue[256]; Xlong *thisrerr, *nextrerr, *thisgerr, *nextgerr, *thisberr, *nextberr; Xint fs_direction; X Xvoid init_floydstein(img) Xstruct mem_image* img; X{ X register int col; X#define FS_SCALE 1024 X int i; X X /* Build a local colour map for convenience */ X for (i = 0; i < img->maplen; i++) { X red[i] = img->colourmap[i] & 255; X green[i] = (img->colourmap[i] >> 8) & 255; X blue[i] = (img->colourmap[i] >> 16) & 255; X } X X for (i = 0; i < 256; i++) X getmcolor(i, news_red + i, news_green + i, news_blue + i); X X /* Initialize Floyd-Steinberg error vectors. */ X thisrerr = long_alloc(img->width + 2); X nextrerr = long_alloc(img->width + 2); X thisgerr = long_alloc(img->width + 2); X nextgerr = long_alloc(img->width + 2); X thisberr = long_alloc(img->width + 2); X nextberr = long_alloc(img->width + 2); X X srand((int)time(0)); X X for (col = 0; col < img->width + 2; col++) { X thisrerr[col] = rand() % (FS_SCALE * 2) - FS_SCALE; X thisgerr[col] = rand() % (FS_SCALE * 2) - FS_SCALE; X thisberr[col] = rand() % (FS_SCALE * 2) - FS_SCALE; X /* (random errors in [-1 .. 1]) */ X } X fs_direction = 1; X} X Xvoid floydstein(img, row) Xstruct mem_image* img; Xint row; X{ X register unsigned char* pP; X int rows, cols; X register int col, limitcol; X long* temperr; X register long sr, sg, sb; X int r, g, b; X#define FS_SCALE 1024 X int err; X int i; X X for (col = 0; col < img->width + 2; col++) X nextrerr[col] = nextgerr[col] = nextberr[col] = 0; X X if (fs_direction ) { X col = 0; X limitcol = img->width; X pP = img->data + row * img->width; X } X else { X col = img->width - 1; X limitcol = -1; X pP = img->data + row * img->width + img->width - 1; X } X X do { X /* Use Floyd-Steinberg errors to adjust actual color. */ X sr = red[*pP] * FS_SCALE + thisrerr[col + 1]; X sg = green[*pP] * FS_SCALE + thisgerr[col + 1]; X sb = blue[*pP] * FS_SCALE + thisberr[col + 1]; X r = sr / FS_SCALE; if (r < 0) r = 0; else if (r > 255) r = 255; X g = sg / FS_SCALE; if (g < 0) g = 0; else if (g > 255) g = 255; X b = sb / FS_SCALE; if (b < 0) b = 0; else if (b > 255) b = 255; X /* just for fun, replace the previous 3 lines with these */ X /*r = (sr / FS_SCALE) & 255; X g = (sg / FS_SCALE) & 255; X b = (sb / FS_SCALE) & 255;*/ X *pP = rgb2newsmap(r, g, b); X X if (fs_direction) { X err = sr - news_red[*pP] * FS_SCALE; X thisrerr[col + 2] += ( err * 7 ) / 16; X nextrerr[col ] += ( err * 3 ) / 16; X nextrerr[col + 1] += ( err * 5 ) / 16; X nextrerr[col + 2] += ( err ) / 16; X err = sg - news_green[*pP] * FS_SCALE; X thisgerr[col + 2] += ( err * 7 ) / 16; X nextgerr[col ] += ( err * 3 ) / 16; X nextgerr[col + 1] += ( err * 5 ) / 16; X nextgerr[col + 2] += ( err ) / 16; X err = sb - news_blue[*pP] * FS_SCALE; X thisberr[col + 2] += ( err * 7 ) / 16; X nextberr[col ] += ( err * 3 ) / 16; X nextberr[col + 1] += ( err * 5 ) / 16; X nextberr[col + 2] += ( err ) / 16; X } X else { X err = sr - news_red[*pP] * FS_SCALE; X thisrerr[col ] += ( err * 7 ) / 16; X nextrerr[col + 2] += ( err * 3 ) / 16; X nextrerr[col + 1] += ( err * 5 ) / 16; X nextrerr[col ] += ( err ) / 16; X err = sg - news_green[*pP] * FS_SCALE; X thisgerr[col ] += ( err * 7 ) / 16; X nextgerr[col + 2] += ( err * 3 ) / 16; X nextgerr[col + 1] += ( err * 5 ) / 16; X nextgerr[col ] += ( err ) / 16; X err = sb - news_blue[*pP] * FS_SCALE; X thisberr[col ] += ( err * 7 ) / 16; X nextberr[col + 2] += ( err * 3 ) / 16; X nextberr[col + 1] += ( err * 5 ) / 16; X nextberr[col ] += ( err ) / 16; X } X if (fs_direction) { X col++; X pP++; X } X else { X col--; X pP--; X } X } while (col != limitcol); X X temperr = thisrerr; X thisrerr = nextrerr; X nextrerr = temperr; X temperr = thisgerr; X thisgerr = nextgerr; X nextgerr = temperr; X temperr = thisberr; X thisberr = nextberr; X nextberr = temperr; X fs_direction = !fs_direction; X} X Xclean_floyd() X{ X free(thisrerr); X free(nextrerr); X free(thisgerr); X free(nextgerr); X free(thisberr); X free(nextberr); X} X Xlong* long_alloc(n) Xint n; X{ X long* l; X X l = (long*)malloc(n * sizeof(long)); X X if (l == NULL) X no_mem(); X X return(l); X} SHAR_EOF fi # end of overwriting check echo shar: extracting "'errs.h'" '(366 characters)' if test -f 'errs.h' then echo shar: will not over-write existing file "'errs.h'" else sed 's/^X//' << \SHAR_EOF > 'errs.h' X/* Various error codes used by decoder X * and my own routines... It's okay X * for you to define whatever you want, X * as long as it's negative... It will be X * returned intact up the various subroutine X * levels... X */ X#define OUT_OF_MEMORY -10 X#define BAD_CODE_SIZE -20 X#define READ_ERROR -1 X#define WRITE_ERROR -2 X#define OPEN_ERROR -3 X#define CREATE_ERROR -4 X SHAR_EOF fi # end of overwriting check echo shar: extracting "'std.h'" '(278 characters)' if test -f 'std.h' then echo shar: will not over-write existing file "'std.h'" else sed 's/^X//' << \SHAR_EOF > 'std.h' X/* STD.H - My own standard header file... X */ X X#define LOCAL static X#define IMPORT extern X X#define FAST register X Xtypedef short WORD; Xtypedef unsigned short UWORD; Xtypedef char TEXT; Xtypedef unsigned char UTINY; Xtypedef long LONG; Xtypedef unsigned long ULONG; Xtypedef int INT; X SHAR_EOF fi # end of overwriting check echo shar: extracting "'mem_image.h'" '(282 characters)' if test -f 'mem_image.h' then echo shar: will not over-write existing file "'mem_image.h'" else sed 's/^X//' << \SHAR_EOF > 'mem_image.h' X/* X * mem_image.h X */ X Xstruct mem_image { X int* colourmap; X int* mapmap; X int maplen; X char* data; X int width; X int height; X int depth; X struct imgfile* imf; X struct mem_image* next; X X /* extras */ X int gif_interlaced; X int x_off; X int y_off; X int background; X int seq; X}; SHAR_EOF fi # end of overwriting check echo shar: extracting "'newsmap.h'" '(75 characters)' if test -f 'newsmap.h' then echo shar: will not over-write existing file "'newsmap.h'" else sed 's/^X//' << \SHAR_EOF > 'newsmap.h' X/* X * newsmap.h X */ X Xextern void init_newsmap(); Xextern int rgb2newsmap(); SHAR_EOF fi # end of overwriting check echo shar: extracting "'imgfile.h'" '(164 characters)' if test -f 'imgfile.h' then echo shar: will not over-write existing file "'imgfile.h'" else sed 's/^X//' << \SHAR_EOF > 'imgfile.h' X/* X * imgfile.h X */ X Xstruct imgfile { X char* filename; X char* name; X FILE* stream; X int width; X int height; X struct mem_image* imglist; X struct imgfile* next; X}; SHAR_EOF fi # end of overwriting check # End of shell archive exit 0   Received: from vmb.brl.mil by VMB.BRL.MIL id aa02767; 7 Sep 90 8:33 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02283; 7 Sep 90 8:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02119; 7 Sep 90 7:57 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa02102; 7 Sep 90 7:41 EDT Received: from ICINECA.CINECA.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4016; Fri, 07 Sep 90 07:40:07 EDT Received: from ICINECA by ICINECA.CINECA.IT (Mailer R2.07) with BSMTP id 1791; Fri, 07 Sep 90 13:40:22 ITA Received: from itnsg1.cineca.it by ICINECA.CINECA.IT (IBM VM SMTP R1.2) with TCP; Fri, 07 Sep 90 13:40:18 ITA Received: by itnsg1.cineca.it (5.52/890607.SGI) (for @icineca.cineca.it:info-iris@brl.mil) id AA01151; Fri, 7 Sep 90 13:38:41 MDT From: "Root (Valter Cavecchia" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Message-Id: <9009071138.AA01151@itnsg1.cineca.it> Subject: Name server problems To: info-iris@BRL.MIL Date: Fri, 7 Sep 90 13:38:39 MDT Cc: "Root (Valter Cavecchia" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Organization: Laboratorio di Fisica Computazionale I.N.F.M. Address: Loc. Pante`, I - 38050 Povo (TN) Italy X-Mailer: ELM [version 2.3 PL5] Hi to all, I have a problem related with my local nameserver configuration. I configured the machine as secondary server caching from the registered domain server, as follows -------- ; ; @(#)named.boot.slave 1.13 (Berkeley) 87/07/21 ; ; boot file for secondary name server ; Note that there should be one primary entry for each SOA record. ; ; sortlist 10.0.0.0 directory /usr/etc/named.d ; type domain source host/file backup file cache . root.cache secondary CINECA.IT 130.186.1.194 130.186.1.53 itnsg1.bak secondary 186.130.IN-ADDR.ARPA 130.186.1.194 130.186.1.53 itnsg1.rev.bak primary 0.0.127.IN-ADDR.ARPA loopback.rev forwarders 130.186.1.53 192.12.192.4 -------- ; ; loopback.rev -- PTR record for 127.1 (itnsg1.cineca.it) ; @ IN SOA itnsg1.cineca.it root.itnsg1.cineca.it ( 1.2 ; Serial 43200 ; Refresh 3 hours 3600 ; Retry 1 hour 360000 ; Expire 100 hours 86400 ) ; Minimum 24 hours itnsg1.cineca.it IN A 130.186.1.194 localhost.cineca.it. IN A 127.0.0.1 IN NS itnsg1.cineca.it ; 1 IN PTR localhost. -------- The defualt domain name is stored in /usr/etc/resolv.conf wich contains only one line: -------- domain cineca.it -------- Everything works well with this configuration, except for one thing. Our domain is very wide, in fact covering all the North-East side of Italy and we are a little university away from the central site. For strange administrative reasons we cannot act as a sub-domain. Frequently we need to connect local machines to the net for some time (demonstrations from vendors, tests and so on) and would like to tell our domain server (the local one) to recognize those machines without asking every time to the central site to put their names into the database. Putting the names in /etc/hosts won't help. So the question is the following: Is there any way to put local information in the local server database? Any hint is welcome. Thanks a lot in advance, - valter -- --------------------------------------------------------------------------- | Valter V. Cavecchia | Bitnet: cavecchi@itncisca | | Centro di Fisica del C.N.R. | Internet: root@itnsg1.cineca.it | | I-38050 Povo (TN) - Italy | Decnet: itnvax::cavecchia (37.65) | ---------------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03117; 7 Sep 90 8:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02455; 7 Sep 90 8:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02318; 7 Sep 90 8:08 EDT Received: from fngate.fnal.gov by VGR.BRL.MIL id aa02173; 7 Sep 90 8:05 EDT Received: from WARNER.DECnet MAIL11D_V3 by fngate.fnal.gov (5.57/Ultrix2.4-C) id AA21929; Fri, 7 Sep 90 06:50:27 CDT Date: Fri, 7 Sep 90 06:50:26 CDT Message-Id: <9009071150.AA21929@fngate.fnal.gov> From: "Frank J. Nagy:VAX Guru,Wizard&Loose Cannon" To: "info-iris@BRL.MIL %fngate.dnet"@fngate Cc: NAGY@fngate.fnal.gov Subject: RE: Help: 32 MB in PI25 Here are two messages about upgrading PIs past 16 MB. Basically what one wants to do is remove the 1 MB SIMMs and replace them with 4 MB SIMMs. The 4 MB SIMMs allow one to upgrade the PIs with anything from 16 MB up to 64 MB of memory. The second message gives a supplier of 4 MB SIMMs which are cheaper (per MB) than the 1 MB SIMMs! =============================================================================== From: FNAL::LEININGER "MARK LEININGER@FNALB.FNAL.GOV (708) 840-4776" 24-AUG-1990 12:12:25.33 To: RICHARDSON CC: NAGY,HERBER,THOMAS,LEININGER Subj: Upgrading SGI Personal Iris past 16M You have two options to upgrade the PI past 16M. Background: The PI has 16 memory slots. If you populate them all with 1M Simms, you go to 16M. If you populate them all with 2M Simms (only available from SGI) you got to 32M. If you populate them all with 4M Simms (only available from third party), you can go to 16M, 32M, 48M, or 64M. You can mix 1M Simms with 2M or 4M Simms to go to 24M or other combinations. Here's what to buy: SGI HU-C32B 32MB Memory upgrade $9100 (discounted price) This upgrade consists of sixteen, 2M byte boards. A 2M byte board is made of double high 1M bit chips. There are a total of 16 memory slots in a personal Iris. So, this 32M upgrade can be used to take one machine to 32M, or to take two machines to 16M. It can also be used to take a machine from 8M to 24M, but note that the 2M Simms must be in the first slots. The disadvantage of this upgrade is that it is not possible to purchase just a 16M upgrade. You must buy the whole 32M. The other disadvantage is that it limits you to 32M forever unless you through out boards. Southcoast Electronics SC94000/08 4MB Memory Upgrade $1652 This upgrade consists of a single 4M Simm made with 4M bit chips. By purchasing 8 of these modules, you could take a single machine to 32M for a total cost of $13,216. The advantage of these upgrades is that you can take the machine to 64M rather than just 32M because it uses 4M boards instead of 2M boards. Also, it is possible to purchase only what you need rather than having to buy the complete 32M upgrade kit. I would expect to see these 4M prices tumble in the near future. =============================================================================== From: FNAL::LEININGER "MARK LEININGER@FNALB.FNAL.GOV (708) 840-4776" 27-AUG-1990 15:20:18.55 To: NAGY,HERBER,THOMAS CC: LEININGER Subj: SGI upgrade memory, best price yet Here is the best price I've seen yet on SGI upgrade memory. It is 4Mbit chips at the same price as 1Mbit chips. Dataram Corp. 1100 Jorie Blvd. Suite 118 Oak Brook, IL 60521 4MB Memory Module for SGI Personal Iris 4D/20 Product Number #D/SIMM/4 Part #61906 $355/each So, for a 32M upgrade you need 8 boards for a cost of 8x355= $2840 as opposed to $9100 our price from SGI. =============================================================================== = Dr. Frank J. Nagy "VAX Guru & Wizard" = Fermilab Computing Division/Distributed Computing Dept/Special Projects Grp = HEPnet/SPAN: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = Internet: NAGY@FNALF.FNAL.GOV = USnail: Fermilab POB 500 MS/234 Batavia, IL 60510   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03244; 7 Sep 90 9:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02989; 7 Sep 90 8:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02987; 7 Sep 90 8:43 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa02238; 7 Sep 90 8:30 EDT Received: Fri, 7 Sep 90 08:30:43 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 7 Sep 90 08:30:43 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009071130.AA03690@aero4.larc.nasa.gov> To: root%itnsg1.cineca.it@cunyvm.cuny.edu Subject: Re: Name server problems Cc: info-iris@BRL.MIL One thing we do around here is have a couple of names and addresses reserved in the host table for demo machines. That way if we have a demo or evaluation unit, all we have to do is plug it into the network. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04276; 7 Sep 90 9:44 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03384; 7 Sep 90 9:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03285; 7 Sep 90 9:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02384; 7 Sep 90 9:02 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01048; Fri, 7 Sep 90 05:53:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 07:18:05 GMT From: Jeff Miller Organization: University of New Mexico, Albuquerque Subject: Non Volatile RAM checksum error!! Message-Id: <1990Sep7.071805.22982@ariel.unm.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have had this repetitive problem with my SGI 4d/20 system that I am rebuilding. Every time I try to boot, cold-start or reboot the system, I get the following sequence of events: (Actually, I usually get just the error message, with some or all of the other stuff. The following is what I always get after powerup) ---------------------------------------------------------------- Console DUART test PASSED Memory walking bit test PASSED Memory address uniqueness test PASSED Non-volatile RAM checksum is incorrect: Initializing the non-volatile RAM parameters. Interrupt mask registers test PASSED Graphics subsystem test PASSED Non-volatile RAM checksum is incorrect: Initializing the non-volatile RAM parameters. ---------------------------------------------------------------- I suspected that the problem might be a low lithium battery, but my DVM quickly cleared up that question. Besides, my clock keeps *perfect* time, even with the power off for 2-3 days (more, perhaps, but that is about as long as I care to leave it off 8-) I suppose that this could be a software problem, since I have not been able to find any information about how to initialize the NVRAM in the limitted number of manuals that I own. My problem is that the system keeps telling me that it is, "Initializing the non-volatile RAM parameters," and yet the system complains that the parameters have not been initialized. A friend said that the problem might be a bad NVRAM chip on the motherboard. Can someone tell me whether or not the NVRAM is really an EEPROM or just simply a battery-backed CMOS static RAM? Perhaps it is combined with the clock/calendar chip, as it is with some of Motorola's clock chips. (The clock chip in my system happens to be made by National Semiconductors --> DP8572AN <-- I have no spec sheet on it...) Any comments, solutions, remarks, etc. would be GREATLY appreciated! jcmiller@hydra.unm.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05096; 7 Sep 90 10:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa04763; 7 Sep 90 10:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa04659; 7 Sep 90 10:00 EDT Received: from prandtl.nas.nasa.gov by VGR.BRL.MIL id aa02627; 7 Sep 90 9:46 EDT Received: Fri, 7 Sep 90 06:46:29 -0700 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Fri, 7 Sep 90 09:47:20 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Fri, 7 Sep 90 10:00:25 EDT by avelon.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Fri, 7 Sep 90 10:00:25 EDT From: Tony Facca Message-Id: <9009071400.AA18091@avelon.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Name server problems Your problem is fixed in the 3.3 release of the software where you can tell the system to lookup names in the host table either before or after it attempts to use the nameserver to resolve. In the meantime, here is a short script which you can run as root to temporarily enable/disable the name resolver on your machine. Be careful that no one else is on when you run it because it brings the inetd (network services) down and then back up. Hope this helps. ------------------------- cut here for best results -------------------------- #! /bin/csh -f # nameserver turn the nameserver on or off and do all the other # network stuff that is required to support the change. # # Original Author: Tony Facca # Original Date: July 1989 # # Modified by Scott Presnell Thu Mar 1 08:41:59 PST 1990 # # 128.156.1.43 falcon.lerc.nasa.gov # 128.156.1.33 eagle.lerc.nasa.gov set primary = "128.156.1.43" # Internet address primary NS set secondary = "128.156.1.33" # secondary nameserver set domain = "lerc.nasa.gov" # domain name set CONFIG=/etc/config if (! -o /bin/su) then echo "You must be superuser to run this script" exit(-1) endif switch ($1) case "on": echo "on" > $CONFIG/named /bin/rm -f /usr/etc/resolv.conf echo "$0 : enabled -- restarting the network" /etc/init.d/network stop /etc/init.d/network start /etc/init.d/network.local start breaksw case "remote": if (-e /usr/etc/resolv.conf) then echo "Nameserver already in remote mode." exit() else echo "domain $domain" > /usr/etc/resolv.conf echo "nameserver $primary" >> /usr/etc/resolv.conf echo "nameserver $secondary" >> /usr/etc/resolv.conf echo "$0 : remote operation enabled -- restarting the network" echo "off" > $CONFIG/named /etc/init.d/network stop /etc/init.d/network start /etc/init.d/network.local start endif breaksw case "off": echo "$0 : disabled -- restarting the network" echo "off" > $CONFIG/named /bin/rm -f /usr/etc/resolv.conf /etc/init.d/network stop /etc/init.d/network start /etc/init.d/network.local start breaksw case "status": if ( `cat $CONFIG/named` == "on" ) then echo "$0 : named should be operating,\c" if ( ! { (kill -0 `cat /usr/etc/named.pid` > /dev/null) } ) then echo " but it isn't. Better check this out." else echo " and it is." endif else if ( -e /usr/etc/resolv.conf ) then echo "$0 : in remote operation mode." else if ( ! { (kill -0 `cat /usr/etc/named.pid` > /dev/null) } ) then echo "$0 : a named process is running, but named is not specified in the system configuration." else echo "$0 : all host name service through the /etc/hosts file." endif breaksw default: echo "Usage: $0 status|on|remote|off" breaksw endsw exit() ------------------------------------------------------------------------------ -- ----------------------------------------------------------------------------- Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 ----------------------------------------------------------------------------- You are at Witt's end. Passages lead off in *all* directions.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05733; 7 Sep 90 10:46 EDT Received: from vmb.brl.mil by VMB.brl.MIL id aa05415; 7 Sep 90 10:35 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05189; 7 Sep 90 10:22 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa02742; 7 Sep 90 10:14 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05271; Fri, 7 Sep 90 07:02:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 11:22:45 GMT From: Bruno Pape Organization: Silicon Graphics S.A., Zuerich, Switzerland Subject: 1.2GB SCSI Disks? Message-Id: <1990Sep7.112245.2982@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello and Thank you everyone, I am now somewhat more informed about SMD and IPI disks. The next question I have is, what will happen if I take a 1.2GB SCSI disk that we sell for the PI and put it in the twin tower for say a 320VGX in place of the normal 760MB SCSI? Will this work? What fun suprises may lay in store? Thanks again, Bruno   Received: from vmb.brl.mil by VMB.BRL.MIL id ab00094; 7 Sep 90 11:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab06838; 7 Sep 90 11:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06704; 7 Sep 90 11:08 EDT Received: from REMOTE.DCCS.UPENN.EDU by VGR.BRL.MIL id aa02979; 7 Sep 90 11:06 EDT Return-Path: Received: from C.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA01890; Fri, 7 Sep 90 11:05:59 -0400 Message-Id: <9009071505.AA01890@remote.dccs.upenn.edu> Date: Fri, 7 Sep 90 11:05 EST From: "Yates, John H." Subject: QMS QUIC Laser Printer support To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES Our 4D/320S does not have the Documenter's Workbench or the Laser Printer Support. I am about to buy it, but someone told me that it may only support Postscript printers. We have 3 QMS 800 (QUIC language) Laser printers. Does the Laser Printer Support include them as devices? Will it create DVI files that can be postprocessed with some other package available from the net? Thanks, John yates@c.chem.upenn.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01788; 7 Sep 90 12:27 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01023; 7 Sep 90 12:17 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00980; 7 Sep 90 12:07 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03259; 7 Sep 90 12:02 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12743; Fri, 7 Sep 90 08:56:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 15:27:26 GMT From: Kurt Akeley Organization: sgi Subject: Re: SGI's migration to X Message-Id: <1990Sep7.152726.24939@odin.corp.sgi.com> References: , <1990Sep6.010419.1573@odin.corp.sgi.com>, <1990Sep6.175301.18898@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.175301.18898@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> In article <1990Sep6.010419.1573@odin.corp.sgi.com> msc@sgi.com writes: |> > |> >Even if it's possible, we don't recommend doing it. Trying to image into |> >the same window using both X and the GL raises a bunch of nasty issues of |> >which one of the nastiest is synchronizing the drawing. Has the GL finished |> >drawing this polygon so I can have X draw this line? Who's on first so to |> >speak. Ugh!! |> > |> |> It would be really really really really nice if whatever X toolkit/UIMS/etc |> gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. |> That is to say, I want to learn *one* subroutine library for popups, |> pulldowns, radio knobs, other crap that can be used in both a GL window and an |> X window. This would seem like a good reason to have X requests and GL |> requests work together, rather than making a GL version of the same library. You'll be able to use the same X-based toolkit with both X and GL applications. Remember, the popups, pulldowns, radio knobs, and other crap all are created as subwindows, not as part of the current window. What you won't be able to do is to blend (or logicop, or z-buffer, or texture map) a popup, pulldown, radio knob, or other crap INTO a GL scene. -- kurt   Received: from vmb.brl.mil by VMB.BRL.MIL id aa02829; 7 Sep 90 13:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02442; 7 Sep 90 13:04 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02278; 7 Sep 90 12:52 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa03377; 7 Sep 90 12:43 EDT Received: from CDCCentr by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8212; Fri, 07 Sep 90 12:42:18 EDT Received: from DSC.DDS.CDCCentr.COM by CDCCentr (outbound name server) with BSMTP; 7 Sep 90 11:41:43 CDT Message-ID: <90090711354192B.ANGC@DSC.DDS.CDCCentr.COM> (UMass-Mailer 4.04) Date: Fri, 7 Sep 90 11:41:35 CDT From: LAKIS PRIFTIS GREATH Subject: ATVISTA image format to SGI image To: info-iris@BRL.MIL I have to convert images grabed by an ATVISTA in *.TGA or TIFF format to SGI image format. Is there any utility developed to make the conversion ? Thanks in advance Lazaros Lambrianidis   Received: from vmb.brl.mil by VMB.BRL.MIL id ac02829; 7 Sep 90 13:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab02442; 7 Sep 90 13:04 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab02278; 7 Sep 90 12:52 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa03379; 7 Sep 90 12:44 EDT Received: Fri, 7 Sep 90 12:45:04 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 7 Sep 90 12:45:04 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009071545.AA04557@aero4.larc.nasa.gov> To: YATES@c.chem.upenn.edu Subject: Re: QMS QUIC Laser Printer support Cc: info-iris@BRL.MIL I don't think there is any thing specific in eiter package for a QMS printer. However, if you already have software that creates files for a QMS printer, then you should not have any problems. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03682; 7 Sep 90 13:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab02829; 7 Sep 90 13:18 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02591; 7 Sep 90 13:04 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03428; 7 Sep 90 13:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16136; Fri, 7 Sep 90 09:46:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 16:05:47 GMT From: Todd Tenenholz Organization: University of Maryland Subject: Backup Scripts for Iris 4D Message-Id: <1990Sep7.160547.4540@murdoch.acc.Virginia.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know of a good utility script that can be used to automate multi- volume backups on Iris 4D stations? All of the ones I have seen use dump or will not figure out which portions of a filesystem will fit on one tape, so that tar can be used. The last time I checked with SGI about bru, the hotline told me that it basically was not going to work with my version of the operating system, (v3.14). I now have one machine running v3.2, but one is still on 3.14. I'm sorry for asking what is probably a common question, but I have looked elsewhere. Thanks in advance. Also: Are any versions of emacs available as share/free/low-cost/ ware? -- Todd Tenenholz, Molecular Graphics Facility, U. Md. at Batimore. Internet: todd@sg.ab.umd.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ab03682; 7 Sep 90 13:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac03108; 7 Sep 90 13:32 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03064; 7 Sep 90 13:26 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03484; 7 Sep 90 13:15 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17425; Fri, 7 Sep 90 10:06:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 13:41:19 GMT From: Jeff Hanson Organization: NASA/Lewis Research Center, Cleveland Subject: Re: GNU interface to NeWS (ps-emacs) problem... Message-Id: <1990Sep7.134119.22354@eagle.lerc.nasa.gov> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If all you want is emacs to start up its own window, modify the vinews software in ~4Dgifts/src. We've done this with no problems. P.S. Sorry to be wasting bandwidth but mail bounced twice. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* \ / \ / \ / \ / \ / \ / Jeff Hanson \ / \ / \ / \ / \ / \ / * ViSC: Better * tohanson@gonzo.lerc.nasa.gov * * * * * * / \ / \ Science / \ / \ NASA Lewis Research Center / \ / \ Through / \ / \ * * * * * * * Cleveland, Ohio 44135 * * * Pictures * * \ / \ / \ / \ Telephone - (216) 433-2284 Fax - (216) 433-2182 \ / \ / \ / *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04259; 7 Sep 90 14:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03108; 7 Sep 90 13:32 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02858; 7 Sep 90 13:16 EDT Received: from REMOTE.DCCS.UPENN.EDU by VGR.BRL.MIL id aa03477; 7 Sep 90 13:12 EDT Return-Path: Received: from C.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA03682; Fri, 7 Sep 90 13:12:01 -0400 Message-Id: <9009071712.AA03682@remote.dccs.upenn.edu> Date: Fri, 7 Sep 90 13:11 EST From: "Yates, John H." Subject: IRIX smongo available? To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES smongo is a plotting package some of our users use on suns. They tried some time ago to port it to SGI, but after a few hours gave up. Is the SGI tweaked version available out there somewhere? Thanks, John yates@c.chem.upenn.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ab04259; 7 Sep 90 14:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03942; 7 Sep 90 13:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03870; 7 Sep 90 13:51 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03688; 7 Sep 90 13:45 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19199; Fri, 7 Sep 90 10:33:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 15:44:14 GMT From: "Bernard J. Duffy" Organization: University of Maryland, Baltimore County Subject: Re: NCAR Graphics 3.0 Message-Id: <3877@umbc3.UMBC.EDU> References: <90249.232702RIE@psuvm.psu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <90249.232702RIE@psuvm.psu.edu> RIE@psuvm.psu.edu writes: >We wish to run NCAR Graphics version 3.0 on a Personal Iris. If you >have experience in compiling NCAR Graphics on an Iris, please let >me know the necessary modifications to be made -especially the >makefiles. Any suggestions/help will be highly appreciated. > Subhransu Roy > Penn State University > Email: s3r@ecl.psu.edu I've gone through several installation attempts with the NCAR 3.0 on the SGI platforms. First thing to know is that that software version was built on an IRIX 3.1 system. I was and still am running IRIX 3.2 on a SGI 4D/25 and SGI 4D/210 (headless). I didn't have any problems with the make if it didn't include the Athena utilities other than the make process was performed via a NFS src tree. That bombed out due to an NFS bug on Ultrix 3.? (highest prior to 4.0) where it would sometimes it wouldn't complete an operation. The make sequence stopped where there was a break in the connection due to an NFS I/O error. All you had to do is follow the directions which were documented in the manual(s), in one of the README files, and with the "Configure -v" (the first command) where you setup the "config" file. I haven't sucessfully built the NCAR GKS with the Athena utilities because of : 1) some problem with the include files : ... Making athena cc -DSYSV -O -I../../../include -c athena.c cpp: error /usr/include/bsd/sys/ioctl.h:9: Can't find include file net/soioctl.h cpp: error /usr/include/bsd/sys/ioctl.h:10: Can't find include file sys/ttychars .h *** Error code 1 Stop. ... *** this made me try a build with -I/usr/include/bsd in the CFLAGS makefile variable in config/SGI4D . I got a little farther, but that wasn't the solution : ... Making idt cc -DSYSV -I/usr/include/bsd -O -I../../include -c intermed.c ccom: Error: intermed.c, line 36: redeclaration of sprintf extern char *sprintf(); ----------------------------^ *** Error code 1 Stop. ... I still have a call into the NCAR folks on how to build this under 3.2 and I'm also curious how they might have handled 3.3 (which I still don't have). So, follow the directions for regular and X11 NCAR GKS 3.0 for IRIX 3.[12].* fyi, Bernie Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05716; 7 Sep 90 15:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab05601; 7 Sep 90 15:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05522; 7 Sep 90 15:28 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04125; 7 Sep 90 15:16 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24877; Fri, 7 Sep 90 12:04:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 18:13:23 GMT From: "Christopher J. Hawley" Organization: SGI Subject: Re: Opening console automatically? Message-Id: <1990Sep7.181323.27431@odin.corp.sgi.com> References: <5570@minyos.xx.rmit.oz> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <5570@minyos.xx.rmit.oz>, rxcob@minyos.xx.rmit.oz (Owen Baker) writes: |> Does anyone know if it is possible to open the console window |> automatically when a user first logs in? Our users keep |> forgetting and hence dont see any error messages. The default behaviour for Personal Iris consoles is to start iconified; this is controlled by the following line in /usr/NeWS/lib/startup.ps : /consoleStartsIconic /true def (This variable determines whether the option flag -Z7 is appended to the argument list for wsh when starting the console window.) So, if you want the console window open on login, change the above line to /consoleStartsIconic /false def Users who have their own customized of startup.ps will need to change their files as well if they want the same effects. |> Any help appreciated, thanks. You're welcome! --- Christopher J. Hawley / esper chawley@sundiver.esd.sgi.com Silicon Graphics, Inc. 1L-945 phone: 415 / 335-1621 Mountain View, CA 94039-7311 USA 408 / 243-1042 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Nicht nur wie schnell Sie fahren, sondern _wie_ Sie schnell fahren."   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05992; 7 Sep 90 16:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05601; 7 Sep 90 15:36 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab05455; 7 Sep 90 15:27 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04051; 7 Sep 90 15:01 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24328; Fri, 7 Sep 90 11:54:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 12:15:47 GMT From: Dhekne c/o NCST Organization: National Centre for Software Technology, Bombay, INDIA Subject: "debugger on IRIS 3130" Message-Id: <872@shakti.ncst.ernet.in> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello !! I have been trying to use the debugger on IRIS 3130, 'edge'. But I am unable to. Whenever I use it on non-graphics programs, it is OK, but for graphic programs, it starts behaving funny. Mainly, it just exits from the program or gets stuck. This is the case with 'dbx' also. However, I have found that it works in some cases - When you are using single buffer mode, and no popup menus. The moment you use either double buffer mode or popup menus, it starts giving problem. Actually it works till the point you have set the break point, and on reaching it, it exits. Has anybody faced such a problem ? Is there any solution ? We are looking at the possibilities of upgrading 3130 to 4d/20. Is the 4d/20 faster than 3130, or it is just a cheaper version of the higher 4d models ? Does it contain any geometric engines ? ( the technical details of 4d/20 do not say anything about them ). How do the users rate 4d/20 in comparison with 3130 ? (questions ! questions !!) suggestions ? help ? THANKS !! Sunil Kulkarni ( dhekne@shakti.ernet.in )   Received: from vmb.brl.mil by VMB.BRL.MIL id ab05992; 7 Sep 90 16:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab05716; 7 Sep 90 15:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05662; 7 Sep 90 15:40 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04214; 7 Sep 90 15:34 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26023; Fri, 7 Sep 90 12:20:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 19:07:03 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: ATVISTA image format to SGI image Message-Id: <68753@sgi.sgi.com> References: <90090711354192B.ANGC@DSC.DDS.CDCCentr.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL begin 777 fromtarga M`6``!R;9?4P````````````X``E``0GG([@)*8`!``$$("OA8"(`,(P(2>]_^BO MAH"`KZ``%```\"$,$!3'KX2`A`P0%"0`````#!`4*```("&/A("$CX6`B(^& M@(`,$`"```````P0%&0`0"`A````#0/@``@`````)[T`"`/@``@`(/@A`^`` M"``````````````````````GO?_H*($``Z^_`!00(``(KZ4`'#P$$``\!1`` M)*4```_@!%0DA`BT#!`49"0$``&/K@`<`````(W$``2-Q0`(#!``F``````, M$!1D```@(8^_`!0GO0`8`^``"``````GO?^0K[``**^_`$2OI0!TK[8`0*^T M`#BOM0`\`("`(:^R`#"OLP`TK[$`+`(`("$/X`1,)X6`$!1```D`0+`A/`00 M`#P%$``DI0`L)(0(M`_@!%0"`#`A#!`49"0$``$,$`%:`L`@(3!0`/\,$`%: M`L`@(0P0`5H"P"`A,$X`_R0!``(1P0`(`````#P$$``\!1``)*4`5`_@!%0D MA`BT#!`49"0$``$,$`%B`L`@(0P0`6("P"`A``*4```2E`,,$`%:`L`@(3!1 M`/\,$`%B`L`@(0P0`6("P"`A#!`!8@+`("&GH@!*#!`!8@+`("&GH@!,#!`! M6@+`("&CH@!.#!`!8@+`("$P50#_`!6I`C*U``,2```(``"8(0P0`5H"P"`A M)G,``0)P""L4(/_[````````F"$:0``G)`$`#Q(A``DD`0`0$B$`!R0!`!@2 M(0`')`$`(!(A``@`````$```"``````0```0`!(80``2&(`0```-`'(8(Q`` M``L`$AB`/`00`#P%$``DI0"$)(0(M`_@!%0"(#`A#!`49"0$``&/HP!8```` M``!@$"$00``))&/__P+`("$,$`%:KZ,`6(^C`%@``````&`0(11`__DD8___ MAZ\`2H>X`$R/I`!T)!D``Z^Y`!BOKP`0)X6`%"0&`0$D!P`##!`+3:^X`!04 M0``)`$"@(3P$$``\!1``CZ8`="2E`*@/X`14)(0(M`P0%&0D!``!AZ@`3``` M```9```F`````#P0$``\$1``/!(0`292CW`F,4]P)A`/<(>I`$J3J@!.KZD` M$`+`("$"`"@A`B`P(0)`."$,$`&*KZH`%`*`("$"`"@A`F`P(0``."$,$`FX MK[4`$`*`("$"("@A`F`P(20'``$,$`FXK[4`$`*`("$"0"@A`F`P(20'``(, M$`FXK[4`$(>K`$PFI`$H/X`1(`L`@(0P0"C0"@"`AC[\`1(^P M`"B/L0`LC[(`,(^S`#2/M``XC[4`/(^V`$`#X``()[T`<">]_^BOOP`4#^`$ M-`````"/OP`4)[T`&`/@``@`````)[W_X*^D`""OOP`4CZ0`(`_@!#0````` M``(<```#'`./I``@#^`$-*>C`!R'HP`<``)R``!N&"&/OP`4``,<```#'`,` M8!`A`^``"">]`"`GO?_@KZ0`(*^_`!2/I``@#^`$-````````AH```,<```# M'`./I``@#^`$-*>C`!R'HP`]_\"OM``@K[(`&*^S`!ROL0`4`,"((0#@F"$`H)`A`("@(1```&ROOP`D MK[``+(^P`%`\!!`!)(3/<"0%``$"@#@A#^`$6@`0,(`\`A`!`@`@(21"SW`0 M@``1)A#__Y!.```D0@`!IBX``)!/```D0@`!ID\``)!8``$D0@`!`@`@(28Q M``(F4@`")$(``29S``(F$/__%(#_\:9X__Z/L``L$```5X^_`"2OL``LC[`` M4#P$$`$`$#"`)(3/<"0%``$"@#@A#^`$6@#0,",\`A`!`@`@(21"SW`0@``0 M)A#__Y!9```D0@`!ICD``)!(```D0@`!ID@``)!)```"`"`A)C$``B92``(D M0@`!)G,``B80__\4@/_RIFG__H^P`"P0```WC[\`)*^P`"R/L`!0``````(` M("$0@``C)A#__PP0`78"@"`A``(<```#'`,``U*#,4L`'P`+8@`!BV`C)`$` M'P&!`!H``W%#,<\`'P`/P@`##\`C,&@`'P`(2@`!*$@C`@`@(292``(F,0`" M)G,``B80__\``&@2IDW__@`````#`0`:``#($J8Y__X``````2$`&@``4!*F M:O_^%(#_WP````"/L``L$```#(^_`"2/H@!4)`$`#Q!!_](D`0`0$$'_T"0! M`!@00?^N)`$`(!!!_XP`````C[\`)(^Q`!2/L@`8C[,`'(^T`"`#X``()[T` M0">]_^"OL0`8K[``%`"`@"$\$1``K[\`'"8Q"+22!@``/`40`"2E`,P/X`14 M`B`@(3P%$`"2!@`!)*4`V`_@!%0"("`A/`40`)(&``(DI0#D#^`$5`(@("$\ M!1``A@8`!(8'``8DI0#P#^`$5`(@("$\!1``D@8`""2E`0@/X`14`B`@(88& M``H\!1``)*4!%`(@("$/X`14`,`X(3P%$`"&!@`.A@<`$"2E`2@/X`14`B`@ M(3P%$`"2!@`2)*4!/`_@!%0"("`A/`40`)(&`!,DI0%(#^`$5`(@("&/OP`< MC[``%(^Q`!@#X``()[T`(````````````````">]_^BOOP`4`*`8(0_@!!`` M`RA`C[\`%">]`!@#X``(`````">]_^BOOP`4`,`8(0_@!`P``S!`C[\`%">] M`!@#X``(`````">]_^@4H``%K[\`%`P0`E``P"@A$```&8^_`!0HP0`(%"`` M#@#`$"&DA0``I(4``J2%``2DA0`&),;_^*2%``@HP0`(I(4`"J2%``RDA0`. M$"#_]22$`!``P!`A$$``!B3&__\`P!`A),;__Z2%```40/_\)(0``H^_`!0G MO0`8`^``"``````HP0`(%"``;P#`$"&$@@````````1!``0H00$`$```"*2@ M```H00$`%"``!`!`&"$0```")`,`_P!`&"&DHP``A((``@`````$00`$*$$! M`!````BDH``"*$$!`!0@``0`0!@A$````B0#`/\`0!@AI*,``H2"``0````` M!$$`!"A!`0`0```(I*``!"A!`0`4(``$`$`8(1````(D`P#_`$`8(:2C``2$ M@@`&``````1!``0H00$`$```"*2@``8H00$`%"``!`!`&"$0```")`,`_P!` M&"&DHP`&A((`"``````$00`$*$$!`!````BDH``(*$$!`!0@``0`0!@A$``` M`B0#`/\`0!@AI*,`"(2"``H`````!$$`!"A!`0`0```(I*``"BA!`0`4(``$ M`$`8(1````(D`P#_`$`8(:2C``J$@@`,``````1!``0H00$`$```"*2@``PH M00$`%"``!`!`&"$0```")`,`_P!`&"&DHP`,A((`#@`````$00`$*$$!`!`` M``BDH``.*$$!`!0@``0`0!@A$````B0#`/\`0!@AI*,`#B3&__@HP0`()(0` M$!`@_Y0DI0`0`,`0(1!``!,DQO__A((````````$00`$*$$!`!````BDH``` M*$$!`!0@``0`0!@A$````B0#`/\`0!@AI*,```#`$"$DA``")*4``A1`_^\D MQO__`^``"``````GO?_H)`$``13!``6OOP`4#!`%3@#@,"$0``!1C[\`%"0! M__\4P0`&*.$`"`P0!80`X#`A$```2H^_`!0HX0`(%"``.0#@$"&$KP``A(X` M``#/`!F$B``"A(P`!"3G__@HX0`()(0`$"2E`!```,`2`=C((:29__"$J?_R MA)C_]@#)`!D``%`2`0I8(:2+__*$K?_TA(K_^`#-`!D``'@2`8]P(:2.__2$ MN?_VA(__^@#9`!D``$@2`PE`(:2(__:$J__XA(G__`#+`!D``&@2`4U@(:2, M__B$KO_ZA(W__@#.`!D``,@2`?G`(:28__J$J/_\``````#(`!D``%@2`2M0 M(:2*__R$K/_^``````#,`!D``'`2`:YX(1`@_\JDC__^`.`0(1!```PDY___ MA+@``(29````V``9`.`0(23G__\DI0`")(0``@``0!(#*$@A%$#_]J2)__Z/ MOP`4)[T`&`/@``@`````%(4`BRCA``@4(`!S`.`0(82N``"$N``"`<8`&H2H M``2$J@`&A*P`"!3```(```````<`#20!__\4P0`$/`&``!7!``(```````8` M#82N``H4P``"```````'``TD`?__%,$`!#P!@``7`0`"```````&``T``'@2 MI*\``!3```(```````<`#20!__\4P0`$/`&``!4!``(```````8`#0,&`!J$ MN``,%,```@``````!P`-)`'__Q3!``0\`8``%4$``@``````!@`-).?_^!3` M``(```````<`#20!__\4P0`$/`&``!6!``(```````8`#0``R!*DN0`"%,`` M`@``````!P`-)`'__Q3!``0\`8``%<$``@``````!@`-`08`&H2H``X4P``" M```````'``TD`?__%,$`!#P!@``7`0`"```````&``TDI0`0%,```@`````` M!P`-)`'__Q3!``0\`8``%0$``@``````!@`-``!($J2I__0HX0`(`48`&@`` M6!*DJ__V``````&&`!H``&@2I*W_^``````!Q@`:``!X$J2O__H``````P8` M&@``R!*DN?_\``````$&`!H``$@2I*G__A`@_Y```````.`0(1!``*,DY___ MA*H```#@$"$!1@`:)*4``A3```(```````<`#20!__\4P0`$/`&``!5!``(` M``````8`#23G__\``%@2I*O__A1`_^\``````^``"``````HX0`(%"``=P#@ M$"&$C```).?_^`&&`!HDI0`0%,```@``````!P`-)`'__Q3!``0\`8``%8$` M`@``````!@`-)(0`$```:!*DK?_PA([_\@`````!Q@`:%,```@``````!P`- M)`'__Q3!``0\`8``%<$``@``````!@`-``!X$J2O__*$F/_T``````,&`!H4 MP``"```````'``TD`?__%,$`!#P!@``7`0`"```````&``T``,@2I+G_](2( M__8``````08`&A3```(```````<`#20!__\4P0`$/`&``!4!``(```````8` M#0``2!*DJ?_VA(K_^``````!1@`:%,```@``````!P`-)`'__Q3!``0\`8`` M%4$``@``````!@`-``!8$J2K__B$C/_Z``````&&`!H4P``"```````'``TD M`?__%,$`!#P!@``5@0`"```````&``T``&@2I*W_^H2.__P``````<8`&A3` M``(```````<`#20!__\4P0`$/`&``!7!``(```````8`#0``>!*DK__\A)C_ M_@`````#!@`:%,```@``````!P`-)`'__Q3!``0\`8``%P$``@``````!@`- M*.$`"```R!*DN?_^$"#_C```````X!`A$$``%"3G__^$B````.`0(0$&`!HD MY___%,```@``````!P`-)`'__Q3!``0\`8``%0$``@``````!@`-)(0``B2E M``(``$@2I*G__A1`_^X``````^``"`````"/HP`0`````"AA``@4(`"I`&`0 M(92X``"4C@``E,D````8R(`#.,@A``YX@``9R,`![G@A``E0@``/>0`#.,@C M`4E0(0`*4(``&YX(P'Y0"$!25`A`0I8(0`+8@*D[```E+@``I2-``*4 MR0`"`!AX@`'X>"$`#7"```]XP`'-<"$`"4"```YQ``'X>",!"4`A``A`@``/ M>(`!S7`C`<_((0$)0"$#*%`A``I:`J3K``*4N``$E(P`!)3)``0`&'"``=AP M(0`,:(``#G#``:QH(0`)R(``#6D``=AP(P,IR"$`&EX(0`/>(``#6B``8M@(P&-<"$!Z7@A`<_((0`9 M0@*DZ``&E+@`")2*``B4R0`(`!A@@`&88"$`"EB```Q@P`%J6"$`"7"```M9 M``&88",!R7`A``YP@``,8(`!:E@C`6QH(0')<"$!KG@A``_*`J3Y``B4N``* ME(@`"I3)``H`&%B``7A8(0`(4(``"UC``4A0(0`):(``"E$``7A8(P&I:"$` M#6B```M8@`%(4",!2V`A`:EH(0&-<"$`#GH"I.\`"I2X``R4F0`,E,D`#``8 M4(`!6%`A`!E`@``*4,`!&4`A``E@@``(00`!6%`C`8E@(0`,8(``"E"``1E` M(P$*6"$!B6`A`6QH(0`-<@*D[@`,E+@`#I2/``Z4R0`.`!A`@`$80"$`#\B` M``A`P`,OR"$`"5B``!G)``$80",!:5@A``M8@``(0(`#+\@C`RA0(0%I6"$! M2V`A)&/_^``,:@(H80`(I.T`#B2$`!`DI0`0),8`$!`@_UHDYP`0`&`0(1!` M`!PD8___E+@``)2.``"4R0```!C(@`,XR"$`#GB``!G(P`'N>"$`"5"```]Y M``,XR",!25`A``I0@``9R(`![G@C`?E`(0%)4"$!"E@A``MB`@!@$"&D[``` M)(0``B2E``(DQ@`").<``A1`_^8D8___`^``"``````HP0`(%"``)P#`$"&$ MC@``A*\``(29``(!S\`AI)@``(2H``*$B@`$`RA((:2)``*$JP`$A(T`!@%+ M8"&DC``$A*X`!H28``@!KG@AI(\`!H2Y``B$B0`*`QE`(:2(``B$J@`*A(P` M#`$J6"&DBP`*A*T`#(2/``X!C7`AI(X`#(2X``XDQO_X*,$`"`'XR"&DF0`. M)(0`$!`@_]PDI0`0`,`0(1!```HDQO__A(@``(2I````P!`A`0E0(:2*```D MQO__)*4``A1`__@DA``"`^``"``````HP0`(%"``)P#`$"&$C@``A*\``(29 M``(!S\`CI)@``(2H``*$B@`$`RA((Z2)``*$JP`$A(T`!@%+8".DC``$A*X` M!H28``@!KG@CI(\`!H2Y``B$B0`*`QE`(Z2(``B$J@`*A(P`#`$J6".DBP`* MA*T`#(2/``X!C7`CI(X`#(2X``XDQO_X*,$`"`'XR".DF0`.)(0`$!`@_]PD MI0`0`,`0(1!```HDQO__A(@``(2I````P!`A`0E0(Z2*```DQO__)*4``A1` M__@DA``"`^``"``````DPO__!$$``@!`""$D(0`'``$0PR1"``$`@#@A&$`` M.```&"$D!@#_D.0``"3G``$PC@"`$<```P`````0```"I*```*2F```PCP!` M$>```P`````0```"I*```J2F``(PF``@$P```P`````0```"I*``!*2F``0P MF0`0$R```P`````0```"I*``!J2F``8PB``($0```P`````0```"I*``"*2F M``@PB0`$$2```P`````0```"I*``"J2F``HPB@`"$4```P`````0```"I*`` M#*2F``PPBP`!$6```P`````0```"I*``#J2F``XD8P`!`&((*A0@_\LDI0`0 M`^``"``````DPO__!$$``@!`""$D(0`'``$0PR1"``$`@#@A&$``-P``&"&$ M[@`````@(2G!`(`0(``"`````"0$`("$[P`"`````"GA`(`0(``"`````#2$ M`$"$^``$`````"L!`(`0(``"`````#2$`""$^0`&`````"LA`(`0(``"```` M`#2$`!"$Z``(`````"D!`(`0(``"`````#2$``B$Z0`*`````"DA`(`0(``" M`````#2$``2$Z@`,`````"E!`(`0(``"`````#2$``*$ZP`.`````"EA`(`0 M(``"`````#2$``$D8P`!`&((*B3G`!"@I```%"#_RR2E``$#X``(`````(^( M@'`GO?_HK[\`%`"`."$5```;`*!0(:^G`!@D!`$`#^`$@J^J`!R/IP`8CZH` M'`!`0"$``"@A`$!((20&``@D"P$````@(0``&"$D#@`!`&YX!`"OP"03```" M``0@0#2$``$D8P`!%&;_^20.``$DI0`!H20``!2K__(E*0`!*4$`"!0@`"8! M0!`AD/D``)#N``$!&6`AD8T```$.>"&@[0``D?@``)#Y``*@^``!`1E@(9&- M``"0[@`#H.T``@$.>"&1^```D/D`!*#X``,!&6`AD8T``)#N``6@[0`$`0YX M(9'X``"0^0`&H/@`!0$98"&1C0``D.X`!Z#M``8!#G@AD?@``"5*__@I00`( M).<`"!`@_]V@^/__`4`0(11```,E2O__$```"J^(@'"0^0```4`0(0$98"&1 MC0``).<``25*__\40/_YH.W__Z^(@'"/OP`4)[T`&`/@``@```````5P0`2A M``(`H`@A)"$``0`!*$,`CA@A`*`P(0"`$"$D8__^$,``"B2E__^$1```A&\` M``"@,"&D3P``)$(``B1C__XDI?__%,#_^*1D``(#X``(`````"C!``@0(``% M/`,``3P#``$0```P-&,!`3P#``$T8P$!E(X``"3&__@!PP`9*,$`""2E`"`D MA``0``!X$JRO_^"4F/_R``````,#`!D``,@2K+G_Y)2(__0``````0,`&0`` M2!*LJ?_HE(K_]@`````!0P`9``!8$JRK_^R4C/_X``````&#`!D``&@2K*W_ M\)2.__H``````<,`&0``>!*LK__TE)C__``````#`P`9``#($JRY__B4B/_^ M``````$#`!D``$@2K*G__!`@_]0``````,`0(1!```LDQO__E(H```#`$"$! M0P`9),;__R2$``(DI0`$``!8$JRK__P40/_W``````/@``@`````CZ,`$``` M```H80`(%"``20!@$"&4KP``E(X``)3(````#\(``=C()0`(3``#*5`EK.H` M`)2L``*4S@`"E(L``@`,:@``#L0``6UX)0'X0"6LZ``$E*D`!)3+``24F0`$ M``E2```+;``#*F`E`8UP):SN``B4N``&E-D`!I2/``8`&$(``!E4``'H2"4! M*E@EK.L`#)2M``B4SP`(E(P`"``-<@``#T0``8[`)0,(R"6L^0`0E*H`"I3, M``J4B0`*``I:```,=``!*V@E`:YX):SO`!24J``,E,D`#)28``P`",H```E< M``,94"4!2V`EK.P`&)2N``Z4V``.E(T`#@`.>@`D8__X`!C,``&O0"4!&4@E M*&$`"*SI`!PDYP`@)(0`$"2E`!`0(/^Z),8`$`!@$"$00``0)&/__Y2K``"4 MB@``E,T````+8@`!3'`E``U\``'/P"4`8!`A)&/__ZSX```DQ@`")*4``B2$ M``(40/_R).<`!`/@``@`````CZ,`%``````H80`($"``!8^B`!"/H@`0$``` M9`!@0"&/H@`0`````)2O``"4C@``E,D``)3L````#\(``=C()0`)5``#*E@E M``QN``%M>"6L3P``E+@``I3*``*4C@`"E.T``@`82@``"F0``$@EK$D`")2J``:4S0`&E(X`!I3X``8`"F(```U\``',R"4#+U@E`!A. M``%I4"6L2@`,E*P`")3/``B4C@`(E.D`"``,:@``#\0``"6L3P`8E+@`#I3*``Z4C@`.E.T`#@`82@``"F0``@(Q^`#_I*X````"S`(S M*@#_I-@````"7@(Q;`#_I.H``*4,``",@@`$*&$`"#!-`/\``G(",<\`_Z2M M``(``L0",QD`_Z3/``(``E8",4L`_Z3Y``*E"P`"C((`""2$`"`P3`#_``)J M`C&N`/^DK``$``)\`C'X`/^DS@`$``+.`C,J`/^D^``$I0H`!(R"_^PDI0`0 M,$L`_P`"8@(QC0#_I*O_]@`"=`(QSP#_I,T`!@`"Q@(S&0#_I.\`!J49``:, M@O_P),8`$#!*`/\``EH",6P`_Z2J__@``FP",:X`_Z3,__@``GX",?@`_Z3N M``BE&``(C(+_]"3G`!`P60#_``)2`C%+`/^DN?_Z``)D`C&-`/^DR__Z``)V M`C'/`/^D[?_ZI0\`"HR"__@E"``0,%@`_P`"R@(S*@#_I+C__``"7`(Q;`#_ MI,K__``";@(QK@#_I.S__*4.__R,@O_\`````#!/`/\``L(",QD`_Z2O__X` M`E0",4L`_Z39__X``F8",8T`_Z3K__X0(/^8I0W__@!@2"$1(``5)&/__XR" M````8$@A,$X`_P`">@(Q^`#_I*X````"S`(S*@#_I-@````"7@(Q;`#_I.H` M`*4,```DA``$)*4``B3&``(DYP`")0@``A4@_^TD8___`^``"`````",@P`0 ME((`!B0!`/\080"<`````!!@`)HH00`(%"``@@!`("&$K@``A+D``@`.>@`! M[G@C`>,`&@`90@`!&4`CA*H`!(2M``8`"EH``6I8(P`-<@`!S7`C%&```@`` M````!P`-)`'__Q1A``0\`8``%>$``@``````!@`-)$+_^!1@``(```````<` M#20!__\480`$/`&``!4!``(```````8`#0``P!*DN```A+@`"`$#`!H`&,H` M`SC((Q1@``(```````<`#20!__\480`$/`&``!5A``(```````8`#22E`!`4 M8``"```````'``TD`?__%&$`!#P!@``5P0`"```````&``T``$@2I*G_\H2I M__H!8P`:``E2``%)4",48``"```````'``TD`?__%&$`!#P!@``7(0`"```` M```&``T48``"```````'``TD`?__%&$`!#P!@``500`"```````&``T``&`2 MI*S_](2L__P!PP`:``QJ``&L:",48``"```````'``TD`?__%&$`!#P!@``5 MH0`"```````&``T``'@2I*__]H2O__X#(P`:``_"``,/P",48``"```````' M``TD`?__%&$`!#P!@``7`0`"```````&``TH00`(``!`$J2H__@``````4,` M&@``6!*DJ__Z``````&C`!H``'`2I*[__``````#`P`:``#($J2Y__X0(/^! M``````!`("$0@``5)$+__X2H````0"`A``A*``$H2",!(P`:)*4``A1@``(` M``````<`#20!__\480`$/`&``!4A``(```````8`#21"__\``%`2I*K__A2` M_^T``````^``"``````GO?_8K[``(`"`@"&OOP`DKZ4`+*^F`#"/@X`@E@(` M!@``````8@@K$"``'``````08``,`````(^$@'0/X`2``````(^$@'@/X`2` M`````(^$@'P/X`2``````)8"``8`````#^`$@@`"($"O@H!TE@0`!@_@!((` M!"!`KX*`>)8$``8/X`2"``0@0*^"@'R6`P`&`````*^#@""6#@`*`````"W! M``,0(``(`````(^E`"R/I@`P`@`@(0P0$WT``#@A$```&(^_`"2/A8!TCZ8` M,`(`("$,$!-]```X(8^%@'B/I@`P`@`@(0P0$WTD!P`!CX6`?(^F`#`"`"`A M#!`3?20'``*6#P`&CX2`=(^%@'B/AH!\CZ<`+`P0!(*OKP`0C[\`)(^P`"`# MX``()[T`*">]_^B/K@`HK[\`%#'/``$`@!@A`*!`(1'@``T`P$@AE&4`!J^I M`""OJ``/OP`4CZD` M&(^D`!R5)0`&#!`&E@````"/OP`4)[T`&`/@``@``````,`0(1!``"LDQO__ M/`D0`"4I`6`D"`#_A((``"0!`/\``CF``.(X(0#A`!H``#@2*.$`0!0@``0` MX!@AI(@``!```!DDA``"!*$`!#"N``<1P``"`````"7.__@`#GD`!,$`!##9 M``<3(``"`````"``!0````".!`"4CZ4`)`P0#2X`````C@4`E(^F M`"0,$`X'`@`@(8X$`(``````$(```P`````/X`2``````(X$`(0`````$(`` M`P`````/X`2``````)88``(D`0$`,QG_`!OI``8CZ0`&`````"L@@"`A(8`=I29``@``````-D(*Q0@ M`!(`````A((`>)2(``HD0@`!``(4```"%`,`2`@KI(``=A0@``>D@@!XE(D` M<*2``'@U*@`0I(H``P0$WVOI``8 MCZ0`&`````"4BP`&A(T`=HR#`(`E;/__):X``:2,`'JDC@!VK(,`?)1B```D M;P`"K(\`?#!"__^/OP`4)[T`&`/@``@`````)[W_Z*^_`!2OI0````P`````0```\)`+__XR%`(``````%*``"``````,$`T'KZ0` M&(^D`!@`````K((`@(R%`(``````C)@`?``````3```@`````(2&`':$AP!X M#!`25Z^D`!B/I``8`````(2"`':4F0`()$(``0`"%````A0#`%D(*Q0@`!"D M@@!VA((`>)2(``HD0@`!``(4```"%`,`2`@KI(``=A0@``>D@@!XE(D`<*2` M`'@U*@`0I(H`]`!@#X``( M`````">]_^BOOP`4`(`8(21D`!@/X`3()`8`4(^_`!0GO0`8`^``"``````# MX``(K(4`:">]_]BOI0`LKZ8`,*^D`"BOOP`DCZX`.(^O`#R/N`!``.`8(:^C M`!"/IP`PCZ4`*(^F`"ROK@`4KZ\`&```("$,$`MWK[@`'(^_`"0GO0`H`^`` M"``````GO?_8KZ8`,*^E`"ROOP`DCZX`.(^O`#R/N`!``.`8(:^C`!"/IP`P MCZ8`+*^N`!2OKP`8```H(0P0"W>ON``]`"@#X``(`````">]_]"O MOP`[_`!7!`)P`````EA@`")89``H` M`````QD`&0``$!(``A"``$`@(0_@!(*OH@`DK@(`D(^D`"0/X`2"`````(X( M`)"N`@"4$0``!0````"."0"4`````!4@``F/J@`D/`00`#P%$``DI0*@#^`$ M5"2$"+0,$!1D)`0``8^J`"0D`0!W``I80"5L`@"N#`",CZT`.`````"1KP`` M`````!7A`$*/I``PE@X`")88``H``"@A`=@`&0``,!(8P`!N`````###``,4 M8``$``40@!````\D!/__``40@"0$__^.&0"0)*4``0,B0"&M````C@D`E``` M```!(E`AK40``!1E__"&MY```C@X`D``````!PL`AKP``!(X9`)0````` M`R)`(:T$``2."0"0``````$B4"&M0``(C@L`E``````!8F`AK80`"(X-`)`` M`````:)X(:W@``R.#@"4``````'"P"$D0@`0%$/_WZ\$``P0```VI@``>H^D M`#`D!0(`#!`4F```,"&/I``PC@4`D(^F`"0,$!20`````(^Y`"0`````$%D` M"``````\!!``/`40`"2E`L`/X`14)(0(M`P0%&0D!``!A@@`<@`````1```& MCZ0`,(X$`)"/I0`D#!`-+@````"/I``PC@4`E(^F`"0,$!20`````(^I`"0` M````$$D`"``````\!!``/`40`"2E`N0/X`14)(0(M`P0%&0D!``!A@H`<@`` M```10``%`````(X$`)2/I0`D#!`-+@````"F``!ZK@``?*X``(`,$`T'`@`@ M(8^D`#"N`@"$I@``=*8``'8D"P(`I@``>*X+`(@D!0(````P(0P0%)BN!`!L M`@`0(8^_`!R/L``8`^``"">]`#`GO?_@K[\`%`"`&"&48@`&```````"<8(` M3B`A#^`$@@`$((`40``(KZ(`'#P$$``\!1``)*4#"`_@!%0DA`BT#!`49"0$ M``&/OP`4CZ(`'`/@``@GO0`@``400P"`,"$80``,```8(93$```D8P`!``,< M```#'`,`!'("``1Z``'/P"4`8@@JI-@``!0@__8DQ@`"`^``"```````!1"# M`(`P(1A``!0``!@A/`<`_P`#<(``SB@AC*0``"1C``$`!,(",QG_```$?@(` M!$H``2=0)`'Y0"4``QP``0I8)0`#'`,`!&8``6QH)0!B""H4(/_OK*T```/@ M``@`````)[W_Z*^D`!BOOP`4CZ0`&`P0#1TD!0`,CZ0`&"0%``P,$`TN)(0` M#(^D`!@D!0`$#!`-+B2$`&B/OP`4)[T`&`/@``@`````)[W_X*^_`!2OI0`D MKZ8`*`P0"TTGA8`X%$``#`!`&"$\!!``/`40`"2E`RPDA`BT#^`$5*^C`!R/ MHP`<#!`49"0$``&/HP`<`````)1N``:/KP`D`````*WN``"/N0`HE'@`"``` M``"O.```C[\`%">]`"`#X``(`````">]_^BOOP`4A((`>@`````D0O__``(4 M```"%`,$0``'I((`>HR#`'P`````E&(``"1N``(0```#K(X`?`P0"KD````` MC[\`%">]`!@#X``(`````">]_^BOOP`4A((`>@`````D0O__``(4```"%`,$ M0``)I((`>HR.`'PPHO__I<4``(R/`'P`````)?@``A````.LF`!\#!`*^``` M``"/OP`4)[T`&`/@``@`````)[W_Z*^_`!0`H#@AKZ<`'*^D`!@`X"@A#!`- MY:^F`""/I``8CZ8`((^G`!R4@P`"I(``=#!B_P"DA@!X%$``%Z2'`':4@@`& ME(\`"`#"`!DP:0#_``!P$@```````````<\`&0``P!(```````````#B`!D` M`,@2`SA`(0`````!"0`9```H$B2E`@`,$`Y#`````!```!B/OP`4)`$!`!1! M``T`````E(L`"(R*`)``RP`9``!@$@#L:"$`#7"``4YX(8WE```,$`Y#```` M`!````F/OP`4/`00`#P%$``DI0-4#^`$5"2$"+0,$!1D)`0``8^_`!0GO0`8 M`^``"``````GO?_HK[\`%`"`&"&4;@`(`*!`(0$.""L0(``&`,`X(91O``H` M`````.\(*Q0@`!./OP`4/`00`#P%$``DI0-P)(0(M`$`,"$/X`14KZ,`&(^C M`!@\!!``/`40`)1F``B49P`*)*4#F`_@!%0DA`BT#!`49"0$``&/OP`4)[T` M&`/@``@`````)[W_X*^D`""/K@`@KZ8`**^_`!2/I@`HC<0`;`P0%(@````` MCZ\`**^B`!P03P`)CZ,`(#P$$``\!1``)*4#K`_@!%0DA`BT#!`49"0$``&/ MHP`@C[D`*(QX`(@``````QE`(:QH`(B/OP`4CZ(`'`/@``@GO0`@)[W_X*^D M`""/K@`@KZ8`**^_`!2/I@`HC<0`;`P0%)``````CZ\`**^B`!P03P`)CZ,` M(#P$$``\!1``)*4#R`_@!%0DA`BT#!`49"0$``&/HP`@C[D`*(QX`(@````` M`QE`(:QH`(B/OP`4CZ(`'`/@``@GO0`@)[W_Z*^_`!0`@!@AC&X`B``````0 MK@`2C[\`%*QE`(B,9`!LKZ4`'`P0%)@``#`A!$$`"8^E`!P\!!``/`40`"2E M`^`/X`14)(0(M`P0%&0D!``!CZ4`'`````"/OP`4)[T`&`/@``@`H!`A)[W_ MX*^_`!24CP`(A(X`>(2'`'8!SP`9C(D`E```P!(`^,@A`!E`@`$H4"&-1@`` M``````3!``V/OP`4/`00`#P%$``DI0/X)(0(M`_@!%2OI@`6OI``8CZ0`&(^N`"24CP`(C[D`(`'/`!F,B@"0C(@` ME(R)`(R/I@`<)`'__P``P!(#.!`A``(0@`%"6"$!`A@AK6D``(QE```````` M$*$`!0````",C``4``````&%:"&LC0`4K&8``(R.`(P``````<9X(:R/`(R/ MOP`4)[T`&`/@``@`````)[W_Z`"@&"$D`@`!K[\`%!1B`(<`P$@A%.(`A0`` M``"/K@`H`(`X(0".0"$`B`@K$"``>P$@*"$`X"`A).<``@#H""L0(``7```` M`)#B__^0[__^`````!1/``4`````D/@````````3`@`.`````"3G``$`Z`@K M$"``"@````"0XO__D/G__@`````46?_X`````)#J````````%4+_]``````D MY__^`.00(Q!``#8`0#`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`S1K M`(`H80`)H*L```##,",4(``9)*4``9",```D8__XH*P``)"-``$``QP`H*T` M`9".``(``QP#H*X``I"/``,H80`)H*\``Y"8``0DI0`(H+C__)"9``4DA``( MH+G__9"*__X`````H*K__I"+__\0(/_IH*O__P!@$"$D8___``,<`!!```H` M`QP#`&`0(9",```D8___``,<```#'`,DA``!)*4``11`__B@K/__%,#_S2C! M`'\`X"`A).<``0#H""N0X___$"``#@#D$".0[0```&`0(11-``D`````).<` M`0#H""L0(``%`````)#N````````$$[_^0``````Y!`C$$``#P!`,"$`8!`A M*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,<`P##,".@HP``)*4``22E``$4 MP/_TH*+__P#H""L4(/^(`.`@(22E``&@H/__$``!O@"I$",08@`$)`4``A`` M`(PD!0`")`4``A3E`(D`````CZ\`*`"`."$`CT`A`(@(*Q`@`'L!("@A`.`@ M(23G``(`Z`@K$"``%P````"0XO__D/C__@`````46``%`````)#Y```````` M$R(`#@`````DYP`!`.@(*Q`@``H`````D.+__Y#J__X`````%$K_^`````"0 MZP```````!5B__0`````).?__@#D$",00``V`$`P(2C!`'\4(``$``8<`!`` M``,D`P!^``8<```#'`,T;`"`*&$`":2L````PS`C%"``&22E``*0C0``)&/_ M^*2M``"0C@`!``,<`*2N``*0CP`"``,<`Z2O``20F``#*&$`":2X``:0F0`$ M)*4`$*2Y__B0B@`%)(0`"*2J__J0B__^`````*2K__R0C/__$"#_Z:2L__X` M8!`A)&/__P`#'``00``*``,<`P!@$"&0C0``)&/__P`#'````QP#)(0``22E M``(40/_XI*W__A3`_\THP0!_`.`@(23G``$`Z`@KD./__Q`@``X`Y!`CD.X` M``!@$"$43@`)`````"3G``$`Z`@K$"``!0````"0[P```````!!/__D````` M`.00(Q!```\`0#`A`&`0(2C!`'\4(``$``8<`!````,D`P!^``8<```#'`,` MPS`CI*,``"2E``(DI0`"%,#_]*2B__X`Z`@K%"#_B`#@("$DI0`"`*D0(P1! M``(`0`@A)"$``0`!$$,0``$OI*#__A1E`)``````%.(`C@````"/N``H`(`X M(0`8R$``F4`A`(@(*Q`@`(,!("@A`.`@(23G``0`Z`@K$"``%P````"4XO_^ ME.K__``````42@`%`````)3K````````$6(`#@`````DYP`"`.@(*Q`@``H` M````E.+__I3L__P`````%$S_^`````"4[0```````!6B__0`````).?__`#D M$",$00`"`$`((20A``$``1!#$$``-@!`,"$HP0!_%"``!``&'``0```#)`,` M?@`&'````QP#-&X`@"AA``F@K@```,,P(Q0@`!DDI0`!E(\``"1C__B@KP`` ME)@``@`#'`"@N``!E)D`!``#'`.@N0`"E(H`!BAA``F@J@`#E(L`""2E``B@ MJ__\E(P`"B2$`!"@K/_]E(W__`````"@K?_^E([__A`@_^F@KO__`&`0(21C M__\``QP`$$``"@`#'`,`8!`AE(\``"1C__\``QP```,<`R2$``(DI0`!%$#_ M^*"O__\4P/_-*,$`?P#@("$DYP`"`.@(*X3C__X0(``.`.00(Y3X````8!`A M%%@`"0`````DYP`"`.@(*Q`@``4`````E/D````````06?_Y``````#D$",$ M00`"`$`((20A``$``1!#$$``#P!`,"$`8!`A*,$`?Q0@``0`!AP`$````R0# M`'X`!AP```,<`P##,".@HP``)*4``22E``$4P/_TH*+__P#H""L4(/^``.`@ M(22E``&@H/__$```G@"I$",490"4`````!3E`)(`````CZH`*`"`."$`"EA` M`(M`(0"(""L0(`"#`2`H(0#@("$DYP`$`.@(*Q`@`!<`````E.+__I3L__P` M````%$P`!0````"4[0```````!&B``X`````).<``@#H""L0(``*`````)3B M__Z4[O_\`````!1.__@`````E.\````````5XO_T`````"3G__P`Y!`C!$$` M`@!`""$D(0`!``$00Q!``#8`0#`A*,$`?Q0@``0`!AP`$````R0#`'X`!AP` M``,<`S1X`(`H80`)I+@```##,",4(``9)*4``I29```D8__XI+D``)2*``(` M`QP`I*H``I2+``0``QP#I*L`!)2,``8H80`)I*P`!I2-``@DI0`0I*W_^)2. M``HDA``0I*[_^I2/__P`````I*___)28__X0(/_II+C__@!@$"$D8___``,< M`!!```H``QP#`&`0(929```D8___``,<```#'`,DA``")*4``A1`__BDN?_^ M%,#_S2C!`'\`X"`A).<``@#H""N$X__^$"``#@#D$".4Z@```&`0(11*``D` M````).<``@#H""L0(``%`````)3K````````$$O_^0``````Y!`C!$$``@!` M""$D(0`!``$00Q!```\`0#`A`&`0(2C!`'\4(``$``8<`!````,D`P!^``8< M```#'`,`PS`CI*,``"2E``(DI0`"%,#_]*2B__X`Z`@K%"#_@`#@("$DI0`" M`*D0(P1!``(`0`@A)"$``0`!$$,0```)I*#__CP$$``\!1``)*4$&"2$"+0/ MX`14`&`P(0P0%&0D!``!C[\`%">]`!@#X``(`````">]_^@`H!@A)`(``:^_ M`!0`@$`A%&(`4P#`2"$4X@!1``````$`,"$!(!`AD,0``"3&``$P@P!_,&?_ M_Q#@`5`P9?__,(X`@!'``"DLX0`(%"``&@"@&"&0SP``)*7_^*!/``"0V``! M,*7__Z!8``&0V0`"+*$`"*!9``*0R@`#)$(`"*!*__N0RP`$),8`"*!+__R0 MS/_]`````*!,__V0S?_^`````*!-__Z0SO__$"#_Z:!.__\`H!@A)*7__Q!@ M_]HPI?__D,\```"@&"$DI?__,*7__R3&``$D0@`!%&#_^:!/__\0`/_1D,0` M`)#$```LH0`(%"``#B3&``&@1```H$0``:!$``(DI?_XH$0``S"E__^@1``$ M+*$`"*!$``6@1``&H$0`!Q`@__0D0@`(`*`8(22E__\08/^[,*7__P"@&"$D MI?__,*7__Z!$```48/_[)$(``1``_[20Q```$&(`!"0$``(0``!4)`0``B0$ M``(4Y`!1``````$`,"$!(!`AD,0``"3&``$P@P!_,&?__Q#@`/DP9?__,)@` M@!,``"DLX0`(%"``&@"@&"&0V0``)*7_^*19``"0R@`!,*7__Z1*``*0RP`" M+*$`"*1+``20S``#)$(`$*1,__:0S0`$),8`"*1-__B0SO_]`````*1.__J0 MS__^`````*1/__R0V/__$"#_Z:18__X`H!@A)*7__Q!@_]HPI?__D-D```"@ M&"$DI?__,*7__R3&``$D0@`"%&#_^:19__X0`/_1D,0``)#$```LH0`(%"`` M#B3&``&D1```I$0``J1$``0DI?_XI$0`!C"E__^D1``(+*$`"*1$``JD1``, MI$0`#A`@__0D0@`0`*`8(22E__\08/^[,*7__P"@&"$DI?__,*7__Z1$```4 M8/_[)$(``A``_[20Q```%&0`4P`````4X@!1``````$`,"$!(!`AE,0``"3& M``(P@P!_,&?__Q#@`*4P9?__,(H`@!%``"DLX0`(%"``&@"@&"&4RP``)*7_ M^*!+``"4S``",*7__Z!,``&4S0`$+*$`"*!-``*4S@`&)$(`"*!.__N4SP`( M),8`$*!/__R4V/_Z`````*!8__V4V?_\`````*!9__Z4RO_^$"#_Z:!*__\` MH!@A)*7__Q!@_]HPI?__E,L```"@&"$DI?__,*7__R3&``(D0@`!%&#_^:!+ M__\0`/_1E,0``)3$```LH0`(%"``#B3&``*@1```H$0``:!$``(DI?_XH$0` M`S"E__^@1``$+*$`"*!$``6@1``&H$0`!Q`@__0D0@`(`*`8(22E__\08/^[ M,*7__P"@&"$DI?__,*7__Z!$```48/_[)$(``1``_[24Q```%&0`4P`````4 MY`!1``````$`,"$!(!`AE,0``"3&``(P@P!_,&?__Q#@`%$P9?__,(P`@!&` M`"DLX0`(%"``&@"@&"&4S0``)*7_^*1-``"4S@`",*7__Z1.``*4SP`$+*$` M"*1/``24V``&)$(`$*18__:4V0`(),8`$*19__B4RO_Z`````*1*__J4R__\ M`````*1+__R4S/_^$"#_Z:1,__X`H!@A)*7__Q!@_]HPI?__E,T```"@&"$D MI?__,*7__R3&``(D0@`"%&#_^:1-__X0`/_1E,0``)3$```LH0`(%"``#B3& M``*D1```I$0``J1$``0DI?_XI$0`!C"E__^D1``(+*$`"*1$``JD1``,I$0` M#A`@__0D0@`0`*`8(22E__\08/^[,*7__P"@&"$DI?__,*7__Z1$```48/_[ M)$(``A``_[24Q```/`00`#P%$``DI00X)(0(M`_@!%0`8#`A#!`49"0$``&/ MOP`4)[T`&`/@``@`````)[W_P*^P`"``@(`AK[\`))8.`'``H%`A,<\`@@#` M8"$5X``#`.!8(1```1``!`````"/I0`H#!`-'0%`("&6`@`&$```H8^_`"0\ M!!``/`40`"2E!%0/X`14)(0(M`P0%&0D!``!$```F(^_`"0D`0$`%$$`C0`` M```0``"$,&(`_Y8#``:."``,`&`@(8X)`!``@!`A`4`H(1!```\DA/__E*(` M```````!(@@K$"```P!(""L`0$@A`$@(*Q`@``(``````$!`(0"`$"$DI0`" M%$#_\R2$__^.!@"$K@@`#*X)`!"OK`!(KZL`3*^C`!`!0"`A)`4``@P0#J8D M!P`!CZL`3(^L`$BOH@`H`@`@(0!`*"$!8#@A#!`.?`&`,"&/JP!,CZP`2`(` M("$!8#`A#!`-I`&`*"&.!0"$CZ8`*`P0#@<"`"`AE@(`!A```%Z/OP`DE@,` M!HX(``P`8"`AC@D`$`"`$"$!0"@A$$``#R2$__^4H@````````$B""L0(``# M`$@(*P!`2"$`2`@K$"```@``````0$`A`(`0(22E``(40/_S)(3__XX&`(2N M"``,K@D`$*^L`$BOJP!,KZ,`$`%`("$D!0`"#!`.IB0'``*/JP!,CZP`2``" M*$"OI0`H`@`@(0%@."$,$`Y\`8`P(8^K`$R/K`!(`@`@(0%@,"$,$`VD`8`H M(888`'(`````$P``!0````".!`"$CZ4`*`P0#1T`````C@4`A(^F`"@,$`X' M`@`@(889`'(`````$R``!0````".!`"$CZ4`*`P0#1T`````E@(`!A```!F/ MOP`D/`00`#P%$``DI01H#^`$5"2$"+0,$!1D)`0``1```!"/OP`D)`$``1!! M_WLD`0`"$$'_K@`````0`/_Q`````#P$$``\!1``)*4$?`_@!%0DA`BT#!`4 M9"0$``&/OP`DC[``(`/@``@GO0!`)[W_T*^P`!@`@(`AK[\`'*^E`#26#@!P M`,`8(3'/`($5X``#`````!```)`````!```"\`````C@4` MA)8&``8,$`XE`@`@(98&``:.`P"$``84```"%`,`0"@A)$+__X^D`#0``A0` M$*``#``"%`,`0"@AD'@``"1"__\``A0```(4`R1C``$DA``"%*#_^*28__Z6 M!@`&`````!```&$`P!`AE@,`!H^E`#0``QA```,<```#'`,`8#`AIZ,`(`P0 M#B4"`"`AAAD`C`"`3(``$`````(^D`#0,$`T=`&`H(98"``80``!/C[\` M'#P$$``\!1``)*4$F`_@!%0DA`BT#!`49"0$``$0``!&C[\`'"0!`0`400`[ M`````!```#(P90#_#!`.7@(`("&.!0"$``(T```&-`,,$`XE`@`@(8X$`(2/ MI@`T)`4``0P0$/,D!P`"E@(`!A```#*/OP`<#!`.7@(`("$``AP```,<`XX% M`(0``C0```8T`Z>C`"`,$`XE`@`@(88(`'*'HP`@$0``!`````".!`"$#!`- M'0!@*"&.!`"$CZ8`-"0%``(,$!#S)`<``I8"``80```9C[\`'#P$$``\!1`` M)*4$K`_@!%0DA`BT#!`49"0$``$0```0C[\`'"0!``$0H?_-)`$``A"A_]H` M````$`#_\0`````\!!``/`40`"2E!,`/X`14)(0(M`P0%&0D!``!C[\`'(^P M`!@#X``()[T`,``````#X``(````````````````)[W]6`"`&"$D#O__K[\` M%!1@`!&OK@`D`B@/ MX`2\KZ,"J(^C`J@GI`(V#^`$O`!@*"$GI`(H#!`4@```*"$$0``1`$`@(2>E M`"0D!@("#!`4D*^D`"`D`0("%$$`"(^D`"`\!!``)(0$X">E`"0/X`2,)`8" M`J^@`!R/I``@#!`4<`````"/H@`<`````(^_`!0GO0*H`^``"``````````` M)[W_Z*^_`!0/X`0^KZ0`&(^D`!@,$!2@`````(^_`!0GO0`8`^``"``````` M````)`(#[@````P0X``#``````@0%*0``````^``"```$"$D`@/P````#!#@ M``,`````"!`4I``````#X``(`````"0"`^T````,$.```P`````($!2D```` M``/@``@`````)`(#[`````P0X``#``````@0%*0``````^``"``````D`@/K M````#!#@``,`````"!`4I``````#X``(`````"0"`_L````,$.```P`````( M$!2D``````/@``@`````)`(#Z0````P#X``(`````#P!$`"L(@]L`^``""0" M__\\`Q``C&,.Y"0"`_D`@R`A````#!3@``0\`1```&`0(0/@``BL)`[D"!`4 MI``````\`A``C$(.X```````@@@K$"```@``````0"`A)`(#^0````P4X/_T M/`$0`*PD#N0#X``(```0(0```````````````````````````````#P"$`$D M0D]P/`$/P*PB`$`\`A`!)$)O>#P!#\"L(@!$/`(0`B1"CX`\`0_`K"(`2#P" M$``D0@B4/`$/P*PB`$P\`A``)$(/0#P!#\"L(@!0/`(0`"1"!P`\`0_`K"(` M5#P"#X`D0A((/`$/P*PB`"`\`@^`)$(2$#P!#\"L(@`D/`(/@"1"$@`\`0_` MK"(`*#P"`$`D0E*@/`$/P*PB`!0\`@!`)$)2T#P!#\"L(@`8/`(0`"1"#V`\ M`0_`K"(`$#P"$``D0@]L/`$/P*PB`!P\`A``)$($X#P!#\"L(@```^``"``` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````=7-A9V4@9G)O;71AF4@)60*````=&]T87)G M83H@8V%N)W0@;W!E;B!I;G!U="!F:6QE("5S"@``;G5M:60@)60*````;6%P M='EP92`E9`H`:6UG='EP("5D"@``;6%P;W)I9R`E9"!M87!S:7IE("5D(`H` M;6%P8FET&]R:6<@>6]R:6<@)60@)60*``!X'-I>F4@)60*`&EM9V1EF4Z(&-A;B=T(&]P96X@:6YP=70@9FEL90H` M````:6UG7W-E96LZ('=I97)D(&EM86=E('1Y<&4*`&EM9VQI8CH@EM<75Y?8$%"0T1%1D=(24I+ M3$U.3U!14E-455976%E:>WQ]?G\````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````0TA20TQ!4U,`````+VQI8B]C:')C;&%S Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: SGI's migration to X Message-Id: <1990Sep7.190102.28444@odin.corp.sgi.com> References: , <1990Sep6.010419.1573@odin.corp.sgi.com>, <1990Sep6.175301.18898@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep6.175301.18898@jarvis.csri.toronto.edu>, drb@eecg.toronto.edu (David R. Blythe) writes: |> It would be really really really really nice if whatever X toolkit/UIMS/etc |> gets fobbed off on me (i.e. Motif,OpenLook) also works with GL graphics. |> That is to say, I want to learn *one* subroutine library for popups, |> pulldowns, radio knobs, other crap that can be used in both a GL window and an |> X window. This would seem like a good reason to have X requests and GL |> requests work together, rather than making a GL version of the same library. Apparently you didn't read the last paragraph of my message where I pointed out that you will be able to to mix GL and X subwindows within a single top-level window. This is all the support you need to use any of the X toolkits. |> If a client is local can't it use the same direct paths to the hardware as GL |> (i.e. have X built on top of or in conjunction with GL (either through the |> X server, or bypassing it when possible) rather than a separate |> entity)? Remote requests would have to go through a serializer, so the remote |> guy may pay some performance penalty in extra overhead but it seems worth it |> to keep the local stuff fast and integrated. It can be done but remember we are talking about a fast path to the graphics hardware which is a very different thing than the X server. Xlib has to be extensively rewritten, a fairly massive undertaking that is difficult to do without breaking fundamental things about X. IBM has done it. Unfortunately their system decides which version of Xlib to use (the standard one or the rewritten one) based on whether the first display the client opens is local or remote. If a client opens a local display then a remote display ... oops. -- 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 aa06505; 7 Sep 90 16:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac06300; 7 Sep 90 16:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab06296; 7 Sep 90 16:15 EDT Received: from csdfx8a.arlut.utexas.edu by VGR.BRL.MIL id aa04345; 7 Sep 90 16:10 EDT Received: by csdfx8a.arlut.utexas.edu (5.0/Alliant-5.0) id AA23279; Fri, 7 Sep 90 15:12:53 CDT Date: Fri, 7 Sep 90 15:12:53 CDT From: David Boles Message-Id: <9009072012.AA23279@csdfx8a.arlut.utexas.edu> To: info-iris@BRL.MIL Subject: beware of novice! Hello ! I am currently looking into buying a computer or computers for work. Since I am extremely new to this, I was wondering if I could get some feedback from "the guys in the trenches" on my computational needs. Basically, I need scientific visualization and image processing capabilities. Some of the things being tossed around are: (1) Suppose I have data that will be viewed as a 3d sur- face; I would like to map other 2d data onto this surface. Is it possible to animate a series of images in which the 3d surface stayed the same but the 2d data changed? Is there any fundamental change in considering this for a 40x40 grid, 100x100 grid, 200x200 grid? (2) Suppose that I bought a machine that could not smoothly animate the images that I have created. Could I then render them in advance, store them, and somehow replay them? Would this then be trans- ferable to videotape? (3) If I started on a small SGI machine initially and later upgraded to a larger, faster unit, how hard would the transition be in terms of software? Any response on these questions as well as general comments will be greatly appreciated. Please send these to (me) : aviator@csdfx8a.arlut.utexas.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06656; 7 Sep 90 16:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab06505; 7 Sep 90 16:33 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06477; 7 Sep 90 16:27 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa04384; 7 Sep 90 16:19 EDT Received: Fri, 7 Sep 90 16:19:14 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 7 Sep 90 16:19:14 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009071919.AA00779@aero4.larc.nasa.gov> To: shakti!dhekne@uunet.uu.net Subject: Re: "debugger on IRIS 3130" Cc: info-iris@BRL.MIL Edge on the 3130 doesn't work with graphics, period. However, dbx does work on the 3130, sort of. One of the main things you must do in a graphics program is to have a call to foreground before opening a window or dbx wont work. If you can afford to up grade to a SGI Personal Iris do it. SGI never supported the 3130 from the beginning, so most of the software bugs were never fixed. The window manager, MEX, will crash if you sneeze, and there are a whole list of other problems. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07118; 7 Sep 90 17:59 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07034; 7 Sep 90 17:49 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06991; 7 Sep 90 17:42 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04674; 7 Sep 90 17:31 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03869; Fri, 7 Sep 90 14:19:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 20:57:30 GMT From: Wiltse Carpenter Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Non Volatile RAM checksum error!! Message-Id: <1990Sep7.205730.612@odin.corp.sgi.com> References: <1990Sep7.071805.22982@ariel.unm.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep7.071805.22982@ariel.unm.edu> jcmiller@hydra.unm.edu (Jeff Miller) writes: > > I have had this repetitive problem with my SGI 4d/20 system that >I am rebuilding. > : >Non-volatile RAM checksum is incorrect: Initializing the non-volatile > RAM parameters. > > I suspected that the problem might be a low lithium battery, but The battery powers only the time of day clock and does not affect the non-volatile ram (an EEPROM). > A friend said that the problem might be a bad NVRAM chip on the >motherboard. The non-volatile ram is actually on a small pc board with the reset button connected to the motherboard by a small ribbon cable. It contains some of the stuff that gets printed when you do a ``printenv'' from the PROM's manual mode prompt (e.g. bootfile) and generally gets set with the setenv command from the same prompt. It also contains the Ethernet address so that switching electronics modules does not change the machine's address. > Any comments, solutions, remarks, etc. would be GREATLY > appreciated! Perhaps the little cable is disconnected (try typing eaddr in the PROM to see if your Enet address looks reasonable), or maybe the EEPROM is bad. -Wiltse   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07553; 7 Sep 90 18:34 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07475; 7 Sep 90 18:24 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07473; 7 Sep 90 18:19 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04829; 7 Sep 90 18:15 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06689; Fri, 7 Sep 90 15:03:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 20:25:55 GMT From: Mark Bradley Organization: Solbourne Computer Systems Subject: Re: 1.2GB SCSI Disks? Message-Id: <1990Sep7.202555.10668@Solbourne.COM> References: <1990Sep7.112245.2982@sgzh.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep7.112245.2982@sgzh.uucp> root%sgzh.uucp@uunet.uu.net (Bruno Pape) writes: >I am now somewhat more informed about SMD and IPI disks. > >The next question I have is, what will happen if I take a 1.2GB SCSI >disk that we sell for the PI and put it in the twin tower for say a >320VGX in place of the normal 760MB SCSI? Will this work? What fun >suprises may lay in store? > >Thanks again, > >Bruno It will cause a complete power failure for not only your 320VGX, but for the entire building in which the machine is housed. But really, the termination for the PI is external, and on the twin tower, is integral to the disk. make sure it's terminated correctly. If you don't know the details of this, you should probably not try this yourself. markb -- Mark Bradley (DoD#1100) Faster, faster, until the thrill I/O Subsystems of speed overcomes the fear of death. Solbourne Computer, Inc. --Hunter S. Thompson   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00122; 7 Sep 90 21:34 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08519; 7 Sep 90 21:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08492; 7 Sep 90 20:53 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05261; 7 Sep 90 20:46 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17311; Fri, 7 Sep 90 17:43:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 90 20:17:05 GMT From: Anil Kaul Organization: IBM T.J. Watson Research Center Subject: Tex, Postscript, figures......... Message-Id: <1990Sep7.201705.18938@arnor.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Keywords: Hi, I am writing a report in Latex and would like to include a screen dump from an SGI screen. I wonder if there is anybody out there who has done such a thing in the past and I would greatly appreciate any help in how to do the same. I know how to include a postscript file in a tex document and print it. But the problem I am facing with including a screen dump obtained by "scrsave() and tops()" is that when I include it in the document, I can't get the picture to position itself in the bounding box I define for it. It turns out that the picture is always drawn at the top of the page and in the process at most times it lands up overwriting over text. Can someone shed some light on this topic please? thanks, - Anil Kaul kaul@ibm.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ac00122; 7 Sep 90 21:35 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab08519; 7 Sep 90 21:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab08492; 7 Sep 90 20:53 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05263; 7 Sep 90 20:47 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17391; Fri, 7 Sep 90 17:44:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 00:42:12 GMT From: "John M. Sullivan" Organization: Princeton University Mathematics Department Subject: NeWS can't find host information for "cinnamon" Message-Id: <2356@idunno.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was trying to put a new Iris on our network, and copied a bunch of files over from one of our other machines to get yp set up right, etc. yp does now seem to work, but somehow I broke NeWS. If I log in on the console now (without NOGRAPHICS), I get a message (too quickly to read it) about the window server dying with status 1. If I run /bin/news_server by hand, it says: NeWS can't find host information for "cinnamon" The file /etc/hosts and the yp hosts database both contain proper entries for cinnamon (128.112.16.70) and for localhost. The networking is working fine--nfs, yp, rlogin, ftp all are happy. There doesn't seem to be a trace command on the iris like on the sun to see what news_server is doing. 'strings' wasn't much help either. Does anyone know what "host info" it is looking for where? Thanks, John Sullivan sullivan@math.princeton.edu -- John M. Sullivan Princeton Univ. Math Dept. sullivan@math.princeton.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01472; 8 Sep 90 1:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01432; 8 Sep 90 1:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01430; 8 Sep 90 1:42 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00673; 8 Sep 90 1:31 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05545; Fri, 7 Sep 90 22:30:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 00:52:21 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: PD nroff (of sorts) Message-Id: <1990Sep8.005221.6101@relay.wpd.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There have been requests on this alias for PD alternatives for formatting nroff documents, especially for manual page viewing. A program called awf was posted to comp.sources.unix. Its creator is Henry Spencer at the University of Toronto. It may be suitable for preformatting 3rd party manual pages so that IRIX man command can display them. --- Ciemo   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00099; 10 Sep 90 19:22 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00421; 10 Sep 90 18:27 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00397; 10 Sep 90 18:10 EDT Received: from SGI.COM by VGR.BRL.MIL id aa06981; 10 Sep 90 17:24 EDT Received: from relay.sgi.com by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for info-iris@brl.mil id AA16837; Fri, 7 Sep 90 10:51:16 -0700 Received: from gate-whizzer.esd.sgi.com by relay.sgi.com (5.52/900423.SGI) for @sgi.sgi.com:info-iris@brl.mil id AA22155; Fri, 7 Sep 90 10:51:08 PDT Received: from rhyolite.wpd.sgi.com by whizzer.wpd.sgi.com via SMTP (5.64-bind 1.5+ida/900721.SGI) for @relay.sgi.com:info-iris@brl.mil id AA10276; Fri, 7 Sep 90 10:50:42 -0700 Received: by rhyolite.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:karron%CMCL2.NYU.EDU@CUNYVM.CUNY.EDU id AA19020; Fri, 7 Sep 90 10:50:41 PDT Date: Fri, 7 Sep 90 10:50:41 PDT From: Vernon Schryver Message-Id: <9009071750.AA19020@rhyolite.wpd.sgi.com> To: info-iris@BRL.MIL, karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Subject: Re: RTS-CTS bad on ttyf?? > From @CUNYVM.CUNY.EDU:karron@mcirps2.med.nyu.edu Thu Sep 6 20:04:44 1990 >... > WRONG ! . These ports should open, but no characters should move until > CTS is engaged. I don't know about newer machines, but the CTS pin > seems to be GROUNDED, as I can't get the breakout box led to light > up when it is connected to +BATTERY, or low when -BATTERY. You appear to have a bad cable somewhere. CTS is not grounded in old or new machines. The fault could be either your external cable or something within the machine. >... > I am also finding that the kermit I use does a core dump on trying > to open ttyf[1,2] with handshake engages. After a while, I am getting > messages about streams being out of resourses. I will reboot the > machine to clear the streams kernel, but this does not look good. You apparently have your own kermit. The core dump might tell you what it is doing. Running out of streams resources is most often caused by echo-loops between the machine and a modem. For example, if you configure your modem, printer, or whatever with echoing turned on, and then turn on a getty at high speed, you can cause shouting matches that consume vast numbers of buffers. > The /dev/tty{d,m}4 (I only tested 4, and don't want to spend > more time on this) do NOT do RTS-CTS, as expected. the /dev/tty{f}4 lines > does asssert RTS, and drops it as its buffer fills. It does NOT > listen to CTS. Indeed, I think that that line is shorted someplace > judging from the behavior of the break out box LEDs'. This is how the drivers have worked since I added RTS/CTS flow control years ago. tty{d,m}* keep RTS=DTR and CTS is ignored. Only ttyf* do hardware flow control, using RTS and CTS as stop and go indications. > I can use RTS-CTS between the host and the peripheral device. The host can > tell the peripheral to stop transmitting, but the peripheral can not tell the > host to be quiet. For my application (verbose peripheral limited by host), > that is fine. However, since I can't get a signal from the hosts CTS, > loopback testing of the host RTS-CTS does NOT work. Indeed, my experience > with RTS-CTS signaling is that the host should not transmit unless CTS is held > high. It seems that sgi does not respect CTS, and holds RTS up except when it > does not want characters. The tty{m}4 properties seem to work as expected. > The machine would send a HANGUP (or at least kermit said somthing) signal when > DCD was disconnected. >.... Again, it sounds as if you have a bad cable. RTS/CTS flow control not only works well on 4D70's, it is necessary for another pet of mine, SLIP over >=9.6 modems such as Telebits. Vernon Schryver vjs@sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id ab01675; 8 Sep 90 2:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab01432; 8 Sep 90 1:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab01430; 8 Sep 90 1:42 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa00679; 8 Sep 90 1:31 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5399; Sat, 08 Sep 90 01:31:03 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Sat, 8 Sep 90 01:34 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA06570; Sat, 8 Sep 90 01:37:08 DSD Date: Sat, 8 Sep 90 01:37:08 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: time() vs gettimeofday() To: info-iris@BRL.MIL Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009080837.AA06570@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil Which is the better time call to use if you only are interested in measuring clock seconds ? (not system time, cpu time, but real time as measured by a stop watch ). How do you know if the Performance Measurement Utilities are installed ? I don't remember seeing them on my 3.3 inst tape. Where are they ? dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01868; 8 Sep 90 3:14 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01765; 8 Sep 90 2:42 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01719; 8 Sep 90 2:31 EDT Received: from [132.206.6.10] by VGR.BRL.MIL id aa00776; 8 Sep 90 2:21 EDT Received: by frodo.Physics.McGill.CA id AA07955; Sat, 8 Sep 90 02:22:21 EDT (5.59++/IDA-1.1S) Date: Sat, 8 Sep 90 02:22:21 EDT From: Loki Jorgenson Rm421 Message-Id: <9009080622.AA07955@frodo.Physics.McGill.CA> To: info-iris@vgr.brl.mil Subject: What is "pseudorgb()"? Hey ho.... I have been fruitlessly searching man pages, libraries, include files and source code trying to find out what "pseudorgb()" does. I have discovered that one needs -lgutil to resolve it but "ar -t libgutil.a" does not show it in the table of contents. Can anyone enlighten me as to what it is and why I can't find it, either in references or in libraries? Thanks, Loki Jorgenson node: loki@physics.mcgill.ca Physics, McGill University fax: (514) 398-3733 Montreal Quebec CANADA phone: (514) 398-6531 << If I only had a brain >>   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04039; 8 Sep 90 15:44 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa04008; 8 Sep 90 15:34 EDT Received: by VMB.BRL.MIL id aa04003; 8 Sep 90 15:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03983; 8 Sep 90 15:16 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa01856; 8 Sep 90 15:11 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7707; Sat, 08 Sep 90 15:10:50 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Sat, 8 Sep 90 15:13 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA07410; Sat, 8 Sep 90 15:17:20 DSD Date: Sat, 8 Sep 90 15:17:20 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: RTS-CTS retraction : NO PROBLEM. To: info-iris@BRL.MIL Cc: vjs@sgi.com Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009082217.AA07410@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil, vjs@sgi.com After checking all of the subtle possibilities, I was refered to check the obvious: cables. I tested my cables, and they seemed ok. I then tested the ports with a paperclip (to loop back TD-RD, CTR-RTS, and DCD-DTR ) and eliminate problems with cables. The problem persisted, and pointed to inside the machine. I opened the back, and using a can of contact cleaner, blew out lots of dust, dirt, and junk. Cleaned the boards and the ribbon cable card edge connectors, and reassembled. the problem was gone. My machine is well over three years old, gets moved a lot, and has worked very dependable so that it is not opened up much. Sorry for the fuss, and I am very happy with hardware handshaking at high serial io speeds, > 9600 baud. I have been running test overnight, and there have been no lost characters. My thanks to Vernon Schryver, (who implimented RTS-CTS on the 4D machines) for patiently holding forth that my problem was cables, even when I did not think that it was the cause of the problem. dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04102; 8 Sep 90 16:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03914; 8 Sep 90 15:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03890; 8 Sep 90 15:03 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa01839; 8 Sep 90 14:56 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7664; Sat, 08 Sep 90 14:56:04 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Sat, 8 Sep 90 14:59 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for mcclb0.med.nyu.edu!ucbvax.berkeley.edu!sgi!shinobu!odin!sgihub!dragon!bananaPC. wpd.sgi.com!ciemo) id AA07340; Sat, 8 Sep 90 15:02:36 DSD Date: Sat, 8 Sep 90 15:02:36 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: Re: PD nroff (of sorts) To: Dave Ciemiewicz Cc: info-iris@BRL.MIL Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009082202.AA07340@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil Great ! Where can I get it (Henry Spencers awf) ? How do I get somthing in comp.sources.unix ? I don't have rn, and the main university does not keep postings more than a few days. If you have Henry Spencers e-mail address, can I write him ? dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06643; 12 Sep 90 17:55 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06563; 12 Sep 90 17:44 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06535; 12 Sep 90 17:40 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa03927; 12 Sep 90 17:24 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17452; Wed, 12 Sep 90 14:07:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 06:41:04 GMT From: Stephen Johnson Subject: Sun DGA Message-Id: <142064@sun.Eng.Sun.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL DGA -- any workstation hardware vendor must use it to get around the inherent graphics inadequacies of X windows. What is Sun's DGA? On Sun systems, the X-windows applications programmer is allowed access to the underlying graphics hardware through either a Sun API or through the standard X protocol. The Sun API uses a combination of shared memory, device driver, and library interface code to get access to the raw hardware capabilities. This is DGA in its most fundemental form. The shared memory area is used to keep the client process in synch with the server process. The device driver code is used to make sure the kernel, the server process, and the DGA client process are all in sync with the hardware, and, finally, the library interface must be appropriate to take advantage of the hardare/DGA capabilities. This is what Xgl does. It remains synchronous with the server through the shared memory information and it remains on track with the hardware through the device driver and, finally, the libraray interface it most appropriate for X clients and X applications. Xgl is structured so that it runs within a X window. It is capable of producing hardware performance on a local host and Xlib performance on a network. At worst, Xgl always runs at Xlib performance. Xlib and Xgl will always coexist within a window. Xlib calls for rendering and Xgl calls for rendering always synchronize with the shared memory area before touching the hardware underlying the window. Thus, Xgl rendering calls and Xlib calls can coexist with little problem at the application level. Although, in reality, the Xlib programmer must perform a XFlush or a xgl_context_post before switching from one rendering methodology to the other. Thus, the Xgl programmer can use Xlib calls and Xgl calls intermixed to produce high performance graphics on Sun workstations. -Stephen Johnson - Xgl Graphics Software Engineer These are my personal opinions and the rest about ownership seems silly.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06950; 12 Sep 90 18:16 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab06563; 12 Sep 90 17:45 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa06551; 12 Sep 90 17:41 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04005; 12 Sep 90 17:36 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19786; Wed, 12 Sep 90 14:32:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 08:58:49 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: time() vs gettimeofday() Message-Id: <1990Sep8.085849.5096@odin.corp.sgi.com> References: <9009080837.AA06570@mcirps2.med.nyu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <9009080837.AA06570@mcirps2.med.nyu.edu> karron@MCIRPS2.MED.NYU.EDU writes: | Which is the better time call to use if you only are interested | in measuring clock seconds ? (not system time, cpu time, but | real time as measured by a stop watch ). gettimeofday() will get you down to the system clock resolution, which is 10 ms by default, but which can be changed to ~1 ms (exact value depends on the model) by kernel configuration or the ftimer command. time() will only give you 1 second resolution. | How do you know if the Performance Measurement Utilities are installed ? | I don't remember seeing them on my 3.3 inst tape. Where are they ? Install eoe2.sw.perf (the ftimer command mentioned above is in eoe2.sw.usrenv). -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa07865; 12 Sep 90 20:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa07739; 12 Sep 90 19:54 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07680; 12 Sep 90 19:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04363; 12 Sep 90 19:38 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28582; Wed, 12 Sep 90 16:30:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 90 22:10:12 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: time() vs gettimeofday() Message-Id: <68830@sgi.sgi.com> References: <9009080837.AA06570@mcirps2.med.nyu.edu>, <1990Sep8.085849.5096@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep8.085849.5096@odin.corp.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes: > > gettimeofday() will get you down to the system clock resolution, > which is 10 ms by default, but which can be changed to ~1 ms (exact > value depends on the model) by kernel configuration or the ftimer > command. time() will only give you 1 second resolution. The resolution of gettimeofday() is limited to the frequency of clock interrupts, which is either 10 or 1 ms. However, you should not expect the tv_usec field of the structure returned by gettimeofday() to contain a multiple of 10,000 or 1,000. Any fractions of a clock tick from the adjtime() system call are slopped into the current time. In addition, the syssgi() system call can be used to adjust the clock rate, periodically adding or subtracting a number of nanoseconds to the current time, thereby jiggling the least significant bits of the current time. The deamons described in timed(1M) and timeslave(1M) use both mechanisms. A port of ntp or xntp would also use them. Gettimeofday() and time() should be used for time stamps. The timers used by select() and other things are based on "lbolt", the "hz counter" that is returned by times(). Times() should be used if you want a relatively constant tick. vjs   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08034; 12 Sep 90 20:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac07865; 12 Sep 90 20:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07795; 12 Sep 90 19:58 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04417; 12 Sep 90 19:53 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00380; Wed, 12 Sep 90 16:48:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 90 02:56:12 GMT From: Kevin Marinelli Organization: Dalhousie University Subject: Re: Name server problems Message-Id: <1990Sep9.025612.17127@nstn.ns.ca> References: <9009071138.AA01151@itnsg1.cineca.it> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL One method that I have used to solve this problem is to have our net adminintrator create "permanent" fictional machines. This way, when I need to put test equipment on the net, all I do is configure the machine with an IP address and a name from the list of what I can use, and away the machine goes, including having the DNS recognize it. Kevin Marinelli Dalhousie University   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08205; 12 Sep 90 20:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08109; 12 Sep 90 20:35 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08069; 12 Sep 90 20:24 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04454; 12 Sep 90 20:12 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00696; Wed, 12 Sep 90 16:52:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 90 03:21:25 GMT From: Kevin Marinelli Organization: Dalhousie University Subject: Re: NCAR Graphics 3.0 Message-Id: <1990Sep9.032125.18360@nstn.ns.ca> References: <90249.232702RIE@psuvm.psu.edu>, <3877@umbc3.UMBC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3877@umbc3.UMBC.EDU> bernie@umbc5.umbc.edu.UUCP (Bernard J. Duffy) writes: >In article <90249.232702RIE@psuvm.psu.edu> RIE@psuvm.psu.edu writes: >>We wish to run NCAR Graphics version 3.0 on a Personal Iris. If you I do not have experience with NCAR V3.0, just versions 1 and 2. I have had experience installing older version of NCAR on numerous systems for about 8 years. These older versions were FORTRAN based not C based, so I have no real experience at all installing version 3.0, but I may be able to help a little anyway. > > I've gone through several installation attempts with the NCAR 3.0 >on the SGI platforms. First thing to know is that that software version >was built on an IRIX 3.1 system. I was and still am running IRIX 3.2 >on a SGI 4D/25 and SGI 4D/210 (headless). > I didn't have any problems with the make if it didn't include the >Athena utilities other than the make process was performed via a NFS >src tree. That bombed out due to an NFS bug on Ultrix 3.? (highest >prior to 4.0) where it would sometimes it wouldn't complete an operation. >The make sequence stopped where there was a break in the connection due >to an NFS I/O error. > All you had to do is follow the directions which were documented in >the manual(s), in one of the README files, and with the "Configure -v" >(the first command) where you setup the "config" file. > I haven't sucessfully built the NCAR GKS with the Athena utilities >because of : > 1) some problem with the include files : >... >Making athena > cc -DSYSV -O -I../../../include -c athena.c >cpp: error /usr/include/bsd/sys/ioctl.h:9: Can't find include file net/soioctl.h >cpp: error /usr/include/bsd/sys/ioctl.h:10: Can't find include file sys/ttychars >.h >*** Error code 1 > >Stop. >... > *** this made me try a build with -I/usr/include/bsd in the CFLAGS > makefile variable in config/SGI4D . I got a little farther, but > that wasn't the solution : >... >Making idt > cc -DSYSV -I/usr/include/bsd -O -I../../include -c intermed.c >ccom: Error: intermed.c, line 36: redeclaration of sprintf > extern char *sprintf(); > ----------------------------^ >*** Error code 1 > >Stop. >... Remove all defines for sprintf in the code by commenting them out. They are already pre-defined for you in IRIX. I have run into this problem before when I was installing the Utah Raster Toolkit and other software. In general, when you get a re-declaration error for a "standard" UNIX function you should comment out the offending definition. You are mostly correct in your modifications to the compile line. (someone please correct me if I am wrong but...) cc -DSYSV -I/usr/include/bsd -O -I../../include -c intermed.c -lbsd Should be a more general compilation statement when using BSD functions. The -lbsd tells the linker to link with the bsd libraries. It is not necessary when you compile with the -c option, which tells the compiler not to invoke the linker. In general, when compiling with the -I/usr/include/bsd option, including the -lbsd option at the end of the compilation statement is a good idea that is harmless when it is not needed but is VITAL when it is needed. > > I still have a call into the NCAR folks on how to build this under 3.2 >and I'm also curious how they might have handled 3.3 (which I still don't >have). > > So, follow the directions for regular and X11 NCAR GKS 3.0 > for IRIX 3.[12].* > >fyi, Bernie > >Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 >Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU >Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie >Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954 Good Luck, Kevin Marinelli Dalhousie University Halifax, N.S.   Received: from vmb.brl.mil by VMB.BRL.MIL id ac08643; 12 Sep 90 22:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab08627; 12 Sep 90 22:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab08601; 12 Sep 90 22:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04738; 12 Sep 90 22:27 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14110; Wed, 12 Sep 90 19:20:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 90 19:47:18 GMT From: Mark Moraes Organization: Department of Computer Science, University of Toronto Subject: Re: PD nroff (of sorts) Message-Id: <90Sep9.154557edt.550@smoke.cs.toronto.edu> References: <9009082202.AA07340@mcirps2.med.nyu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL karron@MCIRPS2.MED.NYU.EDU writes: >Where can I get it (Henry Spencers awf) ? >How do I get somthing in comp.sources.unix ? I don't have rn, > and the main university does not keep postings more than a few days. cs.toronto.edu:pub/awf.shar.Z is a copy straight from Henry's uucppublic. (It's also on uunet.uu.net by now, and every comp.sources.unix archive, presumably) Mark. PS: No, Ed. Don't repost this! :-) From comp.archives Thu Sep 6 20:20:16 EDT 1990 Path: news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv From: moraes@cs.toronto.edu (Mark Moraes) Newsgroups: comp.archives Subject: [news.software.b] Re: cnews expire takes forever Keywords: awf, nroff clone, written in old awk, henry spencer lunacy (:-) Message-ID: <1990Sep6.225856.18153@math.lsa.umich.edu> Date: 6 Sep 90 22:58:56 GMT Sender: emv@math.lsa.umich.edu (Edward Vielmetti) Reply-To: moraes@cs.toronto.edu (Mark Moraes) Followup-To: news.software.b Organization: (none) Lines: 48 Approved: emv@math.lsa.umich.edu (Edward Vielmetti) X-Original-Newsgroups: news.software.b Archive-name: awf/06-Sep-90 Original-posting-by: moraes@cs.toronto.edu (Mark Moraes) Original-subject: Re: cnews expire takes forever Archive-site: cs.toronto.edu [128.100.1.65] Archive-directory: /pub Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) In news.software.b you write: >Needless to say, I will force myself to reformat ALL of the docs and read >them completely before going any farther. (anybody know of a good PD >{n|t}roff that I can get hold of?) Henry made a cryptic mention of awf, written specifically for this purpose. Since it hasn't shown up in comp.sources.unix yet, an easier way to grab it might be to snarf pub/awf.shar.Z by anonymous ftp from cs.toronto.edu. Here's awf.README. Perhaps some kind soul from osu-cis or uunet will put it there for people without Internet access. Alternatively, try the ftp by mail service offered by bitftp@pucc.princeton.edu (send a message saying "help") If you have GNU C++ (g++), you may want to grab groff instead and get it working. It'll probably run a tad faster. On the other hand, awf is smaller. Mark. ---------- This is awf, the Amazingly Workable Formatter -- a "nroff -man" or (subset) "nroff -ms" clone written entirely in (old) awk. It is slow and has many restrictions, but does a decent job on most manual pages and simple -ms documents, and isn't subject to AT&T's brain-damaged licensing that denies many System V users any text formatter at all. It is also a text formatter that is simple enough to be tinkered with, for people who want to experiment. Type "make r" to run a regression test, formatting the manual page (awf.1) and comparing it to a preformatted copy (awf.1.out). Type "make install" to install it. Pathnames may need changing. I don't know whether awf will run on 16-bit machines. Data requirements are modest, but I fear the programs are probably big enough to run awk out of space. I can't believe I really wrote this. Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry 13 July 1990   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09244; 13 Sep 90 1:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09183; 13 Sep 90 0:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09128; 13 Sep 90 0:38 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04934; 13 Sep 90 0:27 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20914; Wed, 12 Sep 90 20:41:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 02:50:53 GMT From: david pratt Organization: Naval Postgraduate School, Monterey CA Subject: Unknown error codes Message-Id: <1378@mira.cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Good Morning to all! I hope you had a better weekend then I did. My code (4 threads on an Iris 4D/120 GTX running 3.3) gives me the following errors: Bus Error MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK MP Bus Error Register 0 (Read Address): 0x17300004 MP Bus Error Register 1: 0xA4FEB0 Bus Error MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK MP Bus Error Register 0 (Read Address): 0x17302608 MP Bus Error Register 1: 0x1FBFEB0 Bus Error MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK MP Bus Error Register 0 (Read Address): 0x17300004 MP Bus Error Register 1: 0x78FEB0 If it is a case of RTFM, please tell me what FM. I have tried to find the errors to no avail. Any help would be greatfully accepted. -- Dave Pratt pratt@cs.nps.navy.mil (408) 646-2865 If the meek shall inherit the earth, I'm SOL! These are my opinions, who knows what the Navy thinks.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09244; 13 Sep 90 1:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab09183; 13 Sep 90 0:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab09128; 13 Sep 90 0:38 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04936; 13 Sep 90 0:27 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21043; Wed, 12 Sep 90 20:43:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 02:33:40 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: Imaginary PIs [ clarification; desired i/o features ] Message-Id: <1990Sep10.023340.19858@odin.corp.sgi.com> References: <1411@contex.UUCP>, <3330@dftsrv.gsfc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <3330@dftsrv.gsfc.nasa.gov> buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) writes: | In article <1411@contex.UUCP> frank@contex.UUCP (Frank Perdicaro) writes: | >A Modest Proposal | ... | >Proposed Configuration 3. | > Very minor sheet metal modification make it possible to run a full height | >drive in the top slot of a 4D 25. Make these modifications and place a drive | >there. Cut the existing SCSI cable in half, and have the top-slot drive | >serve the secondary cpu. This still provides for SCSI expansion in one cpu, | >but provides two independent cpu in one box. | I apparently missed this when originally posted. The top slot in the current PI can be used for either 2 half/high devices, or one full high, so no sheet metal (or other mods) are necessary. Of course, this doesn't do anything for the proposed 2 cpu's in a single chassis! On a related note, there has been some discussion of possibly providing an optional second SCSI bus on some future ESD (low-end) machine, similar to what was recently added on the IO3 board for the high end machines. Is this something that some of you might find useful/desirable? What other i/o features are folks looking for? (Don't bother complaining about pricing, I'm only interested in engineering related features!) Please reply via E-mail to olson@sgi.com, unless you think it is of general interest. I'm only soliciting opinions, not making any promises. I speak only for myself, etc., etc. -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09345; 13 Sep 90 1:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ae09244; 13 Sep 90 1:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab09229; 13 Sep 90 0:55 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04999; 13 Sep 90 0:40 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15488; Wed, 12 Sep 90 19:36:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 90 20:42:36 GMT From: Lennart Lovstrand Organization: Rank Xerox EuroPARC, Cambridge, UK Subject: Re: PD nroff (of sorts) Message-Id: <530@roo.UUCP> References: <1990Sep8.005221.6101@relay.wpd.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep8.005221.6101@relay.wpd.sgi.com> ciemo@bananaPC.wpd.sgi.com (Dave Ciemiewicz) writes: > There have been requests on this alias for PD alternatives for formatting > nroff documents, especially for manual page viewing. A program called awf > [...] You may also want to take a look at James Clark's ``groff'' in the GNU archives at prep.ai.mit.edu. Groff includes an implementation of troff, pic, eqn, tbl, and the man macros and has drivers for Postscript, TeX DVI, and typewriter-like devices. Also included is a modified version of the Berkeley me macros, and an enhanced version of the X11R4 xditview. It requires GNU's g++ 1.37.1 (available at the same location) or any commercial C++ compiler implementing version 2.0 of the C++ language. Works great! --Lennart -- Lennart R _A _ N_ K Rank Xerox EuroPARC, 61 Regent St, Cambridge, UK \/ |_ |_) | | \/ Zany, Sun-4/60 at EuroPARC, SunOS Release 4(0.3c)-3 /\ |_ | \ |_| /\ TOPS-20 Command processor 7(65)-3 [*PRERELEASE*] E u r o P A R C   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11208; 10 Sep 90 11:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10495; 10 Sep 90 11:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa10388; 10 Sep 90 11:08 EDT Received: from relay.cs.net by VGR.BRL.MIL id aa04938; 10 Sep 90 10:58 EDT Received: from relay2.cs.net by RELAY.CS.NET id aj08987; 10 Sep 90 10:58 EDT Received: from gmr.com by RELAY.CS.NET id ar26202; 10 Sep 90 10:55 EDT Date: Mon, 10 Sep 90 09:56 EDT From: JORDAN%gmr.com@relay.cs.net Subject: 1991 Symposium on Interactive 3D Graphics To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <9009101058.aa04938@VGR.BRL.MIL> Has anyone heard about this conference for next year? How did this year's conference work out? Could someone send me registration info to attend in 1991? Theodore P. Mugabi-Jordan 1151 Crooks Road GM Systems Engineering Center Troy, Michigan 48084 (313) 280-6766 Thanking someone in advance   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00421; 10 Sep 90 18:17 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa18447; 10 Sep 90 16:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa18364; 10 Sep 90 16:06 EDT Received: from REMOTE.DCCS.UPENN.EDU by VGR.BRL.MIL id aa06402; 10 Sep 90 15:58 EDT Return-Path: Received: from C.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA29127; Mon, 10 Sep 90 15:58:18 -0400 Message-Id: <9009101958.AA29127@remote.dccs.upenn.edu> Date: Mon, 10 Sep 90 15:58 EST From: "Yates, John H." Subject: 8mm tape media woes To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES Argh!! I ordered 10 Sony 8mm tapes from INMAC, $13 apiece. Catalog misprint I was told, $33 is the real price. They honored the lower price for the 10, but had only 5 in stock, backordered the second 5. Ok, I told them, but I won't buy any more 8mm from INMAC. Ok, they said. The first 5 to come in were: Sony 8mm data cartridge QG-112M. The next 5 to come in were: Sony Video 8 P6-120MP (metal particle tape). When doing backups, I tend to get roughly 295 recoverable errors on some of the tapes of each variety, upon which the system then assumes the end of volume (just gives up?), and asks for another tape. Argh! Not good for an overnight script. The data DOES all fit on one GOOD tape. Questions: Are the two varieties above of high enough quality? What is the best tape to use? Should I suspect a hardware problem? Should I suspect dirty heads? (this drive is almost brand new!) (and how should they be cleaned? I know VCR fanatics on both sides of using head cleaner tapes). Thanks, John yates@c.chem.upenn.edu P.S. If anyone is interested, here is the gist of the bru backup file that I I eventually decided upon. (at least this all made sense once I gave up on the Backup script). It avoids /tmp, and /scr (a whole 1.2 GB disk on our machine), and crossing mounted file system boundaries, i.e. gets all the necessary and none of the unnecessary data. bru8mm : # echo "Starting bru 8mm Backup" date df ps -el # mt -t /dev/rmt/tps0d6nr retension mt -t /dev/rmt/tps0d6nr rewind # echo "bru Backup /" bru -cvmRf /dev/rmt/tps0d6nr / # echo "bru Backup /usr" bru -cvmRf /dev/rmt/tps0d6nr /usr # echo "bru Backup /u0" bru -cvmRf /dev/rmt/tps0d6nr /u0 # echo "bru Backup /u1" bru -cvmRf /dev/rmt/tps0d6nr /u1 # # (etc. through /u7) # echo "Rewind tape." mt -t /dev/rmt/tps0d6nr rewind # echo "List 1st bru backup set (/)" bru -tvf /dev/rmt/tps0d6nr # echo "List 2nd bru backup set (/usr)" bru -tvf /dev/rmt/tps0d6nr # echo "List 3rd bru backup set (/u0)" bru -tvf /dev/rmt/tps0d6nr # echo "List 4th bru backup set (/u1)" bru -tvf /dev/rmt/tps0d6nr # # (etc. through /u7) # mt -t /dev/rmt/tps0d6nr rewind # df ps -el date echo "Done."   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00451; 10 Sep 90 20:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00099; 10 Sep 90 19:29 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00535; 10 Sep 90 19:03 EDT Received: from vms3.macc.wisc.edu by VGR.BRL.MIL id aa07248; 10 Sep 90 18:53 EDT Received: from lax.wisc.edu by WISCMACC.BitNet; Mon, 10 Sep 90 17:52 CDT Received: from VMSmail by lax.wisc.edu; Mon, 10 Sep 90 17:49 CDT Message-Id: <20091017492694@lax.wisc.edu> Date: Mon, 10 Sep 90 17:49 CDT From: SENGER@lax.wisc.edu Subject: PI to Video Projectors To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" I have a PI 4D/25. I would like to hook it up to an ElectroHome video projector we have on campus. The video projector is model ECP-3000. It has an RGB Sunc/10 Pin Module installed in it. I have been led to believe that this should work, but I have had no success so far. The projector seems to be unable to automatically sync to the signal. By manually adjusting the horizontal sync I can obtain two side by side images of the screen but this is not very stable. Any help would be appreciated. steven senger@lax.wisc.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00629; 10 Sep 90 21:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00426; 10 Sep 90 20:26 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00413; 10 Sep 90 20:20 EDT Received: from REMOTE.DCCS.UPENN.EDU by VGR.BRL.MIL id aa07549; 10 Sep 90 20:07 EDT Return-Path: Received: from C.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA01810; Mon, 10 Sep 90 20:07:05 -0400 Message-Id: <9009110007.AA01810@remote.dccs.upenn.edu> Date: Mon, 10 Sep 90 20:06 EST From: "Yates, John H." Subject: vmsbackup problem To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES About a month ago someone sent me vmsbackup. I finally got around to building it on our IRIS 4D/320S (SGI). It built without even any warnings, but when I ran it, I got the following error exit. The command: vmsbackup -tvf /dev/rmt/xmt0d0nr.1600 Gives: Snark: Invalid header block size Volume: TEX Saveset name: TEX.BCK number: 1 It has the save set name correct. Any idea what gives? I made the backup on VMS 4.5 . I see where the test and error message come from, but don't have the time to debug/rewrite it. Thanks, John yates@c.chem.upenn.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ab07865; 12 Sep 90 20:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab07739; 12 Sep 90 19:54 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa07682; 12 Sep 90 19:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04377; 12 Sep 90 19:40 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28076; Wed, 12 Sep 90 16:22:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 19:13:30 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: interfacing an Exabyte to a 4D/25 Message-Id: <1990Sep10.191330.28510@odin.corp.sgi.com> References: <3895@umbc3.UMBC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <3895@umbc3.UMBC.EDU> strow@umbc5.umbc.edu (Dr. Larrabee Strow (PHYS)) writes: | I am trying to hook an Exabyte tape drive up to a SGI 4D/25 running | IRIX 3.2. The tape drive uses address 7. When the system is booted | the power up diags fail with: | | > sc0: Unexpected transfer phase. State=4b Phase=33 | > scsi (0,7,0) transfer aborted (Hardware error) | > Device 7 failed DMA test | > | > Diagnostics failed The problem here is with 'bad' firmware in the Exabyte. The power up diagnostics on the PI execute the senddiag command. The Exabyte does not accept this command, but unlike every other SCSI device I have dealt with, it goes to a message in as soon as it sees the first command byte (well, apparrently the 3rd in your case). The solution is to get the latest rev firmware for the Exabyte, or to suppress teh diagnostic. Try setting the bootmode to C (a capital c) in the PROM monitor. Unless you have very early PROM's, this will suppress most of the SCSI diags at boot time, including the senddiag command. | If I allow the bootup to continue, the system becomes essentially useless, | pandora doesn't load, and I keep getting scsi errors from the hard drive, | number 1. This sounds as though you may have termination problems, as well. Be absolutely sure that none of the internal devices have terminators on them, and if you have any external SCSI devices, only the last one on the cable should be terminated. | The supplier had us try changing dip switch number 2 on the MX board but | the power up diags did not change. Switch 2 is for parity, and should be enabled. Turning on switch 1 will shorten the power-on tests, which has alleviated some problems on some machines (that is the way we ship it for the PI). You should also have switch 3 turned on, to force the Exabyte to disconnect only on a word boundary, otherwise you will get error messages about unaligned DMA. | Hopefully we just need to know the proper switch setting on the MX board - | although the supplier should be able to help here they have no suggestions. I don't think the switch settings are the problem, it sounds more like a cable or termination problem. -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id ab08643; 12 Sep 90 22:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08627; 12 Sep 90 22:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08601; 12 Sep 90 22:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04736; 12 Sep 90 22:26 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13293; Wed, 12 Sep 90 19:11:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 23:44:06 GMT From: Roberto Togneri Organization: Elec Eng, Univ of Western Australia Subject: REPOST - problems with pcnfs Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL About a week ago I posted a news article regarding a problem we are experiencing with running pcnfs and mounting filesystems from our IRISes. I think somebody from Silicon Graphics tried to mail me a reply but there was a bug in our setup which only left a remnant of that mail. This bug has been fixed (I've got replies to another article I posted) so I'll repeat my problem here: Our setup consists of three IRISes running 3.1d and NFS. Connected to these are PC's running PC-NFS 3.0.1. The IRISes are cross-mounted via NFS and the PC's mount each root filesystem of the IRISes on separate drive letters. A peculiar problem has always existed which I don't recall has been mentioned in this newsgroup. The problem occurs when attempting to copy or even do a directory listing of the mounted IRIS filesystems on the PC's. Every now and then the copy command will hang on a particular file. The rcp will sometimes work on this file but will sometimes hang as well. Doing ls or dir of some IRIS directories will also hang. The problem in this case usually seems to be the number of files on the directory; removing a file or creating one solves the problem! Needless to say this also creates problems when using the IRIS printer from PC-NFS. The net print command will hang on some files because they can't be copied to the spool area. Has anybody come across these problems? Another problem which I think has been covered is the incompatibility of NFS between IRISes and Suns. We can mount a Sun filesystem happily enough but the Suns can't mount the IRIS filesystems. The mount program returns a version mismatch diagnostic. Is this correct? Any solutions? Is this problem related to the above problem? Any help in this matter would be greatly appreciated. -- Dr. Roberto Togneri Dept. of EE Engineering ACSnet: robert@swanee.ee.uwa.oz The University of Western Australia INTERnet: robert@swanee.ee.uwa.oz.au   Received: from vmb.brl.mil by VMB.BRL.MIL id ab09401; 13 Sep 90 1:28 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac09345; 13 Sep 90 1:18 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09334; 13 Sep 90 1:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05031; 13 Sep 90 0:53 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25684; Wed, 12 Sep 90 21:38:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 01:47:55 GMT From: Roberto Togneri Organization: Elec Eng, Univ of Western Australia Subject: Re: repost of problems with pcnfs Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Oops it looks like a case of look before you leap. After reposting the article on problems with PC-NFS I discovered to my embarrassment that I did get an answer from Jack Weldon (jweldon@csd.sgi.com) Regarding the comment on the line printer problem. Yes it is true that pcnfsd.c assumes that one is running Suns lpr program but I found that this was easily fixed by changing the references in the code to lp and removing some of the options. This hasn't caused any problems other than copying files to the spooler which I don't think is dependent on pcnfsd.c, or is it? Thanks for the information on mounting filesystems and the hanging issue. The former is a just an inconvenience while the latter is more serious. I'm happy to see that the bug has been fixed in versions 3.2 and above. -- Dr. Roberto Togneri Dept. of EE Engineering ACSnet: robert@swanee.ee.uwa.oz The University of Western Australia INTERnet: robert@swanee.ee.uwa.oz.au   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09783; 13 Sep 90 2:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09690; 13 Sep 90 2:17 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09642; 13 Sep 90 2:04 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05189; 13 Sep 90 1:51 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01375; Wed, 12 Sep 90 22:39:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 01:49:32 GMT From: usenet news poster Organization: National Library of Medicine, Bethesda, Md. Subject: Wanted: RGB to PICT conversion utility Message-Id: <1990Sep11.014932.8930@nlm.nih.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have a program to convert SGI color image files to the standard Macintosh Color Quickdraw format (PICT 2)? I would like to be able to move color images from SGIs into Macintosh drawing programs for annotation and recording on Mac high resolution film recorders. Seems like a task others might have encountered. Has anyone written a program to do deal with it (on either the SGI or the Mac)? Many thanks in advance David States   Received: from vmb.brl.mil by VMB.BRL.MIL id ac09783; 13 Sep 90 2:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09752; 13 Sep 90 2:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09717; 13 Sep 90 2:16 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05250; 13 Sep 90 2:08 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03557; Wed, 12 Sep 90 23:04:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 05:14:33 GMT From: Steve Lamont Organization: Foo Bar Brewers Cooperative Subject: Possible C compiler bug? Message-Id: <1379@cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm having a problem with a piece of C code on a 4D/70GT under 3.2. I have declared a variable as float (actually Coord but they're effectively the same). I pass it as a parameter to a function foo() and foo() passes it as a pointer to function bar(). When bar gets the float and dereferences the pointer, it finds a bogus value. It seems what C is doing is promoting the variable to a double even though it is declared as a float. Some investigation reveals that floats and doubles are constructed differently, with 8 bits for exponent and (I think) sign for floats and 12 bits for doubles. Clearly, referencing a double aliased as a float is a bad thing. The following test code shows the problem: ---------------------------------8<----------------------------------------- #include main() { float x = 123.345; foo( &x, x ); exit( 0 ); } foo( a, b ) float *a; float b; { /* * *a and b should be the same. */ fprintf( stderr, "foo: %f %f\n", *a, b ); /* * Now call with b as a pointer and as a value. */ bar( &b, b ); return; } bar( a, b ) float *a; float b; { /* * *a and b should be the same. On our 4D they ain't. */ fprintf( stderr, "bar: %f %f\n", *a, b ); return; } ------------------------------------8<--------------------------------------- Here's what the SillyG returns: foo: 123.345001 123.345001 bar: 3.481816 123.345001 and here's what a BSD VAX 11/785 sez: foo: 123.345001 123.345001 bar: 123.345001 123.345001 I've looked through K&R (2nd Edition) and can't find anything that specifically bears upon this problem in the sections on type coersion. Am I doing something wrong? spl (the p stands for perplexed over precision) -- Steve Lamont, SciViGuy -- (408) 646-2752 (subject to change at random) NPS Confuser Center / Code 51 / Naval Postgraduate School / Monterey, CA 93940 "You're okay," said Honeysuckle. "The dogs like you." - Charles Bukowski, "How to Get Published"   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09848; 13 Sep 90 2:53 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab09783; 13 Sep 90 2:43 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab09770; 13 Sep 90 2:30 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05285; 13 Sep 90 2:22 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04581; Wed, 12 Sep 90 23:14:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 14:55:16 GMT From: ZUCCOLA Organization: Georgia Institute of Technology Subject: FastPath/Gator Box and CAP Message-Id: <13497@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have recently replace our Kinetics FastPath box with a Cayman gator box. Our CAP software for printing no longer works. Does anyone know of anything similar to CAP that runs under the Gator box, so we can print from the unix machines to our apple laserwriters on the local talk network? I've crossed posted this in a number of places hoping for an answer. I know there is something called GatorPrint but I don't know if this works like CAP did? If anyone has any experience or suggestions, can e-mail me directly at zuccola@max.gatech.edu. Thanx in advance, H----   Received: from vmb.brl.mil by VMB.BRL.MIL id ac10114; 13 Sep 90 3:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10016; 13 Sep 90 3:22 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09946; 13 Sep 90 3:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05349; 13 Sep 90 2:54 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07593; Wed, 12 Sep 90 23:48:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 00:11:21 GMT From: Jim Bennett Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NeWS can't find host information for "cinnamon" Message-Id: <1990Sep11.001121.4449@odin.corp.sgi.com> References: <2356@idunno.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2356@idunno.Princeton.EDU> sullivan@math.Princeton.EDU (John M. Sullivan) writes: >I was trying to put a new Iris on our network, and copied a bunch of >files over from one of our other machines to get yp set up right, etc. >yp does now seem to work, but somehow I broke NeWS. > >If I log in on the console now (without NOGRAPHICS), I get a message >(too quickly to read it) about the window server dying with status 1. >If I run /bin/news_server by hand, it says: >NeWS can't find host information for "cinnamon" There was a problem in 3.2 that had these symptoms. Check in the the directory /usr/etc/yp for a file called "resolv.conf" (spelling?). If it exists, delete it and reboot. The NeWS server should now come up. This problem is fixed in 3.3. Jim Bennett (bennett@esd.sgi.com)   Received: from vmb.brl.mil by VMB.BRL.MIL id ad10114; 13 Sep 90 3:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab10016; 13 Sep 90 3:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab09946; 13 Sep 90 3:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05351; 13 Sep 90 2:55 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07857; Wed, 12 Sep 90 23:51:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 16:09:50 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: Unknown error codes Message-Id: <1990Sep10.160950.25311@odin.corp.sgi.com> References: <1378@mira.cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1378@mira.cs.nps.navy.mil>, pratt@mira.cs.nps.navy.mil (david pratt) writes: > Good Morning to all! > > I hope you had a better weekend then I did. My code (4 threads on an > Iris 4D/120 GTX running 3.3) gives me the following errors: > > Bus Error > MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK > MP Bus Error Register 0 (Read Address): 0x17300004 > MP Bus Error Register 1: 0xA4FEB0 > > Bus Error > MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK > MP Bus Error Register 0 (Read Address): 0x17302608 > MP Bus Error Register 1: 0x1FBFEB0 > > Bus Error > MP Status Register: 0x580:id 0 FP MP Bus Error:IOEACK > MP Bus Error Register 0 (Read Address): 0x17300004 > MP Bus Error Register 1: 0x78FEB0 > > > No, there is no TFM here - this is alas a bug in 3.3 to do with large shared address processes - the exact conditions under which this ocurrs is diffucult to explain - but a fix is in an upcoming maintenance release - please contact your local rep for details. Basically if a large ( > 7 distinct address spaces of < 2MB each) process shrinks its space - by either sbrk(-xx) or be detaching say a mapped file this problem can result. In this example each part of your program - text, data, stack, graphics pipe, new_server shd mem, mapped files, etc. count as a 'distinct space'. SO for a 4 thread process linking with shared gl and shared libc: text, data, stack1, stack2, stack3. stack4, gltext, gldada, libctest, libcdata grpipe, gr shdmem - will be your spaces (clearly > 7) As long as you don;t shrink any of them, I believe you will not get into any problems. Note: there is NOTHING wrong with your hardware, etc. it is completely a software generated problem.. Chris Wagner   Received: from vmb.brl.mil by VMB.BRL.MIL id aa10224; 13 Sep 90 3:48 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10114; 13 Sep 90 3:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa10043; 13 Sep 90 3:22 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05395; 13 Sep 90 3:11 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08823; Thu, 13 Sep 90 00:00:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 16:49:22 GMT From: "Dr. Larrabee Strow (PHYS" MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Organization: University of Maryland, Baltimore County Subject: interfacing an Exabyte to a 4D/25 Message-Id: <3895@umbc3.UMBC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am trying to hook an Exabyte tape drive up to a SGI 4D/25 running IRIX 3.2. The tape drive uses address 7. When the system is booted the power up diags fail with: > sc0: Unexpected transfer phase. State=4b Phase=33 > scsi (0,7,0) transfer aborted (Hardware error) > Device 7 failed DMA test > > Diagnostics failed etc ... If I allow the bootup to continue, the system becomes essentially useless, pandora doesn't load, and I keep getting scsi errors from the hard drive, number 1. The supplier had us try changing dip switch number 2 on the MX board but the power up diags did not change. We then hooked up the drive to a DECstation 3100 and had no power up problems. The DECstation recognized the exabyte as an exabyte, etc., although we could not try the drive out since the kernel wasn't set-up to drive it. Hopefully we just need to know the proper switch setting on the MX board - although the supplier should be able to help here they have no suggestions. L. Larrabee Strow | Department of Physics strow@umbc3.umbc.edu | UMBC, Baltimore, MD 21228   Received: from vmb.brl.mil by VMB.BRL.MIL id ab10224; 13 Sep 90 3:48 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab10114; 13 Sep 90 3:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab10043; 13 Sep 90 3:22 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05397; 13 Sep 90 3:12 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08443; Wed, 12 Sep 90 23:57:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 16:33:35 GMT From: "David B.Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Possible C compiler bug? Message-Id: <68879@sgi.sgi.com> References: <1379@cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1379@cs.nps.navy.mil>, spl@cs.nps.navy.mil (Steve Lamont) writes: > I'm having a problem with a piece of C code on a 4D/70GT under 3.2. I have > declared a variable as float (actually Coord but they're effectively the [stuff deleted] > The following test code shows the problem: [stuff deleted] > > foo( a, b ) > float *a; > float b; > { [stuff deleted] > bar( &b, b ); > return; > } [stuff deleted] > I've looked through K&R (2nd Edition) and can't find anything that > specifically bears upon this problem in the sections on type coersion. Am I > doing something wrong? Since this re-appears periodically, I'll respond on the net. Perhaps this topic should be in Frequently Asked Questions on comp.lang.c. K&R1: b is a double, not a float. K&R 1, page 205: ``formal parameters declared float have their declaration adjusted to read double.'' This means the type-rewriting that ccom is doing (the float b is taken internally as if it were written double b) is justified, since 3.2 and 3.3 cc are not ANSI C (and this function is not written in prototype form). ANSI C is quite different: ANSI C, 3.7.1: ``On entry to the function the value of each argument expression shall be converted to the type of its corresponding parameter, as if by assignment to the parameter.'' So the code would work as written in ANSI C. There's a discussion in the ANSI C Rationale, section 3.7.1. Finally, K&R address the change specifically: K&R2, Sec A 10.1, page 226: ``...the first edition specified that the declarations of float parameters were adjusted to read double. The difference becomes noticeable when a pointer to a parameter is gnnerated within a function.'' Summary: There is no bug in cc here. K&R1 and ANSI C differ. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] PS: Many thanks to Doug Gwyn, Henry Spencer, and a few others for their answers on this and other C questions. Responsibility for any mistakes in this posting is mine, of course, not theirs......   Received: from vmb.brl.mil by VMB.BRL.MIL id aa10466; 13 Sep 90 4:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa10415; 13 Sep 90 4:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa10359; 13 Sep 90 4:01 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05505; 13 Sep 90 3:50 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11424; Thu, 13 Sep 90 00:22:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 01:15:45 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: 8mm tape media woes Message-Id: <1990Sep11.011545.5546@odin.corp.sgi.com> References: <9009101958.AA29127@remote.dccs.upenn.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <9009101958.AA29127@remote.dccs.upenn.edu> YATES@C.CHEM.UPENN.EDU ("Yates, John H.") writes: | Argh!! I ordered 10 Sony 8mm tapes from INMAC, $13 apiece. Catalog | misprint I was told, $33 is the real price. They honored the lower | price for the 10, but had only 5 in stock, backordered the second 5. | Ok, I told them, but I won't buy any more 8mm from INMAC. Ok, they said. | | The first 5 to come in were: Sony 8mm data cartridge QG-112M. | The next 5 to come in were: Sony Video 8 P6-120MP (metal particle tape). | | When doing backups, I tend to get roughly 295 recoverable errors on some | of the tapes of each variety, upon which the system then assumes the end of | volume (just gives up?), and asks for another tape. Argh! Not good for an | overnight script. The data DOES all fit on one GOOD tape. | | Questions: | Are the two varieties above of high enough quality? | What is the best tape to use? | Should I suspect a hardware problem? | Should I suspect dirty heads? (this drive is almost brand new!) | (and how should they be cleaned? I know VCR fanatics on both | sides of using head cleaner tapes). | Our Exabyte rep has STRONGLY recommended that you do NOT use MP (metal particle) tape on the Exabyte drives. You will get far more errors than you should. The Q6-112M sounds like it is the same tape that Exabyte sells (I'm not positive), EXCEPT that the official ones sold by both Exabyte and Sony are Data grade. This means that they have been cerified as reasonably error free, and are otherwise pretty much the same as the commercial grade. If you choose not to use Data grade tapes, you are on your own. They may (and in fact do) work fine most of the time, but you can't count on it. When bru (or other tape programs) give up and ask for a new tape, it is usually because they have encountered an unrecoverable error. There should be a message to this effect on your console and/or in SYSLOG. -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id ac10466; 13 Sep 90 4:28 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab10415; 13 Sep 90 4:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab10359; 13 Sep 90 4:01 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05510; 13 Sep 90 3:51 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12832; Thu, 13 Sep 90 00:38:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 90 18:08:43 GMT From: Todd Tenenholz Organization: University of Maryland Subject: Re: NeWS can't find host information for "cinnamon" Message-Id: <1990Sep10.180843.27534@murdoch.acc.Virginia.EDU> References: <2356@idunno.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2356@idunno.Princeton.EDU> sullivan@math.Princeton.EDU (John M. Sullivan) writes: >I was trying to put a new Iris on our network, and copied a bunch of >files over from one of our other machines to get yp set up right, etc. >yp does now seem to work, but somehow I broke NeWS. > >If I log in on the console now (without NOGRAPHICS), I get a message >(too quickly to read it) about the window server dying with status 1. >If I run /bin/news_server by hand, it says: >NeWS can't find host information for "cinnamon" About 4 mos. ago, I had a similar problem when I tried to get my 120/GTX hooked up to a domain nameserver (We don't run yp). The console would crash with the error "Network protection violation". SGI informed me that IRIX 3.1x has a bug that does not allow the window system to start if the query for localhost does not come back 127.0.0.0. I know you have this set, but it may still be worth looking into. Hope this helps. -- Todd Tenenholz, Molecular Graphics Facility, U. Md. at Batimore. Internet: todd@sg.ab.umd.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ad10466; 13 Sep 90 4:28 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac10415; 13 Sep 90 4:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa10369; 13 Sep 90 4:01 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05518; 13 Sep 90 3:58 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13316; Thu, 13 Sep 90 00:43:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 02:02:42 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NeWS can't find host information for "cinnamon" Message-Id: <68975@sgi.sgi.com> References: <2356@idunno.Princeton.EDU>, <1990Sep11.001121.4449@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep11.001121.4449@odin.corp.sgi.com> bennett@sgi.com (Jim Bennett) writes: >In article <2356@idunno.Princeton.EDU> sullivan@math.Princeton.EDU (John M. Sullivan) writes: > >>I was trying to put a new Iris on our network, and copied a bunch of >>files over from one of our other machines to get yp set up right, etc. >>yp does now seem to work, but somehow I broke NeWS. >> >>If I log in on the console now (without NOGRAPHICS), I get a message >>(too quickly to read it) about the window server dying with status 1. >>If I run /bin/news_server by hand, it says: >>NeWS can't find host information for "cinnamon" > >There was a problem in 3.2 that had these symptoms. Check in the >the directory /usr/etc/yp for a file called "resolv.conf" (spelling?). It's /usr/etc/resolv.conf. >If it exists, delete it and reboot. The NeWS server should now come up. Of course, if you delete it, NeWS and every other network application will resolve hostnames from /etc/hosts (assuming YP/NIS isn't running). (NeWS doesn't use YP.) >This problem is fixed in 3.3. IRIX 3.3 is much more robust when there are name server problems.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01692; 11 Sep 90 13:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac01146; 11 Sep 90 13:42 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ac01051; 11 Sep 90 13:27 EDT Received: from ames.arc.nasa.gov by VGR.BRL.MIL id aa14098; 11 Sep 90 12:38 EDT Received: from [128.157.59.129] by ames.arc.nasa.gov (5.64/1.2); Tue, 11 Sep 90 09:38:59 -0700 Received: by erin.jsc.nasa.gov (5.52/) id AA20925; Tue, 11 Sep 90 11:37:39 CDT Date: Tue, 11 Sep 90 11:37:39 CDT From: John Fwu Message-Id: <9009111637.AA20925@erin.jsc.nasa.gov> To: info-iris@BRL.MIL Subject: Polygonal Model for Human Skull Cc: john@erin.jsc.nasa.gov We are in need of a polygonal model of a human skull. The model needs to be constructed with a minimum number of polygons since the application requires near-real-time manipulation of the skull. We have CT and MRI scan data and algorithms for generating polygonal models from this data however the number of polygons generated is too large for this application. Please contact me or Mark Voss - NASA/JSC Computer Graphics Lab 713-483-8102 or 713-488-5700 -- ----------------------------------------------------------------------------- | J. John Fwu | Internet: fwu@mpad.span.nasa.gov | | Barrios Tech. | SPANnet: MPAD::FWU | | NASA JSC, ER4/BARR | TEXnet: UTADNX::UTSPAN::MPAD::FWU | | Houston, TX 77058 | Voice: (713) 483-8101 | -----------------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa02030; 11 Sep 90 14:14 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01146; 11 Sep 90 13:39 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa00990; 11 Sep 90 13:25 EDT Received: from MCC.COM by VGR.BRL.MIL id aa10148; 11 Sep 90 10:36 EDT Received: from banach.aca.mcc.com by MCC.COM with TCP/SMTP; Tue 11 Sep 90 09:36:58-CDT Posted-Date: Tue, 11 Sep 90 09:36:51 -0500 Message-Id: <9009111436.AA09719@banach.aca.mcc.com> Received: from localhost by banach.aca.mcc.com (4.0/ACAv4.1i) id AA09719; Tue, 11 Sep 90 09:36:53 CDT To: info-iris@BRL.MIL Subject: Bash for 4D/25 Date: Tue, 11 Sep 90 09:36:51 -0500 From: nong@mcc.com I have trouble in getting GNU's Bash to compiled on 4D/25 running 3.3 Has anyone got it to work. I would appreciate any advice/tips/help. Thanks, ------------- Nong Tarlton Microelectronics and Computer Technology Corporation nong@mcc.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00278; 11 Sep 90 16:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03239; 11 Sep 90 15:12 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03212; 11 Sep 90 15:04 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa15753; 11 Sep 90 14:52 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0701; Tue, 11 Sep 90 14:51:10 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Tue, 11 Sep 90 14:52 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA02235; Tue, 11 Sep 90 14:55:00 DSD Date: Tue, 11 Sep 90 14:55:00 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: Can't reply directly, so here goes : To: info-iris@BRL.MIL Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009112155.AA02235@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil Subject: Re: Polygonal Model for Human Skull To: John Fwu (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00476; 11 Sep 90 22:48 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac00376; 11 Sep 90 22:38 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id al00166; 11 Sep 90 22:25 EDT Received: from pucc.Princeton.EDU by VGR.BRL.MIL id aa17027; 11 Sep 90 19:43 EDT Received: from OHSTPHRM.PHARMACY.OHIO-STATE.EDU by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5356; Tue, 11 Sep 90 19:40:46 EDT Received: from OHSTPHRM (FOWBLE) by OHSTPHRM.PHARMACY.OHIO-STATE.EDU (Mailer R2.03B) with BSMTP id 2580; Tue, 11 Sep 90 19:43:06 EST Date: Tue, 11 Sep 90 18:39:54 EST From: Jack Fowble Organization: Ohio State University College of Pharmacy Subject: Quick QIC question To: info-iris@BRL.MIL Message-ID: <9009111943.aa17027@VGR.BRL.MIL> The bottom line question first: If I write on a DC600A cartridge using vendor A's stated 60MB drive unit and adapter, what's the likelihood that I can get an intelligible(?) byte stream into my 4D70GT (with the Cipher 540S 60 MB unit), say using 'dd'? (I'd expect we'd have to play with byte ordering, data formats, etc.; but would we get past blatant low level I/O errors/incompatabilities?) More specificly, Archive has a PC tape unit they call Fastape (60MB) (not the Viper 150) that uses DC600A. Users would like to pull spectra and image data sets from those tapes to the SGI. More generally: Haven't had a good go-round about tape formats and "standards" since last May on this list ;-), at which time I shrugged and thought how lucky I was not to have to think about such madness! Sigh. :-( Looking around here, I find QIC-24 units (seem to do 60MB), QIC-02 units that are also described as QIC-24 (signal interface versus data format???), QIC-150 (150MB) that are also described as QIC-02. The archives of this list also introduced QIC-120 & QIC-11 "standards" (whatever MB). The Fastape unit mentioned above was suggested to me to be of a QIC-36 persuasion. Catalogs indicate QIC-40, -60, -80, and -100 that seem to cross back and forth between standard and mini cartridges. So, WHO writes all these "standards"? Where are such "standards" documented? Anybody already sort all of this out, maybe have some sort of a master reference list? Or does one call in a QIC con$ultant? (As an aside, I even noted a mail order ad describing a flavor of mini cartridge (DC2000) adhering to the "QIC-2000" standard. Oh, come ON now...) In the QIC-sand, Jack   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00586; 11 Sep 90 23:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab00376; 11 Sep 90 22:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ah00166; 11 Sep 90 22:25 EDT Received: from east.gsfc.nasa.gov by VGR.BRL.MIL id aa16879; 11 Sep 90 18:53 EDT Received: from ASTRO.DECnet MAIL11D_V3 by east.gsfc.nasa.gov (5.57/Ultrix2.4-C) id AA06737; Tue, 11 Sep 90 11:56:27 EDT Date: Tue, 11 Sep 90 11:56:26 EDT Message-Id: <9009111556.AA06737@east.gsfc.nasa.gov> From: vargas@astro.dnet.nasa.gov To: "info-iris@brl.mil"@6913.dnet.nasa.gov Subject: Driver Needed I have installed MOVIE.BYU on a CONVEX 210. The only drivers I have is for a Tektronix 4110 and a 4115. We are also running MOVIE on the Irises 4D/25, 3000, 3130, and a 210. I would like a driver for the Irises to put on the CONVEX. Brigham Young does not have a driver for the Irises, and have no plans right now to write a driver for the Irises. Has anyone written one? e-mail or give me a call. thanks, Steve Vargas LOCKHEED/NASA JSC Houston Texas (713) 333-7329 Voice VARGAS%ASTRO.SPAN@STAR.STANFORD.EDU FTS 525-3945   Received: from vmb.brl.mil by VMB.BRL.MIL id ae00660; 11 Sep 90 23:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00376; 11 Sep 90 22:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ag00166; 11 Sep 90 22:24 EDT Received: from REMOTE.DCCS.UPENN.EDU by VGR.BRL.MIL id aa16742; 11 Sep 90 17:58 EDT Return-Path: Received: from C.CHEM.UPENN.EDU by remote.dccs.upenn.edu id AA12162; Tue, 11 Sep 90 16:17:31 -0400 Message-Id: <9009112017.AA12162@remote.dccs.upenn.edu> Date: Tue, 11 Sep 90 16:17 EST From: "Yates, John H." Subject: vmsbackup (again) To: info-iris@BRL.MIL X-Vms-To: INFIRIS,YATES I still have not yet been able to get vmsbackup to work on our 4D/320S IRIX 3.3 . I re-supplied the code that was sent to me to a few interested users, if anyone has gotten it to work please let me know. (if so please let me know what level VMS the tape was written on, and what level IRIX it was read on. This may be very important.) If anybody wants it and has time to play with it, let me know and I will send it to you. Review of problem I see: I made a short 1600 bpi backup tape on a VAX/VMS machine VMS4.5 . vmsbackup builds with no errors or warnings, but when I: vmsbackup -tvf /dev/rmt/xmt0d0nr.1600 I get: Snark: Invalid header block size Volume: TEX Saveset name: TEX.BCK number: 1 It does have the save set name correct. Thanks, John yates@c.chem.upenn.edu P.S. SGI, are you listening? This could be a great tool for making sites with dozens of VMS save set backups on the shelf totally independent of VMS machines, without a major marathon tape media conversion effort.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa08643; 12 Sep 90 22:57 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa08591; 12 Sep 90 22:33 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa08574; 12 Sep 90 22:24 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04710; 12 Sep 90 22:09 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12613; Wed, 12 Sep 90 19:03:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 19:42:00 GMT From: "Louis M. McDonald" Organization: The Aerospace Corporation, El Segundo, CA Subject: XBitmaps on PI Message-Id: <85248@aerospace.AERO.ORG> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are in the process of write a program that mixes X and GL together. We are running it under 3.2.x using 4Sight as the window manager. In one X display we are using X bitmaps. On the personal iris, when the cursor goes over them they appear okay. On our 80, when the cursor goes over them, they disappear. The bitmaps are tied to buttons so they are suppose to be highlighted by making the box they are in thicker. The buttons still work, but on the 80, the bitmap does not reappear. If I run twm, the buttons are okay on the 80. Any ideas? -- Louis McDonald Internet: louis@aerospace.aero.org The Aerospace Corporation 213-336-8914   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09345; 13 Sep 90 1:15 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad09244; 13 Sep 90 1:05 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09229; 13 Sep 90 0:55 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04997; 13 Sep 90 0:40 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16342; Wed, 12 Sep 90 19:45:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 17:08:55 GMT From: Kathy Kuba Organization: Hewlett Packard -- Fort Collins, CO Subject: Re: GL Lighting POSITION Message-Id: <17450007@hpfcdj.HP.COM> References: <17450005@hpfcdj.HP.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Probably the most common problem encountered with lighting is that light > positions are transformed by the current ModelView matrix when the light is > bound (i.e. when lmbind(LIGHTn,foo) is called). As a result you must be > very careful about what ModelView matrix is present when a light is bound. > In releases previous to 3.3, the ModelView matrix was undefined until it was > first loaded (typically with an identity matrix). In release 3.3, the > ModelView matrix is initialized to identity when mmode(MVIEWING) is first > called (putting the GL into multimatrix mode, required for lighting and many > other advanced GL features). It is likely that some error has been made in > the matrix/lmbind sequence, and that this error is affected by the differences > between the 3.2 and 3.3 software releases. > thanks for the pointer! it ended up being a sequence error: i was specifying my ortho before my mmode. rearranging these on 3.3 fixed the problem, and adding an additional loadmatrix(identity) solved it on 3.2. my 3.2 code also runs fine on 3.3. thanks again. kathy   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11387; 13 Sep 90 6:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11294; 13 Sep 90 6:26 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11275; 13 Sep 90 6:19 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05772; 13 Sep 90 6:07 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26014; Thu, 13 Sep 90 02:56:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 14:38:27 GMT From: Rob Hooft Organization: University of Utrecht, Dept. of Physics Subject: Benchmarking the SGI: Floating point faster than integer? Message-Id: <1464@ruunsa.fys.ruu.nl> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, As I am planning to buy a PC, I am benchmarking all computers available to me. On our PI this resulted in a 'pleasant' surprise: Floating point multiplications are about twice as fast as integer multiplications. Is there anybody that can explain the results of the following session to me? Rob Hooft, Chemistry department University of Utrecht, The Netherlands -----CUT HERE--------------------------------------------------------------- cia:[101]:hooft>cat test.f program test integer i real a,f,g integer ia,if,ig f=28.0 g=36.0 if=28 ig=36 t=cputime(0.0) do 100 i=1,3000000 100 ia=if*ig write(*,*) cputime(t) t=cputime(0.0) do 200 i=1,3000000 200 a=f*g write(*,*) cputime(t) t=cputime(0.0) do 300 i=1,3000000 300 continue write(*,*) cputime(t) end function cputime(f) real g(2) call etime(g) cputime=g(1)+g(2)-f return end cia:[102]:hooft>f77 -O0 -o test test.f cia:[103]:hooft>test 6.340000 4.200000 2.070000 12.5u 0.1s 0:15 82% cia:[104]:hooft>^D -----CUT HERE--------------------------------------------------------------- -- ------------------------------------------------------------------------ This is my brand new signature ========================================= ------------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11496; 13 Sep 90 6:51 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab11387; 13 Sep 90 6:40 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11337; 13 Sep 90 6:30 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05792; 13 Sep 90 6:16 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27063; Thu, 13 Sep 90 03:07:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 16:00:32 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu!bruggink@ucsd.edu Subject: re: rgb -> PICT Message-Id: <4364@dogie.macc.wisc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >Subject: Wanted: RGB to PICT conversion utility >Reply-To: states@tech.nlm.nih.gov () > >Does anyone have a program to convert SGI color image files to the >standard Macintosh Color Quickdraw format (PICT 2)? > >David States I use a Macintosh utility called "PICTure This" (cost <$100) which will convert many image formats to PICT files (e.g. TARGA, TIFF, GIF, Sun Raster). On the Silicon Graphics, use "togif" [FTP from site 129.173.18.107] to get a GIF file from the RGB, download that to the Mac, and convert to PICT using PICTure This. [I had to uuencode/decode the GIFs for transfer; PICTure This sometimes had problems w/ binary-downloaded GIFs.] --dennis bruggink bruggink@ccc.nersc.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11644; 13 Sep 90 7:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab11496; 13 Sep 90 6:54 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11449; 13 Sep 90 6:44 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05830; 13 Sep 90 6:37 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29147; Thu, 13 Sep 90 03:29:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 16:10:30 GMT From: Dave Carek Organization: NASA/Lewis Research Center, Cleveland Subject: Keyboard bell on 4D210 Message-Id: <1990Sep11.161030.8805@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there any way to adjust the volume off the keyboard bell/beeper on a 4D/210 other than cottonballs and tape? -- ----------------------------------------------------------------------- | David Carek | phone: 216-433-8396 | | NASA Lewis Research Center | | | Cleveland, Ohio 44135 | email: eddc@opus.lerc.nasa.gov | |---------------------------------------------------------------------| | Engineer -> An innovative imaginative scientist who must design the | | improbable using the impossible on a budget that is invisible | -----------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id ab11644; 13 Sep 90 7:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac11496; 13 Sep 90 6:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab11449; 13 Sep 90 6:44 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05832; 13 Sep 90 6:38 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29049; Thu, 13 Sep 90 03:28:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 14:55:12 GMT From: Dave Carek Organization: NASA/Lewis Research Center, Cleveland Subject: VT100 emulator/Xterm keymappings Message-Id: <1990Sep11.145512.8586@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anybody know of a good public domain vt100 emulator. I tried using the wsh with the -v option but it doesn't seem to refresh the screen properly when using the edt editor on a VAX. I also tried using the Xterm vt102, which is nice, but I couldn't find a Gold Key for the life of me and I couldn't figure out how to map one in. I tried reading the man pages for X and xterm but I just got more confused. Any info on the above problems would be greatly appreciated. I'm currently running the 3.3 OS Thanks in advance. -- ----------------------------------------------------------------------- | David Carek | phone: 216-433-8396 | | NASA Lewis Research Center | | | Cleveland, Ohio 44135 | email: eddc@opus.lerc.nasa.gov | |---------------------------------------------------------------------| | Engineer -> An innovative imaginative scientist who must design the | | improbable using the impossible on a budget that is invisible | -----------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa11883; 13 Sep 90 7:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11726; 13 Sep 90 7:20 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11694; 13 Sep 90 7:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05856; 13 Sep 90 6:55 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01179; Thu, 13 Sep 90 03:51:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 17:53:56 GMT From: "Lawrence R. Rogers" Subject: Re: xterm Message-Id: <2408@idunno.Princeton.EDU> References: <1990Aug30.094905@anusf.anu.edu.au>, <1990Aug30.201212.9948@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL -- OK - I have IRIX 3.3.1 and am trying to get the supplied xterm to talk to my R4 server, but it simply doesn't do anything. The xclock worked fine as do many other programs in /usr/bin/X11, but not good ol' xterm. Thanks for your help. Larry Rogers ----------------------------------------------------------------------------- | Internet: lrr@Princeton.EDU Manager, UNIX Systems | | UUCP: princeton!lrr Princeton University | | BITNET: lrr@PUCC.BITNET Computing and Information Technology| | PHONE: 609 258 6483 Computing Center | | Alternate: 609 258 6000 87 Prospect Street, Room 201 | | FAX: 609 258 3943 Princeton, NJ 08544 | -----------------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id ab11883; 13 Sep 90 7:30 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab11726; 13 Sep 90 7:20 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab11694; 13 Sep 90 7:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05858; 13 Sep 90 6:55 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00954; Thu, 13 Sep 90 03:48:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 17:56:15 GMT From: Bron Campbell Nelson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Benchmarking the SGI: Floating point faster than integer? Message-Id: <69040@sgi.sgi.com> References: <1464@ruunsa.fys.ruu.nl> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1464@ruunsa.fys.ruu.nl>, chooft@ruunsa.fys.ruu.nl (Rob Hooft) writes: > As I am planning to buy a PC, I am benchmarking all computers available to > me. On our PI this resulted in a 'pleasant' surprise: Floating point > multiplications are about twice as fast as integer multiplications. Is there > anybody that can explain the results of the following session to me? [session deleted] The explaination is simple: on the MIPS R2000 and R3000 cpus, floating point multiplication *IS* about twice as fast as integer multiplication (actually, a bit more than twice as fast). The ratio for division is even greater. My understanding is that MIPS decided to throw a lot of silicon at the floating point problem, while they found that the majority of integer multiplies in "real" programs involved a constant term, and so could be done with shifts and adds. Thus, less silicon was thrown at the integer multiply problem (and even less at the integer divide). -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron These statements are my own, not those of Silicon Graphics.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12334; 13 Sep 90 8:05 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa11987; 13 Sep 90 7:44 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa11949; 13 Sep 90 7:34 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05915; 13 Sep 90 7:21 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03012; Thu, 13 Sep 90 04:11:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 90 19:03:22 GMT From: randy frank Organization: University of Iowa, Image Analysis Facility Subject: new user .cshrc file question Message-Id: <2308@ns-mx.uiowa.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello, Question: when using the graphical system administration tools where do the .cshrc and .login files come from for a new user? Under the old adm scripts they came from /etc/stdlogin and /etc/stdcshrc. It seems that the graphical tools take this info from the /etc/cshrc file and the /etc/stdlogin file. I have a special accounting program which is launched by the /etc/cshrc file and it got copied into a new user's .cshrc file where it launched itself and proceeded to run .cshrc and launch itself which ran .cshrc and so on until the process table filled up. The accounting program keeps track of graphics head login time as opposed to normal login time so I can bill extra for sitting in the pretty seat. (Neat hang, took at least 10 min to figure out what script was spawning itself and another 10 to find out why.) So if the graphical tools copy /etc/cshrc how can I make them copy /etc/stdcshrc instead (like the old adduser script does)?? Thanks... -- rjf. Randy Frank, Engineer | (319) 335-6712 University of Iowa, Image Analysis Facility | 73 EMRB randy@tessa.iaf.uiowa.edu | Iowa City, IA 52242   Received: from vmb.brl.mil by VMB.BRL.MIL id aa01177; 12 Sep 90 1:22 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa00945; 12 Sep 90 0:30 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa00908; 12 Sep 90 0:12 EDT Date: Wed, 12 Sep 90 0:04:57 EDT From: Phil Dykstra To: Jack Fowble cc: info-iris@BRL.MIL Subject: Re: Quick QIC question Message-ID: <9009120004.aa24283@SPARK.BRL.MIL> There are QIC numbers that refer to many things, not just the recording format, but also the interfaces, read/write heads, ECC and Data Compression standards, etc. Don't worry about QIC-02 for example, it is an interface standard. The major recording formats you will see now are: Recording Format Cartridge Type Capacity Read Compatibility QIC-24 DC600A 60MB QIC-120 DC6150 125MB QIC-24 QIC-150 DC6150 150MB QIC-120/QIC-24 (or a longer tape) DC6250 250MB A DC600A cartridge, written in the QIC-24 format, should be readable on any QIC-24, 120, or 150 drive. There may however be the issue of byte swapping (fixable with either dd conv=swab or the SGI "ns" device). Ignore QIC-40, 80, 100, 110, 128, and 380. I believe that these all use a physically slightly smaller cartridge (I don't know who uses them). In fact these cartridges all have numbers in the DC2000's which you mentioned seeing. Long ago, Sun used to use QIC-11 by default (a lower density format even than QIC-24) and /dev/rst8 would get you QIC-24. QIC-11 is now old enough that it no longer appears on my cheat sheet. And the one other QIC number you asked about: QIC-36 is the Basic Interface standard for QIC-24 format drives. No doubt it is all designed to confuse the consumers. - Phil   Received: from vmb.brl.mil by VMB.BRL.MIL id aa00092; 12 Sep 90 14:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01322; 12 Sep 90 1:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01311; 12 Sep 90 1:48 EDT Received: from uunet.UU.NET by VGR.BRL.MIL id aa17879; 12 Sep 90 1:37 EDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA02421; Wed, 12 Sep 90 01:37:54 -0400 Received: by opal.STC.LOCKHEED.COM (4.0/1.76); Tue, 11 Sep 90 23:48:35 CDT Received: from arthur.msd.lmsc.lockheed.com by sacha.msd.lmsc.lockheed.com (4.1/Ultrix3.0-C_mdc) id AA03046; Tue, 11 Sep 90 21:50:08 PDT Received: by arthur.msd.lmsc.lockheed.com (4.1/SMI-4.1_mdc) id AA06097; Tue, 11 Sep 90 21:46:58 PDT Date: Tue, 11 Sep 90 21:46:58 PDT From: Dave Cunningham Message-Id: <9009120446.AA06097@arthur.msd.lmsc.lockheed.com> To: info-iris@BRL.MIL Subject: Sun/SGI boot interference I'm being told by another site at my company that my Irises are causing problems that prevent thier diskless suns from booting. The suns apparently loose track of what YP domain they are part of somewhere during the boot process and hang. Folks at the other site believe, based on some past experience that I haven't been able to get a detailed report on, that the problem is a bug in the Iris's bootparamd. Has anyone else out there experienced this ? Configuration details are: Suns running SunOs 4.0.3, Irises 3.2.1 Both sites on a single (bridged) ethernet Irises are diskfull, suns are diskless clients and a sun server Both sites run nfs and yp; different yp (ooops, nis) domains The fix I'm being asked to apply is to comment out the bootparamd and bootp lines in my inetd.conf files on the Irises. I don't boot the irises diskless, but I do install software across the net; I believe that bootp, at least, is necessary to get sash running. If anyone has any pertinent info or experience I'd appreciate a note. Thanks in advance, Dave Cunningham cunning@arthur.msd.lmsc.lockheed.com Lockheed Missiles and Space Co. O/81-10, B/157-5E, (408)-756-1382 #include   Received: from vmb.brl.mil by VMB.BRL.MIL id ab02742; 12 Sep 90 15:13 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02276; 12 Sep 90 15:08 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab01527; 12 Sep 90 14:53 EDT Received: from pucc.Princeton.EDU by VGR.BRL.MIL id aa01241; 12 Sep 90 11:58 EDT Received: from UKACRL.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6361; Wed, 12 Sep 90 11:56:14 EDT Received: from RL.IB by UKACRL.BITNET (Mailer R2.03B) with BSMTP id 4872; Wed, 12 Sep 90 16:31:36 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.03B) with BSMTP id 4685; Wed, 12 Sep 90 16:31:35 BST Via: UK.AC.OX.VAX; 12 SEP 90 16:31:31 BST Date: Wed, 12 SEP 90 16:31:33 GMT From: HCART%VAX.OXFORD.AC.UK@pucc.princeton.edu To: INFO-IRIS@BRL.MIL Subject: Tek 4200 emulation on a 3130? Message-ID: <9009121158.aa01241@VGR.BRL.MIL> Attached to our departmental ethernet we have, amongst other machines, a few suns, some of which run uniras. I would like to use my 3130 to access a sun, emulating a tektronix 4200 series terminal or similar. Can it be done? If so, how? Hugh Cartwright. [Physical Chemistry, Oxford University.]   Received: from vmb.brl.mil by VMB.BRL.MIL id aa04511; 12 Sep 90 15:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa04409; 12 Sep 90 15:56 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa04324; 12 Sep 90 15:48 EDT Date: Wed, 12 Sep 90 15:45:22 EDT From: Phil Dykstra To: Dave Cunningham cc: info-iris@BRL.MIL Subject: Re: Sun/SGI boot interference Message-ID: <9009121545.aa28298@SPARK.BRL.MIL> We have experienced the "Sun booting problem" as well. Many versions of bootparamd answer requests even if they have no file systems for the requesting machine. This causes a race condition where a SunOS 4.x machine will try to mount file systems from the first machine to answer its broadcast bootparam request. We commented out bootparm in /usr/etc/inetd.conf on all of our SGI's. All versions of Irix 3.2 seem to have this problem [as well as some other computers like the TI Lisp Machines]. Irix 3.3 may have fixed it - I don't know. We did not have to do anything involving bootp. - Phil   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05086; 12 Sep 90 16:20 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa04797; 12 Sep 90 16:10 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa04620; 12 Sep 90 15:59 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa03189; 12 Sep 90 15:48 EDT Received: Wed, 12 Sep 90 15:48:45 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 12 Sep 90 15:48:45 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009121848.AA04897@aero4.larc.nasa.gov> To: HCART%VAX.OXFORD.AC.UK@pucc.princeton.edu Subject: Re: Tek 4200 emulation on a 3130? Cc: info-iris@BRL.MIL Try the command wsiris, it is documented. This will let you emulate a tektronix terminal. I have used it through a serial port, but haven't gotten it to work over the ethernet. It does an ok job. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id ab05086; 12 Sep 90 16:21 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab04797; 12 Sep 90 16:10 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa04635; 12 Sep 90 16:00 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa03229; 12 Sep 90 15:50 EDT Received: Wed, 12 Sep 90 15:51:23 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 12 Sep 90 15:51:23 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009121851.AA04917@aero4.larc.nasa.gov> To: cunning@arthur.msd.lmsc.lockheed.com Subject: Re: Sun/SGI boot interference Cc: info-iris@BRL.MIL I think I have heard of that bug before, and it is fixed in IRIX 3.3. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa06318; 12 Sep 90 17:17 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa06044; 12 Sep 90 17:06 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa05994; 12 Sep 90 17:01 EDT Date: Wed, 12 Sep 90 17:00:02 EDT From: Phil Dykstra To: info-iris@BRL.MIL Subject: Differential SCSI? Message-ID: <9009121700.aa29209@SPARK.BRL.MIL> We are interested in remoting some SCSI peripherals from an SGI 4D. The normal single-ended-SCSI is only rated to about 20 feet. So called differential-SCSI is good for 80 feet. Does SGI offer differential SCSI? I assume that all of your peripherals need to be configured for differential as well. Has anyone actually tried to put say the QIC and/or 8mm tape units 50+ feet away? - Phil   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09401; 13 Sep 90 1:28 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09118; 13 Sep 90 0:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09106; 13 Sep 90 0:26 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa04926; 13 Sep 90 0:21 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23282; Wed, 12 Sep 90 21:11:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 18:59:37 GMT From: "Louis M. McDonald" Organization: The Aerospace Corporation, El Segundo, CA Subject: Sun Color Raster to file to IRIS format Message-Id: <85326@aerospace.AERO.ORG> References: <69101@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I thought someone posted a Sun Color Raster file conversion once before. I would like to convert the Sun file to a format that "showci" can work with. Louis McDonald -- Louis McDonald Internet: louis@aerospace.aero.org The Aerospace Corporation 213-336-8914   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09618; 13 Sep 90 2:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09545; 13 Sep 90 1:53 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09539; 13 Sep 90 1:49 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05140; 13 Sep 90 1:36 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29936; Wed, 12 Sep 90 22:24:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 90 03:27:56 GMT From: Jean Starkey Organization: Montana State University, Dept. of Microbiology, Bozeman MT 59717 Subject: neurosciences modeling Message-Id: <2414@dali> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know of any programs to do brain tissue level (histological) recontruction/modeling which run on the Iris? I would be very grateful for any information. Jean R. Starkey umbjs@caesar.cs.montana.edu umbjs@mtsunix1.bitnet   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22290; 14 Sep 90 5:27 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa22209; 14 Sep 90 4:30 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22193; 14 Sep 90 4:14 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05349; 14 Sep 90 3:24 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21201; Fri, 14 Sep 90 00:15:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 90 05:59:58 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Filter to convert X window dump images to IRIS images Message-Id: <69101@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The X window system has a utility called xwd that allows the image of a window to be saved in a image format called X window dump (xwd) format. The following program converts an xwd image into a color IRIS image file that can be displayed on an IRIS using "ipaste". paul haeberli paul@sgi.com begin 777 fromxwd M`6``!R;MS/L````````````X``]``@#X``(`"#X(0/@``@````````` M`">]_^"OL``4K[$`&#P1$```@(`AK[\`'(X&```F,0[@/`40`"2E!,P,$!#L M`B`@(3P%$`".!@`$)*4$W`P0$.P"("`A/`40`(X&``@DI03P#!`0[`(@("$\ M!1``C@8`#"2E!00,$!#L`B`@(3P%$`".!@`0C@<`%"2E!1@,$!#L`B`@(3P% M$`".!@`8)*4%+`P0$.P"("`A/`40`(X&`!PDI04X#!`0[`(@("$\!1``C@8` M("2E!4@,$!#L`B`@(3P%$`".!@`D)*4%6`P0$.P"("`A/`40`(X&`"@DI05P M#!`0[`(@("$\!1``C@8`+"2E!8`,$!#L`B`@(3P%$`".!@`P)*4%E`P0$.P" M("`A/`40`(X&`#0DI06H#!`0[`(@("$\!1``C@8`."2E!;P,$!#L`B`@(3P% M$`".!@`\)*4%S`P0$.P"("`A/`40`(X&`$`DI07<#!`0[`(@("$\!1``C@8` M2"2E!>P,$!#L`B`@(3P%$`".!@!,)*4&!`P0$.P"("`A/`40`(X&`%`DI080 M#!`0[`(@("$\!1``C@8`5"2E!B0,$!#L`B`@(3P%$`".!@!8)*4&.`P0$.P" M("`A/`40`(X&`%PDI09(#!`0[`(@("$\!1``C@8`8"2E!E@,$!#L`B`@(8^_ M`!R/L``4C[$`&`/@``@GO0`@)[W_B*^W`"P`H+@AK[X`,*^_`#2OM@`HK[0` M)*^G`(2.X@`$CO8```#`\"$D#@`#KZX`&"0&`0$D!P`#)X6`$*^B`&"OH@`4 M#!`%$*^V`!"/KP!@KZ(`=!G@`$0``*`AK[4`/(^U`(BOL`!,K[$`2*^R`$2O MLP!`&L``'```@"$\$1``/!(0`#P3$``F]`'@GO?[(K[``'`"`@"$J`0`#)`X``:^N`2BOOP`L MK[0`**^S`"2OL0`@%"``!*^E`3P\%!``$```"2:4#N`\%!``)I0.X#P%$``D MI09P#!`0[`*`("$,$`W<)`0``2H!``04(``$`````"0/``$0```"KZ\`3*^@ M`$R/N`$\)X6`%(\$``0,$`WH`````!1```FOH@!0C[D!/#P%$`"/)@`$)*4& MF`P0$.P"@"`A#!`-W"0$``&/IP!0)Z0`K"0%`&0,$!!X)`8``20!``$000`% MDZ@!*#P$$``,$`+J)(0&M).H`2@`````$0``!8^I`$PGI`"L#!`#!B0%`&2/ MJ0!,`````!$@``2/J@"P#!``?">D`*R/J@"P)`$`!Q%!``F/JP"L/`40`"2E M!M@,$!#L`H`@(3P$$``,$`+J)(0'`(^K`*P`````+6$`9!`@``F/L`"L/`40 M`"2E!PP,$!#L`H`@(3P$$``,$`+J)(0',(^P`*P`````)A#_G`P0$10"`"`A M%$``!`!`B"$\!!``#!`"ZB2$!SR/IP!0`B`@(20%``$,$!!X`@`P(1!0``6/ MK`!,/`00``P0`NHDA`=@CZP`3``````1@``'CZ(`^#P%$``DI0>,`H`@(0P0 M$.P"(#`ACZ(`^``````00`"&`$"8(0`3((``DR`C#!`1%``$((`40``$KZ(! M$#P$$``,$`+J)(0'G``3@$`,$!$4`@`@(:^"@/`,$!$4`@`@(:^"@/0,$!$4 M`@`@(8^D`1"/IP!0KX*`^"0%``P,$!!X`F`P(1!3``63K0$H/`00``P0`NHD MA`>XDZT!*``````1H``9`````!I@`!<``!`A`!-P@(^Q`1`!TW`C``YP@*^R M`#```)`AKZX`."8P``0"("`A#!`#!B0%``0"`"`A#!`"^"0%``:/KP`X)E(` M#`)/""HF,0`,%"#_]280``R/L@`P`````!I@`&(``!`A`!/`@`,3P",`&,"` MK[(`,#P0$`"/L0$0)A`'Y```D"&ON``TCB0`````````DP@K%"``"0`````" M@"`A`@`H(0P0$.PF9O__#!`-W"0$``&.)````````)8Y``2/B8#P`(`8(0`# M$$``&4("`2)0(:5(``"/C8#TEBL`!@&B<"$`"V("I*^J`'P0 M```2KZL`@(^O`3R/F8#XC>0`"(^&@/"/AX#TK[,`%">E`%0,$`#\K[D`$!`` M`!*/OP`L/`40`"2E"'`,$!#L`H`@(1````R/OP`L$$#_[X^O`3PD`0`!$$'_ M[(^O`3PD`0`"$$'_Z8^O`3P0`/_Q`````(^_`"R/L``]`3B,C@`()`$``A7!``@`````C(\`,(R8`!0``````?@`&0``$!(0 M```,`````(R9`#",B``,C(H`%`,H`!D``$@2```````````!*@`9```0$@`` M`````````^``"``````GO?_H`(`P(3P$$`"OOP`4/`40`"2E"(@,$!#L)(0. MX`P0#=PD!``!C[\`%">]`!@#X``(``````"%$"$`@@@K$"``"0````"0@P`` MD(X``22$``&@CO__)(0``0""""L4(/_YH(/__P/@``@``````(40(0""""L0 M(``3`````"2#``.090``D(X``"2$``&@;@``H(7__R2&``$`P!@AD&4``)"/ M````````H&\``*"%````P"`A)(0``@""""L4(/_O``````/@``@`````/`(0 M`"1"")R0C@``)*7__P!.>"&1^```)(0``1R@__J@F/__`^``"``````GO?_H M)`H``:^_`!0`@$`A%,H`2`"@2"&/K@`H`````!#.`$6/N``H`0`H(1```#4! M"3`A)`/_\)"B```DI0`!``)Y`@`"R0`#(U@D,?@`#P,+8"4`I@@K%"#_]Z"L M__\0```UC[@`*)"C``"0K0`!)*4``:"M__\DI0`!`*8(*Q0@__F@H___$``` M*X^X`"B0HP`"D*X``"2E``,`I@@KH*/__10@__J@KO__$```(H^X`"@DH@`# MD$,``)"O```DI0`!H$\``*"C__\DI``!`(`0(9!#``"0N0```````*!9``"@ MHP```(`H(22E``(`I@@K%"#_[P`````0```.C[@`*"0!``00X?_*`````"0! M`!`0X?_4`````"0!`!@0X?_;`````"0!`"`0X?_A`````(^X`"@`````%PH` M!8^_`!0!`"`A#!`#'@$@*"&/OP`4)[T`&`/@``@`````)[W_F*^R`!@`@)`A MK[\`)*^T`!ROM0`@KZ8`<(Y.`"0D%``!%=0`5P"@J"&OL``TK[$`,(Y/``B. M1P`8`J_`(0,'`!H`!T##CDL`*(^J`'".3@`0%.```@``````!P`-)`'__Q3A M``0\`8``%P$``@``````!@`-KZ``9(Y'`!@``(@A``>`PR>D`&0``,@2```` M```````#*``9``!($@```````````4L`&0``8!(!+&@A&@``"@'-&"&0;P`` M)C$``0(P""HD8P`!)(0``10@__J@C___CD<`&`````".1@`4`````!#4``4` M````CE@`'``````7%``(`````(Y9`!PGI`!D`@`H(0P0`RFON0`0CD<`&``` M``".2``(C[$`,`*H4"$!1P`:%.```@``````!P`-)`'__Q3A``0\`8``%4$` M`@``````!@`-C[``-```$!```EC#`ZM((9$I`&0P3``'`8EP!C'-``&OK0!D MCD4`+(Y#`"00``#'`````(Y"``P`````%%0`:B0!``*OL``TK[$`,*^S`"RO MH`!DCD,`)(Y0`!@``)@A``"((1A@`%D`$(##CD4`*`````".3P`(CD<`&`*O MP"$#!P`:``=`PX^K`'".30`0%.```@``````!P`-)`'__Q3A``0\`8``%P$` M`@``````!@`-KZ``8">D`&```!`A``#($@```````````R@`&0``4!(````` M``````%E`!D``$@2`4E@(0&3<"$:```(`:X8(9!O```D0@`!`%`(*B1C``$D MA``!%"#_^J"/__^.1@`4`````!#4``4`````CE@`'``````7%``'`````(Y9 M`!R.1P`8)Z0`8`(`*"$,$`,IK[D`$(Y(``B.2@`8`JA8(0%J`!J/N`!D%4`` M`@``````!P`-)`'__Q5!``0\`8``%6$``@``````!@`-`!C(0"8Q``$``!`0 M``)(PP.I8"&1C`!@,$T`!P&L<`8QSP`!`?E`):^H`&2.2P`$CD4`*(Y#`"0` MJP`9`B,(*@``4!(4(/^K`5.8(8Y%`"R/L``TC[$`,(^S`"P0``!:CZ0`9"0! M``(400!*`````*^P`#2OL0`PCDP`*(^I`'".3@`L`2P`&8Y(`!"OH`!@CE`` M+```B"$F$``'!@$``@(`""$D(0`'``&`PP`0@,``$(##)Z0`8```:!(````` M``````*N`!D``,`2`!AXPP&OR"$:```(`1D8(9!K```F,0`!`C`(*B1C``$D MA``!%"#_^J"+__^.2@`4`````!54``@``"`ACD<`+*^@`!`GI`!@`@`H(0P0 M`RDD!@`!```@(201``,GH@!K)Z,`:)!,__@D0O__`$,(*P`$2@`0(/_[`2P@ M):^D`&2.10`L)`$`!!2A``N/L``TCZ0`9#*N``$1P``#`````!````(`!"$" M,(0`#XY%`"ROI`!DC[``-(^Q`#"/I`!D$```"X^D`&0\!!``/`40`"2E!+0, M$!#L)(0.X`P0#=PD!``!CD4`+`````"/I`!DCD,`)`````"/I`!D`````!2C M``4``\"`CZ0`9!````@`@!`A``/`@#P-$``!N&@AC:T$,(^O`&0``````:\0 M)(^_`"2/L@`8C[0`'(^U`"`#X``()[T`:(R/`"B,C@`0`,\`&8R"`"0D`0`( M``#`$@,%R"$!V4`AD0,``!!!``@```````)(@#P*$``!25`AC4H$,``````! M0Q@D,&,`_P/@``@`8!`AC(\`*(R.``@`SP`9`*X0(8R(`!P``LC#)`$``3!" M``<``,`2%0$`!0,9&"$D"0"``$DH!Q````0PI0#_)`H``0!**`0PI0#_C(L` M$``````!8V`AD8T````````!I7`D$<``!```&"$0```")`,``0``&"$#X``( M`&`0(2>]_^BOOP`4C(X`#"0!``(5P0`)`````(R/`"PD`0`(%>$`!0`````, M$`2Z`````!```!&/OP`4C)@`)"0!``$7`0`*`````(R9`!2,B``<`````!]`!@#X``(```` M````````````)[W_V*^E`"ROI@`P`.`8(8^N`#B/KP`\C[@`0*^D`"B/I0`H MCZ<`,(^F`"ROOP`D```@(:^C`!"OK@`4KZ\`&`P0!3JON``]`"@# MX``(`````">]_]BOI@`P`.`8(8^N`#B/KP`\C[@`0*^E`"R/I@`LCZ<`,*^_ M`"0``"@AKZ,`$*^N`!2OKP`8#!`%.J^X`!R/OP`D)[T`*`/@``@`````)[W_ MV*^_`!2OI``H)`0`F*^P`!"OI0`LKZ8`,`P0$12OIP`T`$"`(0!`("$,$!)( M)`4`F(^N`#``````D<\``0`````Y^``K+Q@``1,```:ON``@/`00``P0!N(D MA`F@$``!-P``$"&/N0`P)`$`=Y,H````````%0$`6(^K`"R/HP`L`````!!@ M`!2/J@`H`&`@(0P0$G`D!0&VCZD`(*^B`"@1(``+CZ,`+`1```F/HP`LCZ0` M*`P0$G@`````CZ0`+`P0$H`D!0`"KZ(`*(^C`"P`````CZH`*``````%00`( MCZ(`.#P$$``DA`G(#!`&X@!@*"$0``$1```0(8^B`#@D"P':I@L``(^L`#0D M`P`!I@P``H^M`#PL00`"I@,`"J8#``@4(``$I@T`!H^N`$``````I@X`""Q! M``,4(``$`````(^O`$0`````I@\`"I88``H`````%P,`""0)``.6"``()!D` M`A4#``6F&0`$$````Z8#``0D"0`#I@D`!#P*`)@U2I:`K@H`#*X``!`"`"`A M#!`)L">%@""N```4I@``P0``#;```0(8^K`"P`````$6``#8^M`"B/K``@`````!&` M``0``"@A$````B0%``(``"@ACZ0`+`P0$H``````KZ(`*(^M`"@`````!:$` M!(^D`"@0``#&```0(8^D`"@"`"@A#!`2D"0&`)@D`0"8$$$`!@`````\!!`` M#!`&XB2$"A00``"Z```0(98%```D`0':,*\`_P`/P@``!7("`=C()1/JP`X````````5P0`8`````)88``B6&0`* M```P(0,9`!D``"@2&*``1P```````!`A``4@@"0#__^."`"0``````$"2"&M M(```C@H`E``````!0E@A)$(`!`!$""H4(/_VK6,``!```#BF``!ZE@P`")8- M``J/I``H`8T`&20%`@```#`A``!X$@`/<(`,$!*8KZX`'(^D`"B.!0"0CZ8` M'`P0$I``````CZ8`'``````01@`&`````#P$$``,$`;B)(0*@!```#<``!`A MAA@`<@`````3```'CZ0`*(X$`)`,$`:W`,`H(8^F`!P`````CZ0`*(X%`)0, M$!*0`````(^Y`!P`````$%D`!@`````\!!``#!`&XB2$"J00```A```0(88( M`'(`````$0``!0````".!`"4CZ4`'`P0!K<`````I@``>JX``'RN``"`#!`& MC@(`("$40``'K@(`A#P$$`"6!0`&#!`&XB2$"L@0```,```0(8^D`"@D"0(` MK@D`B*8``'2F``!VI@``>"0%`@```#`A#!`2F*X$`&P"`!`AC[\`%(^P`!`# MX``()[T`*">]_^BOOP`4`(`8(91B``8```````)Q@@'"("$,$!$4``0@@(^_ M`!0GO0`8`^``"```````!'H",?C_```$=@(`!$(`/`$`_P$!2"0!V,@E`RE0 M)0`$7@`#X``(`4L0)0`%$$,`@#`A&$``#```&"&4Q```)&,``0`#'````QP# M``1R`@`$>@`!S\`E`&((*J38```4(/_V),8``@/@``@```````40@P"`,"$8 M0``4```8(3P'`/\``W"``,XH(8RD```D8P`!``3"`C,9_P``!'X"``1*``$G M4"0!^4`E``,<```#'`,!"E@E``1F``%L:"4`8@@J%"#_[ZRM```#X``(```` M`">]_^BOI``8CZ0`&*^_`!0,$`:F)`4`#(^D`!@D!0`,#!`&MR2$``R/I``8 M)`4`!`P0!K]`!@#X``(`````(^.@+`GO??@K[\`'`"`&"$` MH$`A`,!((1'```\`X%`ACZ\(,">D`"``8"@A`0`P(0$@."&OJ@`0#!`2+*^O M`!2/F("P)Z0`(`,`^`D`````$```#8^_`!R/N0@P/`00`"2$#N``8"@A`0`P M(0$@."&OJ@`0#!`0[*^Y`!0,$`W<)`0``8^_`!PGO0@@`^``"``````#X``( MKX2`L````````````````">]_\BOL``8`("`(:^_`!R6#@!P`*!0(3'/`((` MP&`A%>```P#@6"$0``$K)`+__Y8"``0`````+$$``Q`@``,L00`"``!8(2Q! M``(0(``"````````8"&6`P`"`````#!B_P`40`"")`$!`!```'C`!@`````$$,``P`````0```])`+__XX$`(2/I@`L M)`4``0P0#.,D!P`"E@(`!A```#:/OP`4#!`*E`(`("$``E0```I<`P`"'``D M`?__%6$``P`#'`,0```K)`+__XX%`(2GHP`8`@`@(0P0"FD`8#`AAZ,`&``` M```08@`#`````!```"`D`O__A@P`<@`````1@``$`````(X$`(0,$`:F`&`H M(8X$`(2/I@`L)`4``@P0#.,D!P`"E@(`!A```!*/OP`4/`00``P0!N(DA`M( M$```#8^_`!0D`0`!$*'_N``````D`0`"$*'_T@`````0`/_T`````#P$$``, M$`;B)(0+7(^_`!2/L``0`^``"">]`"@GO?_@K[``$`"`@"&OOP`4#!`)AP(` M("$"`"`A#!`*?P``*"&6#@!P`````#'/``(1X`!1`````(88`'(`````$P`` M!`(`("$,$`;0`@`@(0(`("$"`"@A#!`*4R0&`)@D`0"8$$$`!@`````\!!`` M#!`&XB2$"X`0``!<)`+__X89`'(`````$R```P`````,$`;0`@`@(98(``(D M`0$`,0G_`!4A`#0``````@`@(0P0"G\D!0(`E@H`")8+``H``````4L`&0`` M8!(`#&B`KZT`'(8.`'(`````$<``!`````".!`"0#!`&MP&@*"&.!0"0CZ8` M'`P0"E,"`"`ACZ8`'``````01@`&`````#P$$``,$`;B)(0+J!```#,D`O__ MA@\`<@`````1X``&`````(X$`)0,$`:W`,`H(8^F`!P`````C@4`E`P0"E," M`"`AC[@`'``````06``&`````#P$$``,$`;B)(0+S!```!XD`O__C@0`@``` M```0@``$``````P0$=D`````K@``@(X$`(0`````$(``!``````,$!'9```` M`*X``(26&0`")`$!`#,H_P`5`0`(`````(X$`)`,$!'9`````(X$`)0,$!'9 MK@``D*X``)2.!`!L#!`2>`````"/OP`4C[``$`/@``@GO0`@)[W_Z*^_`!24 MC@!P`````#'/``(1X``=C[\`%(R%`(``````$*``&8^_`!2,F`!\``````,% MR",'(0`"`R`((20A``$``4!#&0``$(^_`!2$A@!VA(<`>`P0!PROI``8CZ0` M&`````"4B0`&`````!!)``:/OP`4E(H`<"0"__\U2P`@I(L`<(^_`!0GO0`8 M`^``"``````````````````````GO?_HK[\`%`"`&"$D9``8#!`2H"0&`%"/ MOP`4)[T`&`/@``@``````^``"*R%`&@GO?_HK[\`%`"@."$`X"@AKZ<`'*^D M`!@,$`I$KZ8`((^D`!B/I@`@CZ<`'!!```8`````/`00``P0!N(DA`OP$``` M/OP`4E(X`!C!X`/\`[@`9``!X$@```````````?@`&0``*!(, M$`I_)*4"`!```%N/OP`4E((`!I2(``@`P@`9,&P`_P``R!(```````````,H M`!D``$@2````````````X@`9``!0$@%)6"$``````6P`&0``*!(,$`I_)*4" M`!```$:/OP`4/`00``P0!N(DA`P4$```08^_`!0D`0`!$$'_U``````D`0`" M$$'_U0`````D`0`#$$'_W@`````0`/_Q`````"0!`0`400`O`````)2"``00 M```B)`$``8R-`)``````C:4```P0"G\`````$```*8^_`!2,C@"0``=X@`'/ MP"&/!0``#!`*?P`````0```AC[\`%)2(``B,F0"0`,@`&0``4!(!1T@A``E8 M@`,K8"&-A0``#!`*?P`````0```5C[\`%#P$$``,$`;B)(0,+!```!"/OP`4 M)`$``1!!_]X`````)`$``A!!_^(`````)`$``Q!!_^<`````$`#_\0`````\ M!!``#!`&XB2$#$2/OP`4)[T`&`/@``@`````E(X`"```````K@@K$"``!@`` M``"4CP`*``````#/""L4(``$```0(1````(D`@`!```0(0/@``@`````)[W_ MZ*^_`!0`@!@AC&0`;*^F`"`,$!*(KZ,`&(^F`""/HP`8%$8`!@!`("&,;@"( M``````'&>"$0```#K&\`B"08__^L>`"(C[\`%">]`!@#X``(`(`0(2>]_^BO MOP`4`(`8(8QD`&ROI@`@#!`2D*^C`!B/I@`@CZ,`&!1&``8`0"`AC&X`B``` M```!QG@A$````ZQO`(@D&/__K'@`B(^_`!0GO0`8`^``"`"`$"$GO?_HK[\` M%`"`&"&,;@"(`````!'%``@`H!`AC&0`;*QE`(@,$!*8```P(1````./OP`4 M`*`0(8^_`!0GO0`8`^``"`````````````````````"4@@`$$```&B0!``&, MC@"4`````(W"```0```=`````(28`':,CP"4`!C(@`'Y0"&-`@``$```%@`` M``"$B0!XE(H`"(2,`'8!*@`9C)@`E```6!(!;&@A``UP@`,.>"&-X@``$``` M"@`````D`0`!$$'_Y@`````D`0`"$$'_Z``````D`0`#$$'_[``````#X``( M`````">]_^``P$`AKZ<`+(^F`"ROOP`4KZ4`)`$`*"&OJ``H#!`*1*^D`""/ MI``@CZ8`)(^H`"@40``WC[\`%)2"``00```<)`$``8R.`(R,CP"0C(4`E!`` M`"&M[@``C)@`E(R)`)``"!"`C)D`C`$B4"$#`B@A$```&:U9``"/JP`LE(P` M"(R.`)0!;``9C)@`D(R/`(P``&@2`:@8(0`#$(`#`D@A`<(H(1````RM+P`` M)`$``1!!_^0`````)`$``A!!_^8`````)`$``Q!!_^R/JP`LCZ4`'`````", MH@``)`'__Q!!``4`````C)D`%``````#(E`AK(H`%*RF``",BP",``````%F M8"&LC`",C[\`%">]`"`#X``(`````">]_^@D`@`!K[\`%!2B`&T`P$@A%.(` M:P````"/K@`H`(`X(0".0"$`B`@K$"``80$@*"$`X"`A).<``@#H""L0(``7 M`````)#B__^0[__^`````!7B``4`````D/@````````06``.`````"3G``$` MZ`@K$"``"@````"0XO__D/G__@`````7(O_X`````)#J````````%$K_]``` M```DY__^`.0P(Q#``!P`````*,$`?Q0@``0`!AP`$````R0#`'X`!AP```,< M`S1K`(``8!`A`,,P(R1C__\``QP```,<`Z"K```00``*)*4``0!@$"&0C``` M)&/__P`#'````QP#)(0``22E``$40/_XH*S__Q3`_^+_^0``````Y#`C$,``$`#H""L`8!`A*,$`?Q0@``0` M!AP`$````R0#`'X`!AP```,<`P##,".DHP``)*4``B2E``(4P/_TI*+__@#H M""L4(/^B`.`@(22E``(`J1`C!$$``@!`""$D(0`!``$00Q```/BDH/_^%*,` M=@`````4X@!T`````(^X`"@`@#@A`!C(0`"90"$`B`@K$"``:0$@*"$`X"`A M).<`!`#H""L0(``7`````)3B__Z4ZO_\`````!5"``4`````E.L````````0 M2P`.`````"3G``(`Z`@K$"``"@````"4XO_^E.S__``````5@O_X`````)3M M````````%$W_]``````DY__\`.0P(P3!``(`P`@A)"$``0`!,$,0P``<```` M`"C!`'\4(``$``8<`!````,D`P!^``8<```#'`,T;@"``&`0(0##,",D8___ M``,<```#'`.@K@``$$``"B2E``$`8!`AE(\``"1C__\``QP```,<`R2$``(D MI0`!%$#_^*"O__\4P/_G*,$`?P#@("$DYP`"`.@(*X3C__X0(``.`.0P(Y3X M````8!`A%P(`"@#D,",DYP`"`.@(*Q`@``8`Y#`CE/D````````3(O_Y```` M``#D,",$P0`"`,`((20A``$``3!#$,``$`#H""L`8!`A*,$`?Q0@``0`!AP` M$````R0#`'X`!AP```,<`P##,".@HP``)*4``22E``$4P/_TH*+__P#H""L4 M(/^:`.`@(22E``$`J1`C$```@:"@__\4HP!Z`````!3C`'@`````CZH`*`"` M."$`"EA``(M`(0"(""L0(`!I`2`H(0#@("$DYP`$`.@(*Q`@`!<`````E.+_ M_I3L__P`````%8(`!0````"4[0```````!!-``X`````).<``@#H""L0(``* M`````)3B__Z4[O_\`````!7"__@`````E.\````````43__T`````"3G__P` MY#`C!,$``@#`""$D(0`!``$P0Q#``!P`````*,$`?Q0@``0`!AP`$````R0# M`'X`!AP```,<`S1X`(``8!`A`,,P(R1C__\``QP```,<`Z2X```00``*)*4` M`@!@$"&4F0``)&/__P`#'````QP#)(0``B2E``(40/_XI+G__A3`_^``"`````"3F(`P`````!,```,`````$```(P``$"$G@X`T M/`40`"2E#K"C@(`P)Z0"*`P0$OROHP*HCZ,"J">D`C8,$!+\`&`H(2>D`B@, M$!*````H(01``!$`0"`A)Z4`)B0&`@(,$!*0KZ0`("0!`@(400`(CZ0`(#P$ M$``DA`R@)Z4`)@P0$R@D!@("KZ``'(^D`"`,$!)X`````(^B`!P`````C[\` M%">]`J@#X``(```````````GO?_HK[\`%`P0#G"OI``8CZ0`&`P0$_`````` MC[\`%">]`!@#X``(```````````GO?_HK[\`%*^D`!@,$!/TKZ4`'(^D`!B/ MI0`<#!`.!0!`,"&/OP`4)[T`&`/@``@`````)[W_Z*^D`!BOI@`@CZ0`(*^_ M`!0,$`Z-KZ4`'(^D`!B/I0`]`!@#X``(```` M`">]_^``P!@AK[\`%!!@``<`H$`A$(``!0````"0C@```````!7```,````` M$```6```$"&1!P`!D0(``#CG`"L0```7+.<``1#@``0D`@`!$````B0"``(D M`@`!$```&S1%`P`0X``$)`(``1````(D`@`")`(``1```!0T10$($.```P`` M```0```0)`4``A````X``"@A$```/0``$"$D`0!A$$'_[P`````D`0!R$$'_ M\P`````D`0!W$$'_X@`````0`/_T`````"0&`;:OHP`HKZ<`'`P0$H"OJ``D MCZ,`*(^G`!R/J``D!$$``P!`("$0```F```0(:Q@```0X``$H&(`#20/`(`0 M```)H&\`#)$8```D`0!R%P$`!"0"``(0```")`(``20"``*@8@`,D1D``"0! M`&$7(0`,`````!3@``H````````H(20&``(,$!*8KZ,`*(^C`"@$00`#```` M`!````D``!`AD&D`#3P!$```"5"``"H((:Q@``2L8``(K"`5``!@$"&/OP`4 M)[T`(`/@``@`````````````````````/`(0`(^.@$`D0@[`)[W_Z*^P`!`` M3@@K`$"`(1`@`!&OOP`4/`\0`(WO%[``````$>``!0`````,$`Z^`@`@(1`` M``,`````#!`.C0(`("&/F(!`)A``$`(8""L4(/_Q`````(^_`!2/L``0`^`` M"">]`!@GO?_@K[``$`"`@"&OOP`4%@```R0#__\0```F)`+__Y("``P````` M,$X`@Q'``!4P60`(,$\`!!'@``,`````$```!```&"$,$`Z^`@`@(0!`&"&2 M!``-#!`2>*^C`!R/HP`]`!@GO?^XK[``%`"@@"&OOP`DK[(`'*^S`""O ML0`8KZ0`2)(#``PD$0!")!,``B02``8P;@!2%=$`(C!J`!:2#P`-/!D0```/ MP(`#.,@ACSD5`(X"``0``````%D(*Q`@`$P`````DZ,`2R0!``J@0P``C@@` M!``````E"0`!$&$`!*X)``23H@!+$```8(^_`"0,$`]_`@`@(20!__\400`$ MDZ,`2Q````,D`___DZ,`2P`````0``!4`&`0(3!J`!854@`4,&X`$I.K`$LG MI0!'HZL`1Y($``VN````#!`2B"0&``$D`0`!%$$`!`````"3H@!+$```18^_ M`"22#``,)`+__S6-`"`0```_H@T`##!N`!(5TP`0`````(X"``@`````$$`` M#`````".#P`$`````!7B``P`````CA@````````7```(`````#!Y`$07(``& M```8(0P0#\@"`"`A$````@!`&"$``!@A$&```P`````0```D)`+__Y(#``P` M````,&(`1!1`_ZHP;@!2#!`/?P(`("&.`@```````"1"__\$00`&K@(``).D M`$L,$`[V`@`H(1````J2"P`,DZ(`2XX(``0`````H0(``(X)``0`````)2H` M`:X*``22"P`,`````#%L`"`1@``$DZ,`2Q````,D`___DZ,`2P``````8!`A MC[\`)(^P`!2/L0`8C[(`'(^S`"`#X``()[T`2">]_^"OOP`4`(`8(8QE``B, M;@`$`*`X(0''>".OKP`8D'@`#*QG``0S&0!$$R``"`````"0:``-/`H0`"5* M%0``"$B``2HP(1````JL8```D&L`#3P-$``EK14```M@@`&-,"&,S@`````` M``'%$".L8@``C&0````````$@0`$`(`0(1````(``!`A`(`0(8S/``",>``$ M``````'XR",#(@@J$"``"8^H`!@`8"`AKZ,`(`P0$&*OIP`]`!@#X``(`````">]_^`` M@!@AK[\`%)!N``R090`-,<\`!!'@``P`H#`A/!D0`20`-C&\`"#P!$``UK@`(`!E`@``H""&@;@`,)?@@`!`` M``RL.!4`/`L0`9!L``TE:[J0``9(P`$K$"$\`1````QH@``M""&L8@`()$H` M"*PJ%0",;@`(`,`@(:QN``0,$!0,KZ,`((^C`"`00``)C[\`%)!B``P````` M,$\`!!7@``2/OP`4-%D`0*!Y``R/OP`4)[T`(`/@``@`````D(X`#3P#$``` M#GB``&\8(8QC%0",F``$``````!X$",$00`#`````!````>L@P`$C)D````` M````60@J$"```@````"L@@```^``"````````````````">]_[BOI@!0CZX` M4*^S`!BOL``4`."`(0"`F"&OOP`<'<```Z^E`$P0``!B```0(8^O`%"/N`!, MK[(`+`'X`!D``)`2`D\(*Q0@``0``````E@(*Q`@``0`````C[(`+!```%0` M`!`AK[4`(*^Q`"BOM``D/!40`(X#```FM14`)!3__QQ@`!P`8!`A#!`4(`(` M("$45``0`````(^Y`$R/JP!0`EE`(24)__\!.0`;C[(`+(^Q`"B/M``DC[4` M(!<@``(```````<`#0``4!(0```X`6H0(XX.``".#``$)<\``:X/``".`P`` M)8W__ZX-``0`8!`A`D((*XX%``00(``$`$"((1````("0(@A`$"((0)@("$, M$!,H`B`P(8X8``"."0`$`Q%`(ZX(``".`P```3'((:X9``0$80`#`%&8(1`` M``(``!`A`&`0(9(+``V.#@`$``M0@`*J8"&-C0````````&N>",!X@@J$"`` M`P`````,$!!B`@`@(0)1D",60``(`````(^B`%"/L0`HC[(`+(^T`"2/M0`@ M$```!8^_`!R.`P``$`#_M0````"/OP```!``````T6``"$````Z#8``P0```0)`+__P!@("$GI0`@#!`5 M.*^F`!B/I@`8`````)#9``P`````,R@`(!$```0`0!@A$````B0#__\`0!@A M`&`0(8^_`!0GO0`8`^``"````````````````">]_\B/CH#`K[<`+```N"&O MO@`PK[\`-*^V`"BOM``@K[4`)*^R`!BOLP`6@,`VV``!`L`P(31/``&OCX#`KX:`R*^8@,2O@H#,`$`H M(8^&@,@DDP`'/!Y__S?>X```$YB")!7__@#`B"$``)`ACB,`````````8!`A M,%D``1<@`!T"((`A`&"`(8X"````$R"`,$@``14```X``````B`P(:^&@,@4 ML``"KB(```(@*"&.(P````````!@@"&.`@```````#!)``$1(/_V``````(D M$"$"`@@K%"``!```````40@K$"``90``````8!`A`B"`(0!5B"0"$0@K%"#_ MVP````"/BH#,`````!(*``,`````$```!*^%@-02-@`%)E(``:^%@-00``!F M```0(292``$N00`"%"#_S```````H(@A```@(0P0&>2OA8#4CXN`S`!`@"$E M;``$$8(`"P`````F<@?_`!*2PC!#``,08``2`!*30"0-``0!H[@C`%>`(1`` M``T"5Y`ACX6`U(^.@,P``````<5X(P7A``(!X`@A)"$``P`!P(,">)`C)E(( M```2DL(`$I-``A+((0,P""L0(``$`]((*Q```#T``!`A`]((*Q`@``H"0*`A M/`1__PP0&>0TA.``)`'__Q1!``0"7I`C$```,@``$"$"7I`C#!`9Y`)`("$D M`?__%$$`!0`````,$!GQ`@`@(1```"@``!`ACXB`S`*72",""5`AK1```"5+ M__RN"P``CXR`S`(`*"$EC0`$$;``!3;"``&-C@```````#7/``&MCP``CA@` M``````"OF(#,CYF`S!``_WRO(@```$`P(0#0""L0(``&-,D``8S(```````` MKXB`T*S#```TR0`!$+$`!*XI``"OAH#($```!*^%@-0`P"@AKX6`U*^&@,@F M(@`$C[\`-(^P`!"/L0`4C[(`&(^S`!R/M``@C[4`)(^V`"B/MP`LC[X`,`/@ M``@GO0`X)(+__*^"@,B,3@``)`'__@'!>"2L3P``CYF`S(Q8````````%QD` M`@````"O@H#4`^``"``````GO?_0K[``$`"`@"&OOP`4KZ4`-(X"__P````` M,$X``1'```8`4!@C#!`1V0(`("&.`O_\``````!0&",$80`"`&`((20A``,` M`1B#CZ0`-`P0$12OHP`(``3Q@A`'`(*Q0@``H````` M`'#((P]`#`````````````````GO?_0KZ4`-*^G`#R/IP`T`(`8(3P. M?_\USO__K[\`%*^F`#@D#P`")!@`9*.X`"FCKP`H)Z8`'*^N`!ROHP`@KZ,` M)">E`#@,$!4X`.`@(8^Y`"``````HR```(^_`!0GO0`P`^``"``````````` M**$`#!0@`!T`!!@C,&,``Q!@``,`HR@CJ(````"#("$D`?_@`*$X)!#@``P` MIR@C`.0X(22$`""L@/_@K(#_Y*R`_^BL@/_LK(#_\*R`__2L@/_X%(?_]ZR` M__PD`?_\`*$X)!#@``4`IR@C`.0X(22$``04A__^K(#__!B@``4``````*0H M(22$``$4A?_^H(#__P/@``@``````````"0"`_`````,$.```P`````($!H` M``````/@``@`````)`(#[@````P0X``#``````@0&@```````^``"```$"$D M`@/M````#!#@``,`````"!`:```````#X``(`````"0"`^P````,$.```P`` M```($!H```````/@``@`````)`(#ZP````P0X``#``````@0&@```````^`` M"``````D`@/[````#!#@``,`````"!`:```````#X``(`````"3&``$DQO__ M$,``#@"`&"&0H@``)(0``22E``$00``)H(+__R3&__\0P``&`````)"B```D MA``!)*4``11`__F@@O__$,``"``````DQO__$,``!0`````DQO__H(```!3` M__TDA``!`^``"`!@$"$GO?_@CX*`X*^P`!2OL0`8`("((:^_`!P40``#`$"` M(1```!4``!`ACXZ`X`````"-SP```````!'@``\``!`AC@4````````"("`A M#!`2WR80``000``#`$`8(1````8`8!`AC@4````````4H/_W`B`@(0``$"&/ MOP`@``2'O``01```3((0`!('I M__X`````$2``#@````"!ZO__`````!%```F)[/_]@>L``)GL```58/_QK(P` M``/@``@``````^``"+B,``.@B@`"H(D``0/@``B@B``````````````0P``; M`(`X(1"D`!D``````(4(*A0@``@HP0`0`*80(`""""H0(``$*,$`$!```%TH MP0`0*,$`$!0@``4`````,*(``S"#``,00P`+`````!#```<``````*88(8"B M```DI0`!)(0``12C__R@@O__`^``"`#@$"$00``;*,$`("0!``$000`0```` M`"0!``(000`'`````("B```DI0`!)(0``23&__\0```.H(+__X2B```DI0`" M)(0``B3&__X0```(I(+__H"B``"$HP`!)*4``R2$``,DQO_]H(+__:2#__XH MP0`@%"``%BC!`!",H@``C*,`!(RH``B,J0`,C*H`$(RK`!2,K``8C*T`'"2E M`"`DA``@),;_X*R"_^"L@__DK(C_Z*R)_^RLBO_PK(O_]*R,__@0`/_JK(W_ M_"C!`!`4(``.*,$`!(RB``",HP`$C*@`"(RI``PDI0`0)(0`$"3&__"L@O_P MK(/_]*R(__@0`/_RK(G__"C!``04(/^S`````(RB```DI0`$)(0`!"3&__P0 M`/_XK(+__"C!`!``IB@@%"``!0"&("`PH@`#,(,``Q!#``T`````$,#_JP`` M```DI?__`*88(R2$__^`H@``)*7__R2$__\4H__\H((``0/@``@`X!`A$$`` M&RC!`"`D`0`#$$$`$``````D`0`"$$$`!P````"`HO__)*7__R2$__\DQO__ M$```#J""``"$HO_^)*7__B2$__XDQO_^$```"*2"``"`HO__A*/__22E__TD MA/_]),;__:""``*D@P``*,$`(!0@`!8HP0`0C*+__(RC__B,J/_TC*G_\(RJ M_^R,J__HC*S_Y(RM_^`DI?_@)(3_X"3&_^"L@@```#21C#L"/F(!`)&,`$`!X""L4(``#```` M`!````<``!`AD'D`#``````S*`"#%0#_]0``````8!`A`^``"``````````` M``````````"/CH#L)[W_N*^_`!0GI@`@)`54"`P0&@2OK@`] M_^"OL0`8`("((:^_`!ROL``4CBX`"``````5P``#``````P0$`D"("`ADB,` M#``````P;P`!%>``##!H`$0P>`"`$P``!``````T>0`!$````Z(Y``P0``!* M)`+__Y(C``P`````,&@`1!$``!4`````/`(0`(^)@$`D0@[``$D(*Q`@``\` M0(`AD@H`#``````Q2P!`$6```P`````,$`Z^`@`@(8^,@$`F$``0`@P(*Q0@ M__4`````DB,`#`````".)0`(,&T`!!&@``2N)0`$DB0`#1````@D$``!DB0` M#3P/$```!'"``>YX(8WO%0```````>6`(PP0$I`"`#`A)%#__ZXB```&```' MKC```(XC``0`````D&(``"1X``$0```7KC@`!(XY```D`?__$R$`!@````"2 M*``,`````#4)`"`0```,HBD`#)(J``P`````-4L`$*(K``R2(P`,`````#!L M`(`1@``#`````#!M`/ZB+0`,KB```"0"__^/OP`@`"1&(`,&#!`:#.>A`"#'H0`@QZ``)$2`(`!$ M@"@`CZX`/(^H`"Q&)``R``!X(44```*MP@``)`\``8^X`$`D`0`!$$$``Z\/ M```40``/)`$``H^Y`#0GA(!@#!`:=*\@``"/J0`P/`00`"2$&B@GA8!D#!`2 M_*TB```\`A``$```;R1"&B@D`0`"$$$`!``````D`0`#%$$`#X^K`#@\!!`` M#!`:="2$%J"/J@`P/`00`#P%$``DI1:L)(0:*`P0$ORM0@``/`(0`!```%PD M0AHHCZL`.``````58`!%`````"D!`!(4(``@`````#P$$`!$!@@`1`<``"2$ M&B@D!0`1KZ``$`P0&GROJ``LCZ@`+(^M`#`\!1``)*4:.B1,``$I`0!1`*`8 M(10@``.MK```$````B0"`%`!`!`A/`X0`"7.&BD`3B`A$*0`!0`````D`@`P M)&,``11D__Z@8O__$```&J!@```=```.`````#P$$`!$!@@`1`<``"2$&B@D M!0`!#!`:?*^@`!"/N``P)$\``3P!$`"O#P``$```"Z`@&BD\!!``1`8(`$0' M```DA!HH`0`H(0P0&GROH``0CZD`,"19``&M.0``/`H0`)%*&BB/K``T.4L` M+2UK``$\`A``)$(:*1```!2MBP``/`00`$0&"`!$!P``)`T``:^M`!`DA!HH M#!`:?`$`*"&/KP`P)$X``:WN```\&!``DQ@:*(^I`#0[&0`M+SD``3P"$``D M0AHIK3D``(^_`!PGO0`H`^``"`````",A0``/`%__S0A__\`!3!#`,$P)"0! M``4`P0`:,*,``0``>!``#\!```!P$@,#$"$D0@`P`^``"*R.```GO?U`K[<` M/*^V`#@`P+@AK[X`0*^_`$2OM``PK[4`-*^R`"BOLP`LK[``(*^Q`"2OI0+$ MKZ`"M)+B``V/M@*D`("8(9)P````````$@``(``````D`0`E$@$`'0````". MX@```````"1"__\$00`&KN(``#($`/\,$`[V`N`H(1````F/N0*TCNX`!#(" M`/^AP@``CN\`!``````E^``!KO@`!(^Y`K0F\",0```+ M.C$`!(^O`L0D`?_\)?@`!P,!R"2ON0+$CS;__``````&P0`"````````L"&2 M<```$`#_TP`````R*`!$%0```R8"_]`V,0`@)@+_T))P```\"1```3!((9$I M#*$R,@!`,2H`!!%```\`````/`,0`"1C#*```EB``6)8(0`+6$`!"H(1,```DR M,@!`C[D"Q"0!__PG*``'`0%()*^I`L2-*O_\$```":^J`/"/JP+$)`'__"5L M``$`#P`````GF(!H)!D` M`3P!@`"ON0#\$>$`!*^X`0P`#T`C$```%:^H`/`GM`$<#!`5*2>D`/`0```0 MHH(``#(I``(1(``',BP`"">*@&PD"P`!KZL`_!````BOJ@$,,BP`"!&```:/ MN`#P)XV`<"0.``&OK@#\KZT!#(^X`/``````*P$`"A`@``D#`!`A%P```P`` M```60``5`````"19`#`FE/__$```$:*9```D`0`*`$$`&@!`&"$FE/__```0 M$@`">(`!XG@A``]X0`!O0",E"0`P*$$`"A`@__2BB0``)$H`,":4__^BB@`` M$D``"C(M`@`GJP$=`71@(P+,$",80``%,BT"`*^B`IROH@#T-C$"`#(M`@`0 M``*IKZT`4">N`1TR.``!`<"@(0'`J"$3```),C(`0(^Y`L0D`?_\)R\`!P'A M0"2OJ`+$C0G__!````FOJ0#PCZH"Q"0!__PE2P`'`6%@)*^L`L2-C?_\```` M`*^M`/"/K@#P/`&```'!P"03`/^]C[@`\">T`1P,$!4I)Z0`\!``_[>B@@`` M)[D!'0,@H"$#(*@A)`0`!R0%``(0```',C(`0">O`1T!X*`A`>"H(20$``\D M!0`#,C(`0#(H``$1```*CZT"Q(^I`L0D`?_\)2H`!P%!6"2OJP+$C6S__!`` M``FOK`#PCZT"Q"0!__PEK@`'`<'`)*^X`L2/&?_\`````*^Y`/`D`0!8%@$` M!``````\`Q``$````R1C%N@\`Q``)&,6_(^O`/``````%>``"@'@$"$60``3 M`````"0(``$D"0`!-C$"`#(R`$"OJ0#T$```#*^H`IP`1%`D/`%__S0A__\` M:E@A``)H0Y%L```!H7`D`*X0!R:4__\40/_VHHP``!)```HR+P`0)[@!'0,4 MR","V1`C&$``!3(O`!"OH@*``)#(Y`@"/J`#P```` M`!$``"`R.0(`$```%20!`%@R*0(`%2``&S(Y`@`D"@`!)`L``:^K`/2OJ@*< M$```%#8Q`@`GC(!T)`T``J^M`/P0```/KZP!#">.@'@D&``"K[@`_!````JO MK@$,)`$`6!(!__D`````)`$`;Q(!_^@`````)`$`>!(!_^X`````,CD"`!`` M`A>ON0!0,B\`0!7@``,FP@`!)!8`!B;"``$H00`1$"``!"0%`!$0```"`$`H M(20%`!$GJ`#0)ZD`Y*^I`!BOJ``4)Z0"Q">F`.PGIP#H#!`4B*^@`!``0*`A MCZ(`T"0!``$000`#`````!1```HD`0`")X2`?`P0&G0`@*`A)XJ`?#(K`@"O MJP!0$``!]`!*J"$D`0`"%$$`$"0!``,R+``"$8``!``````\%!``$````R:4 M%Q`\%!``)I07'`P0&G0"@"`A,BT"`*^M`%`0``'C`H*H(20!``,400`,C[D` MZ#P$$``DA!-@(@D#@`!KZX`_*^M M`0R2@P```````!!@``U`1,6P``$`````#(Y`!`3(``$`````"0/`"ZBKP``)K4``1K```X````` MDH,````````08``*`````"2$__^BHP``)I0``1B```4FM0`!DH,````````4 M8/_X`````!B```6/J0#DKZ0"F*^D`/0V,0$`CZD`Y">H`0>OJ`$()[0!$A4@ M`!NCH`$'CZ(`[``````D0O__!$$``RA!``H``A`C*$$`"A0@``Z/HP$(CZ,! M"``````D`0`*`$$`&B1C__\``%`0```0$BA!``HE2P`P$"#_^*!K``"OHP$( MCZ,!""1,`#`D8___H&P``*^C`0B/K0$()ZX!!0'-""L0(``*C[@`[(^B`0@D M`P`P)Z0!!21"__\`@@@K%"#__:!#``"OH@$(C[@`[``````?```%`````(^Y M`.0`````$R``"(^J`0B/KP$()`D`*R7H__^OJ`$($```!J'I__^/J@$()`P` M+25+__^OJP$(H4S__SP-$``!L&@AD:T,H0`````QK@`!$<``!P````"/N`$( M)`@`12<9__^ON0$($```!J,(__^/J0$()`L`924O__^OKP$(H2O__X^L`0B/ MK0#T)ZH!!S8Q`(`!3!`C,CD"``&B<"&OK@#TK[D`4!```3FOH@#X,B@`0!4` M``,JP0`\)!8`!BK!`#P0(``$)`4`/!````("P"@A)`4`/"08``$GKP#0)ZL` MY*^K`!BOKP`4K[@`$">D`L0GI@#L#!`4B">G`.@`0*`ACZ(`T"0!``$000`# M`````!1```HD`0`")X2`C`P0&G0`@*`A)XF`C#(J`@"OJ@!0$``!%@!)J"$D M`0`"%$$`$"0!``,R+``"$8``!``````\%!``$````R:4%S0\%!``)I070`P0 M&G0"@"`A,BT"`*^M`%`0``$%`H*H(20!``,400`,CZ@`Z#P$$``DA!=,#!`: M=`"`H"$\#A``)",!^`@J$"``"S(L``*2BP``)`$`,!%A``(@)@D&``!K[@`_*^H`0R/I`#L)[4!$J^@`-P8@``+)`L` M,)*#````````$&``!R0+`#"/KP#<`````"GA`!$4(``&CZD`W"0+`#"BJP`` M$```"":U``&/J0#<,&(`_R4J``&OJ@#M`.2OK0`8KZP`%">D`L0GI@#L)Z<`Z`P0%(BOH``0 MCZX`Y`!`H"$1P``$,B@`$"09``&ON0#L,B@`$!4``!4"P)`A#!`:=`*`("$` M5@@J$"```@``````0)`A&D``#H^K`.P"DA`AD%C__R0!`#`7`0`)CZL`["92 M__\:0``%)$+__Y!/__\D`0`P$>'_^@````"/JP#L`````"EA__T4(``$```` M``++""H0(``$CZD`[!``_D4F5O__CZD`[!``_R`"2;`CH[`!$B>T`1(0```* M)[4!$X^J`L0D`?_\)4P`!P&!:"2OK0+$C:[__">T`1(GM0$3HZX!$C(Y`@`0 M```SK[D`4(^H`L0D`?_\)1@`!P,!>"2OKP+$C?3__``````6@``%,BL`0"0! M_[\"(8@D)Y2`G#(K`$`58``%``````P0&G0"@"`A$```$`*"J"&2A0``)H(` M`1"@``PD5?__)M;__P;```DD5?__D$4``"1"``$0H``%)%7__R;6__\&P?_Z M`````"15__\R*0(`$```#J^I`%`0`/QZ)G/__R8*_^`M00!9$"#_^P`````` M"E"`/`$0```J""&,*@````````%```@`````CZP`_(^N`/0"M!@C`&QH(0&N M$"$`7@@JKZ(`W!0@``>OHP#(C[D"M(^H`-R/M0#(`RC`(1```#>ON`*TCZ\" MM(^U`,@R*0`@`?Y8(1$@`!.OJP*TCZH`4``````50``(`````(^L`-PV,0(` M,BX"``/,:".OK0*<$```!J^N`%"/N0*/K@#\,%(`_X[B M````````)$+__P1!``:NX@```D`@(0P0#O8"X"@A$```"280__^.Z@`$,D(` M_Z%"``".[``$`````"6-``&N[0`$)A#__QX`_^T`````CZX`_``````1P``< MCZL`4!G``!D``)`AC[`!#`````".X@``D@,``"1"__\$00`&KN(``#!D`/\, M$`[V`N`H(1````F/KP#\COD`!#!B`/^C(@``CN@`!``````E&``!KO@`!(^O M`/PF4@`!`D\(*A0@_^LF$``!CZL`4``````18``;`````(^I`IP\`A``D$(6 MT!D@`!8!((`A,%(`_X[B````````)$+__P1!``:NX@```D`@(0P0#O8"X"@A M$```"280__^.Z@`$,D(`_Z%"``".[``$`````"6-``&N[0`$)A#__QX`_^T` M````&J``&C(X`80:H``7``"0(0*`@"&.X@``D@,``"1"__\$00`&KN(``#!D M`/\,$`[V`N`H(1````DF4@`!CNX`!#!B`/^AP@``COD`!``````G*``!KN@` M!"92``$"50@J%"#_["80``$R.`&$$P#[T0`````R+P$`$>``&S(T``2/JP*8 M/`(0`)!"%M`98``6`6"`(3!2`/^.X@```````"1"__\$00`&KN(```)`("$, M$`[V`N`H(1````DF$/__CND`!#)"`/^A(@``CNH`!``````E3``!KNP`!"80 M__\>`/_M`````#(M`(`1H``=`````(^N`/@``(@A&<``&0````"/L`$(```` M`([B``"2`P``)$+__P1!``:NX@``,&0`_PP0#O8"X"@A$```"8^O`/B.^0`$ M,&(`_Z,B``".Z``$`````"48``&N^``$CZ\`^"8Q``$"+P@J%"#_ZR80``$2 M@/N3`````(^K`-P``````7X(*A`@^XX`````/`(0`)!"%K@#RX`C&@#[B0`` M```P40#_CN(````````D0O__!$$`!J[B```"("`A#!`.]@+@*"$0```))A#_ M_X[I``0R(@#_H2(``([J``0`````)4P``:[L``0F$/__'@#_[0`````0`/MS MDG```(^_`$2/L``@C[$`)(^R`"B/LP`LC[0`,(^U`#2/M@`XC[<`/(^^`$`# MX``()[T"P#P#$`",8Q=D)`(#^0"#("$````,%.``!0`````\`1``K"079`/@ M``@`8!`A"!`:```````\`A``C$(78```````@@@K$"```@``````0"`A)`(# M^0````P4X/_T`````#P!$`"L)!=D`^``"```$"$\`1``K"(83`/@``@D`O__ M)`($'@````P0X``#``````@0&@```````^``"`````!$!F@`/`$`#P`&+0(T M(?__`*`@(0#!,"0D`0?_,*4'_T0'8``4H0`3,(0(`!3```H\`0`(%.``"#P! M``@4@``#``````/@``@D`@`"`^``""0"``,\`0`(`,$@)!"```,``````^`` M""0"```#X``()`(``12@`!$`````%,``"0`````4X``'`````!2```,````` M`^``""0"``@#X``()`(`"12```,``````^``""0"``8#X``()`(`!Q2```,` M`````^``""0"``0#X``()`(`!40&8``\`0!_``8MPC0A__\`H"`A`,$P)"0! M`/\PI0#_%*$`$3"$`0`4P``(/`$`0!2```,``````^``""0"``(#X``()`(` M`SP!`$``P2`D$(```P`````#X``()`(```/@``@D`@`!%*``#P`````4P``' M`````!2```,``````^``""0"``@#X``()`(`"12```,``````^``""0"``8# MX``()`(`!Q2```,``````^``""0"``0#X``()`(`!0```````````````"2" M__^00P`!($(``11@__T``````^``"`!$$",``````^#((03!``(D"0`@)`D` M+0`&:$``!T?"`:AH):")```\`7_@`:%((P`'8$`DA``!!2$``B0*`F@E2@`! M``W%0A,``(`!*@`8)`$'_Q,!`)\```````UJP```$!``#6K"/`$`(`&A:"4, M$!M```)`(B<8^^T#`\`A`!C`(H^L`!`#"S`&`P8X!!&```T!9U@C+,P`"@&" M8",`K"@C)*4``AR@``0HH0`2$```!20%``$HH0`2%"```RS!``HD!0`1+,$` M"A0@`!(`I"@A)`$`"@#!`!LDA``!)$(``0``.!(DYP`P```P$!2%``F@A___ M+,$`!10@`#T`````+,$`!A`@`#P`````$```+@`````DQ@`P)(0``1"%`":@ MAO__``AH@`&@<""$!+4@A`8!P)P')<"L!+$@A`>Y@(0`*:(`!H'`G`Y@(0%L6"$G&/__`PLP!@,&.`0DQ@`P M)(0``:"&__\4A?_<`6=8(R<8__\#"S@&$.``"Z"````50``+`````!4@``DE M9___%0``!P#K."04X``%,,8``13```,``````R``"``````DB?__D2@``"0! M`#D1`0`%+0$`,!0@``16```8`I"@A``U* MP!4@``,`````/`@0`"4(`7"1"0``)(0``1$@``.@B?__%(7_^R4(``$#(``( M/`*```4```\`````)0C_Y1T```P```````A`0#P#$```:!@A``A`@#P!$``` M*`@AC"X"P(PO`L2$8P0,"!`;E```````"%D#``M8@#P!$```*P@AC"L#<">] M__``"%!``4M8!``+7X.OJP`,KZP``*^M``0%```QK[\`""0)`#0E"/_D!0'_ M_B4I``(`"$!`/`,0`#P*$``!2%`A`&D8(0`)2(``"$"`A&,#UH5*!`X\#A`` M/`\0`#P,$``\#1```:AH(0&(8"$!Z7@A`B-[P'LC8P"R(VM`LP` M:A@A#!`;E"1C``$%8``*CZ@`#``*1\(`"UA``6A8)0`)1\(`"E!``4A0)0`) M2$`D8___CZ@`#``)3\*/K```CZT`!(^_``@!27`A)[T`$`%@>"$($!N4`P_$F\^+XD_!ETWWV0S6\B'1]E/BI7\^^!HTO^Q6%DH,`R@[]A[7R M`````(``````````H`````````#(`````````/H`````````G$````````## M4````````/0D````````F):```````"^O"```````.YK*```````E0+Y```` M``"Z0[=``````.C4I1``````D83G*H````"UYB#TH````.-?J3$$````CAO) MO\4```"QHKPN=D```-X+:SJ)Z```BL.O%%WJ``-C7)K=NK)`` MAX9X,@I7M`"I:!8_S.VA`-/"&\Y`%(2@A%E189`9I.2RN])D4>&F.%-CH9CEX]CYY0```,P````````` M%$4!``0!`````PS`S#`!$!``!`1$`P,`P#P\#`//,,\,`,`,`````````%`! M1```$``0!```!`$``!0``1``````,`,``#,\,,\`,#P````````````````` M`#```P`````%`!`154``!``$`41``0`$`!$$!!``````````#/```````P#, M,,``,,`$1`$!04````%`````^T;[H_P`_%W\NOT7_73]T?XN_HO^Z/]%_Z(` M```#``8`"0`-`!``$P`7`!H`'0`A`"0`)P`K`"X`,0`U`#@`.P`_`$(`10!) M`$P`3P!3`%8`60"V`1,!<`'-`BH"AP+D`T$#G@/[```````````````````` M`````````0````,````'````#P```!\````_````?P```/\```'_```#_P`` M!_\```__```?_P``/_\``'__``#__P`!__\``___``?__P`/__\`'___`#__ M_P!___\`____`?___P/___\'____#____Q____\_____?_________]81V5T M4&EX96PZ(&)A9"!I;6%G92$A"@!H96%D97(@&UA<"!D97!T:"`E M9`H`````=VED=&@@)60@:&5I9VAT("5D"@!X;V9F71E(&]R M9&5R("5D"@``8FET;6%P('5N:70@)60*`&)I=&UA<"!B:70@;W)D97(@)60* M`````&)I=&UA<"!P860@)60*``!B:71S('!E&ET:6YG+@````!X=W5D.B!85T0@:&5A9&5R('-I>F4@:7,@=&]O('-M86QL M+@!E>&ET:6YG+@````!#86XG="!M86QL;V,@=VEN9&]W(&YA;64@/@$A$3$)*1D MY!245-0TM'3T#(Q,S"RL;.PWCZ^?OX! M@4'!(:%AX1&14=$QL7'Q"8E)R2FI:>D9F5G9.;EY^06%1<4EI67E%955U36U M=?4-C4W-+:UM[1V=7=T]O7W]`X-#PR.C8^,3DU/3,[-S\PN+2\LKJVOK&YM; MVSN[>_L'AT?')Z=GYQ>75]F4*`````&EO<&5N.B!E7!E"@```&=E=')O M=SH@=VEE'R`A(B,D)28G*"DJ*RPM+B\P,3(S-#4V-S@Y M.CL\/3X_0&%B8V1E9F=H:6IK;&UN;W!Q'EZ6UQ=7E]@04)#1$5& M1TA)2DM,34Y/4%%24U155E=865I[?'U^?P`````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````!#2%)#3$%34P`````O;&EB+V-H0```$EN9FEN:71Y`````"U);F9I M;FET>0```"M);F9I;FET>0```$EN9FEN:71Y`````"U);F9I;FET>0`````` M````````$`"]P!``O<```````````'<```!R``````````````!N;R!N86UE M`````````````0```&%S8VEI`````````!``%0`````````````````````` M````````````````3F%.`$YA3@`M````*P```"`````P>```,%@``$YA3@`M M````*P```"````!.84X`+0```"L````@````*&YU;&PI```````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` )```````````` ` end   Received: from vmb.brl.mil by VMB.BRL.MIL id aa16420; 13 Sep 90 12:50 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa16155; 13 Sep 90 12:19 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa16005; 13 Sep 90 12:01 EDT Received: from uunet.UU.NET by ADM.BRL.MIL id aa23013; 13 Sep 90 11:50 EDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA12963; Thu, 13 Sep 90 11:37:24 -0400 Received: by opal.STC.LOCKHEED.COM (4.0/1.77); Thu, 13 Sep 90 09:20:03 CDT Received: from arthur.msd.lmsc.lockheed.com ([129.197.11.6]) by sacha.msd.lmsc.lockheed.com (4.1/Ultrix3.0-C_mdc) id AA18445; Wed, 12 Sep 90 21:13:05 PDT Received: by arthur.msd.lmsc.lockheed.com (4.1/SMI-4.1_mdc) id AA06578; Wed, 12 Sep 90 21:07:24 PDT Date: Wed, 12 Sep 90 21:07:24 PDT From: Dave Cunningham Message-Id: <9009130407.AA06578@arthur.msd.lmsc.lockheed.com> To: info-iris@BRL.MIL Subject: Sun/SGI boot interference Thank you to everyone who replied to my question about Irises interfering with diskless Sun's boot procedures. The concensus answer was Yes, 3.2 (at least) Irises have a misbehaving bootparamd which interferes with 4.0.3 (at least) Suns trying to boot from a server. Lots of sites have run into the problem. Commenting out the bootparam line in /usr/etc/inetd.conf on the Irises fixes the problem. (Unless, of course you need to boot Irises diskless...). It is NOT necessary to disable the bootp server. You also need to reboot or send a HUP to inetd, and possibly kill a lingering process running rpc.boot. The problem is supposed to be fixed in Irix 3.2.x, x>1, and in 3.3. There is also a SunOs patch for 4.0.3 which may avoid the problem; it's call the "jumbo nfs" patch. Don't know about SunOs 4.1. Thanks again for the helpful responses. #include Dave Cunningham cunning@arthur.msd.lmsc.lockheed.com Lockheed Missiles and Space Co. O/81-10, B/157-5E, (408)-756-1382   Received: from vmb.brl.mil by VMB.BRL.MIL id aa17826; 13 Sep 90 14:40 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa16565; 13 Sep 90 13:06 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa16491; 13 Sep 90 12:56 EDT Received: from vm.uoguelph.ca by ADM.BRL.MIL id aa24390; 13 Sep 90 12:47 EDT Received: from VM.UoGuelph.CA by vm.uoguelph.ca (IBM VM SMTP R1.2.2MX) with BSMTP id 1403; Thu, 13 Sep 90 12:20:50 EST Received: by UOGUELPH (Mailer R2.07) id 7889; Thu, 13 Sep 90 12:20:49 EST Date: Thu, 13 Sep 90 11:54:29 EST From: Peter Jaspers-Fayer Subject: /usr/etc/resolv.conf (and colors) To: Iris mailing list Message-ID: <9009131247.aa24390@ADM.BRL.MIL> There has been some talk here about resolv.conf, and I'd like to ask a question: If you create that file, then then System/Sytem manager/Networking toolchest menu complains that it can't do anything. Why? (I'm running 3.3.1) On a totally unrelated note: Just so this won't be a total waste of bandwidth, here's a small tip: The wsh and textcolor commands talk about the 'current color map', but that didn't help me much and I couldn't find a way with apropos or any man page to map the numbers to the colours. Experimentation reveals that the colours (0,1,2,...) are in the order of the bottom colour bar on the QuickPaint screen. `xshowcmap` also shows this order. Mine are: Black, Red, Green, Yellow, Blue, Purple, SkyBlue, White, Grey etc. 33 -> 55 is a greyscale from black to white. Of course if you fiddle with the colormap (cedit & etc) then the above will change. /PJ SofPJF@VM.UoGuelph.Ca (Probably also reachable (until ?) at SOFPJF@UOGUELPH.BITNET) Klein bottle for rent, apply within.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa18414; 13 Sep 90 15:47 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa18318; 13 Sep 90 15:37 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa18297; 13 Sep 90 15:27 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa00665; 13 Sep 90 14:53 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04217; Thu, 13 Sep 90 11:44:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 90 18:16:01 GMT From: "Scott R. Presnell" Subject: mt fsf command and bru backups Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi all. I've been doing backups on a exabyte device using some home brew scripts. So far no problems as long as you specify the block size. I can save, list, and extract things with relative ease. The confusion/problem I have is this: inside the script, I keep track of the number of bru "files" I have written. But when I use "mt -f /dev/nrexabyte fsf X" I don't get to the "file" I want to list or extract. It seems that the file I want is at about X*3 or so by mt's count of files. (btw: **thank you** for the -L and -g option - how I figured it out). Any hints? It's not a big problem, but it's something of a nuisance. I write the files like so: "mt -t /dev/nrexabyte feom ; bru -c -b 128k -f /dev/nrexabyte /usr" This is on a Personal Iris 20G running IRIX 3.2.1. Thanks. - Scott Presnell -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet   Received: from vmb.brl.mil by VMB.BRL.MIL id aa19530; 13 Sep 90 17:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa19258; 13 Sep 90 17:07 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19238; 13 Sep 90 17:01 EDT Received: from prandtl.nas.nasa.gov by VGR.BRL.MIL id aa01717; 13 Sep 90 16:50 EDT Received: Thu, 13 Sep 90 13:49:58 -0700 from csduts1.lerc.nasa.gov by prandtl.nas.nasa.gov (5.61/1.2) Received: Thu, 13 Sep 90 16:50:51 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Thu, 13 Sep 90 16:57:30 EDT by ZoSo.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Thu, 13 Sep 90 16:57:30 EDT From: Tony Facca Message-Id: <9009132057.AA02357@ZoSo.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: A problem with xhost? I have a question about the xhost program. Actually, what I am trying to do is use toolchest to open xterm clients on remote machines. Under 3.2 this worked just fine. I do an "xhost remote_host" and follow that up with "rsh remote_host xterm -display local_host:0" [basically] Anyway, I now have 3.3 running on several of the systems and this method no longer works. I think its a problem with xhost as evidenced by the following: ----------- nasp03 is running 3.2 ----------------------- [39] [nasp03] :xhost access control enabled (only the following hosts are allowed) nasp03.lerc.nasa.gov localhost [40] [nasp03] :xhost zoso zoso being added to access control list [41] [nasp03] :xhost access control enabled (only the following hosts are allowed) zoso.lerc.nasa.gov <-- zoso appears nasp03.lerc.nasa.gov localhost [42] [nasp03] :xhost + all hosts being allowed (access control disabled) [43] [nasp03] :xhost access control disabled (any host is allowed) <-- control disabled zoso.lerc.nasa.gov nasp03.lerc.nasa.gov localhost -------------------- end of 3.2 session ---------------------- The above is how I would expect xhost to behave, according the FM. Take a look at what happens under 3.3 ----------- ZoSo is running 3.3 ------------------------------ [32] [ZoSo] tmp :xhost access control enabled (only the following hosts are allowed) zoso.lerc.nasa.gov localhost [33] [ZoSo] tmp :xhost avelon avelon being added to access control list [34] [ZoSo] tmp :xhost access control enabled (only the following hosts are allowed) zoso.lerc.nasa.gov localhost <-- NO AVELON !!?? [35] [ZoSo] tmp :xhost + all hosts being allowed (access control disabled) [36] [ZoSo] tmp :xhost access control enabled (only the following hosts are allowed) <-- ENABLED?? zoso.lerc.nasa.gov localhost -------------------- end of 3.3 session ---------------------- So, what gives? I am pretty sure that things really are not working properly with xhost, not that its working but not reporting things properly. Also, this is not unique to these two systems. I tried it on several versions of 3.2 and several 3.3's. I'm at Witts end, again. Any suggestions would be most appreciated. ----------------------------------------------------------------------------- Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 ----------------------------------------------------------------------------- You are at Witt's end. Passages lead off in *all* directions.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa19760; 13 Sep 90 17:44 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab19530; 13 Sep 90 17:23 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19407; 13 Sep 90 17:13 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa02140; 13 Sep 90 17:07 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5835; Thu, 13 Sep 90 17:07:10 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Thu, 13 Sep 90 17:11 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA03201; Thu, 13 Sep 90 17:12:24 DSD Date: Thu, 13 Sep 90 17:12:24 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: Back Issues Computer Graphics Journals wanted ... To: info-iris@BRL.MIL Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009140012.AA03201@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil If you have old , older, or ancient issues of these journals, I would like to take them off your hands(even buy them) to fill the holes in my collections. I promise not to throw what I don't need to complete my collection. I will recycle all the pulp I can. Journals Wanted: ------------------------------------------------------------------------------- IEEE Computer Graphics and Applications, pre 1989 only. IEEE Computer, pre 1986 only. ACM SIGGRAPH, pre 1987 only. ACM Transactions on Graphics, pre vol 8, No 3(1989) Communications of the ACM, pre 1987 Computers in Medicine and Biology, all Computer methods and programmes in biomedicine, all Computers in Physics, all Unix Review, pre 1987 Computer Graphics World, sporatic copies. Popular Science, pre 1989 Omni, pre 1990 Analog, sporatic copies needed in the past 20 years (call me) Byte, Looking for old (Vol 1,2,3,4,5) issues to fill in holes. Nature, pre 1986 ------------------------------------------------------------------------------- I would be interested in other journals if you think I would want them from my list above. This is for my/our office library. It is also used as thermal insulation along the walls, and radiation shielding in the event of a nuclear blast. If you have material you want to send/sell, let me know. I will arrange to have the material picked up by Federal Express. dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05456; 15 Sep 90 11:37 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05320; 15 Sep 90 10:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05318; 15 Sep 90 10:46 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa10805; 15 Sep 90 10:41 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08985; Sat, 15 Sep 90 07:37:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 90 18:41:37 GMT From: Rajeev Jayavant Organization: Hewlett Packard -- Fort Collins, CO Subject: Re: Bash for 4D/25 Message-Id: <17450008@hpfcdj.HP.COM> References: <9009111436.AA09719@banach.aca.mcc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL / hpfcdj:comp.sys.sgi / tomw@orac.esd.sgi.com (Tom Weinstein) / 10:01 am Sep 11, 1990 / >In article <9009111436.AA09719@banach.aca.mcc.com>, nong@MCC.COM writes: >> I have trouble in getting GNU's Bash to compiled on 4D/25 running 3.3 >> Has anyone got it to work. I would appreciate any advice/tips/help. > >> Thanks, > >> ------------- >> Nong Tarlton >> Microelectronics and Computer Technology Corporation >> nong@mcc.com > > Bash will work under IRIX-3.3 whenever Brian gets around to releasing > version 1.06. > > -- > Tom Weinstein > Silicon Graphics, Inc., Entry Systems Division, Window Systems > tomw@orac.esd.sgi.com > Any opinions expressed above are mine, not sgi's. > ---------- I spent some time last weekend porting bash-1.05 to Irix. I currently have it running on a 120GTX under 3.2 and on a 210GTX under 3.3. I gave up trying to get job control working under 3.2, but it seems to work fine under 3.3. I only made minor changes to config.h, machines.h, jobs.c, and nojobs.c to get things working. I have sent a message to Brian informing him that I have what appears to be a working version for Irix, but have not heard back from him yet. If bash-1.06 is not going to be released anytime soon, I can dig up the original 1.05 sources and generate some diffs. Rajeev ------------------------------------------------------------------------------- Rajeev Jayavant (rajeev@hpfcla.hp.com) "Excuse me, I've lost my marbles" Hewlett Packard - Graphics Technology Division - P. Opus, [Bloom County]   Received: from vmb.brl.mil by VMB.BRL.MIL id ab22290; 14 Sep 90 5:27 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa22261; 14 Sep 90 5:06 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22250; 14 Sep 90 5:00 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa05444; 14 Sep 90 4:53 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27517; Fri, 14 Sep 90 01:46:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 04:11:16 GMT From: Joe Cychosz Organization: Purdue University Engineering Computer Network Subject: Kermit for the SGI Iris Message-Id: <1990Sep14.041116.21575@ecn.purdue.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I previously posted a note requesting a working version of Kermit for the Iris. The one in 4Dgifts works fine. It still has the problem with the wart program. But using wart on a Sun to generate the ckcpro.c file and then compiling on the Iris allows it to work. My orginal problems had to do with using kermit through a network connection. (i.e., log into one machine, rlogin to the iris, run kermit). When used directly thourgh one of the tty ports it works fine.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa26295; 14 Sep 90 12:19 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25736; 14 Sep 90 11:48 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25728; 14 Sep 90 11:41 EDT Received: from ATHENA.MIT.EDU by VGR.BRL.MIL id aa06562; 14 Sep 90 11:34 EDT Received: from M11-116-8.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA13883; Fri, 14 Sep 90 11:35:12 EDT From: eugholz@athena.mit.edu Received: by M11-116-8.MIT.EDU (5.61/4.7) id AA06747; Fri, 14 Sep 90 11:35:08 -0400 Message-Id: <9009141535.AA06747@M11-116-8.MIT.EDU> To: Info-Iris@BRL.MIL Subject: fowarding mail Date: Fri, 14 Sep 90 11:35:02 EDT I'm trying to foward my mail from a Personal IRIS on which I have an account to my main general-purpose account on a different machine. The command that I know of to foward mail is "mail -F destination" -- and this is what is documented in the man page on mail on the IRIS. However, trying this on two different IRISes has yielded the message "unknown flag -F". I'd appreciate any hints about fowarding mail through this or any other technique. I have seen references to using a ".Foward file", but have not found any documentation about the proper format for such a file -- and trial and error isn't doing it for me. Thanks a lot, Eugene Gholz (send replies to eugholz@athena.mit.edu)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa27540; 14 Sep 90 13:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa26591; 14 Sep 90 12:44 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa26482; 14 Sep 90 12:32 EDT Received: from cidsv01.cid.aes.doe.CA by VGR.BRL.MIL id aa06841; 14 Sep 90 12:20 EDT Received: from cidws03 by cidsv01 (5.61-MX) with SMTP id AA26058; Fri, 14 Sep 90 16:19:54 GMT Return-Path: From: Alain St-Denis Message-Id: <9009141619.AA01072@cidws03.cid.aes.doe.CA> Subject: Default Swap Partition To: info-iris@BRL.MIL Date: Fri, 14 Sep 90 12:19:48 EDT X-Mailer: ELM [version 2.2 PL16] Is there any special reason why we can't have the default swap partition on whatever disk we would like. I know we can do it using the PROM's "swap" environment variable. But this variable is not permanent in the PROM. So we would have to reset it at each boot. Our systems never swapped anything, but since their load will increase in the next few months, we thought that it would be more efficient if the swap space resided on another disk. Is it that unreasonable? -- Alain St-Denis Centre informatique de Dorval Environnement Canada astdenis@cid.aes.doe.CA (514) 421-4697   Received: from vmb.brl.mil by VMB.BRL.MIL id aa27759; 14 Sep 90 13:56 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab27241; 14 Sep 90 13:34 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa27225; 14 Sep 90 13:28 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa07121; 14 Sep 90 13:23 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13929; Fri, 14 Sep 90 10:13:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 17:00:21 GMT From: Dave Carek Organization: NASA/Lewis Research Center, Cleveland Subject: xterm key remapping Message-Id: <1990Sep14.170021.28769@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Could someone provide me with a little insight on how to remap keys in an xterm window. bindkey doesn't seem to do the job. Any help would be greatly appreciated. -- ----------------------------------------------------------------------- | David Carek | phone: 216-433-8396 | | NASA Lewis Research Center | | | Cleveland, Ohio 44135 | email: eddc@opus.lerc.nasa.gov | |---------------------------------------------------------------------| | Engineer -> An innovative imaginative scientist who must design the | | improbable using the impossible on a budget that is invisible | -----------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa28095; 14 Sep 90 14:16 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa26945; 14 Sep 90 13:09 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa26844; 14 Sep 90 12:59 EDT Received: from aero4.larc.nasa.gov by VGR.BRL.MIL id aa07000; 14 Sep 90 12:45 EDT Received: Fri, 14 Sep 90 12:46:20 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 14 Sep 90 12:46:20 EDT From: "Brent L. Bates AAD/TAB MS361 x42854" Message-Id: <9009141546.AA11433@aero4.larc.nasa.gov> To: eugholz@athena.mit.edu Subject: Re: fowarding mail Cc: info-iris@BRL.MIL You need a file call .forward in your home directory. This file contains one line of the form logname@destination or what ever you would have in a "To:" line. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from vmb.brl.mil by VMB.BRL.MIL id aa02100; 14 Sep 90 17:45 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01467; 14 Sep 90 16:46 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01318; 14 Sep 90 16:34 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa08109; 14 Sep 90 16:26 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19111; Fri, 14 Sep 90 13:18:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 17:39:24 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: /usr/etc/resolv.conf (and colors) Message-Id: <1990Sep14.173924.9268@odin.corp.sgi.com> References: <9009131247.aa24390@ADM.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9009131247.aa24390@ADM.BRL.MIL>, SOFPJF@VM.UOGUELPH.CA (Peter Jaspers-Fayer) writes: |> The wsh and textcolor commands talk about the 'current color map', but |> that didn't help me much and I couldn't find a way with apropos or any |> man page to map the numbers to the colours. Experimentation reveals that |> the colours (0,1,2,...) are in the order of the bottom colour bar on the |> QuickPaint screen. `xshowcmap` also shows this order. Mine are: Use showmap from the "Tools" toolchest (/sur/sbin/showmap) to look at the colormap. Color 0 - 31 are on the bottom row of its display with 0 at the left. A program can use the {rgb,hsv}{i,} functions to find the index of the closest color in the default color map to that specifed as the function argument. -- 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 aa03029; 14 Sep 90 22:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa02892; 14 Sep 90 21:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa02890; 14 Sep 90 21:12 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa08998; 14 Sep 90 20:59 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26435; Fri, 14 Sep 90 17:54:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 90 00:43:58 GMT From: Scum Organization: Carnegie-Mellon University, CS/RI Subject: turning lighting on, off, on again Message-Id: <10477@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a problem which, after much experimentation, seems to be that once I turn lighting off, I can't turn it back on again. I've tried rebinding the material (I turn off lighting by lmbind(MATERIAL, 0)), but that doesn't seem to work. I've even tried redefining all my material, my lights, and my lighting model and then rebinding, but this doesn't seem to work either. Can anybody tell me how exactly one is supposed to turn lighting back on again? I can't find it in the manuals (only how to turn it off). Also, I turn the lighting off so I can draw in regular RGB mode flat shaded polygons, if that's important. I'm running on Irix 3.2 incredibly thankful in advance, -- Chris (cycy@ri.cmu.edu). -- -- Chris. (cycy@isl1.ri.cmu.edu) "People make me pro-nuclear." -- Margarette Smith   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03550; 15 Sep 90 0:06 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03253; 14 Sep 90 23:38 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03251; 14 Sep 90 23:34 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa09408; 14 Sep 90 23:24 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29461; Fri, 14 Sep 90 20:22:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 90 03:07:03 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: logical volumes under 3.3 Message-Id: <13693@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We got 3.3 earlier this week and I've been reading over the manuals trying to plan an install later this month. One of our systems has 4 780M disks and I was thinking of combining parts of all four into one giant logical volume and use it for user file space (one of the biggest pains in the rear on our other systems has been balancing disk utilitization across multiple file systems dedicated to users). Well, as I was working out the details, I realized that the resulting logical volume would end up being well over 2G long. Furthermore, we may be adding more disk in the future and I'd like to be able to just add them to the logical volume. What happens if it goes over 4G? With a 32-bit int/long, we can get a maximum of 2G (signed) or 4G (unsigned). The 3.3 manuals say you can keep adding disk partitions to logical partitions and doesn't mention any limits at all. Somehow I would be very surprised if this were true (pleasantly surprised, but surprised nonetheless). The man page for statfs(2) seems to indicate that it could handle a file system that was 1024G long (using 512-byte blocks), but the man page for stat(2) indicates that the max file size is 2G. If this is truely the case, I'd be satisfied; we probably aren't going to have very many files over a gigabyte. Has anyone who's gotten 3.3 played with this stuff yet? Is there a limit on how large logical volumes can be? robert -- Robert Viduya robert@shangri-la.gatech.edu Technical Services / Office of Information Technology Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from vmb.brl.mil by VMB.BRL.MIL id ab03550; 15 Sep 90 0:06 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa03321; 14 Sep 90 23:55 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa03311; 14 Sep 90 23:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa09467; 14 Sep 90 23:39 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29608; Fri, 14 Sep 90 20:30:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 90 01:43:51 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: Default Swap Partition Message-Id: <1990Sep15.014351.17626@odin.corp.sgi.com> References: <9009141619.AA01072@cidws03.cid.aes.doe.CA> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <9009141619.AA01072@cidws03.cid.aes.doe.CA> aspgasd@cid.aes.doe.ca (Alain St-Denis) writes: | Is there any special reason why we can't have the default swap partition on | whatever disk we would like. | | I know we can do it using the PROM's "swap" environment variable. But this | variable is not permanent in the PROM. So we would have to reset it at | each boot. | | Our systems never swapped anything, but since their load will increase in | the next few months, we thought that it would be more efficient if the swap | space resided on another disk. Is it that unreasonable? | -- | Alain St-Denis | Centre informatique de Dorval | Environnement Canada | astdenis@cid.aes.doe.CA | (514) 421-4697 Just re-configure the kernel with the swap device you want. See the variable SWAPDEV in /usr/sysgen/system. You might also want to read the lboot and master man pages, etc., if you need more info. -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05352; 15 Sep 90 11:01 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05190; 15 Sep 90 9:44 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05188; 15 Sep 90 9:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa10679; 15 Sep 90 9:25 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08072; Sat, 15 Sep 90 06:20:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 90 20:46:56 GMT From: Chris Miller Organization: NASA/Lewis Research Center, Cleveland Subject: 4Mb SIMMs in a 4D/25TG: Chips from some manufacturers don't work! Message-Id: <1990Sep14.204656.5216@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Problem: Chips from some manufacturers don't work! There have been a few postings regarding using 4Mb SIMMs in a personal IRIS. Here is a summary of our experiences. ----------------------------------------------------------------------------- The SIMMs were purchased from Clearpoint, only current GSA schedule vendor, at a GSA price of $360/module. Half of the SIMMs are marked as (pardon the crude graphics): module ID tags: chip numbers: -------------- --------- TOSHIBA | TOSHIBA | | 9025AAA | TC514100J-80 | THM94000S-80 | | JAPAN | JAPAN 9020HDK -------------- --------- and the other half (Hitachi) have no module IDs, only chip numbers: JAPAN R200 9026 2NN HM514100JP8H We exchanged these for more Toshiba modules: -------------- --------- TOSHIBA | TOSHIBA | | 9018AAA | TC514100J-80 | THM94000S-80 | | JAPAN | JAPAN 9016HDK -------------- --------- ----------------------------------------------------------------------------- In the descriptions below, 0 = empty slot, 1 = 1Mb SIMM, 2 = 2Mb SIMM, H = 4Mb Hitachi SIMM, T = 4Mb Toshiba SIMM. SGI supports 2Mb SIMMs. If you use them the installation is: 2211 2211 For 24Mb. Note: you MUST(!) install 2211 2211 the 1Mb SIMMs behind the 2Mb SIMMs. For 32Mb of total memory, the installation pattern is: 2222 2222 For 32Mb. 2222 2222 The memory configurations that we have tried are: 1100 1100 Came up as 8Mb (correct) 1100 1100 1111 1111 Came up as 16Mb (correct) 1111 1111 TT11 TT11 Came up as 64Mb (wrong) TT11 TT11 T000 T000 Came up as 16Mb (correct) T000 T000 TT00 TT00 Came up as 32Mb (correct) TT00 TT00 HH00 HH00 Came up as 0Mb (wrong!!) HH00 HH00 TH00 TH00 Came up as 32Mb (correct) TH00 TH00 TTH0 TTH0 Came up as 48Mb (correct) TTH0 TTH0 TTHH TTHH Came up as 64Mb (correct) TTHH TTHH 11TT 11TT Comes up as 16Mb 11TT 11TT It appears as though the machine checks the first bank of chips (port 0) to determine the chip size and assumes that the rest are the same. The Hitachi 4Mb SIMMs are NOT correctly detected. ----------------------------------------------------------------------------- Our thanks to Clearpoint Research for being gratious enough to exchange the Hitachi SIMM modules for Toshiba modules (overnight!).   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05423; 15 Sep 90 11:27 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab05352; 15 Sep 90 11:06 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05331; 15 Sep 90 10:57 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa10837; 15 Sep 90 10:55 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09244; Sat, 15 Sep 90 07:44:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 90 02:39:39 GMT From: Jody Winston Organization: Shell Oil, Bellaire Research Center Subject: screen lock Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a screen lock program for the Iris like either Sun's lockscreen or X's xlock? Jody Winston uunet!shellbrc!jody 3737 Bellaire Blvd. (713) 663-2676 Hoston, TX 77001   Received: from vmb.brl.mil by VMB.BRL.MIL id aa05905; 15 Sep 90 14:38 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa05841; 15 Sep 90 14:07 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa05812; 15 Sep 90 13:54 EDT Received: from enh.nist.gov by VGR.BRL.MIL id aa11174; 15 Sep 90 13:46 EDT Received: from poly1.nist.gov by ENH.NIST.GOV; Sat, 15 Sep 90 13:47 EDT Received: by poly1.nist.gov (5.52/890607.SGI) (for @enh.nist.gov:info-iris@brl.mil) id AA16066; Sat, 15 Sep 90 13:47:31 EDT Date: Sat, 15 Sep 90 13:47:31 EDT From: rbriber@poly1.nist.gov Subject: GNU bash To: info-iris@BRL.MIL Message-id: <9009151747.AA16066@poly1.nist.gov> X-Envelope-to: info-iris@brl.mil Opps, pardon the ignorance but what does GNU's bash do? -- ---------------------------------------------------------------------------- | Adios Amoebas, | "I've tried and I've tried and I'm still mystified, | | Robert Briber | I can't do it anymore and I'm not satisfied." | | 224/B210 NIST | --Elvis | | Gaithersburg, MD |------------------------------------------------------| | 20899 USA | rbriber@poly1.nist.gov (Internet) | |(301) 975-6775(voice)| rbriber@enh.nist.gov (Internet) | |(301) 975-2128 (fax) | rbriber@nbsenh (Bitnet) | ----------------------------------------------------------------------------   Received: from vmb.brl.mil by VMB.BRL.MIL id aa09680; 16 Sep 90 1:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa09182; 16 Sep 90 0:58 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa09161; 16 Sep 90 0:52 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa13181; 16 Sep 90 0:41 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22644; Sat, 15 Sep 90 21:41:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 90 19:56:54 GMT From: Tom Weinstein Organization: Silicon Graphics Inc. Subject: Re: Bash for 4D/25 Message-Id: References: <9009111436.AA09719@banach.aca.mcc.com>, <17450008@hpfcdj.HP.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17450008@hpfcdj.HP.COM> jayavant@hpfcdj.HP.COM (Rajeev Jayavant) writes: > / hpfcdj:comp.sys.sgi / tomw@orac.esd.sgi.com (Tom Weinstein) / 10:01 am Sep 11, 1990 / >> Bash will work under IRIX-3.3 whenever Brian gets around to releasing >> version 1.06. >> >> -- >> Tom Weinstein >> Silicon Graphics, Inc., Entry Systems Division, Window Systems >> tomw@orac.esd.sgi.com >> Any opinions expressed above are mine, not sgi's. >> ---------- > I spent some time last weekend porting bash-1.05 to Irix. I currently > have it running on a 120GTX under 3.2 and on a 210GTX under 3.3. I > gave up trying to get job control working under 3.2, but it seems to > work fine under 3.3. I only made minor changes to config.h, > machines.h, jobs.c, and nojobs.c to get things working. > I have sent a message to Brian informing him that I have what appears > to be a working version for Irix, but have not heard back from him > yet. If bash-1.06 is not going to be released anytime soon, I can dig > up the original 1.05 sources and generate some diffs. > Rajeev Four months ago I gave Brian code to make Bash work with job control under Irix-3.3, and that code will be in bash-1.06. I never tried to make it work under 3.2, though. -- Tom Weinstein Silicon Graphics, Inc., Entry Systems Division, Window Systems tomw@orac.esd.sgi.com Any opinions expressed above are mine, not sgi's.   Received: from vmb.brl.mil by VMB.BRL.MIL id aa12389; 16 Sep 90 15:18 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa12302; 16 Sep 90 14:36 EDT Received: from vat.brl.mil by VMB.BRL.MIL id aa12295; 16 Sep 90 14:24 EDT Date: Sun, 16 Sep 90 14:23:04 EDT From: Earl Weaver (VLD/ASB) To: info-iris@BRL.MIL Subject: TeX driver wanted Message-ID: <9009161423.aa19654@VAT.BRL.MIL> Anybody have a (PostScript) driver for the NewGen laser printer (either 400x400 dpi or 800x400 dpi) under TeX? Also, anybody have TROFF font files (binaries for the Personal Iris) for the same printer?   Received: from vmb.brl.mil by VMB.BRL.MIL id aa13200; 16 Sep 90 23:32 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa13113; 16 Sep 90 22:50 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa13104; 16 Sep 90 22:40 EDT Received: from phvax.smithkline.com by VGR.BRL.MIL id aa15892; 16 Sep 90 22:37 EDT Received: from PHVAX.DECnet MAIL11D_V3 by smithkline.com (5.57/Ultrix2.4-C) id AA00690; Sun, 16 Sep 90 22:30:21 EDT Date: Sun, 16 Sep 90 22:30:21 EDT Message-Id: <9009170230.AA00690@smithkline.com> From: dixons%phvax.dnet@smithkline.com To: "info-iris@brl.mil %INET.dnet"@smithkline.com Cc: "fsfacca@avelon.lerc.nasa.gov %INET.dnet"@smithkline.com Subject: RE: A problem with xhost? Tony Facca (fsfacca@avelon.lerc.nasa.gov) writes: >I have a question about the xhost program. Actually, what I am trying to do >is use toolchest to open xterm clients on remote machines. Under 3.2 >this worked just fine. I do an "xhost remote_host" and follow that up >with "rsh remote_host xterm -display local_host:0" [basically] > >Anyway, I now have 3.3 running on several of the systems and this method no >longer works. I think its a problem with xhost as evidenced by the following: [etc] I have noticed a similar problem with gettin xhost to pay attention to commands. It seems to respond OK but then forgets what you tell it. It occured to me that maybe I needed to have the X server up and running before using xhost so I started up xclock and then tried xhost. That solved the problem for me. I don't think that this is the behaviour under 3.2 but seems to happen under 3.3. Also, I haven't gone back to see if the xhost changes are remembered after you log out or not. See if that works for you. Scott Dixon (dixons@smithkline.com)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21638; 17 Sep 90 15:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab21090; 17 Sep 90 15:00 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20975; 17 Sep 90 14:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa19665; 17 Sep 90 14:36 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07256; Mon, 17 Sep 90 11:32:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 90 23:56:07 GMT From: Paul Haeberli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Has anyone ported gcc to IRISes yet? Message-Id: <69474@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for a port of gcc to IRIS 4D machines. If you've done the port please contact me. thanx!! paul haberli paul@sgi.com 415-962-3665   Received: from vmb.brl.mil by VMB.BRL.MIL id aa22213; 17 Sep 90 15:42 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20601; 17 Sep 90 14:34 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20358; 17 Sep 90 14:15 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa19521; 17 Sep 90 14:08 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06107; Mon, 17 Sep 90 11:02:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 90 21:34:11 GMT From: Robert Viduya Organization: Office of Information Technology, Georgia Tech Subject: Mouse cleaning Message-Id: <13726@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have any suggestions as to what the best way to clean mice feet is? Our visualization lab has been in operation over a year now and over the months, those felt pads under the mice have accumulated a lot of gunk; real sticky gunk that makes the mouse pad stick to the mouse. One of our users evidently got real frustrated and ripped the felt pads off. That fixed the problem for a bit but the mouse eventually scratched the mouse pad up so bad that the whole thing is now useless. I've tried a couple of chemical cleaners with no luck. I'm somewhat cautious trying them because I don't want the glue holding the felt pads to weaken. I've also heard a rumor that the felt pads can be replaced with white plastic (mylar?) pads that ride a lot more smoothly. Has anyone tried this? Will they scratch up the mouse pad too and, if not, where do we get them? robert -- Robert Viduya robert@shangri-la.gatech.edu Technical Services / Office of Information Technology Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from vmb.brl.mil by VMB.BRL.MIL id ab21638; 17 Sep 90 15:11 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac21090; 17 Sep 90 15:00 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20978; 17 Sep 90 14:45 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa19669; 17 Sep 90 14:37 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06911; Mon, 17 Sep 90 11:21:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 90 23:16:19 GMT From: Steve Lehar Organization: Boston University Center for Adaptive Systems Subject: Re: Mouse cleaning Message-Id: References: <13726@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Re: problem with sticky mouse feet I've found that scraping the felt pads on the mouse occasionally with a sharp knife seems to do the trick. The sticky stuff is generally so viscous that it does not impregnate the roots of the felt hairs, so that gentle scraping tends to roll it off in little chunks. If you have already treated the gunk with some kind of solvent, this scraping may not work, since you may have dissolved the stuff enough to let it really soak into the felt. -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@bucasb.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6741 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)   Received: from vmb.brl.mil by VMB.BRL.MIL id aa20162; 17 Sep 90 14:04 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa19304; 17 Sep 90 12:51 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa19287; 17 Sep 90 12:39 EDT Received: from Icarus.AE.MsState.Edu by VGR.BRL.MIL id aa18748; 17 Sep 90 12:30 EDT Received: from tardis.ae.msstate.edu by Icarus.AE.MsState.Edu (4.0/5.0s); id AA27885; Mon, 17 Sep 90 11:30:23 CDT Date: Mon, 17 Sep 90 11:30:23 CDT From: Larry Thorne Message-Id: <9009171630.AA27885@Icarus.AE.MsState.Edu> To: info-iris@BRL.MIL Subject: 4MB SIMMs on 4D/25 We're about to try installing some 4MB SIMMS in one of our 4D/25TGs. I've heard rumors that a certain ROM revision level is required for the PI to recognize 4MB SIMMs. Is this correct? If so, what ROM revision level is required? And, if a ROM revision level is required that's different from the one we have, how do we get the "new" one? Thanks in advance! Larry Thorne larryt@ae.msstate.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21090; 17 Sep 90 14:55 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa20336; 17 Sep 90 14:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20311; 17 Sep 90 14:13 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa19484; 17 Sep 90 14:01 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0988; Mon, 17 Sep 90 14:00:10 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Mon, 17 Sep 90 10:15 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA13295; Mon, 17 Sep 90 10:18:38 DSD Date: Mon, 17 Sep 90 10:18:38 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: ANSI argument prototype extraction To: info-iris@BRL.MIL Cc: davea@sgi.com Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009171718.AA13295@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil, davea@sgi.com I am converting my source to ANSI prototypes, and I was wondering if there was a utility that would generate a .h file of all the declarations for your source. I tried using the ctags program, but that truncates long lines. dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa21786; 17 Sep 90 15:21 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab20336; 17 Sep 90 14:20 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa20319; 17 Sep 90 14:13 EDT Received: from cunyvm.cuny.edu by VGR.BRL.MIL id aa19494; 17 Sep 90 14:02 EDT Received: from MCCLB0.MED.NYU.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0994; Mon, 17 Sep 90 14:00:39 EDT Received: from mcirps2.med.nyu.edu by MCCLB0.MED.NYU.EDU; Mon, 17 Sep 90 10:11 EDT Received: by mcirps2.med.nyu.edu (5.52/890607.SGI) (for @mcclb0.med.nyu.edu:info-iris@brl.mil) id AA13245; Mon, 17 Sep 90 10:14:18 DSD Date: Mon, 17 Sep 90 10:14:18 DSD From: karron%mcirps2.med.nyu.edu@cunyvm.cuny.edu Subject: tcsh lf-cr problems... To: info-iris@BRL.MIL Reply-to: karron%CMCL2.NYU.EDU@cunyvm.cuny.edu Message-id: <9009171714.AA13245@mcirps2.med.nyu.edu> X-Envelope-to: info-iris@brl.mil I obtained the tcsh binary from ftp.brl.mil, and it works just fine except... When I abort from a command, and sometimes for no apparent reason at all, tcsh will scramble output, no longer outputing a cr. This causes all of the lines to wrap. I can't seem to reset the stty mode with the stty command, and the only way to reset things is to logout and log back in. Does anyone have a fix for this problem ? Also, If I want to rebuilt the program, I need the csh source. Has anyone rebuilt the program with csh source on iris, and where can I get the source ? Is this the same csh source that sgi uses ? (the csh source that tcsh is the mods to ) dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+   Received: from vmb.brl.mil by VMB.BRL.MIL id aa23735; 17 Sep 90 17:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23111; 17 Sep 90 17:00 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab23098; 17 Sep 90 16:54 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa20758; 17 Sep 90 16:49 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12667; Mon, 17 Sep 90 13:44:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 07:52:17 GMT From: Geoff Collyer Organization: Statistics, U. of Toronto Subject: lack of symbol tables in sgi distributions Message-Id: <1990Sep17.075217.18381@utstat.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I note with displeasure that SGI ships binaries stripped of symbol tables, presumably to save scarce and expensive bytes on disk (:-), and not merely to make miserable the lives of users who lack source. Given the ever-dropping prices of disks and the utility of symbol tables (e.g. for giving stack traces of misbehaving programs to the hotline, or for patching global variables), is there any reason for SGI to continue shipping stripped binaries? I realise that COFF symbol tables can get large, but even minimal symbol tables (i.e. not enough for source-language debugging) would help. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id ab23735; 17 Sep 90 17:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa23560; 17 Sep 90 17:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa23486; 17 Sep 90 17:32 EDT Received: from ugw.utcs.utoronto.ca by VGR.BRL.MIL id aa20904; 17 Sep 90 17:19 EDT Received: from VM.NRC.CA (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57417; Mon, 17 Sep 90 17:16:54 EDT Received: by NRCVM01 (Mailer R2.06) id 0681; Mon, 17 Sep 90 16:47:31 EDT Date: Mon, 17 Sep 90 16:42:12 EDT From: Wayne Podaima Organization: National Research Council, Computing Services, Ottawa CAN Subject: Driver for Tek 4697? To: info-iris@vgr.brl.mil Message-Id: <90Sep17.171654edt.57417@ugw.utcs.utoronto.ca> One of our users is thinking of purchasing a Tektronix 4697 ColorQuick inkjet printer. Has anyone written a driver for such a beast (apparently it does not use the same commands as a 4692/3)? Thanks in advance, Wayne Podaima   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24153; 17 Sep 90 19:35 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab24101; 17 Sep 90 19:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab24090; 17 Sep 90 19:04 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21338; 17 Sep 90 18:58 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16721; Mon, 17 Sep 90 15:25:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 15:50:57 GMT From: Rob Hooft Organization: University of Utrecht, Dept. of Physics Subject: Audio Message-Id: <1477@ruunsa.fys.ruu.nl> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is somebody having some demo program for /dev/audio, preferably C-source? I'd love to play with all possibilities of our 4D/20. -- Rob Hooft, Chemistry department University of Utrecht. hooft@hutruu54.bitnet hooft@chem.ruu.nl chooft@fys.ruu.nl   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24401; 17 Sep 90 20:09 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24295; 17 Sep 90 19:59 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24277; 17 Sep 90 19:54 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21461; 17 Sep 90 19:40 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18601; Mon, 17 Sep 90 16:23:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 17:09:54 GMT From: Tim Anderson Organization: Open Communication Forum Subject: Re: Mouse cleaning Message-Id: <1990Sep17.170954.12509@agora.uucp> References: <13726@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL And the tech-support hotline laughed at me when I stated that I'd rather have a mechanical mouse! Granted that when the opticals run they run better. Unfortunately in the 'real' world we have to deal with things like DUST, HAIR, COFFEE, COKE, dropping books on that stupid opti-pad, etc, etc... On my Microsoft (tm) mechanical mouse all I have to do is pull out the mouse ball, clean out the dust bunnies, put it back together and I have a new mouse. The opti-mouse, however, is junk if I happen to loose the opti-pad, scratch the opti-pad, or (heaven forbid) want to try to turn the opti-pad 90 degrees. I won't even tell you about the time that we accidently swapped the opti-pad with another mouse's opti-pad when moving 5 computers to a convention... A choice between opti and mechanical would be nice! tima@agora.hf.intel.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24641; 17 Sep 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa24101; 17 Sep 90 19:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24090; 17 Sep 90 19:04 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21336; 17 Sep 90 18:57 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17212; Mon, 17 Sep 90 15:42:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 17:00:47 GMT From: Chris Wagner Organization: Silicon Graphics, Research & Development Subject: Re: logical volumes under 3.3 Message-Id: <1990Sep17.170047.14630@odin.corp.sgi.com> References: <13693@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13693@hydra.gatech.EDU>, robert@shangri-la.gatech.edu (Robert Viduya) writes: > We got 3.3 earlier this week and I've been reading over the manuals trying > to plan an install later this month. One of our systems has 4 780M disks > and I was thinking of combining parts of all four into one giant logical > volume and use it for user file space (one of the biggest pains in the > rear on our other systems has been balancing disk utilitization across > multiple file systems dedicated to users). Well, as I was working out > the details, I realized that the resulting logical volume would end up > being well over 2G long. Furthermore, we may be adding more disk in the > future and I'd like to be able to just add them to the logical volume. > What happens if it goes over 4G? With a 32-bit int/long, we can get a > maximum of 2G (signed) or 4G (unsigned). The 3.3 manuals say you can keep > adding disk partitions to logical partitions and doesn't mention any limits > at all. Somehow I would be very surprised if this were true (pleasantly > surprised, but surprised nonetheless). > > The man page for statfs(2) seems to indicate that it could handle a > file system that was 1024G long (using 512-byte blocks), but the man > page for stat(2) indicates that the max file size is 2G. If this is > truely the case, I'd be satisfied; we probably aren't going to have very > many files over a gigabyte. > > Has anyone who's gotten 3.3 played with this stuff yet? Is there a limit > on how large logical volumes can be? > > robert Well, there is some missing dicumentation! In 3.3 the maximum file size is still 2G (cause of lseek, etc). The maximum file SYSTEM size is 8G due currently to on-disk space limitations. Chris Wagner   Received: from vmb.brl.mil by VMB.BRL.MIL id ab24641; 17 Sep 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab24401; 17 Sep 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24376; 17 Sep 90 20:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21483; 17 Sep 90 19:51 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18970; Mon, 17 Sep 90 16:35:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 18:18:22 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: logical volumes under 3.3 Message-Id: <69499@sgi.sgi.com> References: <13693@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <13693@hydra.gatech.EDU>, robert@shangri-la.gatech.edu (Robert Viduya) writes: > Has anyone who's gotten 3.3 played with this stuff yet? Is there a limit > on how large logical volumes can be? Guess this is my baby, since I'm the logical volume originator. Yes, logical volumes (and filesystems thereon) may exceed 2 gig, though the size of regular files is still limited to 2 gig by the 'signed long' nature of the lseek argument. (And the fact that regular filesize is stored internally as a signed long, which precludes playing any tricks with SEEK_CUR or SEEK_END). There is actually an 8 gig limit to the size of a filesystem, imposed by some data structures in the on-disk filesystem stuff. Logical volumes themselves have no (practical) limit, but 8 gig is the maximum size of filesystem you can put on one. Oops, I don't think this is documented in the mkfs man page... mea culpa for that: however, you will get a reasonably self-explanatory error message from mkfs if you try to make a filesystem bigger than 8 gig. Or if you try to grow an existing one to over 8 gig with growfs (just a little plug here, folks: existing filesystems can be grown without losing their contents in 3.3. Check out growfs(1M)!). Two further hints: if you're concerned with balancing disk usage, it's probably worth setting your logical volume up as a striped volume; this will distribute traffic evenly amoung your disks and give you a better overall throughput in a multiuser situation. Also, with SCSI disks, you will get improved performance if you use the mount option to increase the filesystem "logical block size" to larger than its default. See the mount(1m) man page: basically you should add "lbsize=65536" to the mount options. Dave Higgen (daveh@xtenk.asd.sgi.com)   Received: from vmb.brl.mil by VMB.BRL.MIL id ac24641; 17 Sep 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac24401; 17 Sep 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab24376; 17 Sep 90 20:08 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21488; 17 Sep 90 19:52 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19323; Mon, 17 Sep 90 16:44:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 18:48:43 GMT From: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!kuhub.cc.ukans.edu!arritt@tut.cis.ohio-state.edu Organization: University of Kansas Academic Computing Services Subject: 3.3 fortran problem Message-Id: <25656.26f4d43b@kuhub.cc.ukans.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone been having problems compiling Fortran code under 3.3? I just installed 3.3 and tried to compile one of the models I've been using, and got the following error message: f77 -static -Olimit 1400 -O1 -c hill2dc.f ugen: internal: error in write, writing 6528 bytes instead of 8192 bytes *** Error code 1 Stop. What does this mean? I've never seen anything like it before. The code worked fine under 3.2 and is totally unmodified since before the 3.3 installation (I can show an ls -lrt to prove it ...) Several other pieces of code of comparable length and complexity compile properly under 3.3, so it's apparently not that the code is too big. I might add that the error occurs with both -O1 and -O2 for whatever it's worth (haven't tried with no optimization; that isn't viable because the jobs take 20-30 cpu hours even under -O2). Thanks for whatever help you can provide. (I've had no luck with the so-called "hotline".) ________________________________________________________________________ Raymond W. Arritt | Assistant Professor | Dept. of Physics and Astronomy | "everyone knew that as time went Univ. of Kansas | by we'd get a little bit older Lawrence, KS 66045 | and a little bit slower..." arritt@kuhub.cc.ukans.edu | arritt@ukanvax.bitnet |   Received: from vmb.brl.mil by VMB.BRL.MIL id ad24641; 17 Sep 90 20:24 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ae24401; 17 Sep 90 20:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24381; 17 Sep 90 20:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21557; 17 Sep 90 20:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15928; Mon, 17 Sep 90 15:01:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 15:02:45 GMT From: ZUCCOLA Organization: Georgia Institute of Technology Subject: CPU Priority Message-Id: <13746@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was wondering is there a way to control who can use which CPU on a power series machine. I understand that such a thing is possible on the Convex and other MIPS machines. What we'd like to be able to do is say these list of users have priority on these CPUs and if they're busy and the people on the list need a CPU, they have priority and the other job(s) is/are kicked off that CPU. Thanx in advance, H----- |==================================|===================================| | HARMON JAY ZUCCOLA |Internet zuccola@max.gatech.edu | |Dept of Chemistry and Biochemistry| | | Georgia Institute of Technology |FAX 404-894-7452 | | Atlanta, Georgia 30332-0400 | | |==================================|===================================| | As the area of light increases, so does the circumference of darkness| | -A. Einstein | |======================================================================|   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24792; 17 Sep 90 20:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad24401; 17 Sep 90 20:13 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24379; 17 Sep 90 20:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21492; 17 Sep 90 19:58 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17988; Mon, 17 Sep 90 16:03:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 17:05:36 GMT From: Andrea Malagoli Organization: U of Chicago - Astronomy & Astrophysics Subject: Lockscreen Message-Id: <1990Sep17.170536.27140@midway.uchicago.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is my first posting to the network. I have developed a lockscreen utility for Irises 4D. It works on my PI. I am no expert C programmer, so I would appreciate receiving comments and/or revised versions of this program. Andrea Malagoli Astronomy Department University of Chicago 5640 S.Ellis Ave. Chicago, IL 60613 e-mail: malagoli@mhd4.uchicago.edu -------------------------cut here---------------------------- /* * L O C K S C R E E N * * lockscreen utiliy for the SGI machines * * lockscreen allows a user to lock the access to the monitor * without logging out. This is useful when one needs to go * out of the office and does not want to leave the machine * accessible to anybody. * * After calling lockscreen, the screen gets blank and a bouncing * ball appears on a black background. To unlock, press the * RIGHT MOUSE BUTTON. When the prompt asking for the password * appears, just enter the correct password. * * Just compile with * cc -o lockscreen lockscreen.c -lgl_s * * This code has been written borrowing some routines available * in 4Dgifts/examples/grafix. * * WRITTEN BY: Andrea Malagoli * Astronomy Department * University of Chicago * malagoli@mhd.uchicago.edu * DATE: 15 June 1990 * */ #include #include #include #include #include Icoord maxxval; /* width of prompt window ( in screen coords) */ long menu; /* defined menu's identifier */ long oldmode; /* previous drawmode */ char filename[20]; /* array to store standard input for the prompt */ struct passwd mypwd; /* User information from /etc/passwd */ int curpos, prevpos; /* cursor current and previous positions */ long xvelocity = 0, yvelocity = 0; /* initial ball velocity */ int iter=1; #define XMIN 0 #define XMAX XMAXSCREEN #define YMIN 0 #define YMAX YMAXSCREEN /* setup for the prompt box */ Screencoord mask1, mask2, mask3, mask4; /* full window */ main() { Device dev; short val; long menuval; int check_pwd(); init(); hyde_cursor(); xvelocity = (long int) (rand(0.6)/32767.*150); yvelocity = (long int) (rand(0.3)/32767.*150); /* process events forever */ while(TRUE) { drawball(); while( qtest() ){ dev=qread(&val); switch(dev) { case RIGHTMOUSE: if(val) { color( BLUE ); clear(); swapbuffers(); mktxtport(); if(check_pwd(filename) == 1){ endit(); break; } else break; } break; default: break; } } } } endit() { clr_overlay(); gexit(); exit(0); } init() { /* do all the basic graphics setup */ ginit(); /* enable overlay, and be sure rubber band box will be red */ drawmode(OVERDRAW); overlay(2); mapcolor(BLACK, 0, 0, 0); mapcolor(RED, 255, 0, 0); drawmode(NORMALDRAW); doublebuffer(); gconfig(); maxxval = 590; /* prompt window's width in pixels */ /* initial values for restoring screenmask */ getscrmask(&mask1, &mask2, &mask3, &mask4); qdevice(RIGHTMOUSE); } clearpup() { /* clear the pup plane where we asked for the filename */ setupprompt(0); color(PUP_CLEAR); clear(); /* clear the PUPDRAW plane */ endprompt(); } clr_overlay() { /* clear any left over junk in overlay and pup planes */ drawmode(OVERDRAW); color(BLACK); clear(); drawmode(PUPDRAW); color(PUP_CLEAR); clear(); drawmode(NORMALDRAW); } /* screen positionings of prompt box */ #define FILEX 340 #define FILEY 500 #define FILEYHI (30+FILEY) /* 30 pixels hi */ #define TEXTX (FILEX+5) #define TEXTY (FILEY+10) /* Clear prompt, move to start of prompt box, and output requested prompt */ clearprompt(prmpt) char *prmpt; { color(PUP_WHITE); clear(); color(PUP_BLACK); linewidth(2); recti(FILEX+2, FILEY+2, FILEX+maxxval-6, FILEYHI-3); linewidth(1); cmov2i(TEXTX, TEXTY); charstr(prmpt); } setupprompt(sav) { if(sav) oldmode = getdrawmode(); drawmode(PUPDRAW); /* so can clear just text */ scrmask(FILEX, (Screencoord)(FILEX+maxxval-6), FILEY, FILEYHI); } endprompt() { scrmask(mask1, mask2, mask3, mask4); /* restore old */ drawmode(oldmode); } mktxtport() /* get name of file */ { int curstrlen; short c; char *cc = "a"; char *str; Device dev; long maxwidth; size_t maxlen = sizeof(filename); static char fprompt[] = "Enter Password for "; char *prmpt = fprompt; mypwd = *getpwuid( getuid() ); /* Get User ID and encrypted password */ prmpt = strcat(fprompt,mypwd.pw_name); prmpt = strcat(prmpt,": "); maxwidth = (XMAXSCREEN-11) - (FILEX + strwidth(fprompt)); setupprompt(1); /* display prompt */ curstrlen = 0; clearprompt(prmpt); prevpos = curpos; curpos = TEXTX + strwidth(prmpt) + 2; draw_bar(); qdevice(KEYBD); /* read until carriage return or linefeed */ while(dev = qread(&c)) { if(dev != KEYBD) continue; /* don't care */ switch(c) { case '\027': /* ctrl-W sets back to start of prompt */ curstrlen = 0; clearprompt(prmpt); prevpos = curpos; curpos = TEXTX + strwidth(prmpt) + 2; draw_bar(); break; case '\n': case '\r': goto done; case '\b': if(curstrlen) { *cc = filename[--curstrlen]; filename[curstrlen] = '\0'; clearprompt(prmpt); /* display rightmost portion */ for(str=filename; *str && strwidth(str) > maxwidth; str++); prevpos = curpos; curpos = curpos - strwidth(cc); draw_bar(); /* charstr(str); */ } break; default: str = &filename[curstrlen]; filename[curstrlen++] = c; filename[curstrlen] = '\0'; *cc = c; prevpos = curpos; curpos = curpos + strwidth(cc); draw_bar(); /* charstr(str); */ break; } } done: unqdevice(KEYBD); endprompt(); clearpup(); clr_overlay(); } int check_pwd(char *pww) { char *salt="12"; strncpy(salt, mypwd.pw_passwd, 2); if( strcmp(mypwd.pw_passwd,crypt(pww,salt)) == 0 ){ return 1; } else { return 0; } } drawball() { static xpos = 500,ypos = 500; long radius = 20; if( iter >= 200 ) { xvelocity = (long int) (rand(0.6)/32767.*60); yvelocity = (long int) (rand(0.3)/32767.*60); iter = 0; } iter++; color(BLACK); clear(); xpos += xvelocity; ypos += yvelocity; if (xpos > XMAX - radius || xpos < XMIN + radius) { xpos -= xvelocity; xvelocity = -xvelocity; } if (ypos > YMAX - radius || ypos < YMIN + radius) { ypos -= yvelocity; yvelocity = -yvelocity; } color(YELLOW); circfi(xpos, ypos, radius); swapbuffers(); } hyde_cursor() { short index; static short blank[16][16]={{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}}; curstype(C16X1); drawmode(CURSORDRAW); defcursor(1, blank); setcursor(1, 0, 0); drawmode(NORMALDRAW); } draw_bar() { static int ydown = (FILEY + 5); static int yup = (FILEYHI - 7); int vert[2]; linewidth(1); if( prevpos != curpos ){ color( PUP_WHITE ); bgnline(); vert[0] = prevpos; vert[1] = ydown; v2i(vert); vert[0] = prevpos; vert[1] = yup; v2i(vert); endline; color( PUP_BLACK ); bgnline(); vert[0] = curpos; vert[1] = ydown; v2i(vert); vert[0] = curpos; vert[1] = yup; v2i(vert); endline; } else { color( PUP_BLACK ); bgnline(); vert[0] = curpos; vert[1] = ydown; v2i(vert); vert[0] = curpos; vert[1] = yup; v2i(vert); endline; } }   Received: from vmb.brl.mil by VMB.BRL.MIL id ab24792; 17 Sep 90 20:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id af24401; 17 Sep 90 20:14 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab24381; 17 Sep 90 20:09 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21559; 17 Sep 90 20:00 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15965; Mon, 17 Sep 90 15:02:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 14:48:11 GMT From: Dave Olson Organization: Silicon Graphics, Inc. Mountain View, CA Subject: Re: lack of symbol tables in sgi distributions Message-Id: <1990Sep17.144811.13199@odin.corp.sgi.com> References: <1990Sep17.075217.18381@utstat.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In <1990Sep17.075217.18381@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: | I note with displeasure that SGI ships binaries stripped of symbol | tables, presumably to save scarce and expensive bytes on disk (:-), and | not merely to make miserable the lives of users who lack source. | Given the ever-dropping prices of disks and the utility of symbol tables | (e.g. for giving stack traces of misbehaving programs to the hotline, | or for patching global variables), is there any reason for SGI to | continue shipping stripped binaries? I realise that COFF symbol tables | can get large, but even minimal symbol tables (i.e. not enough for | source-language debugging) would help. There are many reasons for shipping stripped binaries, depending on who you talk to (few of the companies I have worked for have ever shipped unstripped binaries), but certainly disk spaces is a large one. MIPS compilers generate LARGE symbol tables. In a not atypical case, here are the sizes of /bin/csh on my machine, stripped, and unstripped: -rwxr-xr-x 1 olson engr 367280 Aug 9 10:10 csh -rwxr-xr-x 1 olson engr 221184 Sep 17 07:43 csh Note that 40% of the file is removed by stripping it... While it is true that most of customers are now buying larger disk drives, telling them to add another 100 Mb or so, just so binaries could be patched wouldn't go over to well! After all, we like to think we don't ship TOO many buggy programs :). -- Dave Olson Life would be so much easier if we could just look at the source code.   Received: from vmb.brl.mil by VMB.BRL.MIL id ac24792; 17 Sep 90 20:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id af24641; 17 Sep 90 20:28 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24606; 17 Sep 90 20:21 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21584; 17 Sep 90 20:05 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19944; Mon, 17 Sep 90 16:59:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 20:09:17 GMT From: Steven J Flynn Organization: University of Delaware Subject: EMACS for the Personal Iris Message-Id: <30735@nigel.ee.udel.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know where I can get a copy of EMACS for the Personal Iris. The source code is not important, but would be welcomed. Thanks a bunch! Steve Flynn sflynn@huey.udel.edu   Received: from vmb.brl.mil by VMB.BRL.MIL id aa24942; 17 Sep 90 20:54 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ad24792; 17 Sep 90 20:44 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa24752; 17 Sep 90 20:33 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21629; 17 Sep 90 20:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20199; Mon, 17 Sep 90 17:05:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 19:58:37 GMT From: James Helman Organization: Stanford University Subject: Re: xterm key remapping Message-Id: References: <1990Sep14.170021.28769@eagle.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL X keyboard bindings can be changed globally using xmodmap, e.g. the following binds the caps lock key to and changes the backspace key to . (Which is after all, where they were before international keyboards forced finger dances such as the Control Stretch Twist or Control Two Hand Boogie upon us.) xmodmap - << xxx clear lock add control = Caps_Lock keycode 66 = Delete Delete xxx xmodmap -pk prints out the keyboard table. If you want to change particular keys under xterm, change mouse button actions or bind function keys to strings, you can modify xterm's resources to create your own keymaps. The following lines in a .Xdefaults file or used as input to xrdb will create special keymaps for the function keys. XTerm*VT100.Translations: #override \ F1: string("ls -atl") string(0x0d) \n\ F2: string("ls -alt | head") string(0x0d) \n\ F10: keymap(mh) \n\ F11: keymap(dbx) \n\ F12: keymap(None) \n\ XTerm*VT100.mhKeymap.translations: \ F1: string("prev") string(0x0d) \n\ F2: string("comp") string(0x0d) \n\ F3: string("show") string(0x0d) \n\ F4: string("repl") string(0x0d) \n\ F5: string("next") string(0x0d) \n\ F6: string("forw") string(0x0d) \n\ F7: string("scan last:10") string(0x0d) \n\ F8: string("rmm") string(0x0d) XTerm*VT100.dbxKeymap.translations: \ F1: string("next") string(0x0d) \n\ F2: string("step") string(0x0d) \n\ F3: string("continue") string(0x0d) \n\ F4: string("print ") insert-selection(PRIMARY, CUT_BUFFER0)\n\ F5: string("stop at ") insert-selection(PRIMARY, CUT_BUFFER0)\n\ F6: string("up") string(0x0d) \n\ F7: string("down") string(0x0d) \n\ F8: string("status") string(0x0d) Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25106; 17 Sep 90 21:29 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25078; 17 Sep 90 21:19 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25071; 17 Sep 90 21:10 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21740; 17 Sep 90 21:05 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22159; Mon, 17 Sep 90 17:55:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 19:46:16 GMT From: M White Organization: Edinburgh University Computing Service Subject: flight with StereoView Message-Id: <6379@castle.ed.ac.uk> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello there, has anyone out there hacked flight to work with StereoView? I am only interested from a technical viewpoint of course :-) Matthew -- Matthew White - Visualisation Support - Edinburgh Parallel Computing Centre "All right, hands up if you think it was a Russian water tentacle." - Abyss   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25212; 17 Sep 90 21:44 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25106; 17 Sep 90 21:34 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25097; 17 Sep 90 21:23 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21769; 17 Sep 90 21:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22855; Mon, 17 Sep 90 18:09:02 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 22:04:53 GMT From: John Edelson Organization: Silicon Graphics, Inc. Subject: Neural Network Software for the IRIS Message-Id: <1990Sep17.220453.20458@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am trying to measure the level of interest in Neural Network Software running on the IRIS. If you are an IRIS user and would be interested in neural network software, I'd like to know about it. I am currently working with a neural network vendor and I'm trying to figure out for them the level of demand for their package on the IRIS. John Edelson edelson@sgi.com 415 335-1532   Received: from vmb.brl.mil by VMB.BRL.MIL id aa25279; 17 Sep 90 21:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab25212; 17 Sep 90 21:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25181; 17 Sep 90 21:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21772; 17 Sep 90 21:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23123; Mon, 17 Sep 90 18:14:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 23:10:14 GMT From: ZUCCOLA Subject: 2D Drawing Tools Message-Id: <13775@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a simple 2D drawing program on the SGI like Cricket draw,macpaint etc., that outputs postscript files or other formats for easy conversioN? (Cricket draw and macpaint draw simple things like circles,rectangles,text etc...). Thanx in advance, H----- | HARMON JAY ZUCCOLA |Internet zuccola@max.gatech.edu | |Dept of Chemistry and Biochemistry| | | Georgia Institute of Technology |FAX 404-894-7452 | | Atlanta, Georgia 30332-0400 | |   Received: from vmb.brl.mil by VMB.BRL.MIL id ab25279; 17 Sep 90 21:58 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ac25212; 17 Sep 90 21:47 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab25181; 17 Sep 90 21:36 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa21774; 17 Sep 90 21:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23206; Mon, 17 Sep 90 18:16:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 23:23:35 GMT From: Rainer Malzbender Organization: University of Colorado, Boulder Subject: Personal Iris 4D/25 Parallel Port Pinout Message-Id: <26428@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is the parallel port on a 4D/25 just like a PC parallel port ? If the pinout is in the manuals, SGI did a good job of hiding it. I want to hook up a Laserjet II to it. Thanks for any help. -- Rainer Malzbender "Having a deep aversion to useless complication, Dept. of Physics God naturally chose the antisymmetric tensor U. of Colorado, Boulder as His medium of expression." - M. Schwartz   Received: from vmb.brl.mil by VMB.BRL.MIL id aa26018; 18 Sep 90 1:13 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa25941; 18 Sep 90 1:03 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa25939; 18 Sep 90 0:54 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa22332; 18 Sep 90 0:50 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28435; Mon, 17 Sep 90 21:40:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 01:27:31 GMT From: Jeff Doughty Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Need info on Lisp interpreters for SGI machines Message-Id: <1990Sep18.012731.23921@odin.corp.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A friend of mine will be developing some Lisp software for 4D machines. He is interested in experiences users have had with various Lisp packages (Franz Lisp, etc.). I would appreciate it if you could E-mail your comments to me (or post) so I can pass them on. Jeff Doughty IRIX group jeffd@norge.asd.sgi.com   Received: from vmb.brl.mil by VMB.BRL.MIL id aa26683; 18 Sep 90 2:52 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa26616; 18 Sep 90 2:41 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa26608; 18 Sep 90 2:35 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa22549; 18 Sep 90 2:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00515; Mon, 17 Sep 90 23:12:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 19:27:21 GMT From: Mike Yang Organization: Silicon Graphics, Inc. Subject: RE: A problem with xhost? Message-Id: <1990Sep17.192721.16107@relay.wpd.sgi.com> References: <9009170230.AA00690@smithkline.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <9009170230.AA00690@smithkline.com>, dixons%phvax.dnet@SMITHKLINE.COM writes: |> I have noticed a similar problem with gettin xhost to pay attention to |> commands. It seems to respond OK but then forgets what you tell it. The X server will reset itself when there are no clients. Therefore, if your server is running but you have no X clients, when you run xhost it establishes a connection, it does its stuff, it exits, the X server resets and effectively undoes what xhost did. The solution, as you noticed, is to run an X client to keep the server from resetting when xhost exits, ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786   Received: from vmb.brl.mil by VMB.BRL.MIL id aa26773; 18 Sep 90 3:02 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab26616; 18 Sep 90 2:41 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id ab26608; 18 Sep 90 2:35 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa22551; 18 Sep 90 2:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00647; Mon, 17 Sep 90 23:16:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Sep 90 20:17:11 GMT From: Bean Anderson Organization: Silicon Graphics Inc. Subject: Re: lack of symbol tables in sgi distributions Message-Id: <1990Sep17.201711.20000@relay.wpd.sgi.com> References: <1990Sep17.075217.18381@utstat.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1990Sep17.075217.18381@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes: |> I note with displeasure that SGI ships binaries stripped of symbol |> tables, presumably to save scarce and expensive bytes on disk (:-), and |> not merely to make miserable the lives of users who lack source. |> Given the ever-dropping prices of disks and the utility of symbol tables |> (e.g. for giving stack traces of misbehaving programs to the hotline, |> or for patching global variables), is there any reason for SGI to |> continue shipping stripped binaries? I realise that COFF symbol tables |> can get large, but even minimal symbol tables (i.e. not enough for |> source-language debugging) would help. |> -- |> Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu 1. The minimal SGI system has a 170MB drive (there's a ton of them in the field) and so our minimal software system must fit on that drive. Unstripped binaries would not fit. In addition, we generally don't want to force users to buy disk space for stuff that they may not use. 2. Tape space is, perhaps, even more important. Unstripped binaries would double the number of tapes required for a release. At our current size, that would add approximately $300,000 of cost per extra tape to our distribution cost. Our cost for the next release then will be approximately $1,000,000 extra just to have unstripped binaries. Those are two key reasons for stipping binaries. New distribution media (such as CD-ROM) will/may solve the second issue and maybe even the first as we could ship both stripped and unstripped binaries. Lastly, I totaly agree that some minimal symbol table information should be available. We are looking at that issue now. Bean   Received: from vmb.brl.mil by VMB.BRL.MIL id aa03198; 18 Sep 90 10:39 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id aa01465; 18 Sep 90 9:38 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa01426; 18 Sep 90 9:32 EDT Received: from ucbvax.Berkeley.EDU by VGR.BRL.MIL id aa24127; 18 Sep 90 9:20 EDT Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07090; Tue, 18 Sep 90 06:11:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 90 01:40:16 GMT From: Joel Tenenbaum Organization: SUNY, Purchase NY Subject: sendmail on a 3130 Message-Id: <6@purvid.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Our Ethernet LAN has just been connected to NyserNet. The sendmail.cf file which came with our 3130 system does not seem to be easily modifiable for inbound or outbound mail via the Internet connection (or I'm doing something wrong). The NyserNet folks sent along a more up to date sendmail.cf file which has a variety of macros, objects, and rules not present in the original. Should the old sendmail work with the new sendmail.cf aside from some revised file locations? Does anyone know of Iris-3130 source or binary code for this purpose. (I'll try the experiment and call SGI tomorrow but for the moment I'm seeking wisdom.) In a similar vein, I've seen but forgotten where sgi archives are available by anonymous ftp. Many thanks, Joel -- Joel Tenenbaum ...{yale,uunet}!hsi!mlfarm!purvid!joel