Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27262; 2 Mar 89 4:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27080; 2 Mar 89 3:40 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa27071; 2 Mar 89 3:25 EST Date: Thu, 2 Mar 89 3:25:40 EST From: Mike Muuss To: Info-Iris@BRL.MIL Subject: Troubles with shared libraries! Message-ID: <8903020325.aa27209@SPARK.BRL.MIL> I have been continuing to have problems moving binaries between diffrent SGI platforms when they are compiled with shared libraries. I consider being able to share binaries to be a highly desirable feature, and I intend to continue to "flog" this topic until something is decided. I have modified the Cakefile so that all programs in the BRL-CAD Package are compiled (linked) with -lgl_s (when using LIBFB), -lm, and -lc_s. I still have problems when calling the routine ps_open_PostScript(). In this particular test, I compiled the code on a 4D/70GT, and then ran it on a 120/GTX, with this result: 54 voyage> ./pix-fb /n/spark/m/cad/pix/star.pix Bus error (core dumped) 55 voyage> dbx ./pix-fb dbx version 1.31 Copyright 1987 Silicon Graphics Inc. Copyright 1987 MIPS Computer Systems Inc. Type 'help' for help. Reading symbolic information of `./pix-fb' . . . Process name from core dump: pix-fb Process died at pc 0xf02db00 of signal : bus error [using memory image in core] (dbx) where > 0 ps_open_PostScript(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) [0xf02dafc] 1 sgi_dopen(0x90, 0x100030c0, 0x200, 0x200, 0x0, 0x0) ["../libfb/if_4d.c":720, 0x402c90] 2 fb_open(0x2, 0x200, 0x200, 0x0, 0x0, 0x0) ["../libfb/fb_generic.c":180, 0x400f78] 3 main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["../util/pix-fb.c":159, 0x400674] (dbx) More startlingly, when I run the same binary on a Personal Iris, it *leaps* to location 0, and traps, giving a worthless core dump (the stack frame is no good, DBX is lost). Compiling the code on the GTX and then running on a GT also dumps core. Same for GTX code run on a non-GT (eg 4D/70). A test program to demonstrate looks like this: main() { int g_status, f; /* * Now that the mode has been determined, * ensure that the graphics system is running. */ if( !(g_status = ps_open_PostScript()) ) { char * grcond = "/etc/gl/grcond"; char * newshome = "/usr/brlcad/etc"; /* XXX */ f = fork(); if( f < 0 ) { perror("fork"); return(-1); /* error */ } if( f == 0 ) { /* Child */ chdir( newshome ); execl( grcond, (char *) 0 ); perror( grcond ); _exit(1); /* NOTREACHED */ } /* Parent */ while( !(g_status = ps_open_PostScript()) ) { sleep(1); } } } This code is compiled by: cc foo.c -lgl_s -lc_s -o foo Run it on the machine that compiled it, no problem. Run the exact same binary on any other kind of 4D: Pffft -- core dumped. THE INTENT. The intent of this code fragment is to permit applications to produce graphics display even if nobody is logged in on the console (eg, the window manager is not running). This happens often at BRL because (a) we don't like using the SGI-provided keyboard, and (b) we produce a lot of our graphics elsewhere on the network, and just wish to display the result on an SGI. We don't necessarily want to have to log in on the SGI just to see pictures. If the window manager is not running, it has to be started first, with a somewhat restricted set of PostScript code (to avoid offering menus that might allow somebody to open a shell window). I believe that the HotLine told us to do things this way. It seems to work fine when used on the machine that compiled it, but not other types of SGI machines. Did I forget a compiler option? Not invoke the shared libraries right? Find a bug? Or what? So, several questions arise: 1) Is calling ps_open_PostScript() the only way to accomplish this test? 2) Is ps_open_PostScript() the best way? 3) Where is it documented, anyways? I can't find any mention online. ("pcat *.z|grep ps_open" is a poor substitute for "man -k"). 4) Can anyone suggest a workaround, so that I can make this stuff work, NOW? Any help you can provide will be most appreciated! Thanks, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09113; 2 Mar 89 16:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07422; 2 Mar 89 14:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07343; 2 Mar 89 14:37 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa02565; 2 Mar 89 14:09 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA12778; Thu, 2 Mar 89 10:42:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 89 15:26:32 GMT From: Thomas Russo Organization: The University of Texas at Austin, Austin, Texas Subject: Flight/dog questions Message-Id: <10878@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We've got a couple of Personal Irises and I've got a few dog/flight questions. 1) I've heard talk of an "airshow" capability. How does one create an airshow and how does one view such a thing? 2) The heads-up display is great, but how do you get the missle lock to work when you're using it? I've tried it many many times and can't figure out where the target should be for the lock to function. 3) about that heads up display... there is a little circle with part of a cross hair which moves about as I zip around. My first guess at what this was (a sight?) appears to be incorrect. So what the **** is it? 4) On one of our irises (the one with the chintzier graphics) the radar shows an opponent in red if the target is above you, and black if it's below. This is fine when using the heads-up display, but if you use the other type the little black radar blip doesn't show up so well on the black background. Any way to tweak the executable (we don't have the source) to fix that? (BTW, I was told that the source is available if you sign a non-disclosure agreement. Is that so?) What follows is not really a question, but I thought I'd register my thoughts on this matter. It's really just a wish: 5) Isn't there a better way of doing inter-machine dogfighting than using UDP broadcasts? (like, broadcast once when starting up so other running programs can see you, then maintaining a list of addresses with which to communicate) Our network has hundreds of hosts on it, and UDP broadcasts at dog's rate bring the thing to a grinding halt. (Many of the older hosts respond to every packet with a "port unknown" packet. Meltdown city.) So, like, the only way to run dog is to disconnect from the campus net, which means that we can't dogfight with the other irises on campus, which is a shame. I know dog is an unsupported demo, but if anyone has the time to spend hacking it up to use some other mechanism it would probably be a good thing to do. But don't get me wrong: we love dog. Deep down, it is one of the secret reasons I encouraged the purchase of Irises at the center! --tvr ------ Thomas Russo Center for Nonlinear Dynamics University of Texas at Austin russo@chaos.utexas.edu but not before friday, when our disk is back up. (there's another question: Anyone have any bad experiences with those 1.2GB disks which come on 4Server8s? Ours barfed badly this week and had to be replaced, after only 1 month in service. Is this a trend, or did we just have really really really bad luck?)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09249; 2 Mar 89 16:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07688; 2 Mar 89 15:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07567; 2 Mar 89 15:05 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa04137; 2 Mar 89 14:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA14857; Thu, 2 Mar 89 11:18:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 89 18:12:46 GMT From: "J. Wiltse Carpenter" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: More Iris questions Message-Id: <27780@sgi.SGI.COM> References: <4337@pt.cs.cmu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4337@pt.cs.cmu.edu>, gleicher@b.gp.cs.cmu.edu (Michael Gleicher) writes: > Some more Iris questions: > > 2) Is there any documentation on the audio I/O capabilties of the Personal > Iris? I know it has a D/A converter, and I think it has an A/D > converter. > Does anyone have some code to send some data (a sampled sound or > waveform) to the speaker or to the audio out jack? > The only documentation available is the manual page, audio(7). But the audio channel is pretty simple so it hopefully won't be too hard to figure out how to use it. Here's a summary: The PI has an eight bit bi-directional A/D-D/A converter that supports three different sampling rates: 32Khz, 16khz, and 8khz. The output gain is software settable. A/D conversion is done by simply reading from /dev/audio and D/A conversion is done by writing to /dev/audio. Simple record and playback can be done with the ``dd'' command. To set the sampling rate or output gain requires that an ioctl() be performed on /dev/audio. In addition to the straight forward D/A conversion, there is a "loop mode" whereby a single buffer may be replayed for a preset time. To play a continuous sine wave for instance, one would construct a buffer containing one waveform and instruct /dev/audio to play it repeatedly for a certain length of time. The ioctl() AUDIOCDURATION (defined in /usr/include/sys/ audio.h), is used to specify the playback time in .01 second increments. -Wiltse   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11070; 2 Mar 89 18:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09589; 2 Mar 89 17:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09448; 2 Mar 89 17:27 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08770; 2 Mar 89 17:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA21311; Thu, 2 Mar 89 13:06:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 89 20:35:52 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Troubles with shared libraries! Message-Id: <27805@sgi.SGI.COM> References: <8903020325.aa27209@SPARK.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903020325.aa27209@SPARK.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > I have been continuing to have problems moving binaries between diffrent > SGI platforms when they are compiled with shared libraries. I consider > being able to share binaries to be a highly desirable feature, and I > intend to continue to "flog" this topic until something is decided. > > I have modified the Cakefile so that all programs in the BRL-CAD Package > are compiled (linked) with -lgl_s (when using LIBFB), -lm, and -lc_s. > I still have problems when calling the routine ps_open_PostScript(). You have found a bug which is fixed in release 4D1-3.1 Rev D which was released to manufacturing on Monday February 27th. Volume shipments should start within 30 days. Incidently Rev D includes version 1.3 of 4Sight which has many bug fixes and is much more solid than version 1.2. Here are the gory details of Mike's problem. You can stop reading here if you don't care about them. The GL uses libcps to communicate with the window server. We embedded the key pieces of libcps in the GL so people with existing GL applications wouldn't have to change their Makefiles to also link with libcps. However these functions are not exported from the GL. When you link with a shared library and reference a function that isn't exported (exporting means the function is in the shared library's call table) the reference is resolved by calling to the address of the function in the version of the shared library you are linking with. When your program referenced ps_open_PostScript it ended up calling the address of ps_open_PostScript in the shared GL you linked with. It will be in a different place on other machines and other releases of the shared GL for the same machine. Hence it breaks on these other machines. I won't even try to explain the fix here. It is very long and complicated. The complexity comes from maintaining binary compatibility with GL applications from previous releases. In Rev D you will have to link programs that use the GL and do their own PostScript stuff with -lgl_s and -lcps and you will have binary compatibilty across all 3.1 Rev D machines. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11324; 2 Mar 89 18:36 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09380; 2 Mar 89 17:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09351; 2 Mar 89 17:11 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08556; 2 Mar 89 16:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA21266; Thu, 2 Mar 89 13:06:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 89 18:59:49 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Binary Compatability? Message-Id: <27790@sgi.SGI.COM> References: <8902272226.AA00876@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If you want your GL program to have binary compatibility across all 4D products you *must* link with the shared GL as well as avoiding any hardware (such as alpha planes) that only exists on certain models. You also must only use the exported (i.e. public) entry points of the shared GL. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13719; 3 Mar 89 7:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13099; 3 Mar 89 6:02 EST Received: from spark.brl.mil by VMB.BRL.MIL id aa13094; 3 Mar 89 5:50 EST Date: Fri, 3 Mar 89 5:50:11 EST From: Mike Muuss To: Info-Iris@BRL.MIL Subject: lrectwrite & gsync? Message-ID: <8903030550.aa06677@SPARK.BRL.MIL> My thanks to the folks from SGI who informed me that ps_open_PostScript() not being machine independent presently, and that the new release fixes this. Since I am forced to abandon the portability topic until we get the fabled next release, I have moved on to some performance enhancements. I have noticed that if I write the entire screen (on a GT) with a single call to lrectwrite(), it proceeds with blinding speed. If, however, I send the same amount of data using one call to lrectwrite() per scanline, it proceeds at the rate of about 1000 scalines/second, which is very slow. Running gr_osview during this time, I notice that total user time is about 3%, and system time averages 40-60% !!! I am calling lrectwrite() in a loop, there are no (intentional) system calls being made. What I suspect is that lrectwrite() may be doing something like a gsync() on every call, or perhaps notifying the window manager that this might be a good time for another process to have a chance to do some graphics, or some such. I seek a way to stop this behavior. Can anybody help? (I find nothing about this in the online manuals. I know from writing SunView programs that acquiring a "window manager lock" is something that some systems permit. Is there a comparable SGI routine that will do as I wish?) Suggestions to reformat the in-memory data into a form so that I can ALWAYS use a single lrectwrite() are not helpful. Sometimes I can do it all in one, sometimes not. It would cost 4 Mbytes of extra memory and a lot of data copies to shuffle things. Thanks, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15843; 3 Mar 89 9:57 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14665; 3 Mar 89 8:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14618; 3 Mar 89 8:14 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa17802; 3 Mar 89 7:55 EST Received: Fri, 3 Mar 89 07:55:49 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 3 Mar 89 07:55:49 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903031555.AA13163@aero4.larc.nasa.gov> To: texbell!bigtex!mybest!ut-emx!phib412@bellcore.com Subject: Re: Flight/dog questions Cc: info-iris@BRL.MIL 1. When you execute flight/dog add '-o filename' then everything you do is save on a file. Make sure you have a lot of disk space. To replay the 'airshow' add '-i filename', everything you did shows up as a separate aircraft. You can chase the planes, fire on them, etc, however, they keep flying as if you weren't there. When the end of the file is reached, the file is rewound and things start over. I have done this writing out one file, then, use that file as input and also writing out a new file, thus combining the old file and what you are doing now. If you do this enough times you can build a complete airshow with lots of aircraft. 2. I can't remember having any problems with missile lock, but I haven't played in a while and I usually don't use the heads-up display. The heads-up version I have is a little 'buggy', and the instrumentation is not real clear. 3. My guess was some type of G indicator, or some other type of rate of change indicator. What is it really? 4. A lot of the IRIS demos and other software is available from SGI and the IRIS Software Exchange. For $100 they will send you a tape with the software on it. They have 2000/3000 and 4D tapes. The address to get the tape follows: User Services Silicon Graphics, Inc. Mailstop 2U-420 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 5. I had heard someone mention it would be nice if you could specify which machines the information would go to, but I don't know if anything was done allong those lines. I hope this is some help. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20176; 3 Mar 89 13:34 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa18134; 3 Mar 89 11:49 EST Date: Fri, 3 Mar 89 11:38:13 EST From: Gary S. Moss (VLD/VMB) To: info-iris@BRL.MIL Subject: Reading keyboard input from PostScript Message-ID: <8903031138.aa17386@VMB.BRL.MIL> Hi, Any NeWS Extended Input System (EIS) gurus out there, please help. I have been having difficulty writing PostScript code to read a line of input on a 4D/60T running IRIX 3.1. It seems as though every time the script is run, another 'interest' in keyboard events gets registered, but not revoked, so that each keystroke is received multiple times, depending on how many times the script has been run since 4Sight was last loaded (by logging in to the console). Also, the keyboard events don't get consumed by the 'awaitevent', but get read by the shell after the script terminates. I imagine I could do this easiest from 'C' and just call any necessary PostScript graphics code by using the C to PostScript interface (CPS), but I would like to understand what is going on. Thanks, moss ----------------------- cut here ------------------ #!/usr/NeWS/bin/psh executive /bias 16#6F00 def /cr 13 def /dim 100 def /str dim string def /buf dim string def /insertchar % key => key { dup % => key key bias sub % remove ASCII bias, => key char str exch strindex exch put % str[strindex] = char, => key /strindex strindex 1 add def % increment subscript } def /getkeybdinput % - => { strindex dim eq { exit } if % subscript range check awaitevent % => event /Name get % grab key value insertchar % convert key to char and store it cr eq { exit } if % quit if carriage return pause } def /getlinefromkeybd % - => { { getkeybdinput } loop str print (\n) print } def /strindex 0 def % initialize subscript for string array currentinputfocus % => [canvas,process] /inputfocus 2 array def % create 'inputfocus' [canvas,process] array inputfocus copy % store [canvas,process] 0 get addkbdinterests % enable receipt of keyboard events /kbdevents 3 array def % create event array 'kbdevents' kbdevents copy % store keyboard events % The following line doesn't seem to be necessary. % 0 get expressinterest % express interest in ascii_keymap getlinefromkeybd % The following are attempts to revoke all acquired interests, but only % result in errors. %kbdevents 0 get revokeinterest % revoke interest in ascii_keymap %kbdevents inputfocus 0 get %revokekbdinterests % undo effects of addkbdinterests   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25169; 3 Mar 89 17:40 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa23111; 3 Mar 89 15:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23026; 3 Mar 89 15:15 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa03974; 3 Mar 89 14:57 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA25727; Fri, 3 Mar 89 11:10:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 89 16:08:11 GMT From: "David M. Laur" Organization: Princeton University, NJ Subject: Reducing the size of 4D executables Message-Id: <7356@pucc.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL As part of our graphics research activity, the Princeton Interactive Computer Graphics Lab (ICGL) maintains a cluster of 16 Personal IRIS workstations which is available to students and faculty 24 hours a day. There are currently 675 users registered in our password file, although not all of these are continuously active users. One of the biggest system administration headaches we face is keeping a useful amount of disk space available to the users (and ourselves). This problem is exacerbated by the relatively larger size of programs compiled for the 4D's RISC processor, compared to a typical CISC executable. In desparation, we read the documentation. It turns out that there are some pretty painless mechanisms for reducing the size of a typical 4D executable. Kevin Perry (our systems programmer), recently compiled a moderate-size GL program with a variety of different cc command-line options, and noted the sizes of the resulting executables. Here are the results of this test: Compilation Cmd Executable Size cc -g test.c -lgl: 330 Kb (with symbol table, debugging) cc test.c -lgl: 330 Kb (with symbol table) cc -s test.c -lgl: 196 Kb (strip symbol table) cc -s test.c -lgl_s: 53 Kb (use shared GL library) cc -s test.c -lgl_s -lc_s: 33 Kb (use shared GL and C libraries) cc -s -O test.c -lgl_s -lc_s: 29 Kb (use optimizer) Note: The -g option is meaningless if combined with the -s option. So: we have found it useful to advertise the use of some of these options, and have changed our existing makefiles to take advantage of them. +---------------+ David Laur | "a bizarre | Princeton University | underwater | Interactive Computer Graphics Lab | scenerio..." | Internet: dmlaur@magritte.princeton.edu +---------------+ Bitnet: dmlaur@pucc   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25414; 3 Mar 89 18:22 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa24945; 3 Mar 89 17:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24901; 3 Mar 89 17:08 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08246; 3 Mar 89 16:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.33) id AA02663; Fri, 3 Mar 89 13:15:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Mar 89 20:20:06 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: lrectwrite & gsync? Message-Id: <27896@sgi.SGI.COM> References: <8903030550.aa06677@SPARK.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903030550.aa06677@SPARK.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > I have noticed that if I write the entire screen (on a GT) with > a single call to lrectwrite(), it proceeds with blinding speed. > If, however, I send the same amount of data using one call to > lrectwrite() per scanline, it proceeds at the rate of about 1000 > scalines/second, which is very slow. > > Running gr_osview during this time, I notice that total user time > is about 3%, and system time averages 40-60% !!! I am calling > lrectwrite() in a loop, there are no (intentional) system calls > being made. What I suspect is that lrectwrite() may be doing > something like a gsync() on every call, or perhaps notifying > the window manager that this might be a good time for another process > to have a chance to do some graphics, or some such. The system time is most likely due to the dma setup. The pixels are transferred by dma. On the GT lrectwrite chooses whether to use dma or push the pixels into the pipe depending on the number of pixels being transferred. Pushing pixels is much slower than dma but obviously the dma setup time is a concern. I don't know the exact changeover point. No messages are sent to the window manager. No window or screen locks are acquired or freed. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26450; 4 Mar 89 1:06 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa26137; 4 Mar 89 0:04 EST Received: from sem.brl.mil by VMB.BRL.MIL id aa26135; 3 Mar 89 23:54 EST Date: Fri, 3 Mar 89 23:45:03 EST From: Mike Muuss To: Mark Callow cc: info-iris@BRL.MIL Subject: Re: lrectwrite & gsync? Message-ID: <8903032345.aa14962@SEM.BRL.MIL> Mark - Thanks for your detailed and informative note. From what you say, then the 60% SYS time must be DMA setup, and the 40% IDLE time must be the actual DMA transmission time. I was seeing 1000 scanlines/second. If that translates to 1000 syscalls and interupts per second, then I can understand the significant overhead that I was encountering. I guess I would like the opportunity to vary the pipe_write / DMA crossover point in my application, to see if I can produce faster screen updates. The SGI evaluation to set the threshold may not have taken the system overhead fully into account. THE BIG PICTURE Let me also take this opportunity to tell you what I need to do; perhaps you can suggest some different strategy that may achieve higher performance. I have a shared memory segment that is organized as 1024 scanlines of 1280 pixels of 4 bytes each (SGI AlphaBGR format for lrectwrite). The arrangement of this data must be fixed, regardless of what sub-rectangle of it is presently of interest. If it would help any, I can change the internal organization any way I like, subject to the previous constraint. When the application is using the full screen, then this entire array is written with a single call to lrectwrite(), with delightfully good performance. When the application is using a smaller window, it presently drops back to a loop which calls lrectwrite() once per scanline. Here is the actual code fragment: /* Simplest case, nothing fancy */ y = ybase; if( !sw_zoom && !sw_cmap ) { if( ifp->if_width == SGI(ifp)->mi_memwidth ) { /* This one is very fast */ lrectwrite( SGI(ifp)->mi_xoff+0, SGI(ifp)->mi_yoff+y, SGI(ifp)->mi_xoff+0+ifp->if_width-1, SGI(ifp)->mi_yoff+y+nlines-1, &ifp->if_mem[(y*SGI(ifp)->mi_memwidth)* sizeof(struct sgi_pixel)] ); return; } for( n=nlines; n>0; n--, y++ ) { lrectwrite( SGI(ifp)->mi_xoff+0, SGI(ifp)->mi_yoff+y, SGI(ifp)->mi_xoff+0+ifp->if_width-1, SGI(ifp)->mi_yoff+y, &ifp->if_mem[(y*SGI(ifp)->mi_memwidth)* sizeof(struct sgi_pixel)] ); /* XXX big performance hit here. * GTX is limited to about 1000 lrectwrites/sec, * due to some library synchronization mechanism * that burns 60% of the CPU in sys-time. ?!?! */ } return; } So, what I really want to do is write a RECTANGLE from my buffer to a RECTANGLE on the screen, more in the style of rectcopy(). Does the 4D architecture offer me a way of doing this? I can imagine several possibilities: 1) a subroutine, perhaps: lrectwriterect( x1,y1, x2, y2, pixel_p, mem_width, mem_skip ) which would use mem_width pixels, then skip mem_skip pixels, and repeat. This would be perfect. 2) A subroutine modeled on the Berkeley writev() call that would take an array of structures roughly like this (any reasonable layout is fine with me): struct fast_pixel_cmds { int xscr_base; int yscr_base; struct sgi_pixel *pixel_p; int count; } array[MAX_CMDS]; fast_pixel_write_v( &array[0], cmd_count ); 3) A "vector" version of lrectwrite() that looked something like this: struct lrectwrite_vector { int xscr_base, yscr_base; int xscr_max, yscr_max; struct sgi_pixel *pixel_p; } array[MAX_CMDS]; lrectwrite_v( &array[0], cmd_count ); Any suggestion at all that you might have will be greatly appreciated! Thanks, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00321; 4 Mar 89 21:31 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00287; 4 Mar 89 21:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00207; 4 Mar 89 21:11 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa00663; 4 Mar 89 18:56 EST Received: from NORUNIX.EARN by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8688; Sat, 04 Mar 89 18:57:22 EST Received: by runix.runit.sintef.no (norunix.EARN) (1.2/5.5) id AA01618; Sat, 4 Mar 89 13:29:32 +0100 Date: 4 Mar 89 13:29 +0100 From: Finn Drablos To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Message-Id: <22*finnd@vax.runit.unit.uninett> Subject: graphics terminal emulation I sometimes run programs on the local Cray generating graphics as UNIRAS metafiles. I then want to display the graphics on the Iris, for example by using it as a graphics terminal for the VAX- frontend, where we have UNIRAS. Is there any useful emulation software for the Iris ? Or do somebody have suggestions for an alternative solution ? ================== Finn Drablos PHONE +47 7 597710 FAX +47 7 597708 MR-Senteret, SINTEF MHS(EAN) : finnd@vax.runit.unit.uninett N-7034 TRONDHEIM, NORWAY EARN/BITNET : drabloes@norunit -----------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14367; 6 Mar 89 16:15 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa11897; 6 Mar 89 13:52 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11843; 6 Mar 89 13:27 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa23393; 6 Mar 89 12:56 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA15115; Mon, 6 Mar 89 12:54:09 EST Received: by buita.bu.edu (3.2/4.7) id AA20794; Mon, 6 Mar 89 12:55:25 EST Received: by adt.uucp (3.2/SMI-3.2) id AA07249; Mon, 6 Mar 89 10:19:49 EST Date: Mon, 6 Mar 89 10:19:49 EST From: jim frost Message-Id: <8903061519.AA07249@adt.uucp> To: info-iris@BRL.MIL Subject: Re: Flight/dog questions >We've got a couple of Personal Irises and I've got a few dog/flight >questions. > >1) I've heard talk of an "airshow" capability. How does one create an >airshow and how does one view such a thing? dog -o filename will dump a flight to a disk file, dog -i filename will read from a disk file, and dog -i file1 -o file2 will add your plane to an existing file. Beware: these files get big FAST. >2) The heads-up display is great, but how do you get the missle lock to >work when you're using it? I've tried it many many times and can't figure >out where the target should be for the lock to function. Dead center, same as without heads-up. There are cross-hairs at that point. The closer the better. Heads-up doesn't give messages so you have no idea exactly what's going on, but it does work. >3) about that heads up display... there is a little circle with part of a >cross hair which moves about as I zip around. My first guess at what this was >(a sight?) appears to be incorrect. So what the **** is it? True direction; this is where your plane is really going. >4) On one of our irises (the one with the chintzier graphics) the radar shows >an opponent in red if the target is above you, and black if it's below. This is >fine when using the heads-up display, but if you use the other type the little >black radar blip doesn't show up so well on the black background. Any way to >tweak the executable (we don't have the source) to fix that? (BTW, I was told >that the source is available if you sign a non-disclosure agreement. Is >that so?) That must be the model with only 12 bit-planes. It should also have rainbow-colored planes and the purple mountains aren't displayed. No idea how to fix it, although I'd like to try. There also appears to be other problems with the radar on personal irises (seems to be quite intermittent) and I suspect they are linked to color as well. jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14647; 6 Mar 89 16:47 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa13309; 6 Mar 89 15:23 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13145; 6 Mar 89 15:09 EST Received: from [36.2.0.98] by SMOKE.BRL.MIL id aa21683; 6 Mar 89 12:16 EST Received: by sierra.STANFORD.EDU (3.2/4.7); Mon, 6 Mar 89 09:14:57 PST Date: Mon, 6 Mar 89 09:14:57 PST From: "Lloyd J. Lacomb" To: info-iris@BRL.MIL Subject: Re: (l)rectwrite Message-Id: Like Mike I have noticed the slow performance of the (l)rectwrite routines when I have to draw each line individually as opposed to drawing all the lines in one call. Since the explanation seems to have to do with the internal hardware/DMA configuration, I have an additional question about (l)rectwrite. Why are the (l)rectwrite routines fixed to only accept only data in 1st quadrant (i.e. y2 > y1) format rather than being versitaile enough to figure out that if y2 < y1, the image is in 4th quadrant form. It would seem that the routines could then pipeline the data in some hardware effcient manner to the memory rather than having the user issue the call for each line of the data. I suppose that the routines should be general enough to deal with 2nd and 3rd quadrant data but since that is another issue lets keep the request simple. Thanks for any help on this matter. Lloyd LaComb lacomb@sierra.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14776; 6 Mar 89 17:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14720; 6 Mar 89 17:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14661; 6 Mar 89 16:49 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa28861; 6 Mar 89 16:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02161; Mon, 6 Mar 89 13:01:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Mar 89 20:44:39 GMT From: Jim Helman Organization: Stanford University Subject: Re: 3D input, comments on Jim Barton's note Message-Id: <401@isl.stanford.edu> References: <8902281549.AA03342@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8902281549.AA03342@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) writes: > > 5. Correct documentation? What's that? > > 6. Quality?! Service? I hope these have finally been adopted. > > SGI could learn a few things , correction [sic] a lot, from the > microcomputer industry, concerning add on equipment and > other things. Easy there. If you think SGI is bad, maybe you should look around a bit. The SUN hotline takes a week to get back to you. SGI's hotline usually returns calls within the hour. We've even had an SGI field engineer come out at 6:30 on a Friday evening because we needed the machine for the weekend. As for the documentation, it's better than most and improving. Just compare the G Graphics Library Manual with the newer GT Graphics Library Manual. Sure sometimes you get a brainless person or a neophyte on the hotline who wastes half an hour of your time reading man pages to him/herself on the phone. And sometimes SGI can't supply working replacement parts, such as the latest processor board, in a timely fashion. But overall, SGI does better than any other company of its size that I've dealt with. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20913; 7 Mar 89 12:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20478; 7 Mar 89 11:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20416; 7 Mar 89 11:29 EST Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa13839; 7 Mar 89 11:10 EST Received: Tue, 7 Mar 89 07:46:12 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 7 Mar 89 07:46:12 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903071546.AA25538@aero4.larc.nasa.gov> To: helman%isl.Stanford.EDU@labrea.stanford.edu Subject: Re: 3D input, comments on Jim Barton's note Cc: info-iris@BRL.MIL Your right about SUN. I called them 2 weeks ago, and still no answer. It seems to me that there are VERY FEW companies out there that care about their customers. What every happened to people trying their best to do their best? There are a few people out there, but they don't seem to be in management. I have run into a couple people at SGI that try to be helpful, they're not all bad. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01178; 7 Mar 89 21:58 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01107; 7 Mar 89 21:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac01007; 7 Mar 89 21:32 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa25509; 7 Mar 89 18:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24323; Tue, 7 Mar 89 15:22:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 89 21:57:11 GMT From: Andy Witkin Organization: Carnegie Mellon University Subject: meta key Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL HOW TO INSTALL A META KEY IN IRIX 3.1 1. If you use gnu emacs, put (setq meta-flag 1) into your .emacs file. You need do nothing special for unipress emacs. 2. Copy /usr/NeWS/lib/NeWS/UI.ps to ~/NeWS/UI.ps 3. Edit your private copy of UI.ps: Find this portion: /deliver_keyboard_to_focus { % event => - dup dup begin % ev ev sgi_translatekey % ev (string) /ClientData exch def % ev and add code before and after as follows: /MetaDown false def % true when either alt key is down { createevent dup begin % gobble alt key /Name [28560 28559] def /Priority 4 def /Exclusivity true def end expressinterest { awaitevent dup /Action get /DownTransition eq {/MetaDown true store} % downtrans -> set flag {/MetaDown false store} % uptrans -> clear flag ifelse } loop } fork /deliver_keyboard_to_focus { % EXISTING CODE dup dup begin % EXISTING CODE sgi_translatekey % EXISTING CODE dup dup type /stringtype eq % if there's a string exch length 0 ne and % of nonzero length MetaDown and % and meta is down Action /DownTransition eq and % and ev is a keypress {dup dup 0 get 128 or % then ior 128 into 0 exch put % the 1st char in the string } if /ClientData exch def % EXISTING CODE 4. Log out and log back in. Alt is now a meta key. (If you get in trouble, log in as someone else, rename ~/NeWS/UI.ps to something else, and figure out what you did wrong.) (This hack does two things: We fork a process that gobbles alt key presses and maintains our /MetaDown flag. And we add some code to deliver_keyboard_to_focus, a routine that runs whenever a key is pressed. deliver_keyboard_to_focus calls sgi_translatekey, sgi's routine that takes an event and stuffs a translation string on the stack. When the meta key is down, our added code checks to see if sgi_translatekey left a non-empty string on top of the stack, and if so, sets the high bit in the string's first character. The hacked string is then salted away in the /ClientData field of the event for god-knows-who to look at later.) --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01358; 7 Mar 89 22:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00800; 7 Mar 89 21:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00715; 7 Mar 89 21:18 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa16765; 7 Mar 89 12:58 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA22175; Tue, 7 Mar 89 12:56:26 EST Received: by buita.bu.edu (3.2/4.7) id AA24809; Tue, 7 Mar 89 12:57:48 EST Received: by adt.uucp (3.2/SMI-3.2) id AA00035; Tue, 7 Mar 89 10:39:58 EST Date: Tue, 7 Mar 89 10:39:58 EST From: jim frost Message-Id: <8903071539.AA00035@adt.uucp> To: info-iris@BRL.MIL Subject: Re: 3D input, comments on Jim Barton's note >> SGI could learn a few things , correction [sic] a lot, from the >> microcomputer industry, concerning add on equipment and >> other things. > >Easy there. If you think SGI is bad, maybe you should look around a >bit. The SUN hotline takes a week to get back to you. This is true, and if you have a real problem they'll bounce you around a LOT. Once I even got a message from someone about "my SO" (service order), which wasn't at all useful since I have (even still) about five active ones. Better than that, Sun shipped the 386i version of the 4.0 developer's kit without even RUNNING the debugger; the thing absolutely refused to work on any core, complaining about "bad text addresses". Even my worst experiences with SGI software pale against such incompetence. >As for the documentation, it's better than >most and improving. Just compare the G Graphics Library Manual with >the newer GT Graphics Library Manual. Yes, the newer are certainly better, although we've found that many functions are ambiguously documented; you actually have to play with them to figure out some specifics. Again, there is much worse out there! Basically I'm impressed with how fast SGI responds to their customers. Look at how fast the 4Sight system has matured! If everyone responded so fast, my job would be a lot easier. jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01479; 7 Mar 89 23:05 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01107; 7 Mar 89 21:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00921; 7 Mar 89 21:24 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa23642; 7 Mar 89 16:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA16497; Tue, 7 Mar 89 13:01:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Mar 89 19:38:35 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Graphics Benchmarking Message-Id: <28119@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm posting this article in reply to an early article asking how we benchmark our graphics hardware. Direct responses and queries can be sent to kurt@sgi rather than myself. -- jmb =============================================================================== This note is a response to Barry Fowler's message of 15 February 1989. Barry referenced our '88 SIGGRAPH paper (High Performance Polygon Rendering) and asked several questions concerning it and the system that it describes. His questions (paraphrased by me) and our responses are: 1. What system do the benchmark figures in the paper correspond to? They are for the dual-processor GTX (4D-120) product. However, only one of the CPU's is used during the benchmark (the other is available for general purpose computing). 2. Were the benchmark figures computed, or were they measured on actual equipment? We ran the benchmarks on the prototype GTX hardware that was available at the time. I reran the benchmarks on current equipment, and have included the new figures below. 3. Will SGI distribute the binaries of the benchmark programs? Perhaps even source code? We are happy to distribute both binary and source to customers through our sales/service organization. The performance figures claimed in the paper (and the current figures) are: - 101,000 quadrilaterals per second. 100 pixel, arbitrarily rotate, lighted, Z-buffered. (102000, up 1 percent) - 137,000 triangles per second. 50 pixel, arbitrary strip direction, lighted, Z-buffered. (135000, down 1 percent) - 394,000 lines per second. 10 pixel, arbitrarily directed, depthcued, Z-buffered. (334000, down 15 percent) - 210,000 antialiased lines per second. 10 pixel, arbitrarily directed, Z-buffered. (175000, down 17 percent) - 8.3 millisecond full-screen clear. Both color and Z-buffer banks cleared. (8.2, up 1 percent) Current polygon and area fill benchmark results are all within one precent of the figures claimed in the paper. Line drawing rates, however, are down roughly 15 percent from the claimed values. This performance loss is the result of a bug fix correcting the hardware interaction of polygon patterning with line drawing. We expect that future microcode releases will restore the line drawing performance to previously measured values. -- kurt   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11274; 8 Mar 89 19:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10204; 8 Mar 89 17:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09960; 8 Mar 89 16:59 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa20797; 8 Mar 89 16:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA28773; Wed, 8 Mar 89 12:47:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Mar 89 19:35:42 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: EDT for 4D Message-Id: <387@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL From time to time I have requested and have seen requests on the net for the VAX-VMS EDT editor to run on SGI 4D machines. I now have received two different commercial EDT versions for the 4D. We are currently evaluating these. Both seem to work just fine and before someone complains I do not own stock in either company. I am posting this for all of you who came from a VMS machine and do not like VI or EMACS. MESIRA, 3109 Scotts Valley Drive, Scotts Valley, CA 95066 (408)-425-7115 sells a modified version of UNIPRESS EMACS which seems to be a very nice emulation of EDT. Boston Business Computing, Ltd., 360 Merrimack Street, Riverwalk Center, Lawrence, Massachusetts 01843 (508)-683-7920 sells two products: EDT+ and VCL. EDT+ is a stand alone EDT editor. VCL is a shell like CSH or SH which looks very close to the VAX-VMS DCL command language. VCL is not 100% DCL because it is a shell on a UNIX box, but it is close. I know I will be flamed because I seem to want to make my 4D look like a VMS machine. I do not care. After all, isn't UNIX supposed to adapt to my needs instead of what some computer scientist thinks that I need. I now run EDT on our VMS machines, our IBM-PC's, our PDP-11's and our SGI machines. It is nice not being forced to use a reincarnation of TECO just because the UNIX box is more cost effective. That really should get a few flames. (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17114; 9 Mar 89 9:37 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14379; 9 Mar 89 7:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14365; 9 Mar 89 7:31 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa00476; 9 Mar 89 6:42 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29644; Wed, 8 Mar 89 13:03:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Mar 89 20:33:54 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: apropos for the 4D (not an official product of SGI) Message-Id: <28249@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL WHAT IT IS ========== Attached is a shell archive (shar file) containing two scripts which mimic the functionality of BSD "apropos" on an IRIS 4D (Sorry, no man pages). These scripts are not designed to be run on a 2/3000 series IRIS. CAVEAT EMPTOR, DISCLAIMERS, ET CETERA ===================================== The implementation of these scripts has been my own personal undertaking and they do not constitute an "official" SGI product. These apropos scripts may or may not be shipped with future SGI products. If apropos is supported in future IRIS 4D software releases, it may or may not be in the form of these two scripts. Future products may be incompatible with these scripts. These scripts are being released "AS IS". DO NOT CALL THE GEOMETRY HOTLINE IF YOU HAVE PROBLEMS. The scripts are completely unsupported. To quote Robin Williams from his "Reality, What a Concept" album, "You're on your own. Goodbye!" I will consider comments but I make no promises to support these scripts in the future. INSTRUCTIONS ============ 1) Using your favorite editor (vi, emacs, et cetera), cut out the shell archive (shar) indicated by "CUT HERE" and write it to the file "apropos.shar" in your personal bin directory or /usr/local/bin. 2) Unpack the archive to create "apropos" and "mkwhatis". sh apropos.shar # I always think of this as "just add water" I have not included any manual pages but the scripts document themselves. Really. 3) Run "mkwhatis" to create /usr/catman/whatis. You must do this as root. su mkwhatis NOTE: mkwhatis takes 10-15 minutes to "do it's thang". Grab some coffee or do work in one of your other 4Sight windows. You will need to rerun mkwhatis if you install any new options on your system. 4) "apropos" to your heart's content. For example, "apropos nfs" yields: exportfs (1M) - export and unexport directories to NFS clients exports (4) - list of NFS filesystems being exported mountd (1M) - NFS mount request server nfsd, biod (1M) - NFS daemons nfsmount (2) - mount an NFS file system nfsstat (1M) - display Network File System statistics nfssvc, async_daemon (2) - NFS daemons Have fun. --- Ciemo ----- CUT HERE ---------------------------------------------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by ciemo on Wed Mar 8 12:13:58 PST 1989 # Contents: apropos mkwhatis echo x - apropos sed 's/^@//' > "apropos" <<'@//E*O*F apropos//' #! /bin/sh # # NAME # apropos - find the apropriate manual pages for a give keyword # # SYNOPSIS # apropos keyword [...] # # DESCRIPTION # apropos searches its database of manual page descriptions # for those which match the specified keywords. The search # provided is an implied "or" of the keywords. # # apropos uses a database called whatis located in the manual # page tree. This database is created using the tool mkwhatis(1). # # This functionality of this version is based on William Joy's # version from UC Berkeley. # # SEE ALSO # mkwhatis(1) # # FILES # /usr/catman/whatis # # CAVEATS # Since apropos gets its information from a "static" database, it # is possible for apropos to report the existence of manual pages # which are not on the system. # # AUTHOR # Dave Ciemiewicz (ciemo) # # COPYRIGHT (C) 1989, Silicon Graphics, Inc., All rights reserved. # This file is not a product of Silicon Graphics, Inc. and is # provided for unrestricted use provided that this legend is # included on all tape media and as a part of the software # program in whole or part. Users may copy or modify this file # without charge, but are not authorized to license or distribute # it to anyone else except as part of a product or program # developed by the user. # # THIS FILE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND # INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS # FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, # USAGE OR TRADE PRACTICE. # # This file is provided with no support and without any # obligation on the part of Silicon Graphics, Inc. to assist in # its use, correction, modification or enhancement. # # SILICON GRAPHICS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO # THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY # THIS FILE OR ANY PART THEREOF. # # In no event will Silicon Graphics, Inc. be liable for any lost # revenue or profits or other special, indirect and consequential # damages, even if Silicon Graphics has been advised of the # possibility of such damages. # USAGE="Usage: apropos keyword [...]" WHATIS=/usr/catman/whatis if test $# -eq 0; then echo $USAGE 1>&2 exit 2 fi if test ! -r $WHATIS; then echo $0": can't open "$WHATIS 1>&2 exit 1 fi for keyword in $* do grep -i '^'$keyword $WHATIS # At the beginning of a line grep -i '[^a-zA-Z0-9_]'$keyword $WHATIS # Anywhere else in line done | sort -u @//E*O*F apropos// chmod u=rwx,g=rx,o=rx apropos echo x - mkwhatis sed 's/^@//' > "mkwhatis" <<'@//E*O*F mkwhatis//' #! /bin/sh # # NAME # mkwhatis - make manual page "whatis" database for use with apropos # # SYNOPSIS # mkwhatis [filename] # # DESCRIPTION # mkwhatis scans the preformatted manual page trees (/usr/catman), # parses the manual pages, and strips out the NAME section information # to create the "whatis" database used by apropos(1). # # By default, mkwhatis creates the file, /usr/catman/whatis. Another # file may be created as the database by specifying its filename on # the command line. You must run mkwhatis as root to create the # whatis file. See su(1M). # # The format of the whatis file created is based on that used by # William Joy's UC Berkeley version of apropos. # # SEE ALSO # apropos(1) # # FILES # /usr/catman/whatis # # CAVEATS # This program is S...L...O...W. Expect execution times of about # 10-15 minutes. The reason is that EVERY manual page on the system # is read. # # You must run mkwhatis as root. # # AUTHOR # Dave Ciemiewicz (ciemo) # # COPYRIGHT (C) 1989, Silicon Graphics, Inc., All rights reserved. # This file is a not product of Silicon Graphics, Inc. and is # provided for unrestricted use provided that this legend is # included on all tape media and as a part of the software # program in whole or part. Users may copy or modify this file # without charge, but are not authorized to license or distribute # it to anyone else except as part of a product or program # developed by the user. # # THIS FILE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND # INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS # FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, # USAGE OR TRADE PRACTICE. # # This file is provided with no support and without any # obligation on the part of Silicon Graphics, Inc. to assist in # its use, correction, modification or enhancement. # # SILICON GRAPHICS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO # THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY # THIS FILE OR ANY PART THEREOF. # # In no event will Silicon Graphics, Inc. be liable for any lost # revenue or profits or other special, indirect and consequential # damages, even if Silicon Graphics has been advised of the # possibility of such damages. # USAGE="Usage: mkwhatis [filename]" WHATIS=/usr/catman/whatis case $# in 0) ;; 1) WHATIS=$1;; *) echo $USAGE 1>&2 exit 2 ;; esac cd /usr/catman find * -type "f" -print | while read f do pcat $f | col -b | sed -e 's/ / /g' -e 's/ */ /g' -e 's/^ *//' | nawk ' BEGIN {name=0; count=0} $1 ~ /[0-9a-zA-Z_]+\([1-8][a-zA-Z]*\)/ { match($1, /\([1-8][a-zA-Z]*\)/) section = substr($1, RSTART, RLENGTH) next } $1 ~ /NAME/ {name=1; next} $1 ~ /SYNOPSIS|SY.*SIS/ {finish()} # SYNOPSIS is a common typo $2 ~ /SYNOPSIS|SY.*SIS/ {finish()} # SYNOPSIS is a common typo $1 ~ /DESCRIPTION/ {finish()} $2 ~ /SPECIFICATION/ {finish()} /^[ \t]*$/ {next} { if (name==1) nametext = nametext " " $0 next } function finish() { if (filenm ~ /g_man/) section="(3G)" # No section on GL man pages partscount = split(nametext, parts, " -") printf "%-24s", parts[1] " " section for (i=2; i<=partscount; i++) { printf " -%s", parts[i] } printf "\n" exit } ' filenm=$f done | sed -e 's/\([A-Za-z]\)- \([A-Za-z]\)/\1\2/g' -e 's/^ *//' | sort -u > $WHATIS @//E*O*F mkwhatis// chmod u=rwx,g=rx,o=rx mkwhatis exit 0 ----- CUT HERE ---------------------------------------------------------------- -- Dave (commonplace) "Boldly going where no one cares to go." Ciemiewicz (incomprehensible) ciemo (infamous)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22305; 9 Mar 89 14:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20418; 9 Mar 89 12:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20304; 9 Mar 89 12:28 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa07481; 9 Mar 89 11:40 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6373; Thu, 09 Mar 89 11:42:08 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 09 Mar 89 17:09:23 Date: Thu, 9 Mar 89 17:08:45 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Graphic problems To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8903091140.aa07481@SMOKE.BRL.MIL> Hallo everybody, we just encountered a strange graphic problem after upgrading a) from a 4D70G to a 4D70/GT and after that b) from some IRIX 3.1 prerelease to IRIX 3.1C. Before this action the following (highly simplified) code worked just fine: main() winopen("1.st"); fork() if parent: do some work else if child: winopen("2.nd") and some more work After the double-upgrade we get a core-dump from the second winopen. The call- stack reads like this: gl_init_wstate( .... ) glinit.c line 148 winope( ..... ) winstuff.c line 538 winopen (....) ginit.c line 98 I would like to know whether this is a bug in the software, or a violation of the window-manager rules, or a feature of the GT-hardware. A small test- program, which reproduces the described behaviour, is included an can be compiled and linked using cc test.c -o test -lgl -g We would really appreciate a fast response, because this problem is quite disturbing to our work. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET: -----------------------------test.c------------------------------------------- #include #include main() { int id1,id2,f_id; id1 = winopen("first"); f_id = fork(); if( f_id == -1) { printf(" no success in fork \n "); exit(0); } if( f_id != 0) { printf(" child = %d \n",f_id); while(TRUE); exit(0); } printf(" now new \n"); id2 = winopen("second"); printf(" kicker ??? \n"); ringbell(); while(TRUE); } -----------------------------------end of test.c------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab22305; 9 Mar 89 14:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21509; 9 Mar 89 13:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21507; 9 Mar 89 13:33 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa09928; 9 Mar 89 12:57 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA13344; Thu, 9 Mar 89 12:55:28 EST Received: by buita.bu.edu (3.2/4.7) id AA03324; Thu, 9 Mar 89 12:55:30 EST Received: by adt.uucp (3.2/SMI-3.2) id AA11251; Thu, 9 Mar 89 10:44:44 EST Date: Thu, 9 Mar 89 10:44:44 EST From: Joe Ilacqua Message-Id: <8903091544.AA11251@adt.uucp> To: info-iris@BRL.MIL Subject: Re: EDT for 4D <>From time to time I have requested and have seen requests on the To: info-iris@BRL.MIL Cc: lacomb@sierra.stanford.edu Subject: GPIB board for the 4D series Message-Id: A month or so ago I received the GPIB borad for use with my 4D/70GT. We use the borad to transfer data between the data acquisition computer and the Iris. On the old 2000/3000 series this was quite a simple matter; you changed a file or two in /etc and then it was a simple matter to read() or write() from any user program. It is quite a different matter on the 4D series. The ONLY documentation on the card is an include file /usr/include/sys/ugpid.h and the (mostly hardware and assembly language) user's manual from the vendor. The include file suggests that you contact the vendor for an additional manual about "... IEEE-488 Multitasking UNIX Device Drivers User Manual" (costs $35). Has anyone out there gotten the GPIB card to work on the 4D machines and if so could they send me a copy of the program that sets up the structure needed to get some data through the card. When the field eng. installed the card he said that he looked agound SGI and couldn't find any example software and my questions aren't localized enough that I want to call the hotline. Thanks, Lloyd LaComb lacomb@sierra.stanford.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24379; 9 Mar 89 16:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24230; 9 Mar 89 16:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24203; 9 Mar 89 16:28 EST Received: from CAD.USNA.MIL by SMOKE.BRL.MIL id ab13083; 9 Mar 89 14:49 EST Date: Thu, 9 Mar 89 14:45:28 EST From: "David F. Rogers" To: info-iris@BRL.MIL cc: dfr@usna.mil Subject: Dials & button boxes Message-ID: <8903091445.aa01217@CAD.USNA.MIL> G'day, We just got a bunch of 4D's with dial and button boxes. Apparently, none of the standard demos uses either the dial or button boxes. Has anyone got a piece of code that uses either one of both that you can email me so that I can test the hardware for acceptance? Much appreciated. Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA Tel: 301-267-3283/4/5 ARPANET: dfr@usna.mil UUCP: ~uunet!usna!dfr   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00824; 10 Mar 89 0:18 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00685; 10 Mar 89 0:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00664; 9 Mar 89 23:55 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa19681; 9 Mar 89 23:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05647; Thu, 9 Mar 89 20:40:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Mar 89 23:33:40 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Graphic problems Message-Id: <28374@sgi.SGI.COM> References: <8903091140.aa07481@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903091140.aa07481@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > Hallo everybody, > > we just encountered a strange graphic problem after upgrading > > a) from a 4D70G to a 4D70/GT and after that > b) from some IRIX 3.1 prerelease to IRIX 3.1C. > > > Before this action the following (highly simplified) code worked just fine: > > > main() > > winopen("1.st"); > fork() > if parent: do some work > else if child: winopen("2.nd") and some more work > > After the double-upgrade we get a core-dump from the second winopen. The call- > stack reads like this: > > gl_init_wstate( .... ) glinit.c line 148 > winope( ..... ) winstuff.c line 538 > winopen (....) ginit.c line 98 > I've just investigated this for you. The problem is that on the GT there is a piece of per-process shared memory between the GL Client and the Window Server. This is established when the GL is initialized which happens at the first winopen. When you fork and do the second winopen, the window server establishes another piece of shared memory for the child process. Unfortunately the GL, since it has already been initialized, tries to use the shared memory of the parent instead of reinitializing its global state structure to use the child's shared memory. In other words, this is a bug in the GL. We are planning to fix the GL so you can use graphics from multiple shared-processes (sproc threads). This is probably typical of the problems we will uncover in that work. You can expect the problem to be fixed though I don't know when. Unfortunately I can't think of a workaround. Perhaps the GL experts can help. -Mark -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00853; 10 Mar 89 0:39 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00433; 9 Mar 89 23:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac00355; 9 Mar 89 22:57 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa19116; 9 Mar 89 22:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA00223; Thu, 9 Mar 89 18:47:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 89 01:40:25 GMT From: Bevis Ip Organization: University of Toronto Mechanical Engineering Subject: BSD style man (plus another apropos for the 4D) Message-Id: <89Mar9.204027est.20087@me.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here are three shell scripts I wrote quite a while ago for BSD style "man". This "man" runs much faster than SGI's own but you have to run "makemanpaths" (and "makewhatis", although not really necessary) whenever you have new man page entries. This version of "makewhatis" is more efficient (in my opinion) than the one Dave Ciemiewicz (ciemo@bananapc.SGI.COM) just posted, although it still takes about 10 minutes to finish. The scripts are geared at IRIS 4D running IRIX 3.1 (evolved from those I wrote back in IRIX 2.2 days). Sorry, no man page either. bevis ------------CUT----------- #! /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: # makemanpaths # makewhatis # man # This archive created: Thu Mar 9 19:06:38 1989 export PATH; PATH=/bin:$PATH if test -f 'makemanpaths' then echo shar: will not over-write existing file "'makemanpaths'" else cat << \SHAR_EOF > 'makemanpaths' #!/bin/sh # Build man pages path for faster location. # # CopyRight (C) 1989 by Bevis Ip, all rights reserved. # # Email: ip@me.toronto.edu, uunet!utai!me!ip # # Everyone is granted the permission to copy, modify and redistribute # this program provided that this notice is remain attached. The # authour assumes no liability of any kind in connection with the # usage of this code. Use it at your own risk. # MANPATHS=${1-/usr/local/lib/manpaths} cd /usr/catman trap '' 1 2 3 15 rm -f $MANPATHS find . ! -type directory -print | sed 's/^.\///' | sort -t/ -2 > $MANPATHS chmod 444 $MANPATHS SHAR_EOF chmod +x 'makemanpaths' fi # end of overwriting check if test -f 'makewhatis' then echo shar: will not over-write existing file "'makewhatis'" else cat << \SHAR_EOF > 'makewhatis' #!/bin/sh # Build BSD style whatis database for whatis (man -f) and apropos (man -k). # # This is a hack; worked backward from the formatted, packed catman pages. # (3G) man pages had been formatted strangely and require special treatment. # # CopyRight (C) 1989 by Bevis Ip, all rights reserved. # # Email: ip@me.toronto.edu, uunet!utai!me!ip # # Everyone is granted the permission to copy, modify and redistribute # this program provided that this notice is remain attached. The # authour assumes no liability of any kind in connection with the # usage of this code. Use it at your own risk. # WHATIS=${1-/usr/local/lib/whatis} TMP=/tmp/whatis MANDIR=/usr/catman > $TMP for i in `find $MANDIR -type d -print` do cd $i if [ "`echo *.z`" = "*.z" ] then continue fi case $i in $MANDIR/g_man/cat3/*) # no section info @#$%^&*( pcat `find . ! -type l -name \*.z -print` | col -b | \ sed -n -e '/^ *$/d' \ -e '/^ *NAME$/b getname' -e b \ -e :getname -e n -e h -e :getmore -e n \ -e '/.*SY.*SIS/b gotit' \ -e '/.*DESC/b gotit' \ -e '/.*SPEC/b gotit' \ -e H -e "b getmore" \ -e :gotit -e x \ -e 's/\n/(3G) /' -e 's/\n/ /g' \ -e 's/[ ][ ]*/ /g;p' \ >> $TMP continue ;; esac pcat `find . ! -type l -name \*.z -print` | col -b | \ sed -n -e '/^ *$/d' \ -e '/^ *.*([0-9].*) *.*([0-9].*)$/b getsect' \ -e '/^ *NAME$/b getname' -e b -e :getname -e n \ -e '/.*SY.*SIS/b gotit' \ -e '/.*DESC/b gotit' \ -e '/.*SPEC/b gotit' \ -e H -e "b getname" \ -e :gotit -e x \ -e 's/\n/ /g' -e 's/[ ][ ]*/ /g;p;b' \ -e :getsect -e 's/^ *.*(/(/' \ -e 's/ *.*$//;h' \ >> $TMP done trap '' 1 2 rm -f $WHATIS awk '{ gotit=0 printf "%s", $2 for (i = 3; i <= NF; i++) { if ($i == "-") { if (gotit++ == 0) printf " %s\t-", $1 else printf " -" } else { if ($i ~ /.*-$/) { # end=length($i)-1 # printf " %s", substr($i, 1, end) printf " %s", $i if (++i <= NF) printf "%s", $i } else printf " %s", $i } } if (gotit == 0) printf " %s", $1 printf "\n" }' $TMP | sort -u > $WHATIS chmod 444 $WHATIS SHAR_EOF chmod +x 'makewhatis' fi # end of overwriting check if test -f 'man' then echo shar: will not over-write existing file "'man'" else cat << \SHAR_EOF > 'man' #!/bin/sh # This is model to BSD man; quick and dirty but fast. # # CopyRight (C) 1989 by Bevis Ip, all rights reserved. # # Email: ip@me.toronto.edu, uunet!utai!me!ip # # Everyone is granted the permission to copy, modify and redistribute # this program provided that this notice is remain attached. The # authour assumes no liability of any kind in connection with the # usage of this code. Use it at your own risk. # #MAKEMANPATHS=/usr/local/bin/makemanpaths REALMAN=/usr/bin/man MANPATHS=/usr/local/lib/manpaths WHATIS=/usr/local/lib/whatis PAGER=${MANPAGER-${PAGER-'less -sbp50'}} args="$@" for i do case $i in [1-8][Cc]) std=1 case $i in 1?) sec="cat1.*" ;; 2?) sec="cat2.*" ;; 3?) sec="cat3.*" ;; 4?) sec="cat4.*" ;; 5?) sec="cat5.*" ;; 6?) sec="cat6.*" ;; 7?) sec="cat7.*" ;; 8?) sec="cat8.*" ;; esac ;; [1-8][Ff]) ftn=1 case $i in 1?) sec="cat1.*" ;; 2?) sec="cat2.*" ;; 3?) sec="cat3.*" ;; 4?) sec="cat4.*" ;; 5?) sec="cat5.*" ;; 6?) sec="cat6.*" ;; 7?) sec="cat7.*" ;; 8?) sec="cat8.*" ;; esac ;; [1-8]) sec="cat$i.*" ;; -w) path=1 ;; -T*) TERM="`echo $i | sed 's/-T//'`" ; export TERM ;; -k) apropos=1 ;; -f) whatis=1 ;; -*) usage=1 ; break ;; *) break ;; esac shift done if test -n "$usage" -o $# -eq 0 then echo "Usage: man [-w] [sec] name ..." >&2 echo " man [-k] key ..." >&2 exit 1 fi if test -n "$apropos" then for i in "$@" do grep -i "$i" $WHATIS done exit 0 elif test -n "$whatis" then for i in "$@" do egrep "^$i[ ,]|, $i" $WHATIS done exit 0 fi if test ! -s $MANPATHS then # echo "Building manpaths, hang on..." # exec $MAKEMANPATHS $MANPATHS echo "No manpaths, starting up $REALMAN..." exec $REALMAN $args fi cd $MANDIR for target do manpages="$manpages `grep \"$sec/$target.z\$\" $MANPATHS 2>&-`" done # make fortran pages last (usually not what people's looking for) for i in $manpages do case $i in */ftn/*) ftnpages="$ftnpages $i" ;; *) stdpages="$stdpages $i" ;; esac done if test -n "$std" then manpages=$stdpages elif test -n "$ftn" then manpages=$ftnpages else manpages=$stdpages$ftnpages fi if test -z "$manpages" then if test -n "$sec" then set $args; sec=$1; shift echo "No entry for $* in section $sec of the manual." else echo "No manual entry for $*." fi exit 1 fi if test -n "$path" then echo $manpages exit 0 fi bold=`tput smso` boldoff=`tput rmso` set $manpages trap '' 2 pcat $1 | col | eval $PAGER trap 2 while : do shift if test $# -eq 0 then exit 0 fi echo "${bold}----> $1 [$#] <---- (More?) ${boldoff}\c" read cmd case "$cmd" in n*|N*) continue ;; q*|Q*) exit 0 ;; esac trap '' 2 pcat $1 | col | eval $PAGER trap 2 done SHAR_EOF chmod +x 'man' fi # end of overwriting check # End of shell archive exit 0 -- Bevis Ip University of Toronto Mechanical Engineering CSNET : ip@me.toronto.edu BITNET: ip@me.UTORONTO Internet: ip%me.toronto.edu@relay.cs.net UUCP : {allegra,decwrl,decvax}!utcsri!me!ip _OR_ {pyramid,uunet}!utai!me!ip   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00286; 10 Mar 89 7:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01338; 10 Mar 89 3:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01325; 10 Mar 89 3:11 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa21013; 10 Mar 89 2:56 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 3830; Fri, 10 Mar 89 02:57:22 EST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 10 Mar 89 08:57:09 Date: Fri, 10 Mar 89 08:57:06 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: RE:RE: Graphics problems To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8903100256.aa21013@SMOKE.BRL.MIL> Thanks to Mark Callow for his fast reply to my message. It's this kind of treatment that makes me feel quite happy about our relationship to SGI (even if their software is not bug-free (but is mine ???)). Wherelse do I get a 10 hour response from the States to question from Germany? Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 (should read "Center for Molecular Modelling" in the near future) Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09052; 10 Mar 89 11:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05354; 10 Mar 89 10:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04869; 10 Mar 89 9:58 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa28529; 10 Mar 89 9:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA03501; Fri, 10 Mar 89 06:36:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 89 13:26:01 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: EDT for 4D Message-Id: <391@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This is a followup on my previous post about the availability of EDT for the 4D system. I just got a moderately rude message indicating that I should get gnu EMACS and put it into EDT emulation mode. For those who have not tried this I would not suggest it. The EDT emulation mode of the version of gnu EMACS which I tried would only emulate about 50% of what the EDT editor can do. In my opinion, a half way emulation is worse than no emulation. (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12375; 10 Mar 89 13:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10322; 10 Mar 89 11:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10157; 10 Mar 89 11:44 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa02862; 10 Mar 89 11:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA09312; Fri, 10 Mar 89 08:32:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 89 16:14:00 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Lines per Window Message-Id: <262@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How does "more" program know how many lines in 4Sight window? Apparently not from termcap ... iris-ansii says 40 lines, but, if I shrink the window to only 4 or 5 lines more still works fine. I want to make "less" work like this, too. "less" seems to only use termcap. Any answers? -Rich -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Ft. Belvoir, VA 22060-5546 BITNET: richr%ai.etl.army.mil@CUNYVM +1 202 355 3653 CSNET: richr%ai.etl.army.mil@RELAY.CS.NET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16288; 10 Mar 89 18:41 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15901; 10 Mar 89 17:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15884; 10 Mar 89 17:18 EST Received: from citi.umich.edu by SMOKE.BRL.MIL id aa13688; 10 Mar 89 17:03 EST From: "Ronald B. Adams" To: info-iris@BRL.MIL Date: Fri, 10 Mar 89 16:06:16 CST Received: by redsim.RSI (5.52/5.6) id AA05862; Fri, 10 Mar 89 16:06:16 CST Message-Id: <8903102206.AA05862@redsim.RSI> Any chance of getting an option added to man(1) that would let me specify an alternative directory to /usr/catman? I want to keep all of my man pages on my NFS server only, but I want each of my client PI's to be able to use them. The -d option is NOT the answer. -- Ron Adams Rediffusion Simulation texsun!redsim!adams "I used to be reflective, now I'm just diffused." - Elvis Albedo, 'Rayleigh Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17552; 11 Mar 89 3:52 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa17388; 11 Mar 89 3:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17381; 11 Mar 89 2:59 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa17942; 11 Mar 89 2:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA20181; Fri, 10 Mar 89 21:59:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Mar 89 00:41:17 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Lines per Window Message-Id: <28477@sgi.SGI.COM> References: <262@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <262@ai.etl.army.mil>, richr@ai.etl.army.mil (Richard Rosenthal) writes: > How does "more" program know how many lines in 4Sight window? > ... > -Rich > 'more' uses the standard BSD interface of using ioctl with the TIOCGWINSZ command to get the window size. It also accepts the SIGWINCH call which the system will generate for you if the window is resized (and you ask for it). The command and structure returned are described in /usr/include/sys/termio.h. In SysV curses, this can also be done by simply examining the LINES variable, which contains the current number of lines in the window. With minor modifications (such as including the right header file), you should be able to compile 'less' as if it was on a BSD4.3 system (job control will work as expected too). -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17552; 11 Mar 89 3:52 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab17388; 11 Mar 89 3:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab17381; 11 Mar 89 2:59 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa17951; 11 Mar 89 2:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24725; Fri, 10 Mar 89 23:41:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 89 18:38:56 GMT From: Lewis Yuchan Geer Organization: Washington U Physics, St. Louis Subject: Vector transform function in GL? Message-Id: <647@wuphys.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does there exist a function in the graphics library that will take a coordinate vector, multiply it with the current transform matrix and return the result? I have a very strong impression that I have seen such a function, but for the life of me I can't find it in any of the manuals. I know this can be accomplished with feedback -- if the function doesn't exist, has anyone written one? Thanks, Lewis Geer lewis@castor.wustl.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19249; 11 Mar 89 18:21 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19093; 11 Mar 89 18:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19035; 11 Mar 89 17:55 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa24185; 11 Mar 89 17:04 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA22331; Sat, 11 Mar 89 10:23:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 89 16:02:09 GMT From: Steve Holzworth Organization: William G. Daniel & Associates, Cary, N.C. Subject: Re: Binary Compatability? Message-Id: <199@tachyon.UUCP> References: <8902282220.aa21482@SEM.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8902282220.aa21482@SEM.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > Jim - > stuff deleted > It is not at all clear to me that the choice you made w.r.t. the GL > interface was at all necessary. I'm quite certain that you could have > carried support for all your different machines around in all versions > of the libraries. I believe this could have been implemented in such a > way as to only require a single extra memory load (indirection) per > subroutine call, a small price to pay. > Small Price!? I used to work for Ikonas Graphics Systems, writing microcode. I would go to >>extreme<< lengths to pull a Single instruction out of the code. Maybe your application doesn't require "balls to the wall" speed that mine typically do. If so, fine, but for some people, an extra indirection for each graphics call would be foolish when the current scheme of using shared libraries works quite well. > Negative comment: different SGI models are entirely too different, > inside. All the work that the GL has to do to hide the differences > is unfortunate, and bothersome. We are a VAR for SGI products. We sell a high-end CAD system for civil engineering and land planning. We ported from the 3000 series to a 4D70GT in about two weeks. When I went to SGI in August to port onto the Personal IRIS, it took all of a half hour to do. Everything worked, and I assure you, we push every bit of the hardware capabilities. > Positive comment: "IRIX" version 3.1, for the first time, actually > does a pretty good job of doing things. But I still seem to waste > a lot of my time trying to accomplish things that should have been simple. > > -Mike I agree with David Rogers. Every computer system I've ever worked with has had a few quirks. I have no complaints about SGI. Steve Holzworth Stephen Dedalus Incorporated   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21380; 12 Mar 89 13:05 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa21308; 12 Mar 89 12:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21306; 12 Mar 89 12:21 EST Received: from PIG.DREA.DND.CA by SMOKE.BRL.MIL id aa03136; 12 Mar 89 11:43 EST Received: Fri, 10 Mar 89 15:38:10 AST by pig.drea.dnd.ca (5.52/5.6) Date: Fri, 10 Mar 89 15:38:10 AST From: Jim Diamond Message-Id: <8903101938.AA09564@pig.drea.dnd.ca> To: info-iris@BRL.MIL Subject: Apropos changes for 3130 Recently G. Murdock Helms distributed an "apropos" program for 3000's. Since awk (at least on my 3130) doesn't seem to act as desired by GMH (specifically, split($0, s, "\\-") splits the line on every occurance of "\", not just on "\-"), any lines which had other "\"s were treated incorrectly. I've modified his script to take care of this problem, and to remove other nroff constructions not of interest to the "apropos" user. It seems to work fine on my man pages (I didn't closely check them all!), but I would appreciate being told about any problems with this version. Jim Diamond zsd@pig.drea.dnd.ca -------------------------------------------------------------------- #!/bin/sh # -i is used only by cron once a week in the middle of the night # to build the index. Other flags are incorrect. Apropos # will only take one argument at a time. # # Modified by Jim Diamond (zsd@pig.drea.dnd.ca) 89/03/10 10:54:00 as follows: # 1) Fixed bugs related to the fact that awk uses only the first character # of the "sep" text for "split"; thus in the old version any lines # containing more than one backslash were handled incorrectly. # 2) Added sed to remove various nroff constructs. # 3) Fixed handling of multiple (physical) line title lines. # # $Header: /usr/u/ssmith/RCS/apropos,v 1.3 88/06/13 12:32:15 ssmith Exp $ # # $Log: apropos,v $ # Revision 1.3 88/06/13 12:32:15 ssmith # Exit with message if no arguments (used to hang grep). # 'Unknown flag' message ( from "Usage...."). # Handle multiple args. ( 'for' loop ). # Use of grep's exit codes--message if nothing found. # grep flag from '-w' to '-i' (doug). # Eliminated pipe to 'more' ( screwed up $?). If desired, run grep in # a subshell then filter output, e.g., '| fold | more'. # Awk properly eliminates .B's from SGI graphics manual pages. # # Revision 1.2 88/06/13 12:27:37 ssmith # test for su added 11/9/87 # # Revision 1.1 88/06/13 12:21:05 ssmith # Initial revision # # # Database: index=/usr/local/lib/index if [ 0 -eq $# ] then echo $0 What?; exit; # echo "Usage: $0 [-i] [word]"; fi for i do case "$i" in -i) if [ ! -w /bin/su ] then echo $USER: You must be root to build index. exit 1 else build=1 fi break ;; -*) echo Unknown flag $i; exit ;; *) if grep -i $i $index then : ok; else echo "\nNothing appropriate: $i \n"; fi esac done # The following was written solely for the purpose of # getting the one line of info for apropos to use and # dumping it to a file an a reasonably aesthetic format. # This is achieved primarily with awk, and it does not hunt # through the whole file and waste time. if [ $build ] then for x in /usr/man/local/man?/* /usr/man/?_man/man?/* do awk ' {name="'`expr $x : '.*/\(.*\)\..*' \| $x`'";} /^\.TH/ {ver=$3;printf("%-15s",sprintf("%s(%s)",name,ver))} /^\.SH NAME/ { getline; while ($1 !~/^.SH/) { if ($1 ~ /\.B/) printf("%s ", $2); else printf("%s ", $0); getline; } printf("\n"); exit; } ' $x done | sed -e "s/\\\\-/-/g" -e "s/\\\\s[+-]*[0-9]**//g" \ -e "s/\\\\f[0-9P]//g" -e "s/\\\\(em/-/" -e "s/\\\\^//g" \ -e "s/\\\\|//g" -e "s/ *\$//" > $index else exit; fi # # Acknowledgements: The APROPOS clone was developed by # G. "Murdock" Helms, with major revisions and bug fixes # written by Steve Smith. Thanks to Doug Kerr, Khanh Nguyen, # and Steve Philipson for their help and suggestions. (Thanks guys!)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20359; 12 Mar 89 2:33 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20182; 12 Mar 89 1:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20096; 12 Mar 89 1:22 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27923; 12 Mar 89 1:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24163; Sat, 11 Mar 89 22:13:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 89 01:32:57 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: (none) Message-Id: <28503@sgi.SGI.COM> References: <8903102206.AA05862@redsim.RSI> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903102206.AA05862@redsim.RSI>, adams@redsim.UUCP ("Ronald B. Adams") writes: > > Any chance of getting an option added to man(1) that would let me > specify an alternative directory to /usr/catman? I want to keep all of > my man pages on my NFS server only, but I want each of my client PI's > to be able to use them. The -d option is NOT the answer. > This is so obvious that presumably you have some problem with this method but I'll say it anyway. Mount the man pages from your nfs server on /usr/catman. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20359; 12 Mar 89 2:33 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20182; 12 Mar 89 1:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab20096; 12 Mar 89 1:22 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27926; 12 Mar 89 1:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24147; Sat, 11 Mar 89 22:12:54 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Mar 89 01:30:08 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Lines per Window Message-Id: <28502@sgi.SGI.COM> References: <262@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <262@ai.etl.army.mil>, richr@ai.etl.army.mil (Richard Rosenthal) writes: > How does "more" program know how many lines in 4Sight window? > > Apparently not from termcap ... iris-ansii says 40 lines, but, > if I shrink the window to only 4 or 5 lines more still works > fine. > > I want to make "less" work like this, too. "less" seems to only > use termcap. > wsh sets the size in the kernel using the bsd TIOCSWINSZ ioctl. Terminfo and curses retrieve this information using the TIOCGWINSZ ioctl. Any program using curses or terminfo (e.g. more, ls, vi) works quite well. The version of less that I'm using works just fine. The algorithm in terminfo is as follows: set lines and columns from terminfo database if (TIOCGWINSZ) override lines and columns with ioctl data if (getenv(LINES)) override lines with environment value if (getenv(COLUMNS)) override columns with environment value We don't have termcap on the 4D (other than the libtermcap emulation provided by terminfo) so either you are on a 3xxx or you've provided your own termcap. For the 3xxx simply replace terminfo with termcap in the above algorithm. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06230; 13 Mar 89 15:09 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03946; 13 Mar 89 13:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03883; 13 Mar 89 13:28 EST Received: from RELAY.CS.NET by SMOKE.BRL.MIL id aa26403; 13 Mar 89 13:24 EST Received: from relay2.cs.net by RELAY.CS.NET id ah23549; 13 Mar 89 12:20 EST Received: from switzerland by RELAY.CS.NET id bs26966; 13 Mar 89 12:09 EST Received: from ean by scsult.SWITZERLAND.CSNET id a010751; 13 Mar 89 17:20 WET Date: 13 Mar 89 17:15 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET Message-ID: <19:doelz@urz.unibas.ch> Subject: SGI responses Hi, just a few (very critical) words on the praising of SGI's responses... 1.) I agree that the response on bug reports is (mostly) such quick that I don't think that there is a more efficient method available. 2.) I agree that people at SGI try to do their best, and they do it very hard. They are friendly and ask questions to nail the problem down. 3.) I agree that my programs are not bug-free (but I don't sell them either). * B U T * I am afraid that bug reports are necessary & effective, and the fixing of bugs is another story! Once you've encountered ^a problem, it makes you happy that SGI is able to reproduce the bug. But this does not at all mean that your problem is solved nor that a workaround is provided! E.g., > Authorizing-Users: Mark Callow > (Stuff deleted.) > >In other words, this is a bug in the GL. > >We are planning to fix the GL so you can use graphics from multiple >shared-processes (sproc threads). This is probably typical of the >problems we will uncover in that work. You can expect the problem to >be fixed though I don't know when. > >Unfortunately I can't think of a workaround. Perhaps the GL experts can >help. At least that means that they are aware of it ... My problems went the same way: bug reported, bug accepted, promises to fix it and then ... black hole. I am afraid that there are so many bugs that SGI is just too small (or just doesn't employ enough people) to get around this problem. On the VAXes, the introduction of VMS 5.0 went fairly smoothly because the product has been tested carefully, and admittedly DEC is slightly bigger than SGI is. I agree that I like to get new products as soon as they're available, but if the staff of SGI is too small to keep tracking all the problems, I suggest a discount system for bug reports: per bug 5 -20% off the maintenance, depending on severity. Reinhard (don't flame me too much - I am suffering from an IRIS since 8 months).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10897; 13 Mar 89 21:22 EST Received: by VMB.BRL.MIL id aa10861; 13 Mar 89 21:21 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab10599; 13 Mar 89 20:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10595; 13 Mar 89 19:58 EST Received: from [10.2.0.78] by SMOKE.BRL.MIL id aa04484; 13 Mar 89 19:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA17948; Mon, 13 Mar 89 16:34:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 89 22:03:57 GMT From: Dave Forsey Organization: U of Waterloo, Ontario Subject: Video Playback on the GTX. Message-Id: <8582@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL At the SGI booth at SIGGRAPH last year, one of the demos on the GTX presented a window repeatedly replaying a short segment of previously captured NTSC video. Was this accomplished by filling up the framebuffer with the images and copying them one after another into the visible window, or did the images come from main memory? Dave Forsey Computer Graphics Laboratory, University of Waterloo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12215; 14 Mar 89 3:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11968; 14 Mar 89 1:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11885; 14 Mar 89 1:27 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa07610; 14 Mar 89 1:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05286; Mon, 13 Mar 89 22:17:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 89 03:55:37 GMT From: Gavin Bell Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Video Playback on the GTX. Message-Id: <28573@sgi.SGI.COM> References: <8582@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL That program is called 'blast', and it stored its images in main memory (I believe that demo needed at least 32 megabytes of real memory...) There are two other demos, 'cine' and 'cinebw', that store their images in frame buffer memory; they both take over the entire screen, while blast runs in its own window (cinebw handles black&white images, cine does full-color RGB images). --gavin (gavin@sgi.com) Disclaimer: I make just as many dumb little mistakes as anybody...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20837; 17 Mar 89 3:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20803; 17 Mar 89 3:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20797; 17 Mar 89 3:19 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27866; 17 Mar 89 3:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA16378; Fri, 17 Mar 89 00:16:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Mar 89 21:40:40 GMT From: Jeremy Nussbaum Organization: Prime Computervision, Bedford MA Subject: core dumps, malloc, notesfiles Message-Id: <976@cvbnet2.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have an sgi 4d with release 3.1 of the os. I brought up the notesfiles system, and had recurring core dumps on startup. The coredumps occured in about 10 different places, with no apparent cause. The problem finally went away when I added the lines mallopt(M_KEEP,0); mallopt(M_DEBUG); to the beginning of the main program. Can anyone guess/tell me why this fixed up the random core dumps? I realize that reusage of freed storage is a problem, but the core dumps occurred very early on, and with the "old" version of malloc. Also, this code runs as is on many machines. More info: - the notesfile source is 1.7.0.3, which I believe is the most recent. - the core dumps occurred at startup, in getpwnam (actually at the bottom of a whole bunch of calls initiated by the getpwnam call), in an ioctl (!) and a number of other places, implying that random data structures were being clobbered. - the core dumps occurred both with the default malloc, and with the libmalloc malloc. Adding the above two lines has completely cured the problem. Thanks,   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20320; 20 Mar 89 23:18 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20168; 20 Mar 89 22:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20150; 20 Mar 89 22:32 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa13992; 20 Mar 89 22:28 EST Received: from columbia.edu by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA04122; Mon, 20 Mar 89 22:29:11 EST Received: from cucard.med.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA02479; Mon, 20 Mar 89 22:16:27 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA16314; Mon, 20 Mar 89 22:16:14 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA11294; Mon, 20 Mar 89 18:11:50 EST Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA27001; Mon, 13 Mar 89 04:54:33 EST Date: Mon, 13 Mar 89 04:54:33 EST From: Rod Paul Message-Id: <8903130954.AA27001@dasys1.UUCP> To: info-iris@BRL.MIL, richr@ai.etl.army.mil Subject: Re: Lines per Window Seems you may have an old version of "less", let me know what version you have and I've got a later one I'll pass it on. If you're running a 4D series with v 2.0, 2.2 or 3.1 you can hack /bin/man (or is it /usr/bin/man ?), anyway you can plug in "less" , it even handles ^Z on the new OS.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20431; 20 Mar 89 23:49 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20168; 20 Mar 89 22:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab20150; 20 Mar 89 22:32 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa13993; 20 Mar 89 22:28 EST Received: from columbia.edu by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA04123; Mon, 20 Mar 89 22:29:12 EST Received: from cucard.med.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA02477; Mon, 20 Mar 89 22:16:20 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA16308; Mon, 20 Mar 89 22:16:06 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA11284; Mon, 20 Mar 89 18:11:36 EST Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA26417; Mon, 13 Mar 89 04:49:14 EST Date: Mon, 13 Mar 89 04:49:14 EST From: Rod Paul Message-Id: <8903130949.AA26417@dasys1.UUCP> To: info-iris@BRL.MIL, mlj8e@dale.acc.virginia.edu Subject: Re: EDT for 4D Well I guess some people never want to progress.....   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16219; 14 Mar 89 8:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14804; 14 Mar 89 8:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14489; 14 Mar 89 7:47 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa10363; 14 Mar 89 7:40 EST Received: Tue, 14 Mar 89 07:40:31 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 14 Mar 89 07:40:31 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903141540.AA11796@aero4.larc.nasa.gov> To: doelz%urz.unibas.ch@relay.cs.net Subject: Re: SGI responses Cc: info-iris@BRL.MIL Sounds good to me. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26558; 14 Mar 89 18:38 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab26181; 14 Mar 89 17:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab26151; 14 Mar 89 17:15 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa28260; 14 Mar 89 17:01 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA29532; Tue, 14 Mar 89 16:58:56 EST Received: by buita.bu.edu (3.2/4.7) id AA03180; Tue, 14 Mar 89 16:59:17 EST Received: by adt.uucp (3.2/SMI-3.2) id AA07266; Tue, 14 Mar 89 13:21:09 EST Date: Tue, 14 Mar 89 13:21:09 EST From: jim frost Message-Id: <8903141821.AA07266@adt.uucp> To: info-iris@BRL.MIL Cc: Subject: SGI 'su' I would appreciate it very, very much if someone would fix 'su' so it properly reads the destination user's shell configuration files. I'm about to hack one together but I really shouldn't have to do that. This is very important to me since our root .cshrc properly sets the prompt to the hash mark, but this is never called when su'ing. If you forget, or if someone walks up, you or they will unknowingly be root. This is of course very dangerous even if security isn't an issue. jim frost associative design technology madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27694; 14 Mar 89 23:47 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa27406; 14 Mar 89 22:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27392; 14 Mar 89 22:04 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa00738; 14 Mar 89 21:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA28893; Tue, 14 Mar 89 15:58:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 89 23:47:23 GMT From: Stephen Smith Organization: NASA Ames Research Center, Calif. Subject: apropos version B 3000-series Message-Id: <2898@eos.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I changed the format of apropos to avoid problems with split() and to make it appear a true clone. Installation as /usr/local/bin/apropos. The index by default points at /usr/local/lib/index. Steve Smith comments/complaints/compliments to: ssmith@eos.arc.nas.gov ============================ snip snip ================================ #!/bin/sh # # BSD apropos clone -- lookup manual pages by keyword # # Usage: apropos [-i] | [ key words... ] # -i builds the index used for the keyword lookups. # # Notes: # It is not advisable to build the index and do keyword lookups simultaneously. # We use cron to build the index once a week at night. # # # $Header: /usr/u/ssmith/RCS/apropos,v 1.3 88/08/12 10:00:15 ssmith Exp $ # # $Log: apropos,v $ # Revision 1.3 88/08/12 10:00:15 ssmith # New rcs file # # Revision 1.3 88/06/13 12:32:15 ssmith # Exit with message if no arguments (used to hang grep). # 'Unknown flag' message ( from "Usage...."). # Handle multiple args. ( 'for' loop ). # Use of grep's exit codes--message if nothing found. # grep flag from '-w' to '-i' (doug). # Eliminated pipe to 'more' ( screwed up $?). If desired, run grep in # a subshell then filter output, e.g., '| fold | more'. # Awk properly eliminates .B's from SGI graphics manual pages. # # Revision 1.2 88/06/13 12:27:37 ssmith # test for su added 11/9/87 # # Revision 1.1 88/06/13 12:21:05 ssmith # Initial revision # # # Database: index=/usr/local/lib/index build=0 # don't build if [ 0 -eq $# ] then echo $0 What?; exit; # echo "Usage: $0 [-i] [word]"; fi for i do case "$i" in -i) if [ ! -w /bin/su ] then echo $USER: You must be root to build index. exit 1 else build=1 fi break ;; -*) echo Unknown flag $i; exit ;; *) (if grep -i $i $index then : ok; else echo "$i: Nothing appropriate."; fi) | fold esac done if [ $build -eq 0 ]; then exit ; fi # # Build data base (-i). Each entry consists of man page and section, and a # brief description of the command. # PATH=/bin:/usr/bin: root=/usr/man ; sec=[au]_man ; lsec=local ; subsec=man[0-9] ; files="$root/$sec/$subsec/*"; lfiles="$root/$lsec/$subsec/*" ; for x in $files $lfiles do awk ' /^\.TH/ { sec="("$3")"; } /^\.SH NAME/ { for( getline ; $1 !~ /^.SH/ ; getline ) { $1 = substr($1, 1, length($0)); if($1 == ".B") { $1 = $2; $2=""; }; str = str $0 " "; } d = index(str, "-"); printf("%-20s %s\n", substr(str, 1, d-2)sec, substr( str, d)); exit; } ' $x done 2> $index.errs | deroff -mm > $index if [ ! -s $index.errs ] ; then rm -f $index.errs ; fi ; exit 0; # Note: # deroff doesn't handle leading '.B's (gl pages), they're stripped first. # Acknowledgements: The APROPOS clone was developed by # G. "Murdock" Helms on behest of Doug Kerr, with thanks to # Doug Kerr, Khanh Nguyen, Steve Philipson and Steve Smith # for their help and suggestions. (Thanks guys!)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28886; 15 Mar 89 4:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28695; 15 Mar 89 3:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28679; 15 Mar 89 2:47 EST Received: from RELAY.CS.NET by SMOKE.BRL.MIL id aa02551; 15 Mar 89 2:39 EST Received: from relay2.cs.net by RELAY.CS.NET id ae18626; 15 Mar 89 0:00 EST Received: from switzerland by RELAY.CS.NET id ah17278; 14 Mar 89 23:49 EST Received: from ean by scsult.SWITZERLAND.CSNET id a014546; 14 Mar 89 13:40 WET Date: 14 Mar 89 13:07 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET Message-ID: <20:doelz@urz.unibas.ch> Subject: EAN networking software Return-Receipt-To: "Reinhard Doelz" Hi, because we're not supporting NFS and 4DDN does not do what we want to do, we need to install a mailing software which is not dependent of the OS. The EAN software (copyrighted by University of British Columbia 1987) is installed on all the VAXes without problems. Now we got the EAN distribution tape for BSD UNIX which is supposed to run without problems on SUN's. Because they try to be compatible to any UNIX, there should be little or no BSD- specific stuff (There are some crazy IRIX problems - e.g., no ranlib - but I found it in the 4Dgifts somewhere). Therefore we were disappointed that it just doesn't run under IRIX 3.1. The problem is that we get a lot of error messages which are rather complicated to be resolved. Did anyone out in netland try to install EAN on a SGI ? Reinhard P.S. The Ean message system was developed by the Distributed Systems Research Group within the University of British Columbia's Department of Computer Science. The version we got for UNIX is EAN for BSD UNIX Version 2.1.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05256; 15 Mar 89 18:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04207; 15 Mar 89 16:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04041; 15 Mar 89 16:15 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa20896; 15 Mar 89 16:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA26426; Wed, 15 Mar 89 11:30:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 89 04:42:36 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SGI 'su' Message-Id: <28701@sgi.SGI.COM> References: <8903141821.AA07266@adt.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903141821.AA07266@adt.uucp>, madd@adt.UUCP (jim frost) writes: > I would appreciate it very, very much if someone would fix 'su' so it > properly reads the destination user's shell configuration files. I'm > about to hack one together but I really shouldn't have to do that. > > This is very important to me since our root .cshrc properly sets the > prompt to the hash mark, but this is never called when su'ing. If you > forget, or if someone walks up, you or they will unknowingly be root. > This is of course very dangerous even if security isn't an issue. Here's how I deal with that problem in my .cshrc without changing su. I ran into this when I first started working at SGI. As far as I recall the problem isn't with su but with the way System V handles the "effective user" compared with BSD. if ($?prompt) then if ("$prompt" == "# ") then set prompt = `hostname`'#\! ' set path=(/usr/local/bin /usr/bsd /bin /etc /usr/etc /usr/bin /usr/sbin /usr/hosts /usr/games /usr/NeWS/bin /usr/demos/bin) umask 22 else set prompt = `hostname`'{\!} ' endif endif -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03430; 15 Mar 89 15:43 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01693; 15 Mar 89 14:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01422; 15 Mar 89 14:16 EST Received: from [128.186.3.1] by SMOKE.BRL.MIL id aa13976; 15 Mar 89 12:44 EST Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA06746; Wed, 15 Mar 89 12:49:45 EST Date: Wed, 15 Mar 89 12:49:45 EST From: "John D. McCalpin" Message-Id: <8903151749.AA06746@masig1.ocean.fsu.edu> To: info-iris@BRL.MIL Subject: Feedback Optimizer I have been experimenting with the various optimization parameters of the MIPS f77 compiler on a Personal IRIS. In several places, the documentation refers to the ability of the system to create and use a feedback file, which allows the optimizer to make use of profiling information in a previous run in a new compilation. The prof(1) manual entry explains how to create the feedback file, but does not tell how to use it. Neither do the man pages for f77(1) or pixie(1). The compiler optimization guide in the C manual does not refer to this feature either, except that such a feedback file appears in two figures. The prof(1) entry tells me to read the entries for umerge(1) and uopt(1) for further information. These man pages are not distributed with the system, either on-line or hard-copy. I called the hotline and spent some time explaining to the compiler person there how the system was supposed to work. Now I remember why I quit using the hotline! I shouldn't pick on SGI, though, since I got about the same result by calling MIPS.... So, does anyone know what to do with the feedback file created by 'prof -pixie -feedback feedback_file' to make the compiler/optimizer use it? -- ---------------------- John D. McCalpin ------------------------- Mesoscale Air-Sea Interaction Group & Department of Oceanography & Supercomputer Computations Research Institute - Fl State Univ. mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN) ------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03700; 15 Mar 89 15:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01693; 15 Mar 89 14:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01437; 15 Mar 89 14:17 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa14497; 15 Mar 89 12:57 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA23149; Wed, 15 Mar 89 12:55:41 EST Received: by buita.bu.edu (3.2/4.7) id AA06056; Wed, 15 Mar 89 12:56:04 EST Received: by adt.uucp (3.2/SMI-3.2) id AA29409; Wed, 15 Mar 89 12:47:52 EST Date: Wed, 15 Mar 89 12:47:52 EST From: Joe Ilacqua Message-Id: <8903151747.AA29409@adt.uucp> To: info-iris@BRL.MIL Subject: Compiling for different 4Ds Is there any way within the C Preprocessor to tell whether we are compiling on at Personal Iris or a 4D/70g ? I need to know If I can use rectread() or if I must use readpixels(). A way to find out at run time could be useful also. The number of pixels read at any one time is small so I could use readpixels() if I had to, but rectread is 10 times faster... Joe Ilacqua, Associative Design Technology   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04440; 15 Mar 89 16:42 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab04207; 15 Mar 89 16:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab04041; 15 Mar 89 16:15 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa20906; 15 Mar 89 16:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA26945; Wed, 15 Mar 89 11:38:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 89 17:50:31 GMT From: Archer Sully Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SGI 'su' Message-Id: <28714@sgi.SGI.COM> References: <8903141821.AA07266@adt.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903141821.AA07266@adt.uucp>, madd@adt.UUCP (jim frost) writes: > I would appreciate it very, very much if someone would fix 'su' so it > properly reads the destination user's shell configuration files. I'm > about to hack one together but I really shouldn't have to do that. > > This is very important to me since our root .cshrc properly sets the > prompt to the hash mark, but this is never called when su'ing. If you > forget, or if someone walks up, you or they will unknowingly be root. > This is of course very dangerous even if security isn't an issue. This is normal, proper System V behavior for su. If you use 'su -', then the full login procedure is followed. If you don't wish to use su - for whatever reason, you can have your own .cshrc check your uid, and set the prompt to a # when you are root. archer --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04440; 15 Mar 89 16:43 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac04207; 15 Mar 89 16:32 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa04095; 15 Mar 89 16:16 EST Received: from UCBVAX.Berkeley.EDU by ADM.BRL.MIL id aa01296; 15 Mar 89 16:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29031; Wed, 15 Mar 89 12:18:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 89 19:45:16 GMT From: George Hartzell Organization: University of Colorado, Boulder Subject: Problem with 2400T Message-Id: <7441@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are having some network trouble with an iris 2400Turbo. It is running version GL2-3.5 of sgi's unix, with tcp/ip. Apparently it is responding to routing packets with a "port unreachable" ICMP reply. My understanding is that it should just be ignoring them. Has anyone seen this before? George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05724; 15 Mar 89 20:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05672; 15 Mar 89 20:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05645; 15 Mar 89 20:35 EST Received: from lakisis.umd.edu by SMOKE.BRL.MIL id aa25292; 15 Mar 89 20:31 EST Date: Wed, 15 Mar 89 20:31:26 EST From: Mark Phillips Message-Id: <8903160131.AA28305@lakisis.umd.edu> Received: by lakisis.umd.edu; Wed, 15 Mar 89 20:31:26 EST To: info-iris@BRL.MIL Subject: question about IRIS version of Mathematica Does anyone know how disk space the IRIS version of Mathematica takes up? Mark Phillips mbp@lakisis.umd.edu (arpanet) Department of Mathematics (301) 454-2693 University of Maryland College Park, Maryland 20742   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05782; 15 Mar 89 21:26 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05613; 15 Mar 89 20:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05594; 15 Mar 89 20:11 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa25159; 15 Mar 89 20:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA13568; Wed, 15 Mar 89 16:44:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 00:33:50 GMT From: Eric Pearce Organization: BD&HR (Beer Drinkers & Hell Raisers) Subject: Re: Lines per Window Message-Id: <28713@bu-cs.BU.EDU> References: <262@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <262@ai.etl.army.mil> richr@ai.etl.army.mil. (Richard Rosenthal) says: >How does "more" program know how many lines in 4Sight window? > >Apparently not from termcap ... iris-ansii says 40 lines, but, >if I shrink the window to only 4 or 5 lines more still works >fine. > >I want to make "less" work like this, too. "less" seems to only >use termcap. I have a version of less (version 61) and it has support for both termcap + terminfo and other differences between BSD and SYSV. I had better luck compiling it with the SYSV defines (on an IRIS personal). You should be able to get it at any decent archive site, if not, I can mail it to you. -e -- ------------------------------------------------------------------------------- Eric Pearce ARPANET eap@bu-it.bu.edu Boston University Information Technology CSNET eap%bu-it@bu-cs 111 Cummington Street JNET jnet%"ep@buenga" Boston MA 02215 UUCP !harvard!bu-cs!bu-it!eap 617-353-2780 voice 617-353-6260 fax BITNET ep@buenga   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06209; 15 Mar 89 23:16 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab06115; 15 Mar 89 23:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab06082; 15 Mar 89 22:57 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26518; 15 Mar 89 22:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA22500; Wed, 15 Mar 89 19:33:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 89 23:45:58 GMT From: Archer Sully Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Compiling for different 4Ds Message-Id: <28776@sgi.SGI.COM> References: <8903151747.AA29409@adt.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903151747.AA29409@adt.uucp>, spike@adt.UUCP (Joe Ilacqua) writes: > > Is there any way within the C Preprocessor to tell whether we > are compiling on at Personal Iris or a 4D/70g ? I need to know If I > can use rectread() or if I must use readpixels(). A way to find out > at run time could be useful also. The number of pixels read at any > one time is small so I could use readpixels() if I had to, but > rectread is 10 times faster... > > Joe Ilacqua, > Associative Design Technology You can get the information about the what kind of graphics you are on from gversion at run time. There is a man page on it, but a quick summary might look like this: #include main() { char version[12]; noport(); winopen(""); gversion(version); printf("%s\n",version); } the output of this program will look something like this: GL4D-x.x on a 4D/70G GL4DGT-x.x on a GT or GTX GL4DPI-x.x on a Personal Iris where x.x is the release of the OS that you are running on. Archer Sully archer@sgi.com "life is short, and full of stuff" -- Lux Interior --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06714; 16 Mar 89 0:18 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa06115; 15 Mar 89 23:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06082; 15 Mar 89 22:57 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26507; 15 Mar 89 22:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA22529; Wed, 15 Mar 89 19:33:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 00:15:24 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: ranlib is not needed in System V Message-Id: <28784@sgi.SGI.COM> References: <20:doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <20:doelz@urz.unibas.ch> doelz@urz.unibas.ch (Reinhard Doelz) writes: [lines relating to the real issue deleted] >specific stuff (There are some crazy IRIX problems - e.g., no ranlib - but I System V ar has ranlib built in - selected with option s. There is no separate ranlib program. In our version of ar options d, m, r, and u imply option s. Having options dmru imply option s means that doing ar cr x.a x.o ar cr x.a y.o ... is *very slow*, since the symbol table gets rebuilt again and again. ar crs x.a x.o y.o ... is much faster. Explicitly showing option s makes the above line compatible with standard System V. Regards, [ David B. Anderson Silicon Graphics (415) 964-1459 x3060 ] [ USENET: {decwrl!,hplabs!sun!}sgi!davea Internet: davea@sgi.com ] ``I ca'n't believe *that*!'' said Alice. ``Ca'n't you?'' the Queen said in a pitying tone. ``Try again: draw a long breath, and shut your eyes.'' Through the Looking-Glass   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16254; 16 Mar 89 14:58 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15224; 16 Mar 89 14:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15151; 16 Mar 89 14:19 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa14847; 16 Mar 89 14:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05456; Thu, 16 Mar 89 11:02:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 00:53:15 GMT From: Archer Sully Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Feedback Optimizer Message-Id: <28788@sgi.SGI.COM> References: <8903151749.AA06746@masig1.ocean.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903151749.AA06746@masig1.ocean.fsu.edu>, mccalpin@MASIG1.OCEAN.FSU.EDU ("John D. McCalpin") writes: > > So, does anyone know what to do with the feedback file created by > 'prof -pixie -feedback feedback_file' to make the compiler/optimizer > use it? The usage message from umerge looks like this: Usage is: umerge infile [-f feedbackfile -t symfile] -o outfile [options...] options are: -g<0-3> -O<0-4> -debug -bbmax n -i file -inline_all -noinline -growth_limit x You can get umerge to use the feedback file by using the followin incantation: cc -O3 -Wm,-f,feedback <.u files> the -Wm passes the list of arguments to umerge. This documented near the end of the cc man page. I'm not sure if it actually works, as I just tried something that uses a completely bogus feedback file, and umerge didn't complain at all. But you never know. Good luck, Archer Sully archer@sgi.com "life is short, and full of stuff" -- Lux Interior --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16254; 16 Mar 89 14:58 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15700; 16 Mar 89 14:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15430; 16 Mar 89 14:32 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa15329; 16 Mar 89 14:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05501; Thu, 16 Mar 89 11:03:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 04:02:02 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: question about IRIS version of Mathematica Message-Id: <28804@sgi.SGI.COM> References: <8903160131.AA28305@lakisis.umd.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903160131.AA28305@lakisis.umd.edu>, mbp@LAKISIS.UMD.EDU (Mark Phillips) writes: > > Does anyone know how disk space the IRIS version of Mathematica takes > up? > > Mark Phillips mbp@lakisis.umd.edu (arpanet) > Department of Mathematics (301) 454-2693 > University of Maryland > College Park, Maryland 20742 According to du, Mathematica requires 8091 512-byte blocks or roughly 4MB of diskspace. -- Dave (commonplace) "Boldly going where no one cares to go." Ciemiewicz (incomprehensible) ciemo (infamous)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16911; 16 Mar 89 15:40 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab15224; 16 Mar 89 14:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab15151; 16 Mar 89 14:19 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa14880; 16 Mar 89 14:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05463; Thu, 16 Mar 89 11:02:53 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 02:36:38 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Problem with 2400T Message-Id: <28794@sgi.SGI.COM> References: <7441@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <7441@boulder.Colorado.EDU>, hartzell@boulder.Colorado.EDU (George Hartzell) writes: > We are having some network trouble with an iris 2400Turbo. It is > running version GL2-3.5 of sgi's unix, with tcp/ip. Apparently it is > responding to routing packets with a "port unreachable" ICMP reply. My > understanding is that it should just be ignoring them. Has anyone seen > this before? > George Hartzell (303) 492-4535 > MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 > hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell What kind of routing packets? RIP/UDP? If so, is routed(1M) running? I seem to recall a bug which would cause routed to quite. I don't remember if it was fixed before or after 3.6. Of course, corruption of files such as /etc/services and /etc/rc.tcp, or a crazy YP master could make it difficult or impossible for routed(1M) to run. In any case, you really should consider upgrading to 3.6. My understanding of the universe and everything implies one should not ignore ordinary UDP packets. One hopes and expects that you are not seeing port-unreachables for ICMP-redirects. If you are using some other kind of routing, with a deamon that is supposed to be listen on some port other than 520, then you'll have to do some porting. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09378; 16 Mar 89 8:36 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09169; 16 Mar 89 8:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09002; 16 Mar 89 8:08 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01767; 16 Mar 89 8:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA17606; Thu, 16 Mar 89 04:57:02 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 09:35:07 GMT From: Len Lattanzi Organization: Synthesis Software Solutions Inc, Sunnyvale, CA Subject: Re: Feedback Optimizer Message-Id: <15354@mips.mips.COM> References: <8903151749.AA06746@masig1.ocean.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903151749.AA06746@masig1.ocean.fsu.edu> mccalpin@MASIG1.OCEAN.FSU.EDU ("John D. McCalpin") writes: :So, does anyone know what to do with the feedback file created by :'prof -pixie -feedback feedback_file' to make the compiler/optimizer :use it? :-- My data is based on Mips Compilers version 1.31 (use f77 -V to verify your version) There are two supported uses for feedback files. 1) Cache reorganizer prof -pixie -feedback fb f77 -cord -feedback fb -o xxx .... You should have a new binary whose procedures are organized to cause minimal cache conflicts when run in the same configuration as the feedback run 2) Inliner f77 -O3 -feedback -o xxx .... This option gives umerge hints about inlining based on your feedback run. I say hints because it's not always advantageous to inline. (Or are you running Dhrystone :-) I will let MIPS know about the missing uopt/umerge man pages. Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> Synthesis Software Solutions, Inc. 1 408 991 0367 292 Commercial Avenue, Sunnyvale, California 94086   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13716; 16 Mar 89 12:36 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa12438; 16 Mar 89 11:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12284; 16 Mar 89 10:49 EST Received: from [128.186.3.1] by SMOKE.BRL.MIL id aa08184; 16 Mar 89 10:41 EST Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA10569; Thu, 16 Mar 89 11:16:07 EST Date: Thu, 16 Mar 89 11:16:07 EST From: "John D. McCalpin" Message-Id: <8903161616.AA10569@masig1.ocean.fsu.edu> To: -v@masig1.ocean.fsu.edu, info-iris@BRL.MIL Subject: Feedback optimization Thanks to: Len Lattanzi (len@Synthesis.com) Synthesis Software Solutions, Inc. for information about the feedback optimization. Some more questions: (1) Can both of these options (cache reorganization and inlining) be used at the same time? (2) The -O3 with the -feedback option worked. I got no speedup on this particular code, but that is not necessarily a problem. (3) The -cord option does NOT work. The compiler gets almost to the end before bombing --- it could not find /usr/bin/ftoc. What does ftoc do, and should it be there? By the way, I am not running dhrystone :-). I am running LINPACK and a variety of floating-point intensive finite-difference PDE codes. So far it looks like loop unrolling buys a lot on this machine. On 32-bit LINPACK (order 100 case), with full optimization -O3, unrolling the innermost loops (the BLAS subroutines) gives a speedup from 1.4 to 1.9 MFLOPS (unrolled to a depth of 16). I still can't recover the 3.0 MFLOPS in the LINPACK published results for the MIPS M-800 (which should be the same CPU and clock speed). -- ---------------------- John D. McCalpin ------------------------- Mesoscale Air-Sea Interaction Group & Department of Oceanography & Supercomputer Computations Research Institute - Fl State Univ. mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN) ------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19168; 16 Mar 89 21:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19072; 16 Mar 89 21:22 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19047; 16 Mar 89 21:07 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa25364; 16 Mar 89 20:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA25706; Thu, 16 Mar 89 17:31:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 89 23:04:04 GMT From: Irvin Lustig Organization: Princeton Univ. Computing and Information Technology Subject: gr_osview on a remote host Message-Id: <7133@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are trying to use the -N option of gr_osview and get the message "Password incorrect." "Unable to invoke remote demon" All of our hosts are using yellow pages. It's not clear how to supply the "correct" password. Is there some special change to the services file? Do we need to set .rhosts in a special way? Any help is greatly appreciated. -Irv Lustig Assistant Professor Dept. of Civil Engineering and Operations Research Princeton University irv%basie@princeton.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20979; 21 Mar 89 2:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20892; 21 Mar 89 2:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab20835; 21 Mar 89 1:47 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa15346; 21 Mar 89 1:33 EST Received: from columbia.edu by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA20713; Tue, 21 Mar 89 01:34:52 EST Received: from cucard.med.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA02724; Mon, 20 Mar 89 22:32:58 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA16770; Mon, 20 Mar 89 22:28:04 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA11932; Mon, 20 Mar 89 18:26:13 EST Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA03394; Thu, 16 Mar 89 00:08:41 EST Date: Thu, 16 Mar 89 00:08:41 EST From: Rod Paul Message-Id: <8903160508.AA03394@dasys1.UUCP> To: doelz@urz.unibas.ch, info-iris@BRL.MIL Subject: Re: EAN networking software r.e. "ranlib", read the documentation on "ar", I beleive the flags "-ts" takes care of updating the symbol tables (thus no need for ranlib).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21019; 21 Mar 89 2:49 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20830; 21 Mar 89 1:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20818; 21 Mar 89 1:35 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa15340; 21 Mar 89 1:32 EST Received: from columbia.edu by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA20655; Tue, 21 Mar 89 01:34:14 EST Received: from cucard.med.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA02690; Mon, 20 Mar 89 22:30:42 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA16758; Mon, 20 Mar 89 22:27:48 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA11918; Mon, 20 Mar 89 18:25:56 EST Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA03100; Thu, 16 Mar 89 00:01:42 EST Date: Thu, 16 Mar 89 00:01:42 EST From: Rod Paul Message-Id: <8903160501.AA03100@dasys1.UUCP> To: info-iris@BRL.MIL, watcgl!drforsey@watmath.waterloo.edu Subject: Re: Video Playback on the GTX. I don't know if perchance you're refering to the demo that Hannaway & Associates were playing on their GTX. Was the sequence you saw a cowboy galloping on a horse? If so it was them and if you need their number I can give it to you.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21080; 21 Mar 89 3:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20892; 21 Mar 89 2:07 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20835; 21 Mar 89 1:47 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa15344; 21 Mar 89 1:33 EST Received: from columbia.edu by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA20732; Tue, 21 Mar 89 01:34:54 EST Received: from cucard.med.columbia.edu by columbia.edu (5.59++/0.3) with SMTP id AA02726; Mon, 20 Mar 89 22:33:05 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA16782; Mon, 20 Mar 89 22:28:21 EST Received: by cucard.med.columbia.edu (5.51/5.10) id AA11951; Mon, 20 Mar 89 18:26:33 EST Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA03611; Thu, 16 Mar 89 00:13:01 EST Date: Thu, 16 Mar 89 00:13:01 EST From: Rod Paul Message-Id: <8903160513.AA03611@dasys1.UUCP> To: adt!madd@bu-it.bu.edu, info-iris@BRL.MIL Subject: Re: SGI 'su' I've never had any problem with "su" regarding the correct prompts, my systems all pretty much use the distributed .cshrc's .login's .profile's etc The only problems I have is using 'newgrp' if my shell is csh and I try to re-log in with the new group id.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28348; 17 Mar 89 10:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25587; 17 Mar 89 9:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25533; 17 Mar 89 9:04 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa02396; 17 Mar 89 8:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29862; Fri, 17 Mar 89 05:45:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Mar 89 12:43:04 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: Mathematica Message-Id: <402@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am interested in acquiring Mathematica for my 4D system and need information about where and how to get it. Thanks. (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07002; 17 Mar 89 19:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa06597; 17 Mar 89 17:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06559; 17 Mar 89 17:23 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa17211; 17 Mar 89 17:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24703; Fri, 17 Mar 89 13:56:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Mar 89 19:18:20 GMT From: Bron Campbell Nelson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: LINPACK Message-Id: <28904@sgi.SGI.COM> References: <8903161616.AA10569@masig1.ocean.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903161616.AA10569@masig1.ocean.fsu.edu>, mccalpin@MASIG1.OCEAN.FSU.EDU ("John D. McCalpin") writes: > So far it looks like loop unrolling buys a lot on this machine. > On 32-bit LINPACK (order 100 case), with full optimization -O3, > unrolling the innermost loops (the BLAS subroutines) gives a speedup > from 1.4 to 1.9 MFLOPS (unrolled to a depth of 16). I still can't > recover the 3.0 MFLOPS in the LINPACK published results for the MIPS > M-800 (which should be the same CPU and clock speed). Unrolling (especially of things like DAXPY) does indeed help on the machine. In addition to all the "standard" reasons, the MIPS f.p. unit has independent multiply and add units. So by unrolling the loop, you provide a number of fp adds that can happen concurrently with the multiplies; a bit win. I don't know why you're seeing such low numbers; they look more like the double precision rates (rather than the 32bit rates you say you're working on). I just ran the code on my machine (a 12Mhz 4D/60) and I just got about 2.3MFLOPS using -O2 optimization (straight Fortran code as supplied from Dongarra; daxpy unrolled to a depth of 4). -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09603; 17 Mar 89 22:14 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa08156; 17 Mar 89 20:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07313; 17 Mar 89 20:36 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa19176; 17 Mar 89 20:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA04889; Fri, 17 Mar 89 17:17:45 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Mar 89 21:00:33 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: gr_osview on a remote host Message-Id: <28921@sgi.SGI.COM> References: <7133@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <7133@phoenix.Princeton.EDU>, ijlustig@phoenix.Princeton.EDU (Irvin Lustig) writes: > We are trying to use the -N option of gr_osview and get the message > "Password incorrect." > "Unable to invoke remote demon" > > All of our hosts are using yellow pages. > It's not clear how to supply the "correct" password. Is there some > special change to the services file? Do we need to set .rhosts > in a special way? > > Any help is greatly appreciated. > > -Irv Lustig > Assistant Professor > Dept. of Civil Engineering and Operations Research > Princeton University > irv%basie@princeton.edu There are lots of reasons that this could happen. If you don't use the -Nuser@host syntax, gr_osview attempts to login as "guest". If you don't support a guest login, or it has a password, then the attempt will fail. Due to a bug in the current gr_osview, going to any 'user' which has a password in the password file will fail. Unfortunately, this causes a security breach which may not be acceptable in some installations. I haven't been able to devise a workaround. This bug will be fixed in the next release of IRIX, the 3.2 release due mid-year. PS. This bug is totally my own fault, so flame me, but it's not really necessary to trash SGI for not fixing bugs. Even the best of us can't do everything perfect. PPS. The 3.2 release will have a brand new version of gr_osview that you will like alot. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00085; 18 Mar 89 18:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00218; 18 Mar 89 18:01 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa00198; 18 Mar 89 17:41 EST Received: from UCBVAX.Berkeley.EDU by ADM.BRL.MIL id aa00215; 18 Mar 89 13:08 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA22011; Sat, 18 Mar 89 11:52:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Mar 89 19:41:17 GMT From: Stuart Levy Organization: Minnesota Regional Network, Mpls., MN Subject: IRIS 4-D: inetd crashes if yp is on Message-Id: <1226@nic.MR.NET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm hoping some or many of you have dealt with this problem before. /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection attempt, if we have yellow pages enabled. (Its YP server is then a Sun running SunOS 3.5.) YP appears to work fine otherwise on things like passwd and hosts lookups. Inetd runs as expected when we just disable YP. This is tolerable but it'd be nice to have it. Inetd starts up normally, listening on the right ports (telnet, ftp, rsh etc); the first connection attempt succeeds and then is immediately dropped, as inetd leaves a core dump. It appears to be doing something like FD_ISSET with an fd of -1 -- which causes a crash since it's treated as unsigned and so tries to index in its array with a huge offset -- but it's too hard to trace where that number came from. Any clues would be appreciated! Stuart Levy slevy@geom.umn.edu (or slevy@nic.mr.net or slevy@uc.msc.umn.edu) === By the way, in the exchange on sending ICMP port unreachables in reply to routing packets: hosts are not supposed to send error replies to broadcasts, as routing packets (including RIP) generally are. They should be ignored unless addressed specifically to that host. This could indicate an SGI software bug or disagreement over the broadcast address or both. It might be possible to make the error messages disappear by setting the IRIS's broadcast address to whatever address the broadcasts are being sent to, if 3.5 allows that.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02834; 19 Mar 89 17:34 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa02685; 19 Mar 89 15:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02679; 19 Mar 89 15:35 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa09225; 19 Mar 89 15:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19599; Sun, 19 Mar 89 12:07:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Mar 89 18:55:09 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: Re: IRIS 4-D: inetd crashes if yp is on Message-Id: <354@hydra.gatech.EDU> References: <1226@nic.MR.NET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection > attempt, if we have yellow pages enabled. (Its YP server is then a Sun > running SunOS 3.5.) YP appears to work fine otherwise on things like passwd > and hosts lookups. Inetd runs as expected when we just disable YP. This is > tolerable but it'd be nice to have it. We had this problem a few weeks back and tracked it down to the fact that sgi's inetd expects a few specific entries in the /etc/services file. Since the /etc/services file is yp'ed and sun's default services file doesn't include the ones that sgi's inetd expects, inetd just gives up and dumps core. We fixed the problem by copying the entries for "bootpc", "chargen" (both of them), "ntalk" and "bootp" from sgi's /etc/services file to the services file on the sun yp server. Inetd hasn't complained since. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19829; 20 Mar 89 21:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19518; 20 Mar 89 20:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19508; 20 Mar 89 19:51 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa12588; 20 Mar 89 19:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA07584; Mon, 20 Mar 89 16:36:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Mar 89 16:22:58 GMT From: dave Organization: Graftel Systems Inc., Wilmington MA Subject: GNU Emacs 18.52 on the Personal IRIS? Message-Id: <281@graftel.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for the correct m-.h and s-.h configuration files for the Personal IRIS. The file m-iris4d.h and s-iris3-6.h referred to in m-iris4d.h do not seem to be correct. I would appreciate hearing from someone who has GNU Emacs working on the Personal IRIS. Thanks dave rounds   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04895; 20 Mar 89 4:28 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04563; 20 Mar 89 3:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04556; 20 Mar 89 3:11 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa16336; 20 Mar 89 3:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19065; Sun, 19 Mar 89 23:28:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Mar 89 06:20:11 GMT From: Robert Wier Organization: Northern Arizona University, Flagstaff, AZ Subject: active newsgroup Message-Id: <1221@naucse.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is this an active newsgroup? I've not seen anything turn up here under this heading, but then, we don't get a lot of stuff. I would appreciate anyone sending E-Mail direct to let me know if there is a mailing list or newsgroup to discuss sgi IRIS type things. For example... Is there a GIF to IRIS program available? We have a turbod model 2400 (does that make it 3xxx?). PS - we just demoed the Personal IRIS. Just the thing for my desktop! many thanks - - Bob Wier College of Engineering Flagstaff, Arizona Northern Arizona University ...arizona!naucse!rrw | BITNET: WIER@NAUVAX | *usual disclaimers*   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13947; 20 Mar 89 13:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12249; 20 Mar 89 11:17 EST Received: by VMB.BRL.MIL id aa12243; 20 Mar 89 11:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12038; 20 Mar 89 10:55 EST Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa24271; 20 Mar 89 10:23 EST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA12754; Mon, 20 Mar 89 10:21:44 EST Received: by buita.bu.edu (3.2/4.7) id AA13616; Mon, 20 Mar 89 10:22:27 EST Received: by adt.uucp (3.2/SMI-3.2) id AA18799; Mon, 20 Mar 89 10:03:24 EST Date: Mon, 20 Mar 89 10:03:24 EST From: Joe Ilacqua Message-Id: <8903201503.AA18799@adt.uucp> To: info-iris-request@vmb.brl.mil Cc: info-iris@BRL.MIL Subject: Re: IRIS 4-D: inetd crashes if yp is on <> /etc/inetd dumps core on our IRIS 4-D (4D1-3.147) at the first connection <> attempt, if we have yellow pages enabled. (Its YP server is then a Sun <> running SunOS 3.5.) YP appears to work fine otherwise on things like passwd <> and hosts lookups. Inetd runs as expected when we just disable YP. This is <> tolerable but it'd be nice to have it. < Organization: NASA Ames Research Center, Moffett Field, CA Subject: Where's the Goodies? Message-Id: <22917@ames.arc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello Folks, Our first Iris 4D just arrived (with more comming) and I just subscribed to this newsgroup. My question is: are there any archive sites for ftp-able public domain iris/sgi graphics programs, and other goodies? Thanks in advance, John S. Watson, Civil Servent from Hell ARPA: watson@ames.arc.nasa.gov NASA Ames Research Center UUCP: ...!ames!watson Any opinions expressed herein are, like, solely the responsibility of the, like, author and do not, like, represent the opinions of NASA or the U.S. Government.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27774; 21 Mar 89 11:08 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa26878; 21 Mar 89 10:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26819; 21 Mar 89 10:01 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa22143; 21 Mar 89 9:52 EST Received: Tue, 21 Mar 89 07:44:11 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 21 Mar 89 07:44:11 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903211544.AA02689@aero4.larc.nasa.gov> To: ames.arc.nasa.gov!watson@ames.arc.nasa.gov Subject: Re: Where's the Goodies? Cc: info-iris@BRL.MIL vgr.brl.mil has an anonymous ftp account. A few programs are stored there and an archive of all the info-iris mail messages. If you hear of any other places, please let me know. Thanks. You might also check around there at Ames, there are a lot of IRIS's there, I am sure someone there knows about some other places to look. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03538; 21 Mar 89 22:11 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03298; 21 Mar 89 20:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03254; 21 Mar 89 20:44 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08788; 21 Mar 89 20:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19110; Tue, 21 Mar 89 17:27:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Mar 89 22:47:10 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: KSH-I on sgi machines Message-Id: <358@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone managed to ksh-i running properly on an sgi machine? I tried it and the makefiles assumed (somewhat correctly) that it was being compiled on a System V machine. They happily churned along and produced a ksh that worked correctly but didn't have job control. The code has ALL Berkeley (not just the job control code) #ifdef'ed with "BSD". I'm about to dive into it to see if I can fake it into compiling a System V version with Berkeley job control and I thought I'd check to see if someone else might've already done the job for me. Hopefully I won't have this problem when we get ksh88. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05878; 22 Mar 89 7:50 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04930; 22 Mar 89 6:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04928; 22 Mar 89 6:09 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa13684; 22 Mar 89 6:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14605; Wed, 22 Mar 89 02:29:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Mar 89 06:47:54 GMT From: Rod Paul Organization: Datamerica Systems, NYC Subject: Re: gr_osview on a remote host Message-Id: <9073@dasys1.UUCP> References: <7133@phoenix.Princeton.EDU>, <28921@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <28921@sgi.SGI.COM> jmb@patton.SGI.COM (Jim Barton) writes: >In article <7133@phoenix.Princeton.EDU>, ijlustig@phoenix.Princeton.EDU (Irvin Lustig) writes: >> We are trying to use the -N option of gr_osview and get the message >> "Password incorrect." >> "Unable to invoke remote demon" >Due to a bug in the current gr_osview, going to any 'user' which has a >password in the password file will fail. Unfortunately, this causes a >security breach which may not be acceptable in some installations. I >haven't been able to devise a workaround. > >This bug will be fixed in the next release of IRIX, the 3.2 release due >mid-year. > >PS. This bug is totally my own fault, so flame me, but it's not really > necessary to trash SGI for not fixing bugs. Even the best of us > can't do everything perfect. > Jim, I suggest not trashing yourself on this one... I logged a call a couple of weeks ago to SGI (I assume the mid is still open), your program isn't the only one with this problem. Anyway I explained to the support guy, that not only is "gr_osview" unable to execute a remote daemon, but neither can "bru" if the password field is locked ("bru" also defaults to "guest"). Being the nosey parker that I am I ran "strings" (piped through my favourite, "less") on both "gr_osview" and "bru", both made some call to a bsd routine I don't recall the exact name right now, but I beleive it was "ruserpass.c" which makes reference to a ".netrc" file (I assume to be similar to ".rhosts"). Unfortunatly the support guy I talked to hadn't ever heard of a ".netrc" file either. If it's format can be found (I assume "ruserpass" looks for it), problem may be solved? I know life ain't that easy and if you wrote "bru" too I know that won't be the answer... Cheers, Rod. -- Rodian Paul Big Electric Cat Public UNIX ..!cmcl2!dasys1!rpaul   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06158; 22 Mar 89 8:06 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac05878; 22 Mar 89 7:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05868; 22 Mar 89 7:49 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa15349; 22 Mar 89 7:40 EST Received: Wed, 22 Mar 89 07:43:06 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 22 Mar 89 07:43:06 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903221543.AA07026@aero4.larc.nasa.gov> To: pyrnj!dasys1!rpaul@rutgers.edu Subject: Re: gr_osview on a remote host Cc: info-iris@BRL.MIL P.S. The .netrc file should be in the home directory of the local machine and should have read permission by the owner ONLY. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07025; 22 Mar 89 8:48 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab05878; 22 Mar 89 7:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05688; 22 Mar 89 7:48 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa15248; 22 Mar 89 7:38 EST Received: Wed, 22 Mar 89 07:39:46 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 22 Mar 89 07:39:46 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903221539.AA07011@aero4.larc.nasa.gov> To: pyrnj!dasys1!rpaul@rutgers.edu Subject: Re: gr_osview on a remote host Cc: info-iris@BRL.MIL The ".netrc" file is documented under ftp. Below is the documentation: THE .netrc FILE The .netrc file contains login and initialization informa- tion used by the auto-login process. It resides in the user's home directory. The following tokens are recognized; they may be separated by spaces, tabs, or new-lines: machine "name" Identify a remote machine name. The auto-login process searches the .netrc file for a machine token that matches the remote machine specified on the ftp command line or as an open command argument. Once a match is made, the subsequent .netrc tokens are processed, stop- ping when the end of file is reached or another machine token is encountered. login "name" Identify a user on the remote machine. If this token is present, the auto-login process will initiate a login using the specified name. password "string" Supply a password. If this token is present, the auto-login process will supply the specified string if the remote server requires a password as part of the login process. Note that if this token is present in the .netrc file, ftp will abort the auto-login process if the .netrc is readable by anyone besides the user. account "string" Supply an additional account password. If this token is present, the auto-login process will supply the specified string if the remote server requires an addi- tional account password, or the auto-login process will initiate an ACCT command if it does not. macdef "name" Define a macro. This token functions like the ftp mac- def command functions. A macro is defined with the specified name; its contents begin with the next .netrc line and continue until a null line (consecutive new- line characters) is encountered. If a macro named init is defined, it is automatically executed as the last step in the auto-login process. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18106; 22 Mar 89 18:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15762; 22 Mar 89 16:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15447; 22 Mar 89 16:07 EST Received: from [128.186.3.1] by SMOKE.BRL.MIL id aa03685; 22 Mar 89 15:52 EST Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA08557; Wed, 22 Mar 89 16:03:40 EST Date: Wed, 22 Mar 89 16:03:40 EST From: "John D. McCalpin" Message-Id: <8903222103.AA08557@masig1.ocean.fsu.edu> To: info-iris@BRL.MIL Subject: cache miss delays on 4D's Does anyone know what kind of cache miss delays are incurred on the various machines in the 4D line? I am specifically interested in the Personal IRIS and the 4D/60. On the LINPACK numbers that I posted earlier, the difference is clearly associated with the fact that a Personal IRIS has an 8 kB data cache and the 4D/60 has (at least) a 32 kB data cache. The equivalent MIPS machine (M-800) has a 64 kB data cache. The LINPACK code requires something not too far over 40 kB of data space, and the hit rate would be much better on the 4D/60. In order to estimate performance on my big codes, I can assume LOTS of cache misses, so the performance will be largely determined by how much latency is incurred on a data cache miss --- especially since SGI is not currently shipping the MIPS cache re-ordering part of the optimizer.... One more necessary item in the formula is how big a memory chunk is loaded on a cache miss. I think that this is called the cache line size. Does anyone know this value for the machines? I would guess it to be the same for all R-2000-based machines, but you can never tell.... -- ---------------------- John D. McCalpin ------------------------- Mesoscale Air-Sea Interaction Group & Department of Oceanography & Supercomputer Computations Research Institute - Fl State Univ. mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN) ------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18752; 22 Mar 89 21:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18550; 22 Mar 89 20:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18505; 22 Mar 89 19:59 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa06477; 22 Mar 89 17:52 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA17214; Wed, 22 Mar 89 13:18:55 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Mar 89 20:54:57 GMT From: Richard Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: 4Dgifts - Imagetools Message-Id: <271@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I really like the 4Dgifts - Imagetools by Paul Haeberli. Question: Is the image format created by "scrsave" some kind of standard format? I would like to distribute some images of the VERBATIM variety, RGB, 3 8-bit bytes per pixel, 24 bits total, and I would like to consider using the Imagetools format. Question: Will various other systems/software be able to read this format? /s/ Rich -- Richard Rosenthal Internet: richr@ai.etl.army.mil Engineer Topographic Labs UUCP: ...!ames!ai.etl.army.mil!richr Ft. Belvoir, VA 22060-5546 BITNET: richr%ai.etl.army.mil@CUNYVM +1 202 355 3653 CSNET: richr%ai.etl.army.mil@RELAY.CS.NET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18798; 22 Mar 89 21:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18550; 22 Mar 89 20:18 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab18505; 22 Mar 89 19:59 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa07098; 22 Mar 89 18:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA22331; Wed, 22 Mar 89 14:47:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Mar 89 22:06:44 GMT From: jato!emerald.jpl.nasa.gov!leo@elroy.jpl.nasa.gov Organization: Jet Propulsion Laboratory Subject: C++ needed for 3130 Message-Id: <961@jato.Jpl.Nasa.Gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Greetings. I need information on C++ for the 3130. Has anyone installed either ATT C++ or G++ on a 3130? Is there a place where I can get a ready-to-go installation of G++? Pleases send info to: Leo Blume leo@emerald.jpl.nasa.gov Many thanks in advance.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20114; 23 Mar 89 2:41 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19733; 23 Mar 89 1:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19657; 23 Mar 89 1:26 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10445; 23 Mar 89 1:15 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14358; Wed, 22 Mar 89 22:01:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Mar 89 03:43:10 GMT From: Len Lattanzi Organization: Synthesis Software Solutions Inc, Sunnyvale, CA Subject: Re: cache miss delays on 4D's Message-Id: <15779@mips.mips.COM> References: <8903222103.AA08557@masig1.ocean.fsu.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL One clarification on the Mips compiler cache-reorganizer. This only reorders procedures to fit better in the icache. -Len Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> Synthesis Software Solutions, Inc. 1 408 991 0367 292 Commercial Avenue, Sunnyvale, California 94086   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20234; 23 Mar 89 3:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20065; 23 Mar 89 2:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20059; 23 Mar 89 2:19 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa10762; 23 Mar 89 2:13 EST Received: from FINFUN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5058; Thu, 23 Mar 89 02:15:57 EST Date: Thu, 23 Mar 89 09:15 O From: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: tar To: info-iris@BRL.MIL X-Original-To: info-iris@brl.arpa Message-ID: <8903230213.aa10762@SMOKE.BRL.MIL> Please tell me what I'm doing wrong. I'm doing a backup with tar of my files on a 4D/70GTB. I don't want to waste good tape so I try to write the new files after the last one on the tape. Iris man pages do not mention anything about the "-r" key which should add the new files after the last file and tar is complaining with the message "tar:blocked tapes cannot be updated" if I try to use "-r". Ok, next try: I used "tar tf /dev/nrtape" to get to the last file on tape and then I tried with "tar cv files" to add the new files. The man pages are saying for "c": Create a new tape; writing starts at the beginning of the tape instead of after the last file. This option assumes that you are at the beginning of the tape. What happens if I'm not at the beginning? No success the tape is first rewinded and the files are written at the begining of the tanpe. To use just "tar v files" does not work either. What should I do to add new files after the last file on a cartridge tape? Leif Laaksonen Centre for Scientific Computing ESPOO FINLAND   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23818; 23 Mar 89 9:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23544; 23 Mar 89 9:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23327; 23 Mar 89 8:56 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa16184; 23 Mar 89 8:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA05065; Thu, 23 Mar 89 05:47:27 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Mar 89 13:20:52 GMT From: Chuck Musciano Organization: Advanced Technology Dept., Harris Corp., Melbourne, Fl. Subject: Re: 4Dgifts - Imagetools Message-Id: <1756@trantor.harris-atd.com> References: <271@ai.etl.army.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <271@ai.etl.army.mil> richr@ai.etl.army.mil. (Richard Rosenthal) writes: >I really like the 4Dgifts - Imagetools by Paul Haeberli. What is "Imagetools"? Where can I get a copy? Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-5510   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24907; 23 Mar 89 10:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23013; 23 Mar 89 8:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22532; 23 Mar 89 8:27 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa14825; 23 Mar 89 8:04 EST Received: Thu, 23 Mar 89 07:51:48 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Thu, 23 Mar 89 07:51:48 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903231551.AA02202@aero4.larc.nasa.gov> To: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu Subject: Re: tar Cc: info-iris@BRL.MIL If the 4D/70GTB is like the 3000's, you can't do what you're trying to do. Our documentation says that you can ONLY create an entire tape at one time, you CAN'T append to a tape that already has information on it. This is very annoying. Another annoyance is that archives can't be spread over multiple tapes. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27220; 23 Mar 89 11:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26069; 23 Mar 89 10:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25872; 23 Mar 89 10:36 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa19462; 23 Mar 89 10:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA09818; Thu, 23 Mar 89 07:28:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Mar 89 14:50:54 GMT From: Steven Anderson Organization: CSci Dept., University of Minnesota, Mpls. Subject: screenblank on 4D/70GT Message-Id: <11749@umn-cs.CS.UMN.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How do you get 'screenblank' to function while you are not logged in to a 4D/70GT? -Steve Anderson sanderso@umn-cs.cs.umn.edu umn-cs!sanderso   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27560; 23 Mar 89 12:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27220; 23 Mar 89 12:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27164; 23 Mar 89 11:57 EST Received: from RELAY.CS.NET by SMOKE.BRL.MIL id aa21780; 23 Mar 89 11:43 EST Received: from relay2.cs.net by RELAY.CS.NET id ad20465; 23 Mar 89 11:05 EST Received: from switzerland by RELAY.CS.NET id aj21789; 23 Mar 89 11:00 EST Received: from ean by scsult.SWITZERLAND.CSNET id a008188; 23 Mar 89 16:40 WET Date: 23 Mar 89 16:26 +0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET Message-ID: <36:doelz@urz.unibas.ch> Subject: backup problems (RE: tar) Return-Receipt-To: "Reinhard Doelz" Good Point ! The tar is a little bit tedious for backups. >Iris man pages do not mention anything about the "-r" key which >should add the new files after the last file and tar is complaining >with the message "tar:blocked tapes cannot be updated" if I try to use >"-r". Ok, next try: I used "tar tf /dev/nrtape" to get to the last file My man pages look like follows: TAR(1) Silicon Graphics TAR(1) For the r option to work on multi-partitions tape, one has to position the tape head to the last partition on the tape. This option does not work on cartridge tape. See mt(1) on how to append a new archive at the end of recorded data. I use BEER ( which is a shell in /usr/adm/beer) employing the bru for backups. BEER is kind of wasting tapes, but at least it guides you on your daily business and it can use multiple tapes. Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28555; 23 Mar 89 13:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26953; 23 Mar 89 11:37 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26930; 23 Mar 89 11:28 EST Received: from AC4.PICA.ARMY.MIL by SMOKE.BRL.MIL id aa20927; 23 Mar 89 11:15 EST Date: Thu, 23 Mar 89 11:08:59 EST From: Ken Van Camp To: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu cc: info-iris@BRL.MIL Subject: Re: tar Message-ID: <8903231108.aa14097@ARDEC-AC4.ARDEC.ARPA> > If the 4D/70GTB is like the 3000's, you can't do what you're trying >to do. Our documentation says that you can ONLY create an entire tape >at one time, you CAN'T append to a tape that already has information on >it. This is very annoying. Yes, it is true of the 4D's as well. >Another annoyance is that archives can't >be spread over multiple tapes. That's what SGI told me when we bought our original 3020's, but we tried it and it worked fine. I have restored several volumes of tapes this way with no ill effects. I have also tried this out on the 4D's with no problem. --Ken Van Camp ARPANET: kvancamp@PICA.ARMY.MIL -or- kvancamp@ARDEC.ARPA BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) USENET: pica.army.mil!kvancamp@UUNET.UU.NET   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28748; 23 Mar 89 13:17 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab28188; 23 Mar 89 12:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28087; 23 Mar 89 12:42 EST Received: from [129.99.20.2] by SMOKE.BRL.MIL id aa23192; 23 Mar 89 12:27 EST Received: Thu, 23 Mar 89 09:28:46 PST by orville.nas.nasa.gov (5.59/1.2) Date: Thu, 23 Mar 89 09:28:46 PST From: "David A. Tristram" Message-Id: <8903231728.AA25626@orville.nas.nasa.gov> To: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu, info-iris@BRL.MIL Subject: Re: tar Leif, After you read to the end of the tape, either with tar tf /dev/nrtape or with "mt fsf ", you might try 'writing' to the the no rewind tape device with "tar cvf /dev/nrtape files" or even "tar cvf - files | dd bs=250k of=/dev/nrtape" What we do for multi volume backups is make lists of the files we want to back up using find, and then use a utility we wrote called tarsz that estimates the size of the resulting tar archive. Then we split the list into separate lists, each with only enough files to fit on one tape. Dave   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28966; 23 Mar 89 13:36 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab28748; 23 Mar 89 13:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28566; 23 Mar 89 13:07 EST Received: from ZORAC.DCIEM.DND.CA by SMOKE.BRL.MIL id aa23568; 23 Mar 89 12:43 EST Received: by zorac.DCIEM.DND.CA (4.12/25-eef) id AA20208; Thu, 23 Mar 89 12:09:53 est Date: Thu, 23 Mar 89 12:09:53 est From: Tim Pointing Message-Id: <8903231709.AA20208@zorac.DCIEM.DND.CA> To: info-iris@BRL.MIL, slevy@uc.msc.umn.edu Subject: Re: IRIS 4-D: inetd crashes if yp is on I had similar problems with inetd using YP from another system (a Sun). I think the problem stems from inetd not finding one of the executables listed in "/usr/etc/inetd.conf" (the x-server line.) After I commented out that line (and the other couple of lines which weren't mentioned in the YP servers services but were in the inetd.conf file. We seem to be running just fine now. Tim Pointing, DCIEM tim@zorac.dciem.dnd.ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03030; 23 Mar 89 16:11 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00805; 23 Mar 89 14:57 EST Received: from sem.brl.mil by VMB.BRL.MIL id aa00793; 23 Mar 89 14:46 EST Date: Thu, 23 Mar 89 14:35:27 EST From: Mike Muuss To: Steven Anderson cc: info-iris@BRL.MIL Subject: Re: screenblank on 4D/70GT Message-ID: <8903231435.aa13038@SEM.BRL.MIL> Use the blanktime() call to set the blanking interval. Note that on some 4D machines, the parameter may not exceed 2^15, even though the parameter is supposed to be a LONG. eg: /* * Set an 8 minute screensaver blanking, which will light up * the screen again if it was dark, and will protect it otherwise. * The 4D has a hardware botch limiting the time to 2**15 frames. */ blanktime( (long) 32767L ); Best, -Mike   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14962; 24 Mar 89 17:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14900; 24 Mar 89 16:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14875; 24 Mar 89 16:43 EST Received: from megaron.arizona.edu by SMOKE.BRL.MIL id aa26507; 24 Mar 89 16:30 EST Received: by megaron.arizona.edu (5.59-1.7/15) id AA08366; Fri, 24 Mar 89 14:31:50 MST Received: by uazaic.SGI (5.52/5.6) id AA09447; Thu, 23 Mar 89 14:04:12 PST Date: Thu, 23 Mar 89 14:04:12 PST From: Dolata Message-Id: <8903232204.AA09447@uazaic.SGI> To: arizona!info-iris%brl.arpa@arizona.edu Subject: Split info-iris ?? Since I don't have, and do not plan to get in the near future, a 4D iris, I find 80% of info-iris pretty meaningless these days. What do people think of creating a new list, info-4D ???   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14998; 24 Mar 89 17:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14747; 24 Mar 89 16:15 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14740; 24 Mar 89 16:08 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26086; 24 Mar 89 16:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29642; Fri, 24 Mar 89 12:49:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 89 20:32:35 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Send me your cool NeWS/PostScript goodies Message-Id: <29361@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm interested in seeing what kinds of cool things people are doing with the NeWS/PostScript capability of 4Sight. If you have anything you'd like to share please email me details; code would be even better. I'm currently making pie menus work in 4Sight for all clients including GL clients. I have a couple of minor bugs to fix then I'll post all the stuff to this group. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14998; 24 Mar 89 17:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14747; 24 Mar 89 16:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab14740; 24 Mar 89 16:08 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26089; 24 Mar 89 16:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29607; Fri, 24 Mar 89 12:49:16 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 89 20:28:28 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: tar Message-Id: <29360@sgi.SGI.COM> References: <8903231551.AA02202@aero4.larc.nasa.gov>, <28925@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <28925@bu-cs.BU.EDU>, eap@bu-cs.BU.EDU (Eric Pearce) writes: > > Has anybody tried GNU tar on the SGI? (I can't try it myself at the > moment) It does multi-volume archives and incremental backups and > restores. I don't know if it would solve the tape positioning > problems you are having with the 1/4" drive. It's worth a try. > > (you can get it from prep.ai.mit.edu) > It won't help. The problem is the 1/4" controller and drive. I believe it's common to all 1/4 inch archive tapes. The man page for tar on SunOs release 4.0 says r ... Note: this option does not work with quarter-inch archive tapes. SGI's tar handles multi-volume tar files. Beer/Bru is good for backup. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15100; 24 Mar 89 17:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac14998; 24 Mar 89 17:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14996; 24 Mar 89 17:23 EST Received: from orville.nas.nasa.gov by SMOKE.BRL.MIL id aa27007; 24 Mar 89 17:15 EST Received: Fri, 24 Mar 89 14:17:09 PST by orville.nas.nasa.gov (5.59/1.2) Date: Fri, 24 Mar 89 14:17:09 PST From: "David A. Tristram" Message-Id: <8903242217.AA07544@orville.nas.nasa.gov> To: info-iris@BRL.MIL Subject: New Release of the Panel Library Cc: dat@orville.nas.nasa.gov Drum Roll Please... I am pleased to Announce that the new and improved, latest and greatest version of the Panel Library User Interface Toolkit for the Silicon Graphics Iris is pretty much ready, and will be sent upon request beginning in April. (no fooling!) The Panel Library provides sliders, buttons, and other mouse-sensitive Actuators whose values may be read and set from within your graphics program. The Actuators are on movable and resizable Mex windows called Panels. The applications programmer may designate Action Functions that are executed when the user clicks on particular actuators. The Library accepts user-defined actuators and provides other nice features like journaling mouse events to script files on disk, and dumping its configuration as compilable C code. Present users of the Panel Library know all that though, and are probably more interested in... New Features for this Release: A detailed Reference Manual, An improved beveled 3D look, Support for hierarchies of actuators, New actuators including menus, icons, frames, and scrolls, An interactive Control Panel Editor, ...And of course, numerous bug-fixes. The Panel Library is written in C, and makes extensive use of the Iris Graphics Library. The Panel Library is in the public domain, it may not be resold or relicensed. Modified and enhanced versions of this software are likewise to be made freely available. Sites using the Panel Library are requested to register with NASA. People with network access can get their copy of the Panel Library source code distribution by sending a request to the ARPANET address: dat@orville.nas.nasa.gov Others are to send a request on letterhead with a quarter-inch cartridge tape to: David A. Tristram ATTN:PANEL LIBRARY REQUEST MS 258-5 NASA Ames Research Center Moffett Field, CA 94035 In the case of grave difficulties, calls may be directed to 415-694-4404.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15281; 24 Mar 89 18:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15134; 24 Mar 89 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15121; 24 Mar 89 18:01 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa27250; 24 Mar 89 17:47 EST Received: Fri, 24 Mar 89 17:49:16 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 24 Mar 89 17:49:16 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903250149.AA07532@aero4.larc.nasa.gov> To: dolata%uazaic.UUCP@arizona.edu Subject: Re: Split info-iris ?? Cc: info-iris@BRL.MIL Bad idea. Some of the 4D stuff overlaps with the 3000's. I think one list is the best idea. Also 3000 stuff overlaps with 4D's. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04997; 27 Mar 89 12:19 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03858; 27 Mar 89 11:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03796; 27 Mar 89 10:52 EST Received: from vms3.macc.wisc.edu by SMOKE.BRL.MIL id aa26085; 27 Mar 89 10:37 EST Received: from VMSmail by vms3.macc.wisc.edu; Mon, 27 Mar 89 09:35 CST Message-Id: <19032709353671@vms3.macc.wisc.edu> Date: Mon, 27 Mar 89 09:35 CST From: SWIGGUM <@vms3.macc.wisc.edu:SWIGGUM@gustav.decnet> Subject: Re: Split info-iris ?? To: info-iris@BRL.MIL X-VMS-To: WIRCS3::IN%"info-iris@brl.arpa",SWIGGUM 80% does not apply to you? That's not so bad. Anyway, I think it is a great idea. Anyone interested in starting an info-1400 group? Silicon Graphics doesn't even put that category on its customer surveys! Douglas Swiggum University of Wisconsin--Madison   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13318; 28 Mar 89 2:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa12963; 28 Mar 89 0:36 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12946; 28 Mar 89 0:21 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10357; 28 Mar 89 0:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02972; Mon, 27 Mar 89 21:09:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Mar 89 15:28:48 GMT From: Robert Soosaar Organization: Engineering Computing Facility, University of Toronto Subject: Kyoto Common Lisp on SGI Message-Id: <818@mv06.ecf.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are porting Kyoto Common Lisp to our Silicon Graphics workstations (Personal Iris and 3000 series) and have come across a few problems. On the Iris 3130: We cannot get KCL to generate a saved state by dumping to a file. The root of this problem is likely in the unix_save.c routines. On the Personal Iris: A few of the functions are written with in-line assembly code. These functions (in earith.c and bitop.c) have to be converted into assembler code for the MIPS processor. If someone has already performed the modifications or even attempted some of these mods. I would appreciate hearing some feedback. Rob Soosaar University of Toronto Institute for Aerospace Studies (416)667-7701 soosaar@ecf.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26813; 28 Mar 89 16:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23946; 28 Mar 89 14:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23764; 28 Mar 89 14:32 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26947; 28 Mar 89 14:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA12740; Tue, 28 Mar 89 11:03:24 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Mar 89 17:42:28 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Disk Quotas Message-Id: <29504@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL While I was perusing comp.sources.unix, I came across an article containing code the purports to support disk quotas on System V type machines. Since several persons on the net have asked about similar support for 4D machines, I was wondering if any of them would be willing to port the thing and see if it actually does the job. We probably wouldn't do it internally right away, since nobody in house uses quotas, making effective testing somewhat problematical. If it can be verified to work, then we can release it as part of 4Dgifts or through the IRIS software exchange. The relevant article is for source v18i067 - diskquotas under system V. If you can't get it from there, I saved a copy. Send me mail and I'll send it to you. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab26813; 28 Mar 89 16:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23946; 28 Mar 89 14:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab23764; 28 Mar 89 14:32 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26963; 28 Mar 89 14:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA12711; Tue, 28 Mar 89 11:03:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Mar 89 17:35:46 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Kyoto Common Lisp on SGI Message-Id: <29503@sgi.SGI.COM> References: <818@mv06.ecf.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <818@mv06.ecf.toronto.edu>, soosaar@ecf.toronto.edu (Robert Soosaar) writes: > We are porting Kyoto Common Lisp to our Silicon Graphics > workstations (Personal Iris and 3000 series) and have come > across a few problems. ... > > On the Personal Iris: > A few of the functions are written with in-line assembly > code. These functions (in earith.c and bitop.c) have to > be converted into assembler code for the MIPS processor. > ... > Rob Soosaar Might I suggest you just write the same code in C, and let the MIPS optimizer turn it into fast assembly. I haven't hand coded assembly for a 4D for speed purposes for years. The last time I did, I spent hours getting at as fast as possible. Then I wrote the same function in C, compiled & optmized it, and found out that the generated code had one less instruction than I had. Why beat your brains out? -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29250; 28 Mar 89 18:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27123; 28 Mar 89 17:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27019; 28 Mar 89 16:52 EST Received: from SMITHKLINE.COM by SMOKE.BRL.MIL id aa00969; 28 Mar 89 16:27 EST Received: from PHVAX.DECnet MAIL11D_V3 by smithkline.com (5.57/Ultrix2.4-C) id AA10186; Tue, 28 Mar 89 16:06:12 EST Date: Tue, 28 Mar 89 16:06:11 EST Message-Id: <8903282106.AA10186@smithkline.com> From: dixons%phvax.dnet@smithkline.com To: "info-iris@brl.mil %PHINGW.dnet"@smithkline.com Subject: Re: Kyoto Common Lisp on SGI In article <818@mv06.ecf.toronto.edu>, soosaar@ecf.toronto.edu (Robert Soosaar) writes: > We are porting Kyoto Common Lisp to our Silicon Graphics > workstations (Personal Iris and 3000 series) and have come > across a few problems. ... > > On the Personal Iris: > A few of the functions are written with in-line assembly > code. These functions (in earith.c and bitop.c) have to > be converted into assembler code for the MIPS processor. > ... > Rob Soosaar And in reply, Jim Barton (jmb@sgi.sgi.com) writes > Might I suggest you just write the same code in C, and let the MIPS optimizer > turn it into fast assembly. I haven't hand coded assembly for a 4D for > speed purposes for years. The last time I did, I spent hours getting at as > fast as possible. Then I wrote the same function in C, compiled & optmized > it, and found out that the generated code had one less instruction than I > had. Why beat your brains out? The port of KCL to the Personal Iris has been done by Dennis Hultquist (hultquis@nas.nasa.gov). He has gotten it mostly working so send him a message. Most of the assemble code is trivial. The one that is a problem is earith.c, which is not done correctly for the 4D. The problem there is that one of the functions in earith is to divide a 64 bit number by a 32 bit number (actually I think it is a 62 bit number by 31 bits but same difference) to give a 32 bit answer and a remainder. There is no simple way to translate such an operation to C, although on many machines it is a single instruction. The other problem, at least for the 4D port is that there seems (at least from my perusal of the manual) to be no corresponding machine instruction for the MIPS chips. Hence, extended precision arithmetic on the 4D version doesn't work. If anyone has a good idea of how to do this, let me or Dennis Hultquist know. I am aware of how it is done in SCHEME but this is pretty complicated and I haven't taken the time to translate it (essentially a long division algorithm) to the special case needed for KCL. Scott Dixon dixons@smithkline.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29250; 28 Mar 89 18:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27123; 28 Mar 89 17:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27053; 28 Mar 89 16:53 EST Received: from [128.186.3.1] by SMOKE.BRL.MIL id aa01280; 28 Mar 89 16:36 EST Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA29596; Tue, 28 Mar 89 16:48:26 EST Date: Tue, 28 Mar 89 16:48:26 EST From: "John D. McCalpin" Message-Id: <8903282148.AA29596@masig1.ocean.fsu.edu> To: info-iris@BRL.MIL Subject: anonymous ftp Does the SGI 3000 series software support the traditional "anonymous" ftp account system? If so, what do I need to do to set up such a restricted ftp account? If not, does anyone have the software for the 3000 series to do this? Thanks, -- ---------------------- John D. McCalpin ------------------------- Mesoscale Air-Sea Interaction Group & Department of Oceanography & Supercomputer Computations Research Institute - Fl State Univ. mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN) ------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.brl.MIL id aa12313; 29 Mar 89 10:46 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa10365; 29 Mar 89 9:22 EST Date: Wed, 29 Mar 89 9:09:00 EST From: Gary S. Moss (VLD/VMB) To: Mark Callow cc: info-iris@BRL.MIL Subject: Re: Send me your cool NeWS/PostScript goodies Message-ID: <8903290909.aa10034@VMB.BRL.MIL> Mark, I'm just finishing up a screen lock program which is written using CPS. Basically, I used PostScript to open a blanket window over the screen which does not have Frame controls and displays an image in either Sun raster file format or IRIS RGB image file format like the ones under /usr/NeWS/smi. If you don't supply a file name, a default image is used. The PostScript source is converted to C with CPS and the C source portion opens up a small GL client window for inputing the user's password, and does the input and password checking. If anyone is interested, I will gladly mail them the sources; currently they total only about 550 lines. -moss   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14657; 29 Mar 89 13:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13649; 29 Mar 89 12:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa13632; 29 Mar 89 12:18 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16902; 29 Mar 89 11:58 EST Received: from FINFUN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6829; Wed, 29 Mar 89 11:58:33 EST Date: Wed, 29 Mar 89 19:41 O From: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: fortran (once again) To: info-iris@BRL.MIL X-Original-To: info-iris@brl.arpa Message-ID: <8903291158.aa16902@SMOKE.BRL.MIL> Please tell me what I'm doing wrong. I have a short file with some fortran subroutines but I'm totally unable to compile the file. The fortran compiler grabs more and more of memory and after a while the system tells: DANGER: Out of swap space and I lose the control of the system totally. The system I'm using is a 4D/70GTB and the fortran compiler is version 1.31. I can get the same effect by just compiling the following subroutine: I have tried with and without optimization but always the same problem. ----------------------cut here-------------------------------------- C C C PLOTTER OFF CALL ESC.) SUBROUTINE HPLOF C BEFORE OFF SEND A TERMINATING CHARACTER CALL HPOUT(char(125)//char(27)//'.)') RETURN END -----------------------cut here------------------------------------ I have tried to compile the code on a VAX and a SUN and there was no problem. Thanks in advance, Leif Laaksonen CSC ESPOO FINLAND   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17589; 29 Mar 89 16:59 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa16893; 29 Mar 89 15:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16866; 29 Mar 89 15:44 EST Received: from Anaconda.Stanford.EDU by SMOKE.BRL.MIL id aa22066; 29 Mar 89 15:17 EST Received: by anaconda.Stanford.EDU.stanford.edu (4.0/SMI-DDN) id AA01606; Wed, 29 Mar 89 10:58:28 PST Date: Wed, 29 Mar 89 10:58:28 PST From: Byung-Uk Lee Message-Id: <8903291858.AA01606@anaconda.Stanford.EDU.stanford.edu> To: info-iris@BRL.MIL Subject: 1/2" tape drive to a Personal Iris? I am new to this group, so I am not sure if this question was asked before. I am working on a medical project, and I need to read 1600 bpi 1/2" tape from a CT scanner. I have a Cipher tape drive which has Pertec interface. I know of a couple of vendors selling VME controller cards, but they did not have device driver software for Iris. Some of them have driver software for Unix, but I am not sure if the porting is feasible to an inexperienced guy. Does anyone has an experience in this kind of problem? I may have to buy a 1600bpi 1/2" tape drive system if the above attempt does not work. I'd like to have suggestions on the tape drive system. Thanks very much. Byung-Uk Lee bul@anaconda.stanford.edu (w)415-723-4310,415-723-2437   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01506; 30 Mar 89 7:02 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00929; 30 Mar 89 6:10 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa00926; 30 Mar 89 5:55 EST Received: from UCBVAX.Berkeley.EDU by ADM.BRL.MIL id aa00719; 30 Mar 89 1:53 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02013; Wed, 29 Mar 89 22:41:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Mar 89 01:44:32 GMT From: "Calvin H. Vu" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: fortran (once again) Message-Id: <29669@sgi.SGI.COM> References: <8903291158.aa16902@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903291158.aa16902@SMOKE.BRL.MIL>, LAAKSONE@FINFUN.BITNET writes: > > Please tell me what I'm doing wrong. I have a short file with some > fortran subroutines but I'm totally unable to compile the file. > The fortran compiler grabs more and more of memory and after a while > the system tells: DANGER: Out of swap space and I lose the control > of the system totally. The system I'm using is a 4D/70GTB and the > fortran compiler is version 1.31. > > I can get the same effect by just compiling the following subroutine: > > I have tried with and without optimization but always the same problem. > ----------------------cut here-------------------------------------- > C > C > C PLOTTER OFF CALL ESC.) > SUBROUTINE HPLOF > C BEFORE OFF SEND A TERMINATING CHARACTER > CALL HPOUT(char(125)//char(27)//'.)') > RETURN > END > > -----------------------cut here------------------------------------ > I have tried to compile the code on a VAX and a SUN and there was no > problem. > > Thanks in advance, > > Leif Laaksonen > CSC ESPOO FINLAND I tried your test case with the 3.1 Rev C release which is the oldest 1.31 compiler I can lay my hands on but could not reproduce the problem. It compiles successfully with all different versions of the fortran compiler I currently have so I'm not sure what the problem is/was. I suggest the followings: - check the version of the fortran compiler you have by typing 'versions ftn'. [Rev C release should have 41 as the last two digits in the Version column.] - if your alpha number is less than 41 you can get Rev C from your local SGI office. You might be able to get Rev D too. - if your alpha number is 41 or greater you might have problems with the distribution tape. It sounds far-fetched but it's the only thing I can think of. You can try to get a replacement tape from the SGI office if that's the case. I tend to believe this is what happened though since this is the first time we have ever heard of this problem. It would have caused an uproar if this actually happened to everybody :-). Calvin Vu Silicon Graphics Computer Systems   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07657; 30 Mar 89 11:51 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05207; 30 Mar 89 10:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05126; 30 Mar 89 10:46 EST Received: from ALEXANDRIA-EMH2.ARMY.MIL by SMOKE.BRL.MIL id aa07919; 30 Mar 89 10:29 EST Date: 30 Mar 89 10:20:00 EST From: "ARTIC::GERRITS" Subject: SGI 3030 with video To: info-iris Message-ID: <8903301029.aa07919@SMOKE.BRL.MIL> I have a laser disc player PIONEER 60010A and would like to use it with the Silicon Graphics 3030 for our training purposes. For all you GURUs, I need help. (i.e documentation, sample software, etc .......) thank you Jonus   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08120; 30 Mar 89 12:22 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab05207; 30 Mar 89 10:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05140; 30 Mar 89 10:47 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa07956; 30 Mar 89 10:31 EST Received: from FINFUN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 9137; Thu, 30 Mar 89 10:31:19 EST Date: Thu, 30 Mar 89 18:20 O From: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: fortran again To: info-iris@BRL.MIL X-Original-To: info-iris@brl.arpa Message-ID: <8903301031.aa07956@SMOKE.BRL.MIL> Thanks to all of you who have responded to my query about my fortran problem. The problem has not been solved but it has been pointed out to me that the problem do not occur in version 41 of fortran. I'm sorry that I did not look what my version is until now. My versions are ftn 900839 , ftn.sw 1000839 and ftn.man 1100839 and they are dated 88/12/7. We have apart from a two processor POWER IRIS which is just to be installed 3 personal IRIS workstations and one 4D/70GTB at the biotechnical lab. I just had to see if my fortran program works on the personal IRIS. The same problem occured and the system had to be rebooted. The versions of the fortran compiler were the same as on the 4D/70GTB but they were dated 88/12/12. I had some mails from sgi saying that the fortran compiler should be at least version 41 or higher. So my next question is that why do sgi ship new personal IRIS workstations with that old (ver 39) fortran compilers? The personal IRIS workstations came just a couple of days ago. An my fortran (on the 4D/70GTB) is not older than about 3 months. It looks as if people at sgi are not able to lay their hands on that old compiler versions as sgi is still shiping. -leif laaksonen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10922; 30 Mar 89 14:57 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09245; 30 Mar 89 14:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09243; 30 Mar 89 13:56 EST Received: from ALEXANDRIA-EMH2.ARMY.MIL by SMOKE.BRL.MIL id aa13432; 30 Mar 89 13:34 EST Date: 30 Mar 89 13:17:00 EST From: "ARTIC::GERRITS" Subject: need help with the SGI 3030 and a Laser Video Disc-player. To: info-iris Message-ID: <8903301334.aa13432@SMOKE.BRL.MIL> Can anyone help me with (1) Sample programs (2) Documentation. I would very much appreciate your help. jonus   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12547; 30 Mar 89 16:14 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab12350; 30 Mar 89 16:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12323; 30 Mar 89 15:55 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa17137; 30 Mar 89 15:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA10197; Thu, 30 Mar 89 11:54:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Mar 89 19:05:09 GMT From: Roy Smith Organization: Public Health Research Institute, NYC, NY Subject: Looking for iris-ansi termcap/terminfo entry Message-Id: <3731@phri.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for both a termcap and terminfo entries for "iris-ansi", i.e. the "wsh" terminal emulator. Does anybody have one they can send me? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14526; 30 Mar 89 21:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14452; 30 Mar 89 21:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14445; 30 Mar 89 20:57 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21325; 30 Mar 89 20:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA27763; Thu, 30 Mar 89 17:16:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 00:58:02 GMT From: Eric Pearce Organization: BD&HR (Beer Drinkers & Hell Raisers) Subject: Re: Looking for iris-ansi termcap/terminfo entry Message-Id: <29112@bu-cs.BU.EDU> References: <3731@phri.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL You should be able to produce them by using "infocmp". If not, write me, and I will mail you the one I have. -- ------------------------------------------------------------------------------- Eric Pearce ARPANET eap@bu-it.bu.edu Boston University Information Technology CSNET eap%bu-it@bu-cs 111 Cummington Street JNET jnet%"ep@buenga" Boston MA 02215 UUCP !harvard!bu-cs!bu-it!eap 617-353-2780 voice 617-353-6260 fax BITNET ep@buenga   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15735; 31 Mar 89 0:48 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15695; 31 Mar 89 0:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15676; 31 Mar 89 0:23 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa22780; 31 Mar 89 0:00 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA08367; Thu, 30 Mar 89 20:48:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 03:05:38 GMT From: Thomas Palmer Organization: NCI Supercomputer Center, Frederick, MD Subject: Benchmark comparison of DEC 3100 and 4D/70GT Message-Id: <771@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We received a DEC 3100 demo unit today and I've run some benchmarks comparing it to our 4D/70GT. The results are somewhat perplexing. On a floating point test (just raw +,-,*,divide) the 3100 performs at about 2.2 mflops; the 4D/70GT at only 1.02 mflops. With a Dhrystone the 3100 produced 24590 dhrystones/sec; the 4D/70GT only 10204. Our Cray only churns out 14705 dhrystones/sec! What gives here? They have the same chip set (R2000 plus R2010 fpa, right?) The compilers are the same. Are the clock speeds the same? Is DEC using more cache? Any ideas? -Tom Thomas C. Palmer National Cancer Institute Supercomputer Facility c/o PRI, Inc. Phone: (301) 698-5797 PO Box B, Bldg. 430 Uucp: ...!uunet!ncifcrf.gov!palmer Frederick, MD 21701 Arpanet: palmer@ncifcrf.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17422; 31 Mar 89 7:07 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa16959; 31 Mar 89 6:26 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16941; 31 Mar 89 6:13 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa01313; 31 Mar 89 5:56 EST Received: from FINFUN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4336; Fri, 31 Mar 89 05:56:46 EST Date: Fri, 31 Mar 89 13:55 O From: LAAKSONE%FINFUN.BITNET@cunyvm.cuny.edu MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: fortran revisited To: info-iris@BRL.MIL X-Original-To: info-iris@brl.arpa Message-ID: <8903310556.aa01313@SMOKE.BRL.MIL> I'm sorry I must apologize for claiming that sgi has sent us the old version (39) of fortran with some new equipment to Finland. That is not the case. I don't want to go into details how and why the old fortran (version 39) was installed. The problem with compiling the piece of fortran code on version still exist. But I guess that the problem is not too interesting any more because I can get the version 41 which do not have the compiling problem. My question is who if any should inform me/us that there is a new version of a compiler? Nobody had told me that I was lagging behind in compiler versions. Here is no sgi office in Finland. -leif laaksonen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20439; 31 Mar 89 9:28 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19933; 31 Mar 89 9:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19874; 31 Mar 89 9:06 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa04316; 31 Mar 89 8:50 EST Received: Fri, 31 Mar 89 08:50:08 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 31 Mar 89 08:50:08 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8903311650.AA03992@aero4.larc.nasa.gov> To: mailrus!uflorida!haven!ncifcrf!palmer@rutgers.edu Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Cc: info-iris@BRL.MIL I am not familiar with the Dhrystone test, but if it has a lot of integer math, that will slow it down on the Cray. On the Cray's real math is faster than integer math. Don't ask me why, it is a known fact. The Cray's are optimized for real math and they don't care about integers. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25024; 31 Mar 89 13:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa23634; 31 Mar 89 12:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23603; 31 Mar 89 12:25 EST Received: from SGI.COM by SMOKE.BRL.MIL id aa10197; 31 Mar 89 11:57 EST Received: from baskett.sgi.com by sgi.sgi.com (5.52/880418.SGI) (for info-iris@brl.arpa) id AA11074; Fri, 31 Mar 89 08:57:45 PST Received: by baskett.sgi.com (5.52/880418.SGI) (for @sgi.SGI.COM:info-iris@brl.arpa) id AA29184; Fri, 31 Mar 89 08:57:40 PST Message-Id: <8903311657.AA29184@baskett.sgi.com> To: decwrl!rutgers.edu!mailrus!uflorida!haven!ncifcrf!palmer@BRL.MIL Cc: info-iris@BRL.MIL Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT In-Reply-To: Your message of 31 Mar 89 03:05:38 GMT. <771@fcs280s.ncifcrf.gov> Date: 31 Mar 89 08:57:39 PST (Fri) From: baskett@sgi.com Your numbers don't make sense in that they are so far apart that you must have an apples and oranges problem somewhere, perhaps in the levels of optimization. Nevertheless, the machines are not the same in several important ways. A 4D/70 is a 12.5 Mhz R2000 chip set while a 3100 is 16 MHz. A 70 has a 32KB data cache and a 3100 has a 64KB data cache. The instruction caches are the same. Finally, the memory systems are completely different. Cache miss penalties are likely to be different. Reads and writes are handled differently, the write buffers are different, etc. These differences will matter to some applications an not to others. Linpack and dhrystone are only starting points. Remember how different various 68000 based workstations are. Expect the same on MIPS based workstations. Forest   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27037; 31 Mar 89 15:46 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa25680; 31 Mar 89 14:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25655; 31 Mar 89 14:21 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa14418; 31 Mar 89 14:03 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA18104; Fri, 31 Mar 89 10:59:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 18:27:46 GMT From: Jim Helman Organization: Stanford University Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Message-Id: References: <771@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > With a Dhrystone > the 3100 produced 24590 dhrystones/sec; the 4D/70GT only 10204. The copy of dhrystone.c that I have defines the clock tick rate, HZ, to be 60. On the 4D machines this should be 100 (see /usr/include/sys/param.h). Using -O3 optimization, our 4D80 (16.7MHz MIPS) clocks in at 29250 dhrystones/sec. However, the whole question is somewhat moot, since the dhrystone is a pretty worthless benchmark. So now ya know. -jim   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28851; 31 Mar 89 19:22 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab28764; 31 Mar 89 19:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28736; 31 Mar 89 19:02 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21511; 31 Mar 89 18:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA01532; Fri, 31 Mar 89 15:17:46 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 22:26:53 GMT From: Mark Callow Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Message-Id: <29850@sgi.SGI.COM> References: <771@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <771@fcs280s.ncifcrf.gov>, palmer@ncifcrf.gov (Thomas Palmer) writes: > > What gives here? They have the same chip set (R2000 plus R2010 fpa, > right?) The compilers are the same. Are the clock speeds the same? > Is DEC using more cache? Any ideas? The clock speeds are different. -- -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29034; 31 Mar 89 20:00 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab28936; 31 Mar 89 19:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28934; 31 Mar 89 19:43 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa21673; 31 Mar 89 19:32 EST Received: Fri, 31 Mar 89 19:31:53 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 31 Mar 89 19:31:53 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904010331.AA06270@aero4.larc.nasa.gov> To: chiba!khb@sun.com Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Cc: info-iris@BRL.MIL I agree, the only reliable way to bench mark machines is to take real programs and run them on different machines. I bet if someone changed the Dhrystone test so that it used ALL reals instead of integers, it would run faster on the CRAY, than the integer version on the CRAY. Could someone send me a copy of the Dhrystone test, if it isn't too big? Thanks -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29182; 31 Mar 89 20:11 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28936; 31 Mar 89 19:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28932; 31 Mar 89 19:42 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21671; 31 Mar 89 19:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02952; Fri, 31 Mar 89 15:48:20 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 22:33:00 GMT From: Tom Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: AT&T C++ Message-Id: <11636@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anybody ported AT&T C++ to the 4D series? I have been trying for two days, but it barfs whenever munch is executed. Any pointers? Thomas Russo Center for Nonlinear Dynamics University of Texas at Austin -----------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29283; 31 Mar 89 20:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28764; 31 Mar 89 19:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa28723; 31 Mar 89 19:01 EST Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa21500; 31 Mar 89 18:40 EST Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29717; Fri, 31 Mar 89 14:44:19 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 89 22:16:29 GMT From: chiba Organization: Sun Microsystems, Mountain View Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Message-Id: <97051@sun.Eng.Sun.COM> References: <8903311650.AA03992@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8903311650.AA03992@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) writes: > > I am not familiar with the Dhrystone test, but if it has a >lot of integer math, that will slow it down on the Cray. On the >Cray's real math is faster than integer math. Don't ask me why, >it is a known fact. The Cray's are optimized for real math and >they don't care about integers. >-- Dhrystone is _purely_ an integer test. It is basically worthless for predicting performance of real code, but since a wide variety of periodicals (Byte, et al) and netfolk insist on running it, and publishing the results manufacter's of small computers do pay attention (some more so than others, note the flap in comp.arch re: intel 860 performance :>). Cray customers benchmark the machines the old fashion way....they take their real codes to cray (or reasonable subsets thereof) and have them run them. (so, btw does Sun). This is the only way to really judge a computer, have those who know how to tickle the beastie run your real codes and faithfully report what happened, and how. Those who have small budgets rely on the press/net to give them the best info they can .... and thus Dhrystones lives on...and on.... Cray's actually have a good balance between integer and FP....for the class of applications for which the machine was designed (i.e. numerical math...so integers are for do-loop indicies and address computation only). If your application is different (say symbolic computation or certain types of circuit simulation) you may find that a very different machine is what the doctor ordered. Well enough pontificating for now. I return you to your regularly scheduled sgitalk :> Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23145; 3 Apr 89 18:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22915; 3 Apr 89 18:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22907; 3 Apr 89 17:52 EDT Received: from ucsd.edu by SMOKE.BRL.MIL id aa01220; 3 Apr 89 17:24 EDT Received: from inls1.ucsd.edu by ucsd.edu; id AA06394 sendmail 5.60/UCSD-1.0 Mon, 3 Apr 89 13:12:42 PDT Received: by inls1.UCSD.EDU (4.0/UCSDGENERIC.2) id AA03540 to info-iris@brl.arpa; Mon, 3 Apr 89 13:12:44 PDT Date: Mon, 3 Apr 89 13:12:44 PDT From: Margaret Mikulska Message-Id: <8904032012.AA03540@inls1.UCSD.EDU> To: blbates@aero4.larc.nasa.gov Subject: Re: Benchmark (Dhrystone & Whetstone) Cc: info-iris-request@vmb.brl.mil, info-iris@BRL.MIL From info-iris-request@vmb.brl.mil Fri Mar 31 18:26:23 1989 To: chiba!khb@sun.com Subject: Re: Benchmark comparison of DEC 3100 and 4D/70GT Cc: info-iris@BRL.MIL > I bet if someone changed the Dhrystone test so that it used ALL >reals instead of integers, ... Dhrystone was designed specifically to test integers. For testings reals/floats, Whetstone is the thing to use. I may have a copy of both somewhere. Margaret Mikulska Univ. of Calif. San Diego Dept. of Computer Science & Engineering mmikulska@ucsd.edu MMIKULSKA@UCSD ucsd!beowulf!mikulska   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23194; 3 Apr 89 18:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22338; 3 Apr 89 16:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22241; 3 Apr 89 16:35 EDT Received: from [128.186.3.1] by SMOKE.BRL.MIL id aa29747; 3 Apr 89 16:02 EDT Received: by masig1.ocean.fsu.edu (5.52/25-eef) id AA02408; Mon, 3 Apr 89 12:17:45 EST Date: Mon, 3 Apr 89 12:17:45 EST From: Alan Davis Message-Id: <8904031717.AA02408@masig1.ocean.fsu.edu> To: info-iris@BRL.MIL Subject: EDT settings on 3xxx series To other 3xxx owners or someone at SGI, is there a way to make the system recognize that daylight savings time now starts in the beginning of April rather than at the end of the month. We have the included the EDT field to TZ, but the system doesn't recognize it till the old date. I noticed that this has been fixed on the Personal Iris. What about us oldtimers? -- Alan Davis | Mesoscale Air-Sea Interaction Group | TCP/IP davis@masig1.ocean.fsu.edu Florida State University | (128.186.3.1) 435 OSB Meteorology Annex | SPAN scri::"davis@masig1.ocean.fsu.edu" Tallahassee, FL 32306-3041 | BITNET davis%masig1.ocean.fsu.edu@cunyvm (904) 644-3798 | _______________________________________________________________________________   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28798; 4 Apr 89 9:28 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa26935; 4 Apr 89 8:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa26909; 4 Apr 89 7:54 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08646; 4 Apr 89 7:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA11229; Tue, 4 Apr 89 04:08:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Apr 89 21:29:43 GMT From: rob ogden Organization: Univ. of Cincinnati, College of Engg. Subject: help w/personal iris selection Message-Id: <833@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL April 3, 1989 Hello sgi group: We are considering a personal iris. The quote we have has the following items: Software Development Pkg. $510. Laser Printer Support $1000. Documentor's workbench $300. How useful are these items? We will use this machine w/FORTRAN and Abaqus finite element software. We will have a postscript printer, Apple Laserwriter NT. What do these three items do for us? Can we save $1810. by skipping these? Please, email me your reply. Thank you, Rob Ogden rogden@uceng.uc.edu uccba!uceng!rogden   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00263; 4 Apr 89 10:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa28239; 4 Apr 89 9:17 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28143; 4 Apr 89 9:00 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10324; 4 Apr 89 8:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA13903; Tue, 4 Apr 89 05:14:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Apr 89 22:00:56 GMT From: Trevor Paquette Subject: Float to sign/exp/mantissa Message-Id: <1026@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am sure that someone out there has a routine that given a floating point number, what is the sign, exponent and mantissa of the number.. I'd rather not re-invent the wheel if this has already been done. If some kind soul out there has such a function, and is willing to send it my way, I'd be very grateful. aTdHvAaNnKcSe Trev ============================================================================== Trevor Paquette/GraphicsLand, Calgary, Alberta ..uunet!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W calgary!paquette@cs.ubc.ca Luminous beings we are, not this crude matter   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29183; 4 Apr 89 9:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28798; 4 Apr 89 9:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28693; 4 Apr 89 9:24 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa11863; 4 Apr 89 9:07 EDT Received: Tue, 4 Apr 89 09:07:46 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 4 Apr 89 09:07:46 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904041707.AA02529@aero4.larc.nasa.gov> To: davis@masig1.ocean.fsu.edu Subject: Re: EDT settings on 3xxx series Cc: info-iris@BRL.MIL I have been told that the daylight savings time code is hardwired into the kernal (real stupid place to put it). The question of getting this changed is asked every time we toggle between standard and savings time. So far I haven't heard of a solution yet. They should get this information from a file that can be easily changed, like the holidays file or something similar. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29183; 4 Apr 89 9:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac28798; 4 Apr 89 9:36 EDT Date: Tue, 4 Apr 89 9:25:57 EDT From: Gary S. Moss (VLD/VMB) To: info-iris@BRL.MIL Subject: 'cc' bug found, also ScreenLock update Message-ID: <8904040925.aa28280@VMB.BRL.MIL> FYI, The 'C' compiler distributed with IRIX 3.1 (Mips Computer Systems Release 1.31) has a horrible bug; returning from 'main' with 'return' always returns 0 exit status. I have no reason to think that this is unique to 3.1, Doug Gwyn says that this brain damage was probably inherited from Sun. main() { return 1; } /* results in exit status 0 */ Using 'exit' works correctly, but calling 'exit' from main goes against my principles. Does anyone know where to send software bug reports? Should I call the hotline? I have an update of ScreenLock that returns the proper error status when failing to startup (i.e. no NeWS server running). I discovered this by doing 'make test' from a Sun window without 4Sight running on the IRIS and it succeeded. Also, I have added a slight modification to support the lame cursors on the Personal IRIS (thanks to Jim Sims for trying things on his P.I.). Anyone wanting an update, please send another request. -moss   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29630; 4 Apr 89 10:06 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac29183; 4 Apr 89 9:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29132; 4 Apr 89 9:43 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa12054; 4 Apr 89 9:15 EDT Received: Tue, 4 Apr 89 09:14:39 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 4 Apr 89 09:14:39 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904041714.AA02549@aero4.larc.nasa.gov> To: info-iris@BRL.MIL Subject: Dhrystone benchmark Thanks to everyone's help. Now I know that the Dhrystone is a test of integer speed and I now have a zillion copies of it. Some system keeps sending out duplicate copies of everything. Even though the Dhrystone IS a test of integer speed, I still think it would be interesting to see the results on a Cray with the integers changed to reals. Just for the sake of curiosity. Thank again. -- Brent   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00620; 4 Apr 89 10:58 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00263; 4 Apr 89 10:48 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00162; 4 Apr 89 10:29 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa13191; 4 Apr 89 9:59 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA17543; Tue, 4 Apr 89 06:37: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: 4 Apr 89 13:16:19 GMT From: John Buchanan Organization: University of Toronto, CSRI Subject: Keyboard repeat speed. Message-Id: <8904041316.AA11427@explorer.dgp.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am sure that there is a way to change the speed of the key repeat on a Personal Iris. What I do not know is exactly how to do it. Any help is thankfully requested.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08408; 4 Apr 89 16:54 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa08193; 4 Apr 89 16:43 EDT Received: from tbd.brl.mil by VMB.BRL.MIL id aa08151; 4 Apr 89 16:31 EDT Date: Tue, 4 Apr 89 16:19:35 EDT From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.MIL Subject: Re: setting DST in IRIS 3xxx Organization: U.S. Army Ballistic Research Laboratory, APG, MD Message-ID: <8904041619.aa21339@TBD.BRL.MIL> The simplest way to take care of Daylight time on IRIS3k machines seems to be manually change the contents of /etc/TZ to read EDT4EDT At your leisure during the summer, change it back to EST5EDT ...Glenn R-P   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08997; 4 Apr 89 17:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08746; 4 Apr 89 17:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08646; 4 Apr 89 17:06 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa25917; 4 Apr 89 16:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA06958; Tue, 4 Apr 89 13:02: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: 4 Apr 89 18:01:51 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: EDT settings on 3xxx series Message-Id: <29974@sgi.SGI.COM> References: <8904041707.AA02529@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The timezone is not wired into any IRIS kernel. It may be in some others, but all IRIS's all run flavors of System V. (Forget the V-kernel, and the old 4.2 experiments you may have heard of.) Remember that in SV, ctime(3) uses the TZ environment variable (or TIMEZONE in SVR3) to know how to convert from the GMT maintained in the kernel to whatever you want to see. To fix time on an IRIS 3000 running 3.6, you can: 1) change the date on your machine. You will confuse your uucp and sendmail neighbors, but if you are not running timed(1m), nntp, timeslave(1m) et al, this is probably simplest. You will have to ignore the '[ECMP]ST' in date strings. You will also have to change the date again in a few weeks. If you use NFS and make(1) for software development, simply changing the date will cause some little confusion, unless all machine change it similarly. To everyone inside SGI: DO NOT DO THIS, USE #2, #3, or #4 BELOW! 2) save and edit /etc/TZ, and reboot. For example, the string 'PDT7' solves the symptom on the west coast. You will need to remember to restore the old contents of /etc/TZ after May 1, and before fall. You must reboot to get everything using the new envirnment variable. 3) don't worry, be happy, and use a real clock for the rest of the month. This is probably the best "solution." 4) get rid of this "day light savings" silliness, and use UTC/GMT. You will be able to babble 'zulu' and other impressive things. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac08997; 4 Apr 89 17:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab08746; 4 Apr 89 17:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab08646; 4 Apr 89 17:07 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa25954; 4 Apr 89 16:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA06981; Tue, 4 Apr 89 13:02: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: 4 Apr 89 18:24:17 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: help w/personal iris selection Message-Id: <29978@sgi.SGI.COM> References: <833@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <833@uceng.UC.EDU>, rogden@uceng.UC.EDU (rob ogden) writes: > > April 3, 1989 > > Hello sgi group: > > We are considering a personal iris. The quote we have has > the following items: > Software Development Pkg. $510. > Laser Printer Support $1000. > Documentor's workbench $300. > > How useful are these items? We will use this machine w/FORTRAN and > Abaqus finite element software. We will have a postscript printer, > Apple Laserwriter NT. > > Please, email me your reply. > > Thank you, Rob Ogden > > rogden@uceng.uc.edu > uccba!uceng!rogden The Software Development Pkg contains the following things: C compiler front-end Common compiler back-end tools (optimizers, code-generators, linkers) Standard system header and libraries Basic language tools (library archiver, symbol table dumpers, etc.) "prof" and "pixie" code profilers "dbx" debugger "edge" - a multiwindowed graphical interface to dbx The FORTRAN option requires the Software Development Package to provide headers, libraries, and tools which are common to the SGI compilers. The only things provided in the FORTRAN option are the: FORTRAN compiler front-end FORTRAN specific headers and libraries FORTRAN specific tools The profilers, debuggers and other system tools work with C, FORTRAN, Pascal, and PL/1 and so are sold only in the Software Development Package. The Ada compiler uses some but not all of the Software Developement Tools. For examble, Ada has it's own debugger instead of using dbx/edge but the profiling tools prof and pixie work with Ada. The Laser Printer Support Package contains all of the tools and drivers to support printing on your system using a an Apple LaserWriter NT. And so you need it. The Documentor's WorkBench contains the tools for document preparation using nroff/ditroff (psroff). You'll have to make the decision whether or not you need this capability. -- Dave (commonplace) "Boldly going where no one cares to go." Ciemiewicz (incomprehensible) ciemo (infamous)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09240; 4 Apr 89 17:57 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08997; 4 Apr 89 17:46 EDT Received: by VMB.BRL.MIL id aa08803; 4 Apr 89 17:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08498; 4 Apr 89 17:01 EDT Received: from [128.16.6.4] by SMOKE.BRL.MIL id aa12418; 4 Apr 89 9:30 EDT Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa02354; 4 Apr 89 13:20 GMT To: info-iris@BRL.MIL Subject: gnu c++ running in IRIS 4D? Date: Tue, 04 Apr 89 14:16:37 +0100 From: Sam Richards Source-Info: purple.cs.ucl.ac.uk Message-ID: <8904040930.aa12418@SMOKE.BRL.MIL> Has anybody managed to get the gnu c++ compiler working on the SGI 4D? Thanks ... Sam Richards. sam@uk.ac.ucl.cs   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09957; 4 Apr 89 19:28 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09890; 4 Apr 89 19:17 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09776; 4 Apr 89 19:06 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27853; 4 Apr 89 18:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14032; Tue, 4 Apr 89 15:12: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: 4 Apr 89 21:34:07 GMT From: "David B. Anderson" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 'cc' bug found, also ScreenLock update Message-Id: <30006@sgi.SGI.COM> References: <8904040925.aa28280@VMB.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >>main() { return 1; } /* results in exit status 0 */ This is a known bug. We inherited it from MIPS. It has been fixed in the 3.2 release (I did it myself). Regards, [ David B. Anderson Silicon Graphics (415) 964-1459 x3060 ] [ USENET: {decwrl!,hplabs!sun!}sgi!davea Internet: davea@sgi.com ] ``Well then,'' the Cat went on, ``you see a dog growls when it's angry, and wags its tail when it's pleased. Now *I* growl when I'm pleased and wag my tail when I'm angry. Therefore I'm mad.'' - Alice in Wonderland -   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09957; 4 Apr 89 19:28 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab09890; 4 Apr 89 19:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09822; 4 Apr 89 19:07 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa27894; 4 Apr 89 18:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14366; Tue, 4 Apr 89 15:17: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: 4 Apr 89 17:09:13 GMT From: Andrew Koenig Organization: AT&T Bell Laboratories, Liberty Corner NJ Subject: Re: Float to sign/exp/mantissa Message-Id: <9151@alice.UUCP> References: <1026@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1026@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > I am sure that someone out there has a routine that given > a floating point number, what is the sign, exponent and mantissa > of the number.. The widely available frexp() library function gives you most of what you want. After executing the following: double x; double frexp(); double mant; int exp; x = /* some value */; mant = frexp(x, &exp); you are guaranteed that x is equal to mant * 2^^exp (here, ^^ means exponentiation), that 0.5 <= |mant| < 1, and that the sign of mant is the same as the sign of x, except that if x is 0, mant and exp will be 0 too. That should make it easy for you to get what you want. -- --Andrew Koenig ark@europa.att.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10904; 4 Apr 89 21:37 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10804; 4 Apr 89 21:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10792; 4 Apr 89 20:58 EDT Received: from ew09.nas.nasa.gov by SMOKE.BRL.MIL id aa28980; 4 Apr 89 20:42 EDT Received: by ew09 (5.61/1.34) id AA14172; Tue, 4 Apr 89 17:27:49 -0700 Date: Tue, 4 Apr 89 17:27:49 -0700 From: "Eric L. Raible" Message-Id: <8904050027.AA14172@ew09> To: info-iris@BRL.MIL In-Reply-To: Sam Richards's message of Tue, 04 Apr 89 14:16:37 +0100 <8904040930.aa12418@SMOKE.BRL.MIL> Subject: gnu c++ running in IRIS 4D? Reply-To: raible@orville.nas.nasa.gov Date: Tue, 04 Apr 89 14:16:37 +0100 From: Sam Richards Source-Info: purple.cs.ucl.ac.uk Has anybody managed to get the gnu c++ compiler working on the SGI 4D? Thanks ... Sam Richards. sam@uk.ac.ucl.cs How about just gnu C? How about gdb?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10904; 4 Apr 89 21:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa10859; 4 Apr 89 21:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10828; 4 Apr 89 21:16 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa29051; 4 Apr 89 21:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA21763; Tue, 4 Apr 89 17:41: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: 4 Apr 89 22:28:35 GMT From: Robert Myers Organization: UCSD Network Operations Group Subject: Re: Float to sign/exp/mantissa Message-Id: <1580@ucsd.EDU> References: <1026@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1026@cs-spool.calgary.UUCP> paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > I am sure that someone out there has a routine that given >a floating point number, what is the sign, exponent and mantissa >of the number.. I'd rather not re-invent the wheel if this has > > aTdHvAaNnKcSe > Trev The routines frexp(3) and modf(3) are already part of libm and may be what you are looking for. Raul Rathmann, raul%sdnp1@ucsd.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12424; 5 Apr 89 1:14 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa12224; 5 Apr 89 1:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12208; 5 Apr 89 0:50 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01559; 5 Apr 89 0:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA01742; Tue, 4 Apr 89 21:04:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Apr 89 00:03:07 GMT From: Dennis Linse Organization: Princeton Unversity, Princeton, NJ Subject: Re: EDT settings on 3xxx series Message-Id: <7587@phoenix.Princeton.EDU> References: <8904041707.AA02529@aero4.larc.nasa.gov>, <29974@sgi.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <29974@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: -> -> [Offers some useful comments including ... ] -> ->The timezone is not wired into any IRIS kernel. ... -> ->To fix time on an IRIS 3000 running 3.6, you can: -> ->1) change the date on your machine. -> You will have to ignore the '[ECMP]ST' in date strings. You will -> also have to change the date again in a few weeks. -> ->2) save and edit /etc/TZ, and reboot. For example, the string 'PDT7' -> ->3) don't worry, be happy, and use a real clock for the rest of the month. -> This is probably the best "solution." -> ->4) get rid of this "day light savings" silliness, and use UTC/GMT. -> ->Vernon Schryver ->Silicon Graphics ->vjs@sgi.com While all of these are viable alternatives, I thought that the original question was more aimed at the reason that one must ignore the '[ECMP]ST' when it is actually '[ECMP]DT'. Where is the code that magically changes for standard time to daylight savings time. It is hinted in at least one manual page (ctime?) that there is a way to set up a new table to adjust for different days to change to daylight savings time. It even mentions doing something special for 1974 and 1975. (I know neither why this is important nor why one needs this, or does someone out there run their machine on 1974 time :-) Dennis djlinse@phoenix.princeton.edu -- Found at the top of a looonnng homework assignment: "Activity is the only road to knowledge" G.B. Shaw   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18825; 5 Apr 89 8:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab18327; 5 Apr 89 8:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18185; 5 Apr 89 8:14 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa05209; 5 Apr 89 8:02 EDT Received: Wed, 5 Apr 89 08:01:18 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 5 Apr 89 08:01:18 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904051601.AA05433@aero4.larc.nasa.gov> To: sgi!vjs%rhyolite.SGI.COM@ucbvax.berkeley.edu Subject: Re: EDT settings on 3xxx series Cc: info-iris@BRL.MIL Nothing you said is a "solution", only a patch. Can we expect SGI to FIX this BUG in the system? Where are the daylight savings change over dates set? -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19873; 5 Apr 89 9:55 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18327; 5 Apr 89 8:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18172; 5 Apr 89 8:13 EDT Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa05051; 5 Apr 89 7:54 EDT Received: Wed, 5 Apr 89 07:53:01 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 5 Apr 89 07:53:01 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904051553.AA05405@aero4.larc.nasa.gov> To: ndcheg!uceng!rogden@iuvax.cs.indiana.edu Subject: Re: help w/personal iris selection Cc: info-iris@BRL.MIL A lot depends on what each package includes. Based on other systems I've seen, the Software Development Pkg probably includes compilers, debugers, loaders, etc; sounds necessary for what you want to do. Laser Printer Support probably could be optional, also depending on what it contains and what you want to do and how you want to do it. You can easily write your own software to use Postscript and the system already supports printers. I would say unless it has something you absolutly need, it is not necessary. Documentor's workbench probably is needed. On some systems this IS the online manuals and the necessary support programs. I hope this is some help. Please correct me if I have made a mistake. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02390; 5 Apr 89 12:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01738; 5 Apr 89 12:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01728; 5 Apr 89 12:10 EDT Received: from ALEXANDRIA-EMH2.ARMY.MIL by SMOKE.BRL.MIL id aa13794; 5 Apr 89 11:47 EDT Date: 5 Apr 89 11:22:00 EST From: "ARTIC::GERRITS" Subject: laser video disc on the IRIS To: info-iris Message-ID: <8904051147.aa13794@SMOKE.BRL.MIL> has anybody managed to display images of the laser video disc on the IRIS? Thanks ... Jonus   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03718; 5 Apr 89 13:23 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01059; 5 Apr 89 12:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00946; 5 Apr 89 11:42 EDT Received: from RELAY.CS.NET by SMOKE.BRL.MIL id aa10317; 5 Apr 89 10:44 EDT Received: from relay2.cs.net by RELAY.CS.NET id ae19362; 5 Apr 89 10:12 EDT Received: from gmr.com by RELAY.CS.NET id ac25632; 5 Apr 89 10:11 EDT Date: Wed, 5 Apr 89 09:03 EST From: JORDAN%gmr.com@relay.cs.net Subject: VMS utilities To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.mil" Message-ID: <8904051044.aa10317@SMOKE.BRL.MIL> VMS has a console handler that allows one to edit previous commands by using the up arrow key. For me, this is far superior than the history commands used in UNIX. Has anyone out there written any routines out there to emulate this on a UNIX system? or for sale? Thanks, ted jordan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07315; 5 Apr 89 14:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01738; 5 Apr 89 12:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01646; 5 Apr 89 12:07 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa13499; 5 Apr 89 11:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02550; Wed, 5 Apr 89 08:24: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: 5 Apr 89 13:36:35 GMT From: John Buck Organization: Polytechnic University, Farmingdale NY Subject: Re: Float to sign/exp/mantissa Message-Id: <458@polyof.UUCP> References: <1026@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1026@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > I am sure that someone out there has a routine that given > a floating point number, what is the sign, exponent and mantissa > of the number.. I'd rather not re-invent the wheel if this has > already been done... Most Unix manuals have the frexp(3C) and ldexp(3c) functions which do what you want. [man 3 frexp]. If your system does not have them under frexp/ldexp, they MAY be called something else. Check your permuted index. John Buck john@polyof.poly.edu trixie!polyof!john   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09469; 5 Apr 89 15:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07639; 5 Apr 89 14:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07533; 5 Apr 89 14:41 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa18638; 5 Apr 89 14:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA12079; Wed, 5 Apr 89 11:17: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: 5 Apr 89 17:18:31 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: EDT settings on 3xxx series Message-Id: <30062@sgi.SGI.COM> References: <8904041707.AA02529@aero4.larc.nasa.gov>, <29974@sgi.SGI.COM>, <7587@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <7587@phoenix.Princeton.EDU>, djlinse@phoenix.Princeton.EDU (Dennis Linse) writes: > > ... Where is the code that > magically changes for standard time to daylight savings time. > > djlinse@phoenix.princeton.edu The old ctime(3) code has a compiled-in table. There is at least two more or less public domain versions of ctime(3) which use various methods to convert time to an ASCII string, including worrying about timezones and daylight savings. You could write your own. That will not help very much on a [123]000 unless you have the source to things such as ls(1), date(1), sendmail, [mM]ail, and csh(1), all of which are linked with the previous version of ctime. At least the SVR3.2 based 4D's have the new style TZ environment variable, which lets you set things to your government's heart's content. (Guy Harris has reminded me that it was always the TZ environment variable. Only the file name changed in SVR3.) Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15725; 5 Apr 89 18:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15371; 5 Apr 89 18:02 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15258; 5 Apr 89 17:48 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa24100; 5 Apr 89 17:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA21235; Wed, 5 Apr 89 14:18: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: 5 Apr 89 20:25:01 GMT From: Stuart Crawford Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300 Subject: Printing a screendump Message-Id: <7466@zodiac.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This should be a fairly straightforward task. How do you generate and print a screendump (rasterfile)? We have both imagen and Postscript printers and printing to either would be fine. Thanks in advance. Stuart Crawford Advanced Decision Systems stuart@ads.com - Stuart   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16295; 7 Apr 89 12:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14753; 7 Apr 89 10:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14740; 7 Apr 89 10:22 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa23522; 7 Apr 89 10:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19251; Fri, 7 Apr 89 06:51: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: 5 Apr 89 18:04:01 GMT From: Trevor Paquette Subject: Re: Float to sign/exp/mantissa Message-Id: <1046@cs-spool.calgary.UUCP> References: <1026@cs-spool.calgary.UUCP>, <1044@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1044@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > In article <1026@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: ] > ] > ] > I am sure that someone out there has a routine that given ] > a floating point number, what is the sign, exponent and mantissa ] > of the number.. I'd rather not re-invent the wheel if this has ] > already been done. If some kind soul out there has such a ] > function, and is willing to send it my way, I'd be very grateful. ] > ] > aTdHvAaNnKcSe ] > Trev ] > ] ] Maybe I should elaborate on this a bit.. ] What I am doing is writing a Machine Independant Format (MIF) similar to ] XDR that Sun has. This arose out of the fact that some of the machines ] that we need to use do not have XDR support.. So I am writing my own. ] Since floats and doubles are represented the same way on different machines *** * The above line should read.. *> Since floats and doubles are NOT represented the same way on different machines * Sorry if the caused any confusion *** ] I have to come up with a way of representing a number in a file that is ] machine independant. ] I DO NOT want to do something like the following to represent an integer.. ] ] /* FILE *fp; ] int num; */ ] fprintf(fp,"%d ",num); ] ] This is clearly a waste of disk space.. when we can do the following.. ] ] /* char ch[4]; */ ] /* to write the number */ ] ch[0] = (char)((*num & 0xff000000) >> 24); ] ch[1] = (char)((*num & 0x00ff0000) >> 16); ] ch[2] = (char)((*num & 0x0000ff00) >> 8); ] ch[3] = (char)((*num & 0x000000ff)); ] fwrite(ch, 1, 4, fp); ] ] /* to read the number */ ] fread(ch, 1, 4, fp); ] num = (int)(ch[3]) + (int)(ch[2] << 8) + (int)(ch[1] << 16) + (int)(ch[0] << 24); ] ] Much better.. saves lotsa disk space.. files tend to be MUCH smaller this way. ] ] Now the problem arises when trying to save a float or a double.. how? ] I want to keep as much precision in the number as possible.. ] ] the following is a start but I still end up with a float to deal with.. ] ] double d = some number; ] double mant; ] int exp; ] ] mant = frexp(d, &exp); ] ] I still have mant to deal with which is a float.. back to square one.. ] ] Any help would be appreciated.. ============================================================================== Trevor Paquette/GraphicsLand, Calgary, Alberta ..uunet!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W calgary!paquette@cs.ubc.ca Luminous beings we are, not this crude matter   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17673; 7 Apr 89 14:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16454; 7 Apr 89 12:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16405; 7 Apr 89 12:30 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa26385; 7 Apr 89 11:39 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19234; Fri, 7 Apr 89 06:51: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: 5 Apr 89 17:24:55 GMT From: Trevor Paquette Subject: Re: Float to sign/exp/mantissa Message-Id: <1044@cs-spool.calgary.UUCP> References: <1026@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1026@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > > > I am sure that someone out there has a routine that given > a floating point number, what is the sign, exponent and mantissa > of the number.. I'd rather not re-invent the wheel if this has > already been done. If some kind soul out there has such a > function, and is willing to send it my way, I'd be very grateful. > > aTdHvAaNnKcSe > Trev > Maybe I should elaborate on this a bit.. What I am doing is writing a Machine Independant Format (MIF) similar to XDR that Sun has. This arose out of the fact that some of the machines that we need to use do not have XDR support.. So I am writing my own. Since floats and doubles are represented the same way on different machines I have to come up with a way of representing a number in a file that is machine independant. I DO NOT want to do something like the following to represent an integer.. /* FILE *fp; int num; */ fprintf(fp,"%d ",num); This is clearly a waste of disk space.. when we can do the following.. /* char ch[4]; */ /* to write the number */ ch[0] = (char)((*num & 0xff000000) >> 24); ch[1] = (char)((*num & 0x00ff0000) >> 16); ch[2] = (char)((*num & 0x0000ff00) >> 8); ch[3] = (char)((*num & 0x000000ff)); fwrite(ch, 1, 4, fp); /* to read the number */ fread(ch, 1, 4, fp); num = (int)(ch[3]) + (int)(ch[2] << 8) + (int)(ch[1] << 16) + (int)(ch[0] << 24); Much better.. saves lotsa disk space.. files tend to be MUCH smaller this way. Now the problem arises when trying to save a float or a double.. how? I want to keep as much precision in the number as possible.. the following is a start but I still end up with a float to deal with.. double d = some number; double mant; int exp; mant = frexp(d, &exp); I still have mant to deal with which is a float.. back to square one.. Any help would be appreciated.. Trev ============================================================================== Trevor Paquette/GraphicsLand, Calgary, Alberta ..uunet!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W calgary!paquette@cs.ubc.ca Luminous beings we are, not this crude matter   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02910; 6 Apr 89 13:43 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22837; 6 Apr 89 10:32 EDT Date: Thu, 6 Apr 89 10:15:16 EDT From: Gary S. Moss (VLD/VMB) To: Stuart Crawford cc: info-iris@BRL.MIL Subject: Re: Printing a screendump Message-ID: <8904061015.aa22718@VMB.BRL.MIL> < This should be a fairly straightforward task. How do you generate and print < a screendump (rasterfile)? We have both imagen and Postscript printers and < printing to either would be fine. Thanks in advance. < < Stuart Crawford Stuart, I agree it should be fairly straightforward, but saying that could get you in trouble with Murphy. I assume that you are running 4Sight, so look on page N5-28 (section 5.2 of the 4Sight User's Guide version 2.0) and there are both the 'writecanvas' and 'writescreen' PostScript procedures. The example that they give for dumping the whole screen is: framebuffer setcanvas (/tmp/snap) writescreen Where /tmp/snap is the absolute path name of the output file. Feeding this to 'psh' gave me a 'timeout' error, but I got a file of 3617400 bytes. I'm not sure if any utilities exist for using this format file; it just says that it is a rasterfile. Also, there is a utility called 'scrsave' in /usr/NeWS/bin that will save all or part of the screen in an SGI image format suitable for display with the 'readcanvas' PostScript procedure on page N5-22. I tried saving the entire screen and got a file of 620279 bytes. I fed it to my ScreenLock program, which takes an optional image file name, and it looked correct. I don't know off-hand if any converters or NeWS/PostScript procedures exist to produce a PostScript file from one of these formats, but that would be the logical next step. If no one else comes up with something, I will start hunting through the documentation and NeWS directories again, it's starting to become a bad habit though. I also don't know if the formats of these files are documented, but that would certainly be helpful. Please keep me posted, I could also make use of such a capability. -moss   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10351; 7 Apr 89 3:49 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa10180; 7 Apr 89 3:38 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa10097; 7 Apr 89 3:17 EDT Received: from UCBVAX.Berkeley.EDU by ADM.BRL.MIL id aa06062; 6 Apr 89 16:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA25821; Thu, 6 Apr 89 12:18: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 Apr 89 19:15:09 GMT From: Alex Woo Organization: NASA-Ames Research Center Subject: Removable SCSI winchesters for 4D's Message-Id: <23570@ames.arc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a requirement for removable winchester disk drives for an IRIS 4D's. In theory this should work from the IRIS's SCSI port but we have not tried any vendor. If you have installed removable winchesters, I would appreciate it if you would drop me a note. We have used Emulex PDM 380's on VAX's and microVAX's but they do not explicitly support IRIS's. Thanks. ====================================================================== Alex Woo, MS 227-2 | woo@pioneer.arc.nasa.gov NASA Ames Research Center | woo@amelia.nas.nasa.gov Moffett Field, CA 94035 | {seismo,topaz,lll-crg,ucbvax}! Phone: (415) 694-6010 | ames!pioneer!woo ====================================================================== {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!pioneer!woo ======================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21509; 7 Apr 89 16:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19414; 7 Apr 89 15:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19314; 7 Apr 89 15:00 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa02795; 7 Apr 89 14:40 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA03201; Fri, 7 Apr 89 11:22: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 Apr 89 18:26:58 GMT From: Kenneth Smith Organization: Biology Dept., Columbia Univ., New York, NY Subject: Solid modeling program needed for neuron display Message-Id: <258@cubsun.BIO.COLUMBIA.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Solids Modeling program needed for neuron reconstruction. The host machine is a Silicon Graphics 4D70GT. We are looking for a program to render the surfaces of several objects at once, given a set of non-uniformly distributed points on the boundaries of equally spaced slices through the objects. The data consist of the outlines of neurons traced automatically from serial electron micrographs. Many individual neurons may be traced in each frame, and their reconstructions from a series of frames must be treated as separate objects by the display program. The traced neuron contours can have arbitrary shape, and the reconstructed objects are of arbitrary complexity, i.e. they may be simple tubes or highly branched. We are already familiar with Alpha1 and Voxel/View. If anyone knows of any other packages, I would appreciate hearing about it. Thanks- -------------------------------------------------------------------------------- Kenneth C. Smith INTERNET: ksmith@cubmol.bio.columbia.edu Computer Graphics Facility UUCP: ...!columbia!cubmol!ksmith Dept. of Biological Sci. BITNET: ksmith%cubmol.bio.columbia.edu@cuvmb.bitnet Columbia University, New York, NY 10027   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21870; 7 Apr 89 17:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21766; 7 Apr 89 17:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21690; 7 Apr 89 16:53 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa06909; 7 Apr 89 16:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA09190; Fri, 7 Apr 89 13:18: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: 7 Apr 89 16:18:50 GMT From: Steve Correll Organization: Key Computer Labs, Fremont, CA Subject: Re: VMS utilities Message-Id: <745@key.COM> References: <8904051044.aa10317@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8904051044.aa10317@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > VMS has a console handler that allows one to edit previous commands by > using the up arrow key. For me, this is far superior than the history > commands used in UNIX. Has anyone out there written any routines out > there to emulate this on a UNIX system? MIPS systems have an optional emacs-like line editor built into both "csh" and "dbx"; it has roughly the same functionality as the VMS handler, but uses control-characters rather than the arrow keys (unfortunately, though you can customize it to use the control-keys of your choice, you can't make it use the arrow keys). The SGI Irises based on the MIPS CPU lack this useful feature (though the SGI "dbx" manual even mentions it briefly). Is somebody at SGI listening who might have mercy on us fumble-fingered users who dislike cardpunch-style editing with "!" and "^"? -- ...{sun,pyramid}!pacbell!key!sjc Steve Correll   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22668; 7 Apr 89 19:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22586; 7 Apr 89 19:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22535; 7 Apr 89 19:00 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa08438; 7 Apr 89 18:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA15666; Fri, 7 Apr 89 15:16: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 Apr 89 21:35:14 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: VMS utilities Message-Id: <30242@sgi.SGI.COM> References: <8904051044.aa10317@SMOKE.BRL.MIL>, <745@key.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <745@key.COM>, sjc@key.COM (Steve Correll) writes: > In article <8904051044.aa10317@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: > > VMS has a console handler that allows one to edit previous commands by > > using the up arrow key. For me, this is far superior than the history > > commands used in UNIX. Has anyone out there written any routines out > > there to emulate this on a UNIX system? > > MIPS systems have an optional emacs-like line editor built into both "csh" and > "dbx"; it has roughly the same functionality as the VMS handler, but uses > control-characters rather than the arrow keys (unfortunately, though you can > customize it to use the control-keys of your choice, you can't make it use the > arrow keys). > > The SGI Irises based on the MIPS CPU lack this useful feature (though the SGI > "dbx" manual even mentions it briefly). Is somebody at SGI listening who might > have mercy on us fumble-fingered users who dislike cardpunch-style editing > with "!" and "^"? > -- > ...{sun,pyramid}!pacbell!key!sjc Steve Correll At they moment, you will have to settle for second sources for command line editing features. For csh users, tcsh is available in the public domain (don't ask me where). tcsh is a superset of csh and supports command line editing. I believe this is what MIPS Computers supports as their csh. You may also need csh source for this. KSH-88 is a superset of sh and is available from the AT&T Unix System Toolchest. One major feature is that it supports both vi and emacs style command line editing. AT&T System V.4 will replace sh with KSH-88. If you have a modem, call 1-201-522-6900 and log in as "guest". From there you can recieve instructions on how to obtain KSH-88 and other goodies. -- Dave (commonplace) "Boldly going where no one cares to go." Ciemiewicz (incomprehensible) ciemo (infamous)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23241; 7 Apr 89 21:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23182; 7 Apr 89 21:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23139; 7 Apr 89 20:49 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa09646; 7 Apr 89 20:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA21550; Fri, 7 Apr 89 17:08:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Apr 89 23:53:58 GMT From: Renu Raman Organization: Sun Microsystems, Mountain View Subject: Re: VMS utilities Message-Id: <98096@sun.Eng.Sun.COM> References: <8904051044.aa10317@SMOKE.BRL.MIL>, <745@key.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <745@key.COM> sjc@key.COM (Steve Correll) writes: >In article <8904051044.aa10317@SMOKE.BRL.MIL>, JORDAN@gmr.COM writes: >> VMS has a console handler that allows one to edit previous commands by >> using the up arrow key. For me, this is far superior than the history >> commands used in UNIX. Has anyone out there written any routines out >> there to emulate this on a UNIX system? > >MIPS systems have an optional emacs-like line editor built into both "csh" and >"dbx"; it has roughly the same functionality as the VMS handler, but uses >control-characters rather than the arrow keys (unfortunately, though you can >customize it to use the control-keys of your choice, you can't make it use the >arrow keys). > >The SGI Irises based on the MIPS CPU lack this useful feature (though the SGI >"dbx" manual even mentions it briefly). Is somebody at SGI listening who might >have mercy on us fumble-fingered users who dislike cardpunch-style editing >with "!" and "^"? >-- >...{sun,pyramid}!pacbell!key!sjc Steve Correll If you have the csh sources, then get the tcsh sources (which are basically diffs to csh + some code) from the comp.sources archive and you can get the functionality of the emacs like editor, including arrow keys - atleast its possible on vtxxx terminals as well on my Sun console). It has more bells & whistles like command search, file/command completions, man page lookups, command spelling correction.........list goes on. Renu Raman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23548; 7 Apr 89 22:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23434; 7 Apr 89 21:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23416; 7 Apr 89 21:42 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10051; 7 Apr 89 21:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA24580; Fri, 7 Apr 89 18:13: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: 7 Apr 89 23:42:39 GMT From: ee993@cs.yale.edu Organization: Yale Computer Center, New Haven Subject: Re: Solid modeling program needed for neuron display Message-Id: <56235@yale-celray.yale.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <258@cubsun.BIO.COLUMBIA.EDU>, ksmith@cubsun.BIO.COLUMBIA.EDU (Kenneth Smith) writes... > >Solids Modeling program needed for neuron reconstruction. The host machine >is a Silicon Graphics 4D70GT. > A good program package is Movie.BYU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24076; 8 Apr 89 0:20 EDT Received: by VMB.BRL.MIL id aa23882; 8 Apr 89 0:08 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa23760; 7 Apr 89 23:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab23738; 7 Apr 89 23:18 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10812; 7 Apr 89 23:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA26223; Fri, 7 Apr 89 18:47: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 Apr 89 00:24:21 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: vax utilities Message-Id: <427@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If some people are really interested in VMS like command line editing on the 4D machines why not get the commercial product VCL from Boston Business Computing. It allows full VMS type command line editing as well as about 80% of the other things which VMS allows. P.S. they also sell what appears to be a 100% compatible EDT editor for the 4D. (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab24076; 8 Apr 89 0:20 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa23881; 8 Apr 89 0:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23863; 7 Apr 89 23:52 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa10957; 7 Apr 89 23:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA29994; Fri, 7 Apr 89 20:12: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: 8 Apr 89 02:03:44 GMT From: Daniel A Haug Organization: Lockheed Austin Div. Subject: GNU Emacs for 4D machines Message-Id: <234@shrike.AUSTIN.LOCKHEED.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How does one go about getting GNU Emacs on SG machines, in particular, the 4D machine? Is there a PD version for the SG? Not being an Emacs whiz, I took the source code from our Sun version, moved it over, updated the config.h and began recompiling modules. This has not been working very well. Am I naive? What is the best approach here? dan haug Internet: haug@austin.lockheed.com uucp: ut-emx!lad-shrike!aihaug   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27560; 8 Apr 89 18:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27296; 8 Apr 89 17:35 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa27288; 8 Apr 89 17:16 EDT Received: from UCBVAX.Berkeley.EDU by ADM.BRL.MIL id aa05069; 8 Apr 89 17:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA13168; Sat, 8 Apr 89 13:39:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Apr 89 20:01:17 GMT From: Bevis Ip Organization: University of Toronto Mechanical Engineering Subject: Re: VMS utilities Message-Id: <89Apr8.160131edt.18546@me.utoronto.ca> References: <8904051044.aa10317@SMOKE.BRL.MIL>, <745@key.COM>, <98096@sun.Eng.Sun.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <98096@sun.Eng.Sun.COM> ram@sun.UUCP (Renu Raman) writes: > If you have the csh sources, then get the tcsh sources (which are basically > diffs to csh + some code) from the comp.sources archive and you can > get the functionality of the emacs like editor, including arrow keys - > ... I believe the version posted is 5.9, which is fine if you don't want job control. If you are 4Ds running >IRIX4.1, you might want to get it from tut.cis.ohio-state.edu via ftp in /usr/pub/tcsh directory, the version there right now is 5.12 and the next release (5.13?) will work for 4Ds with job control. If you can't wait for the next release, I can probably send you the diffs to 5.12 (which I've sent to Paul Placeway) if there aren't many request. If you don't have vanilla BSD4.3 source, I might make the bianary available if you can trust binary release (I don't). bevis -- Bevis Ip University of Toronto Mechanical Engineering CSNET : ip@me.toronto.edu BITNET: ip@me.UTORONTO Internet: ip%me.toronto.edu@relay.cs.net UUCP : {allegra,decwrl,decvax}!utcsri!me!ip _OR_ {pyramid,uunet}!utai!me!ip   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00649; 9 Apr 89 0:24 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ac00310; 9 Apr 89 0:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id al00225; 8 Apr 89 23:56 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01373; 8 Apr 89 20:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA21644; Sat, 8 Apr 89 17:01: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: 8 Apr 89 23:16:09 GMT From: Guy Harris Organization: Auspex Systems, Santa Clara Subject: Re: Float to sign/exp/mantissa Message-Id: <1407@auspex.auspex.com> References: <1026@cs-spool.calgary.UUCP>, <1044@cs-spool.calgary.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > What I am doing is writing a Machine Independant Format (MIF) similar to > XDR that Sun has. This arose out of the fact that some of the machines > that we need to use do not have XDR support.. So I am writing my own. You may want to grab Sun's XDR source from, say, "uunet", instead; it's in the "comp.sources.unix" archives. It may not have support for your floating-point format, but at least it's a start. Basically, the XDR form is big-endian IEEE. The code is machine-dependent; the VAX version represents the VAX format as a structure with bit fields, and extracts and inserts the fields that way.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00987; 9 Apr 89 1:17 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00310; 9 Apr 89 0:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab00145; 8 Apr 89 23:53 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa00412; 8 Apr 89 19:00 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA18410; Sat, 8 Apr 89 15:44:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Apr 89 17:21:57 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Solid modeling program needed for neuron display Message-Id: <30293@sgi.SGI.COM> References: <258@cubsun.BIO.COLUMBIA.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <258@cubsun.BIO.COLUMBIA.EDU>, ksmith@cubsun.BIO.COLUMBIA.EDU (Kenneth Smith) writes: > > Solids Modeling program needed for neuron reconstruction. The host machine > is a Silicon Graphics 4D70GT. > Have you checked out Vital Images? They have 3D software which does exactly this. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00987; 9 Apr 89 1:17 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00310; 9 Apr 89 0:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00225; 8 Apr 89 23:55 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01233; 8 Apr 89 20:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA20811; Sat, 8 Apr 89 16:39: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: 8 Apr 89 22:35:54 GMT From: Bevis Ip Organization: University of Toronto Mechanical Engineering Subject: Re: VMS utilities Message-Id: <89Apr8.183558edt.18575@me.utoronto.ca> References: <8904051044.aa10317@SMOKE.BRL.MIL>, <745@key.COM>, <98096@sun.Eng.Sun.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL [ My apology to local readers, my last one didn't get out of our machines at all; so I'm doing again on hammer. - bevis ] In article <98096@sun.Eng.Sun.COM> ram@sun.UUCP (Renu Raman) writes: > If you have the csh sources, then get the tcsh sources (which are basically > diffs to csh + some code) from the comp.sources archive and you can > get the functionality of the emacs like editor, including arrow keys - > ... I believe the version posted is 5.9, which is fine if you don't want job control. If you are 4Ds running >IRIX4.1, you might want to get it from tut.cis.ohio-state.edu via ftp in /usr/pub/tcsh directory, the version there right now is 5.12 and the next release (5.13?) will work for 4Ds with job control. If you can't wait for the next release, I can probably send you the diffs to 5.12 (which I've sent to Paul Placeway) if there aren't many request. If you don't have vanilla BSD4.3 source, I might make the bianary available if you can trust binary release (I don't). bevis -- Bevis Ip University of Toronto Mechanical Engineering CSNET : ip@me.toronto.edu BITNET: ip@me.UTORONTO Internet: ip%me.toronto.edu@relay.cs.net UUCP : {allegra,decwrl,decvax}!utcsri!me!ip _OR_ {pyramid,uunet}!utai!me!ip   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01526; 9 Apr 89 3:18 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab01395; 9 Apr 89 2:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab01387; 9 Apr 89 2:43 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa03761; 9 Apr 89 2:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA06189; Sat, 8 Apr 89 23:13: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: 9 Apr 89 05:23:08 GMT From: Nadeem Malik Organization: UTexas Computation Center, Austin, Texas Subject: Sun Common-Lisp (Lucid) reassembly Message-Id: <11873@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sun Common lisp on Sun4, which I believe is Lucid lisp, allows disassembly of the lisp functions. I am interested in reassembling the disassembled code after modifying it for collecting some run-time trace data. There is no reassemble function in Lucid lisp to allow this. I would appreciate any comments or suggestions on how to achieve this reassembly. Another way would be to compile a function to be instrumented in to a file and then modify the object code in the compiled file, but sun4 doesn't have a disassembler. I would greatly appreciate any help on pointing me to either a disassembler for sun4, or Lisp reassembler. Thanks, in advance. -- Nadeem Malik. SNAIL: ENS 312, Electrical and Computer Engin, U.T., Austin, Tx 78712 EMAIL: malik@emx.utexas.edu {uunet,harvard}!cs.utexas.edu!emx!malik VOICE: (512) 471-3903   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01626; 9 Apr 89 3:49 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01395; 9 Apr 89 2:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01387; 9 Apr 89 2:43 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa03755; 9 Apr 89 2:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA06196; Sat, 8 Apr 89 23:13: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: 9 Apr 89 05:30:09 GMT From: Nadeem Malik Organization: UTexas Computation Center, Austin, Texas Subject: Re: Sun Common-Lisp (Lucid) reassembly Message-Id: <11874@ut-emx.UUCP> References: <11873@ut-emx.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <11873@ut-emx.UUCP> malik@emx.UUCP (Nadeem Malik) writes: >Sun Common lisp on Sun4, which I believe is Lucid lisp, allows disassembly of >the lisp functions. I am interested in reassembling the disassembled code Please excuse me for the accidental cross-posting of the above message in your group. -- Nadeem Malik. SNAIL: ENS 312, Electrical and Computer Engin, U.T., Austin, Tx 78712 EMAIL: malik@emx.utexas.edu {uunet,harvard}!cs.utexas.edu!emx!malik VOICE: (512) 471-3903   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04247; 9 Apr 89 18:49 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03820; 9 Apr 89 17:36 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03811; 9 Apr 89 17:16 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa09467; 9 Apr 89 17:02 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA13382; Sun, 9 Apr 89 13:38: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: 9 Apr 89 20:02:06 GMT From: Rayan Zachariassen Organization: Department of Computer Science, University of Toronto Subject: Experiences with 4D/2xx as timesharing systems? Message-Id: <89Apr9.160219edt.38129@neat.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Whether in the short or long term, we are looking at the high-end SGI boxes as compute servers and timesharing boxes. In this context we are totally uninterested in their graphics aspects. I'd like to hear from sites that are already doing this, if any, with any comments about this kind of use of the SGI boxes. I'm especially interested in comparisons with other systems prior to purchase, and differences between expectations and reality after you got the box in. I gather these things have just started shipping so the field is probably still meagre... In order to get technical details out of the local salescritter we have to ask specific questions, so I'd also like some general answers to the following to get us going: Our major worry (in the fine SGI tradition...) is with the software, in particular we consider any System V based box to start out with a negative (this is our reality not our religion). We understand SGI is committed to SV. Does this mean they will track AT&T SV releases directly, or that whatever SV-based OS that MIPS comes up with will shortly appear on the 4Ds? The filesystem is a worry. We're happy it isn't SV but unhappy at the apparent gratuitous incompatibility with the BSD F^nS. Our tools are unlikely to work, right? It also seems like a less robust design. Will it go away in favour of something else that is largely compatible with F^nS ((Fat)Fast File System)? I note that MIPS ships FFS with their rice-computer OS, how come SGI seems to be waiting for SVR4 to do the same? During testing on the personal iris, some anomalies showed up that could be explained by the scheduler or VM being tuned for a single-user workstation environment. For example running a certain (non-graphics) program would cause lost ether packets and horrible response time on the iris, but the same program is apparently wellbehaved on other machines. Similarly, logging out of the PI causes lost packets. Anyone experienced similar anomalies on the 4D/2xx? Anyone using them for timesharing? How does the fine-grained multiprocessing support (threads libraries, compiler support etc.) differ qualitatively from other implementations (MachOS, Sequent, Encore, Sun)? Can one use a 4D to serve root and swap for a SunOS 4.0 workstation? How is the hardware reliability on the 4Ds? Any other pertinent comments from customers are welcome. The kind of configuration that is of interest is a 4D/240S with minimal extra stuff (small SCSI, cartridge), to which we'll add the storage subsystem w/ a few gigs of disk. Users would have access via the ether. In the timesharing application we would want to potentially support at least twice the work our Sun4/280Ss are being asked to do (which is 30 users + 30 workstations, mostly light activity but occasional developers and long-running and/or large jobs) which it does well when it works. Please REPLY BY MAIL! I will summarize if interesting info appears. Thanks, rayan AI/NA/Theory, DCS, U of Toronto   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11079; 10 Apr 89 10:36 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09177; 10 Apr 89 9:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09090; 10 Apr 89 9:07 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa19287; 10 Apr 89 8:56 EDT Received: Mon, 10 Apr 89 08:56:12 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 10 Apr 89 08:56:12 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904101656.AA16000@aero4.larc.nasa.gov> To: mailrus!jarvis.csri.toronto.edu!neat.ai.toronto.edu!rayan@tut.cis.ohio-state.edu Subject: Re: Experiences with 4D/2xx as timesharing systems? Cc: info-iris@BRL.MIL If you are not interested in graphics, why buy a SGI machine? Buy something from anybody else, it is bound to be better, cheaper, and better supported than a SGI machine. Do you not like UNIX or just System V in particular? -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11768; 10 Apr 89 11:07 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09759; 10 Apr 89 9:54 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09598; 10 Apr 89 9:42 EDT Received: from neat.ai.toronto.edu by SMOKE.BRL.MIL id aa20151; 10 Apr 89 9:25 EDT Received: from localhost (stdin) by neat.ai.toronto.edu with SMTP id 38134; Mon, 10 Apr 89 09:27:27 EDT To: Bates TAD/HRNAB ms294 x2601 Cc: info-iris@BRL.MIL Subject: Re: Experiences with 4D/2xx as timesharing systems? In-reply-to: Your message of "Mon, 10 Apr 89 09:56:12 -0400". Date: Mon, 10 Apr 89 09:27:16 EDT From: Rayan Zachariassen Message-Id: <89Apr10.092727edt.38134@neat.ai.toronto.edu> Because if one ignores the graphics then the boxes become a competitive hardware platform for general purpose computing. SGI keeps thinking of themselves as a graphics company (at least that's the reaction we get from high-ups when they see our lack of interest in the graphics). This is a pity because with the right OS they could make a killing in our kind of market. To answer your second question, UNIX is indeed the right OS, but System V in particular is NOT. If (say) a multiprocessor 4.3+BSD ran on the 4Ds and competitive hardware price was maintained, they'd be the only game in town for us. We even frown on berkeleyized SV because the admin stuff is different, but I guess we can live with it if we have to. If there is a future 4BSD-mips release, I'd love to see a port to the 4D platform. rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14255; 10 Apr 89 13:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12972; 10 Apr 89 12:20 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa12944; 10 Apr 89 12:09 EDT Date: Mon, 10 Apr 89 11:51:01 EDT From: Phil Dykstra To: Rayan Zachariassen cc: info-iris@BRL.MIL Subject: Re: Experiences with 4D/2xx as timesharing systems? Message-ID: <8904101151.aa03979@SPARK.BRL.MIL> > Because if one ignores the graphics then the boxes become a competitive > hardware platform for general purpose computing. Yes, even if you totally ignore the graphics, the CPU power per dollar in the SGI's is still impressive. W.r.t. BSD Unix on SGI machines, I agree that this would sure be nice! I despise SysV. I think our hope of liberation will come with R4, which will finally make System V a usable OS [By then of course 4.4 BSD will be out and SysV will have to play catch up again, but it will still be a major improvement]. - Phil   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab14255; 10 Apr 89 13:44 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14008; 10 Apr 89 13:33 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13952; 10 Apr 89 13:20 EDT Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa27262; 10 Apr 89 12:58 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA28644; Mon, 10 Apr 89 12:53:34 EDT Received: by buita.bu.edu (3.2/4.7) id AA08525; Mon, 10 Apr 89 12:55:33 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA12937; Mon, 10 Apr 89 11:00:09 EDT Date: Mon, 10 Apr 89 11:00:09 EDT From: Joe Ilacqua Message-Id: <8904101500.AA12937@adt.uucp> To: info-iris@BRL.MIL Subject: Re: VMS utilities Message-Id: <8904101515.AA13178@adt.uucp> To: info-iris@BRL.MIL Subject: Re: Experiences with 4D/2xx as timesharing systems? > If you are not interested in graphics, why buy a SGI machine? >Buy something from anybody else, it is bound to be better, cheaper, >and better supported than a SGI machine. The high-end 4D machines have very good price/performance even without the graphics (so do the Personals but without graphics new offerings from DEC etc are better apparently). If they beat other systems in price/performance (they beat quite a few), then the graphics is just a bonus. Operators can play flight while waiting for backups :-). Seriously, I believe that a properly tuned/configured 4D/2xx would make a fantastic multiuser machine for the money. The biggest problem is the lack of serial ports, which can be fixed by either a cheap machine as a front-end or a standalone terminal server such as encore's annex box. Exactly how well this will perform is up in the air; all of our SGI machines are obviously tuned to work single-user/single application and perform rather poorly if you break these constraints. I haven't looked into correcting this because we generally have one user, one or more machines. Since the machines are mostly SysV and are intended to be workstations, there are some real problems with using them as multiuser: * 'tar' is not a backup program, no matter who thinks so. We copy entire filesystems between machines for redundancy and back up from one of the Suns, but our data space is less then a half-gigabyte in general, not the case on large multiuser machines. * SysV "ps" is too painful to use when managing a system with lots of things running. Someone ought to build an "sps". Funky shell scripts could fix this but when you need to know what's going on, you usually are in too much trouble to waste that kind of time and resources to find out (eg some idiot accidentally spawned two hundred jobs and filled the proc table; never done it myself :-). * There are several programs (ftp has given me trouble in the past) which don't clean up utmp correctly, bothersome but not fatal. * The filesystem does not appear to be BSD FFS, something which becomes an issue real fast with a lot of users. It doesn't have the 14 character bugaboo that bothers me so much though. * If you use Sun's yp, you're in for a lot of fun. It's not the default for getpwent etc. Aside from the problems that caused, we've had few problems with it. * The graphics is not in the least bit secure. Neither is anyone else's that I've worked with. That's all I can think of at the moment. Some of the above may have been fixed; the OS version we use on most of our 4D's is out-of-date and we've yet to see an update. I'd be interested in hearing about performance if someone has tuned a 4D for multiuser. jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14943; 10 Apr 89 14:26 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14700; 10 Apr 89 14:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14573; 10 Apr 89 13:58 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa28845; 10 Apr 89 13:51 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA07403; Mon, 10 Apr 89 10:14:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 89 15:53:21 GMT From: Tom Russo Organization: University of Texas at Austin, Center for Nonlinear Dynamics Subject: Re: GNU Emacs for 4D machines Message-Id: <11902@ut-emx.UUCP> References: <234@shrike.AUSTIN.LOCKHEED.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Well, the way I did it was to grab the distribution off of uunet.uu.net (anonymous FTP) and then use the header files which were posted here a few months ago INSTEAD OF THOSE IN THE DISTRIBUTION. Here's the README from my emacs source directory, and a shell script to unpack the header files. Once you do all that's said in the readme, you should have a running emacs. Good luck. --------------/usr/local/emacs/src/README --------------------------- In order to get emacs to compile on the Irises, one must: substitute the .h and .c files in this directory for the ones that come with emacs. edit config.h-dist to use these headerfiles, and save it to config.h edit etc/Makefile to use CFLAGS=-g -I/usr/include/bsd LOADLIBES=-lmld then make from the top directory ---------sgiemacs.shar--------------------------------------------------- #!/bin/sh # This is a shell archive. Remove anything before this line, then # unpack it by saving it in a file and typing "sh file". (Files # unpacked will be owned by you and have default permissions.) # # This archive contains: # s-iris3-6.h m-iris4d.h unexmips.c echo x - s-iris3-6.h cat > "s-iris3-6.h" << '//E*O*F s-iris3-6.h//' /* Definitions file for GNU Emacs running on Silicon Graphics system 3.6. Copyright (C) 1987 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the GNU Emacs General Public License for full details. Everyone is granted permission to copy, modify and redistribute GNU Emacs, but only under the conditions described in the GNU Emacs General Public License. A copy of this license is supposed to have been given to you along with GNU Emacs so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* * Define symbols to identify the version of Unix this is. * Define all the symbols that apply correctly. */ #define USG #define USG5 #define IRIS /* SYSTEM_TYPE should indicate the kind of system you are using. It sets the Lisp variable system-type. */ #define SYSTEM_TYPE "silicon-graphics-unix" /* nomultiplejobs should be defined if your system's shell does not have "job control" (the ability to stop a program, run some other program, then continue the first one). */ #define NOMULTIPLEJOBS /* Default is to set interrupt_input to 0: don't do input buffering within Emacs */ /* #define INTERRUPT_INPUT */ /* Letter to use in finding device name of first pty, if system supports pty's. 'a' means it is /dev/ptya0 */ #define FIRST_PTY_LETTER 'a' /* * Define HAVE_TERMIO if the system provides sysV-style ioctls * for terminal control. */ #define HAVE_TERMIO /* * Define HAVE_TIMEVAL if the system supports the BSD style clock values. * Look in for a timeval structure. */ #define HAVE_TIMEVAL /* * Define HAVE_SELECT if the system supports the `select' system call. */ #define HAVE_SELECT /* * Define HAVE_PTYS if the system supports pty devices. */ #define HAVE_PTYS /* Define HAVE_SOCKETS if system supports 4.2-compatible sockets. */ #define HAVE_SOCKETS /* * Define NONSYSTEM_DIR_LIBRARY to make Emacs emulate * The 4.2 opendir, etc., library functions. */ /* #define NONSYSTEM_DIR_LIBRARY */ /* Define this symbol if your system has the functions bcopy, etc. */ #define BSTRING /* subprocesses should be defined if you want to have code for asynchronous subprocesses (as used in M-x compile and M-x shell). This is generally OS dependent, and not supported under most USG systems. */ #define subprocesses /* If your system uses COFF (Common Object File Format) then define the preprocessor symbol "COFF". */ /* #define COFF */ /* define MAIL_USE_FLOCK if the mailer uses flock to interlock access to /usr/spool/mail/$USER. The alternative is that a lock file named /usr/spool/mail/$USER.lock. */ /* #define MAIL_USE_FLOCK */ /* Define CLASH_DETECTION if you want lock files to be written so that Emacs can tell instantly when you try to modify a file that someone else has modified in his Emacs. */ /* #define CLASH_DETECTION */ /* We use the Berkeley (and usg5.2.2) interface to nlist. */ #define NLIST_STRUCT /* The file containing the kernel's symbol table is called /vmunix. */ #define KERNEL_FILE "/vmunix" /* The symbol in the kernel where the load average is found is named _avenrun. */ #define LDAV_SYMBOL "_avenrun" /* Special hacks needed to make Emacs run on this system. */ /* * Make the sigsetmask function go away. Don't know what the * ramifications of this are, but doesn't seem possible to * emulate it properly anyway at this point. */ #define sigsetmask(mask) /* Null expansion */ #define sigblock(x) x /* The IRIS defines SIGIO in signal.h, but doesn't implement it. */ #undef SIGIO #define LIBS_MACHINE -lbsd -ldbm -lPW #define C_SWITCH_MACHINE -I/usr/include/bsd /* setjmp and longjmp can safely replace _setjmp and _longjmp, but they will run slower. */ #define _setjmp setjmp #define _longjmp longjmp /* On USG systems the system calls are interruptable by signals that the user program has elected to catch. Thus the system call must be retried in these cases. To handle this without massive changes in the source code, we remap the standard system call names to names for our own functions in sysdep.c that do the system call with retries. */ #define read sys_read #define open sys_open #define write sys_write #define INTERRUPTABLE_OPEN #define INTERRUPTABLE_IO /* On USG systems these have different names */ #define index strchr #define rindex strrchr /* USG systems tend to put everything declared static into the initialized data area, which becomes pure after dumping Emacs. Foil this. Emacs carefully avoids static vars inside functions. */ /* #define static */ /* Compiler bug bites on many systems when default ADDR_CORRECT is used. */ #define ADDR_CORRECT(x) (int)((char *)(x) - (char*)0) /* some errno.h's don't actually allocate the variable itself */ #define NEED_ERRNO //E*O*F s-iris3-6.h// echo x - m-iris4d.h cat > "m-iris4d.h" << '//E*O*F m-iris4d.h//' /* m- file for Iris-4D machines. Use with s-iris3-6.h Copyright (C) 1987 Free Software Foundation, Inc. This file is part of GNU Emacs. GNU Emacs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing. Refer to the GNU Emacs General Public License for full details. Everyone is granted permission to copy, modify and redistribute GNU Emacs, but only under the conditions described in the GNU Emacs General Public License. A copy of this license is supposed to have been given to you along with GNU Emacs so you can know your rights and responsibilities. It should be in a file named COPYING. Among other things, the copyright notice and this notice must be preserved on all copies. */ /* The following three symbols give information on the size of various data types. */ #define SHORTBITS 16 /* Number of bits in a short */ #define INTBITS 32 /* Number of bits in an int */ #define LONGBITS 32 /* Number of bits in a long */ /* Define BIG_ENDIAN iff lowest-numbered byte in a word is the most significant byte. */ #define BIG_ENDIAN /* Define NO_ARG_ARRAY if you cannot take the address of the first of a * group of arguments and treat it as an array of the arguments. */ #define NO_ARG_ARRAY /* Define WORD_MACHINE if addresses and such have * to be corrected before they can be used as byte counts. */ #undef WORD_MACHINE /* Define how to take a char and sign-extend into an int. On machines where char is signed, this is a no-op. */ #define SIGN_EXTEND_CHAR(c) ((signed char)(c)) /* Now define a symbol for the cpu type, if your compiler does not define it automatically: Ones defined so far include vax, m68000, ns16000, pyramid, orion, tahoe, APOLLO and many others */ #ifndef mips #define mips #endif #ifndef IRIS_4D #define IRIS_4D #endif /* Use type int rather than a union, to represent Lisp_Object */ /* This is desirable for most machines. */ #define NO_UNION_TYPE /* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend the 24-bit bit field into an int. In other words, if bit fields are always unsigned. If you use NO_UNION_TYPE, this flag does not matter. */ #define EXPLICIT_SIGN_EXTEND /* Data type of load average, as read out of kmem. */ #define LOAD_AVE_TYPE long /* This doesn't quite work on the 4D */ /* Convert that into an integer that is 100 for a load average of 1.0 */ #define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / 256.0) /* s-iris3-6.h uses /vmunix */ #undef KERNEL_FILE #define KERNEL_FILE "/unix" /* Define CANNOT_DUMP on machines where unexec does not work. Then the function dump-emacs will not be defined and temacs will do (load "loadup") automatically unless told otherwise. */ #undef CANNOT_DUMP /* Define VIRT_ADDR_VARIES if the virtual addresses of pure and impure space as loaded can vary, and even their relative order cannot be relied on. Otherwise Emacs assumes that text space precedes data space, numerically. */ /* #define VIRT_ADDR_VARIES */ /* Define C_ALLOCA if this machine does not support a true alloca and the one written in C should be used instead. Define HAVE_ALLOCA to say that the system provides a properly working alloca function and it should be used. Define neither one if an assembler-language alloca in the file alloca.s should be used. */ #define C_ALLOCA /* #define HAVE_ALLOCA */ /* Define NO_REMAP if memory segmentation makes it not work well to change the boundary between the text section and data section when Emacs is dumped. If you define this, the preloaded Lisp code will not be sharable; but that's better than failing completely. */ #define NO_REMAP /* This machine requires completely different unexec code which lives in a separate file. Specify the file name. */ #define UNEXEC unexmips.o /* * The TEXT_START here is by experiment; the DATA_START is as per the * manual (Assembly Language Programmers guide). These values can be * found at run time from &_ftext and &_fdata, though the C file which * reads these must be compile with -G 0 (prevent access to those two * 'variables' using the $gp register). However, I am lazy and don't * really want to rewrite unexec.c yet again to use this instead of * TEXT_START and DATA_START. The manual indicates that these * locations are fixed for ZMAGIC files, so I'll be lazy and do it * this way. It will probably break as of the next release of the * IRIS4D, but I've described up above how to find the new values, so * I won't feel too guilty. Note that the value returned through * _ftext is the start of text space (in this case it was 0x400140); I * presumed that the headers started at 0x400000 and was right. * * DATA_SEG_BITS forces that bit to be or'd in with any pointers which * are trying to access pure strings (as gnu-emacs only allows 24 bits * for the value field of a LISP_OBJECT). */ #define TEXT_START 0x400000 #define DATA_START 0x10000000 #define DATA_SEG_BITS 0x10000000 #undef LIBS_MACHINE #define LIBS_MACHINE -lbsd -lPW -lmld #define LIBS_DEBUG /* Define this if you have a fairly recent system, in which crt1.o and crt1.n should be used. */ #define HAVE_CRTN #ifdef HAVE_CRTN /* Must define START-FILES so that the linker can find /usr/lib/crt0.o. */ #define START_FILES pre-crt0.o /usr/lib/crt1.o #define LIB_STANDARD -lc /usr/lib/crtn.o #else #define START_FILES pre-crt0.o /usr/lib/crt0.o /* The entry-point label (start of text segment) is `start', not `__start'. */ #define DEFAULT_ENTRY_ADDRESS start #endif /* Use terminfo instead of termcap. */ #define TERMINFO /* Letter to use in finding device name of first pty, if system supports pty's. 'a' means it is /dev/ptya0 */ #undef FIRST_PTY_LETTER #define FIRST_PTY_LETTER 'q' /* Define STACK_DIRECTION for alloca.c */ #define STACK_DIRECTION -1 /* The standard definitions of these macros would work ok, but these are faster because the constants are short. */ #define XUINT(a) (((unsigned)(a) << INTBITS-VALBITS) >> INTBITS-VALBITS) #define XSET(var, type, ptr) \ ((var) = ((int)(type) << VALBITS) + (((unsigned) (ptr) << INTBITS-VALBITS) >> INTBITS-VALBITS)) #define XSETINT(a, b) XSET(a, XTYPE(a), b) #define XSETUINT(a, b) XSET(a, XTYPE(a), b) #define XSETPNTR(a, b) XSET(a, XTYPE(a), b) #define XMARKBIT(a) ((a) < 0) #define XSETMARKBIT(a,b) ((a) = ((a) & ~MARKBIT) | ((b) ? MARKBIT : 0)) #define XUNMARK(a) ((a) = (((unsigned)(a) << INTBITS-GCTYPEBITS-VALBITS) >> INTBITS-GCTYPEBITS-VALBITS)) //E*O*F m-iris4d.h// echo x - unexmips.c cat > "unexmips.c" << '//E*O*F unexmips.c//' /* Unexec for MIPS (including IRIS4D). Note that the GNU project considers support for MIPS operation a peripheral activity which should not be allowed to divert effort from development of the GNU system. Changes in this code will be installed when users send them in, but aside from that we don't plan to think about it, or about whether other Emacs maintenance might break it. Copyright (C) 1988 Free Software Foundation, Inc. NO WARRANTY BECAUSE THIS PROGRAM IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC, RICHARD M. STALLMAN AND/OR OTHER PARTIES PROVIDE THIS PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL RICHARD M. STALLMAN, THE FREE SOFTWARE FOUNDATION, INC., AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE THIS PROGRAM AS PERMITTED BELOW, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS) THIS PROGRAM, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. GENERAL PUBLIC LICENSE TO COPY 1. You may copy and distribute verbatim copies of this source file as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy a valid copyright notice "Copyright (C) 1987 Free Software Foundation, Inc."; and include following the copyright notice a verbatim copy of the above disclaimer of warranty and of this License. You may charge a distribution fee for the physical act of transferring a copy. 2. You may modify your copy or copies of this source file or any portion of it, and copy and distribute such modifications under the terms of Paragraph 1 above, provided that you also do the following: a) cause the modified files to carry prominent notices stating that you changed the files and the date of any change; and b) cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of this program or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement (except that you may choose to grant more extensive warranty protection to some or all third parties, at your option). c) You may charge a distribution fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. Mere aggregation of another unrelated program with this program (or its derivative) on a volume of a storage or distribution medium does not bring the other program under the scope of these terms. 3. You may copy and distribute this program (or a portion or derivative of it, under Paragraph 2) in object code or executable form under the terms of Paragraphs 1 and 2 above provided that you also do one of the following: a) accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Paragraphs 1 and 2 above; or, b) accompany it with a written offer, valid for at least three years, to give any third party free (except for a nominal shipping charge) a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Paragraphs 1 and 2 above; or, c) accompany it with the information you received as to where the corresponding source code may be obtained. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form alone.) For an executable file, complete source code means all the source code for all modules it contains; but, as a special exception, it need not include source code for modules which are standard libraries that accompany the operating system on which the executable file runs. 4. You may not copy, sublicense, distribute or transfer this program except as expressly provided under this License Agreement. Any attempt otherwise to copy, sublicense, distribute or transfer this program is void and your rights to use the program under this License agreement shall be automatically terminated. However, parties who have received computer software programs from you with this License Agreement will not have their licenses terminated so long as such parties remain in full compliance. 5. If you wish to incorporate parts of this program into other free programs whose distribution conditions are different, write to the Free Software Foundation at 675 Mass Ave, Cambridge, MA 02139. We have not yet worked out a simple rule that can be stated here, but we will often permit this. We will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software. In other words, you are welcome to use, share and improve this program. You are forbidden to forbid anyone else to use, share and improve what you give them. Help stamp out software-hoarding! */ #include "config.h" #include #include #include #include #include #include #include #include #include #ifdef IRIS_4D #include "getpagesize.h" #endif static void fatal_unexec (); #define READ(_fd, _buffer, _size, _error_message, _error_arg) \ errno = EEOF; \ if (read (_fd, _buffer, _size) != _size) \ fatal_unexec (_error_message, _error_arg); #define WRITE(_fd, _buffer, _size, _error_message, _error_arg) \ if (write (_fd, _buffer, _size) != _size) \ fatal_unexec (_error_message, _error_arg); #define SEEK(_fd, _position, _error_message, _error_arg) \ errno = EEOF; \ if (lseek (_fd, _position, L_SET) != _position) \ fatal_unexec (_error_message, _error_arg); extern int errno; extern int sys_nerr; extern char *sys_errlist[]; #define EEOF -1 static struct scnhdr *text_section; static struct scnhdr *init_section; static struct scnhdr *finit_section; static struct scnhdr *rdata_section; static struct scnhdr *data_section; static struct scnhdr *lit8_section; static struct scnhdr *lit4_section; static struct scnhdr *sdata_section; static struct scnhdr *sbss_section; static struct scnhdr *bss_section; struct headers { struct filehdr fhdr; struct aouthdr aout; struct scnhdr section[10]; }; /* Define name of label for entry point for the dumped executable. */ #ifndef DEFAULT_ENTRY_ADDRESS #define DEFAULT_ENTRY_ADDRESS __start #endif unexec (new_name, a_name, data_start, bss_start, entry_address) char *new_name, *a_name; unsigned data_start, bss_start, entry_address; { int new, old; int pagesize, brk; int newsyms, symrel; int nread; struct headers hdr; int i; int vaddr, scnptr; #define BUFSIZE 8192 char buffer[BUFSIZE]; old = open (a_name, O_RDONLY, 0); if (old < 0) fatal_unexec ("opening %s", a_name); new = creat (new_name, 0666); if (new < 0) fatal_unexec ("creating %s", new_name); hdr = *((struct headers *)TEXT_START); if (hdr.fhdr.f_magic != MIPSELMAGIC && hdr.fhdr.f_magic != MIPSEBMAGIC) { fprintf (stderr, "unexec: input file magic number is %x, not %x or %x.\n", hdr.fhdr.f_magic, MIPSELMAGIC, MIPSEBMAGIC); exit (1); } if (hdr.fhdr.f_opthdr != sizeof (hdr.aout)) { fprintf (stderr, "unexec: input a.out header is %d bytes, not %d.\n", hdr.fhdr.f_opthdr, sizeof (hdr.aout)); exit (1); } if (hdr.aout.magic != ZMAGIC) { fprintf (stderr, "unexec: input file a.out magic number is %o, not %o.\n", hdr.aout.magic, ZMAGIC); exit (1); } #define CHECK_SCNHDR(ptr, name, flags) \ if (strcmp (hdr.section[i].s_name, name) == 0) \ { \ if (hdr.section[i].s_flags != flags) \ fprintf (stderr, "unexec: %x flags (%x expected) in %s section.\n", \ hdr.section[i].s_flags, flags, name); \ ptr = hdr.section + i; \ i += 1; \ } \ else \ ptr = NULL; i = 0; CHECK_SCNHDR (text_section, _TEXT, STYP_TEXT); CHECK_SCNHDR (init_section, _INIT, STYP_INIT); CHECK_SCNHDR (rdata_section, _RDATA, STYP_RDATA); CHECK_SCNHDR (data_section, _DATA, STYP_DATA); #ifdef _LIT8 CHECK_SCNHDR (lit8_section, _LIT8, STYP_LIT8); CHECK_SCNHDR (lit4_section, _LIT4, STYP_LIT4); #endif /* _LIT8 */ CHECK_SCNHDR (sdata_section, _SDATA, STYP_SDATA); CHECK_SCNHDR (sbss_section, _SBSS, STYP_SBSS); CHECK_SCNHDR (bss_section, _BSS, STYP_BSS); if (i != hdr.fhdr.f_nscns) fprintf (stderr, "unexec: %d sections found instead of %d.\n", i, hdr.fhdr.f_nscns); pagesize = getpagesize (); brk = (sbrk (0) + pagesize - 1) & (-pagesize); hdr.aout.dsize = brk - DATA_START; hdr.aout.bsize = 0; if (entry_address == 0) { extern DEFAULT_ENTRY_ADDRESS (); hdr.aout.entry = (unsigned)DEFAULT_ENTRY_ADDRESS; } else hdr.aout.entry = entry_address; hdr.aout.bss_start = hdr.aout.data_start + hdr.aout.dsize; rdata_section->s_size = data_start - DATA_START; data_section->s_vaddr = data_start; data_section->s_paddr = data_start; data_section->s_size = brk - DATA_START; data_section->s_scnptr = rdata_section->s_scnptr + rdata_section->s_size; vaddr = data_section->s_vaddr + data_section->s_size; scnptr = data_section->s_scnptr + data_section->s_size; if (lit8_section != NULL) { lit8_section->s_vaddr = vaddr; lit8_section->s_paddr = vaddr; lit8_section->s_size = 0; lit8_section->s_scnptr = scnptr; } if (lit4_section != NULL) { lit4_section->s_vaddr = vaddr; lit4_section->s_paddr = vaddr; lit4_section->s_size = 0; lit4_section->s_scnptr = scnptr; } if (sdata_section != NULL) { sdata_section->s_vaddr = vaddr; sdata_section->s_paddr = vaddr; sdata_section->s_size = 0; sdata_section->s_scnptr = scnptr; } if (sbss_section != NULL) { sbss_section->s_vaddr = vaddr; sbss_section->s_paddr = vaddr; sbss_section->s_size = 0; sbss_section->s_scnptr = scnptr; } if (bss_section != NULL) { bss_section->s_vaddr = vaddr; bss_section->s_paddr = vaddr; bss_section->s_size = 0; bss_section->s_scnptr = scnptr; } WRITE (new, TEXT_START, hdr.aout.tsize, "writing text section to %s", new_name); WRITE (new, DATA_START, hdr.aout.dsize, "writing text section to %s", new_name); SEEK (old, hdr.fhdr.f_symptr, "seeking to start of symbols in %s", a_name); errno = EEOF; nread = read (old, buffer, BUFSIZE); if (nread < sizeof (HDRR)) fatal_unexec ("reading symbols from %s", a_name); #define symhdr ((pHDRR)buffer) newsyms = hdr.aout.tsize + hdr.aout.dsize; symrel = newsyms - hdr.fhdr.f_symptr; hdr.fhdr.f_symptr = newsyms; symhdr->cbLineOffset += symrel; symhdr->cbDnOffset += symrel; symhdr->cbPdOffset += symrel; symhdr->cbSymOffset += symrel; symhdr->cbOptOffset += symrel; symhdr->cbAuxOffset += symrel; symhdr->cbSsOffset += symrel; symhdr->cbSsExtOffset += symrel; symhdr->cbFdOffset += symrel; symhdr->cbRfdOffset += symrel; symhdr->cbExtOffset += symrel; #undef symhdr do { if (write (new, buffer, nread) != nread) fatal_unexec ("writing symbols to %s", new_name); nread = read (old, buffer, BUFSIZE); if (nread < 0) fatal_unexec ("reading symbols from %s", a_name); #undef BUFSIZE } while (nread != 0); SEEK (new, 0, "seeking to start of header in %s", new_name); WRITE (new, &hdr, sizeof (hdr), "writing header of %s", new_name); close (old); close (new); mark_x (new_name); } /* * mark_x * * After succesfully building the new a.out, mark it executable */ static mark_x (name) char *name; { struct stat sbuf; int um = umask (777); umask (um); if (stat (name, &sbuf) < 0) fatal_unexec ("getting protection on %s", name); sbuf.st_mode |= 0111 & ~um; if (chmod (name, sbuf.st_mode) < 0) fatal_unexec ("setting protection on %s", name); } static void fatal_unexec (s, va_alist) va_dcl { va_list ap; if (errno == EEOF) fputs ("unexec: unexpected end of file, ", stderr); else if (errno < sys_nerr) fprintf (stderr, "unexec: %s, ", sys_errlist[errno]); else fprintf (stderr, "unexec: error code %d, ", errno); va_start (ap); _doprnt (s, ap, stderr); fputs (".\n", stderr); exit (1); } //E*O*F unexmips.c// exit 0 +----------------------------------------------------------------------+ |Thomas Russo | russo@chaos.utexas.edu | |Center for Nonlinear Dynamics, University of Texas at Austin | +----------------------------------------------------------------------+   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17166; 10 Apr 89 16:11 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa16808; 10 Apr 89 16:01 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16783; 10 Apr 89 15:48 EDT Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa02593; 10 Apr 89 15:39 EDT Received: from unipress.UUCP by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP id AA03974; Mon, 10 Apr 89 15:33:20 EDT Received: by unipress.com (3.2/SMI-3.0DEV3) id AA10687; Mon, 10 Apr 89 14:47:11 EDT Date: Mon, 10 Apr 89 14:47:11 EDT From: required by law Message-Id: <8904101847.AA10687@unipress.com> To: info-iris@BRL.MIL Subject: Re: VMS utilities (command line editing) If you use Emacs, you can run a command-line-driven program like a shell or dbx in an Emacs "interactive process" window. In UniPress Emacs (which is available as an option from SGI) these windows behave just like a dumb terminal (erase, kill, etc. work) except that you can recall and edit previous command lines, and all sorts of other things. GnuEmacs probably does this too, or can be hacked to do so. And you can use the arrow keys, too :-). Mike Gallaher UniPress Software   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18753; 10 Apr 89 19:18 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18696; 10 Apr 89 19:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18669; 10 Apr 89 18:50 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01240; 10 Apr 89 18:39 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA23818; Mon, 10 Apr 89 15:22:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 89 18:24:36 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Experiences with 4D/2xx as timesharing systems? Message-Id: <30349@sgi.SGI.COM> References: <89Apr9.160219edt.38129@neat.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Apr9.160219edt.38129@neat.ai.toronto.edu>, rayan@ai.toronto.edu (Rayan Zachariassen) writes: > Our major worry (in the fine SGI tradition...) is with the software, in > particular we consider any System V based box to start out with a negative > (this is our reality not our religion). We understand SGI is committed to SV. Sounds like religion - for SGI it's commercial reality, as it is for every other successful computer vendor. Oh well, why tilt at windmills? > Does this mean they will track AT&T SV releases directly, or that whatever > SV-based OS that MIPS comes up with will shortly appear on the 4Ds? IRIX != UMIPS. We are committed to tracking AT&T releases. IRIX currently is at V.3.1, with V.3.2 late this year. We will implement V.4 as expediently as possible. We will also consider any major OSF/1 feature which adds value to the system. > The filesystem is a worry. We're happy it isn't SV but unhappy at the > apparent gratuitous incompatibility with the BSD F^nS. Our tools are > unlikely to work, right? It also seems like a less robust design. Will it > go away in favour of something else that is largely compatible with > F^nS ((Fat)Fast File System)? I note that MIPS ships FFS with their > rice-computer OS, how come SGI seems to be waiting for SVR4 to do the same? Why worry? The SGI ExtentFileSystem is >faster< than the BSD FFS. For instance, on the Jim Barton extra-special-whizzy single-and-multi-process blow-out-the-buffer-cache benchmark (substantiated by the AIM II disk benchmark and other tests), UMIPS 3.0 FFS on the M/120 runs about 15% slower than IRIX 3.0 EFS on the >exact same hardware<. And we've put alot of work into EFS since the 3.0 release ... As to robust, it also duplicates superblocks, has cylinder groups, bitmaps and the like, but it can use >all< your disk fairly effectively (try that with FFS!) I'll be happy to send you a copy of the benchmark, as well. > During testing on the personal iris, some anomalies showed up that could > be explained by the scheduler or VM being tuned for a single-user workstation > environment. For example running a certain (non-graphics) program would > cause lost ether packets and horrible response time on the iris, but the > same program is apparently wellbehaved on other machines. Similarly, logging > out of the PI causes lost packets. Anyone experienced similar anomalies > on the 4D/2xx? Anyone using them for timesharing? Main problem is with the window manager, which is pretty heavyweight. For all that nice display and all, it takes lots of memory, which has to be fought over with the application you are running in a limited memory system. If you really aren't interested in graphics, don't start the window manager, and the performance will be very good (you >said< server, right?). Try running your same application on a Sun 4 with NeWS and 8Mb of memory (assuming you can get Sun to sell you one) and amuse yourself with the results. As to the lost packets, I believe that this bug is fixed in the latest release available to the field. > How does the fine-grained multiprocessing support (threads libraries, compiler > support etc.) differ qualitatively from other implementations (MachOS, > Sequent, Encore, Sun)? Its better, of course! :-). The thread implementation has been published in USENIX proceedings, etc.. It provides a much more natural model for multi threaded applications than any other model I know of. We also support a layer of synchronization using spinlocks and semaphores that religiously avoids kernel interaction. Remember that syncrhonization latency is the chief problem in getting high performance from fine-grained parallelism. On top of this are some of our primitives, plus the Sequent m_* routines for simple parallel programming. In the environment, we support a multi-process asynchronous debugger which works on normal and "threaded" processes (Sun, Mach don't!). The profiler handles a threaded process correctly. All this is integrated with the normal high-performance MIPS compilers. > Can one use a 4D to serve root and swap for a SunOS 4.0 workstation? I assume so. We are currently at NFS 3.2, so if that's all it needs, it should work. > How is the hardware reliability on the 4Ds? Reliability is good. We publish a demonstrated MTBF number for all machines. PowerSeries products are rated for at least 6000 hours. > Any other pertinent comments from customers are welcome. The kind of > configuration that is of interest is a 4D/240S with minimal extra stuff > (small SCSI, cartridge), to which we'll add the storage subsystem w/ a > few gigs of disk. Users would have access via the ether. In the > timesharing application we would want to potentially support at least > twice the work our Sun4/280Ss are being asked to do (which is 30 users > + 30 workstations, mostly light activity but occasional developers and > long-running and/or large jobs) which it does well when it works. You may want to buy the storage from us. We currently support >10Gb of storage on a single machine through large-capacity SMD drives. Since 4 processors with twice the power of a Sun 4 are in the same box, I would think the load you describe would be easily handled. In my lab, we use a 4D/120 with 2 extra processors (an "unofficial" 4D/140). We have a 150Mb SCSI cartridge, 9-track, E-net, etc. The disk configuration, from /etc/motd, is: Maddog 4D/140S IRIX 4D-3.2A (Alpha 7) ASD Compute/File Server =============================================================================== CDC Sabre 9720-1230 1.2Gb SMD xyl1d1s0 / xyl1d1s6 /usr build tree Fuji Eagle 2351 400Mb SMD xyl1d2s1 /usr/tmp xyl1d2s6 /f user data Toshiba MK156FB 156Mb SCSI dks0d1s7 /e MIPS source Fuji Eagle 2351 400Mb SMD xyl1d0s7 /d user data Hitachi 514-38 380Mb ESDI ips0d3s7 /g user data Hitachi 512-17 150Mb ESDI ips0d0s7 /vme0 BRL, MIPS bench Hitachi DK514C 380Mb SCSI dks0d2s7 /vme0/jmb/other user data =======================> 3.1 Gb and counting <================================= This machine is used by > 30 workstations and lot's of users, performs as a build machine, as well as supporting our development environment, with lots of NFS filesystems, constant E-net traffic and more. Since a 4D/240 is twice as fast as this machine, you should have no problems. > Please REPLY BY MAIL! I will summarize if interesting info appears. I thought the net might be interested in the quasi-official SGI answer. > Thanks, > > rayan > > AI/NA/Theory, DCS, U of Toronto My pleasure. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19294; 10 Apr 89 21:43 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19241; 10 Apr 89 21:32 EDT Received: by VMB.BRL.MIL id ac19229; 10 Apr 89 21:16 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18662; 10 Apr 89 18:50 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01199; 10 Apr 89 18:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA23887; Mon, 10 Apr 89 15:23:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 89 21:12:28 GMT From: Stuart Crawford Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300 Subject: 3D glasses anyone? Message-Id: <7512@zodiac.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've written some software to display objects in a form suitable for viewing with the old type of 3D glasses (one red lens, one green lens). Does anyone know of a local (SF Bay area) source for the purchase of such glasses? Thanks in advance, - Stuart   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19294; 10 Apr 89 21:43 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id ab19241; 10 Apr 89 21:32 EDT Received: by VMB.BRL.MIL id ad19229; 10 Apr 89 21:16 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab18662; 10 Apr 89 18:50 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa01202; 10 Apr 89 18:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA23877; Mon, 10 Apr 89 15:22: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 Apr 89 21:08:54 GMT From: Stuart Crawford Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300 Subject: What happened to clip? Message-Id: <7511@zodiac.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There used to be a nifty little program called clip, located in /usr/sbin. Clip allowed the user to rubberband a rectangle on the screen, and then created a new window whose contents were the bits cobtained in the rectangle the user outlined. We recently upgraded to 3.1 and, to my dismay, clip no longer seems to be provided on the distribution tapes. Does anyone know if it is still available? Thanks, - stuart - Stuart   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19363; 10 Apr 89 22:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac19294; 10 Apr 89 21:49 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19288; 10 Apr 89 21:42 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa03433; 10 Apr 89 21:30 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA02699; Mon, 10 Apr 89 18:06:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 89 00:53:16 GMT From: Foxbat Organization: Boston Univ. Computer Graphics Lab Subject: setvaluator and queueing devices Message-Id: <29422@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I've done a 'setvaluator( DIAL0, 0, 0, 360 )' but this only maps DIAL0's values between 0 and 360 when I have not done a 'qdevice( DIAL0 )'. When I do queue the device I get values between 0 and some huge integer. On a related note...is there any way to tell a dial to wrap around when it has reached a max/min value? Thanks. Tim tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26784; 11 Apr 89 11:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26430; 11 Apr 89 10:51 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa26218; 11 Apr 89 10:35 EDT Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa15278; 11 Apr 89 10:23 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA01362; Tue, 11 Apr 89 10:18:06 EDT Received: by buita.bu.edu (3.2/4.7) id AA09875; Tue, 11 Apr 89 10:20:08 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA19003; Mon, 10 Apr 89 17:11:16 EDT Date: Mon, 10 Apr 89 17:11:16 EDT From: Joe Ilacqua Message-Id: <8904102111.AA19003@adt.uucp> To: info-iris@BRL.MIL Subject: Re: GNU Emacs for 4D machines If after you add the files to make emacs work on the 4D you make the folowing changes, you will get Job Control. In m-iris4d.h add the line: #define killpg( pgrp, sig ) (kill( -(pgrp), (sig) )) as is found in m-ibmrt-aix.h And in sysdep.c change line 500 from: #ifdef BSD killpg (getpgrp (0), SIGTSTP); to #if defined(BSD) || defined(IRIS_4D) killpg (getpgrp (0), SIGTSTP); I belive (and could be wrong) that the right files for the 4D (with out the about patch *sigh*) are in the 18.52 dist. Joe Ilacqua   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25374; 11 Apr 89 9:49 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24895; 11 Apr 89 9:39 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24751; 11 Apr 89 9:18 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa12836; 11 Apr 89 9:10 EDT Received: Tue, 11 Apr 89 09:11:03 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 11 Apr 89 09:11:03 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8904111711.AA19219@aero4.larc.nasa.gov> To: rayan@ai.toronto.edu Subject: Re: Experiences with 4D/2xx as timesharing systems? Cc: info-iris@BRL.MIL Aren't there any other companies with multiprocessors? I would find the pains and hassle of having a SGI machine not worth the trouble. I like UNIX and 4BSD, but don't care for System V. AT&T needs to learn a lot from Berkeley. What about Connection, Convex, and others? Those are multiprocessor machines. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27355; 11 Apr 89 11:43 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa25810; 11 Apr 89 10:20 EDT Received: from NUSC-WPN.ARPA by VMB.BRL.MIL id aa25746; 11 Apr 89 10:08 EDT Date: 11 Apr 89 09:58:00 EDT From: "V36B::POTTER" Subject: To: "info-iris" Reply-To: "V36B::POTTER" Message-ID: <8904111009.aa25746@VMB.BRL.MIL> Hey IRIS folk, We are thinking of producing audio output from some signals that we have generated. Now, we could design a board that performed all of the filtering, modulating, and d/a'ing or we could buy a MAC (well you get the idea). Now, in the before times, SGI supported an audio board. Does SGI still support that audio board (oh, by the way I am using a 4D/60T)? If so, could you fill me in on cost? and some feature and performance data? Thanks, Steve Swenson SWENSON@NUSC-WPN.ARPA ------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29478; 11 Apr 89 13:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab28588; 11 Apr 89 13:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab28546; 11 Apr 89 13:14 EDT Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa18943; 11 Apr 89 12:59 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA05264; Tue, 11 Apr 89 12:53:39 EDT Received: by buita.bu.edu (3.2/4.7) id AA14233; Tue, 11 Apr 89 12:55:43 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA05578; Tue, 11 Apr 89 11:20:09 EDT Date: Tue, 11 Apr 89 11:20:09 EDT From: jim frost Message-Id: <8904111520.AA05578@adt.uucp> To: info-iris@BRL.MIL Subject: Re: Experiences with 4D/2xx as timesharing systems? >In article <89Apr9.160219edt.38129@neat.ai.toronto.edu>, rayan@ai.toronto.edu (Rayan Zachariassen) writes: >>We understand SGI is committed to SV. > >Sounds like religion - for SGI it's commercial reality, as it is for every >other successful computer vendor. DEC? Seriously, not every vendor who supported SysV was successful, nor (more to the point) does every successful vendor support SysV, even throwing out those companies who don't care about UNIX at all. Most of the very successful vendors support SysV but add a lot of the BSD functionality -- job control and sockets are the biggest ones; almost everything else just affects performance. >We will also consider any major OSF/1 feature which adds value >to the system. I don't think you'll see anything in OSF/1, which is going to be pretty vanilla IBM AIX; OSF/2 is supposed to have a lot of new functionality but that's vaporware for awhile. I'll be surprised to see OSF/1 out before this time next year no matter what the official word is. >The SGI ExtentFileSystem is >faster< than the BSD FFS. Could we get some info on your benchmark? I'm particularly interested in how each FS was tuned. I tend to believe the results considering the FS throughput our SGI's have, but tuning can be everything. I'd also like to know what you do to keep fragmentation down when the FS fills up; I'm curious. Our biggest complaint about SGI performance is that it degrades substantially over time. I'm fairly certain that this is a VM problem since it happens with every large application I've run, including some which have pretty clean usage and do *not* have this problem under 4.3 BSD. The system returns to its former spunkiness after reboot. I might expect that it's related to 4Sight except that logout/login doesn't correct the problem. Speaking of 4Sight, it would be very useful to some people if SGI would provide a method of accessing graphics without the window manager. 4Sight eats up a lot of memory ("heavyweight" as you say) as well as some graphics resources (particularly bitplanes) which applications could make use of. jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01437; 11 Apr 89 14:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28588; 11 Apr 89 13:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28546; 11 Apr 89 13:14 EDT Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa18942; 11 Apr 89 12:58 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA05260; Tue, 11 Apr 89 12:53:36 EDT Received: by buita.bu.edu (3.2/4.7) id AA14230; Tue, 11 Apr 89 12:55:40 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA05043; Tue, 11 Apr 89 10:45:57 EDT Date: Tue, 11 Apr 89 10:45:57 EDT From: jim frost Message-Id: <8904111445.AA05043@adt.uucp> To: info-iris@BRL.MIL Subject: Re: VMS utilities (command line editing) >In UniPress Emacs >(which is available as an option from SGI) these windows behave just like >a dumb terminal (erase, kill, etc. work) except that you can recall >and edit previous command lines, and all sorts of other things. >GnuEmacs probably does this too, or can be hacked to do so. >And you can use the arrow keys, too :-). It's not a bad idea to think of GNU Emacs as a substantial superset of UniPress, especially considering the number of outside contributors who have added functionality. GNU does support sub-shells, vt100 terminal emulation in a window, lisp shells (as well as its own interactive lisp), etc. And hanoi to nine levels if you're bored. What are the downsides of using Emacs as a shell? Emacs strips out a lot of control sequences which are necessary to many programs. You can run things without the emacs window but it doesn't quite work like a shell. This could be hacked pretty easily though. Emacs, especially GNU Emacs, is also extremely memory-hungry. There are installations I know of which refuse to allow any emacs or emacs-like editor on their system because of resource usage. But most of them also believe that VMS is reality so it might just be a mindset. Personally I only use emacs as an editor/compile environment which it is particularly well-suited for. A feature-for-feature comparison of GNU emacs versus any other editor is rather interesting, but most other editors are not completely extensible or have as many programmers actively creating newer, funkier additions to it. Speaking of GNU, and more in keeping with the info-iris theme, the recent posting to get GNU Emacs running on the 4D's didn't configure Emacs to believe in job control which the 4D's now support and which Emacs happily handles. If you don't want to figure out how to enable it you can talk to spike@bu-it.bu.edu who can tell you. Happy hacking, jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02517; 11 Apr 89 14:30 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00276; 11 Apr 89 13:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00264; 11 Apr 89 13:50 EDT Received: from UCBVAX.Berkeley.EDU by SMOKE.BRL.MIL id aa19617; 11 Apr 89 13:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA17697; Tue, 11 Apr 89 10:06:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 89 16:24:13 GMT From: Jean-Francois Lamy Organization: Department of Computer Science, University of Toronto Subject: Re: Experiences with 4D/2xx as timesharing systems? Message-Id: <89Apr11.122420edt.38132@neat.ai.toronto.edu> References: <89Apr9.160219edt.38129@neat.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How does one dump/restore an SGI server with about 4Gigs? (we currently have essentially unattended dumps at night over the network, using the Berkeley rdump/rrestore combo, to a pair of Exabytes). Is anything remotely similar possible with SGI machines?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03894; 11 Apr 89 15:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02517; 11 Apr 89 14:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02071; 11 Apr 89 14:28 EDT Received: from BU-IT.BU.EDU by SMOKE.BRL.MIL id aa20535; 11 Apr 89 14:16 EDT Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA07693; Tue, 11 Apr 89 14:11:00 EDT Received: by buita.bu.edu (3.2/4.7) id AA16187; Tue, 11 Apr 89 14:13:03 EDT Received: by adt.uucp (3.2/SMI-3.2) id AA07491; Tue, 11 Apr 89 13:16:49 EDT Date: Tue, 11 Apr 89 13:16:49 EDT From: jim frost Message-Id: <8904111716.AA07491@adt.uucp> To: rayan@ai.toronto.edu, info-iris@BRL.MIL Subject: Re: Experiences with 4D/2xx as timesharing systems? > Aren't there any other companies with multiprocessors? Sure. Sequent, Encore, and IBM come to mind immediately. SGI beats all of them in price/performance although the Encore is set up for heavy use, not as a workstation, and performs very well as a large multiuser machine, making it very competitive in that kind of market. I hear bad things about Sequent reliability and IBM <-> UNIX still strikes me as an oxymoron even with AIX and OSF so you can basically throw them out. What it comes down to is "what are you looking for". SGI beats them all in the workstation and superworkstation market, no questions asked, competitive even without the geometry engine. Even though it's SysV, it's not very SysV and many BSD programs can be built with few changes. You can configure a 4D as multiuser but it probably won't support many. Encore is not in the workstation market, but instead has machines which support hundreds of online users in a very cost-effective manner. Unfortunately their best market is education where there isn't always a lot of money to be had. There are probably other companies which have similar products but I haven't dealt with them at all. Apologies if I missed any big ones. >What about Connection, Convex, and others? >Those are multiprocessor machines. I think you can throw out Connection. It's not a multiprocessor machine like you're accustomed to and the entire design of the system is such that it probably won't ever support UNIX (makes for good reading though -- twelve dimensional architecture). It's really a great thing for heavy-duty parallel computation tasks in batch mode, not interactive or multiuser. jim frost madd@bu-it.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07701; 12 Apr 89 1:37 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07499; 12 Apr 89 0:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07380; 12 Apr 89 0:05 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29362; 12 Apr 89 0:03 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA21287; Tue, 11 Apr 89 20:42: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: 12 Apr 89 00:11:30 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Experiences with 4D/2xx as timesharing systems? Message-Id: <30483@sgi.SGI.COM> References: <89Apr9.160219edt.38129@neat.ai.toronto.edu>, <89Apr11.122420edt.38132@neat.ai.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Apr11.122420edt.38132@neat.ai.toronto.edu>, lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: > How does one dump/restore an SGI server with about 4Gigs? > (we currently have essentially unattended dumps at night over the network, > using the Berkeley rdump/rrestore combo, to a pair of Exabytes). Is > anything remotely similar possible with SGI machines? You can buy officially supported Exabyte-style drives from SGI, and put your own 2Gb tapes in them. The 'bru' command should support dump/restore to this device, as well as tar and cpio. One of my personal favorites to save tape and speed the backup is to compress the data, for example: find . -newer lastbackup -print | cpio -oc | compress -v -f |\ rsh remote "dd bs=16k of=/dev/tape" Compression is slow, but Exabyte tape drives are slower, so there you are ... -- jmb