[usocket-devel] HOST-TO-HBO bug on SBCL

[Erik Huelsmann]

On Sun, Jul 27, 2008 at 9:11 PM, Chun Tian (binghe)
<binghe.lisp at gmail.com> wrote:
> Hi,
>
>>>
>>> Seems you have merged the new-wfi branch, I'll test these new trunk code
>>> soon.
>>
>> That would be great! Note that it may not work with datagram sockets
>> on all implementations yet.
>
> After some small fixes (all of them are sent to this list), new WFI function
> works *well* with datagram sockets. Just no different from my current view
> (I didn't wait multiple sockets in my package yet)
>
>>
>>
>>> Can I ask, when will you make the first 0.4.x release? Is there still
>>> anything to do?
>>
>> Yes: Hans Huebner committed to his branch a number of enhancements
>> required by BKNR or ITA (presumably the latter). I'd like to merge a
>> number of them.
>>
>> If - in the mean time - I can address binding the local interface - as
>> requested by Chris - I'd be happy to merge that too. I hope to get
>> usocket released in 2 to 4 weeks. Because in between now and 4 weeks
>> there's also my holidays, it looks more like in 4 weeks as it stands
>> now.
>
> OK. I just hope it can release as you plan. Once usocket-0.4.x can be
> installed through ASDF-INSTALL, my packages (ASN.1, SNMP, ...) will also can
> be installed quite easily through ASDF-INSTALL:)
>
> For CMUCL binding local interface support, I think my patch to CMUCL only
> have chance to be merged from next CMUCL release (19f), so you should make a
> judgement: whether to support current version of cmucl. If you choose to
> support it, then you should put my loadable patch directly into
> backend/cmucl.lisp, prefixed with this:
>
> #+(or cmu18 cmu19a cmu19b cmu19c cmu19d cmu19e)
>
>
>
>
>
>>
>>
>> As always: if you - or anyone else - have test results (even
>> succesfull ones) please send them to the list: I could really use the
>> feedback (especially with a release coming up).
>
> Just curious, it there any one testing the #+(and LispWorks win32) platform?
> Last time I check the WAIT-FOR-INPUT in 0.4.x branch, it's very broken,
> completely cannot work. (I'll check the 0.4.x again to confirm this)

Well, last time I tested it. However, the test I used was a lot
broken. Since then, it has been somewhat rewritten and it should work.
What happened is that W-F-I got stuck waiting for input when there was
input left on the stream (in the LW buffers). This cannot happen
anymore, because now, the implementation checks LISTEN before passing
on any timeout values larger than 0.

Testing is most welcome, though. I see you have LW64. You don't have
it on Win64, by any chance? If so, could you provide instructions/a
patch to make LW work on Win64?

Thanks again!

Bye,

Erik.