June 96 - Letters
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.
I'm glad to have helped in your development; that's the real reason I write these things.
-- Tim Maroney
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
You can't fix it; that version of the Scriptable Database won't compile with CodeWarrior 7, only with
CodeWarrior 6 (I'll spare you the gory details). But the new version on this issue' s CD (1.0a15) has been
updated so that it works fine with CodeWarrior 7 and later. Sorry for any inconvenience.
-- Dave Johnson
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
Inside Macintosh can't supply code for everything; I'm glad develop could help fill the gap. Note that the
Timing article has been updated on the CD.
-- Caroline Rose
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
You're right, of course. Writing time-critical, number-crunching code in LISP is eminently practical now.
Among dynamic languages, LISP in particular has matured in a big way and is now almost a hybrid
language: full dynamism if you want it (with some accompanying overhead) or, with appropriate declarations
and "explicitness of purpose" by the programmer, the speed (and brittleness!) of a static language. In a
sense, it's the best of both worlds, letting the programmer decide what best fits the situation. So yes, my
example was flawed, though I hope the spirit of it came through despite this.
-- Dave Johnson
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.
- The writing was very focused and stuck to the article's point. All articles seemed very informative.
- Very well organized and well laid out.
- The voice is very personable without being overly familiar.
- The articles use humor appropriately. The material is very readable.
- develop is a very polished, engaging publication from beginning to end.
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. *
