Sun-Spots-Request@Rice.edu (William LeFebvre) (09/23/88)
SUN-SPOTS DIGEST Wednesday, 21 September 1988 Volume 6 : Issue 233
Today's Topics:
Re: interleaf under 4.0
Re: Bigger icons for frames
Re: Writing to /dev/rst0 can hang a Sun 4/260S
Porting posted tools to the 386i?
Directory protection can cause ccom to core dump
Bug in cc on a sun4 running SunOS4.0
Problem: Lost Disc Space
Porting C++ 1.2.1 to suns
Popularity of 1/4" cartridge vs. 1/2" reel-to-reel tape?
ditroff wanted for SUNOS4.0
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: Wed, 14 Sep 88 00:06:26 EDT
From: stpstn!aad@philabs.philips.com (Anthony A. Datri)
Subject: Re: interleaf under 4.0
Our ops (3.0?) that runs under sunos 3.2 seems to work fine when I run it
under suntools on a 2/50 running 4.0. Not fast, mind you, but it runs. I
haven't tried it outside of suntools, but I would suspect that it works
there as well. Interleaf gave us a runaround when we asked them about
sunos 4.0. But then, that seems to be their corporate policy.
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Fri, 16 Sep 88 08:26:53 EDT
From: Mike Jipping <jipping@cs.hope.edu>
Subject: Re: Bigger icons for frames
> Make sure that you fix up the header in the icon file, since the
> icon_load() routine (undocumented, but available in <suntool/icon_load.h>)
> uses these numbers to create the initial icon pixrect. If you get the
> ICON_{WIDTH,HEIGHT} set right, it should work; I've created icons of all
> sorts of sizes this way.
Two followup questions: Are we talking about the COMMENT at the top of
iconedit-generated files? And what does this mean about non-standard
bitmap files?
An example: I've got a bitmap 105 pixels wide by 67 high. I generated it
with Fig, dumped the rasterfile, and converted the rasterfile to the hex
format. I figured since I #included the file in by C program anyway, the
comment line is ignored -- So I threw one in about height and width for my
benefit. But I try and try -- and the darn thing will not load correctly.
Here's a clip:
static short bibtool_icon_image[] = {
#include "bibtool.icon"
};
mpr_static(bibtool_icon_pr, 105, 67, 1, bibtool_icon_image);
So far, I'm following the book. Now I create the icon with "icon_create":
bibtool_icon = icon_create(ICON_IMAGE, &bibtool_icon_pr,
ICON_WIDTH, 105,
ICON_HEIGHT, 67,
0);
No go. The size is right, and a 64x64 portion is right, but the rest of
the icon is simply replicated from the 64x64 portion. So I cheated and
manipulated the icon structure directly -->
static short bibtool_icon_image[] = {
#include "bibtool.icon"
};
mpr_static(bibtool_icon_pr, 105, 67, 1, bibtool_icon_image);
static struct icon bibtool_icon = {
109, 71, NULL, {2, 2, 105, 67},
&bibtool_icon_pr, {0, 0, 0, 0}, NULL, NULL, ICON_BKGRDSET };
This is how Fig does it with it's huge icon, and I just hacked it to fit
here. And now the icon is fine! BTW -- I even replaced the header
comment with an iconedit-like one, and still had problems.
And I lied a bit about the "fine" icon. The image is correct, but it is
placed on the screen like a 64x64 icon. I have my "Icon_gravity" set to
"East" (right hand side of screen) and initial place ment of the icon
hides the right 41 pixels.
So I'm stumped. I'd sure appreciate some hints on how to do this cleanly.
The direct struct definition is for the birds!
-- Mike
Mike Jipping
Hope College
Department of Computer Science
jipping@cs.hope.edu
------------------------------
Date: Wed, 14 Sep 88 14:52:49 BST
From: Chris Brown <mcvax!aivru.sheffield.ac.uk!chris@uunet.uu.net>
Subject: Re: Writing to /dev/rst0 can hang a Sun 4/260S
In v6n226 Dan Ehrlich writes:
>When trying to write blocks that are not sized modulo 512 to
>/dev/rst0 vmunix continuosly generates error messages to the
>console.
If you read the man page for st(4S), under BUGS, it says:
When using the raw device, the number of bytes in any given
transfer must be a multiple of 512. If it is not, the dev-
ice driver returns an error.
>From the error messages Dan reported I'd guess the driver is going ahead
and attempting the transfer anyway, rather than just refusing.
Chris Brown A.I. Vision Research Unit, Sheffield University, England
chris@aivru.sheffield.ac.uk
------------------------------
Date: 16 Sep 88 05:41:37 EDT (Fri)
From: n8emr!lwv@att.att.com (Larry W. Virden)
Subject: Porting posted tools to the 386i?
I am looking for help from folks who have submitted items to Sun Spots
source archives. I am trying to port quite a number of your sunview tools
to the 386i. I got monthtool, calentool, tooltool up okay. But I had a
tougher time with moontool (it compiles, but the icon looks 'strange')
[[ this could be caused by the different byte orderings --wnl ]],
calctool (it doesnt link up - sorry, I dont have the messages here - see
below for the REAL reason for this msg!), brottool seems to eat up all of
my CPU time (mouse button events seem to be delayed as much as a minute or
two!), graphedit (that may not be on these archives, but I got it from
either here or comp.sources.*), vttool compiles and links but appears to
be a subset of vt100 from the looks of it running vttest, eyecon works
just fine <grin>. I KNOW there were a couple of more of these guys from
perhaps the comp.sources.* groups - again, I am on my home machine right
now.
What I am after is info to help me locate bugs, etc that others have found
while porting to the 386i. So far things havent been bad. Many of the
programs had more problems with the transfer of the files from Rice to my
worksite than they did actually compiling. For some reason, requesting
delivery from Rice to my sun's site via bitnet results in tabs changing to
spaces and lines 'wrapped' into 2+ lines at 80 columns - makes for
interesting error messages! [[ Definitely caused by some Bitnet gateway---
others have had this problem as well. --wnl ]]
Anyways, anyone out there have any tips? Any software development tips
for the 386i, still running SunOS 4.0 ... Thanks!
Larry W. Virden 75046,606 (CIS)
674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817
osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET)
------------------------------
Date: Fri, 16 Sep 88 15:07:57 EDT
From: ehrlich@shire.cs.psu.edu (Dan Ehrlich)
Subject: Directory protection can cause ccom to core dump
Reply-To: bugs@blitz.cs.psu.edu
Machine Type: Sun 4/260S
O/S Version: SunOS 4.0
Organization: Computer Science Department
The Pennsylvalia State University
333 Whitmore Laboratory
University Park, PA 16802
Description:
What with Sun's restriction of no more than 5 people being able
to have access to the SUN OS sources it was neccessary to alter
the protections on the directory /usr/src. As we have locally
written software we keep under /usr/src/psu the protection on
/usr/src was changed from 775 to 771 and the group to sunsrc.
The protection on /usr/src/psu is 775 and the group is source.
One of the staff who is in group source but not sunsrc started
to recieve the following message when she tries to recompile
some of our local software after we made these changes:
% cc -g -c lib.c
cc: Fatal error in ccom: Segmentation fault (core dumped)
At first we thought it was a problem with 'cc -g', as if we
removed the '-g' flag the compile ran without error. Then she
noticed that if she was not in a directory under /usr/src the
'-g' flag worked as expected. When we changed the protection
on /usr/src back to 775 everything started working again.
So, we have a problem somewhere that is related to the file
protection o