I've been away from programming for a little while and wish to get
back into it. I have Paul Graham's ANSI Common Lisp book as well as
his On Lisp book and Peter Norvig's Paradigms book. I want to start
working through the first two on my Mac. I just need a quick boost.
I am presently running a self compiled version of GNU Emacs (built
for Carbon). It is a bit out of date as I haven't been able to do a
CVS update since the GNU Project server compromise. I don't know if
I should refresh or not.
I definitely do need to get an SBCL binary that will run under
Panther and would also like to be able to build from CVS.
I want to get ILISP or SLIME (whichever is considered better) setup
and my .emacs configured so that M-X lisp launches me into SBCL.
I think all I need to do this is a pointer to the best HOW-TO (best
being defined as the simplest set of instructions to follow) to do
all this. Recommended tutorials for using Emacs with SBCL would be
nice also.
I have the dev tools (Xcode 1.1, GCC, etc) installed so I can compile
if I have to so long as the instructions are clear.
If all this info isn't in one place, I'll try to correct that by
setting up a page that describes the above as I do it. I get the
impression that there is an interest in Lisp but not everyone gets
over the initial hump. I understand that all too well.
I have in mind to do a graphics programming project that uses OpenGL
and I've been running in circles about the best language to write
it. I keep comming back to Lisp like a strange attractor. Only the
development environment has been keeping me away. Perhaps I can fix
that in due time (shortly after the heat death of the universe).
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Hello David,
I would also recommend OpenMCL which is supported out of the
box on Emacs and ilisp. You might also check out the free version
of LispWorks. Both are great Common LISP implementations for
Mac OS X. CLisp is also very useful, but I like the runtime
performance that you get with natively compiled code.
Useful links:
http://openmcl.clozure.com/
http://www.lispworks.com
-Mark
David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
> I've been away from programming for a little while and wish to get
> back into it.
Welcome Back. Here's what I'm doing with Lisp under Panther...
> I am presently running a self compiled version of GNU Emacs (built
> for Carbon). It is a bit out of date as I haven't been able to do a
> CVS update since the GNU Project server compromise. I don't know if
> I should refresh or not.
I'm using Emacs out of CVS from about 2 weeks ago. I had trouble
compiling even the most recent packaged versions. The configure
script told me my platform wasn't supported. The CVS version seems to
work great with SLIME and sbcl or openmcl.
> I definitely do need to get an SBCL binary that will run under
> Panther and would also like to be able to build from CVS.
I haven't had any luck building the SBCL releases under panther. They
compile most of the way but then error out and the produced binary
doesn't run. It just segfaults immediately. I keep meaning to post
something about it to see if anyone knows a work around. Maybe
someone will see this. :-)
You can get a precompiled version of a slightly old SBCL here:
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-0.8.6-g5-or-panther-binary.tar.bz2
OpenMCL however, works great. I'm using the newest release and it
built fine out of the box.
> I want to get ILISP or SLIME (whichever is considered better) setup
> and my .emacs configured so that M-X lisp launches me into SBCL.
Most people would recommend SLIME, myself included. It works fine on
OS X through Carbon Emacs with OpenMCL or SBCL. Just check it out of
CVS and follow the directions in the README and INSTALL files. It
will tell you how to set up Emacs to use the right Lisp. I recommend
using the FAIRLY_STABLE tag, as I had less luck with the CVS HEAD
version.
I'd take a look at the CLiki SLIME pages. It lists all the basic
keybindings and everything.
http://www.cliki.net/SLIME
http://www.cliki.net/SLIME%20Tips
http://www.cliki.net/SLIME%20Features
http://www.cliki.net/SLIME-HOWTO
> I have in mind to do a graphics programming project that uses OpenGL
> and I've been running in circles about the best language to write
> it. I keep comming back to Lisp like a strange attractor. Only the
> development environment has been keeping me away. Perhaps I can fix
> that in due time (shortly after the heat death of the universe).
You may want to look into OpenMCL rather than SBCL just because of the
Objective-C bridge. It depends on what you need. I personally am
more comfortable with SBCL but use OpenMCL on occasion because of it's
ability to play nice with Objective-C.
Good luck with your project.
Justin Dubs
Justin Dubs wrote:
> David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
>
>>I have in mind to do a graphics programming project that uses OpenGL
>>and I've been running in circles about the best language to write
>>it. I keep comming back to Lisp like a strange attractor. Only the
>>development environment has been keeping me away. Perhaps I can fix
>>that in due time (shortly after the heat death of the universe).
It is tough getting started (esp. with that open source garbage -- Just
Buy Lispworks! Or MCL.), but it is a finite amount of pain, then...
well, then you get a little more pain mastering the FFI to talk to
opengl, tho there are bindings out there to be had. But then you jump to
hyperspeed, so it is seriously worth the hurdles.
My Cello GUI project:
(+ CL GLUT OpenGL ImageMagick &optional Cells Supercollider)
... is still gestating on win32 (delayed by what seems to be "Kenny
Learns Texture-Mapping!" week) but shortly I will be sharing it with a
few hardy souls who claim not to mind the sight of blood, a couple of
whom are on OS X and OpenMCL. I myself plan at the same time to
undertake a (+ (or MCL Lispworks) OSX) port, so OS X should be in hand
shortly.
Meanwhile, Lispworks ships with OpenGL readily accessible. Buy that,
your time is worth it.
As for what language, based on the ease with which one can screw up
programming in opengl and not get a clue as to what one si doing wrong,
I think opengl is a killer app for Lisp, because we can use macros and
the reflective power to encapsulate necessary sequences and enforce
proper opengl usage.
my2.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> As for what language, based on the ease with which one can screw up
> programming in opengl and not get a clue as to what one si doing
> wrong, I think opengl is a killer app for Lisp, because we can use
> macros and the reflective power to encapsulate necessary sequences
> and enforce proper opengl usage.
So I've lost track--what is the recommended way to get to OpenGL from
Lisp. Is there a UFFI wrapping somewhere?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
>>>>> "PS" == Peter Seibel <·····@javamonkey.com> writes:
[...]
PS> So I've lost track--what is the recommended way to get to
PS> OpenGL from Lisp. Is there a UFFI wrapping somewhere?
Try cl-sdl (it includes opengl) for something that aspires to be
cross-platform. Worked fine when I tried it (maybe a year go?).
http://cl-sdl.sourceforge.net/
BM
Bulent Murtezaoglu wrote:
>>>>>>"PS" == Peter Seibel <·····@javamonkey.com> writes:
>
> [...]
> PS> So I've lost track--what is the recommended way to get to
> PS> OpenGL from Lisp. Is there a UFFI wrapping somewhere?
>
> Try cl-sdl (it includes opengl) for something that aspires to be
> cross-platform. Worked fine when I tried it (maybe a year go?).
>
> http://cl-sdl.sourceforge.net/
I can second that. That was how I got started on OpenGL. there is a
one-window limitation, last I knew.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
KT> ... is still gestating on win32 (delayed by what seems to be
KT> "Kenny Learns Texture-Mapping!" week) but shortly I will be
KT> sharing it with a few hardy souls who claim not to mind the
KT> sight of blood, ...
Why not just open it up if you will open it up anyway?
KT> Meanwhile, Lispworks ships with OpenGL readily accessible. Buy
KT> that, your time is worth it.
Actually the trial version should have the bindings too. The win there
is that if you will use CAPI, opengl is available as a capi pane (capi is
available in the trial version too). On the other hand free lisps on
non-win32 + bindings are available and work OK also.
KT> As for what language, based on the ease with which one can
KT> screw up programming in opengl and not get a clue as to what
KT> one si doing wrong, I think opengl is a killer app for Lisp,
KT> because we can use macros and the reflective power to
KT> encapsulate necessary sequences and enforce proper opengl
KT> usage.
Of course for that to happen we probably shouldn't pretent we are an
illiterate monkey! (Really Kenny, since I think there might be
something to your claim that you are 10x the programmer most of us
are, I'd love to see you do things right in areas that matter to me).
I can see the utility of macros like with-new-display-list or
with-gl-context etc. but not much else in the way of macros is
obvious to me (but I am no expert in GL).
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> [...]
> KT> ... is still gestating on win32 (delayed by what seems to be
> KT> "Kenny Learns Texture-Mapping!" week) but shortly I will be
> KT> sharing it with a few hardy souls who claim not to mind the
> KT> sight of blood, ...
>
> Why not just open it up if you will open it up anyway?
Cello now is an unpolished, undocumented, incomplete, (+ win32 (or
Lispworks AllegroCL))-only mess. I am finding astonishing gaffes all the
time, which is good because Cello is getting faster and faster. (the
texture thing is huge). There is especially no point in an open release
since only win32+acl/lw people could use it! besides, i have not been
much impressed by CL folks in re Actually Doing Anything to help CL open
source projects, so why bother? As soon as I get texture mapping working
the way I like I will ship what I have to folks who have been in touch
by email and we few, we happy few, can try to get Cello working on OS X
and elsewhere.
Good plan? :)
>
> KT> Meanwhile, Lispworks ships with OpenGL readily accessible. Buy
> KT> that, your time is worth it.
>
> Actually the trial version should have the bindings too. The win there
> is that if you will use CAPI, opengl is available as a capi pane (capi is
> available in the trial version too). On the other hand free lisps on
> non-win32 + bindings are available and work OK also.
>
> KT> As for what language, based on the ease with which one can
> KT> screw up programming in opengl and not get a clue as to what
> KT> one si doing wrong, I think opengl is a killer app for Lisp,
> KT> because we can use macros and the reflective power to
> KT> encapsulate necessary sequences and enforce proper opengl
> KT> usage.
>
> Of course for that to happen we probably shouldn't pretent we are an
> illiterate monkey!
Eeep! You should have seen me over here the past two days. It was at
times literally manual genetic programming with me randomly altering
values to see if I could get textures to appear. And then reappear after
I had them then lost them somehow.
(Really Kenny, since I think there might be
> something to your claim that you are 10x the programmer most of us
I said that? I think I said I was 10x more productive with Cells, and
that those who scoffed at Cells were free to give me the credit. :)
> are, I'd love to see you do things right in areas that matter to me).
> I can see the utility of macros like with-new-display-list or
> with-gl-context etc. but not much else in the way of macros is
> obvious to me (but I am no expert in GL).
Well there is other stuff. My FFI macros expand into wrapper functions
which for a while called the gl error check after /each/ ogl call (not
sure why I backed that out). I could also add a keyword to the FFI of
diff calls as to whether they were permitted between glBegin/glEnd, and
offer a helpful diagnostic. The FFI macro I have also allows code to be
specified which runs before (to do sanity checks).
Opengl sometimes silently does nothing if things are not quite right. We
can set things up so we can add validation to ogl calls to give friendly
runtime diagnostics. etc etc.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> ... besides, i have not been
> much impressed by CL folks in re Actually Doing Anything to help CL open
> source projects, so why bother?
Let me correct the record. Thomas Burdick is doing Great Things, the
whole crew at common-lisp.net is doing yeoman's work, and I have been
approached by a few folks willing to take Cello "as is" and get it
running on other platforms, so I have nothing to whine about.
It really is too soon for others to dive in, and it is up to me to make
Cello irresistible so others /want/ to get involved. Speaking of which,
one of the monkeys over here accidentally typed out:
(gl-polygon-mode GL_FRONT_AND_BACK GL_FILL)
..and another slipped and fell onto CTRL-ALT-K to knock out a rogue:
(gl-disable GL_TEXTURE_2D)
...hiding in a text display widget, and it looks as textures are running
up the white flag. Watch for even sicker screen shots tonight.
Eep! Oop!
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
BM> Why not just open it up if you will open it up anyway?
KT> Cello now is an unpolished, undocumented, incomplete, (+ win32
KT> (or Lispworks AllegroCL))-only mess.
Oh, I'd forgotten about that win32 bit. Why are you on win32 again?
By choice?
KT> ... As soon as I get texture
KT> mapping working the way I like I will ship what I have to
KT> folks who have been in touch by email and we few, we happy
KT> few, can try to get Cello working on OS X and elsewhere.
KT> Good plan? :)
Sounds OK, but you'll probably have to decide in advance whether you will
release it with an open (whatever) licence. Otherwise all kinds of NDA
issues will creep in.
[...]
KT> Eeep! You should have seen me over here the past two days. It
KT> was at times literally manual genetic programming with me
KT> randomly altering values to see if I could get textures to
KT> appear. And then reappear after I had them then lost them
KT> somehow.
Yeah I once shared an office with a guy who was a fast typer but
didn't like reading. Different approach, but I must admit he got more
done. I did surprise him once (and gained respect that I had no idea
was missing) by nailing the incantation for some
pointer-to-function-returning-a-pointer... whatever in C for his code
by looking at the screen and K&R-ii and w/o monkey typing at all.
Anyway, yeah I noticed you were putting the opengl ng to good use.
[...]
KT> Well there is other stuff. My FFI macros expand into wrapper
KT> functions which for a while called the gl error check after
KT> /each/ ogl call (not sure why I backed that out).
Heh, I backed that out too. I presently think not checking it is not
the same kind of irresponsible behaviour as ignoring errno. The
errors are deterministic and and if there's an error no state change
happens (so you catch it). I dislike macroizing things I am not very
knowledgeable in especially if they come from a C api (because you might
want try to operate at a completely different level of abstraction that
goes beyond with-bla once you get it).
KT> I could also
KT> add a keyword to the FFI of diff calls as to whether they were
KT> permitted between glBegin/glEnd, and offer a helpful
KT> diagnostic. The FFI macro I have also allows code to be
KT> specified which runs before (to do sanity checks).
Hmm, that's a level of automation that might be useful but I am not sure
yet.
KT> Opengl sometimes silently does nothing if things are not quite
KT> right. We can set things up so we can add validation to ogl
KT> calls to give friendly runtime diagnostics. etc etc.
That's right, it does nothing. Or it does its thing consistently. If you
try one thing at a time you get the hang of it pretty quickly, it seems.
We want MORE PICTURES
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> [...]
> BM> Why not just open it up if you will open it up anyway?
>
> KT> Cello now is an unpolished, undocumented, incomplete, (+ win32
> KT> (or Lispworks AllegroCL))-only mess.
>
> Oh, I'd forgotten about that win32 bit. Why are you on win32 again?
> By choice?
Originally to do CliniSys (still has a pulse), now because I am fluent
in AllegroCL. But I signed on as an Apple developer and plan to make
that my main development platform shortly. NT was actually OK for me,
but XP is making me old.
> Sounds OK, but you'll probably have to decide in advance whether you will
> release it with an open (whatever) licence. Otherwise all kinds of NDA
> issues will creep in.
I think I'll stick with the MIT jobbie.
> Yeah I once shared an office with a guy who was a fast typer but
> didn't like reading.
That's me.
Different approach, but I must admit he got more
> done. I did surprise him once (and gained respect that I had no idea
> was missing) by nailing the incantation for some
> pointer-to-function-returning-a-pointer... whatever in C for his code
> by looking at the screen and K&R-ii and w/o monkey typing at all.
I had the reverse experience on a project once. Someone commended me for
being able to fix anything, and I unearthed an unknown disrespecter when
I said I just keep trying things at random until it works and he blurted
out rather dyspeptically, "That's right!". Whoa! :)
>
> We want MORE PICTURES
Any requests for who should grace the spinning cube from Nehe lesson 6?
That shot of Princess Grace (Kelly) brought some fan mail.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
······@eos.ncsu.edu (Justin Dubs) writes:
> I haven't had any luck building the SBCL releases under panther. They
> compile most of the way but then error out and the produced binary
> doesn't run. It just segfaults immediately. I keep meaning to post
> something about it to see if anyone knows a work around. Maybe
> someone will see this. :-)
Brian Mastenbrook posted a patch against SBCL 0.8.7.55 (was
bleeding edge about three hours ago) on one of the SBCL mailing lists.
This patch seems to be absolutely required for building SBCL under
MacOSX.
With this patch, I had no problem building SBCL from an older
version that I built myself some time back (using a binary supplied by
Brian, and an earlier version of the patch posted today).
Note: there have been reports that gcc 3.1 is required; so I
used "gcc_select 3.1" before starting the build.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
In article <··············@raw.grenland.fast.no>, Raymond Wiker
<·············@fast.no> wrote:
> ······@eos.ncsu.edu (Justin Dubs) writes:
>
> Brian Mastenbrook posted a patch against SBCL 0.8.7.55 (was
> bleeding edge about three hours ago) on one of the SBCL mailing lists.
> This patch seems to be absolutely required for building SBCL under
> MacOSX.
An older version of this patch has been available on my site for quite
some time; this just brings it up to date with CVS HEAD and simplifies
the build procedure so it can be run from make.sh (thanks to Brian
Downing).
> With this patch, I had no problem building SBCL from an older
> version that I built myself some time back (using a binary supplied by
> Brian, and an earlier version of the patch posted today).
Very good.
> Note: there have been reports that gcc 3.1 is required; so I
> used "gcc_select 3.1" before starting the build.
src/runtime/Config.ppc-darwin specifies that CC=gcc3 (aka gcc 3.1), so
you don't need to change your systemwide compiler.
Brian
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Raymond Wiker <·············@fast.no> writes:
> Brian Mastenbrook posted a patch against SBCL 0.8.7.55 (was
> bleeding edge about three hours ago) on one of the SBCL mailing lists.
> This patch seems to be absolutely required for building SBCL under
> MacOSX.
It's not required for building SBCL under MacOS 10.2, at least with
the sample of one machine that I have access to :-)
> With this patch, I had no problem building SBCL from an older
> version that I built myself some time back (using a binary supplied by
> Brian, and an earlier version of the patch posted today).
That's good to hear.
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)
David Steuber <·············@verizon.net> writes:
> I definitely do need to get an SBCL binary that will run under
> Panther and would also like to be able to build from CVS.
I believe Brian Mastenbrook's binaries are considered the best place
to start:
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
Note that as of about yesterday, the run-program bug is allegedly
completely fixed, so once you've got something that runs you'll
definitely want to pull up to date CVS. You need run-program or
asdf-install even if you never wqant to use it yourself ;-)
> I think all I need to do this is a pointer to the best HOW-TO (best
> being defined as the simplest set of instructions to follow) to do
> all this. Recommended tutorials for using Emacs with SBCL would be
> nice also.
Not a direct answer to your question (I don't use macos and can't
advise), but you might find the mac-lisp-ide list relevant -
http://common-lisp.net/mailman/listinfo/mac-lisp-ide
-dan
--
"please make sure that the person is your friend before you confirm"
In article <··············@noetbook.telent.net>,
Daniel Barlow <···@telent.net> wrote:
> David Steuber <·············@verizon.net> writes:
>
> > I definitely do need to get an SBCL binary that will run under
> > Panther and would also like to be able to build from CVS.
>
> I believe Brian Mastenbrook's binaries are considered the best place
> to start:
>
> http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
>
> Note that as of about yesterday, the run-program bug is allegedly
> completely fixed, so once you've got something that runs you'll
> definitely want to pull up to date CVS. You need run-program or
> asdf-install even if you never wqant to use it yourself ;-)
Unfortunatly the 0.8.7.54 image I built yesterday still produces random
SIGILL crashes. This was not a problem in the 0.8.6 on Brian's site
above.
To the OP, I would be hesitent to use the 0.8.7 series on Mac OS X for
production work until this is cleaned up. If you do, testing it a lot
would be good to minimize nasty surprises.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
In article <························@attbi_s02>,
Brian Downing <·············@lavos.net> wrote:
> Unfortunatly the 0.8.7.54 image I built yesterday still produces random
> SIGILL crashes. This was not a problem in the 0.8.6 on Brian's site
> above.
>
> To the OP, I would be hesitent to use the 0.8.7 series on Mac OS X for
> production work until this is cleaned up. If you do, testing it a lot
> would be good to minimize nasty surprises.
Apparently Brian has had more luck building with gcc-3.1 than gcc-3.3,
so the situation may not be as dire as I indicated above. Sorry!
More than likely there will be a new binary release available there soon
if things work out.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> writes:
> In article <························@attbi_s02>,
> Brian Downing <·············@lavos.net> wrote:
>> Unfortunatly the 0.8.7.54 image I built yesterday still produces random
>> SIGILL crashes. This was not a problem in the 0.8.6 on Brian's site
>> above.
>>
>> To the OP, I would be hesitent to use the 0.8.7 series on Mac OS X for
>> production work until this is cleaned up. If you do, testing it a lot
>> would be good to minimize nasty surprises.
>
> Apparently Brian has had more luck building with gcc-3.1 than gcc-3.3,
> so the situation may not be as dire as I indicated above. Sorry!
>
> More than likely there will be a new binary release available there soon
> if things work out.
I just tried building 0.8.7.55 on my PB G4, and am getting
SIGBUS at every attempt at starting sbcl (with cold-sbcl.core). I'll
try with gcc 3.1, and see if that helps.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
David Steuber <·············@verizon.net> writes:
> I want to get ILISP or SLIME (whichever is considered better) setup
> and my .emacs configured so that M-X lisp launches me into SBCL.
I think SLIME is easier (trust me: I am a former ILISP maintainer :)
Just read the README file in the source distribution, and check the
tips provided in the SLIME pages at CLiki. Note that SLIME also
supports OpenMCL.
Concerning ILISP, see Bill Clementson's tutorial.
> If all this info isn't in one place, I'll try to correct that by
> setting up a page that describes the above as I do it. I get the
That would be appreciated anyway. I seem to remember that there is a
CLiki for Lisp users under Mac, but I can't remember its name.
> it. I keep comming back to Lisp like a strange attractor. Only the
> development environment has been keeping me away. Perhaps I can fix
You may want to check Clotho:
http://www.common-lisp.net/project/clotho/
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
First off, let me thank everyone for their replies to what is
probably a FAQ. I really appreciate it and I think I now have what I
need to start working through Graham's book (ACL).
I do plan to setup a web page for OS X Lisp stuff. The scope will be
limited to my personal exploits. Until that is up, here is what I
have got/done so far.
GNU Emacs built for Carbon:
http://members.shaw.ca/akochoi-emacs/stories/obtaining-and-building.html
I refreshed my CVS copy last night and recompiled to make sure I had
the latest stuff. One annoying bug was fixed that I have seen so
far. I don't know about breakage yet.
I updated SLIME from CVS. SLIME seems to get the most
recomendations, so I will go ahead and learn with that.
I forgot to mention that I have Darwin Ports
http://darwinports.opendarwin.org/
installed on my machine. Darwin Ports has both OpenMCL and CLISP. Both
appear to be at their latest versions. Because of recomendations, I
have setup OpenMCL instead of SBCL for now. I actually do not want
to marry myself to any particular Lisp at the moment, but it
shouldn't matter for working through Graham's book. I hope not
anyway.
I have the hyperspec, but I don't recall where I got that from.
It's not a priority for me yet, but I would like to be able to toggle
between different Lisps in SLIME. I forsee wanting to bounce between
OpenMCL, CLISP, and SBCL. I have no idea what I will use if I get to
a point where I am writing production level code, ie stuff that I
would be willing to distribute.
As I mentioned before, I will want to use OpenGL. That is a bridge I
will cross in the future, so it isn't a priority right now. I just
need to have a similar enough development environment to what I learn
Lisp on so that I don't have to overload my brain.
While I expect that Debian is the best (or ranks way up there)
environment for learning Lisp, I have some valid reasons for wanting
to play on OS X. I think the work done by people on Carbon Emacs,
SLIME, and OpenMCL has made the hump to getting started one that is
crossable.
I can actually forsee a time when I would like to be able to write
fully source portable code that works on both OS X and Debian.
Having the same IDE in both environments would be appealing. So far
that looks to be Emacs + SLIME. However, they look kind of primative
next to Xcode (which is really only good for Objective-C (ok, and
Java)).
Oh, before I forget, I did run into an oddity with SLIME. When I
first entered M-x slime, Emacs got frozen. I think that was related
to the initial compile of the swank stuff. I was a bit concerned
over that and had to force quit Emacs. However, when I started it up
again, it appeared to work. There were some warnings of
unimplimented features. I gather SLIME is still being worked on, so
I'm not too worried about that.
Anyway, thanks again. I'll probably have other questions as I
proceed through Graham's book.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: Piet van Oostrum
Subject: Re: Who is using SBCL on OSX 10.3.2?
Date:
Message-ID: <wz7jyhamke.fsf@cs.uu.nl>
>>>>> David Steuber <·············@verizon.net> (DS) wrote:
DS> I refreshed my CVS copy last night and recompiled to make sure I had
DS> the latest stuff. One annoying bug was fixed that I have seen so
DS> far. I don't know about breakage yet.
Could be dangerous. On the developers list several recently introduced bugs
were mentioned.
--
Piet van Oostrum <····@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: ·············@hccnet.nl
Piet van Oostrum <····@cs.uu.nl> writes:
> >>>>> David Steuber <·············@verizon.net> (DS) wrote:
>
> DS> I refreshed my CVS copy last night and recompiled to make sure I had
> DS> the latest stuff. One annoying bug was fixed that I have seen so
> DS> far. I don't know about breakage yet.
>
> Could be dangerous. On the developers list several recently introduced bugs
> were mentioned.
That is a risk. SLIME is also in development and OpenMCL 0.14.1-p1
is 'alpha'. I guess that is part of the nature of going with free
software rather than proprietary.
Perhaps I should be looking into Lispworks.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
"David Steuber" <·············@verizon.net> wrote in message
···················@david-steuber.com...
> That is a risk. SLIME is also in development and OpenMCL 0.14.1-p1
> is 'alpha'. I guess that is part of the nature of going with free
> software rather than proprietary.
I suspect "free" is orthogonal to "robust". How many documented bugs was
Windows XP released with?
Not to dis commercial code, but I think there is a lot of open source that
is as good; what commercial may buy you (well, other than with M$), is
direct support. This is clearly important in some cases, but not with all.