CMUCL or SBCL on the Mac 
Author Message
 CMUCL or SBCL on the Mac

I read on some CMUCL or SBCL mailing list that it should take about 1 man-week
to port CMUCL or SBCL to the Macintosh.     Supposedly, the port is
easy for someone with knowledge of CMUCL/SBCL internals because CMUCL and/or SBCL
already runs on Linux/PPC, and Darwin is just another Unix variant.

Is there anyone out there who is interested in doing such a port, perhaps
in return for financial support?   If so, how much?  And are there other
people out there who want Mac CMUCL enough to be willing to help fund such a
project?

I realise that there is a distant projects to fund (eg) a 64 bit CMUCL,
but a Mac port seems small, realistic, and reasonably cheap.   At the moment,
the big factor dissuading me from getting a Mac is the lack of CMUCL.

(I know about [Open]Mcl, but it has slow math.   And I know about
Lispworks, but I have a lot of effort invested in CMUCL FFI code, which
would make LW far more expensive to me than the nominal sales price.)



Tue, 03 Jan 2006 18:28:18 GMT  
 CMUCL or SBCL on the Mac

Quote:

> I read on some CMUCL or SBCL mailing list that it should take about
> 1 man-week to port CMUCL or SBCL to the Macintosh.  Supposedly, the
> port is easy for someone with knowledge of CMUCL/SBCL internals
> because CMUCL and/or SBCL already runs on Linux/PPC, and Darwin is
> just another Unix variant.

There's most of an SBCL port already: I suspect it's taken more than a
week already, though ;-) Ask on the sbcl-devel list for current
status, but I believe it's in a "works but has rough edges still"
state.

Quote:
> (I know about [Open]Mcl, but it has slow math.   And I know about
> Lispworks, but I have a lot of effort invested in CMUCL FFI code, which
> would make LW far more expensive to me than the nominal sales price.)

SBCL FFI is practically the same as CMUCL, but for a renamed package
and few renamed symbols.  It's certainly not hard to maintain FFI code
that runs on both.

-dan

--

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources



Tue, 03 Jan 2006 20:57:53 GMT  
 CMUCL or SBCL on the Mac

Quote:

> Is there anyone out there who is interested in doing such a port, perhaps
> in return for financial support?   If so, how much?  And are there other
> people out there who want Mac CMUCL enough to be willing to help fund such a
> project?

I'd intended to port SBCL, and eventually CMUCL to the Mac, but I
haven't had the time.  Dan Barlow's port is much further along than
mine was.  It's been languishing on my "it would be cool if I had time
to do this" list for a while.

However, I'm about to begin work on a new CMUCL/Solaris app, and it
would be *really* nice to be able to set up the same environment on my
iBook.  Nice enough that I'd be happy to pay for it.  Nice enough that
I'd like to try to organize funding for such an endeavor.

So, anyone who'd be interested in contributing, please speak up,
publicly or otherwise.

--
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                              
   |     ) |                              
  (`-.  '--.)                              
   `. )----'                              



Thu, 05 Jan 2006 09:14:56 GMT  
 CMUCL or SBCL on the Mac

Quote:
> I'd intended to port SBCL, and eventually CMUCL to the Mac, but I
> haven't had the time.  Dan Barlow's port is much further along than
> mine was.  It's been languishing on my "it would be cool if I had time
> to do this" list for a while.

In the "credit where due" department, I have to point out that it's
not _just_ my port - in fact, probably not primarily my port, these
days.

* The original PPC backend for CMUCL was written by Gary Byers (yes,
  the same Gary Byers as OpenMCL and previously Digitool).

* I ported this backend to SBCL, to run on Linux PPC.

* Brian Mastenbrook, Pierre Mai and Patrick Nordebo have all worked on
  runtime support for MacOS X

* Other SBCL developers (notably Christophe Rhodes) have fixed bugs
  and patched things here and there.

Quote:
> However, I'm about to begin work on a new CMUCL/Solaris app, and it
> would be *really* nice to be able to set up the same environment on my
> iBook.  Nice enough that I'd be happy to pay for it.  Nice enough that
> I'd like to try to organize funding for such an endeavor.

