Howdy. Some of you may remember that I was embarking on the long road
to Emacs proficiency a while ago. I am starting to use it more and
more for more things. Also, as my server blew up, I am kind of forced
to re-do my web site as I've been thinking of doing for a while. I
would like to run some parts of it with mod_lisp. However, I have a
concern, and that is how to go about editing the site's code without
interrupting its operation.
What I'd like to have is a long-running Lisp process on my server
serving up mod_lisp requests. So it would be in
(modlisp:modlisp-server) for its lifetime. However, I'd like to be
able to edit the code with Emacs and replace it without having to
change to the attachtty terminal, Ctrl-C, compile, load, and call the
server function again.
If possible, I'd like to use Emacs with SLIME, and if possible I'd
like to do the editing remotely (maybe via gnuclient if I can get it
up and running again, as it seems most Linux distro packages for GNU
Emacs leave it out). But the key thing is to find a way for Emacs to
instruct the background Lisp process that it's time to recompile and
reload.
I'm sure this has been done before. Can anyone give me some pointers
on doing it right? Thanks!
Ari
In principle, it should be possible to have SLIME talk directly to
attachtty, but last time I tried it wasn't really reliable. Here is
what I ended up doing:
1. Start lisp with detachtty (you might need a patched version of
detachtty that can run without a tty).
2. Load swank-loader and do (create-server :dont-close t) to allow
slime to connect.
3. Use M-x slime-connect to connect from emacs.
4. attachtty can still be used if something goes horribly wrong.
I haven't thought of how to do this remotely; in particular I guess it
is a bad idea to open up the slime port?
Ole
·········@cern.ch writes:
> I haven't thought of how to do this remotely; in particular I guess it
> is a bad idea to open up the slime port?
I do this by listening on 127.0.0.1:4005 with slime, and
port-forwarding via SSH from my workstation. This has worked well for
light work so far, and I hope to put it under some real stress very
soon.
Zach
·········@cern.ch wrote in message news:<···············@cern.ch>...
> In principle, it should be possible to have SLIME talk directly to
> attachtty, but last time I tried it wasn't really reliable. Here is
> what I ended up doing:
>
> 1. Start lisp with detachtty (you might need a patched version of
> detachtty that can run without a tty).
>
> 2. Load swank-loader and do (create-server :dont-close t) to allow
> slime to connect.
>
> 3. Use M-x slime-connect to connect from emacs.
>
> 4. attachtty can still be used if something goes horribly wrong.
>
> I haven't thought of how to do this remotely; in particular I guess it
> is a bad idea to open up the slime port?
I can probably handle working 'locally' just fine. My main concern is
having the Lisp process run in the background, continuously serving
requests, while still allowing me to interact with it via SLIME so I
can hack the code without interrupting the service it provides.
That's one of the touted advantages of Common Lisp, and I'd really
like to tap into it. :)
·········@gmail.com (Ari Johnson) writes:
> ·········@cern.ch wrote in message news:<···············@cern.ch>...
>> In principle, it should be possible to have SLIME talk directly to
>> attachtty, but last time I tried it wasn't really reliable. Here is
>> what I ended up doing:
>>
>> 1. Start lisp with detachtty (you might need a patched version of
>> detachtty that can run without a tty).
>>
>> 2. Load swank-loader and do (create-server :dont-close t) to allow
>> slime to connect.
>>
>> 3. Use M-x slime-connect to connect from emacs.
>>
>> 4. attachtty can still be used if something goes horribly wrong.
>>
>> I haven't thought of how to do this remotely; in particular I guess it
>> is a bad idea to open up the slime port?
>
> I can probably handle working 'locally' just fine. My main concern is
> having the Lisp process run in the background, continuously serving
> requests, while still allowing me to interact with it via SLIME so I
> can hack the code without interrupting the service it provides.
> That's one of the touted advantages of Common Lisp, and I'd really
> like to tap into it. :)
So you need your Lisp server to be running in a separate thread (which
is often called a "process" in the Lisp world.) How exactly to do that
depends on the server and what Lisp implementation you are using.
For instance, [Portable]AllegroServe starts up its own threads so you
just start the server and away you go. (You can also set it up so any
thread that enters the debugger will pop a SLIME *sldb* window.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> ·········@gmail.com (Ari Johnson) writes:
>
> > ·········@cern.ch wrote in message news:<···············@cern.ch>...
> >> In principle, it should be possible to have SLIME talk directly to
> >> attachtty, but last time I tried it wasn't really reliable. Here is
> >> what I ended up doing:
> >>
> >> 1. Start lisp with detachtty (you might need a patched version of
> >> detachtty that can run without a tty).
> >>
> >> 2. Load swank-loader and do (create-server :dont-close t) to allow
> >> slime to connect.
> >>
> >> 3. Use M-x slime-connect to connect from emacs.
> >>
> >> 4. attachtty can still be used if something goes horribly wrong.
> >>
> >> I haven't thought of how to do this remotely; in particular I guess it
> >> is a bad idea to open up the slime port?
> >
> > I can probably handle working 'locally' just fine. My main concern is
> > having the Lisp process run in the background, continuously serving
> > requests, while still allowing me to interact with it via SLIME so I
> > can hack the code without interrupting the service it provides.
> > That's one of the touted advantages of Common Lisp, and I'd really
> > like to tap into it. :)
>
> So you need your Lisp server to be running in a separate thread (which
> is often called a "process" in the Lisp world.) How exactly to do that
> depends on the server and what Lisp implementation you are using.
>
> For instance, [Portable]AllegroServe starts up its own threads so you
> just start the server and away you go. (You can also set it up so any
> thread that enters the debugger will pop a SLIME *sldb* window.)
I don't know much about AllegroServe. Since I use Apache for other
things (including my AxKit/XSLT-powered web page, PHP projects I 'get'
to do as part of my fellowship work, simply serving up files, etc.), I
prefer the mod_lisp solution. I'm right now trying to figure out the
best way to attack actually handling files by the Lisp side of things,
but that's a side issue.
The main issue is providing myself with a productive development
environment. SLIME seems to be the way to go in that regard. So
that's covered, but what I'm missing is keeping the mod_lisp-serving
process running while I tweak things.
The Lisp implementations I'm considering are clisp, sbcl, and cmucl.
Clisp has the advantage of a very friendly REPL, but in theory SLIME
would preclude needing that, so I could do away with this
single-threaded implementation. CMU CL and SBCL seem almost
indistinguishable for most intents and purposes.
I don't know much about the interface between CL and SLIME and between
SLIME and Emacs, so I don't know how to make, say, CMUCL cause SLIME
to pop up a debug window when the debugger is entered. Is this
something I missed in skimming the SLIME manual, or is there some
other source I should look to?
Thanks again. :)
* ·········@gmail.com (Ari Johnson)
| The main issue is providing myself with a productive development
| environment. SLIME seems to be the way to go in that regard. So
| that's covered, but what I'm missing is keeping the mod_lisp-serving
| process running while I tweak things.
You dont have to do anything special. At least with cmucl
wich is what I use. Just configure apache to load mod_lisp,
fire cmucl and load:
http://www.fractalconcept.com/fcweb/download/modlisp-cmucl.lisp
You can then start messing with it at the REPL while serving
pages at the same time. That's the basic concept.
Now you can load slime with (load
"/slime/here/swank-loader.lisp") and then
(swank:create-server :port 4005 :dont-close t) and later
connect to the running image from emacs with M-x
slime-connect.
For bonus points try to run lisp under detachtty to have a
long running process and you are done.
You can find a modified version of mod-lisp.lisp plus
some ancillary code at my site.
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
According to Ari Johnson <·········@gmail.com>:
> If possible, I'd like to use Emacs with SLIME, and if possible I'd
> like to do the editing remotely (maybe via gnuclient if I can get it
> up and running again, as it seems most Linux distro packages for GNU
> Emacs leave it out). But the key thing is to find a way for Emacs to
> instruct the background Lisp process that it's time to recompile and
> reload.
This might get you on the way:
http://sandbox.rulemaker.net/ngps/91
With Lisp, typically, you edit a piece of code at a time and test your
program. You don't usually recompile/reload the entire bunch of code. While
connected to the remote Lisp, C-M-x does your key thing.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
"Ng Pheng Siong" <····@netmemetic.com> wrote in message
·················@reader01.singnet.com.sg...
> According to Ari Johnson <·········@gmail.com>:
> > If possible, I'd like to use Emacs with SLIME, and if possible I'd
> > like to do the editing remotely (maybe via gnuclient if I can get it
> > up and running again, as it seems most Linux distro packages for GNU
> > Emacs leave it out). But the key thing is to find a way for Emacs to
> > instruct the background Lisp process that it's time to recompile and
> > reload.
>
> This might get you on the way:
>
> http://sandbox.rulemaker.net/ngps/91
>
> With Lisp, typically, you edit a piece of code at a time and test your
> program. You don't usually recompile/reload the entire bunch of code.
While
> connected to the remote Lisp, C-M-x does your key thing.
What's the advantage of running it in a jail? Why not simply run it locally?
You wouldn't run it in produciton in a jail would you?
Regards,
Will Hartung
(·····@msoft.com)
According to Will Hartung <·····@msoft.com>:
> What's the advantage of running it in a jail?
The jail is dedicated to running this one thing. It can be stripped down to
the barest: just enough stuff in /etc and /usr/lib to get the one thing
running. If it gets rooted there is nothing else there.
The host's firewall rules control access in/out the jail, so, e.g., Swank's
port is not accessible from outside.
(Of course if the host gets rooted that's game over.)
A sysadmin on the host can watch an intruder's action in a jail, kinda like
thru a one-way glass window. People run honeypots in jails.
> Why not simply run it locally?
During development on my desktop, sure. But even then, running stuff in
jails makes it easier to mix and match packages, e.g., for playing with
various MTAs or Apache modules.
> You wouldn't run it in produciton in a jail would you?
Running in production is exactly why it is in jail. I have other jails
running Zope, Smalltalk servers, etc.
Cheers.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog