Specifically, :OS-PROVIDES-POLL isn't on *FEATURES* there because :OS-PROVIDES-POLL really means "OS provides poll() good enough for SBCL's internal needs", which includes the ability to poll on things like stdin and /dev/null -- which Darwin's poll() doesn't do.
I'm also a bit dismayed by the amount of SB-IMPL::FOO going on in DEFUN POLL. That stuff is going to break, probably sooner than later.
So SWANK could probably use Darwin's poll() just fine -- except some of the SBCL internals it tries to use aren't there.
Not sure what's the best solution -- and what's the most expedient one.
Cheers,
-- Nikodemus
* Nikodemus Siivola [2011-12-03 14:42] writes:
Specifically, :OS-PROVIDES-POLL isn't on *FEATURES* there because :OS-PROVIDES-POLL really means "OS provides poll() good enough for SBCL's internal needs", which includes the ability to poll on things like stdin and /dev/null -- which Darwin's poll() doesn't do.
Darwin can't poll /dev/null? How strange.
I'm also a bit dismayed by the amount of SB-IMPL::FOO going on in DEFUN POLL. That stuff is going to break, probably sooner than later.
There is exactly one use of such a symbol: sb-impl::fd-stream-fd. Easy solution: replace it with sb-sys:fd-stream-fd :-)
So SWANK could probably use Darwin's poll() just fine -- except some of the SBCL internals it tries to use aren't there.
Not sure what's the best solution -- and what's the most expedient one.
If SBCL supports threads then we don't need WAIT-FOR-INPUT.
Helmut
I committed a version of WAIT-FOR-INPUT that /should/ work on all SBCL platforms.
Fingers crossed,
-- nikodemus
* Nikodemus Siivola [2011-12-03 15:32] writes:
I committed a version of WAIT-FOR-INPUT that /should/ work on all SBCL platforms.
Fingers crossed,
It's now broken on Linux with SBCL 1.0.53.31-67a805d-dirty.
Helmut
On 3 December 2011 17:37, Helmut Eller heller@common-lisp.net wrote:
It's now broken on Linux with SBCL 1.0.53.31-67a805d-dirty.
Feh.
/me goes looking for a Linux host.
Cheers,
-- nikodemus
On 3 December 2011 17:37, Helmut Eller heller@common-lisp.net wrote:
It's now broken on Linux with SBCL 1.0.53.31-67a805d-dirty.
I just tried to replicate on Linux, and it seems to work fine.
Can you provide more details?
Cheers,
-- nikodemus
* Nikodemus Siivola [2011-12-03 16:11] writes:
On 3 December 2011 17:37, Helmut Eller heller@common-lisp.net wrote:
It's now broken on Linux with SBCL 1.0.53.31-67a805d-dirty.
I just tried to replicate on Linux, and it seems to work fine.
Can you provide more details?
1. add #+sbcl (setq swank:*communication-style* nil) to ~/.swank.lisp 2. start Emacs with:
emacs -Q -nw -eval '(setq inferior-lisp-program "sbcl --no-userinit")' \ -l slime.el -f slime-setup -f slime x.lisp
3. insert a form that would produce an error: (/ 1 0) 4. type C-x C-e and dismiss the debugger with q when in pops up 5. type C-x C-e again and nothing happens except that ; pipelined request... (swank:interactive-eval "(/ 1 0)") appears in the message area
Helmut
On 3 December 2011 18:48, Helmut Eller heller@common-lisp.net wrote:
- add #+sbcl (setq swank:*communication-style* nil) to ~/.swank.lisp
- start Emacs with:
emacs -Q -nw -eval '(setq inferior-lisp-program "sbcl --no-userinit")' \ -l slime.el -f slime-setup -f slime x.lisp
- insert a form that would produce an error: (/ 1 0)
- type C-x C-e and dismiss the debugger with q when in pops up
- type C-x C-e again and nothing happens except
that ; pipelined request... (swank:interactive-eval "(/ 1 0)") appears in the message area
Thanks. Should be better now -- sorry about the breakage.
Cheers,
-- nikodemus
-
Helmut Eller -
Nikodemus Siivola