Hello, world!
We've been working on a program called SLIME, "the Superior Lisp
Interaction Mode for Emacs." This is an ILISP-like Emacs mode written
from scratch and with an eye towards imitating the native Emacs Lisp
programming environment. We've been working on it since late last year
and these days it's still under development but fairly widely used.
You can read about SLIME on our (new) web page at -
http://www.common-lisp.net/project/slime/
This probably isn't news to most people, but I thought I'd post this
more formal introduction all the same. It has been suggested that we
should work more on our public relations. :-)
In particular, people have found it controversial that we only
distribute SLIME sources through CVS. To some people this makes SLIME
look less mature than it is -- "What, they're not even ready for an
'0.1' release? It must be total crap!"
The reason we're CVS-only is that we find that it makes development
easier and more fun when everyone can quickly update to the latest
code: bug reports are relevant and fixes are delivered quickly. It
does require users to be fairly active participants, but it isn't
directly related to the maturity of the code.
In version number terms we're actually up to version 0.13. The thing
is that we "release" by setting a tag in CVS ('FAIRLY-STABLE') instead
of making tarballs for separate distribution, for the reasons above.
So: SLIME does work. You might well hit a bug, but if you report it to
the mailing list it will probably be fixed quickly. If you would
download a slime-0.13.tar.gz and try it, then the code in CVS (either
HEAD or the FAIRLY-STABLE tag) is ready for you to try. If you'd
sooner wait for a finished 1.0 version to "install and forget" then in
that case we're not there yet.
Any questions? :-)
Naturally any of the c.l.l readers who've been involved with major
Lisp development environments in the past would be especially welcome
to join in the SLIME hacking. We hope that SLIME will become a big
part of the "hacking Lisp in Emacs" world, so we want to make it as
good as possible. Undoubtedly many of the issues we're looking at have
been dealt with tastefully before, and we'd like to hear about it.
I'd also like to take this opportunity to say g'day to the Lisp
implementors out there. We have done some fairly deep
implementation-specific hacking to implement features like our
debugger, Meta-Point, and compiler message trapping, and much of it
involves calling internal functions. It would be great if Lisp
implementors could take a look at what we've done, and either point us
to better alternatives or export the functionality we need.
In summary, we're out in the open now, so if you have any questions
about SLIME then just ask. :-)
Happy hacking!
-Luke
Greetings, and thanks for your work on SLIME!
What is involved in getting a gcl backend in? Is anyone available to
help with this, as I'm a bit tied up at the moment.
Take care,
Luke Gorrie <····@bluetail.com> writes:
> Hello, world!
>
> We've been working on a program called SLIME, "the Superior Lisp
> Interaction Mode for Emacs." This is an ILISP-like Emacs mode written
> from scratch and with an eye towards imitating the native Emacs Lisp
> programming environment. We've been working on it since late last year
> and these days it's still under development but fairly widely used.
>
> You can read about SLIME on our (new) web page at -
> http://www.common-lisp.net/project/slime/
>
> This probably isn't news to most people, but I thought I'd post this
> more formal introduction all the same. It has been suggested that we
> should work more on our public relations. :-)
>
> In particular, people have found it controversial that we only
> distribute SLIME sources through CVS. To some people this makes SLIME
> look less mature than it is -- "What, they're not even ready for an
> '0.1' release? It must be total crap!"
>
> The reason we're CVS-only is that we find that it makes development
> easier and more fun when everyone can quickly update to the latest
> code: bug reports are relevant and fixes are delivered quickly. It
> does require users to be fairly active participants, but it isn't
> directly related to the maturity of the code.
>
> In version number terms we're actually up to version 0.13. The thing
> is that we "release" by setting a tag in CVS ('FAIRLY-STABLE') instead
> of making tarballs for separate distribution, for the reasons above.
>
> So: SLIME does work. You might well hit a bug, but if you report it to
> the mailing list it will probably be fixed quickly. If you would
> download a slime-0.13.tar.gz and try it, then the code in CVS (either
> HEAD or the FAIRLY-STABLE tag) is ready for you to try. If you'd
> sooner wait for a finished 1.0 version to "install and forget" then in
> that case we're not there yet.
>
> Any questions? :-)
>
> Naturally any of the c.l.l readers who've been involved with major
> Lisp development environments in the past would be especially welcome
> to join in the SLIME hacking. We hope that SLIME will become a big
> part of the "hacking Lisp in Emacs" world, so we want to make it as
> good as possible. Undoubtedly many of the issues we're looking at have
> been dealt with tastefully before, and we'd like to hear about it.
>
> I'd also like to take this opportunity to say g'day to the Lisp
> implementors out there. We have done some fairly deep
> implementation-specific hacking to implement features like our
> debugger, Meta-Point, and compiler message trapping, and much of it
> involves calling internal functions. It would be great if Lisp
> implementors could take a look at what we've done, and either point us
> to better alternatives or export the functionality we need.
>
> In summary, we're out in the open now, so if you have any questions
> about SLIME then just ask. :-)
>
> Happy hacking!
> -Luke
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> writes:
> What is involved in getting a gcl backend in?
A minimal backend requires:
1) a socket interface to open server sockets and a way to wrap client
sockets into a stream. I once tried to write a GCL backend for
SLIME and already failed here. IIRC, GCL's socket interface uses
some sort of callbacks and I was unable to adapt it to our needs.
I think it would be the best if GCL adopts Franz' socket interface.
OpenMCL has done that and this was a great help. Their interface
is quite nice and doesn't need any callbacks.
2) an interface to the debugger. This basically means a way to
produce the list of backtrace frames and a function to print frames
nicely. Functions to access the variables in a frame would be nice
but are not absolutely necessary.
3) gray streams.
This should be enough for the most basic functionality, like
evaluating, simple debugging and apropos. For more comfort like
M-. and compiler note trapping we need more interfaces, but this can
be added later.
> Is anyone available to
> help with this, as I'm a bit tied up at the moment.
I'd be happy to answer questions, but I don't like to write C code for
GCL (which is probably needed).
Helmut.
Greetings, and thanks!
Helmut Eller <········@stud3.tuwien.ac.at> writes:
> Camm Maguire <····@enhanced.com> writes:
>
> > What is involved in getting a gcl backend in?
>
> A minimal backend requires:
>
> 1) a socket interface to open server sockets and a way to wrap client
> sockets into a stream. I once tried to write a GCL backend for
> SLIME and already failed here. IIRC, GCL's socket interface uses
> some sort of callbacks and I was unable to adapt it to our needs.
> I think it would be the best if GCL adopts Franz' socket interface.
> OpenMCL has done that and this was a great help. Their interface
> is quite nice and doesn't need any callbacks.
>
Is this interface simply documented anywhere? Don't have access to
Franz lisp. We've been discussing our socket interface recently, and
perhaps now would be the time to solicit opinions on what an optimal
interface would look like. I take it the Franz interface also suits
the web/mod_lisp people well?
> 2) an interface to the debugger. This basically means a way to
> produce the list of backtrace frames and a function to print frames
> nicely. Functions to access the variables in a frame would be nice
> but are not absolutely necessary.
>
Not a problem here.
> 3) gray streams.
>
?? What are these?
> This should be enough for the most basic functionality, like
> evaluating, simple debugging and apropos. For more comfort like
> M-. and compiler note trapping we need more interfaces, but this can
> be added later.
>
> > Is anyone available to
> > help with this, as I'm a bit tied up at the moment.
>
> I'd be happy to answer questions, but I don't like to write C code for
> GCL (which is probably needed).
>
OK, then perhaps we have the basis for a dialog, as I'd feel
comfortable with the C/GCL coding side.
Take care,
> Helmut.
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
On 03 May 2004 10:12:42 -0400, Camm Maguire <····@enhanced.com> wrote:
> Helmut Eller <········@stud3.tuwien.ac.at> writes:
>
>> I think it would be the best if GCL adopts Franz' socket
>> interface. OpenMCL has done that and this was a great help.
>> Their interface is quite nice and doesn't need any callbacks.
>
> Is this interface simply documented anywhere?
All AllegroCL docs are available from Franz' website. Start with:
<http://www.franz.com/support/documentation/6.2/doc/socket.htm>
>> 3) gray streams.
>
> ?? What are these?
You can also start with the AllegroCL docs:
<http://www.franz.com/support/documentation/6.2/doc/gray-streams.htm>
Edi.
Camm Maguire <····@enhanced.com> writes:
> Is this interface simply documented anywhere? Don't have access to
> Franz lisp. We've been discussing our socket interface recently, and
> perhaps now would be the time to solicit opinions on what an optimal
> interface would look like.
Franz' documentation is here:
<http://www.franz.com/support/documentation/6.2/doc/socket.htm>
and OpenMCL's here:
<http://openmcl.clozure.com/Doc/sockets.html>
> I take it the Franz interface also suits
> the web/mod_lisp people well?
I think so. At least I see no reason why this interface shouldn't
work. The mapping to the C counter parts is IMO relatively obvious,
at least more obvious as with callback oriented interfaces.
>> 3) gray streams.
>>
>
> ?? What are these?
A mechanism to define custom streams. In SLIME we bind
*standard-output* to such a custom stream to redirect the output to
Emacs. Any mechanism to define a custom stream (eg, Franz'
simple-streams) would be good enough. Gray streams save us some work,
because many other backends use that.
Here's Lispworks documentation:
<http://www.lispworks.com/reference/lw43/LWRM/html/lwref-461.htm>
Helmut.
Luke Gorrie <····@bluetail.com> wrote:
+---------------
| In particular, people have found it controversial that we only
| distribute SLIME sources through CVS. To some people this makes SLIME
| look less mature than it is ...
+---------------
No, just inaccessible. Some of us are not CVS wizards and some of us
don't even *have* a usable CVS client handy. A tarball -- in *whatever*
state, but preferably clearly labelled -- would be a great help.
+---------------
| If you would download a slime-0.13.tar.gz and try it, then the code
| in CVS (either HEAD or the FAIRLY-STABLE tag) is ready for you to try.
...
| Any questions? :-)
+---------------
A "slime-0.13-FAIRLY-STABLE.tar.gz" really would be appreciated.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>>>> On Fri, 30 Apr 2004 23:40:54 -0500, Rob Warnock ("Rob") writes:
Rob> Luke Gorrie <····@bluetail.com> wrote:
Rob> +---------------
Rob> | In particular, people have found it controversial that we only
Rob> | distribute SLIME sources through CVS. To some people this makes SLIME
Rob> | look less mature than it is ...
Rob> +---------------
Rob> No, just inaccessible. Some of us are not CVS wizards and some of us
Rob> don't even *have* a usable CVS client handy. A tarball -- in *whatever*
Rob> state, but preferably clearly labelled -- would be a great help.
I have to second this remark. There are lots of people who are not
familiar with CVS, and who may not even be very familiar with Unix.
Getting them to use what they may feel is a strange and weird new
editor is already a lot to ask (although obviously it will get them
the most bang). Telling them to bootstrap this gigantic learning
curve by learning about CVS and source trees and cryptic logins,
and how it relates to what they see on CVS web pages may be too much
But they understand the ubiquitous idea of a packed distribution file.
They are used to one-click download-and-ask-me-to-unpack types of
stuff, so won't get confused when seeing a tarball on the web.
And even if they are new to Unix, they can easily figure out tar,
since there are no source tree management concepts involved.
It would be nice if bootstrapping a Lisp development environment
was as painless as possible for those kinds of people, and SLIME seems
to be emerging as the Emacs-based IDE of choice. I applaud all the
various efforts that people are contributing towards both goals.
(Of course, the last time I said something like this, people
responded by flaming at me that I was anti-Lisp or something,
even though I've been promoting it and programming in it almost
exclusively for the last 24 years...)
······@news.dtpq.com (Christopher C. Stacy) writes:
> It would be nice if bootstrapping a Lisp development environment
> was as painless as possible for those kinds of people, and SLIME seems
> to be emerging as the Emacs-based IDE of choice. I applaud all the
> various efforts that people are contributing towards both goals.
If only the promice of that niceness were strong enough to get people to
actually implement such a solution on the systems they're familiar with
instead of requiring others to purchase that system (possibly supporting
hardware as well), purchase all lisp implementations for that system,
learn how to use them, learn how to develop on them, research the
conventions expected by the users of those systems, and finally porting
the tools they already wrote for the system they use daily.
Specifically, it's a pity that no one who develops for redhat or
windows cares enough about such issues to help port existing solutions
to those platforms.
> (Of course, the last time I said something like this, people
> responded by flaming at me that I was anti-Lisp or something,
> even though I've been promoting it and programming in it almost
> exclusively for the last 24 years...)
I'm not sure how this sentiment is accusing you of being anti-Lisp, but
maybe you weren't referring to my reaction.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 01 May 2004 19:05:08 +0000, Rahul Jain wrote:
>
> Specifically, it's a pity that no one who develops for redhat or
> windows cares enough about such issues to help port existing solutions
> to those platforms.
>
I use RedHat all the time - at work and at home, probably for more than 12
hours a day, every day. I have done for the past four or five years, and
in that time I haven't used any other platform at all (yes, not even
Windows, and yes, not even for corporate email ;-). I'm not aware of any
issues with any of the software being discussed here - Emacs, SLIME and
cmucl all just work for me. If there are issues on RedHat though, please
do speak up and I'll see if there's anything I can do to help (but you'll
have to do it on this newsgroup since my home email is somewhat flaky at
the moment).
Best wishes,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <····@abstractnonsense.com> writes:
> I use RedHat all the time - at work and at home, probably for more than 12
> hours a day, every day. I have done for the past four or five years, and
> in that time I haven't used any other platform at all (yes, not even
> Windows, and yes, not even for corporate email ;-). I'm not aware of any
> issues with any of the software being discussed here - Emacs, SLIME and
> cmucl all just work for me. If there are issues on RedHat though, please
> do speak up and I'll see if there's anything I can do to help (but you'll
> have to do it on this newsgroup since my home email is somewhat flaky at
> the moment).
Installing this software is not easy using the platform's native package
management system. If we want to have non-lisp-programmers using lisp
software, this problem needs to be addressed. Some of us have developed
a system to allow for packaging of lisp software in Debian, but none of
us had the expertise and/or the motivation to port this to RedHat or MS
Windows.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 01 May 2004 22:08:53 +0000, Rahul Jain wrote:
>
> Installing this software is not easy using the platform's native package
> management system. If we want to have non-lisp-programmers using lisp
> software, this problem needs to be addressed. Some of us have developed
> a system to allow for packaging of lisp software in Debian, but none of
> us had the expertise and/or the motivation to port this to RedHat or MS
> Windows.
There are easily obtainable RPMs for Emacs and cmucl, so I assume you're
talking about SLIME here. I had considered offering to try to build RPMs
for SLIME a couple of weeks ago, when I first installed it. After reading
the SLIME website though, it seemed to me that the developers were saying
they would prefer people to get it from cvs until it hits 1.0. That's not
such an unusual thing to ask in Free/Open Source projects so I wasn't
surprised.
If you're talking about more than just SLIME here, and want a way to
package arbitrary Lisp software into an RPM, I think that's beyond what I
can do at the moment. I'm still too much of a Lisp newbie to help out
there.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <····@abstractnonsense.com> writes:
> If you're talking about more than just SLIME here, and want a way to
> package arbitrary Lisp software into an RPM, I think that's beyond what I
> can do at the moment. I'm still too much of a Lisp newbie to help out
> there.
Indeed, that's the goal, and what I think has been achieved. True binary
packages are the next step, and aren't very easy, for a variety of
reasons.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
William Bland <····@abstractnonsense.com> writes:
> If you're talking about more than just SLIME here, and want a way to
> package arbitrary Lisp software into an RPM, I think that's beyond what I
> can do at the moment. I'm still too much of a Lisp newbie to help out
> there.
It would be useful to have the common lisp controller and a bunch of
libraries put in RPM format, in an apt repository sometime. That's
currently the main concern I have to moving to Fedora from Debian
(getting sick of the internal politics).
If anyone else would be interested, I could help get it kicked off.
I bet we could set up a yum repository on common-lisp.net....
Of course, I'd have to actually start switching over. 8^)
--
Alan Shutko <···@acm.org> - I am the rocks.
Never cut what can be untied.
Alan Shutko <···@acm.org> writes:
> It would be useful to have the common lisp controller and a bunch of
> libraries put in RPM format, in an apt repository sometime. That's
> currently the main concern I have to moving to Fedora from Debian
> (getting sick of the internal politics).
It's easy enough to simply ignore the politics. If you wanted to avoid
excessive politics, you'd probably want to avoid using glibc or the
linux or *BSD kernels, as well. If you'd like to talk about it, feel
free to email me.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On 2004-05-01 06:40:54, Rob Warnock wrote:
> No, just inaccessible. Some of us are not CVS wizards and some of us
> don't even *have* a usable CVS client handy. A tarball -- in *whatever*
> state, but preferably clearly labelled -- would be a great help.
I can't believe that it's easy to install, configure, and maintain
Emacs, but hard to install cvs and follow step by step instructions
from a web page.
On Sat, 1 May 2004 13:39:32 +0200, Stefan Scholl <······@no-spoon.de> wrote:
> I can't believe that it's easy to install, configure, and maintain
> Emacs, but hard to install cvs and follow step by step instructions
> from a web page.
For a Windows user this might well be the case. You can get an Emacs
binary which works out of the box but to get CVS working you probably
have to install something like Cygwin.
Edi.
Edi Weitz <···@agharta.de> wrote in message news:<··············@bird.agharta.de>...
> On Sat, 1 May 2004 13:39:32 +0200, Stefan Scholl <······@no-spoon.de> wrote:
>
> > I can't believe that it's easy to install, configure, and maintain
> > Emacs, but hard to install cvs and follow step by step instructions
> > from a web page.
>
> For a Windows user this might well be the case. You can get an Emacs
> binary which works out of the box but to get CVS working you probably
> have to install something like Cygwin.
Alternative #1: use a native win32 CVS client. There are a number of
options at:
http://www.cvshome.org/cyclic/cvs/windows.html
Alternative #2: use the Java-based CVSGrab if you are behind a
firewall. (I haven't used it myself, but the web site says it works
from behind a firewall). It is at:
http://cvsgrab.sourceforge.net/
Alternative #3: grab the daily SLIME tarball from:
http://www.common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=slime
Cheers,
Bill
Edi Weitz wrote:
> On Sat, 1 May 2004 13:39:32 +0200, Stefan Scholl <······@no-spoon.de> wrote:
>
>
>>I can't believe that it's easy to install, configure, and maintain
>>Emacs, but hard to install cvs and follow step by step instructions
>>from a web page.
>
>
> For a Windows user this might well be the case. You can get an Emacs
> binary which works out of the box but to get CVS working you probably
> have to install something like Cygwin.
There are good cvs clients that work like Windows applications, but
configuring them correctly involves setting up a bunch of configuration
values that the average Windows user (or even Windows programmer) would
have no reason to understand under normal circumstances.
In other words, you're right: it can be pretty easy to get Emacs
working, and kind of hard to use cvs, even with a Windows-style cvs client.
On Sat, 01 May 2004 15:06:44 GMT, mikel <·····@evins.net> wrote:
> There are good cvs clients that work like Windows applications, but
> configuring them correctly involves setting up a bunch of
> configuration values that the average Windows user (or even Windows
> programmer) would have no reason to understand under normal
> circumstances.
>
> In other words, you're right: it can be pretty easy to get Emacs
> working, and kind of hard to use cvs, even with a Windows-style cvs
> client.
Yes. But as already mentioned by other people you don't have to do use
CVS, even with SLIME. There is (and always has been) a tarball
available which is updated daily:
<http://www.common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=slime>
There are enough Windows apps out there (some of them available at no
cost, like FilZip) that can cope with gzipped tar archives. If you
don't want to go the CVS route you can grab a tarball and replace it
with a more current one when appropriate - no big deal.
Edi.
* Edi Weitz <···@agharta.de>
| On Sat, 1 May 2004 13:39:32 +0200, Stefan Scholl <······@no-spoon.de> wrote:
|
| > I can't believe that it's easy to install, configure, and maintain
| > Emacs, but hard to install cvs and follow step by step instructions
| > from a web page.
|
| For a Windows user this might well be the case. You can get an Emacs
| binary which works out of the box but to get CVS working you probably
| have to install something like Cygwin.
Point users to
http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=slime
and click "Download tarball"
Winzip handles .tar.gz just fine.
HTH :)
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
Eduardo Mu�oz <······@terra.es> wrote:
+---------------
| Point users to
| http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=slime
| and click "Download tarball"
+---------------
Thanks!!
+---------------
| HTH :)
+---------------
It did, completely -- thanks!!
Note: Had Luke posted that URL in the first place, I never
would have posted my reply at all. All I really wanted was
to take a quick look at the Swank code...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Note: Had Luke posted that URL in the first place, I never
> would have posted my reply at all. All I really wanted was
> to take a quick look at the Swank code...
Actually I didn't know we had that URL :-). It's one of our free
goodies from common-lisp.net.
Cheers,
Luke
>>>>> On Sat, 1 May 2004 13:39:32 +0200, Stefan Scholl ("Stefan") writes:
Stefan> On 2004-05-01 06:40:54, Rob Warnock wrote:
>> No, just inaccessible. Some of us are not CVS wizards and some of us
>> don't even *have* a usable CVS client handy. A tarball -- in *whatever*
>> state, but preferably clearly labelled -- would be a great help.
Stefan> I can't believe that it's easy to install, configure, and
Stefan> maintain Emacs, but hard to install cvs and follow step by
Stefan> step instructions from a web page.
To do all that for Emacs on Windows requires one click to download
the self-installer, and then another click to confirm launching it.
Come back in 4 minutes and start using Emacs (including ilisp, etc.)
Also, you don't need to understand a whole new way of dealing
with your files -- an edior is not a new concept, unlike a
version control system.
Last Friday night, I wrote:
+---------------
| Luke Gorrie <····@bluetail.com> wrote:
| +---------------
| | In particular, people have found it controversial that we only
| | distribute SLIME sources through CVS. To some people this makes SLIME
| | look less mature than it is ...
| +---------------
|
| No, just inaccessible. Some of us are not CVS wizards and some of us
| don't even *have* a usable CVS client handy. A tarball -- in *whatever*
| state, but preferably clearly labelled -- would be a great help.
+---------------
Thanks to the several people who pointed me at this method
<URL:http://common-lisp.net/cgi-bin/viewcvs.cgi/?cvsroot=slime>
of snarfing a tarball, it's no longer "inaccessible"...
Thanks again, guys!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Fri, 30 Apr 2004 23:49:54 +0200, Luke Gorrie wrote:
> In summary, we're out in the open now, so if you have any questions
> about SLIME then just ask. :-)
>
> Happy hacking!
> -Luke
I've finally got around to starting to learn Common Lisp, having been a
bit scared of it for a couple of years. SLIME is *the* reason I
eventually dived in the way I did.
I have the latest cvs versions of SLIME and Emacs on my laptop, along with
cmucl 18e and a local copy of the hyperspec. I've been programming now
since I was 9 years old (nearly 20 years!). Maybe I've just had a really
sheltered life, but I have *never* seen the development experience as good
as I have it now.
Thank you for SLIME.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
On 30 Apr 2004, Luke Gorrie <- ····@bluetail.com wrote:
[...]
> Any questions? :-)
Yes. Does it make sense to try Slime with XEmacs? The last thing I
read was it didn't work (some weeks ago).
KP
--
"Programs must be written for people to read, and only incidentally
for machines to execute."
-- Abelson & Sussman, SICP (preface to the first edition)
······@12move.de (Karl Pfl�sterer) writes:
> Yes. Does it make sense to try Slime with XEmacs? The last thing I
> read was it didn't work (some weeks ago).
Yes, SLIME is supposed to work (modulo bugs) with XEmacs, GNU Emacs 20
and 21.
Helmut
--=-=-=
Content-Type: text/plain
On 8731 day of my life Luke Gorrie wrote:
> It has been suggested that we should work more on our public
> relations. :-)
Hm... I will add acknolegies section to READMEs of my projects with
link to Slime. All my recently released projects (Lizp, Typel, LPVM)
was develped with Slime :)
2Everyone: Slime is cool! Use Slime!
--
Ivan Boldyrev
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUAQJRUGg4ALcwzZFpVAQJwOQf/WNNLB5oEwFOLxzWt+HSEKJuRZslVbZy0
XhmwCiiSKWZco6cL4YO4bMD0UcTQClYVslmEIV8H7P4WO7pvKesqWae7nj/ffi9z
AlOut5s0ubW+/lAF5vV1957PLA/gChcG77EQG2pmxDxSuKiAS0NotzpoHF4iWsDZ
EaXb6BekY9VKdWVb3dYxOx6nbqf1MHdnfU02onOGx5nTIXhchOyd3YzkRyHkfaBk
eIFJL3fdvwz7reU9k9jqNl527P4aM5CNqTMeDf0ku0rrBAWUZz+HomTpLiTClhvO
sEk+bivY+WRj4Ex38ITu79sXf8xAB+TL6d90qz9Q2rHNmWzn68ISUw==
=U8k9
-----END PGP SIGNATURE-----
--=-=-=--
Luke Gorrie <····@bluetail.com> wrote in message news:<··············@dodo.bluetail.com>...
>
> In particular, people have found it controversial that we only
> distribute SLIME sources through CVS. To some people this makes SLIME
> look less mature than it is -- "What, they're not even ready for an
> '0.1' release? It must be total crap!"
>
I'd like to second (well, nth, I suppose) other people: just make
tarballs. It is *easy* to do this even if you don't automate it, and
it's easy to automate - either have a makefile which does a cvs export
of the most recent released tag, tars it up and puts it somewhere, or
have a taginfo script which does this. Lots of people can't use cvs,
either because they don't have remote CVS access because of firewall
restrictions (I'm fairly sure I don't from where I'm working), or
because they don't know how to.
--tim