hi lisp list
i want to know if it is possible to compile lisp programs in emacs or
not . . .
i'm looking at digitool's mcl, but as a very part time lisp enthusiast
it is quite expensive to get into
thanks
howie
····@brainlink.com (; ; m o n k) wrote in message news:<····························@posting.google.com>...
> hi lisp list
>
> i want to know if it is possible to compile lisp programs in emacs or
> not . . .
>
> i'm looking at digitool's mcl, but as a very part time lisp enthusiast
> it is quite expensive to get into
>
> thanks
>
> howie
I have a Mac at home using OS9 (I am not allowed to change it as I am
not the only one who uses the computer), and have done some rooting
around. If you need all of Common Lisp implemented, then I think MCL
is your only choice. However I am still learning the language so:
PowerLisp 2.02 www.corman.net is very good. It has gone open-source
as well, and the link to the source-forge project is on the site.
Also it has some really nice interface choices that I have become
addicted to. The Worksheet design I think is great.
There is also xlisp which covers a subsection of the language, but
again is good for hobbying and learning because if there is anything
missing in the language you can just make it. I have not reached
macros and special functions yet but so have tested neither of these
systems for this functionality yet.
What I do is if the example is not working in one, try it in the
other, and between them you usually can test your code.
Hope this helps,
Rohan
> I have a Mac at home using OS9 (I am not allowed to change it as I am
> not the only one who uses the computer), and have done some rooting
> around. If you need all of Common Lisp implemented, then I think MCL
> is your only choice. However I am still learning the language so:
> PowerLisp 2.02 www.corman.net is very good. It has gone open-source
> as well, and the link to the source-forge project is on the site.
> Also it has some really nice interface choices that I have become
> addicted to. The Worksheet design I think is great.
>
> There is also xlisp which covers a subsection of the language, but
> again is good for hobbying and learning because if there is anything
> missing in the language you can just make it. I have not reached
> macros and special functions yet but so have tested neither of these
> systems for this functionality yet.
>
> What I do is if the example is not working in one, try it in the
> other, and between them you usually can test your code.
>
> Hope this helps,
>
> Rohan
hi rohan,
yes this is good info., maybe i won't dump my xlisps then, and grabbed
powerlisp last night, thanks!
In article <····························@posting.google.com>,
····@brainlink.com (; ; m o n k) wrote:
>i'm looking at digitool's mcl, but as a very part time lisp enthusiast
>it is quite expensive to get into
Are you a student?
If you are a student, the "newstand" price is $85. This is a bargain
for what you a get -- a professional, time-tested development
environment.
(If you are a non-student in the education world (e.g., a professor),
the price is $275. Otherwise, the price is $345.)
Sashank
·············@vanderbilt.edu (Sashank Varma) wrote in message news:<······························@129.59.212.53>...
> In article <····························@posting.google.com>,
> ····@brainlink.com (; ; m o n k) wrote:
>
> >i'm looking at digitool's mcl, but as a very part time lisp enthusiast
> >it is quite expensive to get into
>
> Are you a student?
>
> If you are a student, the "newstand" price is $85. This is a bargain
> for what you a get -- a professional, time-tested development
> environment.
>
> (If you are a non-student in the education world (e.g., a professor),
> the price is $275. Otherwise, the price is $345.)
>
> Sashank
no, i'm not a student anymore
i didn't realize that powerlisp was opensource now, so that should
probably do me pretty well
do mast people use emacs anyway? or are the lisp editors similar to
emacs?
thanks
howie
In article <····························@posting.google.com>,
; ; m o n k <····@brainlink.com> wrote:
>do mast people use emacs anyway? or are the lisp editors similar to
>emacs?
The editors supplied with integrated Lisp development environments are
often miniature Emacses. The basic editing commands are similar to Emacs,
and they're usually extendable using that Lisp dialect, but because they're
not used as widely as GNU Emacs there isn't a huge conglomeration of
packages for them like there is for Emacs. E.g. you probably won't find
any sophisticated mail readers for these Lisp editors.
But if you're used to Emacs, you should be comfortable editing your Lisp
code in these editors.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> The editors supplied with integrated Lisp development environments are
> often miniature Emacses. The basic editing commands are similar to Emacs,
> and they're usually extendable using that Lisp dialect, but because they're
> not used as widely as GNU Emacs there isn't a huge conglomeration of
> packages for them like there is for Emacs. E.g. you probably won't find
> any sophisticated mail readers for these Lisp editors.
...and since we were talking about lisps for the mac: MCLs own FRED
(FRED Resembles Emacs Deliberately) is a very cool little emacs, where
both emacs people and mac ui people feel at home immediately. It's
completeley programmable in CLOS, and it's great fun to write
applications based on FRED. AND there are quite a number of FRED
extensions available on Digitools share-/freeware ftp server.
--
(espen)
In article <····························@posting.google.com>,
····@brainlink.com (; ; m o n k) wrote:
> hi lisp list
>
> i want to know if it is possible to compile lisp programs in emacs or
> not . . .
>
> i'm looking at digitool's mcl, but as a very part time lisp enthusiast
> it is quite expensive to get into
>
> thanks
>
> howie
CMU LISP runs on emacs.
Fredrik.
--
Fredrik Andersen Kavli
Nykirkeallmening 5
5005 Bergen, Norway
...I made this!
**please change NOMAIL to STUDENT for replying**
················@nomail.no (Fredrik A. Kavli) writes:
> In article <····························@posting.google.com>,
> ····@brainlink.com (; ; m o n k) wrote:
>
> > hi lisp list
> >
> > i want to know if it is possible to compile lisp programs in emacs or
> > not . . .
> >
> > i'm looking at digitool's mcl, but as a very part time lisp enthusiast
> > it is quite expensive to get into
> >
> > thanks
> >
> > howie
>
> CMU LISP runs on emacs.
>
> Fredrik.
Not quite :-)
Emacs has, via a package called ilisp, support for interacting
with several Common Lisp implementations. The Common Lisp
implementations run *outside* of Emacs.
So, if you want to use Emacs for Common Lisp programming, you
need an Emacs implementation for your platform, as well as a Common
Lisp implementation for that platform. CMUCL runs on quite a few
platforms; CLISP even more.
Maybe the original poster would care to tell us what the
platform is?
//Raymond.
--
Raymond Wiker
·············@fast.no
Raymond Wiker <·············@fast.no> writes:
> Maybe the original poster would care to tell us what the
> platform is?
I think from the subject line it looks like he wants to use a Mac. If
he doesn't want to buy Digitool's product (as he has stated) and can't
live with their free trial-out version, he has three choices AFAIK:
1. Use Mac OS X and CLISP <http://clisp.cons.org/>
2. Use LinuxPPC and OpenMCL <http://openmcl.clozure.com/>
3. Use Mac OS Classic with Corman's PowerLisp <http://www.corman.net>
The first two are free, open source implementations. The third one is
free for personal use.
As far as Emacs is concerned, it'll run on the first two operating
systems and the ILISP package has support for CLISP. The OpenMCL site
offers a patch at
<http://openmcl.clozure.com/FTP/ILISP/README-openmcl-ilisp> to use
ILISP with OpenMCL as well.
My apologies if I have left out any choices.
HTH,
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> As far as Emacs is concerned, it'll run on the first two operating
> systems and the ILISP package has support for CLISP. The OpenMCL site
^-- (Mac OS X and Linux PPC)
> offers a patch at
> <http://openmcl.clozure.com/FTP/ILISP/README-openmcl-ilisp> to use
> ILISP with OpenMCL as well.
Actually, there's an Emacs port to Mac OS, it's just not merged into
any mainstream Emacs distro. I have no idea about its quality.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Actually, there's an Emacs port to Mac OS, it's just not merged into
> any mainstream Emacs distro. I have no idea about its quality.
Yep, I knew that but didn't consider it an option. I tested it a while
ago only to find out that it crashes with more recent versions of Mac
OS. (Or maybe it was just my particular setup. I can't check now
'cause I've sold all my Macs.)
The folks who ported GNU Emacs to NT did a great job but even with
cygwin I still miss some things when I have to use it under Windows
(i.e. when I have to use Windows). IMHO Mac OS (Classic) is too far
away from Unix to make Emacs usable on this platform.
I bet it won't be able to support ILISP...
Edi.
PS: This is getting OT now, sorry.
thanks all
for the references to check out - i downloaded emacs for mac at
sourceforge, but don't know the reliability yet as you surmise
emacs is suppossed to come with elisp, and can, i just learned compile
to byte code, but whether or not it will be limited in the long run i
do not know
i'll keep on researching
in terms of ease of set up it seems that mcl or powerlisp would be the
way to go then? i've got to look more closely at the other
builds/ports still
i won't be on osx until midi support is stable . . .
howie
In article <····························@posting.google.com>,
; ; m o n k <····@brainlink.com> wrote:
>emacs is suppossed to come with elisp, and can, i just learned compile
>to byte code, but whether or not it will be limited in the long run i
>do not know
Emacs Lisp is a pretty archaic dialect of Lisp. It's perfectly usable, as
witnessed by all the Emacs packages available, but you need to be aware
that there are many differences between it and Common Lisp, and most Lisp
books that you would use to learn from make use of Common Lisp. Emacs Lisp
is closer in style to MACLISP (the "MAC" prefix has nothing to do with
Macintosh, it refers to MIT's Project MAC in the 60's).
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Actually, there's an Emacs port to Mac OS, it's just not merged into
> any mainstream Emacs distro. I have no idea about its quality.
In OS X there are several options, including a plain GNU emacs runnable
in terminal mode that comes with the default install from Apple.
--
(espen)
> Actually, there's an Emacs port to Mac OS, it's just not merged into
> any mainstream Emacs distro. I have no idea about its quality.
finally getting back through these links
yes and that's what i've grabbed from sourceforge:
http://sourceforge.net/projects/mac-emacs/
howie / monk
On 20 Sep 2001 10:35:40 +0200, ···@agharta.de (Dr. Edmund Weitz)
wrote:
>Raymond Wiker <·············@fast.no> writes:
>> Maybe the original poster would care to tell us what the
>> platform is?
>I think from the subject line it looks like he wants to use a Mac. If
Xlisp is another free option.
> Xlisp is another free option.
yeah i've had xlisp-plus 3.0.4, basically a unix port with command
line access (read very limited menus), and xlisp 2.1g which has better
menus
xlisp-plus needs to be maintained by somebody else because the current
holder is giving it up, i've just been in e-mail contact there
and, to me they both seem kind of flimsy, even though i admit i don't
know how to program in lisp very well at all
Raymond Wiker <·············@fast.no> writes:
> Emacs has, via a package called ilisp, support for interacting
> with several Common Lisp implementations. The Common Lisp
> implementations run *outside* of Emacs.
>
> So, if you want to use Emacs for Common Lisp programming, you
> need an Emacs implementation for your platform, as well as a Common
> Lisp implementation for that platform. CMUCL runs on quite a few
> platforms
The Mac, unfurtunately, is not one of them.
Well, there's a PPC backend in CMUCL, but last I heard from Eric
Marsden, the runtime support is not all there yet. And when it is,
it'll be Linux/PPC rather than MacOS. The original poster didn't
specify an OS, admittedly, so I'm assuming he wanted MacOS.
> Maybe the original poster would care to tell us what the
> platform is?
See the subject line (for the hardware architecture, anyway)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
>>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
Daniel> Raymond Wiker <·············@fast.no> writes:
>> Emacs has, via a package called ilisp, support for interacting
>> with several Common Lisp implementations. The Common Lisp
>> implementations run *outside* of Emacs.
>>
>> So, if you want to use Emacs for Common Lisp programming, you
>> need an Emacs implementation for your platform, as well as a Common
>> Lisp implementation for that platform. CMUCL runs on quite a few
>> platforms
Daniel> The Mac, unfurtunately, is not one of them.
Daniel> Well, there's a PPC backend in CMUCL, but last I heard from Eric
Daniel> Marsden, the runtime support is not all there yet. And when it is,
Daniel> it'll be Linux/PPC rather than MacOS. The original poster didn't
Daniel> specify an OS, admittedly, so I'm assuming he wanted MacOS.
But presumably, once Linux/PPC works, it shouldn't be extremely hard
to get it to run on MacOS X. Having such a machine, I'd like CMUCL
there.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
>
> Daniel> Raymond Wiker <·············@fast.no> writes:
> >> Emacs has, via a package called ilisp, support for interacting
> >> with several Common Lisp implementations. The Common Lisp
> >> implementations run *outside* of Emacs.
> >>
> >> So, if you want to use Emacs for Common Lisp programming, you
> >> need an Emacs implementation for your platform, as well as a Common
> >> Lisp implementation for that platform. CMUCL runs on quite a few
> >> platforms
>
> Daniel> The Mac, unfurtunately, is not one of them.
>
> Daniel> Well, there's a PPC backend in CMUCL, but last I heard from Eric
> Daniel> Marsden, the runtime support is not all there yet. And when it is,
> Daniel> it'll be Linux/PPC rather than MacOS. The original poster didn't
> Daniel> specify an OS, admittedly, so I'm assuming he wanted MacOS.
>
> But presumably, once Linux/PPC works, it shouldn't be extremely hard
> to get it to run on MacOS X. Having such a machine, I'd like CMUCL
> there.
Unfortunately that is not the case. The calling conventions for MacOSX
is different than that of LinuxPPC, and is more like the calling
conventions for IBM's AIX operating system. Actually, it is the other
way around, since the AIX calling convention predated LinuxPPC, which
follows a SVr4 ABI PowerPC-specific spec - it is that spec which I
presume is the "different" one (although I prefer it over the AIX
version).
Anyway, it is less trouble to move an AIX port to MacOSX than to move
a LinuxPPC port at the register and calling sequence level.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> Raymond Toy <···@rtp.ericsson.se> writes:
>>
>> But presumably, once Linux/PPC works, it shouldn't be extremely hard
>> to get it to run on MacOS X. Having such a machine, I'd like CMUCL
>> there.
Duane> Unfortunately that is not the case. The calling conventions for MacOSX
I was assuming that the very hard work of getting the CMUCL backend to
run on PPC was done. Then changing the calling conventions for MacOS
would be much easier. But perhaps I'm totally off base here.
Duane> is different than that of LinuxPPC, and is more like the calling
Duane> conventions for IBM's AIX operating system. Actually, it is the other
Duane> way around, since the AIX calling convention predated LinuxPPC, which
Duane> follows a SVr4 ABI PowerPC-specific spec - it is that spec which I
Duane> presume is the "different" one (although I prefer it over the AIX
Duane> version).
Do you have a link for the MacOS X calling conventions? Just
curious. I looked once before but never found anything.
Duane> Anyway, it is less trouble to move an AIX port to MacOSX than to move
Duane> a LinuxPPC port at the register and calling sequence level.
If the registers have to be rearranged, then that could be quite
difficult. But should be much easier than getting CMUCL to run at
all.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> Do you have a link for the MacOS X calling conventions? Just
> curious. I looked once before but never found anything.
Google found a plausible-looking PDF at
http://developer.apple.com/techpubs/macosx/DeveloperTools/OS_X_PPC_RuntimeConventions/
for what that's worth
> If the registers have to be rearranged, then that could be quite
> difficult. But should be much easier than getting CMUCL to run at
> all.
Maybe Eric Marsden can describe exactly how far he's got if he sees
this thread, but I'm pretty sure he's past "getting it to run at all"
already. SBCL on PPC is practically at the "run at all" stage right
now (calls into lisp, blows up fairly early with some kind of stack
corruption) and I'm reasonably sure his work is more advanced than
mine.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Raymond Toy <···@rtp.ericsson.se> writes:
>
> > Do you have a link for the MacOS X calling conventions? Just
> > curious. I looked once before but never found anything.
>
> Google found a plausible-looking PDF at
>
> http://developer.apple.com/techpubs/macosx/DeveloperTools/OS_X_PPC_RuntimeConventions/
>
> for what that's worth
Yes, that's the one. Specifically, the document is in pdf form:
http://developer.apple.com/techpubs/macosx/DeveloperTools/OS_X_PPC_RuntimeConventions/OS_X_PPC_RuntimeConventions.pdf
I remember it taking me a long time to find the first time, and it took
me not much less time to find this time as well. It doesn't seem to be
very well linked; in fact I don't see any links to it on the
DeveloperTools page, although there are quite a few other useful
documents there as well.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> Daniel Barlow <···@telent.net> writes:
>> Raymond Toy <···@rtp.ericsson.se> writes:
>>
>> > Do you have a link for the MacOS X calling conventions? Just
>> > curious. I looked once before but never found anything.
>>
>> Google found a plausible-looking PDF at
>>
>> http://developer.apple.com/techpubs/macosx/DeveloperTools/OS_X_PPC_RuntimeConventions/
>>
>> for what that's worth
Duane> Yes, that's the one. Specifically, the document is in pdf form:
Duane> http://developer.apple.com/techpubs/macosx/DeveloperTools/OS_X_PPC_RuntimeConventions/OS_X_PPC_RuntimeConventions.pdf
Duane> I remember it taking me a long time to find the first time, and it took
Duane> me not much less time to find this time as well. It doesn't seem to be
Thanks (to both of you). I did look with google and on Apple's web
site a long while back, but obviously I used the wrong search terms.
I got nothing.
Ray
>>>>> "db" == Daniel Barlow <···@telent.net> writes:
db> Maybe Eric Marsden can describe exactly how far he's got if he sees
db> this thread, but I'm pretty sure he's past "getting it to run at all"
db> already.
I have been trying to run a port of CMUCL to PowerPC that was done in
1997 by Gary Byers, at the time of release 18a. Current status is that
simple evaluations work, but garbage collecting seems to corrupt the
stack. The port used to run, so presumably only relatively minor
changes would be needed; unfortunately I'm concurrently learning about
how CMUCL works internally, and am not very familiar with assembly, so
breaths should not be held.
OpenMCL works fine on LinuxPPC, is much more tractable than CMUCL
internally, has thread support, is very ANSI compliant. Its compiler
is less sophisticated, though. See <URL:http://openmcl.clozure.com/>.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Duane Rettig <·····@franz.com> writes:
> Unfortunately that is not the case. The calling conventions for MacOSX
> is different than that of LinuxPPC, and is more like the calling
> conventions for IBM's AIX operating system. Actually, it is the other
Are we talking about register allocation and stack frame layout here?
Most of the time CMUCL basically ignores the calling convention of the
host OS anyway, so I don't see it making much difference either way,
except that the glue for calling FFI stuff will need rewriting.
Of course, if that's not what you're talking about then I missed your
point...
The bits that probably will need changing are Unix glue stuff like
stat and rusage structure layout, signal numbers, memory layout (CMUCL
mmaps at fixed addresses, so let's avoid stomping on the shared
libraries), how to get register contents from a signal handler, and so
on. None of which is incredibly difficult (at least, generally
speaking, but I don't know macos x so maybe this time it _will_ be),
but much of which is tedious.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Unfortunately that is not the case. The calling conventions for MacOSX
> > is different than that of LinuxPPC, and is more like the calling
> > conventions for IBM's AIX operating system. Actually, it is the other
>
> Are we talking about register allocation and stack frame layout here?
> Most of the time CMUCL basically ignores the calling convention of the
> host OS anyway, so I don't see it making much difference either way,
> except that the glue for calling FFI stuff will need rewriting.
Correct, though lisp and C/asm conventions should at least be close
enough not to confuse system debuggers and exception handlers...
> Of course, if that's not what you're talking about then I missed your
> point...
You did not miss my point.
> The bits that probably will need changing are Unix glue stuff like
> stat and rusage structure layout, signal numbers, memory layout (CMUCL
> mmaps at fixed addresses, so let's avoid stomping on the shared
> libraries), how to get register contents from a signal handler, and so
> on. None of which is incredibly difficult (at least, generally
> speaking, but I don't know macos x so maybe this time it _will_ be),
> but much of which is tedious.
If you think of MacOSX as FreeBSD or OpenBSD, you'll have most of it
licked. However, the biggest difference is how they load
shared-libraries (which I presume was to deal with the more dynamic
nature of Objective-C in their NextStep software). Try 'man NSModule'.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: William Barnett-Lewis
Subject: How about OS/2? Or any other obscure system? (Re: learning lisp on a mac)
Date:
Message-ID: <3BAAA7D6.5412AA12@mailbag.com>
Duane Rettig wrote:
>
> Daniel Barlow <···@telent.net> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > Unfortunately that is not the case. The calling conventions for MacOSX
> > > is different than that of LinuxPPC, and is more like the calling
> > > conventions for IBM's AIX operating system. Actually, it is the other
> >
> > Are we talking about register allocation and stack frame layout here?
> > Most of the time CMUCL basically ignores the calling convention of the
> > host OS anyway, so I don't see it making much difference either way,
> > except that the glue for calling FFI stuff will need rewriting.
>
Ok, S&G time. Anything other than MIT Scheme for OS/2? Or anything else
that isn't BillyG or Linux ? Just curious more than anything else
anymore. I know the comercials will say "NO" while running screaming the
other way from me, but i've got an old Thinkpad that OS/2 is the only
real system it will run sensibly. I admit I'd be less worried if the
current version (7.5.17) actually worked on my system...
In the end, it's fine, I'm just curious if there's anything out there
that I've missed.
thanks,
William
--
You better watch out What you wish for;
It better be worth it So much to die for.
Courtney Love
From: ·······@my-deja.com
Subject: Re: How about OS/2? Or any other obscure system? (Re: learning lisp on a mac)
Date:
Message-ID: <nm9vgic63nv.fsf@biohazard-cafe.mit.edu>
Kawa Scheme should work fine with Java 1.1.6, which runs on OS/2
according to
http://www.3cat.com/java_os2/javaos2_faq.html#where
From: Hartmann Schaffer
Subject: Re: How about OS/2? Or any other obscure system? (Re: learning lisp on a mac)
Date:
Message-ID: <3bad11fa@news.sentex.net>
In article <·················@mailbag.com>,
William Barnett-Lewis <······@mailbag.com> writes:
> ..
> Ok, S&G time. Anything other than MIT Scheme for OS/2? Or anything else
> that isn't BillyG or Linux ? Just curious more than anything else
> anymore. I know the comercials will say "NO" while running screaming the
> other way from me, but i've got an old Thinkpad that OS/2 is the only
> real system it will run sensibly. I admit I'd be less worried if the
> current version (7.5.17) actually worked on my system...
>
> In the end, it's fine, I'm just curious if there's anything out there
> that I've missed.
i had clisp running on os/2 when i was still using it
hs
--
War is not healthy for children and other living beings
On 20 Sep 2001, Duane Rettig wrote:
> Daniel Barlow <···@telent.net> writes:
> > Are we talking about register allocation and stack frame layout here?
> > Most of the time CMUCL basically ignores the calling convention of the
> > host OS anyway, so I don't see it making much difference either way,
> > except that the glue for calling FFI stuff will need rewriting.
>
> Correct, though lisp and C/asm conventions should at least be close
> enough not to confuse system debuggers and exception handlers...
That's never stopped CMUCL in the past :) CMUCL doesn't even use the
machine return instruction on most architectures.
Tim
Duane Rettig <·····@franz.com> writes:
> If you think of MacOSX as FreeBSD or OpenBSD, you'll have most of it
> licked. However, the biggest difference is how they load
> shared-libraries (which I presume was to deal with the more dynamic
> nature of Objective-C in their NextStep software). Try 'man NSModule'.
I don't think this is going to be much of a problem until you
try to (explicitly) load a shared library into CMUCL (or SBCL). For
SBCL, at least, there are trampoline functions for all the
shared-library functions that the runtime needs.
--
Raymond Wiker
·············@fast.no
>>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
Daniel> Duane Rettig <·····@franz.com> writes:
>> Unfortunately that is not the case. The calling conventions for MacOSX
>> is different than that of LinuxPPC, and is more like the calling
>> conventions for IBM's AIX operating system. Actually, it is the other
Daniel> Are we talking about register allocation and stack frame layout here?
Daniel> Most of the time CMUCL basically ignores the calling convention of the
Daniel> host OS anyway, so I don't see it making much difference either way,
Daniel> except that the glue for calling FFI stuff will need rewriting.
But you do have to be careful. The Sparc ABI says certain global
registers are reserved to the system. CMUCL was stomping on them.
Fortunately, it seems that Solaris doesn't actually use them, and
fortunately, there were a couple of registers that could be stolen to
replace those reserved registers. Until the ABI changes, CMUCL should
be safe from that.
Ray
> Emacs has, via a package called ilisp, support for interacting
> with several Common Lisp implementations. The Common Lisp
> implementations run *outside* of Emacs.
>
raymond
at sourceforge here is the description of ilisp, can you help me
understand, what is (x)emacs then, and why 'inferior'?
>>ILISP A comprehensive (X)Emacs interface for an inferior Common
>>Lisp, or other Lisp based languages.
howie / monk
····@brainlink.com (; ; m o n k) writes:
> > Emacs has, via a package called ilisp, support for interacting
> > with several Common Lisp implementations. The Common Lisp
> > implementations run *outside* of Emacs.
> >
> raymond
>
> at sourceforge here is the description of ilisp, can you help me
> understand, what is (x)emacs then
That means "GNU Emacs or XEmacs", or both the major Emacs
distributions.
> , and why 'inferior'?
Because the lisp process runs as a child (or inferior) process of Emacs.
>>>>> On 24 Sep 2001 00:00:40 -0700, Thomas F Burdick ("Thomas") writes:
Thomas> ····@brainlink.com (; ; m o n k) writes:
>> > Emacs has, via a package called ilisp, support for interacting
>> , and why 'inferior'?
Thomas> Because the lisp process runs as a child (or inferior) process of Emacs.
To be more accurate: because more than 25 years ago on a PDP-10
operating system at MIT called ITS, the structure of what are in
today's OS parlance are "processes" was strictly hierarchical and
the phrase "inferior job" was used. It had nothing to do with
child (in the sense of "forked") processes on Unix. In particular,
there was a new TECO macro library called EMACS, and there were
libraries for communicating with an "inferior LISP job".
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On 24 Sep 2001 00:00:40 -0700, Thomas F Burdick ("Thomas") writes:
> Thomas> ····@brainlink.com (; ; m o n k) writes:
> >> > Emacs has, via a package called ilisp, support for interacting
> >> , and why 'inferior'?
> Thomas> Because the lisp process runs as a child (or inferior) process of Emacs.
>
> To be more accurate: because more than 25 years ago on a PDP-10
> operating system at MIT called ITS, the structure of what are in
> today's OS parlance are "processes" was strictly hierarchical and
> the phrase "inferior job" was used. It had nothing to do with
> child (in the sense of "forked") processes on Unix. In particular,
> there was a new TECO macro library called EMACS, and there were
> libraries for communicating with an "inferior LISP job".
Interesting to know. I figured it probably came from ITS, but Emacs
is so full of weird terminology that I hadn't thought too specifically
about that particular weird term.
>>>>> On 19 Sep 2001 23:17:15 -0700, ; ; m o n k (";") writes:
> hi lisp list
> i want to know if it is possible to compile lisp programs in emacs or not . . .
Emacs is an editor, and its extension language is its own dialect of
Lisp, called "Emacs Lisp" or sometimes "e-lisp". It is not the same
language as ANSI Common Lisp. Emacs Lisp is not nearly as powerful as
Common Lisp, but was influenced by ancestor dialects from the 1970s.
Emacs Lisp is mainly concerned with manipulating the data structures
in the Emacs editor (buffers, strings, windows, editor commands, etc.)
Emacs Lisp programs can be "compiled" from source code into a
compact, portable byte-code representation called ".el" files.
Most people compile their extension libraries.
Extension libraries implement all kinds of features, such as: much of
the basic editing commands and functionality, mail and news reading,
syntax-based support for editing programs in many languages,
web browsing, calendars, integration of source control systems, etc.
There are some libraries that makes a few of the Common Lisp functions
available in Emacs Lisp programs. But this is not at all the same as
programming in Common Lisp. Those libraries are just a few selected
functions, not the entire language, and there are many critical concepts
and data types that are different in Emacs and Common Lisp.
Although they are both Lisp, with the same (non)-syntax and some of the
same names for basic functions like CONS, there are many major differences
between Common Lisp and Emacs Lisp. For example, Common Lisp includes
object-oriented programming, but Emacs Lisp has nothing like that.
To write a Common Lisp program, you need a Common Lisp compiler (which
will usually come with a suite of integrated development tools).
You probably already are clear on this, since you asked about MCL.
For many people who program in Common Lisp, Emacs is the editor of
choice because it has good support for Lisp (eg. automatic parenthesis
balancing and indentation), and also libraries for communicating and
interfacing between Emacs and an (external) Common Lisp development
environment. The most popular such library is called "ISLISP".
You can do things like incrementally compile and test your program
from inside the editor (Emacs) -- it calls out invisibly to the
Common Lisp development environment that is running along side.
Also, most Lisp development environments include their own editor,
which is also Emacs. Not GNU Emacs, but a seperate and entirely
different implementation of Emacs that is tightly integrated with the
compiler, debugger, etc. The basic editing commands are the same as
in GNU Emacs, but Emacs Lisp is not included - extensions can be
written in Common Lisp; Emacs Lisp libraries are not supported.
Some people prefer to use the built-in Emacs, while others prefer
to use GNU Emacs with the ISLISP interfacing package.
By the way, there is another GNU product called GCL (GNU Common Lisp).
This is an early dialect of Common Lisp, which does not include many
areas and changes that are part of the subsequent ANSI Common Lisp
specification. GCL is not part of Emacs. You could use GCL as you
would use any other external Common Lisp. However, to my knowledge
it does not run on the Macintosh, which is what you're interested in.
With all the different Lisp things in the discussion, I just wanted to
make crystal clear the relationship between Emacs and Common Lisp.
> i'm looking at digitool's mcl, but as a very part time lisp enthusiast
> it is quite expensive to get into
MCL is a very nice programming environment and produces high-quality code.
I am not sure what other Lisp systems are available for the Mac,
but others will chime in here with that answer.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> Although they are both Lisp, with the same (non)-syntax and some of the
> same names for basic functions like CONS, there are many major differences
> between Common Lisp and Emacs Lisp. For example, Common Lisp includes
> object-oriented programming, but Emacs Lisp has nothing like that.
Well, it doesn't ship with an object system, but someone did indeed
build a CLOS-like object system (EIEIO) for it. It's single-dispatch,
but I think it's planning on moving to multiple-dispatch. Of course,
it's not very well integrated with the rest of Elisp (think CLtL1 + PCL),
but it's still very cool to have. Needless to say, it makes Elisp a
nicer place.
This nitpick aside, your post was right on :)
> Well, it doesn't ship with an object system, but someone did indeed
> build a CLOS-like object system (EIEIO) for it. It's single-dispatch,
> but I think it's planning on moving to multiple-dispatch. Of course,
> it's not very well integrated with the rest of Elisp (think CLtL1 + PCL),
> but it's still very cool to have. Needless to say, it makes Elisp a
> nicer place.
>
out of curiosity, could you provide a link, since eventhough i'm
headed towards mcl as my environment, i'd like to play around with
emacs and elisp
howie / monk
····@brainlink.com (; ; m o n k) writes:
> > Well, it doesn't ship with an object system, but someone did indeed
> > build a CLOS-like object system (EIEIO) for it. It's single-dispatch,
> > but I think it's planning on moving to multiple-dispatch. Of course,
> > it's not very well integrated with the rest of Elisp (think CLtL1 + PCL),
> > but it's still very cool to have. Needless to say, it makes Elisp a
> > nicer place.
> >
> out of curiosity, could you provide a link, since eventhough i'm
> headed towards mcl as my environment, i'd like to play around with
> emacs and elisp
Its homepage is the first link you get from typing "eieio" into google.
Christopher Stacy <······@spacy.Boston.MA.US> wrote in message news:<·············@spacy.Boston.MA.US>...
> >>>>> On 19 Sep 2001 23:17:15 -0700, ; ; m o n k (";") writes:
> > hi lisp list
> > i want to know if it is possible to compile lisp programs in emacs or not . . .
>
hi christopher - that is crystal clear
i'm inserting (at below) a post from <······@Rowanwood.com> who
responded to a similar question on the mac emacs sourceforge list, who
coincidentally confirms everything you and others have said
judging by her post even if i pay full price for mcl i'm getting a
heck of a deal, historically speaking, so goodbye xlisp, and i'll keep
powerlisp on the back burner . . .
for me an integrated place to start is better, and i now understand
that i may want to use emacs as my editor of choice, with optional
functionality
<insert>
This depends on what you want to do once you know lisp.
If you just want to get the flavor of the language then emacs-lisp
gives you some of that. But emacs-lisp is not lisp for two reasons:
- It is not a complete common lisp implementation. Many important
things are missing. Somewhere on the web there is an emacs library
you can load that gives you some of what's missing but it's still
only an approximation.
- The most important things to emacs-lisp (buffer manipulation) do
not exist in common lisp.
20 years ago a lot of people were forced to learn lisp on bad
implementations of lisp like the infamous Lisp 1.6 because they were
free and schools did not have much money. This turned many people off
from Lisp and is to a large extent the cause of lisps bad reputation
today. These people still complain about the stupid parentheses.
Meanwhile, in the Artificial Intelligence community, and some places
like MIT and Stanford, and in the industry people were happily paying
30,000 - 100,000 dollars to get a Lisp Machine. These machines make
parentheses a non-issue because they are very good at helping you get
them right.
Today you can have a Lisp that's even better than the Lisp Machine
Lisp for a moderate amount of money - certainly not more than what
you'd pay for Metrowerks C++ environment. In short, if you want to
make any money (ever) writing lisp code you must get Macintosh Common
Lisp now. Nothing less will do.
If you are a student you can get it for $160. See
http://www.digitool.com/purchase.html
- Monica
< and insert a 2nd e-mail>
Emacs originally came out of MIT - it was written by RMS (Richard M
Stallman of GNU fame). I believe he was still in his mid-teens then.
Emacs became very popular and as MIT and MIT-educated people started
inventing LISP machines they made Emacs a standard part of the
environment. In fact, Emacs is everywhere in every decent lisp
implementation. MCL comes with an emacs-like editor.
You need for Emacs to become your regular text editor. You will use
it for anything and everything. If you are using lisp you use Emacs
from within Lisp. If you are doing anything else to text you use
plain Emacs.
People use really incompetent editors like TeachText on Mac and
NotePad on Windows, and even vi on UNIX/Linux/Mac OS X. But Emacs is
available for all these platforms and is preinstalled on most of
them. People that use Emacs are 50-500% more effective than people
that use the incompetent editors and therefore get more work done
easier. Learning Emacs (read the manual over breakfast for two weeks)
pays more than almost anything you can do when you are getting into
computers. The only thing that pays more is a touch-typing class.
Just two examples why emacs is worth knowing: The command M-/
(meta-slash) runs the command "dabbrev-expand" which helps you fill
in a word you have started by typing the rest of the word for you -
it's like mind reading and it really works and may double your typing
speed in a programming project and cuts down on spelling errors. And
keyboard macros - C-X ( C-X ) C-X C-E will let you do
things repeatedly by using a tape recorder to record your keystrokes
and play them back.
One last hint: Get a keyboard where control key is where the caps
lock is. I recommend the Happy Hacking keyboard by PFU Limited. I
have two of these.
- Monica
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On 19 Sep 2001 23:17:15 -0700, ; ; m o n k (";") writes:
[...]
> For many people who program in Common Lisp, Emacs is the editor of
> choice because it has good support for Lisp (eg. automatic parenthesis
> balancing and indentation), and also libraries for communicating and
> interfacing between Emacs and an (external) Common Lisp development
> environment. The most popular such library is called "ISLISP".
^^^^^^
> You can do things like incrementally compile and test your program
> from inside the editor (Emacs) -- it calls out invisibly to the
> Common Lisp development environment that is running along side.
[...]
> Some people prefer to use the built-in Emacs, while others prefer
> to use GNU Emacs with the ISLISP interfacing package.
^^^^^^
I think these references should be ILISP, not ISLISP. J.