Hacked up this afternoon, not quite ready for commital but would appreciate feedback: slime on a local (a.k.a unix domain) socket using half of the attachtty/detachtty utility as a socket shim.
Why? Two reasons:
(1) access control can be done by setting appropriate filesystem permissions on the directory containing the socket (or in Linux but not portably, on the socket itself) - so, a safe way to run slime on shared hosts that doesn't involve cooking up an authentication protocol
(2) attachtty can connect across a network using ssh, so you can control a remote lisp this way as well.
How to use it:
Server-site, create-swank-server has a new keyword argument :af, which defaults to :inet, and can also be :local
* (swank:create-inet-server "/home/dan/.swank/socket" :af :local)
Client-side, slime-connect is renamed to slime-connect/inet, and there's a new function (slime-connect/local pathname)
M-x slime-connect /home/dan/.swank/socket RET
or from another machine
M-x slime-connect me@lisp.example.com:/home/dan/.swank/socket RET
Opinions? You can get attachtty as part of detachtty, in Debian, FreeBSD ports, or from http://www.cliki.net/detachtty
-dan
Daniel Barlow dan@telent.net writes:
Opinions? You can get attachtty as part of detachtty, in Debian, FreeBSD ports, or from http://www.cliki.net/detachtty
Are you aware that CVS Emacs has support for Unix sockets? It does server socket too.
I don't know why people are so keen to use a setup where the Lisp and Emacs are on different machines, but whenever I tried to do something like that (e.g, with remote-compile) it didn't work very well and I always run Emacs on the same machine. Is this a feature we want to support or is this a would-be-nice-in-an-ideal-world thing?
Helmut.
Helmut Eller writes:
Are you aware that CVS Emacs has support for Unix sockets? It does server socket too.
Please, no *Emacs* CVS :)
Paolo
Paolo Amoroso amoroso@mclink.it writes:
Helmut Eller writes:
Are you aware that CVS Emacs has support for Unix sockets? It does server socket too.
Please, no *Emacs* CVS :)
Understandable, but FWIW, it's actually very stable. It's the wave of the future and, more importantly, the only wave on OS X.
/s
"Sean O'Rourke" sorourke@cs.ucsd.edu writes:
Paolo Amoroso amoroso@mclink.it writes:
[...]
Please, no *Emacs* CVS :)
Understandable, but FWIW, it's actually very stable. It's the wave of
No doubt about it. But try a `cvs checkout' via modem...
Paolo
Paolo Amoroso amoroso@mclink.it writes:
"Sean O'Rourke" sorourke@cs.ucsd.edu writes:
Paolo Amoroso amoroso@mclink.it writes:
[...]
Please, no *Emacs* CVS :)
Understandable, but FWIW, it's actually very stable. It's the wave of
No doubt about it. But try a `cvs checkout' via modem...
People still use those?
/s
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
I don't know why people are so keen to use a setup where the Lisp and Emacs are on different machines, but whenever I tried to do something like that (e.g, with remote-compile) it didn't work very well and I always run Emacs on the same machine.
With Distel I do this for debugging, though not development. We build "network appliances" that traditionally haven't been able to have Emacs on them (small flashdisks), so I make a very SLIME-like connection to them over a socket when I need to poke around (in Erlang).
I think the tricky part is filesystem operations. Currently in CVS we assume a shared filesystem, but if you stay away from FS-related operations you can probably still do some useful things without one. Brian's patch adds support for having a shared filesystem but with different mount points (apparently common with SMB). On Cliki, Rahul Jain suggested we integrate with Tramp (Emacs remote editing package). Maybe there is an opporunity to do something Fancy with the `host' field of logical pathnames even?
My own setup doesn't need this stuff, so I'm happy to wait and see what the other guys come up with :-)
-Luke
Luke Gorrie luke@bluetail.com writes:
I think the tricky part is filesystem operations. Currently in CVS we assume a shared filesystem, but if you stay away from FS-related operations you can probably still do some useful things without one. Brian's patch adds support for having a shared filesystem but with different mount points (apparently common with SMB). On Cliki,
I haven't tried this, but if it can be set to rewrite, say, /home/telent/foo.lisp to /telent@ww.telent.net:/home/telent/foo.lisp, it looks like it will already work with tramp. At least, find-file-noselect does. Do we load files anywhere without the aid of find-file{,-noselect}?
package). Maybe there is an opporunity to do something Fancy with the `host' field of logical pathnames even?
Set Phasers To Maximum Pain
LPNs work nicely if you've already designed the entire build system around them, but they're in no way good at representing arbitrary filenames.
-dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 1, 2003, at 3:25 AM, Helmut Eller wrote:
I don't know why people are so keen to use a setup where the Lisp and Emacs are on different machines, but whenever I tried to do something like that (e.g, with remote-compile) it didn't work very well and I always run Emacs on the same machine. Is this a feature we want to support or is this a would-be-nice-in-an-ideal-world thing?
I don't see why not - if we make the assumption of a shared directory, possibly with different mountpoints, then what's the difference from Emacs' perspective between a local lisp and an ssh-tunneled lisp? This way I can test my code on CMUCL (I'm on OS X) from my pretty local Emacs.
- -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
I don't see why not - if we make the assumption of a shared directory, possibly with different mountpoints, then what's the difference from Emacs' perspective between a local lisp and an ssh-tunneled lisp? This way I can test my code on CMUCL (I'm on OS X) from my pretty local Emacs.
But does the patch work for e.g. M-. on previously compiled code? There are quite a few places we use filenames (currently and potentially) and it would be a pity to have to guard them all with filename translations unless we really have to.
Can you tell me again why it doesn't work to use the same mount-points? I think that's the normal practice, otherwise there are just so many things that can break (e.g. symlinks).
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
I don't see why not - if we make the assumption of a shared directory, possibly with different mountpoints, then what's the difference from Emacs' perspective between a local lisp and an ssh-tunneled lisp? This way I can test my code on CMUCL (I'm on OS X) from my pretty local Emacs.
Ah, that's the reason.
I just think that this remote setup is difficult to make work properly and will require complexity for little or no benefit. The main problems I see:
- filenames for files to compile and for M-. and xref etc. - signals. Currently we send SIGINT to interrupt the Lisp. - security.
Of course, if this is important to you and you have patches for this, let's include them.
Helmut.
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Helmut> I don't know why people are so keen to use a setup where the Lisp and Helmut> Emacs are on different machines, but whenever I tried to do something Helmut> like that (e.g, with remote-compile) it didn't work very well and I Helmut> always run Emacs on the same machine. Is this a feature we want to Helmut> support or is this a would-be-nice-in-an-ideal-world thing?
Not a very good argument, but this is something that Franz' ELI does out of the box.
More specific reasons could be that the machine on your desktop doesn't have that much RAM, but you have server that has, so running your development lisp process remotely makes your local machine suffer less (I may be special, but with 32+ Mb emacs process and the CL based eclipse window manager there is some fighting over RAM ressources).
It could also be that you were doing some cross-platform developement. Ie. yuor desktop is an i386 but your target is sparc or PowerPc.
Or Your server could have something specific software or information installed or accessible that is important to your lisp application.
Paths is a problem, but the cases cited above will still be interesting even if you had one siteglobal (automounted) shared (home)directory where you kept your lisp files, in which case the path problem kind of goes away.
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Christian Lynbech christian.lynbech@ericsson.com writes:
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Helmut> I don't know why people are so keen to use a setup where the Lisp and Helmut> Emacs are on different machines, but whenever I tried to do something Helmut> like that (e.g, with remote-compile) it didn't work very well and I Helmut> always run Emacs on the same machine. Is this a feature we want to Helmut> support or is this a would-be-nice-in-an-ideal-world thing?
Not a very good argument, but this is something that Franz' ELI does out of the box.
Do you know how they do it? What happens when you `M-.' and the definition isn't on a filesystem directly accessible to Emacs?
-Luke
Luke Gorrie luke@bluetail.com writes:
Do you know how they do it? What happens when you `M-.' and the definition isn't on a filesystem directly accessible to Emacs?
Here are some interesting bits from the ELI documentation:
If you run Emacs and Lisp on different machines, then you must be certain that the value of fi:emacs-to-lisp-transaction-directory is a directory which is accessible on both machines. Care must be taken to get the pathname just right, including the possible NFS prefix (/net/MACHINE-NAME/...).
(defvar fi:emacs-to-lisp-transaction-directory ... "*The directory in which files for Emacs/Lisp communication are stored. When using Lisp and Emacs on different machines, this directory must be accessible on both machine with the same pathname (via the wonders of NFS).")
(defun fi:common-lisp (&optional ... Each Emacs may have at most one Emacs-Lisp connection. If a connection already exists when fi:common-lisp is called, then the *common-lisp* buffer will be made the current buffer, and all arguments will be ignored."
(defvar fi:filename-frobber-hook 'fi::discombobulate-automounter-lint "*If non-nil, then name of a function which transforms filenames received from Lisp. This exists solely for the purpose of removing /tmp_mnt/net from the beginning of filenames that are on automounted filesystems.")
What about adding two hooks, a translate-from-lisp-filename-hook and a translate-to-lisp-filename-hook, and let users set them to appropriate values?
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at:
Helmut> Daniel Barlow dan@telent.net writes:
Opinions? You can get attachtty as part of detachtty, in Debian, FreeBSD ports, or from http://www.cliki.net/detachtty
Helmut> Are you aware that CVS Emacs has support for Unix sockets? It Helmut> does server socket too.
Helmut> I don't know why people are so keen to use a setup where the Helmut> Lisp and Emacs are on different machines, but whenever I tried Helmut> to do something like that (e.g, with remote-compile) it didn't Helmut> work very well and I always run Emacs on the same machine. Is Helmut> this a feature we want to support or is this a Helmut> would-be-nice-in-an-ideal-world thing?
Many good reasons have already been listed in this thread, I'll add another one: virtual machines. I routinely use UML (User-Mode Linux) and VMware to run stuff. Now there is also Xen on the horizon, which is supposed to virtualize with marginally small performance loss.
If you wonder why one would want to run a Lisp in a virtual machine, think snapshots, versioning, copy-on-write, experiments. Plus, the day UML or Xen gets software suspend-to-disk support, I'm moving all my life inside it. Just imagine a permanent, suspendable, migratable environment, where you do not have to reset your programming environment just because your USB drivers chose to pull the machine down with them.
So, I'll pitch in: yes, there are good reasons to support a remote Lisp.
--J.
-
Brian Mastenbrook -
Christian Lynbech -
Daniel Barlow -
Helmut Eller -
Jan Rychter -
Luke Gorrie -
Paolo Amoroso -
Sean O'Rourke