> I am fairly sure there is no more recent version.
> > This supposed version "5.0" MCL will definitely not run on OSX > > "natively", it requires the so-called "classic" environment.
> > Yet confusingly version 5 is right now advertised on Digitool's website > > as being able to run native on OSX.
> It does run native on OS X. I don't even have the Classic environment > installed on my Mac, but I run MCL 5.0 without any problems. > Something must be wrong with your MCL install, I guess. Have you > tried asking on the MCL mailing list?
(To the original poster:)
Try doing "Get Info" (command-I) on the double-clickable MCL executable and see if "Open in the Classic environment" is checked.
-bcd -- *** Brian Downing <bdowning at lavos dot net>
> That is my main question here, is Digitool's product really worth the > high prices they charge, ...
I find it hard to argue that the price Digitool charges for MCL should be lower. It is much easier to find reasons why the price they charge is too little given the quality of their product and what one can do with it. But that is not our problem but rather Digitool's.
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.
I have practically no experience with any other Lisps except MCL so my comments are only a reflection on my ability to do work efficiently using Digitool's product. I am not in the advantageous position of being able to try out other Lisps. Time is of the essence and is most effectively spent on solving actual problems in a proven environment. If it's a case of "ignorance is bliss", so be it.
In article <joswig-A17F2B.22424421022...@news-50.dca.giganews.com>, Rainer Joswig <jos...@lisp.de> wrote:
> BUT, LispWorks is also far away from what would be possible > under Mac OS X. If one would develop a good native Lisp IDE > on Mac OS X, it would be possible to go far beyond what > LispWorks does support. Actually I think there is an > opportunity for a commercial Lisp with a much better > Mac-OS-X-like user interface and much better support > for and integration of Mac OS X technology (Webkit, > SpotLight, Quartz Extreme, the font engine, Quicktime, > AppleEvents, Rendezvous, iLife, Interface Builder, ...). For Mac OS 9, > MCL was this Lisp. On Mac OS X there is currently no Lisp > that targets the Mac OS X that way.
I couldn't have put it better myself. Lets hope that someone takes up this challenge.
In article <wj0fyzpu3c6....@five-percent-nation.mit.edu>,
rif <r...@mit.edu> wrote: > Can you elaborate on the "slow floating-point and arrays" in MCL and > OpenMCL? I'm assuming they don't store typed arrays natively in > memory?
Basically, with proper declarations, one would like a common lisp compiler to generate code that does unboxed floats, typed native arrays, and in-place, destructive modfication of said array elements. sbcl will generate this sort of code, which is fast and conses less. MCL/OpenMCL often will not, even with everything declared.
> > LispWorks is by far the best Lisp for Mac OS X right now - > > especially because of the Cocoa-based IDE.
> If you like or need to use Cocoa...
The Cocoa stuff isn't that bad...
> Personally I like Carbon just fine. Most large developers (Adobe, MS, > etc.) do not seem to have plans to buy into Cocoa anytime soon. In the > end it's a choice.
On the other side many small developers are fast switching to Cocoa, because it enables small teams to develop software competetively. Actually it has quite a bit of Lisp/Smalltalk feel - Interface Builder, Message Sending, ...
> However, and again this is a personal note, I really > dislike the LispWorks IDE. Functionality is great but the interface, > very much uncorrelated to the use of Cocoa or Carbon, violates just > about every Apple Human Interface Guidelines wrt document management > and text editing. From little details such as the cursor to much larger > issues such as the notion of Editors and buffers is all done in an > extremely dated pre-window, EMACS on VT100 type of way. Drives me > crazy. I can switch between individual windows just fine and really > like to have them.
Set the preference not to reuse windows and you get new windows all the time. Even editor windows. That's not a problem - I work that way with LispWorks and switch with the usual Command-< and Command-> between the windows.
>> Don't get me wrong. For the frequent Windows/Linux and occasional OS X > user LispWorks may be indeed the best CL out there. For the dedicated > Mac users however this is an interface nightmare. Xanalys should have a > good look the Apple guidelines and play with some of the non LISP IDEs > on OS X including Apple's XCode.
Oh, generally I agree. Apple's native interface is quite nice - it is just hard to map the cross-platform CAPI to it. For example Mac OS X has other ideas of icons, icon-palettes, icon sizes, palette configuration windows, etc. You would need to write platform specific code for Mac OS X. Seems like the LispWorks developers want to have it handled by their framework - but that doesn't let you go very far. Another example: If their framework does not handle drag&drop, there is no chance the IDE will suddenly support all the drag&drop interaction that you are used to on Mac OS X.
> I'll rate these on the categories that would matter to most Mac OS X > programmers - Carbon, Cocoa, speed (of compiled code), compiler, and > issues (i.e., problems), and unusual features. > ...<snip>...
Thanks very much for those ratings of the various Lisp App's, with their strong points and weak points.
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.
In article <1109103783.896084.306...@o13g2000cwo.googlegroups.com>,
<toomas.altos...@hut.fi> wrote: > I have practically no experience with any other Lisps except MCL so my > comments are only a reflection on my ability to do work efficiently > using Digitool's product. I am not in the advantageous position of > being able to try out other Lisps. Time is of the essence and is most > effectively spent on solving actual problems in a proven environment. > If it's a case of "ignorance is bliss", so be it.
I appreciate your comments about MCL.
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.
In article <c366f098.0502230130.640ac...@posting.google.com>, jos...@corporate-world.lisp.de (Rainer Joswig) wrote:
> For example > Mac OS X has other ideas of icons, icon-palettes, icon sizes, > palette configuration windows, etc. You would need to write > platform specific code for Mac OS X. Seems like the LispWorks > developers want to have it handled by their framework - but that > doesn't let you go very far. Another example: If their framework does not > handle drag&drop, there is no chance the IDE will suddenly > support all the drag&drop interaction that you are used > to on Mac OS X.
Another immediately noticeable example: Windows and *nix GUIs assume that menus are *always* associated with and attached to a view/window. This is, of course, not the case with MacOS (both Classic and Mac OS X) - Mac apps can and do have a menu bar with functioning menus even if there are no open windows. As a result, CAPI will not let you create a menu without any windows.
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.
Let's hope that with time various MacOS X specific GUI features will find their way into LispWorks, either directly from the vendor, or via user contributed code.
> 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.
I don't think it has anything to do with CAPI Windows/*nix legacy. I think the problem is that all interfaces share a single thread on the Mac unlike the other platforms. In fact, I was rather horrified recently when using LispWorks on Motif. The open dialog (and perhaps others) is *not* modal. You can choose Open and then go back to editing your document without doing anything with the dialog.
In article <gWdTd.9967$x53....@newsread3.news.atl.earthlink.net>, John DeSoi <de...@pgedit.com> wrote:
> I don't think it has anything to do with CAPI Windows/*nix legacy. I > think the problem is that all interfaces share a single thread on the > Mac unlike the other platforms. In fact, I was rather horrified recently > when using LispWorks on Motif. The open dialog (and perhaps others) is > *not* modal. You can choose Open and then go back to editing your > document without doing anything with the dialog.
This is worse than I thought - there's really no excuse for this. The common GUI intersection that is CAPI should behave the same on all platforms. Oh well, I'd resigned myself to doing a fair bit of low level Cocoa stuff anyway...
Ulrich Hobelmann <u.hobelm...@web.de> writes: > Mark Conrad wrote: > I don't know. I have Lispworks (Personal Edition, i.e. free trial) > running on my Mac, mostly because the Emacs port sucks and I want *an* > IDE). You might want to check that out.
What do you dislike about the GnuEmacs support for OS X? 22.214.171.124 is what I'm running and it seems to work fine.