info-mac@uw-beaver (04/09/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Tuesday, 9 Apr 1985 Volume 2 : Issue 28
Today's Topics:
Re: Bad MacWrite Files
Calculating Region Areas
Mac C Compilers
ExperLogo
CompuServing
Preserving a Banana
[forwarded] Jackintosh mid-May Intro in Canada
Math Coprocessor
----------------------------------------------------------------------
Date: Fri 5 Apr 85 13:47:05-CST
From: CMP.BARC@UTEXAS-20.ARPA
Subject: Re: Bad MacWrite Files
I received a number of responses regarding the bad MacWrite files I
reported earlier, and thought I'd summarize for the net. It turns out
that there are both avoidance and repair mechanisms. The problem is
that MacWrite sometimes saves files with MacWrite formatting but
labels the files as type TEXT. This situation arises when the file is
saved via the SAVE AS and TEXT ONLY options in MacWrite, but is later
opened and saved via the normal SAVE command. I tried a variety of
controlled experiments, but have been unable to determine any specific
sequence that is responsible for the corrupt files. On the other
hand, by avoiding mixing TEXT ONLY and normal SAVES, I seem to be able
to avoid generating bad files.
More importantly, Apple's Larry Rosenstein told me how to salvage any
such bad files that might arise. One merely uses SetFile (or FEdit)
to change the file type to WORD (instead of TEXT). As a matter of
fact, I had tried SetFile, but my documentation on SetFile incorrectly
indicated that one needed only to set the creator to MACA (as opposed
to CARY). In any case, correcting the worked and my files are back to
normal.
Dallas Webster CMP.BARC@UTexas-20.ARPA
------------------------------
Date: Sun, 7 Apr 85 14:53:47 pst
From: cohn@Berkeley (Ted Cohn)
Subject: Calculating Region Areas
Distribution: net
A simple process-by-illimination technique can be used to find the
area of a given region (i.e., the number of pixels the region
contains). I remember someone posting their interpretation of the
region structure a few months ago, but I lost it. Since I don't know
the internal structure of a region, the QuickDraw routine PTINRGN can
be use repeatedly. Of course, we do know that:
TYPE Region = RECORD
rgnSize: INTEGER;
rgnBBox: Rect;
{Optional region definition data}
END;
The region is, at most, as big as the enclosing rectangle, rgnBBox.
Therefore, the area must be the sum of those pixels that fall within
the region where PtInRgn(point,region) is true. Or, conversely, the
area is also equal to the differnce of the area of rgnBBox and the sum
of pixels not in the region where PtInRgn(point,region) is false. A
simple Pascal function is as follows:
Function AreaRgn(theRgn: RgnHandle): LongInt; var h, v, x1, x2, y1,
y2: INTEGER;
thePoint: point; begin
x1:=theRgn.rgnBBox.left;
x2:=theRgn.rgnBBox.right;
y1:=theRgn.rgnBBox.top;
y2:=theRgn.rgnBBox.bottom;
AreaRgn:=(x2-x1)*(y2-y1); {Find maximum area}
if theRgn.rgnSize > 10 then {If more to region, iterate}
for h:=x1 to x2-1 do {One less than x2 so not to overcount}
for v:=y1 to y2-1 do {One less than y2 so not to
overcount}
begin
SetPt(thePoint, h, v); {A Pascal frustration}
if not PtInRgn(thePoint,theRgn) then
AreaRgn:=AreaRgn-1;
end; end;
If anyone finds a slicker way of finding region areas, I would love to
hear about it! Perhaps knowing the internal structure (already
decyphered?) might lend a hand. Of course, what applications might
this function have? Finding approximate areas of regions on maps in
MacPaint maybe? Who knows.
- Ted Cohn cohn@ucbvax.BERKELEY.ARPA "I'd rather be driving a
Macintosh"
------------------------------
Date: Mon 8 Apr 85 16:33:45-PST
From: Gary A. Craig <Gary@USC-ECLC.ARPA>
Subject: Mac C Compilers
Reply-to: Gary@ECLC
There is an article in the April 1985 "Computer Language" magazine
describing and benchmarking various C compilers currently available
for the Mac. The compilers evaluated are: Consulair C, Manx Aztec C
(level c, their top-of-the-line model), Hippo C (level 2), Megamax C,
and Softworks C. A few paragraphs are devoted to each, describing the
development evvironment, documentation, etc. Tables are also included
for compile/link/run timing and code sizing for a Sieve benchmark, a
Fibonacci benchmark, a pointer dereferencing benchmark, and a floating
point benchmark (for those compilers which support it). They didn't
supply the specific benchmarks used, but they did reference some other
edition where they could be found. In general, the article should be
helpful to those considering a C compiler purchase.
Gary Craig
Gary@usc-eclc
------------------------------
Date: Thu 4 Apr 85 21:43:44-MST
From: Bill Salmon <SALMON@UTAH-20.ARPA>
Subject: ExperLogo
My experience with ExperLogo has been entirely negative, so it
interested me to see the glowing reports here.
I tried ExperLogo in the hopes that it would be useful in teaching a
course here in "The Intellectual Traditions of Computing", for which
we use 128k Macs in the labs.
ExperLogo did a number of anomalous things. It sometimes changed the
case of characters in lists that were processed with LAST or BUTLAST
(I forget which). Its random-number generator kept producing the same
numbers over and over. But worst of all, programs with tail-recursion
often crashed the machine, as did disk-full conditions, and on one
occasion, the system disk was overwritten. (These latter conditions
did not occ on a Fat Mac.)
Our conclusion was that the package was unusable on a 128k Mac, and
that it was so buggy that ExperTelligence must never have bothered to
test it on such a machine. We sent in bug reports in January, but
have heard nothing from them.
Since that time, I have beta-tested Microsoft's forthcoming Logo,
which is clearly a more mature product.
Bill Salmon (Salmon@Utah-20.ARPA)
------------------------------
Date: 4 Apr 85 19:43:52 PST (Thursday)
From: kato.SV@XEROX.ARPA
Subject: CompuServing
CompuServe offers lots of things. There is stock quotation, electronic
mail facilities, CB simulation for multi-person conversation, travel
bureau services, etc... The only thing I really use is MAUG, the
Micronetworked Apple Users Group. This is a group for users of all
Apple computers although the Mac/Lisa group is hoping to become
separate sometime this year. MAUG (actually one of many Special
Interest Groups) offers a BBoard system organized under headings like
Telecommunications, Apple II products, Apple III, Mac/Lisa products,
Mac/Lisa Hacking, and Inside Mac. There are also databases holding
"threads" of interesting conversations that have appeared on MAUG,
reviews of products, data files like MacPaint pictures and music
files, and runnable programs like the Red Ryder communications program
(excellent!) and various desk accessories. The tools included in the
Mac Software Supplement (Icon Editor, Font Editor, Resource Editor)
are also in a database. There are also on-line conference "areas"
where several people can converse ala CB Simulator. There are also
scheduled conferences where a particular guest(s) is featured. Most,
if not all, SIGs are organized this way. There are also SIGs for
Commodore and Atari machines, there's even a PDP-11 SIG. There is also
a general programmer's SIG. There's a LOT! Creative Solutions, makers
of MacForth, also have their own SIG. To go about CompuServing, go to
your local computer store and look for a CompuServe starter kit. There
will be an account ID and password that you can use right away and
some prepaid time. Once you've logged in, you can sign up for regular
CompuServe service on-line. To access all this good stuff, you should
have software to talk over the modem like Red Ryder or MacTerminal (or
MacForth). It does not need terminal emulation but should have a data
capture facility to save stuff to disk. In order to use the database
stuff, you'll need Binhex, the latest is 4.0. It's available in
database section 8 (DL8) : Telecommunications on MAUG. First you
capture a primitive binhex (there are versions for Basic, Forth, and
Pascal). You use it to download the real binhex (called binhex.hex).
Voila! You can now download from CompuServe MAUG.
- gary -
------------------------------
Date: Fri 5 Apr 85 14:05:38-CST
From: CMP.BARC@UTEXAS-20.ARPA
Subject: Preserving a Banana
I noted a slight anomaly in my Banana PC Jr. 6000, resulting from the
posted installation instructions. It seems that when you install the
new desktop in Step 3, it generates some "Get Info" notes for the
System and Finder. However, when you throw away the System and Finder
in Step 4, you also throw away these notes. Moreover, they certainly
won't get regenerated in Step 5, when you install the new System and
Finder. Of course, there is a simple fix, i.e., just reinstall the
Desktop after Step 5. There may be a more elegant way, e.g.,
interchanging Steps 3 and 4. However, I didn't try this, since Tom
Chavez seemed to suggest that the sequencing was critical (and I had
already thrown the files away, and had no interest in retransfering
the large System and Finder files).
Dallas Webster CMP.BARC@UTexas-20.ARPA
------------------------------
Date: Sun, 7 Apr 85 10:08:34 cst
From: werner@ut-ngp.ARPA (Werner Uhrig)
Subject: [forwarded] Jackintosh mid-May Intro in Canada
From jbtubman@water.UUCP Fri Apr 5 13:06:05 1985 Newsgroups:
net.micro,net.micro.atari Subject: Jackintosh mid-May Intro in Canada
This appeared in the Friday, April 5 edition of the Toronto Globe and
Mail. It will be of interest to Canadians and Americans living near
the Canadian border. All figures are in Canadian dollars ($1 CDN =
$0.73 US, approx). Reprinted without permission.
JACKINTOSH TO POP UP IN MID-MAY IN CANADA
By Jonathan Chevreau
The new general manager of recently formed Atari (Canada) Corp. of
Toronto says its 520 ST, or "Jackintosh," personal computer will be
available in Canada in mid-May, one month before it is on sale in the
United States.
The Jackintosh, a colour home computer similar to Apple's Macintosh,
is the brainchild of Jack Tramiel, who recently acquired Atari Inc. of
Sunnyvale, Calif., after being at the helm of Commodore Interational
Ltd. of the Bahamas.
Atari Canada, a wholly owned subsidiary, began operations in January
under Ian Kennedy, director of sales and marketing and soon to be
general manager. He and three other senior executives followed Mr.
Tramiel from Commodore to Atari.
In the days of the video game boom, Atari video games were distributed
in Canada by Irwin Toy Ltd. of Toronto. Irwin still distributes the
2600 game machine, but the new line of personal computers is being
handled by Atari Canada. It is currently operating out of downtown
sales offices, but plans to move to a showcase and warehouse in the
spring.
Mr. Kennedy projected sales of $35-million for 1985. Atari Canada
plans to spend, initially, about 10 to 12 per cent on advertising,
with the figure declining to 7 per cent in later months.
No Canadian R and D or manufacturing is expected in the short term.
The machines use many North American-made components but are assembled
in Taiwan.
While the home computer market has been depressed of late, Mr. Kennedy
expects next Christmas to be a lively contest between Atari and
Commodore. As well as the Atari model, the market will see
Commodore's new Amiga.
The ST's name stands for Sixteen/Thirty-Two -- the number of bits that
can be processed by its Macintosh-like processor. The ST resembles
the Macintosh closely, employing icons or images, a mouse and
pull-down menus.
However, the Jackintosh, and presumably the competitive Amiga, will
cost much less than the Macintosh, and will have a colour monitor.
The Jackintosh will cost $1,300 in Canada for a configuration that
includes the main processor unit with 500 [sic] kilobytes of memory, a
monitor, 3.5 inch disc drive and mouse. Atari also plans to introduce
a 15-megabyte hard disc drive that will cost less than $500, a printer
for about $350, and an integrated software package that costs less
than $100. The package has word processing, telecommunications, data
base management, a spreadsheet and graphics.
------------------------------
Date: 8 APR 1985 10:00 CST
From: C27830AD%WUVMD.BITNET@Berkeley
Subject: Math Coprocessor
I have seen two references, one in DTACK GROUNDED the other in unknown
parts, to Absoft working on a 16081 math coprocessor for the Mac. An
engineer from Absoft contacted Hal at DTACK re using Hal's existing
circuit for the 16081, which Hal agreed to. Any corroboration?
Art Denzau C27830AD@WUVMD.BITNET (314)889-5688
Dept. of Economics Box 1208
Washington Univ.
St. Louis, MO 63130
------------------------------
End of INFO-MAC Digest
**********************