|
||||||||||||||||||||||
|
MCL Support
Support Options
Per-incident support from DigitoolTechnical support for MCL is available on a pay-per-incident basis direct from Digitool engineers. This includes answering a technical question or providing the applicable patch. Per incident support is via email and is priced according to the complexity of the incident. The basic incident cost is $25 and typically covers most questions regarding patches, errors, etc. If your question or problem requires substantially more work and custom code writing on the part of our engineers, they will quote the cost as appropriate. Submit your technical support questions by using the following link. Your credit card payment (or otherwise) is handled securely via the MoneyedMail service: You must CC MoneyedMail in your email as per the link above. Once you've submitted your question, you'll receive email instructions from MoneyedMail for processing your credit card payment via a secure web page.
|
|||||||||||||||||||||
| Support Questions | Programming Questions | General MCL Questions |
It is likely that your toplevel-function neglected to call (startup-finished), a new "feature" of MCL 2.0.1 that is documented in the release notes. This feature makes it possible to print from the Finder when printing requires launching the MCL app.
Here is the relevant section of the release notes:
New startup housekeeping
In order to make printing from the Finder work correctly, high level events are disabled until MCL's startup code enables them. If you call SAVE-APPLICATION and specify a value for the :TOPLEVEL-FUNCTION parameter, your toplevel function must evaluate the following form (either directly, or indirectly via a call to CCL::STARTUP-CCL):
(startup-finished)
You should do this after processing the (FINDER-PARAMETERS). If you neglect the call to STARTUP-FINISHED, your application will not receive any high level events (e.g. AppleEvents).
Try turning off the :async bit in the #_control trap in %tcp-control and see if that helps.
| Support Questions | Programming Questions | General MCL Questions |
Macintosh Common Lisp (MCL) is an object-oriented dynamic language (OODL) from Digitool, Inc. and Apple Computer, Inc. It implements the industry standard Common Lisp programming language and CLOS (as defined in Common Lisp: The Language, second edition), and is fully integrated with the Macintosh family of personal computers.
MCL is a completely integrated development environment, including a fast incremental compiler which produces efficient native PowerPC or 680x0 code (with MCL 4.3.1 and 3.4, respectively), a window-based debugger, a source code stepper, a dynamic object inspector, a stack backtrace inspector, a programmable Macintosh-style emacs-like editor, online documentation, and an interactive interface toolkit. MCL provides both high-level object-oriented user interface class library and complete low-level access to the Macintosh Toolbox.
Using MCL, you can create a standalone double-clickable Macintosh application using less than 2MB of disk space which can be run with 2MB or more of memory.
MCL is available directly from Digitool, Inc. Here are the price and ordering details.
Yes. See the MCL Price List for details.
To determine compatibility with specific Macintosh models, see the following FAQ: Which version of MCL runs on what hardware?
MCL 3.0 adds support for multiple processes and considerably extends the functionality of the editor Fred and the debugging tools.
The 2.01 version of the ptable init is available for anonymous FTP from digitool.com:/mcl2/patches/ptable-2.01.hqx.
Also note that MCL 3.0 runs on System 7, though System 7.5 or better is highly recommended.
Absolutely. Digitool shipped the first PowerPC native release of MCL in May 96 and a further performance tuned version in October 96.
Note that "works" or "does not work" below means "MCL runs with the board installed and enabled" or "MCL crashes with the board installed and enabled", respectively.
Daystar Turbo '040 33 MHz
works on IIci with MMU4-for-IIci patch.
Should work on other machines, but this is untested.
Daystar Power Cache 50
Works on a IIci.
Radius Rocket 25
Should work on IIci with MMU4-for-IIci patch, but this is untested. Does not work with RocketShare on any machine, but will work with RocketWare.
Radius Rocket 25i
Centris-without-FPU patch will make it work, but this is untested. Also needs MMU4-for-IIci patch on a IIci.
Again, will work with RocketWare, but not RocketShare.
Radius Rocket 33
Seems to work on IIci.
Tokamac 25Mhz
Doesn't work on IIci. Should work with MMU4-for-IIci patch, though this is not tested.
RasterOps 24XLTV
Does not work on Mac II.
MCL complies with the current industry standard for Common Lisp, as defined in "Common Lisp: The Language", second edition, by Guy Steele. This should guarantee a high degree of compatibility with Common Lisp implementations on many other platforms.
This specification changed somewhat between the first and second editions; please consult the second edition for descriptions of the changes.
The Common Lisp Interface Manager (CLIM) is a cross-platform User Interface toolkit, which allows you to create user interfaces for Lisp applications that will run on Macintosh, Windows, Motif (X Windows), and Symbolics Lisp Machines. CLIM 2 is available now for MCL.
MCL was originally developed by a small company in Cambridge, Mass. called Coral Software, under the name "Coral Common Lisp" (CCL). Later, Coral entered a marketing agreement with Franz, Inc., a major vendor of unix-based Lisps, to sell the Coral product under the name "Macintosh Allegro Common Lisp" (MACL).
In 1988, Apple Computer purchased Coral and its assets. In 1992, the 2.0 version of the product was renamed to Macintosh Common Lisp, or MCL. In 1994, MCL was acquired by Digitool, Inc. a new company started by principals of Paradigm Software and members of the Apple MCL development team.
Digitool is continuing to enhance and support MCL in a variety of ways. Digitool often posts patches for MCL on the ftp site. A performance tuned PowerPC native version of MCL is out. MCL has a bright future indeed!
The ptable init initializes the memory management hardware (if present) in such a way that MCL can use it to make ephemeral garbage collection (EGC) more efficient. Since it deals at a very low level with both the hardware and the operating system, it is vulnerable to minor changes when a new Macintosh model or operating system version is released.
MCL will always run without the ptable init. In most configurations, just running the ptable init will slow down all memory accesses until you restart without it. The slowdown isn't very large, but you will have to decide whether or not the benefit of improved EGC performance is worth the cost, depending upon your exact usage of MCL and your Mac.
You should probably use the ptable init only if all of the following are true:
* Your Macintosh's CPU is an 040, 030, or 020 (with a PMMU installed), and
* You prefer to run MCL with EGC enabled
| Support Questions | Programming Questions | General MCL Questions |
| MCL and Macintosh Common Lisp are trademarks of Digitool, Inc. Apple, the Apple logo, and Macintosh are trademarks of Apple Computer. All other trademarks mentioned herein belong to their respective owners. Last update: Fri, April 12 2002 |
| Copyright © 2000-2002 Digitool, Inc. |
| Web design by David & Nick Lamkins |