Try doing "Get Info" (command-I) on the double-clickable MCL executable
and see if "Open in the Classic environment" is checked.

In our case our laboratory started using MCL back in the late 80's on a
trial basis. After the footing felt comfortable, we transferred our
code and ideas from Genera onto MCL. We have been using MCL ever since
on a daily basis for scientific modelling and engineering R&D work.

Scalability issues have not arisen with MCL. Systems having saved image
sizes in the 30-150 MB range - containing about 800 classes specified
in the application - work well and reliably. No tests have been
performed above these levels since our applications have not required
larger spaces.

Response from Digitool's engineering staff is professional and to the
point. Solutions to bugs are usually issued within a day or two and are
typically final versions as well. However, very few bugs are reported
anymore as the product is mature.  New versions appear regularly on a
yearly or every second year basis.

We find that speed in terms of floating point math or array access is
adequate as is for our exploratory work. For production code one has
the options of coding algorithms more efficiently, using declarations,
or linking to frameworks. For example, many of our digital signal
processing algorithms have been re/written in C, and by using XCode, a
framework is generated that can be efficiently called directly from
Lisp. If speed would still be a factor I suppose the next route would
be to upgrade to faster machines: we currently use PowerBooks and iMacs
and 60-70% of a machine's floating-point performance is achievable with
little work (no use of Altivec). For example, about 1 GFlop on a 1,25
GHz iMac is attainable using LAP or C code, all non-consing.

MCL is robust: recent versions are being deployed in critical real-time
applications where a minute of downtime costs more than MCL along with
the hardware it runs on. OS X + MCL is suitable for environments where
reliability and up-time are non-negotiable.

Porting code to another platform would be a very expensive step for us
due to a large code base spanning 15 years. Our application GUIs are
integrated with MCL's excellent IDE/GUI. What little we have seen of
other platforms makes us believe that the OS X + MCL + CLOS combination
offers an unsurpassed object-oriented environment in terms of future
development potential, stability, and quality of solution attained.
However, if we were to start afresh from a zero code base ... we would
... still choose the OS X + MCL + CLOS trio.

"Raffael Cavallaro"

regards,

However, and this is an important point, Randall Beer has developed a
floating point compiler for MCL/OpenMCL
(<http://vorlon.cwru.edu/~beer/Software/FPC-PPC/FPC-PPC-0.21.lisp> and
<http://vorlon.cwru.edu/~beer/Software/FPC-PPC/FPC-PPC-DOC-0.21.txt>)
which does what one would want. Using it means doing floating point
arithmetic via his fpc-ppc macros, but this is not a major hardship, and
it results in compiled code that conses as little, and is as fast as, or
faster than sbcl and lispworks.

Regards,

Getting back to my original post, apparently I messed up somehow,
because I did another install of MCL 5.0 from scratch, and this time it
runs okay with OS X on the Mac.
(natively, not by way of Apple's "Classic" environment)

I am not at clear about the practical differences between Apple's
"Cocoa" versus "Carbon" environments, guess I had better read up on
them.

I better chalk it up to senility.<g>

Let's face it, when some of us get 75 like I am, there is a good chance
that what little smarts I had will start to drift away.

Oh well,

I will buy the "Practical Common Lisp" as soon as it becomes available.

I have a  _lot_  of catching up to do  :)

I kinda feel the same way about switching "away" from MCL, it could
wind up being more work than it would be worth.

Don't know which way I will jump.   For the time being, think I will
just concentrate on getting back up to speed, and delay my final choice
about which Lisp to use until later.

Thanks!  I had discovered Randall Beer's compiler via Google searching
on the topic, but it's nice to hear an independent endorsement of it.

As Rainer suggested, unless Mac OS X's GUI features are a proper subset
of the existing cross-platform GUI library (CAPI), and they are not,
then those features which exist in Mac OS X (extensive Drag-and-Drop
support, menus independent of views, non-application-modal open and save
dialogs, AppleScriptability) but aren't a part of CAPI will have to be
added as extensions to CAPI, or simply left out. For now, LispWorks has
mostly chosen the latter.

To their credit, they have included some MacOS X specific features, such
as sheets, but unfortunately these have been interpreted as application
modal dialogs attached to windows, because this is the windows/*nix
model of open/save dialogs already implented in CAPI. This defeats much
of the purpose of sheets - that is, apart from their association with a
specific view, sheets should be non-application-modal. For an example,
open two windows - not tabs, but different windows - in Safari, and load
a URL in each. Drop a save dialog on one window, then, with the sheet
still down, switch to the other window. Notice that even with the sheet
still down in one window, the other window still has access to all the
functionality of Safari. This is not possible using CAPI.