I am seeing a problem with the cvs head and sbcl 1.0.23 - slime does not clear the window and present me with the repl prompt. Instead I see the *inferior-lisp* window. Here is the last bit that shows up:
; loading #P"/home/ramb/.slime/fasl/2008-12-25/sbcl-1.0.23-linux-x86/swank.fasl" WARNING: These Swank interfaces are unimplemented: (ALL-THREADS CALLS-WHO DISASSEMBLE-FRAME INTERRUPT-THREAD RECEIVE-IF SEND SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN SPAWN WHO-SPECIALIZES) ;; Swank started at port: 46259. 46259 *
slime asks me about a version difference, I answer 'y' and then slime thinks that everything is OK. But the repl promt never shows up.
Any suggestions on how I can debug this?
-Ram
Hi,
On Dec 27, 2008, at 2:23 AM, Ram Bhamidipaty wrote:
I am seeing a problem with the cvs head and sbcl 1.0.23 - slime does not clear the window and present me with the repl prompt. Instead I see the *inferior-lisp* window. Here is the last bit that shows up:
; loading #P"/home/ramb/.slime/fasl/2008-12-25/sbcl-1.0.23-linux-x86/ swank.fasl" WARNING: These Swank interfaces are unimplemented: (ALL-THREADS CALLS-WHO DISASSEMBLE-FRAME INTERRUPT-THREAD RECEIVE-IF SEND SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN SPAWN WHO- SPECIALIZES) ;; Swank started at port: 46259. 46259
slime asks me about a version difference, I answer 'y' and then slime thinks that everything is OK. But the repl promt never shows up.
Try to remove $HOME/.slime and all slime fasl files then recompile/ restart again. Works for me with the latest CVS version.
--wbr.
Any suggestions on how I can debug this?
-Ram
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Try to remove $HOME/.slime and all slime fasl files then recompile/restart again. Works for me with the latest CVS version.
--wbr.
Hi,
Thanks for the tip. I tried that - no luck.
I can see that on the emacs side slime-set-connection-info will print out the message "Connected" along with the slime-random-words-of-encouragement. I do see that part. The inferior lisp buffer has the sbcl '*' prompt.
What part of slime should clear the screen and start the repl. Is there some kind of additional "signal" that is needed from the lisp/sbcl process or is the problem likely to be on the emacs side?
Again - my problem is that after emacs/slime prints out the connection greeting the screen is not cleared and I am not shown the repl buffer.
-Ram
* Ram Bhamidipaty [2008-12-27 01:39+0100] writes:
What part of slime should clear the screen and start the repl. Is there some kind of additional "signal" that is needed from the lisp/sbcl process or is the problem likely to be on the emacs side?
Again - my problem is that after emacs/slime prints out the connection greeting the screen is not cleared and I am not shown the repl buffer.
The REPL is now in contrib/ and you need to load that explicitly. For instance with (slime-setup '(slime-repl)) in your .emacs.
Helmut.
* Ram Bhamidipaty [2008-12-27 20:46+0100] writes:
Thank you!! That was it! Is slime very useful without the REPL buffer?
The *inferior-lisp* buffer is also REPL.
I'm just wondering if the it should be part of the default settings?
Well, it's my hope that SLIME gets easier to maintain if there are fewer features to care about.
Helmut.
On Sat, 27 Dec 2008 22:16:35 +0100, heller@common-lisp.net wrote:
- Ram Bhamidipaty [2008-12-27 20:46+0100] writes:
Thank you!! That was it! Is slime very useful without the REPL buffer?
The *inferior-lisp* buffer is also REPL.
I'm just wondering if the it should be part of the default settings?
Well, it's my hope that SLIME gets easier to maintain if there are fewer features to care about.
A horse is easier to maintain than an automobile. An automobile is easier to maintain than a 767 jet airplane. The horse is useless for getting across the Pacific Ocean in a day.
All that was accomplished is that you will be telling lots of people to add something to their .emacs and answering 'why do I have to do this now?'.
Perhaps a patient survey before surgery?
Then again, the easiest software to maintain is the one with zero users.
Helmut Eller heller@common-lisp.net writes:
- GP lisper [2008-12-28 23:50+0100] writes:
Then again, the easiest software to maintain is the one with zero users.
That, and the software which is maintained by other people.
Heh. That's true. I take it that you're not interested in maintaining any of the contribs? I would like to propose a process to support the contribs without getting in your way: let's have some sort of contrib maintainer than can test the contribs and tag the tree as FAIRLY_STABLE (or something similar) at regular intervals.
I could think of some people better prepared for this task, but if no one else is interested and this turns out to be a good idea, I'm volunteering for this task.
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
Comments welcome.
* Luis Oliveira [2008-12-29 15:28+0100] writes:
Helmut Eller heller@common-lisp.net writes:
- GP lisper [2008-12-28 23:50+0100] writes:
Then again, the easiest software to maintain is the one with zero users.
That, and the software which is maintained by other people.
Heh. That's true. I take it that you're not interested in maintaining any of the contribs?
Yes, mostly. Fixing bugs in contribs has rather low priority for me.
I would like to propose a process to support the contribs without getting in your way: let's have some sort of contrib maintainer than can test the contribs and tag the tree as FAIRLY_STABLE (or something similar) at regular intervals.
I could think of some people better prepared for this task, but if no one else is interested and this turns out to be a good idea, I'm volunteering for this task.
If you want do to that, more power to you!
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
Yes, automatic testing sounds like a good strategy. I think that a test server which runs the test suite once a day and sends the result to this mailing list would be quite useful (not only for contribs).
Helmut.
Luis Oliveira luismbo@gmail.com writes:
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
could you, please, send a link for this? (I don't know what factor is, and is a too generic term for google).
Pedro
pedro.kroger@gmail.com (Pedro Kröger) writes:
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
could you, please, send a link for this? (I don't know what factor is, and is a too generic term for google).
Sorry. This is what I was referring to: http://factorcode.org/binaries.fhtml
www.factorcode.org
Factor is a stack based language.
Thanks,
Glenn
V. Glenn Tarcea gtarcea@umich.edu
On Dec 29, 2008, at 2:25 PM, Pedro Kröger wrote:
Luis Oliveira luismbo@gmail.com writes:
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
could you, please, send a link for this? (I don't know what factor is, and is a too generic term for google).
Pedro
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
I asked Luis the same thing yesterday and he replied
http://factorcode.org/binaries.fhtml
HTH
On Dec 29, 2008, at 2:25 PM, Pedro Kröger wrote:
Luis Oliveira luismbo@gmail.com writes:
Given a comprehensive test suite this process could be completely automatic. (See Factor's build system for a nice example of this.)
could you, please, send a link for this? (I don't know what factor is, and is a too generic term for google).
Pedro
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM