Author |
Message |
John Kle #1 / 18
|
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 |
|
|
Daniel Barlo #2 / 18
|
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 |
|
|
Thomas F. Burdi #3 / 18
|
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 |
|
|
Daniel Barlo #4 / 18
|
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 |
|
|
Paolo Amoros #5 / 18
|
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 |
|
|
Thomas F. Burdi #6 / 18
|
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 |
|
|
John Kle #7 / 18
|
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 |
|
|
Daniel Barlo #8 / 18
|
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 |
|
|
John Kle #9 / 18
|
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 |
|
|
Daniel Barlo #10 / 18
|
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 |
|
|
Daniel Barlo #11 / 18
|
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 |
|
|
Edi Weit #12 / 18
|
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 |
|
|
Thomas F. Burdi #13 / 18
|
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 |
|
|
Christophe Rhode #14 / 18
|
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 |
|
|
Edward O'Conno #15 / 18
|
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 |
|
|
Page 1 of 2
|
[ 18 post ] |
|
Go to page:
[1]
[2] |
|