Hi, Erik
On SBCL (I'm using 1.0.18.x), HOST-TO-HBO cannot work for string:
* (usocket::host-to-hbo "localhost")
debugger invoked on a SB-KERNEL:CASE-FAILURE: #(127 0 0 1) fell through ETYPECASE expression. Wanted one of (INTEGER (VECTOR T 4) STRING).
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
This is because SBCL return #(127 0 0 1) as type (simple-array (unsigned-byte 8) (4)), it's not a subtype of (VECTOR T 4).
An solution is add more type to the ETYPECASE of HOST-TO-HBO: (and HOST-TO-VECTOR-QUAD)
#-(or clisp armedbear) (progn (defun host-to-vector-quad (host) "Translate a host specification (vector quad, dotted quad or domain name) to a vector quad." (etypecase host (string (let* ((ip (ignore-errors (dotted-quad-to-vector-quad host)))) (if (and ip (= 4 (length ip))) ;; valid IP dotted quad? ip (get-random-host-by-name host)))) ((vector t 4) host) ((simple-array (unsigned-byte 8) (4)) host) (integer (hbo-to-vector-quad host)) (null nil)))
(defun host-to-hbo (host) (etypecase host (string (let ((ip (ignore-errors (dotted-quad-to-vector-quad host)))) (if (and ip (= 4 (length ip))) (host-byte-order ip) (host-to-hbo (get-host-by-name host))))) ((vector t 4) (host-byte-order host)) ((simple-array (unsigned-byte 8) (4)) (host-byte-order host)) (integer host) (null nil))))
For some reason, I think just let (HOST-TO-HBO NIL) returns NIL will be good, can save us some coding.
Please review this, thanks.
Regards,
Chun Tian (binghe)
On Mon, Jul 21, 2008 at 7:22 PM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Erik
On SBCL (I'm using 1.0.18.x), HOST-TO-HBO cannot work for string:
- (usocket::host-to-hbo "localhost")
debugger invoked on a SB-KERNEL:CASE-FAILURE: #(127 0 0 1) fell through ETYPECASE expression. Wanted one of (INTEGER (VECTOR T 4) STRING).
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
This is because SBCL return #(127 0 0 1) as type (simple-array (unsigned-byte 8) (4)), it's not a subtype of (VECTOR T 4).
An solution is add more type to the ETYPECASE of HOST-TO-HBO: (and HOST-TO-VECTOR-QUAD)
Thanks for the report! Committed just a second ago (finally!).
I'll backport it to 0.4.x and 0.3.x. When there's enough 0.3.x material, I can do another release. However, I suppose you found this issue because of your UDP work?
Regards,
Erik.
On Mon, Jul 21, 2008 at 7:22 PM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Erik
On SBCL (I'm using 1.0.18.x), HOST-TO-HBO cannot work for string:
- (usocket::host-to-hbo "localhost")
debugger invoked on a SB-KERNEL:CASE-FAILURE: #(127 0 0 1) fell through ETYPECASE expression. Wanted one of (INTEGER (VECTOR T 4) STRING).
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
This is because SBCL return #(127 0 0 1) as type (simple-array (unsigned-byte 8) (4)), it's not a subtype of (VECTOR T 4).
An solution is add more type to the ETYPECASE of HOST-TO-HBO: (and HOST-TO-VECTOR-QUAD)
Thanks for the report! Committed just a second ago (finally!).
I'll backport it to 0.4.x and 0.3.x. When there's enough 0.3.x material, I can do another release. However, I suppose you found this issue because of your UDP work?
Thanks, and Yes.
Seems you have merged the new-wfi branch, I'll test these new trunk code soon.
Can I ask, when will you make the first 0.4.x release? Is there still anything to do?
--binghe
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.
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.
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).
Thanks for your continued interest!
Bye,
Erik.
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)
--binghe
On Sun, Jul 27, 2008 at 9:11 PM, Chun Tian (binghe) binghe.lisp@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.
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?
Sorry, cannot test it on Win64. I even do not have a Win64-installed computer:) LispWorks is per OS-platform licensed, I only have an LW64 enterprise license on AMD64 Linux.
--binghe
-
Chun Tian (binghe) -
Erik Huelsmann