I am really confused about MCL.
Years ago I bought the MCL version that runs on a Mac. That version
was "created" on Friday, Nov-1st, 2002 at 4:38 PM. It was supposedly
"version 5", although the file itself was listed as version 5.5
In any event, that version will not run "native" on Mac OS X.
As I recall, I think I paid about $700 for it, however I got
sidetracked and never used it to develop any programs for sale.
Now Digitool is advertising a "native OS X" version 5 on their website
!!!
I am getting disgusted with these version games and Digitool's high
priced licenses.
What, pray tell, do Lisp developers use nowadays to develop commercial
software when using a Mac. Do they still use MCL, or some other
development environment.
FWIW, Digitool's prices seem out of line to me. I don't mind paying
for a good development environment if it is really needed.
That is my main question here, is Digitool's product really worth the
high prices they charge, or do present-day CL developers use other
lower priced development environments?
Any opinions one way or the other appreciated, before I goof and buy
more Digitool software.
Mark-
Mark Conrad wrote:
> What, pray tell, do Lisp developers use nowadays to develop commercial
> software when using a Mac. Do they still use MCL, or some other
> development environment.
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.
Also, what do you mean by developing commercial software? Or, more
specifically, what about commercial software doesn't allow you to run
something open-source like OpenMCL or SBCL?
What are your requirements to a Lisp IDE?
In article <···············@individual.net>, Ulrich Hobelmann
<···········@web.de> wrote:
> What are your requirements to a Lisp IDE?
I do not know that yet, I am just returning to Lisp after a long
absence, so have to review/update my Lisp knowledge which will take a
fairly long period of time.
I just do not want to be handicapped by a cramped development
environment, when I _do_ become productive.
Mark-
Ulrich Hobelmann <···········@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?
21.3.50.2 is what I'm running and it seems to work fine.
--jon
"Mark Conrad" <············@invalid.com> schrieb im Newsbeitrag
····································@invalid.com...
...
> What, pray tell, do Lisp developers use nowadays to develop commercial
> software when using a Mac. Do they still use MCL, or some other
> development environment.
...
Mark,
I found a nice article on OpenMCL at
http://homepage.mac.com/svc/RebelWithACause/index.html
To me this seems a professional application.
Lispmeister.com has some reference to Cocoa and OpenMCL.
I'm no Mac developer so these are only hints.
Andreas
LispWorks costs more then Digitool but I had good experiences with it
on the Mac. Objective-C bindings make developing Cocoa apps easy. It
does not generate shared libraries out of your Lisp code, though.
"Joel Reymont" <······@gmail.com> writes:
> LispWorks costs more then Digitool but I had good experiences with it
> on the Mac. Objective-C bindings make developing Cocoa apps easy. It
> does not generate shared libraries out of your Lisp code, though.
What exactly do you mean by "generate shared libraries out of your
Lisp code?" I'm not familiar with this terminoilogy.
Cheers,
rif
On 21 Feb 2005 12:13:39 -0500, rif <···@mit.edu> wrote:
> What exactly do you mean by "generate shared libraries out of your
> Lisp code?" I'm not familiar with this terminoilogy.
I guess he means shared libraries as in ".dll" on Windows or ".so" on
Linux/Unix.
<http://www.lispworks.com/documentation/lw44/DV/html/deluser-81.htm>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
> I guess he means shared libraries as in ".dll" on Windows or ".so" on
> Linux/Unix.
>
> <http://www.lispworks.com/documentation/lw44/DV/html/deluser-81.htm>
>
> Edi.
Ah, I think I see. So that link says that you can do it on Windows,
but you can't do it on OS X or Unix?
What CL's can generate .so's? I've never seen that done.
rif
On 21 Feb 2005 12:26:06 -0500, rif <···@mit.edu> wrote:
> What CL's can generate .so's? I've never seen that done.
<http://www.franz.com/support/documentation/7.0/doc/unix-shared-library.htm>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Duane Rettig
Subject: Re: MCL for OS X worth the price?
Date:
Message-ID: <4vf8lk8d7.fsf@franz.com>
Edi Weitz <········@agharta.de> writes:
> On 21 Feb 2005 12:26:06 -0500, rif <···@mit.edu> wrote:
>
> > What CL's can generate .so's? I've never seen that done.
>
> <http://www.franz.com/support/documentation/7.0/doc/unix-shared-library.htm>
Note that the link to the MacOSX specific section says that the
shared-library example doesn't work, because of the way the
test is set up (which assumes that a shared-library is relinkable
as well as loadable.
The problem is that MacOSX makes a distinction between loadable libraries
and linkable libraries; the former are called "bundles", and once the
bundle is built, it can't be broken up for relinking. The linkable
libraries can't be loaded in the same sense as the bundles. However...
Thanks to Mikel Evans, we were able to simulate loading of linkable
libraries in 7.0 - this is done by actually _adding_ the contents
to the running image. There is still a problem though; once you
load a shared-library, you can't unload it again (as you can do
in Allegro CL on all other operating systems). This also means that
if you cl:LOAD a shared-library that had already been loaded after
you had changed it, it can't be done, because the old one can't be
unloaded.
This puts a crimp in the style many users use of loading shared-libraries
in a lisp-like way. However, it does offer some additional benefit,
as long as reloading and unloading is not needed.
The reason we have left the documentation alone is because the addition
is not complete as far as we are concerned. But users of 7.0 will notice
that if they try to load a non-bundle shared-library into their lisp,
it will no longer fail with the "Must be a Mach-O MH_BUNDLE file."
error. So, for example, you can do something like this:
CL-USER(1): (push nil *load-foreign-types*)
(NIL "dylib")
CL-USER(2): (load "/System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa")
; Foreign loading /System/Library/Frameworks/Cocoa.framework/Versions/Current/Cocoa.
T
CL-USER(3):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Mon, 21 Feb 2005 12:26:06 -0500, rif wrote:
>
>> I guess he means shared libraries as in ".dll" on Windows or ".so" on
>> Linux/Unix.
>>
>> <http://www.lispworks.com/documentation/lw44/DV/html/deluser-81.htm>
>>
>> Edi.
>
> Ah, I think I see. So that link says that you can do it on Windows,
> but you can't do it on OS X or Unix?
>
> What CL's can generate .so's? I've never seen that done.
ECL, IIRC.
RalfD
> rif
rif wrote:
>>I guess he means shared libraries as in ".dll" on Windows or ".so" on
>>Linux/Unix.
>>
>> <http://www.lispworks.com/documentation/lw44/DV/html/deluser-81.htm>
>>
>>Edi.
>
>
> Ah, I think I see. So that link says that you can do it on Windows,
> but you can't do it on OS X or Unix?
>
> What CL's can generate .so's? I've never seen that done.
>
Apart from LWW, there's ACL and ECL. Corman Lisp is essentially a DLL.
Others may as well.
Cheers
--
Marco
In article <························@c13g2000cwb.googlegroups.com>,
Joel Reymont <······@gmail.com> wrote:
> LispWorks costs more then Digitool but I had good experiences with it
> on the Mac. Objective-C bindings make developing Cocoa apps easy. It
> does not generate shared libraries out of your Lisp code, though.
Thanks, I do not know how important shared libraries are, seems they
would make for less bulky applications, though.
Hmm, that gives me something to check on the other IDEs like MCL for
example. If MCL supports shared libraries, it might be worthwhile.
Mark-
In article <···············@news.t-online.com>, Andreas Thiele
<······@nospam.com> wrote:
> > What, pray tell, do Lisp developers use nowadays to develop commercial
> > software when using a Mac. Do they still use MCL, or some other
> > development environment.
>
> I found a nice article on OpenMCL at
> http://homepage.mac.com/svc/RebelWithACause/index.html
> To me this seems a professional application.
> Lispmeister.com has some reference to Cocoa and OpenMCL.
Thanks, I will check that out.
Basically, I am just thrashing around, trying to renew my ancient Lisp
knowledge.
Perhaps I had better concentrate on that, and worry about
development-environments later.
When I left off my Lisp education years ago, I was throwing a saddle on
concepts like continuation-passing-style, code-walkers, compilers, etc.
and actually managed to understand a bit of Lisp.
One of my reference books is "Essentials of Programming Languages",
however nowadays I imagine that old 1994 book is dated/obsolete.
I surely wish I could find more _good_ recent books as "good" as that
fine old book.
Oh well, old books are better than no books.<g>
What I really need, I guess, are some books on how to put all that
ancient knowledge to work for some constructive purposes.
Mark-
Mark Conrad <············@invalid.com> writes:
> I surely wish I could find more _good_ recent books as "good" as that
> fine old book.
That's easy:
Successful Lisp: How to Understand and Use Common Lisp
(it's so new that the ink has not dried yet)
http://www.psg.com/~dlamkins/sl/cover.html
Practical Common Lisp
(to be published around April)
http://www.gigamonkeys.com/book/
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
In article <··············@plato.moon.paoloamoroso.it>, Paolo Amoroso
<·······@mclink.it> wrote:
> > I surely wish I could find more _good_ recent books as "good" as that
> > fine old book.
>
> That's easy:
>
> Successful Lisp: How to Understand and Use Common Lisp
> (it's so new that the ink has not dried yet)
> http://www.psg.com/~dlamkins/sl/cover.html
>
> Practical Common Lisp
> (to be published around April)
> http://www.gigamonkeys.com/book/
Thanks, I have the "Successful Lisp", it is a good one.
I will buy the "Practical Common Lisp" as soon as it becomes available.
I have a _lot_ of catching up to do :)
Mark-
Mark Conrad <············@invalid.com> writes:
> I am really confused about MCL.
>
> Years ago I bought the MCL version that runs on a Mac. That version
> was "created" on Friday, Nov-1st, 2002 at 4:38 PM. It was supposedly
> "version 5", although the file itself was listed as version 5.5
>
> In any event, that version will not run "native" on Mac OS X.
>
> As I recall, I think I paid about $700 for it, however I got
> sidetracked and never used it to develop any programs for sale.
Back in 2002, Digitool was selling the MCL 4.3.x series, and clearly
stated that it was not OS X native, but ran in compatability mode. I
bought 4.3.5 after they reduced the price from $375 to $95. I believe
it was $500 with the redistribution kit.
> Now Digitool is advertising a "native OS X" version 5 on their website
> !!!
>
> I am getting disgusted with these version games and Digitool's high
> priced licenses.
The only version games are in your head. They were always very clear
that MCL 5 is OS X native, and the 4 series is classic Mac OS. I
don't know how much you expect to pay for a commercial Lisp
development environmnet, but even with the higher price of $750 for
MCL 5, it's still at the affordable end of commercial Lisp offerings,
and is *less* than Microsoft's Visual Studio.
> FWIW, Digitool's prices seem out of line to me. I don't mind paying
> for a good development environment if it is really needed.
What on earth do you base that on? If you want a commercial
development environment, where do you think you're going to get one
for much less?
In article <···············@conquest.OCF.Berkeley.EDU>, Thomas F.
Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> Back in 2002, Digitool was selling the MCL 4.3.x series, and clearly
> stated that it was not OS X native, but ran in compatability mode. I
> bought 4.3.5 after they reduced the price from $375 to $95. I believe
> it was $500 with the redistribution kit.
>
> The only version games are in your head. They were always very clear
> that MCL 5 is OS X native, and the 4 series is classic Mac OS. I
> don't know how much you expect to pay for a commercial Lisp
> development environmnet, but even with the higher price of $750 for
> MCL 5, it's still at the affordable end of commercial Lisp offerings,
> and is *less* than Microsoft's Visual Studio.
That is very strange, I just again expanded the "mcl-5.0.sea" file in
Apple OS-8.6 It expanded as a folder "MCL 5.0"
Inside that folder I observed these three files, among others. Their
names were:
mcl-compiler-5.0
mcl-kernel-5.0
mcl-library-5.0
The creation date of those files is Sept 18, 2002
In my storage room I have a boxed version 2.0 of MCL.
I have been buying all the updates to MCL since that version, ending
with the supposed version 5.0 that I just described. I do not recall
when I bought the "5.0" version, however it was sometime before
Apple's new OSX was created, because I recall running "5.0" on
Apple's earlier OSs before OSX was available.
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.
I would give my eye teeth to know what the creation dates of their
present files are. Perhaps someone out there can supply us with that
information?
I don't know what is going on with their version numbers.
Mark-
Mark Conrad <············@invalid.com> writes:
> That is very strange, I just again expanded the "mcl-5.0.sea" file in
> Apple OS-8.6 It expanded as a folder "MCL 5.0"
>
> Inside that folder I observed these three files, among others. Their
> names were:
>
> mcl-compiler-5.0
> mcl-kernel-5.0
> mcl-library-5.0
>
> The creation date of those files is Sept 18, 2002
This seems to be the correct version. Here is what I have:
-rw-r--r-- 1 tord admin 463522 19 Sep 2002 MCL-compiler-5.0
-rw-r--r-- 1 tord admin 99154 18 Sep 2002 MCL-kernel-5.0
-rw-r--r-- 1 tord admin 3329018 19 Sep 2002 MCL-library-5.0
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?
--
Tord Romstad
In article <···············@europa.uio.no>,
Tord Kallqvist Romstad <·······@math.uio.no> wrote:
> > The creation date of those files is Sept 18, 2002
>
> This seems to be the correct version. Here is what I have:
>
> -rw-r--r-- 1 tord admin 463522 19 Sep 2002 MCL-compiler-5.0
> -rw-r--r-- 1 tord admin 99154 18 Sep 2002 MCL-kernel-5.0
> -rw-r--r-- 1 tord admin 3329018 19 Sep 2002 MCL-library-5.0
>
> 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>
In article <···············@europa.uio.no>, Tord Kallqvist Romstad
<·······@math.uio.no> wrote:
> I don't even have the Classic environment installed
> on my Mac, but I run MCL 5.0 without any problems.
Thanks, I tried installing MCL 5.0 again from scratch, and this time it
works okay. (Classic not running)
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,
Mark-
The Digitool website could certainly use some better organization but I
am not sure what your source of confusion was. Digitool did not have an
OS X native version "years ago". I never heard of a version 5.5
either. It sounds as if you got a version 4.X. The version # should be
on the CD. I don't know but Digitool may offer an MCL 4 -> MCL 5
upgrade.
MCL does have some rough edges but we think it's currently still the
best OS X CL development environment to create non-trivial OS X apps.
We have created - and keep maintaining - two commercial applications
with MCL (AgentSheets and Deep Navel) are pretty happy and would not
have used any other OS X CLs. For commercial developers the price of
MCL is not really a big issue. As researcher and teacher I wish,
however, that there would be better priced student edition (currently
$450).
our AgentSheets for Mac includes a Lisp(subset) -> Java bytecode
compiler. The output of that can run on any JVM box. The complete
AgentSheets/Windows version is in Java. If we did that again today we
would stick with Lisp for Windows as well.
In article <·······························@invalid.com>,
Mark Conrad <············@invalid.com> wrote:
> Any opinions one way or the other appreciated, before I goof and buy
> more Digitool software.
I run now, or have run, just about every common lisp that runs on Mac OS
X. These include, in no particular order:
Armed Bear Common Lisp
Allegro Common Lisp (trial version)
MCL
OpenMCL
LispWorks (4.4)
clisp
cmucl
sbcl
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.
ABCL - Carbon: via java
Cocoa: via java
speed: slow
compiler: slow
issues: not fully ANSI compliant yet
features: java based, so access to java libraries.
Allegro - Carbon: via ffi?
Cocoa: no
speed: moderate to fast.
compiler: fast
issues: No IDE on Mac OS X. Trial couldn't load vendor supplied
patch. Expensive. Royalties on delivered apps. (i.e., imho not ready for
prime time on Mac OS X, especially if you're interested in GUI apps).
features: runs on Windows and unix/linux, so should be very portable.
Large user community. Excellent and abundant contributed code. Java
access.
MCL - Carbon: excellent Carbon support - best of any lisp.
Cocoa: no (i.e., only via Carbon).
speed: moderate to fast, slow floating point and arrays.
compiler: blazingly fast.
issues: Digitool chose the Carbon route to port from Mac OS Classic
to Mac OS X. As a consequence, MCL's Cocoa support is lacking. In
addition, MCL itself, as well as delivered applications are *not* Mac OS
X bundles - they are single files with a resource fork. This is a
problem as unix tools can unwittingly strip the resource fork of MCL
apps.
features: Unsurpassed Carbon support. Nice IDE. Friendly user
community. Lots of contributed code. Royalty free app delivery with
deployment license.
OpenMCL - Carbon: excellent Carbon support.
Cocoa: very good cocoa support.
speed: moderate to fast, slow floating point and arrays.
compiler: blazingly fast.
issues: As of this writing, app bundles and the alpha IDE need to be
recompiled for every point update of Mac OS X. This effectively prevents
distribution of finished apps (i.e., users would have to download a new
version every time they used Software Update and went from Mac OS X
10.3.7 to 10.3.8 for example.) IDE is primitive.
features: Friendly user community. Free as in beer and speech (llgpl)
- no redistribution issues unlike gpl because of the preamble of the
llgpl. Cocoa bridge.
LispWorks - Carbon: via ffi, but Cocoa is the expected GUI framework
with LispWorks.
Cocoa: excellent Cocoa support.
speed: very fast
compiler: moderately fast
issues: CAPI, LispWorks cross platform GUI API, is not fully HIG
compliant. Mac OS X GUI is not multi-threaded unlike Windows version.
features: Excellent IDE. Friendly user community. Good, abundant
contributed code. CAPI allows easy cross platform development to Windows
and Linux. Royalty free application delivery. Best lisp for Cocoa GUI
development, especially if you want an IDE.
clisp - Carbon: via ffi? (don't know if callbacks are possible)
Cocoa: not that I'm aware of.
speed: generally slow to moderate, but fast bignums.
compiler: moderately fast
issues: No IDE. Not native compiled (bytecode). GPL (so should be
aware of license issues if redistributing).
features: very widely cross platform - Windows, Linux, unix, Mac,
FreeBSD, etc. Free as in speech and beer - GPL.
cmucl - Carbon: via ffi? callbacks?
Cocoa: not that I'm aware of.
speed: moderate to fast.
compiler: slowish (see sbcl for comments).
issues: Not as widely used or developed/maintained on Mac OS X as its
fork, sbcl.
features: widely cross platform. optimizing native compiler.
sbcl - Carbon: via callback system.
Cocoa: not yet.
speed: blazingly fast - fastest generated native code all around of
any Common Lisp (with LispWorks close behind).
compiler: slow, but then, it does a lot of optimizing and generates a
lot of notes to aid programmer in optimizing source.
issues: Not really ready for prime time for GUI app delivery - Carbon
callbacks are still a new feature and there is no IDE.
features: very widely cross platform, and generated code is
unexcelled among Mac OS X common lisps.
Since I'm interested in Cocoa GUI apps, I use LispWorks. I'd use OpenMCL
if one didn't need to recompile and redeliver apps for each OS point
update, but OpenMCL is not quite ready for prime time for GUI app
delivery. MCL is nice, but too slow for float and/or array intensive
code, and I don't want to deliver apps that have resource forks, and I'd
rather use Cocoa than Carbon.
I'd go with LispWorks. It isn't perfect (CAPI HIG issues), but it's the
best Common Lisp all around for Mac OS X right now.
This is really useful information!
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?
rif
In article <···············@five-percent-nation.mit.edu>,
rif <···@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.
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.
Again, I would be quite happy to use OpenMCL if only the issue with
needing to recompile for each OS point upgrade were resolved. Until that
is the case, however, I'll use LispWorks.
In article
<······································@comcast.dca.giganews.com>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote:
> Since I'm interested in Cocoa GUI apps, I use LispWorks. I'd use OpenMCL
> if one didn't need to recompile and redeliver apps for each OS point
> update, but OpenMCL is not quite ready for prime time for GUI app
> delivery. MCL is nice, but too slow for float and/or array intensive
> code, and I don't want to deliver apps that have resource forks, and I'd
> rather use Cocoa than Carbon.
>
> I'd go with LispWorks. It isn't perfect (CAPI HIG issues), but it's the
> best Common Lisp all around for Mac OS X right now.
My experience is similar.
A few remarks:
There are some areas where LispWorks is much
faster than SBCL (CLOS, some I/O stuff - last time I have looked).
LispWorks supports multiple threads (SBCL does not on the Mac),
but I had issues with LispWorks 4.3.7 and my Dual-G5 PowerMac
with threads (two processors busy when one should be active,
IDE sluggish when running background threads).
LispWorks is by far the best Lisp for Mac OS X right now -
especially because of the Cocoa-based IDE.
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.
Rainer Joswig wrote:
> 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...
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. 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.
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.
"dragentsheets" <·····@cs.colorado.edu> wrote in message news:<························@l41g2000cwc.googlegroups.com>...
> Rainer Joswig wrote:
>
> > 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.
Regards,
Rainer Joswig
In article <····························@posting.google.com>,
······@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.
Raffael Cavallaro wrote:
>
> 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.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
In article <··················@newsread3.news.atl.earthlink.net>,
John DeSoi <·····@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...
Ralph
In article <····························@news-50.dca.giganews.com>,
Rainer Joswig <······@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.
regards,
Ralph
"Raffael Cavallaro"
<················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote in message
···········································@comcast.dca.giganews.com...
> In article <·······························@invalid.com>,
> Mark Conrad <············@invalid.com> wrote:
>
> > Any opinions one way or the other appreciated, before I goof and buy
> > more Digitool software.
>
> I run now, or have run, just about every common lisp that runs on Mac OS
> X. These include, in no particular order:
Nice list! I wonder if anyone has updated the Gabriel benchmarks for these
lisps running on the Mac.
In article
<······································@comcast.dca.giganews.com>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote:
> > Any opinions one way or the other appreciated, before I goof and buy
> > more Digitool software.
>
> I run now, or have run, just about every common lisp that runs on Mac OS
> X. These include, in no particular order:
>
> Armed Bear Common Lisp
> Allegro Common Lisp (trial version)
> MCL
> OpenMCL
> LispWorks (4.4)
> clisp
> cmucl
> sbcl
>
> 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.
Mark-
> 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 <························@o13g2000cwo.googlegroups.com>,
<···············@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.
Mark-