[slime-devel] per-slime-dialect slime-connected-hook implementation
The following snippet adds support for per-slime-dialect hooks to be called after the connection is established. A subtle point is that this allows for nice customisation of lisp projects to be run: (define-slime-dialect "foo" "sbcl" nil (lambda () (cd "/foo/project/path/") (slime-load-file "load-foo.lisp"))) (define-slime-dialect "bar" "sbcl" nil (lambda () (cd "/path/to/bar/project/") (slime-load-file "load-bar.lisp"))) Granted, this could have been arranged for via parameters to sbcl, effectively making an illusion of two "differeng" lisp implementations, but somehow this just feels... cleaner? (this is against cvs slime) --- slime/slime.el 2006-11-29 04:11:54.000000000 +0300 +++ slime-new/slime.el 2006-11-29 04:07:28.000000000 +0300 @@ -1573,20 +1573,29 @@ (when package (slime-repl-set-package (second package))))))) -(defmacro define-slime-dialect (name &optional program hook) +(defvar *slime-in-dialect* nil) + +(defmacro define-slime-dialect (name &optional program hook connhook) "Define a command slime-dialect-NAME to start a specific Lisp. PROGRAM is the command to start the inferior process. HOOK is function which is run before the process is started." (let ((funsym (intern (format "slime-dialect-%s" name))) (hooksym (intern (format "slime-dialect-%s-hook" name))) + (connhooksym (intern (format "slime-dialect-%s-connected-hook" name))) (progsym (intern (format "slime-dialect-%s-program" name)))) `(progn (defvar ,progsym ,program) (defvar ,hooksym ,hook) + (defvar ,connhooksym ,connhook) + (add-hook 'slime-connected-hook + (lambda () + (when (equal *slime-in-dialect* ,name) + (run-hooks ',connhooksym)))) (defun ,funsym () ,(format "Start up slime according to `%s'." progsym) (interactive) (let ((inferior-lisp-program ,progsym)) + (setq *slime-in-dialect* ,name) (run-hooks ',hooksym) (call-interactively 'slime))))))
_deepfire@feelingofgreen.ru writes:
+(defmacro define-slime-dialect (name &optional program hook connhook) "Define a command slime-dialect-NAME to start a specific Lisp. PROGRAM is the command to start the inferior process. HOOK is function which is run before the process is started." (let ((funsym (intern (format "slime-dialect-%s" name))) (hooksym (intern (format "slime-dialect-%s-hook" name))) + (connhooksym (intern (format "slime-dialect-%s-connected-hook" name))) (progsym (intern (format "slime-dialect-%s-program" name)))) `(progn (defvar ,progsym ,program) (defvar ,hooksym ,hook) + (defvar ,connhooksym ,connhook) + (add-hook 'slime-connected-hook + (lambda () + (when (equal *slime-in-dialect* ,name) + (run-hooks ',connhooksym)))) (defun ,funsym () ,(format "Start up slime according to `%s'." progsym) (interactive) (let ((inferior-lisp-program ,progsym)) + (setq *slime-in-dialect* ,name)
would a let work jsut as well here? (i'd like to avoid a new global if it's only purpose is to choose which hook to run).
(run-hooks ',hooksym) (call-interactively 'slime))))))
-- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
At Thu, 30 Nov 2006 17:03:38 +0100, Marco Baringer wrote: [snipped]
(defun ,funsym () ,(format "Start up slime according to `%s'." progsym) (interactive) (let ((inferior-lisp-program ,progsym)) + (setq *slime-in-dialect* ,name)
would a let work jsut as well here? (i'd like to avoid a new global if it's only purpose is to choose which hook to run).
(run-hooks ',hooksym) (call-interactively 'slime))))))
Only if a let-bound variable could be made dynamic-extent, which, as far as i know (i could be wrong,) elisp cannot do. regards, Samium Gromoff
+ Samium Gromoff <_deepfire@feelingofgreen.ru>: | Only if a let-bound variable could be made dynamic-extent, which, as | far as i know (i could be wrong,) elisp cannot do. Uh, as far as I know, that is the ONLY kind of let elisp knows about. (The cl package for emacs works pretty hard to make a lexically scoped version of let.) - Harald
At Fri, 01 Dec 2006 09:11:27 +0100 (CET), Harald Hanche-Olsen wrote:
+ Samium Gromoff <_deepfire@feelingofgreen.ru>:
| Only if a let-bound variable could be made dynamic-extent, which, as | far as i know (i could be wrong,) elisp cannot do.
Uh, as far as I know, that is the ONLY kind of let elisp knows about.
(The cl package for emacs works pretty hard to make a lexically scoped version of let.)
Hmm, perhaps i am doing something wrong, but, i tried to replace the defvar + setq with a let, and now emacs says: error in process filter: Symbol's value as variable is void: *slime-in-dialect* basically the change -(defvar *slime-in-dialect* nil) +;; (defvar *slime-in-dialect* nil) (defmacro define-slime-dialect (name &optional program hook connhook) "Define a command slime-dialect-NAME to start a specific Lisp. PROGRAM is the command to start the inferior process. HOOK is function which is run before the process is started." (let ((funsym (intern (format "slime-dialect-%s" name))) (hooksym (intern (format "slime-dialect-%s-hook" name))) (connhooksym (intern (format "slime-dialect-%s-connected-hook" name))) (progsym (intern (format "slime-dialect-%s-program" name)))) `(progn (defvar ,progsym ,program) (defvar ,hooksym ,hook) (defvar ,connhooksym ,connhook) (add-hook 'slime-connected-hook (lambda () (when (equal *slime-in-dialect* ,name) (run-hooks ',connhooksym)))) (defun ,funsym () ,(format "Start up slime according to `%s'." progsym) (interactive) - (let ((inferior-lisp-program ,progsym)) - (setq *slime-in-dialect* ,name) + (let ((inferior-lisp-program ,progsym) + (*slime-in-dialect* ,name)) (run-hooks ',hooksym) (call-interactively 'slime)))))) breaks it.
- Harald
regards, Samium Gromoff
+ Samium Gromoff <_deepfire@feelingofgreen.ru>: | At Fri, 01 Dec 2006 09:11:27 +0100 (CET), | Harald Hanche-Olsen wrote: | > | > + Samium Gromoff <_deepfire@feelingofgreen.ru>: | > | > | Only if a let-bound variable could be made dynamic-extent, which, as | > | far as i know (i could be wrong,) elisp cannot do. | > | > Uh, as far as I know, that is the ONLY kind of let elisp knows about. | > | > (The cl package for emacs works pretty hard to make a lexically scoped | > version of let.) | | Hmm, perhaps i am doing something wrong, but, i tried to replace | the defvar + setq with a let, and now emacs says: | | error in process filter: Symbol's value as variable is void: *slime-in-dialect* I now think that while what I said is technically correct, it was a bit beside the point. I only reacted to an isolated statement, without taking the larger context into account. And this context is very likely related to non-synchronicity: You bind the variable *slime-in-dialect* and call slime. But after slime has finished its job and your function returns, the binding for *slime-in-dialect* is also gone, and so the process filter gets in trouble when it tries to access the variable later. The easiest fix would be to return to using setq, but given that you are using this variable in slime-connected-hook, I think a better solution would be to ask the Lisp process itself what kind of lisp it is, essentially by running something like (slime-eval '(cl:lisp-implementation-type)) and using the response to decide which hook to run. (Note the importance of including the package name on ALL symbols when you call slime-eval. If whatever you send to the other side causes a reader error, the slime connection will be closed down.) This should have the added advantage of doing the right thing when using slime-connect to connect to an already running lisp. - Harald
At Fri, 01 Dec 2006 20:22:47 +0100 (CET), Harald Hanche-Olsen wrote: [snip]
I now think that while what I said is technically correct, it was a bit beside the point. I only reacted to an isolated statement, without taking the larger context into account.
And this context is very likely related to non-synchronicity: You bind the variable *slime-in-dialect* and call slime. But after slime has finished its job and your function returns, the binding for *slime-in-dialect* is also gone, and so the process filter gets in trouble when it tries to access the variable later.
The easiest fix would be to return to using setq, but given that you are using this variable in slime-connected-hook, I think a better solution would be to ask the Lisp process itself what kind of lisp it is, essentially by running something like (slime-eval '(cl:lisp-implementation-type)) and using the response to decide which hook to run. (Note the importance of including the package name on ALL symbols when you call slime-eval. If whatever you send to the other side causes a reader error, the slime connection will be closed down.)
This should have the added advantage of doing the right thing when using slime-connect to connect to an already running lisp.
I think i have a different solution -- pass the variable in question via slime-init-connection-state through into the asynchronously-called closure, and establish the dynamic binding inside it.
- Harald
regards, Samium Gromoff
_deepfire@feelingofgreen.ru writes:
The following snippet adds support for per-slime-dialect hooks to be called after the connection is established.
I haven't looked at the code, but would not define-slime-lisp be a more appropriate name, since different implementations are not dialects after all... Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
At Thu, 30 Nov 2006 18:08:40 +0200, Nikodemus Siivola wrote:
_deepfire@feelingofgreen.ru writes:
The following snippet adds support for per-slime-dialect hooks to be called after the connection is established.
I haven't looked at the code, but would not
define-slime-lisp
be a more appropriate name, since different implementations are not dialects after all...
As far as i have an opinion on this question (which is not very), i mostly agree -- but i merely updated the existing code, so for the current naming i am not the person to blame :-) Actually, on a second thought, i`d probably vote for define-slime-profile because if this feature is to be used as intended, what could be achieved might effectively be same implementation, yet different use mode. regards, Samium Gromoff
* _deepfire@feelingofgreen.ru [2006-11-29 05:24+0100] writes:
The following snippet adds support for per-slime-dialect hooks to be called after the connection is established.
A subtle point is that this allows for nice customisation of lisp projects to be run:
(define-slime-dialect "foo" "sbcl" nil (lambda () (cd "/foo/project/path/") (slime-load-file "load-foo.lisp"))) (define-slime-dialect "bar" "sbcl" nil (lambda () (cd "/path/to/bar/project/") (slime-load-file "load-bar.lisp")))
Granted, this could have been arranged for via parameters to sbcl, effectively making an illusion of two "differeng" lisp implementations, but somehow this just feels... cleaner?
define-slime-dialect is semi obsolete. slime-start in combination with slime-lisp-implementations should be used instead. I added a :init-function arg to slime-start which can be used like your hooks. Your examples can now be achieved with something like this: (setq slime-lisp-implementations '((foo ("sbcl") :init-function (lambda () (cd "/foo/project/path/") (slime-load-file "load-foo.lisp"))))) or with a simple function like: (defun bar () (interactive) ;; ... code for pre-hook, if you need that (slime-start :program "sbcl" :init-function (lambda () ...))) Helmut.
At Tue, 05 Dec 2006 15:38:32 +0100, Helmut Eller wrote:
* _deepfire@feelingofgreen.ru [2006-11-29 05:24+0100] writes:
The following snippet adds support for per-slime-dialect hooks to be called after the connection is established.
[snip]
define-slime-dialect is semi obsolete. slime-start in combination with slime-lisp-implementations should be used instead.
I added a :init-function arg to slime-start which can be used like your hooks. Your examples can now be achieved with something like this:
(setq slime-lisp-implementations '((foo ("sbcl") :init-function (lambda () (cd "/foo/project/path/") (slime-load-file "load-foo.lisp")))))
or with a simple function like:
(defun bar () (interactive) ;; ... code for pre-hook, if you need that (slime-start :program "sbcl" :init-function (lambda () ...)))
Very nice, thanks!
Helmut.
regards, Samium Gromoff
This is possibly the wrong list but having been on it long enough to know the calibre of participants I would just like to ask: if I had been developing something and wanted to release it, what would be the best solution. LispWorks ? My personal best-fit idea is to package up a running Linux image with either SBCL or CLISP and distribute it as a VMWare Player image or something... Any comments ? Sean Charles
On Wed, 06 Dec 2006 14:03:44 +0000, Sean Charles <sean.charles@objitsu.com> wrote:
This is possibly the wrong list but having been on it long enough to know the calibre of participants I would just like to ask: if I had been developing something and wanted to release it, what would be the best solution. LispWorks ?
Yes. IMHO, YMMV, etc.
Hi Edi (and everyone else), On Dec 6, 2006, at 11:03 AM, Edi Weitz wrote:
On Wed, 06 Dec 2006 14:03:44 +0000, Sean Charles <sean.charles@objitsu.com> wrote:
This is possibly the wrong list but having been on it long enough to know the calibre of participants I would just like to ask: if I had been developing something and wanted to release it, what would be the best solution. LispWorks ?
Yes. IMHO, YMMV, etc.
It seems to me that it would be really (really, really) interesting to hear about the pros and cons of LW, ACL, SBCL, etc. vis-a-vis the "real world". I was in academia too long to really understand the real world but I think I've seen something like it on TV. In any case, why would you recommend LW over ACL? thanks, -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
On Wed, 6 Dec 2006 11:19:14 -0500, Gary King <gwking@metabang.com> wrote:
It seems to me that it would be really (really, really) interesting to hear about the pros and cons of LW, ACL, SBCL, etc. vis-a-vis the "real world". I was in academia too long to really understand the real world but I think I've seen something like it on TV.
In any case, why would you recommend LW over ACL?
The short answer is license issues, CAPI, IDE. There's also a longer answer, but I'm too busy with other "real world" stuff right now and I don't think this is the right forum. One of these days, when I have more time, I'll probably write "Edi's Common Lisp FAQ" - now that we have Nikodemus' version... :)
Sean Charles <sean.charles@objitsu.com> writes:
This is possibly the wrong list but having been on it long enough to know the calibre of participants I would just like to ask: if I had been developing something and wanted to release it, what would be the best solution. LispWorks ?
Wrong list and an ill-defined question. Whatever you want to release has its own set of requirements, and your release goals place other requirements.
My personal best-fit idea is to package up a running Linux image with either SBCL or CLISP and distribute it as a VMWare Player image or something...
If you want to know how to deploy an application using SBCL, I'll be happy to help on the SBCL lists -- but as a quick hint, use SAVE-LISP-AND-DIE with the :EXECUTABLE argument; works on Windows too. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola wrote:
Sean Charles <sean.charles@objitsu.com> writes:
This is possibly the wrong list but having been on it long enough to know the calibre of participants I would just like to ask: if I had been developing something and wanted to release it, what would be the best solution. LispWorks ?
Wrong list and an ill-defined question. Whatever you want to release has its own set of requirements, and your release goals place other requirements.
I thought the question was pretty much to the point! I never mentioned release goals at all, I just asked what would be the best solution. Having used Smalltalk for about six years and released an educational game, I had similar issues; in the end I used Squeak and created a 'save-and-die' approach for that. I'll concede it was the wrong list though, but finding keen Lisp'ers is not easy, they tend to be too busy enjoying themselves. ;-)
My personal best-fit idea is to package up a running Linux image with either SBCL or CLISP and distribute it as a VMWare Player image or something...
If you want to know how to deploy an application using SBCL, I'll be happy to help on the SBCL lists -- but as a quick hint, use SAVE-LISP-AND-DIE with the :EXECUTABLE argument; works on Windows too.
I already know how to deploy a Lisp solution etc etc I use SBCL for all me personal scripting needs at home and work (self-employed!), I just wanted to hear others views. Consider it closed.
participants (9)
-
_deepfire＠feelingofgreen.ru -
Edi Weitz -
Gary King -
Harald Hanche-Olsen -
Helmut Eller -
Marco Baringer -
Nikodemus Siivola -
Samium Gromoff
-
Sean Charles