Hi, I was wondering, could someone recommend Common LISP
implementations that will run under Mac OS X? At this time, I'm
looking that solid with a LISP community behind it. Well, I must go
and thanks in advance.
-Conrad
From: Sam Steingold
Subject: Re: Common LISP Implementations for Mac OS X?
Date:
Message-ID: <u1xarqbu3.fsf@gnu.org>
> * Con <········@ehaobk.pbz> [2005-03-07 12:31:46 -0800]:
>
> Hi, I was wondering, could someone recommend Common LISP
> implementations that will run under Mac OS X?
<http://clisp.cons.org> works on Mac OS X
(as well as just about everything else :-)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.memri.org/> <http://www.honestreporting.com>
<http://www.camera.org> <http://pmw.org.il/> <http://www.mideasttruth.com/>
WinWord 6.0 UNinstall: Not enough disk space to uninstall WinWord
Sam Steingold wrote:
>>* Con <········@ehaobk.pbz> [2005-03-07 12:31:46 -0800]:
>>
>>Hi, I was wondering, could someone recommend Common LISP
>>implementations that will run under Mac OS X?
>
>
> <http://clisp.cons.org> works on Mac OS X
> (as well as just about everything else :-)
...and does that include the new killer FFI you have, or are you still
hoping some open source fairy will leave that under your pillow?
:)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Bruno Haible
Subject: Re: Common LISP Implementations for Mac OS X?
Date:
Message-ID: <d0kjek$rdi$1@laposte.ilog.fr>
Kenny Tilton asked:
>
> > <http://clisp.cons.org> works on Mac OS X
>
>...and does that include the new killer FFI you have
CLISP's FFI is not new, but it includes callbacks and automatic
conversion of simple C structures. And yes, it works on MacOS X,
if you take the clisp version from CVS.
> or are you still hoping some open source fairy will leave that under
> your pillow?
Open Source works because people can contribute and do contribute.
For example, if CLISP on MacOS X now supports generational garbage
collection, it is because someone from the Smalltalk community
contributed the necessary support to GNU libsigsegv-2.2.
Bruno
Bruno Haible wrote:
> Kenny Tilton asked:
>
>>><http://clisp.cons.org> works on Mac OS X
>>
>>...and does that include the new killer FFI you have
>
>
> CLISP's FFI is not new, but it includes callbacks and automatic
> conversion of simple C structures. And yes, it works on MacOS X,
> if you take the clisp version from CVS.
Great. That new FFI work on the callbacks is very impressive. Gave me
fits trying to do the same in UFFI (aka LCD of other FFIs) when I had to
port Cells-gtk from native CLisp FFI.
kt
"Con" <········@runbox.com> writes:
> Hi, I was wondering, could someone recommend Common LISP
> implementations that will run under Mac OS X? At this time, I'm
See this paper by Rainer Joswig:
ILC 2003, Lisp and Mac OS X, updated march 2004
http://lispm.dyndns.org/lisp/lisp-and-macosx-2004-03.pdf
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
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
From: Pascal Costanza
Subject: Re: Common LISP Implementations for Mac OS X?
Date:
Message-ID: <d0k538$dae$1@snic.vub.ac.be>
Stephen Edwards wrote:
> In article <························@l41g2000cwc.googlegroups.com>, "Con"
> <········@runbox.com> wrote:
>
>>Hi, I was wondering, could someone recommend Common LISP
>>implementations that will run under Mac OS X? At this time, I'm
>>looking that solid with a LISP community behind it. Well, I must go
>>and thanks in advance.
>
> If you don't mind running an application in classic mode (assuming that
> you are not running a G5 system), PowerLISP is a great freeware LISP
> implementation.
>
> http://www.cormanlisp.com/Powerlisp.html
Not a good idea. PowerLisp is not ANSI-compliant in many respects, and
it is not supported anymore. So there won't be any OS X version.
If you want a Common Lisp environment with an IDE that you can use for
free, LispWorks Personal Edition is the way to go. If you don't mind
paying money, MCL is also worth a try, it's also an excellent
environment for Common Lisp.
Emacs + SLIME works very well for almost all Mac OS X Common Lisp
implementations out there, both free and commercial.
Pascal
In article <························@l41g2000cwc.googlegroups.com>,
"Con" <········@runbox.com> wrote:
> Hi, I was wondering, could someone recommend Common LISP
> implementations that will run under Mac OS X? At this time, I'm
> looking that solid with a LISP community behind it. Well, I must go
> and thanks in advance.
>
> -Conrad
I posted the following in response to a similar question two weeks ago
in this newsgroup. Note that I end up recommending LispWorks, which has
a free trial edition. That free trial is most definitely worth the
download.
from
<http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/2e2
76117925dcbe8/aab851df86f90be7#aab851df86f90be7>
-------------------------------------------------------------------
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.
I recently benchmarked ACL, SBCL, and OpenMCL on a Dual G5, and posted
the
results on cliki:
http://www.cliki.net/Performance%20Benchmarks2
The OS X results are at the bottom of the page.
For that set of benchmarks, ACL was quite speedy.
Raffael Cavallaro wrote:
>
> I posted the following in response to a similar question two weeks ago
> in this newsgroup. Note that I end up recommending LispWorks, which has
> a free trial edition. That free trial is most definitely worth the
> download.
Thanks Raffael, a great overview. I've put it online at :
http://lisp.tech.coop/Which%20Common%20Lisp%20for%20Macintosh
it's a wiki .. go nuts.
drewc
>
> from
> <http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/2e2
> 76117925dcbe8/aab851df86f90be7#aab851df86f90be7>
>
> -------------------------------------------------------------------
>
> 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.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
>>>>> "Raffael" == Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
Raffael> cmucl - Carbon: via ffi? callbacks?
Raffael> Cocoa: not that I'm aware of.
Raffael> speed: moderate to fast.
What makes CMUCL speed moderate to fast but SBCL blazingly fast?
Raffael> compiler: slowish (see sbcl for comments).
Raffael> issues: Not as widely used or developed/maintained on Mac OS X as its
Raffael> fork, sbcl.
Raffael> features: widely cross platform. optimizing native compiler.
I've never heard anyone call (recent) CMUCL widely cross-platform.
Raffael> sbcl - Carbon: via callback system.
Raffael> Cocoa: not yet.
Raffael> speed: blazingly fast - fastest generated native code all around of
Raffael> any Common Lisp (with LispWorks close behind).
I would have expected CMUCL to be pretty close to sbcl in speed, but
perhaps your benchmarks indicate otherwise.
CMUCL also has callbacks on OSX.
Ray
In article <···············@rtp.ericsson.se>,
Raymond Toy <···········@ericsson.com> wrote:
> What makes CMUCL speed moderate to fast but SBCL blazingly fast?
You're right - see below.
>
> Raffael> compiler: slowish (see sbcl for comments).
> Raffael> issues: Not as widely used or developed/maintained on Mac OS X
> as its
> Raffael> fork, sbcl.
> Raffael> features: widely cross platform. optimizing native compiler.
>
> I've never heard anyone call (recent) CMUCL widely cross-platform.
O.K., if you say so. I thought it ran on most *nix and bsds, No?
>
> Raffael> sbcl - Carbon: via callback system.
> Raffael> Cocoa: not yet.
> Raffael> speed: blazingly fast - fastest generated native code all
> around of
> Raffael> any Common Lisp (with LispWorks close behind).
>
> I would have expected CMUCL to be pretty close to sbcl in speed, but
> perhaps your benchmarks indicate otherwise.
I too have found it to be it to be close to (or faster) than sbcl. Don't
know why I characterized it as "moderate to fast" - typing too much, too
fast I guess.
BTW, Rainer Joswig has also corrected my characterization of LispWorks,
since it is faster than sbcl on CLOS benchmarks.
>
> CMUCL also has callbacks on OSX.
This is good to know. Thanks.
For anyone immortalizing my usenet evaluation of Mac OS X lisps on a web
page or the like, the following corrections should be made:
cmucl - speed: blazingly fast
carbon: via ffi and callbacks.
features: optimizing native compiler, callbacks.
LispWorks - speed: fast to blazingly fast (especially CLOS)
From: Raymond Toy
Subject: Re: Mac OS X lisp review amendments (Re: Common LISP Implementations for Mac OS X?)
Date:
Message-ID: <sxdacpb8fe2.fsf@rtp.ericsson.se>
>>>>> "Raffael" == Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
Raffael> In article <···············@rtp.ericsson.se>,
Raffael> Raymond Toy <···········@ericsson.com> wrote:
Raffael> compiler: slowish (see sbcl for comments).
Raffael> issues: Not as widely used or developed/maintained on Mac OS X
>> as its
Raffael> fork, sbcl.
Raffael> features: widely cross platform. optimizing native compiler.
>>
>> I've never heard anyone call (recent) CMUCL widely cross-platform.
Raffael> O.K., if you say so. I thought it ran on most *nix and bsds, No?
It might have been true in the past, but right now it only runs:
o x86 on Linux, FreeBSD, and NetBSD (I think). OpenBSD support is
gone because no one is around to maintain it.
o sparc on Solaris. SunOS 4 support has disappeared. And current
versions only work on Ultrasparcs because no one wants to keep
the non-ultra port working. (But it should be straightfoward to
remove the ultrasparc-isms.)
o ppc on Mac OS X.
The limitation is people willing to support it on their favorite
hardware and OS. So MIPS/SGI is gone too.
Raffael> For anyone immortalizing my usenet evaluation of Mac OS X lisps on a web
Raffael> page or the like, the following corrections should be made:
Raffael> cmucl - speed: blazingly fast
Raffael> carbon: via ffi and callbacks.
Did someone actually do carbon via ffi and callbacks with cmucl?
Mostly just curious.
Ray
In article <···············@rtp.ericsson.se>,
Raymond Toy <···········@ericsson.com> wrote:
> Did someone actually do carbon via ffi and callbacks with cmucl?
> Mostly just curious.
I'm merely noting that the facilities are there. I prefer Cocoa to
Carbon in any event.
regards
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com>
writes:
> 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.
I guess OpenMCL deserves that "native thread support" is added to the list
of nice features. I don't think any of the other lisps (exept MCL) has this
(killer)feature.
--
Oyvin
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote in message news:<··············@neptune.orakel.ntnu.no>...
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com>
> writes:
>
> > 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.
>
> I guess OpenMCL deserves that "native thread support" is added to the list
> of nice features. I don't think any of the other lisps (exept MCL) has this
> (killer)feature.
MCL does NOT have that feature.
LispWorks multiprocessing uses native threads on Windows and Mac OS X.
In article <···························@posting.google.com>,
······@corporate-world.lisp.de (Rainer Joswig) wrote:
> MCL does NOT have that feature.
>
> LispWorks multiprocessing uses native threads on Windows and Mac OS X.
Just to be clear, I took Oyvin to mean that OpenMCL has native threads
(it does).
LispWorks uses native threads for its multiprocessing, but,
unfortunately, the LispWorks CAPI GUI on Mac OS X puts all GUI
interaction in a single thread (possibly because this is easier -
portions of the AppKit are not thread safe).
MCL (the commercial product from Digitool) does not use native OS
threads for multitasking.
regards
Could you please explain what is the difference between "native thread
support" and "non-native thread support" and how they effect program
operation. I am using MCL and am interested in knowing what I am
missing out on.
···············@hut.fi writes:
> Could you please explain what is the difference between "native thread
> support" and "non-native thread support" and how they effect program
> operation. I am using MCL and am interested in knowing what I am
> missing out on.
Native threads means that the threading is taken care of by the OS. Non-
native threads are scheduled/multiplexed by the CL-implementation.
Most of the time you will notice two things abouts native threads:
1) Two threads can run i (true) parallel on multiple CPU's.
2) Scheduling is taken care of by the OS and threads live happily
together with other programs, and you can inspect what thread is
doing what (hanging, sleeping etc.) from the normal OS-tools.
I dare say that if you are running things like allegroserve for
production use, native threads will change your life more than sliced
bread would.
There are also some benefits (and caveats) for GUI's, but I guess
other people on this group can go better into details on that.
--
Oyvin
From: Edi Weitz
Subject: Native threads (Was: Common LISP Implementations for Mac OS X?)
Date:
Message-ID: <uy8cp14ks.fsf_-_@agharta.de>
On 15 Mar 2005 13:09:31 +0100, Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote:
> Native threads means that the threading is taken care of by the
> OS. Non- native threads are scheduled/multiplexed by the
> CL-implementation.
>
> Most of the time you will notice two things abouts native threads:
> 1) Two threads can run i (true) parallel on multiple CPU's.
> 2) Scheduling is taken care of by the OS and threads live happily
> together with other programs, and you can inspect what thread is
> doing what (hanging, sleeping etc.) from the normal OS-tools.
>
> I dare say that if you are running things like allegroserve for
> production use, native threads will change your life more than
> sliced bread would.
Another important difference is that with non-native threads an
expensive FFI call (like, say, CLSQL doing a long-running SQL query)
in one thread can potentially block the whole Lisp application while
with native threads usually only one thread is blocked.
I wonder why the two main commercial vendors (Franz and LispWorks)
still don't offer native threads for Linux. SBCL has them, but only
for 2.6 kernels, and Scieneer has them, but seemingly only for certain
RedHat Enterprise editions. Would anyone be willing to explain what's
the difficulty? Different APIs for different kernels/distros?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Stefan Scholl
Subject: Re: Native threads (Was: Common LISP Implementations for Mac OS X?)
Date:
Message-ID: <1xeexhh6g8i2d.dlg@parsec.no-spoon.de>
On 2005-03-15 13:22:43, Edi Weitz wrote:
> SBCL has them, but only
> for 2.6 kernels,
Works for 2.4, too. The thread-tests throw the same error in 2.6 and
2.4. :-)
It's currently limited to Linux and x86 (as of 0.8.20).
--
Web: http://www.no-spoon.de/ -*- IRC: stesch @ freenode
Oyvin Halfdan Thuv wrote:
> ···············@hut.fi writes:
>
>>Could you please explain what is the difference between "native thread
>>support" and "non-native thread support" and how they effect program
>>operation. I am using MCL and am interested in knowing what I am
>>missing out on.
>
> Native threads means that the threading is taken care of by the OS. Non-
> native threads are scheduled/multiplexed by the CL-implementation.
Being from an academic background, I have also had problems
understanding this distinction. I only knew about the distinction
between cooperative and preemptive multithreading. I have learned that
in practice, native threads are usually preemptive while non-native
threads are usually cooperative, which makes me understand why native
threads are usually preferred. ;)
Pascal
On Tue, 15 Mar 2005 13:23:31 +0100, Pascal Costanza wrote:
> Oyvin Halfdan Thuv wrote:
>> ···············@hut.fi writes:
>>
>>>Could you please explain what is the difference between "native thread
>>>support" and "non-native thread support" and how they effect program
>>>operation. I am using MCL and am interested in knowing what I am
>>>missing out on.
>>
>> Native threads means that the threading is taken care of by the OS. Non-
>> native threads are scheduled/multiplexed by the CL-implementation.
> Being from an academic background, I have also had problems
> understanding this distinction. I only knew about the distinction
> between cooperative and preemptive multithreading. I have learned that
> in practice, native threads are usually preemptive while non-native
> threads are usually cooperative, which makes me understand why native
> threads are usually preferred. ;)
The clue is that MCL's implementation of threads (called processes in
Chapter 12 of the MCL reference) predates Mac OS X, and in fact MCL 5.0
is still compatible with OS 9 and therefore can't depend on OS X native
threads being available.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> writes:
> I dare say that if you are running things like allegroserve for
> production use, native threads will change your life more than
> sliced bread would.
This goes into my quotation file. :)
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> writes:
>
> > I dare say that if you are running things like allegroserve for
> > production use, native threads will change your life more than
> > sliced bread would.
>
> This goes into my quotation file. :)
:)
In article <··············@neptune.orakel.ntnu.no>,
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote:
> I guess OpenMCL deserves that "native thread support" is added to the list
> of nice features. I don't think any of the other lisps (exept MCL) has this
> (killer)feature.
Yes, thanks for spotting this omission.
Con wrote:
> Hi, I was wondering, could someone recommend Common LISP
> implementations that will run under Mac OS X? At this time, I'm
> looking that solid with a LISP community behind it. Well, I must go
> and thanks in advance.
>
> -Conrad
MCL is our choice. Nice IDE, fast compiler, fast runtime (runs our
OpenGL stuff very fast), has an ephemeral garbage collector (essential
for continuously animated stuff). Not free, but you get what you pay
for. Distant second: LispWorks: generic - non OS X - interface, good
for cross platform development. Rising star: ACL for OS X: mature fast
system: no real OS X interface (X11: no thanks!)
Alex
In article <························@f14g2000cwb.googlegroups.com>,
"Alexander Repenning" <·····@cs.colorado.edu> wrote:
> MCL is our choice. Nice IDE, fast compiler, fast runtime (runs our
> OpenGL stuff very fast), has an ephemeral garbage collector (essential
> for continuously animated stuff). Not free, but you get what you pay
> for. Distant second: LispWorks: generic - non OS X - interface, good
> for cross platform development.
Note that both Rainer Joswig and I have exactly the opposite ranking.
This reflects our desire for a Mac OS X lisp that interfaces well with
Cocoa, while your preference for MCL reflects your desire for a Mac OS X
lisp that interfaces well with Carbon, understandable as you have a very
large body of Carbon compatible legacy code.
I think it would be fair to both MCL and LispWorks, as well as useful to
newcomers to both, to state that MCL is the undisputed king of Carbon
based Mac OS X common lisp implementations, while LispWorks is the clear
choice (for now) if one wants easy access to Cocoa. This latter could
change as OpenMCL progresses, however.
BTW, while it is true that CAPI is a "generic - non OS X - interface,"
Mac OS X users of LispWorks are not limited to CAPI - you can load
Interface Builder nib files, and create any Cocoa UI you want. If you
want a true Mac OS X Coca UI with LispWorks, you have to build it
yourself - but this is not so different than MCL, where you use MCL's
CLOSified Carbon calls to do the same thing that a LispWorks user
accomplishes with Lispworks objc package interfacing with Cocoa.
regards
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote in message news:<······································@comcast.dca.giganews.com>...
> In article <························@f14g2000cwb.googlegroups.com>,
> "Alexander Repenning" <·····@cs.colorado.edu> wrote:
>
> > MCL is our choice. Nice IDE, fast compiler, fast runtime (runs our
> > OpenGL stuff very fast), has an ephemeral garbage collector (essential
> > for continuously animated stuff). Not free, but you get what you pay
> > for. Distant second: LispWorks: generic - non OS X - interface, good
> > for cross platform development.
>
> Note that both Rainer Joswig and I have exactly the opposite ranking.
> This reflects our desire for a Mac OS X lisp that interfaces well with
> Cocoa, while your preference for MCL reflects your desire for a Mac OS X
> lisp that interfaces well with Carbon, understandable as you have a very
> large body of Carbon compatible legacy code.
>
> I think it would be fair to both MCL and LispWorks, as well as useful to
> newcomers to both, to state that MCL is the undisputed king of Carbon
> based Mac OS X common lisp implementations,
This does not make MCL be a good Lisp for Mac OS X. It may support
lots Carbon stuff. But not all and LOTS of Mac OS X stuff is simply
missing in MCL. Many of the Mac OS 9 (and before) libraries had
higher-level versions (with some nice Lisp packaging) in the old
times.
MCL does not provide enough higher-level updated Lisp libraries
anymore.
For me MCL is not a Mac OS X Lisp. It is a roughly ported Lisp from
pre Mac OS X times. I'm downloading the MCL 5.0 demo
(which is from 2003) now to my Powerbook running Mac OS X 10.3.8.
The first thing you notice is that MCL can't really deal with
antialiased
fonts in FRED. Selections of antialiased fonts are ugly. It does not
provide the new font tools either.
The service menu is not supported at all.
Handling text files is mostly broken. It tells me something about
Open... and Open Unix..., Load... and Load Unix... Which other
application does that???
Let's see how dialogs are looking. Open the 'Get Info' dialog. I see
immediately half a dozen issues with this dialog. Stuff is not drawn
correctly. Sizes are not right. The whole dialog does not even
look&feel Mac OS X.
Drag&drop for the text fields is not working. I can't drag clippings
to the finder. No context sensitive menu in the text field.
The preferences dialog is so Mac OS 6...
Font usage is totally inconsistent all over the place.
The Carbon interface files are old...
If you look at the MCL and its IDE, this is clearly a Mac OS 8+ (!!)
application ported to Mac OS X. But there is only VERY little that
makes it look & feel like a Mac OS X application.
I haven't tried much to look around for real Mac-OS-X-like
application development environments. Xcode would come to
my mind. Apple currently has about 1000 software engineers
writing software and lots of them are doing applications.
The new standards are Mac OS X 10.4 (if you have access to the
developer versions), iPhoto, Keynote, Pages, iTunes, iMovie,
Final Cut Express HD, Safari, Garageband, and so on... Lisp
systems are currently far behind ... no similar application
has been demonstrated with Lisp in the last years. (This
used to be different many years ago, when, for example,
Microsoft used MCL to prototype Word user interface ideas).
Plus no Lisp idea makes good use of all the nice stuff in
Mac OS X for its own Integrated Development Environment (IDE).
It is easy to imagine to use ideas from, say, the iTunes user
interface
for a Lisp based development environment itself. Especially if you
had Spotlight (the new search stuff for Mac OS X), you could do
lots of fancy things. Like very cool source code browsers/editors.
But that would be another story...
Summary: MCL 5.0 is not a useful tool for general Mac OS X
development. It has not been updated to Mac OS X in several crucial
areas.
> while LispWorks is the clear
> choice (for now) if one wants easy access to Cocoa. This latter could
> change as OpenMCL progresses, however.
>
> BTW, while it is true that CAPI is a "generic - non OS X - interface,"
> Mac OS X users of LispWorks are not limited to CAPI - you can load
> Interface Builder nib files, and create any Cocoa UI you want. If you
> want a true Mac OS X Coca UI with LispWorks, you have to build it
> yourself - but this is not so different than MCL, where you use MCL's
> CLOSified Carbon calls to do the same thing that a LispWorks user
> accomplishes with Lispworks objc package interfacing with Cocoa.
>
> regards
Rainer Joswig wrote:
> For me MCL is not a Mac OS X Lisp. It is a roughly ported Lisp from
> pre Mac OS X times. I'm downloading the MCL 5.0 demo
> (which is from 2003) now to my Powerbook running Mac OS X 10.3.8.
MCL is not what I would call a great modern CL implementation for OS X.
We have a huge list of things that we wish would be better. However, I
still think it IS the BEST for OS X because everything else is even
worse! Many of your points are true and a source of frustration but
they are either easily fixable (and many fixed, e.g.,
http://agentsheets.com/lisp/) or are implemented on other OS X CLs just
as bad or worse.
Carbon versus Cocoa: Apple wanted to encourge developers to use Cocoa
and think of Carbon as legacy framework. Cocoa is rooted in NextSTep
and was part of the original deal for Steve to come back. Well, he did
come back, Apple is doing great and we all should be happy. Still,
aside of Apple few large developer companies are even considering Cocoa
because it's just another, even smaller developer base, framework.
Virtually all the big developer are sticking with Carbon. All the big
new games for OS X: carbon. The outside pressure of companies like
Adobe and Microsoft has worked. Carbon is not limited in any way to
legacy apps. I personally do not like Cocoa becuas there is nothing in
there that is not available in Carbon. Most of the Cocoa examples are
in Objective C which I am just not used to. Anyway, the much more
important issue is that the Carbon/Cocoa "choice" further divides the
already small Apple developer base. In my mind this is a waste of time,
resources and talents. Anyway, we cannot change this and its not a Lisp
issue. However, I think the fact that OpenMCL switched over to Cocoa is
an example of wasting time etc. As it is MCL and OpenMCL have drifted
apart because of this idiotic Carbon/Cocoa division. The bottom line to
Lisp developers is that because of this it's very hard to combine the
MCL and OpenMCL efforts. What a waste!
>From a lisp point of view one has to ask what is there in Cocoa that is
NOT in Carbon that is of relevance directly or indirectly to Lisp?
>
> The first thing you notice is that MCL can't really deal with
> antialiased
> fonts in FRED. Selections of antialiased fonts are ugly.
If you want to "nice" antialiased fonts you have to turn on quarz
rendering.
>It does not
> provide the new font tools either.
neither does Word, Photoshop, ....
Not sure what you compare MCL too. I will assume LispWorks because it's
the only CL for OS X that I am aware of that has a complete non X11
GUI.
MCL has much more sophisticated font handling than LW. The fact that LW
has a "new" font tool still does not seem to allow it have multiple
fonts in a the same document. LW is stuck at the VT100 ASCII level dark
ages with one font per window where as MCL is has rich text
capabilities. What a concept: different text with different fonts in
the SAME window!
>
> The service menu is not supported at all.
So far I have never found anything useful in that menu anyway.
>
> Handling text files is mostly broken. It tells me something about
> Open... and Open Unix..., Load... and Load Unix... Which other
> application does that???
remember that Unix and Mac text files ARE different. It's nice of MCL
to give you this option. This is not brocken at all. One could try to
make this exchange a bit more transparent but there is some trickery
involved.
> Let's see how dialogs are looking. Open the 'Get Info' dialog. I see
> immediately half a dozen issues with this dialog. Stuff is not drawn
> correctly. Sizes are not right. The whole dialog does not even
> look&feel Mac OS X.
ok, i will give you that one. There are some patches but obviously I
should not have to install patches first. Digitool: are you listening?
NO patches for OS X look and feel.
>
> Drag&drop for the text fields is not working. I can't drag clippings
> to the finder. No context sensitive menu in the text field.
ok: but this is not a big one. Be honest: how many times did you use
that menu to have your Mac speak your text?
>
> The preferences dialog is so Mac OS 6...
The LW preference dialog has single check box! The entire preference
setup is not compliant at all with OS X, OS 8,7,6,... guidelines at
all. I don't know what it is but certainly not Mac. I find it very
confusing.
>
> Font usage is totally inconsistent all over the place.
yes it could be better. LW is not that great either.
>
> The Carbon interface files are old...
true
>
> If you look at the MCL and its IDE, this is clearly a Mac OS 8+ (!!)
> application ported to Mac OS X. But there is only VERY little that
> makes it look & feel like a Mac OS X application.
Again not sure what you are comparing MCL to. OpenMCL and ACL do not
have native interfaces. LispWork's document model seem to be rooted in
pre-window, single font, EMACS on VT100, split screen modes. Load
different Lisp files into the same window. That was a great idea on a
VT100. Now we have windows. Somebody told me that this can be changed
but this is the default! Evaluating someting in window: covers up my
whole buffer with the result, then i have to press space to get back.
How cool is that? I am sorry, but i like the idea of having and using
multiple windows. No need to press space, or switch between tabs.
> I haven't tried much to look around for real Mac-OS-X-like
> application development environments. Xcode would come to
> my mind. Apple currently has about 1000 software engineers
> writing software and lots of them are doing applications.
> The new standards are Mac OS X 10.4 (if you have access to the
> developer versions), iPhoto, Keynote, Pages, iTunes, iMovie,
> Final Cut Express HD, Safari, Garageband, and so on... Lisp
> systems are currently far behind ... no similar application
> has been demonstrated with Lisp in the last years. (This
> used to be different many years ago, when, for example,
> Microsoft used MCL to prototype Word user interface ideas).
> Plus no Lisp idea makes good use of all the nice stuff in
> Mac OS X for its own Integrated Development Environment (IDE).
This is just a simple example but have a look at Deep Navel
(http://deepnav.com/). It was implemented in MCL. Uses Quarz rendering,
QuickTime, Metal windows, ...
We cannot compete with 1000 of programmers but look at the some of our
research projects, e.g, http://agentsheets.com/research/ (check out the
interactive fliers). Mobility Agents tracks GPS bus equipped buses. Mr.
Vetro simulates human physiology on PDAs. MCL is at core of these
projects. It does the 3D simulation, user interface, networking to PDAs
and cell phones, ...
> Summary: MCL 5.0 is not a useful tool for general Mac OS X
> development.
simply not true. My summary: all the current OS X lisp implementations
are bad. Nobody seems to have read the human guideline documentation.
If they use Cocoa or Carbon is irrelevant. The user interface is the
same.
> It has not been updated to Mac OS X in several crucial
> areas.
some interfaces are dated but so are the LW ones (e.g., OpenGL).
alex
From: Ulrich Hobelmann
Subject: Re: Common LISP Implementations for Mac OS X?
Date:
Message-ID: <39h9a0F61hb6fU1@individual.net>
Alexander Repenning wrote:
> Carbon versus Cocoa: [...]
Have you had a look at Cocoa? While it isn't optimal that there are two
frameworks for the Mac now, Cocoa is very powerful and gets you things
done you would have to hand-code in Carbon. There's even an OpenGL-View
now, so future Games could use Cocoa, too. OTOH, I think most
media-access libs are still Carbon-only and the biggest strength of
Cocoa lies in typical GUI-apps, so a game might find it easier to use
Carbon (plus there are experienced developers out there). I don't know
how good the integration is between Carbon and Interface builder, but
most Cocoa apps just look and behave more like I expect it from a Mac OS
X app. The learning-Objective-C thing isn't as bad. I don't like OO
languages, but you can easily write the interface in ObjC and use C or
something else for the rest.
>>The service menu is not supported at all.
>
>
> So far I have never found anything useful in that menu anyway.
Yes, I don't really understand it. Instead of marking something and
doing mouse acrobatics with the service menu I usually just cmd-tab to
the other app and insert etc.
>
>>Handling text files is mostly broken. It tells me something about
>>Open... and Open Unix..., Load... and Load Unix... Which other
>>application does that???
>
>
> remember that Unix and Mac text files ARE different. It's nice of MCL
> to give you this option. This is not brocken at all. One could try to
> make this exchange a bit more transparent but there is some trickery
> involved.
I think all of my text files are in Unix-format and ISO-latin-1 encoded.
Most of my files I just copied (or tarred) from my NetBSD box back then.
> The LW preference dialog has single check box! The entire preference
> setup is not compliant at all with OS X, OS 8,7,6,... guidelines at
> all. I don't know what it is but certainly not Mac. I find it very
> confusing.
Yes, most interesting stuff is hidden in window->window prefs. The
cmd-Q quit thing that always asks "really???" is annoying too. I rarely
quit something accidentally, esp. when unsaved files ask you anyway.
> Again not sure what you are comparing MCL to. OpenMCL and ACL do not
> have native interfaces. LispWork's document model seem to be rooted in
> pre-window, single font, EMACS on VT100, split screen modes. Load
> different Lisp files into the same window. That was a great idea on a
> VT100. Now we have windows. Somebody told me that this can be changed
> but this is the default! Evaluating someting in window: covers up my
> whole buffer with the result, then i have to press space to get back.
> How cool is that? I am sorry, but i like the idea of having and using
> multiple windows. No need to press space, or switch between tabs.
That's true.
In article <························@f14g2000cwb.googlegroups.com>,
"Alexander Repenning" <·····@cs.colorado.edu> wrote:
> Rainer Joswig wrote:
> > For me MCL is not a Mac OS X Lisp. It is a roughly ported Lisp from
> > pre Mac OS X times. I'm downloading the MCL 5.0 demo
> > (which is from 2003) now to my Powerbook running Mac OS X 10.3.8.
>
> MCL is not what I would call a great modern CL implementation for OS X.
That's what I'm saying.
> We have a huge list of things that we wish would be better. However, I
> still think it IS the BEST for OS X because everything else is even
> worse!
Actually I think LispWorks is much better than MCL. LispWorks isn't
the great Mac-like Lisp either, but it far is better than MCL
in MANY ways. Here I list a few things I like:
- LispWorks is actively developed and support. MCL seems to be dead.
- LispWorks is much better organized internally. MCL has everything
in a CCL package.
- LispWorks has a much better organized IDE. MCL's tools are
less integrated. LispWorks also has much more functionality
in the IDE. From browsers for generic functions to
compiler error browsers.
- LispWorks has a much better compiler. The code generated
runs much faster. The compiler gives a lot of information,
which you can browse later.
- LispWorks has much more functionality. And this functionality
is better organized. SQL Interface, Rule System, portable GUI,
Unicode, MOP, OpenSSL interface, ...
- LispWorks professional has a delivery option with royalty
free delivery for a reasonable price.
- LispWorks can be used from the command line, via X11 or
via a Cocoa-based interface. I can choose.
- LispWorks deals with various text problems (line endings,
encodings, ...). MCL has only a hack.
- LispWorks has a better TCP interface, better stream interface, ...
Plus it even is documented. See next point.
- LispWorks has updated documentation. MCL has not.
To be fair, there is also quite a lot about LispWorks
that I don't like. But in summary, LispWorks is much better
and offering more value.
> Many of your points are true and a source of frustration but
> they are either easily fixable (and many fixed, e.g.,
> http://agentsheets.com/lisp/) or are implemented on other OS X CLs just
> as bad or worse.
Alex, your stuff is a great service to the MCL community. Thanks.
> Carbon versus Cocoa: Apple wanted to encourge developers to use Cocoa
> and think of Carbon as legacy framework. Cocoa is rooted in NextSTep
> and was part of the original deal for Steve to come back. Well, he did
> come back, Apple is doing great and we all should be happy. Still,
> aside of Apple few large developer companies are even considering Cocoa
> because it's just another, even smaller developer base, framework.
> Virtually all the big developer are sticking with Carbon.
Many of them are dealing with legacy applications.
> All the big
> new games for OS X: carbon. The outside pressure of companies like
> Adobe and Microsoft has worked. Carbon is not limited in any way to
> legacy apps.
Yes, right. That makes it even worse. MCL is far from
having a Carbon-based user interface and far from
enabling people to write Carbon-based Mac OS X applications.
It looks all more or less like Mac OS 8. And that is officially
gone now. Time to update, Digitool!
> I personally do not like Cocoa becuas there is nothing in
> there that is not available in Carbon. Most of the Cocoa examples are
> in Objective C which I am just not used to. Anyway, the much more
> important issue is that the Carbon/Cocoa "choice" further divides the
> already small Apple developer base. In my mind this is a waste of time,
> resources and talents. Anyway, we cannot change this and its not a Lisp
> issue. However, I think the fact that OpenMCL switched over to Cocoa is
> an example of wasting time etc. As it is MCL and OpenMCL have drifted
> apart because of this idiotic Carbon/Cocoa division. The bottom line to
> Lisp developers is that because of this it's very hard to combine the
> MCL and OpenMCL efforts. What a waste!
I would agree to that. It should have led to something where
there is a new user interface. But there isn't yet.
> >From a lisp point of view one has to ask what is there in Cocoa that is
> NOT in Carbon that is of relevance directly or indirectly to Lisp?
>
> >
> > The first thing you notice is that MCL can't really deal with
> > antialiased
> > fonts in FRED. Selections of antialiased fonts are ugly.
>
> If you want to "nice" antialiased fonts you have to turn on quarz
> rendering.
MCL does not know much about the modern font system on Mac OS X.
If you select text around text, the selection looks ugly
on the border from the character to the background.
> >It does not
> > provide the new font tools either.
>
> neither does Word, Photoshop, ....
But Keynote, Pages, Text Edit, Omni Outliner, ...
> Not sure what you compare MCL too. I will assume LispWorks because it's
> the only CL for OS X that I am aware of that has a complete non X11
> GUI.
I compare MCL to the average new application for Mac OS X.
NewsFire, Omni Graffle, Keynote, Safari, WeatherDock, SubEthaEdit,
XCode, Interface Builder, ...
> MCL has much more sophisticated font handling than LW. The fact that LW
> has a "new" font tool still does not seem to allow it have multiple
> fonts in a the same document. LW is stuck at the VT100 ASCII level dark
> ages with one font per window where as MCL is has rich text
> capabilities. What a concept: different text with different fonts in
> the SAME window!
Isn't the way how it stores font/color information in the file just a
hack?
Usually I would advise to use the native text fields in
an application.
I would not hand out a FRED dialog item to an average user.
Because the FRED dialog item behaves differently, lacks
some expected functionality and brings new unexpected
functionality. This starts with basic things. I can't type
option-n on my german keyboard to get a tilde.
As a programmers editor, MCL lacks a lot of the capabilities
of the LispWorks editor. For example MCL does not do
font colorization for Lisp code. Even if you add some tool
to do that, it is not live while I type. And so much more.
LispWorks knows different modes, can handle different encodings,
etc.
> So far I have never found anything useful in that menu anyway.
I have.
> > Handling text files is mostly broken. It tells me something about
> > Open... and Open Unix..., Load... and Load Unix... Which other
> > application does that???
>
> remember that Unix and Mac text files ARE different.
The Mac now is Unix.
> It's nice of MCL
> to give you this option. This is not brocken at all. One could try to
> make this exchange a bit more transparent but there is some trickery
> involved.
I create a new file in MCL and save it. I can only save it
with the old Mac OS 9 line endings, okay.
I drag this file on Text Edit. The result looks fine. I drag
it on LispWorks. Fine, too. I open it with Emacs, fine too.
Now I create a file in emacs. I drag it on Text Edit. Looks fine.
I drag it on LispWorks. Looks fine. I drag it on MCL. I fails
to understand the lineendings.
> > Drag&drop for the text fields is not working. I can't drag clippings
> > to the finder. No context sensitive menu in the text field.
>
> ok: but this is not a big one. Be honest: how many times did you use
> that menu to have your Mac speak your text?
For example I use it in Newswatcher to wrap/unwrap text,
in LispWorks to manipulate Lisp code, in Keynote to
manipulate items, ...
Drag&Drop is also essential. I was writing some stuff
on another machine in the Terminal, selected the text
dragged the selection to the finder on some shared
drive. From another machine I could open the clipping.
No saving dialogs or similar involved. Nice smooth interaction.
> > The preferences dialog is so Mac OS 6...
>
> The LW preference dialog has single check box! The entire preference
> setup is not compliant at all with OS X, OS 8,7,6,... guidelines at
> all. I don't know what it is but certainly not Mac. I find it very
> confusing.
Sure. Mac OS X preference dialogs are looking different from
what I see in LispWorks or MCL.
> > Font usage is totally inconsistent all over the place.
>
> yes it could be better. LW is not that great either.
Yes.
> > If you look at the MCL and its IDE, this is clearly a Mac OS 8+ (!!)
> > application ported to Mac OS X. But there is only VERY little that
> > makes it look & feel like a Mac OS X application.
>
> Again not sure what you are comparing MCL to.
Take Xcode.
> OpenMCL and ACL do not
> have native interfaces. LispWork's document model seem to be rooted in
> pre-window, single font, EMACS on VT100, split screen modes. Load
> different Lisp files into the same window. That was a great idea on a
> VT100. Now we have windows. Somebody told me that this can be changed
> but this is the default!
I don't find it too bad. Setting this option isn't too difficult.
I expect every application to be customized. Before I
use GraphicConverter on a new machine, I always walk
through the settings and change things so that I like it.
> Evaluating someting in window: covers up my
> whole buffer with the result, then i have to press space to get back.
> How cool is that?
It is as arbitrary like to use the top-most not-busy Lisp listener
like in MCL. In LispWorks the output is associated to the
Editor window. In MCL not.
> I am sorry, but i like the idea of having and using
> multiple windows. No need to press space, or switch between tabs.
Sure, but LispWorks gives you multiple windows. Sometimes
more than you like. It even can link windows together.
> > I haven't tried much to look around for real Mac-OS-X-like
> > application development environments. Xcode would come to
> > my mind. Apple currently has about 1000 software engineers
> > writing software and lots of them are doing applications.
> > The new standards are Mac OS X 10.4 (if you have access to the
> > developer versions), iPhoto, Keynote, Pages, iTunes, iMovie,
> > Final Cut Express HD, Safari, Garageband, and so on... Lisp
> > systems are currently far behind ... no similar application
> > has been demonstrated with Lisp in the last years. (This
> > used to be different many years ago, when, for example,
> > Microsoft used MCL to prototype Word user interface ideas).
> > Plus no Lisp idea makes good use of all the nice stuff in
> > Mac OS X for its own Integrated Development Environment (IDE).
>
> This is just a simple example but have a look at Deep Navel
> (http://deepnav.com/). It was implemented in MCL. Uses Quarz rendering,
> QuickTime, Metal windows, ...
The interface looks good, but is a bit limited.
> We cannot compete with 1000 of programmers but look at the some of our
> research projects, e.g, http://agentsheets.com/research/ (check out the
> interactive fliers). Mobility Agents tracks GPS bus equipped buses. Mr.
> Vetro simulates human physiology on PDAs. MCL is at core of these
> projects. It does the 3D simulation, user interface, networking to PDAs
> and cell phones, ...
Cool stuff.
> > Summary: MCL 5.0 is not a useful tool for general Mac OS X
> > development.
>
> simply not true. My summary: all the current OS X lisp implementations
> are bad. Nobody seems to have read the human guideline documentation.
> If they use Cocoa or Carbon is irrelevant. The user interface is the
> same.
That's why I say: there is currently no Lisp with a Mac-like user
interface (defined by what you read currently in Apple's
User Interface Guidelines and what applications Apple
currently releases). There's an opportunity to grab that
(emerging) market.
> > It has not been updated to Mac OS X in several crucial
> > areas.
>
> some interfaces are dated but so are the LW ones (e.g., OpenGL).
In MCL *most* stuff is dated. From the documentation on.
Don't get me wrong. I have liked MCL. But with Mac OS X 10.1 I decided
to leave Mac OS 9 behind. Now with Mac OS X 10.4 almost ready,
Mac OS X has got a better user interface with sexy looks. And I like
it very much.
Fortune had a long article on Apple recently. Steve Jobs talked
about what made the new Apple possible. It is software.
They have build good tools to write software. Lots of software
(-> http://www.apple.com/software/ ). Lisp sh/would fit nicely
in this picture.
> alex
Rainer
Rainer Joswig wrote:
> Actually I think LispWorks is much better than MCL. LispWorks isn't
> the great Mac-like Lisp either, but it far is better than MCL
> in MANY ways.
I have a cold right now: no time for deep thoughts. I feel compelled to
reply to your points one by one because I think MCL does have answers
and frankly I think MCL is better than LispWorks. But what would be the
point? Regarding Cocoa versus Carbon let's just respectfully agree to
disagree. Both are interfaces to OS X functionality. It really does not
matter which one to use. Ultimately it has nothing to do with legacy
versus new. Let's just be clear on one thing. To argue for or against
one or the other is largely a waste of time. The one party benefiting
from this is not Apple. MS must have some good laughs to see the small
Apple developer community (not just Lisp) getting divided over this.
Take for example the discussion of native threads in MCL versus
OpenMCL. OpenMCL came out of MCL. The choice to switch to from Carbon
to Cocoa for OpenMCL - I claim - resulted in the quick separation of
development efforts. Now we have two development threads, pardon the
metaphor, that cannot easily be unified/synchronized. Do you want to
have native threads OR a nice development environment? This, my
friends, is a huge shame. Who benefits from this: nobody. The small
developer community who uses OS X who uses Lisp has been successfully
fragmented.
Perhaps there is little we can do now. OS X is a great OS attracting
new talent. It would be time to have a great native Lisp implementation
for OS X. This is not a question of Carbon versus Cocoa but one of
having a complete Lisp environment that adopts the OS X look and feel
and provides access to all the frameworks and tools available for OS X.
This Lisp should be inspired by Xcode types of tools and not pseudo
window, split screen VT100 dinosaurs. I do not know how can fit the
bill. LispWorks is a generic cross platform tool. It's OK for that
purpose but far from being a native OS X Lisp. From my point of view it
deserves to be a case study on how not to write a modern OS X
application. Allegro has similar cross platform ambitious which it
tries to cover with X11 interfaces (which I personally hate). MCL and
OpenMCL have the right spirit of OS X nativeness ("M" for Macintosh)
but have sadly split into situation that allows next to no synergy.
There is probably no need for another cross platform Lisp. I will just
recommend the developers of Allegro and LispWorks to read the Mac Human
Interface Guidelines and to play with tools such as Xcode and REALbasic
(http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html#//apple_ref/doc/uid/20000957)
At the same time I hope there will be a new great OS X native Lisp. I
think if MCL and OpenMCL would find a way to reunite it would allow the
development effort to reach critical mass and create a great
programming environment: 64 bit, multi processing, ephemeral garbage
collector, Xcode style project manager, ... now that would be great!
Alex
> This reflects our desire for a Mac OS X lisp that interfaces well
with
> Cocoa
Could you please list a few Cocoa applications that I have on my
machine so I can test them out so that I can experience first hand what
I am missing.
> while your preference for MCL reflects your desire for a Mac OS X
> lisp that interfaces well with Carbon, understandable as you have a
very
> large body of Carbon compatible legacy code.
We also have a large body of legacy code ... that increases from day to
day since we continue to develop on Carbon. We do find it sufficiently
flexible and it does what we need.
> BTW, while it is true that CAPI is a "generic - non OS X -
interface,"
> Mac OS X users of LispWorks are not limited to CAPI - you can load
> Interface Builder nib files, and create any Cocoa UI you want.
I am interested in knowing more about Interface Builder. In our current
MCL applications we have hundreds of different user interfaces that are
generated at run time by MCL's compiler. The displays are not static
pre-defiend UI's but are dynamic since the layouts depend on what kind
and amount of data is present at the moment a display is created, e.g.,
what pop-up menus are created, what menus/menu-items they hold (dynamic
menu hierarchy), the direct linking of menu items to CLOS objects via
closures, other items such as dialogs have similar behaviour. Automatic
allocation of screen real-estate is also a necessity and it supports
real-time resizing of the screen so it does not matter what screen size
one is using. Font size is optimized at resize time for best fit. So
could MCL be used to control Interface Builder at run time, i.e.,
supply a specification and have it created immediately and used within
a few hundred ms? Would this work?
In article <························@f14g2000cwb.googlegroups.com>,
···············@hut.fi wrote:
> Could you please list a few Cocoa applications that I have on my
> machine so I can test them out so that I can experience first hand what
> I am missing.
Here are some Cocoa apps I run regularly:
Safari
Mail
GarageBand
iMovie (and iMovie HD)
iChat
iSync
Sherlock
Colloquy (irc client)
Pages
Keynote (i.e., iWork '05)
Terminal
XCode
InterfaceBuilder
NetNewsWire (or NetNewsWire Lite)
Console
iCal
iPhoto
Disk Utility
Transmit
TextEdit
System Preferences
Preview
StickyBrain
Activity Monitor
Backup
Virex 7.5
One way, possibly the easiest way, to tell whether an app is Cocoa is to
see if any of its controls can be used while the app is in the
background by command-clicking on them, or if this causes the app to
come foreground. Note that I am *not* referring to window widgets, such
as title bars, zoom buttons, etc., as these actually belong to the
WindowServer, rather than the app. If you can operate any of the app's
controls via command click, and it remains in the background, it is a
Cocoa app.
For example, with a Finder window foreground, you can change tabs in
Safari, by command-clicking on a different tab. This is, in part, "what
[you] are missing" - the ability to work in multiple applications
simultaneously - you can load a different website in Safari without
leaving your news reader by command-clicking on one of your bookmark
buttons. But you can't check for new articles in your news reader while
you're working in a Terminal window if your news reader is
MT-NewsWatcher, because MT-NewsWatcher is a Carbon app, and to do
anything in it, you must bring it foreground first.
More importantly from a programmer's perspective, what you are missing
is the ability to get this sort of functionality essentially for free as
part of the Cocoa frameworks, rather than having to do it manually with
Carbon.
regards
From: Ulrich Hobelmann
Subject: Re: Common LISP Implementations for Mac OS X?
Date:
Message-ID: <39hag3F5svqfvU2@individual.net>
Raffael Cavallaro wrote:
> One way, possibly the easiest way, to tell whether an app is Cocoa is to
> see if any of its controls can be used while the app is in the
> background by command-clicking on them, or if this causes the app to
> come foreground. Note that I am *not* referring to window widgets, such
> as title bars, zoom buttons, etc., as these actually belong to the
> WindowServer, rather than the app. If you can operate any of the app's
> controls via command click, and it remains in the background, it is a
> Cocoa app.
Nice! Now if they would only implement keyboard-focus-follows-mouse for
the WM. Then I would feel right at home like on a Unix.
In article <······································@comcast.dca.giganews.com>,
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote:
> One way, possibly the easiest way, to tell whether an app is Cocoa is to
> see if any of its controls can be used while the app is in the
> background by command-clicking on them, or if this causes the app to
> come foreground. Note that I am *not* referring to window widgets, such
> as title bars, zoom buttons, etc., as these actually belong to the
> WindowServer, rather than the app. If you can operate any of the app's
> controls via command click, and it remains in the background, it is a
> Cocoa app.
I just tried this in OmniWeb, and command-clicking back in a background
window made the foreground window go back.
Oops. :-)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
In article <·······················@attbi_s01>,
Brian Downing <·············@lavos.net> wrote:
> I just tried this in OmniWeb, and command-clicking back in a background
> window made the foreground window go back.
>
> Oops. :-)
With OmniWeb in the background, if you command-click on the bookmarks
button, the bookmarks window appears in the background, and OmniWeb
stays in the background. If you command-click on the refresh button, the
page/tab refreshes, and OmniWeb stays in the background. However, if you
command-click on a bookmark in the bookmarks bar above the tab bar,
OmniWeb comes foreground. The back and forward buttons don't work with
command-click (bad), but OmniWeb doesn't come foreground (good), the
back and forward pop-up lists do work (good, but weird considering
simple back and forward do not work). WTF?
OmniWeb is very flaky. I once had high hopes for it, but it has been
well and truly lapped by Safari. The Tiger version of Safari, which
promises rss feed integration, should bury OmniWeb for good.[1]
In any event, the point is that it is not possible to click on
*anything* inside a Carbon app's window (remember, window widgets like
the title bar don't count - they belong to the WindowServer) while it is
in the background without bringing it foreground. Cocoa gives you the
ability to make buttons, pop-ups, etc. function without bringing the app
foreground.
[1] It probably hasn't helped any that the Omni Group's founder and a
lead interface designer left to form Delicious Monster.