Sun-Spots Digest, v6n84
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri May 13 08:41:58 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at lanl.gov
------------------------------
Date: Mon, 9 May 88 17:17:07 EDT
From: gamin%amadeus.UUCP at larry.mcrcim.mcgill.edu (Martin Boyer)
Subject: Re: Format for byte encoded rasterfiles (2)
sow at cad.luth.se (Sven-Ove Westberg) and JDEBE at 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 at 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 at 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 at ucbarpa.berkeley.edu (Kevin Layer)
Subject: Re: A SCL floating-point problem
>> From: roberts%studguppy at 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 at Berkeley.EDU
or
ucbvax!franz!layer
------------------------------
Date: 9 May 88 11:40:25 GMT
From: Ian Phillipps <mcvax!camcon!igp at 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 at camcon.uucp | Science Park, Milton Road |-----------------
Phone: +44 223 358855 | Cambridge CB4 4DW, England |
------------------------------
Date: 10 May 88 02:54:04 GMT
From: david at elroy.jpl.nasa.gov (David Robinson)
Subject: Re: NFS 'df' oddities (was Re: Mac II Ethernet Boards)
Reference: v6n75
> From: ralphw at IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
> In article <4476 at hoptoad.uucp> gnu at 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 at csvax.caltech.edu ARPA
david at elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
------------------------------
Date: Tue, 10 May 88 10:28:19 CDT
From: brewer%antares at 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 at anl-mcs.arpa
------------------------------
Date: 10 May 88 17:00:06 GMT
From: woods at 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 at ncar.ucar.edu)
------------------------------
Date: Tue, 10 May 88 16:14:53 +0300
From: leonid at 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 at 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 at ulysses.att.com
{most of BTL}!ulysses!smb
------------------------------
Date: Tue, 10 May 88 08:18:26 EDT
From: Chuck Musciano <chuck at 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 at 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 at 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 at cgl.ucsf.edu
...ucbvax!ucsfcgl!mday
------------------------------
Date: Tue, 10 May 88 13:38:17 +0200
From: Jeremy Cook <jeremy at 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
***********************
More information about the Comp.sys.sun
mailing list