Sun-Spots Digest, v6n153
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri Jul 29 01:45:52 AEST 1988
SUN-SPOTS DIGEST Tuesday, 26 July 1988 Volume 6 : Issue 153
Today's Topics:
Re: graphical SunView panel editor (2)
Re: XDR Question
Re: SunOs 4.0 installation question
Bug in Unix domain sockets
print selection
Confirmation of dying cmdtool
3/260 3rd party memory - summary of responses
maintaining applications for both Sun 3 and 4
Sun 3/4 compatibility
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: Fri, 15 Jul 88 09:39:21 GMT
From: David England <de%COMP.LANCS.AC.UK at cunyvm.cuny.edu>
Subject: Re: graphical SunView panel editor (1)
>Does anyone have a program for interactively creating and editing SunView
>panels?
Yes but its not public domain. Its generates C, PostScript (for pretty
printing) and something call FDL, which is project specific. I'll look
into getting it released but at the moment I have a thesis to write :-)
ref: SIGCHI Bulletin October '87, CHI 87 poster reports.
Dave England
Dept of Computing
University of Lancaster UK
de at lancs.comp.ac.uk
------------------------------
Date: Fri, 15 Jul 88 07:38:43 EDT
From: Chuck Musciano <chuck at trantor.harris-atd.com>
Subject: Re: graphical SunView panel editor (2)
> Does anyone have a program for interactively creating and editing SunView
> panels?
I have often thought about writing such a tool, but I get so picky about
how the MMI should look I never get around to doingthe actual work. In
the interim, here is a quick and dirty routine I use to get my panel items
in just the right place. To use it, give every panel item that you create
this routine as its event proc. Create the items at any old place, and
write enough code to bring up the window. You can then use the mouse to
drag the items around until they look good. The left mouse button does
horizontal motion, the middle button does vertical motion, and the right
buttons forces the item to report its (x,y) position. You can then put
these coordinates back into your program to get things to look good.
I realize this is a kludge of the first order, and that the dragging can
be jumpy, and its a pain to retype all the coordinates back into your
program. But anyone who has done this knows what a pain it is to layout a
panel the first time. I used to recompile about a jillion times. Now I
compile twice: once with move_item() included, and again with the correct
positions typed in.
I welcome questions or comments about how to use move_item().
Blatant advertisement: for simple panels and such, try tooltool, available
on an archive server near you.
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck at trantor.harris-atd.com
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: move_item.c
# Wrapped by chuck at melmac on Fri Jul 15 07:31:50 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'move_item.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'move_item.c'\"
else
echo shar: Extracting \"'move_item.c'\" \(1545 characters\)
sed "s/^X//" >'move_item.c' <<'END_OF_FILE'
X/************************************************************************/
X/* */
X/* move_item.c A notify proc which allows items to move about */
X/* and then report their position. */
X/* */
X/************************************************************************/
X
X#include <stdio.h>
X
X#include <suntool/sunview.h>
X#include <suntool/panel.h>
X
X#define NO_DRAG 0
X#define DRAG_X 1
X#define DRAG_Y 2
X
Xstatic int dragging = NO_DRAG;
X
Xmove_item(item, event)
X
XPanel_item item;
XEvent *event;
X
X{ static int old_x, old_y;
X static Panel_item old_item;
X
X if (event_id(event) == MS_LEFT)
X if (event_is_down(event)) {
X dragging = DRAG_X;
X old_x = event_x(event);
X old_item = item;
X }
X else
X dragging = NO_DRAG;
X else if (event_id(event) == MS_MIDDLE)
X if (event_is_down(event)) {
X dragging = DRAG_Y;
X old_y = event_y(event);
X old_item = item;
X }
X else
X dragging = NO_DRAG;
X else if (event_id(event) == MS_RIGHT && event_is_down(event))
X printf("%5d %5d\n", panel_get(item, PANEL_ITEM_X), panel_get(item, PANEL_ITEM_Y));
X else if (event_id(event) == LOC_DRAG)
X if (dragging == DRAG_X) {
X panel_set(old_item, PANEL_ITEM_X, panel_get(item, PANEL_ITEM_X) + event_x(event) - old_x, 0);
X old_x = event_x(event);
X }
X else if (dragging == DRAG_Y) {
X panel_set(old_item, PANEL_ITEM_Y, panel_get(item, PANEL_ITEM_Y) + event_y(event) - old_y, 0);
X old_y = event_y(event);
X }
X else
X panel_default_handle_event(item, event);
X}
END_OF_FILE
if test 1545 -ne `wc -c <'move_item.c'`; then
echo shar: \"'move_item.c'\" unpacked with wrong size!
fi
# end of 'move_item.c'
fi
echo shar: End of shell archive.
exit 0
------------------------------
Date: Thu, 14 Jul 88 15:08:05 PDT
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: XDR Question
> Can anyone give me the general idea behind the XDR (sp?) specification. I
> believe it stands for External Data Representation, but I can't find any
> documentation on it. Is it being pushed as a possible standard?
XDR does indeed stand for External Data Representation, and provides a way
to transfer data transparently between machines with representation
differences (different byte order, different float format, etc.). XDR is
generally considered part of Sun's RPC (Remote Procedure Call) package,
and is thus described in the RPC Programmer's Guide (which, unfortunately,
I can't find at the moment), although XDR can be used perfectly well
independent of RPC.
I believe that version 3.9 of RPC, including XDR, is in the Sun-Spots
archive on titan.rice.edu. Version 3.9 is a _later_ version, by the way,
with additional features, than the RPC that is shipped with SunOS 3.5; I
don't know what's on the 4.0 tapes.
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
brent at capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
[[ Yes, version 3.9 of Sun's RPC package is in the sun-spots archives. BE
WARNED: there is a very serious and major security hole in (I believe)
all versions of Sun's RPC package. See v6n130 for more information about
it. Archived source and digests can be retrieved via anonymous FTP from
the host "titan.rice.edu" or via the archive server. For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server at rice.edu". --wnl ]]
------------------------------
Date: Thu, 14 Jul 88 20:53:58 EDT
From: dpz at njin.rutgers.edu (David P. Zimmerman)
Subject: Re: SunOs 4.0 installation question
As a satisfied user of 128.6.*.* addresses, I am now proud to say I am
also a satisfied user of OS4.0 suninstall's Internet address range. That
is, yes, it now allows you to specify those addresses you know and love.
Now, this doesn't mean I necessarily am pleased that they still stick
"-gw" on the end of the ie1 interface hostname....
David P. Zimmerman
Systems Programmer
Rutgers University
------------------------------
Date: 14 Jul 88 23:23:58 GMT
From: cruff at handies.ucar.edu (Craig Ruff)
Subject: Bug in Unix domain sockets
We've found a Sun OS kernel bug when Unix domain sockets are being used.
It seems that if a server has a socket open, but is delayed from
processing connect attempts promptly, and many (about 20 in tests, but
maybe only > 5) clients are trying to connect all at once, and the server
is then killed, the kernel hangs in a tight loop in soclose. The symptoms
are no response from the machine (perhaps a few characters echoed on the
console), the CPU led's move very slowly (one every 2-3 seconds). The
only recorse is to reboot the machine. We've also seen random kernel bus
errors.
This is true for the following machine/OS combinations:
Sun 3/280 OS release 3.3
Sun 3/280 OS release 3.5
Sun 3/60 OS release 3.5 diskless
Sun 4/280 OS release 3.2-Sys4
Note that this problem does NOT exists for Internet domain sockets. The
local Sun office has been notified of the problem. A shar file is
appended with source code and scripts to recreate the problem.
[[ The shar file has been archived under "sun-source" as "sockethang.shar".
You can get it with either anonymous FTP to "titan.rice.edu" or by mailing
the request "send sun-source sockethang.shar" to "archive-server at rice.edu"
--wnl ]]
Craig Ruff NCAR INTERNET: cruff at ncar.UCAR.EDU
(303) 497-1211 P.O. Box 3000 CSNET: cruff at ncar.CSNET
Boulder, CO 80307 UUCP: cruff at ncar.UUCP
------------------------------
Date: Thu, 14 Jul 88 19:21:15 CDT
From: unniks at mcc.com (C. Unnikrishnan)
Subject: print selection
sun provides you with functionality already. read the man page on
get_selection. my print command line in .rootmenu looks like
"Print selection" csh -c "/usr/bin/get_selection | lpr"
unni
unni at mcc.com, unniks at cs.utexas.edu
------------------------------
Date: Thu, 14 Jul 88 15:40:01 BST
From: Paul Hudson <mcvax!moncam!paul at uunet.uu.net>
Subject: Confirmation of dying cmdtool
Reference: v6n134, v6n147
Yes, I've noticed this. I'm glad I'm not going mad .... :-) Occasionally
emacstool has done this to me as well. (Its' a 3/50 running 4.0)
Paul Hudson
Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul
Science Park, paul at moncam.co.uk
Milton Road,
Cambridge,
CB4 4FQ
------------------------------
Date: Thu, 14 Jul 88 10:15:08 BST
From: Andrew Watson <mcvax!harlqn.co.uk!andrew at uunet.uu.net>
Subject: 3/260 3rd party memory - summary of responses
I had two responses from users with 32MB Clearpoint cards - Mark Plotnick
<allegra!mp> uses them in both 3/260s & 4/260s, but reports that it took
several tries to get boards that worked in the Sun 4. David Dow
<dow at mcc.com> has one in a 3/260 and has had no trouble.
The machine with 4MB on the CPU is the 3/1xx - all main memory on the 2xx
is on the bus. No-one reported being able to put more than 32MB on a
3/2xx.
Other 3rd party suppliers mentioned, but without firsthand experience -
Helios Systems. Parity Systems Inc.
1996 Lundy Ave. 785 Lucerne Dr.
San Jose, CA 95131 Sunnyvale Ca. 94086
(408) 432-0292 (408) 738-1500
Thanks to all who replied.
Regards,
Andrew.
Andrew Watson, Harlequin Limited, andrew at uk.co.harlqn
Barrington Hall, Barrington, Tel: +44 223 872522
Cambridge CB2 5RG, UK Fax: +44 223 872519
------------------------------
Date: Fri, 15 Jul 88 12:09:20 BST
From: Mario Wolczko <mario%mushroom.computer-science.manchester.ac.uk at nss.cs.ucl.ac.uk>
Subject: maintaining applications for both Sun 3 and 4
The Manchester CS Dept has recently installed its first Sun 4, as part of
a domain comprising tens of Sun 3s. The problem is: What's the best way
to maintain applications for both sets of machines?
We have something like 300Mb of source to assorted applications (Gnu, X,
TeX, etc) that we want to install for both Sun 3s and 4s. What's the best
way to organise it? Possible ways are:
1. Keep a separate copy of the whole thing for each architecture. Use
rdist to keep the source consistent.
Pro: applications themselves (probably) don't need to be altered
Con: lots of duplicate stuff on two disks
2. Use make to keep different .o files in separate subdirectories.
Pro: Only one set of sources required
Con: Have to edit makefiles (many of which are v. complicated),
Sun4 .o files live on Sun3 disk (or vice-versa); seems a bit
silly.
3. Maintain "parallel" directories with sources linked, .o files
separate.
Pro: saves disk space
Con: Hard links preclude compression of sources. Soft links cost
1 block per link. Have to maintain the links.
Clearly, we're not the first to have encountered this problem. If you
have a mixed-architecture domain with substantial sharing of applications,
what do *you* do? What's your environment like: lots of disk space to
play with, only a few "active" applications, etc?
I'd be grateful for your opinions, experiences, hunches (money,
equipment,... :-). I'll summarise responses back to sun-spots.
Mario Wolczko
Dept. of Computer Science Internet: mario%ux.cs.man.ac.uk
The University USENET: mcvax!ukc!man.cs.ux!mario
Manchester M13 9PL JANET: mario at uk.ac.man.cs.ux
U.K. Tel: +44-61-275 2000 extn 6146
------------------------------
Date: Fri, 15 Jul 88 00:36:07 EDT
From: hedrick at aramis.rutgers.edu (Charles Hedrick)
Subject: Sun 3/4 compatibility
The example program is obviously just a small test case. Things like that
come up where you have a data structure where variable-size entries are
packed into an array. In that case you can find that the next entry
doesn't start on a word boundary, and so all your shorts and ints are
misaligned. When possible, you put in padding bytes, so that new records
always start on an even boundary. But if you're trying to read an
existing file, or a network packet, this may not be practical. In that
case I've seen wierd code like
bcopy(&sp->field,&field,sizeof(field));
Fortunately, the two machines we have with this problem both have compiler
options to let the compiler worry about it. On the Pyramid it is -q. On
the Sun 4 it is -misalign. I don't even want to think about what code
this generates. It can't be very nice to look at. I'd try to avoid using
it except as a first step when porting programs.
However I have a quarrel with the author's terminology. He says that the
Sun 4 is not byte addressable. Sun 4 addresses, like Pyramids and other
machines in that class, are to bytes. If you have a (char *), you can
dereference it and get any byte you like. The machine has a load byte
instruction. The problem is that references to shorts and longs must be
aligned to short and long word boundaries. This may indeed cause trouble
with some programs. The programs will also have trouble on Pyramids and
other machines. There are enough other machines like that around that
portable software has had these problems fixed already. However if a
program has only been tried on a Sun 3, and if the writer did not follow
rules for portability, it may indeed have to be modified to move it to a
Sun 4. The software that we import from the net has remarkly few of these
problems. We'd just as soon catch non-portability in things that we write
ourselves. So these things don't bother us. But if we had lots of old
code written in the bad old days when people didn't worry about
portability, and if -misalign turned out to slow them down a lot, this
might not be the machine for you.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list