Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/13/88)
SUN-SPOTS DIGEST Thursday, 12 May 1988 Volume 6 : Issue 84 Today's Topics: Re: Format for byte encoded rasterfiles (2) Re: complex arithmetic in C on the Sun without C++ or NAG Re: A SCL floating-point problem Re: how to tell if you're running under suntools Re: NFS 'df' oddities (was Re: Mac II Ethernet Boards) Re: gammontool Re: BIND on a Sun 3/180 with 3.5 Xy-451 firmware (BEWARE!) Fuji-2372 disks Patch to calctool cheap SCSI drives? Is there a mesg/suntools bug ? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Mon, 9 May 88 16:14:21 MDT From: jpm%green@lanl.gov (Pat McGee) Subject: Re: Format for byte encoded rasterfiles (1) I needed to know this a couple of months ago, and didn't have the sense to ask sun-spots. So, I got some files and figured it out for myself. The format is composed of many sequences of variable length records. Each record may be 1, 2, or 3 bytes long. If the first byte is not 0x80, the record is one byte long, and contains a pixel value. Output 1 pixel of that value. If the first byte is 0x80 and the second byte is zero, the record is two bytes long. Output 1 pixel with value 0x80. If the first byte is 0x80, and the second byte is not zero, the record is three bytes long. The second byte is a count and the third byte is a value. Output (count+1) pixels of that value. A run is not terminated at the end of a scan line. So, if there are three lines of red in a picture 100 pixels wide, the first run will be 0x80 0xff 0x(red), and the second will be 0x80 0x2b 0x(red). Pat McGee, jpm@lanl.gov ------------------------------ Date: Mon, 9 May 88 17:17:07 EDT From: gamin%amadeus.UUCP@larry.mcrcim.mcgill.edu (Martin Boyer) Subject: Re: Format for byte encoded rasterfiles (2) sow@cad.luth.se (Sven-Ove Westberg) and JDEBE@MTUS5.BITNET (John de Beaubien) want to know the format of Suns runlength encoding for rasterfiles. At one point, I wrote a quick filter to decode such files (I didn't want the overhead of the pixrect library). It took a while to find out (at the time, there was a bug in pr_dump with RT_BYTE_ENCODED) but it paid off, and I got something that is easily twice as fast as /usr/lib/rasfilters/convert.2. The rules are the following: 1. Encoding is byte per byte (regardless of the depth of the image) 2. Lengths of less than 3 are not encoded. 3. Lengths of 3 and more duplicate bytes are encoded as follows: for n consecutive "YZ" bytes, write out 0x80 (n-1) "YZ" so: YZ YZ YZ YZ => 0x80 0x03 0xYZ exception: 0x80 (alone) => 0x80 0x00 (note missing byte) and NOT 0x80 0x00 0x80 but 0x80 0x80 => 0x80 0x01 0x80 (follows general rule) Even better, here is a function that does the decoding: (I don't have any for encoding) /* First argument is a pointer to the encoded array of pixels. Second is a pointer to enough space for the decoded array of pixels, which will be ras_width (rounded up to a short) * ras_heigth * ras_depth long Third is length of input (in bytes) (ras_length). Returns length of decoded output, can be used to verify correct encoding/decoding. */ unsigned int decode_image(inpix, outpix, lin) register unsigned char *inpix, *outpix; unsigned int lin; { unsigned char value; unsigned int n; unsigned char *outpix_0; outpix_0 = outpix; while (lin) { if ((value = *inpix++) == 0x80) { if ((n = *inpix++) == 0) { *outpix++ = 0x80; /* special: 0x80 0x00 ==> 0x80 */ lin -= 2; } else { for (value = *inpix++, n++; n; n--) *outpix++ = value; lin -= 3; } } else { *outpix++ = value; lin--; } } return (outpix - outpix_0); } It worked for at least a year on all sorts of images without a burp. Good luck! Martin Boyer amadeus!gamin@mcgill-vision.uucp Institut de recherche d'Hydro-Quebec sun!sunlegende!amadeus!gamin Varennes, QC, Canada J0L 2P0 +1 514 652-8136 [[ I hope that everyone now understands the format. I'll probably suppress future messages about this unless they really add something to the discussion. My thanks to everyone for sending in their discoveries and algorithms/functions. It has been a tremendous help to all concerned. --wnl ]] ------------------------------ Date: Mon, 9 May 88 23:00:42 EDT From: Mike Muuss <mike@brl.arpa> Subject: Re: complex arithmetic in C on the Sun without C++ or NAG A very small part of the BRL CAD Package is a set of header files and library routines to implement complex arithmetic in C, based on code originally written by Doug Gwyn which has been performance improved. If you would like a copy of the whole CAD Package, please let me know, and I can post a message detailing what it does and how to get it. If you would just like the complex math software, that is small enough that I could just E-mail it to you. Best, -Mike Muuss ArpaNet: <Mike @ BRL.ARPA> Postal: Mike Muuss Leader, Advanced Computer Systems Team Ballistic Research Laboratory APG, MD 21005-5066 ------------------------------ Date: Mon, 09 May 88 19:51:27 PDT From: franz!akbar!layer@ucbarpa.berkeley.edu (Kevin Layer) Subject: Re: A SCL floating-point problem >> From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory) >> >> The bench: >> (defun float-compute (n) >> (declare (optimize speed)) >> (declare (type single-float z)) >> (declare (fixnum i)) >> (let ((z 0)) >> (dotimes (i n) >> (setq z (+ (* z z z) >> (/ z 2500.55) >> (* z 23.44 99.444) >> (* z 555.555 z 444.0)) >> ) >> ) >> z) >> ) ;float-compute First, there are two things wrong with your program: 1. the declarations are in the wrong places. Specifically, the declarations for `z' and `i' need to be lexically in the forms which use them. CLtL, page 154: "... bindings apply only to the bindings made by the form at the head of whose body they appear." 2. z is initialized to `0' and it is declared to hold a single-float!! This is incorrect!! Here is the fixed program: (defun float-compute (n) (declare (optimize speed) (type fixnum n)) (let ((z 0.0)) (declare (type single-float z)) (dotimes (i n) (declare (type fixnum i)) (setq z (+ (* z z z) (/ z 2500.55) (* z 23.44 99.444) (* z 555.555 z 444.0)))) z)) and here is a run of it in Allegro CL (3.0) on a SUN3: <cl> (time (float-compute 10000)) cpu time (non-gc) 633 msec user, 16 msec system cpu time (gc) 0 msec user, 0 msec system cpu time (total) 633 msec user, 16 msec system real time 620 msec 0.0 <cl> Cheers, Kevin Layer Franz Inc. layer%franz.uucp@Berkeley.EDU or ucbvax!franz!layer ------------------------------ Date: 9 May 88 11:40:25 GMT From: Ian Phillipps <mcvax!camcon!igp@uunet.uu.net> Subject: Re: how to tell if you're running under suntools Reference: v6n66 > Mike Khaw: > (b) According to Sun s/w support, the env. variable WINDOW_PARENT is > always set if you're running under suntools, so you could > if ($?WINDOW_PARENT) then > echo "running under suntools" > endif The example (b) doesn't handle rlogins. We get round it here by relying on the propogation of TERM across the login, so my .{cshrc,login} files have things like if ( if ( $term == sun && `tty` == /dev/console ) exec suntools if ($term != sun ) alias ... UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps or: igp@camcon.uucp | Science Park, Milton Road |----------------- Phone: +44 223 358855 | Cambridge CB4 4DW, England | ------------------------------ Date: 10 May 88 02:54:04 GMT From: david@elroy.jpl.nasa.gov (David Robinson) Subject: Re: NFS 'df' oddities (was Re: Mac II Ethernet Boards) Reference: v6n75 > From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) > In article <4476@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >There are a few bugs remaining in A/UX NFS, but nothing serious. Try a > >"df -i" from a Sun that has mounted a Mac's disk; you get gibberish. > My Suns do this among themselves with NFS-mounted filesystems, I suspect > that 'df' needs to be thinkg about vnodes as well as inodes, unless anyone > can think of a more general solution. The problem lies in the NFS protocol itself. There is no concept of number of inodes in the statfs RPC call. Currently it appears that df calls statfs(2) and prints the results. The NFS part of the VFS statfs call does not write into the f_files and f_ffree part of the statfs structure leaving you with whatever happened to be in memory at that point (typically junk). A simple fix would be to modify the nfs_statfs code to zero the two fields, you would get no more information but it would look nicer. David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP ------------------------------ Date: Tue, 10 May 88 10:28:19 CDT From: brewer%antares@anl-mcs.arpa Subject: Re: gammontool I thought it was just me. It's nice to know that I wasn't imagening it. I thought I had become a sore loser. Like the time that I "rolled" double sixes three times in a roll when I couldn't use them. (Coincidence?) And whenever there is only one roll that gammontool can use, it almost always seems to get it. Makes you wonder. Orlie Brewer brewer@anl-mcs.arpa ------------------------------ Date: 10 May 88 17:00:06 GMT From: woods@handies.ucar.edu (Greg Woods) Subject: Re: BIND on a Sun 3/180 with 3.5 I previously used the procedure described by Randy Smith to build BIND on a Sun-4. It is definitely the way to go. DO NOT TRY TO MODIFY THE EXISTING netdb.h!! I have wasted a lot of time trying this and have never succeeded in getting the full functionality of BIND without breaking something else (we are a gateway for a lot of things including an RJE system that references netdb.h). By FAR the easiest way to get BIND working is to build everything referencing the include files directly as Randy suggests (hack the makefiles to include the -I../include flag [../../include when building nslookup] when compiling). Secondly, don't install BIND 4.7.3!! It has several serious bugs that result in a lot of unnecessary queries that return negative answers. Take the trouble to FTP BIND 4.8 from ucbarpa.berkeley.edu. It's worth it. If you're on NSFnet you can get it more easily from here (ncar.ucar.edu 128.117.64.4) complete with modified makefiles as pub/bind48.tar.Z . BTW for those that are curious: when 4.9 comes out, it is supposed to implement negative caching. --Greg (woods@ncar.ucar.edu) ------------------------------ Date: Tue, 10 May 88 16:14:53 +0300 From: leonid@TAURUS.BITNET Subject: Xy-451 firmware (BEWARE!) Noting the last comments about problems with the 451 is certain configurations (e.g. 4 disks per board) I just want to tell you something I found out quite long ago. The bottom line of this is the fact that Xy451's bought from SUN had differernt firmware (EPROMs) that ones bought directly from Xylogics, despite that Xylogics was told that it's intended for a SUN machine. The simpthoms I have been withnesing when using such a controller where unusual error messages during format and surface analysis (e.g. sequencer error). Judging from the latest postings I recon Xylogics have changed their EPROMs to work correctly with SUN "diag", but I still have the feeling that the 2 drive limitation has somehow influenced the firmware and thus never dared to attach a 3'd drive to a Xy451. Leonid ------------------------------ Date: Tue, 10 May 88 10:52:50 EDT From: smb@research.att.com Subject: Fuji-2372 disks This sounds a lot like a problem we had on 4.2bsd on our VAXen. The trouble was caused by the page table entry for pages that had never been brought in to memory, and hence were being demand-loaded from the file system. The field (pg_blkno in /usr/include/machine/pte.h) is only 20 bits wide, which limits you to (I think) a 500 MByte file system. pte.h on the Suns seems to have the same values. Pages of the file that are passed that limit are not accessible by this mechanism. On our VAXen, we dealt with the problem by using a 22-bit field, and shrinking pg_fileno to 3 bits (1 would have sufficed), then changing PG_FZERO and PG_FTEXT to 0 and 1, respectively. That, however, disabled their intended use, which was to memory-map open files. Since that code was disabled in 4.2bsd, we didn't consider it a serious loss. A quick glance indicates that the code *is* used on the Sun, so that option isn't available. Even if it were available, you'd have to rebuild much of the kernel from source to use it. The only bypass I can think of for now is to use a smaller partition size. --Steve Bellovin smb@ulysses.att.com {most of BTL}!ulysses!smb ------------------------------ Date: Tue, 10 May 88 08:18:26 EDT From: Chuck Musciano <chuck@trantor.harris-atd.com> Subject: Patch to calctool In a classic example of giving old, trusted software to new users, a small bug in calctool has been detected. The bug involves rounding numbers close to 1 in the scientific and engineering modes. The hex, octal, and binary modes are not affected. Both the calculator display and memory values are affected. The actual results of the operators are correct, but rounding is erroneous. The problem is exhibited when values like 0.9999999999999 are displayed as 0.1 rather than 1. I believe this will occur in both the float and fixed point display modes. A patch to fix the problem follows. Chuck Musciano Advanced Technology Department Harris Corporation (407) 727-6131 ARPA: chuck@trantor.harris-atd.com ************** Patch begins here, continues to end of message *** display.c Tue May 10 07:59:52 1988 --- display.c.new Tue May 10 07:59:39 1988 *************** *** 250,255 **** --- 250,256 ---- s[i] = '0'; if (i == start) { s[--start] = '1'; + exp++; break; } } *************** *** 297,304 **** else for ( ; i < curr_width[0]; i++) strcat(s, "0"); ! if (strlen(s + start) > 13) ! s[start + 13] = '\0'; } else { for (i = strlen(s) - 1; s[i] == '0'; s[i--] = '\0'); --- 298,305 ---- else for ( ; i < curr_width[0]; i++) strcat(s, "0"); ! if (strlen(s + start) > 14) ! s[start + 14] = '\0'; } else { for (i = strlen(s) - 1; s[i] == '0'; s[i--] = '\0'); ------------------------------ Date: Tue, 10 May 88 01:37:12 PDT From: mday@zeno.mmwb.ucsf.edu Subject: cheap SCSI drives? I remember previous discussions in sun-spots discussing the possiblity of using cheap SCSI drives on sun 3's, but I don't remember anyone claiming that they had actually done it. Has anyone gotten a 3rd party SCSI to work on a 3/160, and what hardware or software hacks were necessary? Thanks, Mark Day mday@cgl.ucsf.edu ...ucbvax!ucsfcgl!mday ------------------------------ Date: Tue, 10 May 88 13:38:17 +0200 From: Jeremy Cook <jeremy@kheops.cmi.no> Subject: Is there a mesg/suntools bug ? Typing 'mesg n' in any local tty within SunTools gives the message 'mesg: cannot change mode' (SunOS3.4). a) Is this a bug or a feature ? b) If it is a feature then why ? -- Jeremy Cook [[ Well, its not really either. Suntools grabs a pseudo tty for a window to use, but you aren't "logged into" that tty like you are when you rlogin to a host. So the slave end of the pseudo tty is still owned by root (when you log in to a machine, either remotely or directly, /bin/login--- which runs as root---changes the ownership of your tty so that it is owned by you). "mesg" does its work by literally changing the group and world write permissions of yout terminal (effectively doing a "chmod go-w"). That way another user can't open your terminal to write messages to it. But a shelltool's pseudo tty isn't owned by you, so mesg can't change the modes. A similar problem exists with "biff" since it records the fact that you want mail arrival notices by setting the user execute bit of your terminal. If you want to turn off messages while in suntools, use "mesg n >&/dev/console". A similar approach can be used with "biff". --wnl ]] ------------------------------ End of SUN-Spots Digest ***********************