Chun Tian (binghe) wrote:
Well, this is the problem: I cannot reproduce the "bug" you met. I added two
new simple unit tests into exist USOCKET test suite, to confirm if WAIT-FOR-INPUT could
return immediately when :READY-ONLY was supplied, but my test results showed everything
is just right
Hi, Daniel
Thanks, this time I fully understand what you're talking about.
> Thanks for the reply, but I have some issues:
>
> (1) ready-only should be documented in the doc string.
DONE. You'll see it in our next release.
>
> (2) If ready-only is just supposed to be about consing,
> it shoul
Thanks for the reply, but I have some issues:
(1) ready-only should be documented in the doc string.
(2) If ready-only is just supposed to be about consing,
it should not change any behavior other than that.
(3) Why it is ever right for wait-for-input to return
when there isn't any input? Is the
Notice: All "READ-ONLY" in past mail should be "READY-ONLY".
--binghe
在 2010-6-28，23:48， Chun Tian (binghe) 写道：
> Hi, Daniel
>
> I'm very sorry for the late response for your multiple posts on the
> :READY-ONLY keyword argument of WAIT-FOR-INPUT.
>
> The short answer for you will be: always u
Hi, Daniel
I'm very sorry for the late response for your multiple posts on the :READY-ONLY
keyword argument of WAIT-FOR-INPUT.
The short answer for you will be: always use (:READY-ONLY T), and ...
here is an formal answer from the original designer of WAIT-FOR-INPUT, Erik
Huelsmann:
"""
Witho
Hi. I just tried out the latest usocket. It's not working
properly for me, because wait-for-input returns true
even when there isn't any input.
If I change the default value of the :ready-only argument to
wait-for-input to t instead of nil, that fixes the problem.
I don't even understand why thi
