Nov 90 Letters
Volume Number: 6
Issue Number: 11
Column Tag: Letters
SteveForth Corrections 
By Kirk Chase, Editor, MacTutor
SteveForth Correction
Steve Hawley
Mountain View, CA
Recently I discovered that SteveForth, a FORTH system that I wrote, had been
am elated that my work has received a certain measure of exposure in your journal,
and I am grateful for the positive marks from Mr. Langowski.
I am at the same time distressed because SteveForth is also misrepresented in the
very first paragraph. Mr. Langowski write: “There is a new public domain Forth
available in NetLand: SteveForth” I would like to point out that SteveForth is NOT
public domain, nor is it shareware. It is currently in Beta release and is not entirely
stable. I do not feel it is ready for a general release, which is why the following
paragraph appears in the documentation:
“Thanks for volunteering to beta-test SteveForth. I really appreciate it, and as a
token of my appreciation, I have made the source code available to you. I must point
out that I do not want SteveForth to be given away until it has been thrashed
sufficiently by you. I wrote SteveForth in the space of a semester completely by
myself along with a full course load. There’s no possible way it could be completely
stable. I’d like to know who my beta-testers are so I can provide them with patches
and bug fixes as soon as possible. Giving SteveForth to someone else at this stage isn’t
fair to who you give it to, and it isn’t fiar to me, so please don’t do it.”
I am dismayed that Mr. Langowski completely ignored this paragraph (although it
is apparent he read the documentation), and offered to give SteveForth away himself
without contacting me for approval.
SteveForth is currently on the back burner, as I am busy with other projects and
no longer have the convenient access to a Macintosh for development. I anticipate that
it will be ready for shareware release sometime in 1991.
Steve Hawley
hawley@adobe.com
Tool Window Manager - Pascal
Brendan Murphy
Palatine, IL 60067
Included on the source code disk for this month (#62) is a Pascal version of the
Tool Window Manager written by Mr. Fruin [for the December 1989 issue. I have also
included the source on that source code disk, #39-ed]. It was written in TML Pascal II
and I have used it with Think Pascal. I translated it from C to Pascal a month after the
article came out. I thought of sending it in, but then I read the comment Mr. Fruin
made about a Pascal version being forth coming and decided it was not needed. There
are no comments in the file--one of life little pleasures! It seems to be fairly well
debugged, but there are some flaws in the original design of the unit. For example,
being able to float a modeless dialog. The dialog manager gets in the way. Also it is not
flexible enough (makes to many assumptions about how people want to have there
windows float). Future enhancements could include multiple layered groupings of
windows and a more sophisticated multiple active window scheme. Even though I’ve
used this unit, I recommend that people use Think’s Class Library instead because it
has floating windows and you gain all of there other classes! Besides, it is a good idea to
get on the object-oriented programming band wagon before it runs you over. I highly
suggest that MacTutor take a more aggressive role in supporting TCL like MacApp
Developers Association supports MacApp. I don’t see TCL competing with MacApp, but
filling a need where MacApp would be over kill by a factor of ten (which is most of the
time).
Pearl Lisp Update
Stephen E. Miner
Mountain View, CA
Your reader might want to know that my article, “Objects in Pearl Lisp” which
appeared in the August 1990 issue of your magazine, was submitted a while ago. Since
that time, Apple has acquired Coral and discontinued the Pearl Lisp product. Coral’s
Common Lisp product is now known as Macintosh Allegro Common Lisp, and is
available from APDA.
Although the current version of Macintosh Allegro Common Lisp (MACL) still
uses “Object Lisp” implementation of object-oriented programming, the future
belongs to the Common Lisp Object System (CLOS) standard. (See Common Lisp: The
Language, Second Edition, by Guy L. Steele, Jr. for more information on the CLOS
standard.) Apple promises to implement CLOS in the next version of MACL. In the
meantime, an implementation of Portable CommonLoops (PCL), which is evolving
towards the CLOS standard, is available by anonymous FTP from Arisia.xerox.com or
by ordering through APDA.
On a personal note, I’m now working as a Macintosh software consultant at the
Institute for Research on Learning in Palo Alto.
B-Tree References
Melvyn D. Magree
Plymouth, MN
I would like to add some references and thoughts to Clifford Story’s article,
Language Translation, Binary Trees.
First, Niklaus Wirth’s Algorithms + Data Structures = Programs has a good
discussion of tree structures and includes the procedures in Pascal. He discusses
Optimal Trees (which he uses for a compiler example), Balanced Binary Tree, and
B-Trees among others.
I used Wirth’s B-Tree algorithms as the starting point for B-Tree HELPER™,
extending it with reading and writing pages of the tree to a file, managing keys and
records separately, getting and releasing file space in a random file, and searching for
keys less than or greater than a given key.
Second, D. Comer’s “The Ubiquitous B-Tree” gives a history, rationale, and
explanation of B-Trees. His article appears in ACM Computing Surveys, Vol. 11, No.
2, June 1979. He also includes an extensive bibliography.
Comer also explains B*-Trees and B+-Trees. B*-Trees were named by Donald
Knuth in The Art of Computer Programing, Vol. 3, Searching and Sorting. Knuth
proposed that B*-Trees had nodes that were at least 2/3 full rather than 1/2 full.
Many people use the name B*-Tree for another B-Tree variation proposed by Knuth.
Comer says that Knuth did not name this variation, but Comer chooses to call it
B+-Tree. B+-Trees have all keys in the leaves of the tree. The leaves are also linked
from left-to-right making B+-Tree ideal for sequential search. The disadvantage is
that some keys are duplicated several times, but there are ways to reduce the storage
requirement. I did not use B+-Trees in B-Tree HELPER.
If any reader is looking for a good research topic for a paper or article, consider
doing an update on “The Ubiquitous B-Tree”.
Mac286
Orange Micro, Inc.
1400 N. Lakeview
Anaheim, CA 92807
(714) 779-2772
You can now have the best of both worlds. Orange Micro’s Mac286 is a 8MHz,
Intel 08286 board fro the Mac II. It literally is a second computer in your Macintosh.
With the Mac286, you can execute DOS applications in one window, while you run Mac
Programs in another. The Mac286 makes your Mac a full AT compatible. And since
this is a hardware/software solution, you will get higher performance than just
software solutions. There is also Mac86, a XT compatible board for the Mac SE.
New Product Compatibility Checklist
Kirk Chase
MacTutor
With Apple’s introduction of new products, Apple sent a compatibility letter over
AppleLink. The new CPUs will be running System 6.0.6. For those who are not on
AppleLink, here is a brief synopsis of the compatibility check list found in that letter.
1. Your application should not write directly to hardware (e specially ADB or SCSI).
It should call the appropriate system software managers.
2. Do not assume the presence of a floating point unit (FPU) on 68020 and 68030
machines. Always check for it explicitly. The July 1990 issue of Apple Direct
(FYI on page 4) discusses this and has more information about how to check for
the presence of an FPU.
3. Do not assume monitor pixel resolution (particularly for the color monitor).
Check explicitly for the monitor resolution. See “Inside Macintosh”, Volume V,
chapters ‘Color QuickDraw’ and ‘Graphics Devices’ for more information.
4. Do not assume the dimension of a monitor (i.e. 640x480). Check explicitly for
the monitor size. Always follow the Apple guidelines and size windows
automatically according to Technical Note #2.
5. System Software 6.0.6 and System Software 7.0 share the same Sound Manager.
Every effort has been made to keep applications that properly addressed the old
Sound Manager from breaking. You should carefully check your application with
System 6.0.6 for compatibility. MacinTalk will NOT work with System 6.0.6 or
System 7.0. If your application requires Macintalk, you will need to rewrite the
sound portion of your application for the new Sound Manager.
5a. There is Sound Manager incompatibility between HyperCard 1.2.5 and the Sound
Manager in System Software 6.0.6. This sound incompatibility will exist with
the Sound Manager in all System Software releases beginning with System
Software 6.0.6. However, HyperCard 1.2.5 can run under System Software 6.0.6
if the sound is set to 0 in the Sound CDEV before starting HyperCard. This
incompatibility is fixed in HyperCard 2.0.
6. Macintosh SE/30 expansion card developers need to check for several things:
• Cards should be clock/speed independent
• Cards should take CPUCLK off of pin A38 and take C16M off of pin C38
• Cables should be at least 8.6 inches long
• Cards need to fit the latest form factor guidelines described in “Designing
Cards and Drivers for the Macintosh Family, Second Edition”.
7. Nubus expansion card developers need to check for several things:
• Cards should be within the NuBus power specification for ONE slot
• Those cards which exceed the power specification for ONE slot should come
with documentation that alerts customers that the card should be used in a
machine with multiple slots.
• Cards need to fit the latest form factor guidelines described in “Designing
Cards and Drivers for the Macintosh Family, Second Edition”.
• Do not assume that memory is a contiguous physical range. Logical addresses
may not be the same as physical addresses. Master NuBus cards that may
make accesses to the Macintosh RAM space need to be aware of this and use the
appropriate Virtual Memory Manager calls to determine the physical memory
locations. See “Inside Macintosh”, Volume VI for more details.