Feb 87 Letters
Volume Number: 3
Issue Number: 2
Column Tag: Letters
Seymour Cray on Macintosh
S.C. Kim Hunter
Mission Viejo, CA
In case you missed this gem from the Wall Street Journal, Dec. 30, 1986, I
thought I’d pass this along to you. It seems John Scully mentioned at the December
Boston conference on high technology how Apple had recently bought a Cray
supercomputer for a cool $14.5 million to design the next generation Apple. This
prompted the following remarks from John Rollwagen, Cray’s chief executive, as
quoted in the Wall Street Journal article: “since they were good enough to buy one of
our machines, some of us have bought a few of theirs.” Later Mr. Rollwagen told
Seymour Cray, the company founder, about how Apple was using the machine, and he
related Mr. Cray’s reaction saying “There was a pause on the other end of the line, and
Seymour said, ‘That’s interesting, because I’m designing the next Cray with an Apple!’
“
Prolog Wanted
Greg Pisanich
Redondo Beach, CA
Hi! Being one of your loyal subscribers, I’ve noticed a real dearth of Prolog
articles in your magazine. I mean, with two seperate advertisers spending all that
money and no articles to help hype their product, you guys should be ashamed! [We
are, e specially since we have one article waiting to run! -Ed] Wait! No! No! Don’t tear
the letter up yet! I’m not writing to criticize! I’m writing to ask for one of your
author’s kit. I’ve been working with prolog on the Mac for awhile now and I’d like to
take a stab at writing a series of articles your your excellent publication. I work at
Hughes Radar, in El Segundo. Our department does software tools, although my work
currently involves an expert system to be used in threat recognition (shoot ‘em down
first!). Some of my school work at UCLA has been done in Prolog as that’s really the
only chance I get to work with it.
C Toolbox Tricks
Jean-Michel Decombe
Paris, France
I have been reading you since the first issue. Since the first issue, I came to the
conclusion that MacTutor is the best magazine for the Macintosh. It would be great if
you could start a Trick Corner, where you would give the right code for the right need.
For example, how to write a zoomrect() function, how to widen the prjobdialog in
order to add buttons, and so forth. Here are some of my tricks in C and now I ask you:
What is the best way to write in the data fork of the running program. I write this and
it works, but I’m not sure it’s the right way to do it. [Is there a right way on the Mac?
(Note, this code has been hand typed.) -Ed]
Writing to the Data Fork of a File in C:
char thename[64];
handle the handle;
int thevolref, theappref;
long thelong;
ptr theptr;
getvol(&thename,&thevolref);
getappparms(&thename,&theappref,&the handle);
thelong=BEFORE;
fsopen(thename,thevolref,&theappref);
fsread(theappref,&thelong,theptr);
fsclose(theappref);
thelong=AFTER;
fsopen(thename,thevolref,&theappref);
fswrite(theappref,&thelong,theptr);
fsclose(theappref);
ZoomRect() Function in C:
zoomrect(srect,drect,expand) rect *srect,*drect; boolean expand;
{
grafptr saveport,deskport;
rect r[17];
long unit;
int count;
getport(&saveport);
getwmgrport(&deskport);
initport(deskport);
penmode(notpatxor);
penpat(&gray);
for(count=0;count<=22;count++) {
if(count<=16) {
r[count]=*srect;
unit=(expand?count+1:33-count)*count/2;
r[count].a.top+=(unit*(drect->a.top-srect->a.top))/136;
r[count].a.left+=(unit*(drect->a.left-srect->a.left))/136;
r[count].a.bottom+=(unit*(drect->a.bottom-srect->a.bottom))/136;
r[count].a.right+=(unit*(drect->a.right-srect->a.right))/136;
framerect(&r[count]);}
if(count>=6)
framerect(&r[count-6];}
penmode(patcopy);
penpat(&black);
setport(saveport);
}
The values employed here are the results of several tests. Before, there were
formulas instead, but I tried, choosed the better values and put them instead of the
formulas, for a greater speed. You must use the function with three parameters: the
source and destination rectangles, in global coordinates, and the expand boolean (fast to
slow or slow to fast zoom effect). Like this:
zoom window(the window,openit)
windowptr the window;
boolean openit;
{
int theint;
rect startrect, windowrect;
setport(the window);
setrect(&startrect,0,0,256,171);
windowrect=the window->portrect;
localtoglobal(& windowrect.b.topleft);
localtoglobal(& windowrect.b.botright);
if(openit) {
zoomrect(&startrect,& windowrect,TRUE);
show window(the window); }
else {
hide window(the window);
zoomrect(& windowrect,&startrect,FALSE); }
}
Likes MPW
Mark Lankton
Boulder, CO
While I’m sitting here I’ll pass on a few thoughts about MPW I’ve been working
with the shell/assembler and the C compiler for about a month, and I’ve got to say I’m
impressed. The shell is extremely powerful, and while it seems un-Mac-like, the
convenience of using it to develop programs won me over in a hurry. I routinely
rebuild a program (after a crash-debug-edit interval) with a single tap of the enter
key that’s tought to beat. The C compiler makes tight, fast code, better than any other
I’ve seen on the mac. There are already a nice bunch of tools around, and you can bet
taht there will be many more in short order. It’s good stuff, and if it isn’t as flashy as
Lightspeed at first glance, well look again. One thing for sure, it has the look of a
system intended for use on some “serious” hardware- so bring on the new machines!
StringOf Bug in LSP
Evan Torrie
Auckland, New Zealand
I was trying to convert one of my MacPascal programs the other day into
Lightspeed Pascal, when I came across the following bug. My Lightspeed version 1.0
will do the first bit okay using NumToString, but when I get to the second bit using
StringOf, the variable j goes haywire and goes into an endless loop after the program
has been run three times successively. [StringOf is buggy in the current version.
-Editor] By the way, I think Lightspeed is the best software development system I’ve
seen for the Mac. What would have taken me hours of frustration to bedug in TML,
takes me only 10 minutes in Lightspeed. The only things I wish for are a compile to
assembly langauge option and 68020 support. [We want those too! And an assembler!
-Ed] Here’s the bug:
program LSBug;
var
i,j:integer;
theString:Str255;
begin
showText;
{NumToString works OK}
for i:=1 to 2 do
for j:=1 to 2 do
begin
NumToString(i,theString);
Writeln(i,j);
end;
{ But StringOf makes the program go haywire! }
for i:=1 to 2 do
for j:=1 to 2 do
begin
theString:=StringOf(i);
Writeln(i,j);
end;
end.
Comments on IC! Bug in NEON
Paul Snively
MacTutor Contributing Editor
I just read the August issue with a great deal of interest and some amusement. As
usual, I devoured Jörg Langowski’s always excellent Threaded Programming column
because he and I have a common interest in threaded languages. To my surprise, he
resurrected the old NEON bug in IC! along with a comment from BIX. There still seems
to be some question as to why the IC! code insists on rebooting upon being executed.
The ADDQ #3,SP instruction is indeed the culprit, although not for the reasons
suggested in the BIX post. The problem does revolve around the fact that the 68000 is
a word addressed processor. The author of IC!, obviously assuming that a byte-length
instruction on a 68000 actually moves one byte, added three to the SP and moved the
resulting byte. This code shows a flawed understanding of byte accesses using the
68000: a byte access always involves two bytes, not one, so the code was wrong from
the beginning. To move a byte from the stack might be done with ADDQ #2,SP followed
by MOVE.B (SP)+,D0. Another problem is that the author of the IC! routine assumed
that the SP could be manipulated like any other address register, which is not the case.
Obviously, the stack register is crucial to the proper operation of the entire system.
In elementary school we learn that adding an odd number to an even one results in
an odd number 100% of the time. Since that is the case, adding three to the contents of
the SP results in an odd SP. One thing that the stack pointer absolutely MUST NOT be
made to do is contain an odd address! Since the 68000 is word addressed, all address
registers - the SP included - must contain even addresses in order to avoid trouble.
An odd address in an address register other than A7 may or may not cause problems -
it depends upon the code. In the case of the SP, however, the situation is more critical
because of the SP’s importance to the system.