I'm curious: what are the gaps that you see between SBCL and CMUCL
currently?  There's a reasonable degree of consensus[*] among CMUCL
developers that the long-term roadmap for CMUCL is to switch to SBCL,
so from the perspective of avoiding potentially wasted effort it might
be better to spend time enhancing SBCL to the point that it neets your
needs as a CMUCL user.  (As an SBCL developer, of course, that's what
I'd prefer to be doing, too ...)

Of course, whether that's practical depends on how much is missing.

[*] several are "for", others have made no public statement, none have
yet come out as "against"

-dan

--

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources



Thu, 05 Jan 2006 20:41:47 GMT  
 CMUCL or SBCL on the Mac

Quote:

> However, I'm about to begin work on a new CMUCL/Solaris app, and it

Just a reminder[*] that if it is a commercial/research application, and
there are no confidentiality issues, you might consider adding an entry to
the industrial applications or research organizations page at the ALU CLiki
site:

  http://alu.cliki.net

Paolo

[*] I guess I'm beginning to border obnoxiousness...
--



Thu, 05 Jan 2006 21:57:00 GMT  
 CMUCL or SBCL on the Mac

Quote:


> > I'd intended to port SBCL, and eventually CMUCL to the Mac, but I
> > haven't had the time.  Dan Barlow's port is much further along than
> > mine was.  It's been languishing on my "it would be cool if I had time
> > to do this" list for a while.

> In the "credit where due" department, I have to point out that it's
> not _just_ my port - in fact, probably not primarily my port, these
> days.

Cool, thanks for the credits.  I hadn't been keeping track for a while now.

Quote:
> > However, I'm about to begin work on a new CMUCL/Solaris app, and it
> > would be *really* nice to be able to set up the same environment on my
> > iBook.  Nice enough that I'd be happy to pay for it.  Nice enough that
> > I'd like to try to organize funding for such an endeavor.

> I'm curious: what are the gaps that you see between SBCL and CMUCL
> currently?

What pops to mind is: Wire, Hemlock[*], Garnet, calling into Lisp.  These
are probably all fairly easy (I know the last one is, I wrote an
implementation of it for CMUCL).  The CMUCL byte compiler is a nice
thing to have.  I haven't been using SBCL recently, so I'm not sure if
the speed gap has been closed enough, but I suspect it has for most
things.

For this particular project, an absolute killer is SBCL's less stable
status.  Things change more over there (although maybe this perception
is outdated?), and the version number is < 1.  I know that if someone
other than WHN were to number SBCL's versions, it would probably be
1.something by now, but that doesn't matter for purposes of selling it
to a client.

Quote:
> There's a reasonable degree of consensus[*] among CMUCL developers
> that the long-term roadmap for CMUCL is to switch to SBCL, so from
> the perspective of avoiding potentially wasted effort it might be
> better to spend time enhancing SBCL to the point that it neets your
> needs as a CMUCL user.  (As an SBCL developer, of course, that's
> what I'd prefer to be doing, too ...)

I know that this would be my preference.  I wish I had the free time
to grab some CMUCL subsystems and port them, but alas...

Quote:
> Of course, whether that's practical depends on how much is missing.

I feel like there might have been other things, but I could be wrong.

[*] Hemlock really is a requirement for me, for a server app.  ILISP
works okay, but occasionally I've ended out with a hosed environment,
due to a confused ILISP.  I really don't want that to happen with a
server.  Hemlock hasn't ever done this to me (knock on wood).

--
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                              
   |     ) |                              
  (`-.  '--.)                              
   `. )----'                              



Fri, 06 Jan 2006 11:18:03 GMT  
 CMUCL or SBCL on the Mac
Thanks for all the replies.



Quote:
>However, I'm about to begin work on a new CMUCL/Solaris app, and
>it would be *really* nice to be able to set up the same
>environment on my iBook.  Nice enough that I'd be happy to pay
>for it.  Nice enough that I'd like to try to organize funding
>for such an endeavor.

I have a similar problem - I could affort a commercial lisp for my
personal machine, but not for my Solaris work machine(s).  I
would be interested in helping pay for a port, but I just saw
that that Christophe Rhodes wrote on the SBCL mailing list:

      I don't want to steal anyone's thunder, but the SBCL port
      is essentially complete.  There are as far as I recall two
      remaining issues; one is to sort out assembly syntax to
      enable ldso-stubs.S to compile, which will allow dynamic
      linking to work; the second is to generate an appropriate
      floating point environment such that traps can be handled
      decently, rather than producing infinities and NaNs.
      However, these two issues aside, the binaries that have
      been produced pass SBCL's regression test suite and those
      tests in Paul Dietz' suite that are expected to pass; in
      other words, a small amount of cleanup work would raise
      SBCL's MacOS port status to "supported".  (Not in this
      month's release, but with luck next month, and I'd hope
      that it would make an appearance in the CVS repository
      early rather than late).


Quote:
> I'm curious: what are the gaps that you see between SBCL and
> CMUCL currently?

