I see that there is a recent change that means that client-as-string is called from create-request- handler-thread. This breaks for Lispworks users, as client-as-string is only defined for platforms that use usocket (or strictly speaking, for platforms which are not lispworks :-) The following implementation of client-as-string seems to do what's required for Lispworks: #+:lispworks (defun client-as-string (socket) "A helper function which returns the client's address and port as a string and tries to act robustly in the presence of network problems." (multiple-value-bind (address port) (comm:get-socket-peer-address socket) (when (and address port) (format nil "~A:~A" (comm:ip-address-string address) port))))
Thanks for the patch. I made a new release (1.2.18) containing the fix. -Hans On Fri, May 3, 2013 at 11:01 AM, Raymond Wiker <rwiker@gmail.com> wrote:
I see that there is a recent change that means that client-as-string is called from create-request- handler-thread. This breaks for Lispworks users, as client-as-string is only defined for platforms that use usocket (or strictly speaking, for platforms which are not lispworks :-)
The following implementation of client-as-string seems to do what's required for Lispworks:
#+:lispworks (defun client-as-string (socket) "A helper function which returns the client's address and port as a string and tries to act robustly in the presence of network problems." (multiple-value-bind (address port) (comm:get-socket-peer-address socket) (when (and address port) (format nil "~A:~A" (comm:ip-address-string address) port))))
participants (1)
-
Hans Hübner -
Raymond Wiker