Somebody wrote to me wanting to use Qi-tk under SBCL (right now it
runs under CLisp/XP). To oblige I looked at a port.
My code dates back in part to 2004 and does not assume threads in the
CL (in fact AFAIK, SBCL Windows still does not have it). Hence the
system was rigged up to jump between the keyboard stream and the
stream from Tk and respond accordingly with a SLEEP .01 in the middle
to stop the loop sucking up all the CPU.
It works fine under CLisp; but I do remember that at one point in 2004
I had trouble getting the thing to work (I cannot exactly remember
what the problem was). Carl Shapiro kindly sent in a patch which did
the trick.
; Carl's code here ....
(DEFUN listen-to-keyboard ()
(process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*)))
; .... and here
(DEFUN read-from-keyboard (KeyBoard)
(EXT:WITH-KEYBOARD
(LET ((Char
(READ-CHAR-NO-HANG KeyBoard NIL NIL)))
(IF (NULL Char)
NIL
(SYS::INPUT-CHARACTER-CHAR Char)))))
process-keyboard collects the user input and stores it.
So fast forward in 2009 and the port to SBCL and I try
(DEFUN listen-to-keyboard ()
#+CLISP (process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*))
#+SBCL (process-keyboard (READ-CHAR-NO-HANG)))
However the system now responds to a Tk signal only after the user has
typed in a carriage return. Can somebody shed some light here?
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> Somebody wrote to me wanting to use Qi-tk under SBCL (right now it
> runs under CLisp/XP). To oblige I looked at a port.
>
> My code dates back in part to 2004 and does not assume threads in the
> CL (in fact AFAIK, SBCL Windows still does not have it). Hence the
> system was rigged up to jump between the keyboard stream and the
> stream from Tk and respond accordingly with a SLEEP .01 in the middle
> to stop the loop sucking up all the CPU.
>
> It works fine under CLisp; but I do remember that at one point in 2004
> I had trouble getting the thing to work (I cannot exactly remember
> what the problem was). Carl Shapiro kindly sent in a patch which did
> the trick.
>
> ; Carl's code here ....
> (DEFUN listen-to-keyboard ()
> (process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*)))
>
> ; .... and here
> (DEFUN read-from-keyboard (KeyBoard)
> (EXT:WITH-KEYBOARD
> (LET ((Char
> (READ-CHAR-NO-HANG KeyBoard NIL NIL)))
> (IF (NULL Char)
> NIL
> (SYS::INPUT-CHARACTER-CHAR Char)))))
>
> process-keyboard collects the user input and stores it.
>
> So fast forward in 2009 and the port to SBCL and I try
>
> (DEFUN listen-to-keyboard ()
> #+CLISP (process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*))
> #+SBCL (process-keyboard (READ-CHAR-NO-HANG)))
>
> However the system now responds to a Tk signal only after the user has
> typed in a carriage return. Can somebody shed some light here?
Have you heard of tty raw mode and tty cooked mode?
EXT:WITH-KEYBOARD sets the raw mode on the keyboard stream, before
trying to read a character.
You will have to do the same in SBCL.
man tcsetattr ; and use sb-posix.
--
__Pascal Bourguignon__
On 5 May, 21:40, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > Somebody wrote to me wanting to use Qi-tk under SBCL (right now it
> > runs under CLisp/XP). To oblige I looked at a port.
>
> > My code dates back in part to 2004 and does not assume threads in the
> > CL (in fact AFAIK, SBCL Windows still does not have it). Hence the
> > system was rigged up to jump between the keyboard stream and the
> > stream from Tk and respond accordingly with a SLEEP .01 in the middle
> > to stop the loop sucking up all the CPU.
>
> > It works fine under CLisp; but I do remember that at one point in 2004
> > I had trouble getting the thing to work (I cannot exactly remember
> > what the problem was). Carl Shapiro kindly sent in a patch which did
> > the trick.
>
> > ; Carl's code here ....
> > (DEFUN listen-to-keyboard ()
> > (process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*)))
>
> > ; .... and here
> > (DEFUN read-from-keyboard (KeyBoard)
> > (EXT:WITH-KEYBOARD
> > (LET ((Char
> > (READ-CHAR-NO-HANG KeyBoard NIL NIL)))
> > (IF (NULL Char)
> > NIL
> > (SYS::INPUT-CHARACTER-CHAR Char)))))
>
> > process-keyboard collects the user input and stores it.
>
> > So fast forward in 2009 and the port to SBCL and I try
>
> > (DEFUN listen-to-keyboard ()
> > #+CLISP (process-keyboard (read-from-keyboard EXT:*KEYBOARD-INPUT*))
> > #+SBCL (process-keyboard (READ-CHAR-NO-HANG)))
>
> > However the system now responds to a Tk signal only after the user has
> > typed in a carriage return. Can somebody shed some light here?
>
> Have you heard of tty raw mode and tty cooked mode?
>
> EXT:WITH-KEYBOARD sets the raw mode on the keyboard stream, before
> trying to read a character.
>
> You will have to do the same in SBCL.
> man tcsetattr ; and use sb-posix.
>
> --
> __Pascal Bourguignon__- Hide quoted text -
>
> - Show quoted text -
Thanks. I've got that distinction now. Posix does not look like
something I'd have the time to go into.
Snorgers on Qilang managed to get Qi/tk to work under SBCL/Linux by
ripping out the code for alternating between streams and using threads
instead. AFAIK SBCL Windows does not have threads. Are there any
plans to change this?
This is really for people who are current with SBCL development.
Mark