I simply don't use SBCL because I used CMUCL from the start, and
being a mere user I don't mind CMUCL's supposed internal
ugliness.  I have the vague impression that CMUCL is more stable
and the compiler is faster because SBCL was a bit de-optimized
before being rebuilt.  Is this true?  I also have the impression that
SBCL is on its way to having OS-level threads.


Fri, 06 Jan 2006 17:22:39 GMT  
 CMUCL or SBCL on the Mac

Quote:

> I simply don't use SBCL because I used CMUCL from the start, and
> being a mere user I don't mind CMUCL's supposed internal
> ugliness.  I have the vague impression that CMUCL is more stable
> and the compiler is faster because SBCL was a bit de-optimized
> before being rebuilt.  Is this true?  I also have the impression that
> SBCL is on its way to having OS-level threads.

"There is this special biologist word we use for 'stable'. It is 'dead'."
     -- Jack Cohen

But more seriously, do you mean "stable" as in "doesn't fall over as
much", or "stable" as in "doesn't make incompatible changes as
frequently"?  In sense (1), my experience has been that there's not
much to choose between them - I've had web sites running with both
that have continued going for months at a time before being stopped
for upgrade.  In sense (2), you'll need to recompile all your fasls
every time you get a new release of /either/ system, but as SBCL
releases once a month, and CMUCL releases approximately once a year,
the effect is less obvious for CMUCL.  The impact on source code
compatibility is also comparable: you migght find in either system,
say, that your previously unchecked function type declaration was
incorrect and now no longer compiles.

Of course, nobody says you have to upgrade every time a new SBCL
release is made, but if you find a bug we might say "this is fixed in
the latest version, try that".  In much the same way, the CMUCL people
might say "this is fixed in CVS, try a snapshot".

I believe the CMUCL compiler is still faster.

