SteveForth Corrections

By Kirk Chase, Editor, MacTutor

SteveForth Correction

Steve Hawley

Recently I discovered that SteveForth, a FORTH system that I wrote, had been given a brief write-up in MacTutor Magazine by Jörg Langowski [April 1990-ed.]. I 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

Tool Window Manager - Pascal

Brendan Murphy

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

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

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.

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

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 (especially 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.