Is there a reason why the pid of the inferior lisp should be asked from the lisp itself? Isn't (process-id (inferior-lisp-proc)) good enough? (Are multiple lisps in the same slime instance or a remotely running lisp the problem?)
I'm asking this both out of curiosity and because Java (and hence abcl) doesn't have a clue about its pid(s), at least AFAIK.
Andras
Andras Simon andras@renyi.hu writes:
Is there a reason why the pid of the inferior lisp should be asked from the lisp itself? Isn't (process-id (inferior-lisp-proc)) good enough? (Are multiple lisps in the same slime instance or a remotely running lisp the problem?)
Yes, you answered the question almost yourself.
inferior-lisp-proc is IMO not enough, because it basically does
(get-buffer-process inferior-lisp-buffer)
and inferior-lisp-buffer is "*inferior-lisp*" unless someone changed it. If we connect to Lisp, with say M-x slime-connect, there will be no "*inferior-lisp*" lisp buffer, but we need the pid sometimes. E.g. to interrupt Lisp if we use the :fd-handler communication style.
There's also the possibility that we have multiple connections, each with a different *inferior-lisp*<n> buffer and we have no nice way to find out which of those *inferior-lisp* buffers belongs to which Lisp connection.
Recently I made some pid related changes and I guess I've created some problems for you. Basically I just needed a way to find the inferior lisp process, the Emacs object that is, to restart it with the original command line. slime-process just searches the pid in the process-list.
I'm asking this both out of curiosity and because Java (and hence abcl) doesn't have a clue about its pid(s), at least AFAIK.
I see; that's a problem. Perhaps we should make slime-process a per connection variable and initialize it at startup, i.e. when SLIME is started with M-x slime.
Helmut.
On Fri, 1 Oct 2004, Helmut Eller wrote:
[...]
Recently I made some pid related changes and I guess I've created some problems for you. Basically I just needed a way to find the inferior
Yes, although it's not like I can't live without, say, ,restart-inferior-lisp.
lisp process, the Emacs object that is, to restart it with the original command line. slime-process just searches the pid in the process-list.
I'm asking this both out of curiosity and because Java (and hence abcl) doesn't have a clue about its pid(s), at least AFAIK.
I see; that's a problem. Perhaps we should make slime-process a per connection variable and initialize it at startup, i.e. when SLIME is started with M-x slime.
That would be nice (if this means what I think it does).
Thanks!
Andras
On Fri, 1 Oct 2004, Helmut Eller wrote:
There's also the possibility that we have multiple connections, each with a different *inferior-lisp*<n> buffer and we have no nice way to find out which of those *inferior-lisp* buffers belongs to which Lisp connection.
Looks like there's something wrong with multiple connections anyway. slime-goto-connection and ,restart-inferior-lisp don't seem to work.
I see; that's a problem. Perhaps we should make slime-process a per connection variable and initialize it at startup, i.e. when SLIME is started with M-x slime.
One problem I see with this (and I may very well be wrong about it) is that in that case slime-process must not only be set at startup, but kept up-to-date. E.g. if a lisp dies, the corresponding slime-process should be set to nil.
Also, is there any way to set it at startup other then by calling inferior-lisp-proc, say, in slime-start-lisp?
Andras
Andras Simon andras@renyi.hu writes:
Looks like there's something wrong with multiple connections anyway. slime-goto-connection and ,restart-inferior-lisp don't seem to work.
Works for me :)
One problem I see with this (and I may very well be wrong about it) is that in that case slime-process must not only be set at startup, but kept up-to-date. E.g. if a lisp dies, the corresponding slime-process should be set to nil.
slime-process looks at the process-status and returns nil if the process is dead.
Also, is there any way to set it at startup other then by calling inferior-lisp-proc, say, in slime-start-lisp?
No, we have no special way. But inferior-lisp-proc should be good enough for the initialization.
Helmut.
On Sat, 2 Oct 2004, Helmut Eller wrote:
Andras Simon andras@renyi.hu writes:
Looks like there's something wrong with multiple connections anyway. slime-goto-connection and ,restart-inferior-lisp don't seem to work.
Works for me :)
Hm, I wonder what I'm doing wrong. I tried it with acl/cmucl, and hitting RET in the *SLIME connections* buffer just put me in the REPL of the default connection.
One problem I see with this (and I may very well be wrong about it) is that in that case slime-process must not only be set at startup, but kept up-to-date. E.g. if a lisp dies, the corresponding slime-process should be set to nil.
slime-process looks at the process-status and returns nil if the process is dead.
Yes, that's what it does now. But you wrote:
| I see; that's a problem. Perhaps we should make slime-process a per | connection variable and initialize it at startup, i.e. when SLIME is | started with M-x slime.
and it's this suggestion (that slime-process be turned into a per connection variable) that I reacted to.
Also, is there any way to set it at startup other then by calling inferior-lisp-proc, say, in slime-start-lisp?
No, we have no special way. But inferior-lisp-proc should be good enough for the initialization.
OK.
Andras
BTW: I have this win32 improvement for slime-clisp.lisp
#+win32 (defmethod getpid () (or (and (find-package "WIN32") (WIN32:|GetCurrentProcessId|)) (system::getenv "PID") -1))
I posted this on 9/23/04 but it didn't make it through. Now I got reminded.
Andras Simon schrieb:
Is there a reason why the pid of the inferior lisp should be asked from the lisp itself? Isn't (process-id (inferior-lisp-proc)) good enough? (Are multiple lisps in the same slime instance or a remotely running lisp the problem?)
I'm asking this both out of curiosity and because Java (and hence abcl) doesn't have a clue about its pid(s), at least AFAIK.
Reini Urban rurban@x-ray.at writes:
BTW: I have this win32 improvement for slime-clisp.lisp
#+win32 (defmethod getpid () (or (and (find-package "WIN32") (WIN32:|GetCurrentProcessId|)) (system::getenv "PID") -1))
I posted this on 9/23/04 but it didn't make it through. Now I got reminded.
Thanks! I've added this to the CVS version.
Helmut.
-
Andras Simon -
Helmut Eller -
Reini Urban