Native threads are currently in a "usable, but apply caution" state:
as with the CMUCL userland threads, we don't know that the standard
library is all threadsafe (chances are it's not, in fact), so they
really do need testing for whatever specific application you're doing.
That said, I'm using a thread-enabled build on all my machines, and
it works quite nicely with CLX and (albeit rather slowly, due to use
of process-wait) McCLIM.  You can run threaded web servers too: Kevin
Rosenberg has support for sb-thread in cl-modlisp (his lisp client
library for mod_lisp), which I understand is at least competitive in
speed with the other platforms he'd tested, maybe faster.  There may
be SBCL thread support in Portable Allegroserve too; someone who knows
more about that project can contribute there.

-dan

--

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources



Fri, 06 Jan 2006 18:33:58 GMT  
 CMUCL or SBCL on the Mac

Quote:

> But more seriously, do you mean "stable" as in "doesn't fall over as
> much", or "stable" as in "doesn't make incompatible changes as
> frequently"?

Both.  Perhaps I should have said that I don't use SBCL _yet_ because
it is developing rapidly and doesn't offer any huge advantages
over CMUCL, yet.  Mostly, I am happy to use what I have, upgrading
once a year.  I am waiting for a reason to switch over, like
a shiny new Ti-book in need of a lisp compiler.

A couple of questions:

Is SBCL compiled code slower, or is it just compilation that is not as quick?

Are threads expected to run on platforms besides Linux?



Fri, 06 Jan 2006 23:38:37 GMT  
 CMUCL or SBCL on the Mac

Quote:
>> I'm curious: what are the gaps that you see between SBCL and CMUCL
>> currently?

> What pops to mind is: Wire, Hemlock[*], Garnet, calling into Lisp.  These
> are probably all fairly easy (I know the last one is, I wrote an

This is good feedback; thanks.  

 - A brief read says that Wire and Remote look trivial.  Should be
   portable in an afternoon.

 - Garnet is (notionally) portable code, isn't it?  We have a pretty
   good CLX for SBCL, so I see no reason this shouldn't work.  Well,
   except for the garnet loader being full of #+impl with no #+sbcl
   clause, but that's trivial if tedious

 - SBCL provisions for calling into Lisp are about as good as CMUCL on
   non-x86 systems.  No scavenger hooks (they're gencgc-only), so be
   careful with GC, but funcall[0123] works just as it does in CMUCL

Hemlock is a bigger job, I think.  Gilbert Baumann has a project
called Portable Hemlock whose goal is to remove its dependence on
CMUCL internals (it'll never be portable-as-in-ANSI, if only
because it's impossible to implement dired using only CL pathnames)
but progress seems slow there.  He has other stuff to do too, of course.

I use an incredibly low-tech solution for my persistent servers:
detachtty.  It's like screen, but less complicated.  In theory ilisp
can connect to a Lisp using it, but I don't trust ilisp enough to
run production sites, so I usually edit in emacs locally then cut and
paste into the repl.  Like I said, low tech.  Find it on cliki

Quote:
> implementation of it for CMUCL).  The CMUCL byte compiler is a nice
> thing to have.  I haven't been using SBCL recently, so I'm not sure if
> the speed gap has been closed enough, but I suspect it has for most
> things.

The compiler is still slower, to the point that I often build under
CMUCL instead of using SBCL itself to build.  Our perception, I think,
is that end-users are typically developing interactively; as long as
compilation of a single function (or realisitically, a single file) is
still too fast to break mental flow, this is not a priority

The speed of executed code is pretty similar between the two:
according to everyone's favourite microbenchmark suite cl-bench, SBCL
is faster on some stuff, CMUCL on others, and with few exceptions both
are within 100% of each other.

Quote:
> For this particular project, an absolute killer is SBCL's less stable
> status.  Things change more over there (although maybe this perception

I don't know, but I think that's as much a problem of perception as
reality.  SBCL does more frequent releases than CMUCL, but that's
because we're time-boxing and they're feature-boxing.  Probably they
put out CVS snapshot binaries about as often as we release anyway.

Certainly when it comes to really big changes (renaming all the
packages, or removing the interpreter) I think we're pretty much done
between here and 1.0.  It would be nice to get CLOS integrated all the
way into the system so that we could use it in the compiler, but that
ought not to be user-visible.

-dan

--

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources



Fri, 06 Jan 2006 23:48:19 GMT  
 CMUCL or SBCL on the Mac

Quote:

> A couple of questions:

> Is SBCL compiled code slower, or is it just compilation that is not as quick?

I'm just looking at a cl-bench run I did a few minutes ago.  It's not
really fair because it compares the current CVS version of SBCL with
the 12 month old CMUCL I had installed ("3.1.2 18d+ 24 September
2002"), and there's been a fair amount of development since then, but
if you were happy with the speed of CMUCL 12 months ago, it doesn't
indicate any particular cause for concern.

Quote:
> Are threads expected to run on platforms besides Linux?

Someone's working on FreeBSD support, which mostly seems to involve
the usual signal handling issues.  There's no reason in principle that
they shouldn't work elsewhere too, but all my machines are Linux, so I
won't be doing the work myself unless I can persuade someone to pay
for it.

-dan

--

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources



Fri, 06 Jan 2006 23:58:14 GMT  
 CMUCL or SBCL on the Mac

Quote:

> I use an incredibly low-tech solution for my persistent servers:
> detachtty.  It's like screen, but less complicated.  In theory ilisp
> can connect to a Lisp using it, but I don't trust ilisp enough to
> run production sites, so I usually edit in emacs locally then cut
> and paste into the repl.  Like I said, low tech.  Find it on cliki

You're the author, so it's your right to call it "low-tech". I think
it's a very fine and helpful piece of software and use it for all
remote Lisps I maintain. Combine it with something like rlwrap[1] and
you also have command line editing and auto completion (although not
dynamic as in CLISP). It's not as comfortable as ILISP but it has
never killed a Lisp image behind my back - ILISP has...

Edi.

[1] <http://weitz.de/completions.html>



Sat, 07 Jan 2006 00:06:45 GMT  
 CMUCL or SBCL on the Mac

Quote:

>  - SBCL provisions for calling into Lisp are about as good as CMUCL on
>    non-x86 systems.  No scavenger hooks (they're gencgc-only), so be
>    careful with GC, but funcall[0123] works just as it does in CMUCL

I was referring to a more-supported interface, like the one in cvs
CMUCL, or the one that I implemented myself for CMUCL.  I imagine it's
easy for SBCL, too (and in fact, Christophe mentioned that cvs SBCL
just grew this).

Quote:
> Hemlock is a bigger job, I think.  Gilbert Baumann has a project
> called Portable Hemlock whose goal is to remove its dependence on
> CMUCL internals (it'll never be portable-as-in-ANSI, if only
> because it's impossible to implement dired using only CL pathnames)
> but progress seems slow there.  He has other stuff to do too, of course.

I've looked at Portable Hemlock.  But I want the full integration.

Quote:
> I use an incredibly low-tech solution for my persistent servers:
> detachtty.  It's like screen, but less complicated.  In theory ilisp
> can connect to a Lisp using it, but I don't trust ilisp enough to
> run production sites, so I usually edit in emacs locally then cut and
> paste into the repl.  Like I said, low tech.  Find it on cliki

Well, the whole reason I want Hemlock is that I want the nice
environment, and I trust it not to kill the image.  Lacking Hemlock,
I'd go with something like detachtty ... but, I've got Hemlock right
here.

Quote:
> > implementation of it for CMUCL).  The CMUCL byte compiler is a nice
> > thing to have.  I haven't been using SBCL recently, so I'm not sure if
> > the speed gap has been closed enough, but I suspect it has for most
> > things.

> The compiler is still slower, to the point that I often build under
> CMUCL instead of using SBCL itself to build.  Our perception, I think,
> is that end-users are typically developing interactively; as long as
> compilation of a single function (or realisitically, a single file) is
> still too fast to break mental flow, this is not a priority

> The speed of executed code is pretty similar between the two:
> according to everyone's favourite microbenchmark suite cl-bench, SBCL
> is faster on some stuff, CMUCL on others, and with few exceptions both
> are within 100% of each other.

Oh, good.  I would be reluctant to give up the byte compiler, though,
because I've gotten great mileage out of it in the past.

Quote:
> > For this particular project, an absolute killer is SBCL's less stable
> > status.  Things change more over there (although maybe this perception

> I don't know, but I think that's as much a problem of perception as
> reality.

Well, partly this is perception (I got to harp on the continuity of
CMUCL over the decades, which went a long way to my being able to use
Lisp at all).  Partly, I'm a bit scared of SBCL changing under me...

Quote:
> SBCL does more frequent releases than CMUCL, but that's because
> we're time-boxing and they're feature-boxing.  Probably they put out
> CVS snapshot binaries about as often as we release anyway.

... I was using SBCL during the 0.6.x -> 0.7.x era, and was thinking
of that.

Quote:
> Certainly when it comes to really big changes (renaming all the
> packages, or removing the interpreter) I think we're pretty much done
> between here and 1.0.

This, I like to hear.

--
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                              
   |     ) |                              
  (`-.  '--.)                              
   `. )----'                              



Sat, 07 Jan 2006 02:11:53 GMT  
 CMUCL or SBCL on the Mac

Quote:

>>  - SBCL provisions for calling into Lisp are about as good as CMUCL on
>>    non-x86 systems.  No scavenger hooks (they're gencgc-only), so be
>>    careful with GC, but funcall[0123] works just as it does in CMUCL

> I was referring to a more-supported interface, like the one in cvs
> CMUCL, or the one that I implemented myself for CMUCL.  I imagine it's
> easy for SBCL, too (and in fact, Christophe mentioned that cvs SBCL
> just grew this).

I'm sorry, I didn't mean to imply this in my mail; Nikodemus Siivola
hasn't submitted his ideas to the development list yet (and I doubt
that they're in any kind of finished form).

Your issue then, as I understand it, is not the ease of
implementation; why else are you worrying about support?  It's not
clear what the _right_ way of implementing callbacks is; at the very
least, I suspect that you need two variants, one for symbols (that go
through FDEFINITION or equivalent at every call; for instance, used in
graphical user interface callbacks, for ease of development) and one
for functions, when direct call and efficiency are important (for
instance, passing a function to a numerical integration library).
Absent a clear view on what the right way of doing things is, and
given the demonstrable ease of implementation by interested users,
I'd guess that there's scope for people to think about design before
anything is merged into sbcl's CVS (but I'm open to thoughts there :-)

Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



Sat, 07 Jan 2006 03:32:24 GMT  
 CMUCL or SBCL on the Mac

Quote:
> I use an incredibly low-tech solution for my persistent servers:
> detachtty.  It's like screen, but less complicated.  In theory ilisp
> can connect to a Lisp using it, but I don't trust ilisp enough to
> run production sites, so I usually edit in emacs locally then cut and
> paste into the repl.  Like I said, low tech.  Find it on cliki

It's not ILISP, but I haven't had any problems using attachtty with
Emacs's standard inferior lisp mode.

Ted

--
Edward O'Connor



Sat, 07 Jan 2006 05:23:40 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. more cmucl & sbcl questions

2. SBCL vs. CMUCL

3. SBCL and/or CMUCL

4. CMUCL and mac OSX?

5. AMD64 port for SBCL

6. SBCL 0.8alpha: first prerelease

7. SBCL port to NetBSD

8. UFFI and CLSQL now support SBCL & OpenMCL

9. SBCL, a new free Common Lisp based on CMU CL

10. Calling SBCL from C with array arguments

11. SBCL core dumps?

12. Product Announcement - APL.68000 Level II for Mac and Power Mac

 

 
Powered by phpBB® Forum Software