SUN-Spots Digest, v3n14
Scott Alexander
Sun-Spots-Request at RICE.EDU
Mon Dec 9 14:48:20 AEST 1985
SUN-SPOTS DIGEST Sunday, 8 Dec 1985 Volume 3 : Issue 14
Today's Topics:
Hooking Macintoshes up to Suns
Sun-100 display monitor distortion
Apollo vs. Sun - a comparison
Re: Sun-2's versus Sun-3's (2)
Re: file system panics under 2.0
MIDI on SUNs
Re: problems with serial ports on zs board
Trivia
return address for postings
X.25 support for a Sun
Need experiences with Mt. Xinu Vax NFS
Yellow Pages source code, anyone?
Multibus devices on Sun-3, Ethernet transcievers
Lisp won't die!
A lint problem
SunWindows - help
------------------------------------------------------------------------
Date: Thu, 5 Dec 85 14:38:47 cst
From: texsun!mehoge!tj at sun.UUCP (Cal Thixton Sun Microsystems Dallas Office)
Telephone: (214) 823-2084 Office Phone: (214) 788-1951
Purpose-In-Life: To Spread the Gospel of UN*X to the heathens
Subject: Hooking Macintoshes up to Suns
Summary: To connect a Macintosh to a Sun over a serial line,
use the Macintosh printer cable, NOT the Macintosh modem cable.
Penalty for failure to heed this recommendation: The Sun will blow up.
Details:
The Macintosh serial connector (9-pin) supplies +12V and +5V for
powering some unknown device. The Macintosh modem cable presents
+12V,+5V on pins 20,6 of the 25-pin connector. The Sun will fail
because of the +12 on pin 20. One likely symptom is that the
display will stop working (the video problem occurs on the CPU board,
not in the monitor).
The Macintosh printer cable does not present these troublesome voltages
on the 25-pin connector.
Failure analysis:
Pin 20 is RS-423 "DTR", which the Sun drives with a 26LS29 driver
chip. The chip is supplied from +-5V. The chip can withstand
overvoltages up to +15V, but ONLY if the overvoltage supply has
several K ohms impedance, as would be the case with an RS-232 driver.
Since the Macintosh supplies 12V at low-impedance, the driver chip
has to withstand quite a bit of current between the external +12 and
its own -5V supply. It eventually fails. The failed driver chip
draws too much current from the -5V supply, which current limits and
starves the ECL video drivers, which use the -5V.
To repair the Sun:
Replace the 26LS29 chip associated with the port that was connected
to the Macintosh.
-----------------------------
Date: Sat, 7 Dec 85 13:40:59 PST
From: brian at sdcsvax.arpa (Brian Kantor)
Subject: Sun-100 display monitor distortion
Recently ALL of our sun-100s (the old style tabletop guys with the Phillips
monitor) began slowly to exhibit a vertical deflection problem. The image
displayed nonlinearity (compression) of scan lines at the bottom, foldover
at the top, and a shift in the centering such that there was an unscanned
stripe at the bottom and lines at the top were masked off by the edge of
the tube.
This happened at different rates for the different units we have - the oldest
showed it first. This sort of behaviour is typical of component aging, so
I went at it with the heat gun and freeze mist, and found that a capacitor
on the monitor deflection board (C416, 220uf/25V) was bad. Replacing it
repaired the problem - in all four of our units. Total time was about
1 hour to find it, and another to change it in all four of our suns. Total
parts cost, about $2.00 (good old Radio Shack to the rescue).
This kind of failure, in all our units, points to what is perhaps a bad run
of capacitors from Phillips, who sold the monitors to Sun. (All the
caps were made by Phillips themselves.)
I post this note because other people might be experiencing the problem
too, and rather than pay Sun's expensive repair prices might care to
fix it themselves. Of course, these systems have been out warranty for
a couple of years, so we've been doing our own maintenance for some
time.
Oh yes: you can order the replacement picture tube (CRT) for a Sun-100
from your friendly local Sylvania dealer (the part number is right on a
sticker on the tube) for about $100 or so when it wears out - which they
do after 3 or 4 years of constant operation. Symptoms of a bad CRT include
dim image, poor focus (lack of sharpness in the individual scan lines), and
a "silvery" sort of appearance to the image. We've changed all of ours by now.
Make sure you have everything turned off and unplugged before you go
poking around inside the monitor. Like most TV sets, monitors have
several thousand volts on parts of the circuits for some time after
they've been turned off, and touching that is likely to surprise you and
make you do things you didn't want to do. Severe laundry problems.
Brian Kantor UCSD Computer Graphics Lab
c/o B-028, La Jolla, CA 92093
decvax\ brian at ucsd.arpa
ihnp4 >--- sdcsvax --- brian
ucbvax/ Kantor at Nosc
-----------------------------
Date: Wed, 4 Dec 85 17:32:18 est
From: mike%bambi at mouton.ARPA
Subject: Apollo vs. Sun - a comparison
I used Suns at Rice for several years, since the original Sun-1 and Unisoft
V7 Unix. (In fact, I used to moderate this list.) I've been using Apollos
for about 6 months here at Bellcore. These are a few comments about the
merits and problems of the Apollo relative to the Sun. (Note that my Sun
experience goes up to Sun 1.3, not 2.0, and my Apollo experience goes to
SR9.)
First, I have to confess that even on the Apollos, we use Unix exclusively.
(For those who don't know, the Apollo runs a kernel operating system called
Aegis. Libraries and server processes sit on top of that kernel. The
"Domain/IX" product is a Unix emulator for both 4.2 and System V,
simultaneously if you like, and provides most of the Unix system utilities,
libraries, and system calls.)
We use Unix mostly for reasons of portability and familiarity. Regardless
of the merits of the native Apollo operating system, there's no way a
program written with it will run on another machine, while with Unix,
there's at least a fighting chance of writing portable code.
APOLLO MINUSES:
Because the native operating system is not Unix, there are an entirely new
set of system management problems. You have to learn a whole new set of
commands, remember where different configuration files are, and so forth, to
be an effective system manager. This took me about a month or so. The
problem was greatly complicated because most of the Aegis commands have
almost exact Unix equivalents, but the names have been changed. For
example, "list directory" is "ld", not "ls". "Move file" is "mvf", not
"mv". It's an annoyance. Once Domain/IX is in place, these problems
almost, but not quite, go away.
All of 4.2 BSD is not supported. For example, the syscall interface to the
kernel is missing, as is the SIGIO signal. The 4.2 print spooler (lpr, lpd)
and the Unix graph(1) command are not present. I'm sure there are other
things that I haven't missed yet. I am not too familiar with System V and
we aren't using it, so I don't know what's missing there.
Because the C compiler is a native Apollo compiler and not the Portable C
compiler, there are subtle C language incompatibilities. Also, there is no
assembler in the standard distribution, the compiler produces error messages
in a different format, and the code quality is different between Apollo C
and PCC. (It's not clear which is better. Under SR8, Apollo C was clearly
inferior to PCC, but the situation has improved under SR9.)
Apollo uses a TCP/IP derived from the old BBN sys.10 process-based TCP,
which means there are a different set of management commands from the ones a
4.2 user would be used to (ie, different host tables, no netstat, route,
arp). Most of the same functionality is present, it's just different. (The
network libraries, sockets and so forth, are identical to 4.2 BSD's.)
The object and executable formats are unlike Unix's, so programs that dump
memory state don't work. In addition, the symbols etext, edata, and end are
not provided.
To make a sweeping comparison, the Apollo (with a 68010) is slower than the
equivalent Sun. Using the Dhrystone benchmark, an Apollo DN320 with an FPA
comes in at 793, while a Sun 2/120 without FPA runs at between 1100 and
1200. I don't know the relative clock speeds of the two machines, or the
memory wait-state situation on the Apollo, or whether the 68020 versions
will be different.
In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless
Sun (running ND, not NFS) with 2 meg. One should take into account that
this includes the (presumably) extra overhead of running Domain/IX programs
as opposed to native Aegis commands, which we don't use much. Some
commands, particularly those that deal with directory reading or writing
(like "find") are painfully slow.
The standard Unix debuggers (adb, dbx) are not supported on the Apollo. The
standard editor is nicer in some ways, worse in most, to the Sun dbxtool.
It's certainly different - another training problem.
The Apollo's performance is not "predictable" to me. There are sometimes
long pauses for no good reason. This may well be an artifact of my
unfamiliarity with the internals of Aegis, and strange interactions with the
Apollo virtual memory and single level store.
The Apollo documentation for Domain/IX is almost a straight printout of the
Berkeley VAX documentation. Usually the differences and limitations of
Domain/IX are not mentioned. As documentation for someone unfamiliar with
Unix, it suffers from the typical Unix problem - you have to know a lot
about Unix already before the documentation makes sense. Apollo should make
an effort to try to expand on the conventional documentation. They have a
short guide for new users, but nothing really for systems programming. (Sun
has more or less the same problem, but since they've had Unix longer, their
documentation is somewhat further along. It still suffers from emphasis on
novice users, though. I don't know if the 2.0 documentation is better.)
I like the Sun keyboard and optical mouse much better than the Apollo
keyboard and mechanical ball mouse. The Sun window interface has somewhat
better mechanics; Apollo window placement, cursor treatment, and general
user interface have some problems.
APOLLO PLUSES:
Aegis is a much "cleaner" operating system than Unix in a number of ways.
For example, the single level store allows very nice shared libraries to be
implemented. Rather than including the object code for all of the C library
with every program, as Unix does, Aegis does dynamic binding at run time.
The executables are much smaller, and the system can be changed without
rebinding anything. I have executables from 4 major releases of Aegis ago
that still run with no changes. One could claim that from a design
standpoint, Aegis is more consistent than Unix. It has more support for
record-oriented files, which might be important for some applications, like
databases. (You can't use this and remain Unix-compatible).
Apollo has had transparent access to files for much longer than Sun has.
Therefore, the performance seems to be much better (I have only limited
experience with NFS, but long waits for file opens don't occur on the
Apollo.) The performance of Sun ND seems superior to Apollo's distributed
access, but remember that ND didn't allow read/write file sharing among
machines.
In order to run a single ring of machines, much less system administration
per processor is needed on the Apollos. It is almost as simple as plugging
a new machine into the ring, turning it on, and using it. The Sun requires
a much more complicated procedure to configure a new machine. A diskless
Sun has to be administered like a separate machine, while a diskless Apollo
doesn't have any separate administration problems.
The Apollo user interface has some nice features that the Sun lacks, like
scrollable back histories, and command resubmission and editing. There is a
simple (almost too simple) pervasive editor that is always available on the
Apollo to do input editing. The Sun is much more oriented towards multiple
ASCII terminal windows.
The Apollo graphics package is considerably easier to use than the Sun
package, although of course neither is the least bit portable to other kinds
of machines or each other.
The Apollo error messages, both from system routines and the compilers, are
much better than the standard Unix messages found on the Sun.
We experienced a large number of CRT failures at Rice, and other groups at
Bellcore continue to lose Sun CRTs commonly. We have never had an Apollo
CRT go out on us (in two years with four to seven nodes). In general
hardware reliability seems higher on the Apollo.
Apollo seems to have a much higher commitment to software compatibility and
support across releases and different Apollo hardware than Sun does. With
Sun, we went through a large number of completely incompatible software
upgrades (Unisoft to Sun 0.1 to 0.3 to 1.0 to 2.0) across which most
graphics software broke completely. Apollo guarantees compatibility from
release N to release N+1, and in practice, across many more release levels.
The documentation for Aegis has a rich set of examples in several languages
for how to use most of the system interface.
As a company, Apollo has exhibited somewhat different tactics than Sun. In
the early days, Sun made a lot of promises and then failed to deliver.
Apollo delivered a product with full function but bad performance, then
concentrated on making it fast. Now that Sun can deliver, the difference is
less pronounced - but I still remember a year of not being able to do much
with Suns because the graphics and network software wasn't there yet.
THE BOTTOM LINE
We are getting our work done with the Apollo, working around the problems
caused by lack of full Unix support. In general we're happy, but we're also
scared that the CS research community is moving to Suns exclusively. It
seems clear that Sun's commitment to full native Unix is stronger than
Apollo's. We have already had some problems porting programs from Sun or
VAX to Apollo. While this can be chalked up in large part to sleazy
programming practices, that doesn't make the problem any more manageable.
In brief: For applications involving exclusive use of Unix, and contact
with the general research community, the clear choice for now seems to be
Sun. If you don't have the constraints of Unix and Unix portability, you
should give Apollo a look.
Mike Caplinger
mike at bellcore.arpa
ihnp4!bambi!mike
ps. I'm still looking for the perfect workstation. It's beginning to look
as though I'll have to build it. :-)
-----------------------------
Date: Thu, 5 Dec 85 10:50:13 est
From: Sid Stuart <linus!sid at mitre-bedford.ARPA>
Organization: The MITRE Corp., Bedford, MA
Subject: Re: Sun-2's versus Sun-3's
First I would like to apologize for spelling your name wrong Phil.
I promise to write William LeFebvre 100 times on the blackboard before I
go home today.
Second I guess I should try to clear up my muddled arguments so that
they make more sense. The original paragraph said:
"The first problem is that Sun has not set up the capability to boot
different kernels from /pub. The second is the 2K versus 8K page sizes for
the swap space, thus the nd server would need to work for both and is not
currently set up to do so. The third is that the systems are running
different releases of the OS and will do so until the promised release..."
Let me rewite my arguments including what I thought were obvious
assumptions. I should admit that the assumptions become less obvious as I
try to remember them.
1) The nd server distributed by Sun at the present time can only have
one copy of the kernel for the diskless nodes to boot from and, in the initial
distributions at least, Sun 2's will not run off of the same kernel as the
Sun 3's. I doubt the same kernel will ever run on both Sun 2's and Sun
3's, their architectures are too different.
This is a point of contention between Phil and I, he thinks
that Sun will meld the kernels, I think they will introduce a mechanism to
boot different kernels. The only reason I have for my belief is that
I heard this from a salesperson. With that in mind you may want to go along
with Phil on this one ;-).
2) The Sun 2 has a 2K page size. The Sun 3 has an 8K page size. The nd
server would need to handle swapping for both and is not currently set
up to do so.
(at least one argument makes sense without explanation ;-)
3) The systems will be running different releases of the OS, with the
the Sun 3's having a later release than the Sun 2's.
The Sun 2 binary code should run on the Sun 3 (68010 code on a 68020),
but may not be able to grok the system calls from a kernel that is a
different release. The Sun 3 binary code will not be downward compatible
with the Sun 2 processor. Thus the binaries in /bin, /usr/bin ... will
not be compatible between the two systems. This last problem can be
gotten around, but it would cause one to set up and keep multiple
copies of all binaries on the same server. I would hesitate to do this
if I were handling the distribution.
sid at linus
-----------------------------
Date: Thu, 5 Dec 85 00:09:19 EST
From: Chris Torek <chris at mimsy.umd.edu>
Subject: Re: Sun-2's versus Sun-3's
I find it hard to believe that a change in packet size should affect
ND. The protocol includes the I/O request size, and there is no
particular limit to this size (aside from memory constraints, but
that is 2048*64 or 128K of buffer space---64 is NNDMAP, the number
of read buffers that can be mapped, and NDMEMSIZE is 2K times that
value). (We have source for ND, though it is not Sun source, so
their names may vary. This source is available, by the way, for
both Suns and Vaxen, though you must have a Sun source license.)
My guess is that Sun-2s will talk to Sun-3s and vice versa, all
protocols, modulo the 3Com Ethernet board problems of course.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at mimsy.umd.edu
-----------------------------
Date: Thu, 5 Dec 85 14:36:50 cst
From: texsun!mehoge!tj at sun.UUCP (Cal Thixton Sun Microsystems Dallas Office)
Telephone: (214) 823-2084 Office Phone: (214) 788-1951
Purpose-In-Life: To Spread the Gospel of UN*X to the heathens
Subject: Re: file system panics under 2.0
the /etc/zz* sounds like an Alis file. if you seem to be
getting random file system errors, first check the
controll, but then go through /etc/nd.local and make sure
that you do not have any over-lapping partitions. I had a
problem a while back that randomly appeared; somehow a new
client in the office was allocated swap space in the middle
of one of the file systems. the server panic randomly when
the client started swapping to this partition. Since the
client was not heavily used, it took a while to find this.
cal
-----------------------------
Date: Thu, 5 Dec 85 11:38:31 PST
From: sdcarl!dgl at ucbvax.berkeley.edu (D. Gareth Loy)
Subject: MIDI on SUNs
In response to a querey re. MIDI interfaces and software for SUNs,
we at sdcarl have developed both a Multibus and VME-bus interface
for the Roland MPU-401. The design is public domain and available
to anyone requesting it. In addition, we have a device driver
for SMI 2.0 UNIX, and a host of applications programs.
Lucasfilm has augmented our software with some offerings of their
own, different enough to be called a variant, though the core
routines are the same.
The Computer Music Laboratory at Northwestern University is also
developing MIDI-based software and hardware. We are attempting to
negotiate design strategies so as to come into commonality with
them.
=Gareth Loy, Computer Audio Research Laboratory, UCSD
-----------------------------
Date: Thu, 5 Dec 85 14:38:22 cst
From: texsun!mehoge!tj at sun.UUCP (Cal Thixton Sun Microsystems Dallas Office)
Telephone: (214) 823-2084 Office Phone: (214) 788-1951
Purpose-In-Life: To Spread the Gospel of UN*X to the heathens
Subject: Re: problems with serial ports on zs board
If you leave a getty running on a serial line that does not have an actual
terminal tied to it, the lines will float and the serial chip will think that
it is getting Nulls. Getty is then fed these and will sit and happily eat
up a lot of cpu cycles, die and init will fork another getty.
Solutions:
1> turn off getty's on ports not being used.
2> always leave a terminal on the line.
3> make a connector with a resister to pull the carrier detect high and enable
the system to notice CD's. Or Pull the data line up.
4> changes in auto-bauding sequence in /etc/gettytab to overcome the Nulls.
i suggest the following 2 "fixes" for the getty cycling
problem. Trouble is, neither definitely works, they just tend to
alleviate the problem. As always, the real "answer" is keep terminals
plugged in and turned on, or disable logins in /etc/ttys.
Fix 1.
======
In gettytab, add a "pf#2" capability to the entry for your favourite
terminal. From gettytab(5), this sets a 'delay between first prompt
and following flush(seconds)'. This may quiet the static "ringing"
the line.
Fix 2.
======
Change the ttys entry to point to one of the sets of looping line
types. For example, entry 'p' is also for a 9600 baud terminal, but
it switches to entry'q' when you hit the break key. For some reason,
this sometimes alleviates the problem. You may run into problems if
your terminals don't have break keys, or if your users don't know
what to do when their login prompts appear at the wrong baud rate.
tty |
port | 2 ---------------- \
on sun | \
| 3 ------x--------- > to customers equipment
| | /
| 7 ---------------- /
| |
| |
| | |
| | | 4.7k resistor, 1/4 watt
| | |
| |
| 25 -----x
|
|
| 2 -------------\/-------------- 2
| 3--------------/\-------------- 3
| 7 ----------------------------- 7
| 8 ----x---------\
| | \------------- 20
| \
| /
| \ 4.7 Kohms
| /
| |
|25-----x
you get the idea....
cal
-----------------------------
Date: Thu, 5 Dec 85 17:13:55 est
From: Barry Shein <bzs%buit4%bostonu.csnet at CSNET-RELAY.ARPA>
Subject: Trivia
In the file <sundev/kbd.h> there is reference to keyboard
slang called 'buckybits'. Later on in a comment an explanation
of the term is given as the bits set on systems that support
META, TOP etc keys, but that the derivation of the term is
unknown.
I was always under the impression that the term came from the
fact that on these systems META-foo (or ALT-foo) echoed as
'$foo' on the screen, dollar == buck, hence buckybits. Note
the strong relationship between META-foo and ESC-foo and the
fact that most DEC systems still echo ESC as $.
Just thought that should be cleared up, hope you feel better now.
-Barry Shein, Boston University
-----------------------------
From: texsun!mehoge!tj at sun.UUCP (Cal Thixton Sun Microsystems Dallas Office)
Telephone: (214) 823-2084 Office Phone: (214) 788-1951
Purpose-In-Life: To Spread the Gospel of UN*X to the heathens
Subject: return address for postings
Can anything be done to provide better or more accurate
return addresses for postings to sun-spots? Sometimes people
will post items that you might want to talk to them about
off-line, but the addresses provided are generally of no
use.
cal
[I just discovered how disastrous some of the addresses are. I am now
checking more carefully that the ``From:'' line matches the ``From '' line
and that both of them bear some relation to the ``Received:'' lines. If
worse comes to worse, send a note to sun-spots-request and I'll try to
figure out what the original address was. ---dsa]
-----------------------------
Date: Thu, 5 Dec 1985 11:09 O
From: Henry Nussbacher <Vshank%Weizmann.BitNet at ucbvax.berkeley.edu>
Subject: X.25 support for a Sun
I recently heard of X.25 support for a Sun. The specific example is we have
an Ethernet of Unixes, IBM and Suns and we wish to connect an X.25 9600
baud Telenet line. Can someone please send me the necessary information
or user experience with this program and whether the X.25 program has
PAD emulation built in.
Many thanks in advance,
Henry Nussbacher
Weizmann Institute of Science
Rehovot, Israel
-----------------------------
Date: Fri 6 Dec 85 14:08:34-EST
From: Ralph W. Hyre Jr. <Ralph.Hyre at C.CS.CMU.EDU>
Subject: Need experiences with Mt. Xinu Vax NFS
Work-Phone: (412) 578-2847
We have an 11/780 and an 11/785 that we'd like to use as file servers
for each other, and we'd also like to use them as file servers for our
Suns. NFS seems to fit the bill, but I'd like to know if anyone else
has had experience (good or bad) with NFS from Vax to Vax and Vax to Sun.
Any information would be greatly appreciated.
- Ralph
-------
-----------------------------
Date: Fri, 6 Dec 85 17:09:12 pst
From: fluke!jeff at uw-beaver.arpa (Jeff Stearns)
Subject: Yellow Pages source code, anyone?
Do you have distributable source code for the Yellow Pages client routines?
I have a collection of Suns which all speak Yellow Pages, and I'd like
to add my vaxen as YP clients.
The Sun documentation makes it look possible (and I already have the needed
RPC code); does anybody have the rest?
thanx,
Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064
{uw-beaver,decvax!microsoft,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff
-----------------------------
Date: Thu, 5 Dec 85 12:07:03 est
From: allegra!phri!roy at seismo.CSS.GOV (Roy Smith)
Subject: Multibus devices on Sun-3, Ethernet transcievers
We've finally (almost) made up our minds to forget about buying
Sun-2's and get only Sun-3's for the network were setting up. There is,
however, a custom-built Multibus board that was designed for Sun-2's that
we want to get. Lacking any further details (I don't know them yet) does
anybody know if it is possible to put Multibus boards on the VME-bus Sun-3?
I know there is some sort of VME-bus to Multibus adapter available.
Does anybody have any practical experience with it? Unfortunately, while I
have lots of Unibus experience, I've never worked with either VME-bus or
Multibus hardware so I don't even know what kinds of problems to expect.
Are there any pitfalls I should watch out for?
On the software side, are there any vague generalities that can be
made about porting a Sun-2 driver to a Sun-3? What software considerations
are involved in going through a bus adapter? If it involves tearing out
and rewriting half the bus mapping stuff, that's probably more than I care
to deal with.
As a side question, what kind of Ethernet hardware does Sun use? I
like the looks of the Interlan NT100 transcievers; is this what they use?
The removable tap assembly looks like it should be very easy to install and
move around (you just leave the tap in place and move the xciever box to
another one).
-----------------------------
Date: Fri, 6 Dec 85 09:11:31 pst
From: bcsaic!michaelm at uw-june.arpa
Subject: Lisp won't die!
There seems to be a strange bug when you mouse the "Exit" item in the
suntools menu (the Root Window's default menu). It won't kill Lisp!
For instance, if you have the following line in your .suntools menu:
shelltool lisp
and you Exit, the terminal switches back to the 80 x 25 display--almost.
But the mouse pointer is still there, and when you move it over where the
Lisp window was, the pointer changes to a circle with a dot. And the keyboard
hangs; the only way out is to reboot.
Likewise, if you have a /bin/csh window, bring up Lisp in it, then mouse
Exit (without first exiting Lisp), the /bin/csh remains, as does Lisp
(according to ps). This time the keyboard won't hang, although sometimes
the new /bin/csh window occupying the same place that the /bin/csh window
with Lisp was in, hangs.
I haven't been able to reproduce this bug with any other program--rlogin,
nroff, vi, Gnuemacs, etc. all seem to behave OK. So why does Lisp behave
like this?
I've gotten around the problem by always exiting from Lisp before exiting
suntools, but this is a nuisance. It seems like you should be able to set
up the root menu so it first kills off Lisp (using kill), then exits;
but I'm not a C programmer, and I can't figure out how to get the pid of lisp
from within C, so I'm not about to try to modify the routine which handles
exiting from suntools (root_winmgr, I guess). (Or could I use kill (0, 9)?
Will this work in csh?)
By the way, I'm using suntools 2, Frantz Lisp opus 38.91.
Long live Lisp! (by default, I guess)
-----------------------------
Date: Fri, 6 Dec 85 11:52:14 est
From: montanaro at ge-crd.arpa
Subject: A lint problem
I am using lint on a very small program (which follows). I include one
lint library (which follows also). When I use the command "lint -ltpl5
junk.c", I get the following error message:
/usr/lib/lint/llib-port.ln: No such file or directory
I can't find the named file on our Sun. What's it for? Can I get rid
of this message? When I leave out the "-ltpl5" qualifier, no error
message is issued.
Thanks,
Skip Montanaro
montanaro at ge-crd.arpa
[ copy of "hello, world" and llib-ltpl5.ln deleted by moderator.]
[ A bit of investigation and comparing of VAX manual pages and SUN manual
pages shows that there is a -p option on the VAX and SUN which is only
documented on the VAX. The p option checks compatibility with IBM and GCOS
C. The shell file /usr/bin/lint (which fires up all the various pieces of
lint & the pre-processor) checks the arguments twice: in particular, first
for -*p* and then for -l*. Thus, if your library has a 'p' in its name you
turn on portability checking as well as checking your library. (Similarly,
n in the name of the library will turn off portability as a side effect.)
Since you don't have a llib-port.ln, you can delete the first case in
/usr/bin/lint and the problem should go away. ---dsa]
-----------------------------
Date: 4 Dec 1985 15:10:52-EST
From: clapper at NADC
Subject: SunWindows - help
I have been attempting to use SunWindows from within applications code
for the first time. I typed in the example from page 2-3 of
"Programmer's Tutorial to SunWindows." (I've appended a listing of the code
at the end of this letter.) While in the suntools environment, I tried
to run the program - and got the following error message:
EMT trap - core dumped
Next, I compiled the program with the "g" toggle, and used "dbxtool"
to step through its execution. The error seemed to occur somewhere
during my call to tool_select() (tool_select() seems to be calling write.)
The error displayed by dbxtool was:
EMT instruction in write at 0x36c10
00036c10 bad op
A message on the console window corroborated the dbxtool message:
dbx: internal error: couldn't decode op at address 0x36c10
Does anyone out there have any clues?
Thanks in advance.
Brian M. Clapper clapper at nadc.ARPA
Naval Air Development Center
Warminster, PA
-- the code --
#include <stdio.h>
#include <suntool/tool_hs.h>
#include <suntool/msgsw.h>
struct tool *tool;
int sigwinched ();
main (argc, argv)
int argc;
char *argv [];
{
struct toolsw *msg_sw;
if ((tool = tool_make (WIN_LABEL, argv [0], 0)) == NULL)
{
fputs ("can't make tool.\n", stderr);
exit (1);
}
if ((msg_sw = msgsw_createtoolsubwindow (tool, ""
TOOL_SWEXTENDTOEDGE, TOOL_SWEXTENDTOEDGE,
"Hello world!", (struct pixfont *) 0)) == NULL)
{
fputs ("can't create subwindow.\n", stderr);
exit (1);
}
signal (SIGWINCH, sigwinched ());
tool_install (tool); /* install tool in window tree */
tool_select (tool, 0); /* main loop to read input */
tool_destroy (tool); /* clean up. */
}
sigwinched () /* Note window size change and damage-repair signal */
{
tool_sigwinch (tool);
}
-----------------------------
End of SUN-Spots Digest
***********************
More information about the Mod.computers.sun
mailing list