Some recent changes to the Clozure CL trunk (starting with http://trac.clozure.com/ccl/changeset/13377) try to report nameserver errors in the socket-creation-error condition object.
Something like the crude attached patch would update the Clozure CL usocket backend to report these nameserver errors.
Hello RME
Thanks very much for bring us newest changes in Clozure CL. We'll merge your patch as soon as possible.
However I have a question, will your usocket patch work on Clozure CL versions early than the changeset/13377, for example, CCL 1.3 and 1.4? As our current policy is, support as many exist versions of each CLs as possible.
I tested your patch with CCL 1.4, didn't break the compilation, but I still want to listen from a CCL expert like you.
Regards,
Chun Tian (binghe)
在 2010-1-13，04:58， R. Matthew Emerson 写道：
Some recent changes to the Clozure CL trunk (starting with http://trac.clozure.com/ccl/changeset/13377) try to report nameserver errors in the socket-creation-error condition object.
Something like the crude attached patch would update the Clozure CL usocket backend to report these nameserver errors.
<ccl.patch>
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Hello RME
Thanks very much for bring us newest changes in Clozure CL. We'll merge your patch as soon as possible.
However I have a question, will your usocket patch work on Clozure CL versions early than the changeset/13377, for example, CCL 1.3 and 1.4? As our current policy is, support as many exist versions of each CLs as possible.
Well, after deep looking at the patch, I think the answer is YES.
Committed as r520 [1], thanks.
--binghe
[1] http://common-lisp.net/websvn/listing.php?repname=usocket&path=%2Fusocke...
I tested your patch with CCL 1.4, didn't break the compilation, but I still want to listen from a CCL expert like you.
Regards,
Chun Tian (binghe)
在 2010-1-13，04:58， R. Matthew Emerson 写道：
Some recent changes to the Clozure CL trunk (starting with http://trac.clozure.com/ccl/changeset/13377) try to report nameserver errors in the socket-creation-error condition object.
Something like the crude attached patch would update the Clozure CL usocket backend to report these nameserver errors.
<ccl.patch>
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
On Jan 13, 2010, at 4:52 AM, Chun Tian (binghe) wrote:
Hello RME
Thanks very much for bring us newest changes in Clozure CL. We'll merge your patch as soon as possible.
However I have a question, will your usocket patch work on Clozure CL versions early than the changeset/13377, for example, CCL 1.3 and 1.4? As our current policy is, support as many exist versions of each CLs as possible.
Well, after deep looking at the patch, I think the answer is YES.
Yes, that's right. It should continue to work back to at least CCL 1.3.
Committed as r520 [1], thanks.
Note that I'm not familiar with usocket---there may well be a better way.
For instance, the patch doesn't set the host-or-ip slot of the condition object to the host or ip address for which the lookup failed. (In fact, it just sets it to nil for lack of anything better).
Presumably this won't be an issue since the caller already knows what remote host it tried to connect to. One other possibility might be to handle ccl:socket-creation-error in get-host-by-address and get-hosts-by-name---that way the address or name would be lexically available to include in the ns-condition object.
Anyway, thanks. If there are bugs or omissions in CCL that affect usocket (or enhancements to CCL that would make it work better), please feel free to make tickets at http://trac.clozure.com/ccl
Hi, RME
在 2010-1-14，02:51， R. Matthew Emerson 写道：
Committed as r520 [1], thanks.
Note that I'm not familiar with usocket---there may well be a better way.
For instance, the patch doesn't set the host-or-ip slot of the condition object to the host or ip address for which the lookup failed. (In fact, it just sets it to nil for lack of anything better).
Presumably this won't be an issue since the caller already knows what remote host it tried to connect to. One other possibility might be to handle ccl:socket-creation-error in get-host-by-address and get-hosts-by-name---that way the address or name would be lexically available to include in the ns-condition object.
Yes you're right, the WITH-MAPPED-CONDITIONS / HANDLE-CONDITION interfaces didn't leave us a chance to pass the raw host/port data instead of a created usocket object, when the conditions throwing on socket creating. Considering this won't be a big issue as you already said, I think it's better to leave it as is, until we have a better condition passing design in the future. Touching GET-HOST-BY-NAME is not a perfect design, I think, as people may use this function separately and expecting the behavior like before.
On the other side, I'm living in China, in which any hostname is resolvable: ISP is hijacking DNS query packets so that every unsolvable hostname could be redirected to a default address for holding ISP's ads. Any way, I think I don't have any chance to test CCL's this new facility ...
--binghe
Anyway, thanks. If there are bugs or omissions in CCL that affect usocket (or enhancements to CCL that would make it work better), please feel free to make tickets at http://trac.clozure.com/ccl
-
Chun Tian (binghe) -
R. Matthew Emerson