LETTERS

TOOLFRONTEND FIXES
Thanks to Tim Maroney for his excellent column on ToolServer and CodeWarrior (develop Issue 25). But there's a bug in ToolFrontEnd that causes CodeWarrior IDE 1.5b2 to throw away the preferences every time I use it. In case you're interested, I have the solution to the problem. In addition, I've fixed a dialog for the CodeWarrior 8 API and cleaned up the code for the new API.

This bug aside, this excellent little utility has helped me a lot in my development.
-- Andreas Magnusson

Thank you for the bug report. I've created a new version of ToolFrontEnd that contains your bug fixes and others; it can be found on this issue's CD. The plug-in API was in a state of flux when I wrote ToolFrontEnd -- the new API documentation arrived on the day of my deadline for the CD, so there was no opportunity to adapt my first release for it.

FONTTOPICT SNAFU
Regarding this code in FontToPict in Issue 25's Print Hints column:

MakePSHandle(qdFont, qdStyle,myEncoding, &picCommentHdl);
PicComment(kPostScriptHandle,GetHandleSize(picCommentHdl),
    piccommentHdl);

I recall that the second ar gument to PicComment is a word, which means you can't have a picture comment bigger than 32767 bytes. I think Type 1 fonts are usually quite close to this size. Should people be worried about this?
-- Lawrence D'Oliveiro

Color me stupid. You're right, people should be worried about this when they're sending the whole font. Hopefully you'll be sending only the portion of the font that you'll actually need, so the data requirements will be less. But if you're not, you need to break up the font data or use another mechanism to send it to the printer. Sorry about that.
-- Dave Polaschek

SCRIPTABLE DATABASE UPDATE
When I try to use CodeWarrior 7 to compile Greg Anderson's Scriptable Database 1.0a11 (from his article on whose clause resolution in develop Issue 24), I get the following link error:

: mpwexit.c: '__cleanupandexit__'
referenced from '_exit' is undefined

How can I fix this?
-- Jean Jourdain

GOOD TIMING
Thanks to Martin Minow for his "Timing on the Macintosh" article on develop's CD. It saved me from having to hunt down and strangle whoever wrote "you must write an application-defined routine that calculates the elapsed time" in Inside Macintosh: OS Utilities and then didn't supply one.
-- Isidore Ducasse

OODL(E)S OF SPEED IN LISP
Dave Johnson's excellent column on OODLs in Issue 24 is informative and straight to the point. When he's talking about the overhead associated with dynamic languages, however, he's not quite up to date. Dynamic languages need not be slower than static languages. They can be, if the programmer isn't interested in speed. But on the other hand, numerical code in a modern LISP is every bit as fast as FORTRAN or C code, if the programmer cares to add a few declarations. There's no need to add external modules for speed nowadays.

True, some dynamic languages have a lot of runtime overhead, but LISP isn't one of them. This fact needs to be emphasized to programmers, not the obsolete idea that LISP is a slow and memory-hungry dinosaur. Interpreted LISP might have been slow 15 years ago, but so was BASIC. Unfortunately, many programmers still think LISP is interpreted, and the comparison between a compiled language such as modern C or Pascal with an ancient interpreted LISP implementation is simply not fair, nor is it correct. With Common LISP, lexical scoping, and modern compiler technology, LISP can be just as fast as any static language. So, your example of a QuickDraw 3D renderer in LISP is in fact an excellent idea.
-- Peter Bengtson

TOOTING OWN OUR HORN: develop WINS BIG IN COMPETITION

We're happy to announce that develop has won top honors in the STC' s 1995 Northern California Technical Communications competition. STC is the Society for Technical Communication, an international organization of more than 18,000 writers, editors, and other technical communicators. In its category of Monthly or Quarterly Magazines, develop won not only the highest-level award, Distinguished Technical Communication, but also Best of Category. It then went on to win a Merit award in the STC's International Technical Publications Competition.

We're going to indulge ourselves here and list some of the judges' comments that we're particularly fond of.

It's nice to get feedback like this from the competition judges, but you, our readers, are the judges who count the most. You're the ones we want to be sure are happy with develop. We'd like to take this opportunity to thank you for the valuable input you've given us over the six and a half years of develop' s existence, and to ask you to please keep it coming. Without your support and encouragement -- and your critical feedback -- we wouldn't be what we are today.

ALL OPINIONS ARE INVITED We welcome your letters to the editor, especially regarding articles published in develop. Write to Caroline Rose (crose@apple.com or AppleLink CROSE) or, if technical develop-related questions, to Dave Johnson (dkj@apple.com or AppleLink JOHNSON.DK). All letters should include your name and company name as well as your address and phone number. Letters may be excerpted or edited for clarity (or to make them say what we wish they did). Address subscription-related queries to order.adc@applelink.apple.com or AppleLink ORDER.ADC. *