- usocket-devel - mailman3.common-lisp.net

Re: [usocket-devel] Something about usocket-udp on Clozure CL
by Chun Tian (binghe) 09 Jul '10

09 Jul '10

Hi, Alex I'm glad to tell you. I've fixed the USOCKET/Clozure USOCKET:SEND-TO issue. Now you can call SOCKET-SEND on connected usockets. However, the work was committed on USOCKET trunk [1], not USOCKET-UDP. I want to mark USOCKET-UDP as a outdated package, and encourage people switching to USOCKET project. And current USOCKET trunk will be released as version 0.5 in short future. For your project, it's very easy to do this switch: replace the "USOCKET-UDP" into "USOCKET" in your ASDF files, and change function call "SOCKET-CONNECT/UDP" into just "SOCKET-CONNECT". But, you should tell your user checkout USOCKET trunk until its next release. Is this working for you? Regards, Chun Tian (binghe) [1] svn://common-lisp.net/project/usocket/svn/usocket/trunk > Hi Chun, > > Thanks for answering me. Regarding the patch, i don't think i can even call it that, i just noticed that 'USOCKET:SOCKET-SEND (on clozure) always calls 'HOST-TO-HBO with the 'HOST parameter, which in my case was NIL, so i simply added a check there, i don't even know if i'm breaking some kind of expected behavior but i hope not. The patch is now *really* attached. > > For the second issue, i meant that on USOCKET/Clozure USOCKET:SEND-TO does not work on *connected* sockets. > > > Cheers, > > Alex > > > Quoting "Chun Tian (binghe)" <binghe.lisp(a)gmail.com>: > >> Hi, Alex >> >> Sorry for the late response. I'm a little busy. >> >> So, a new Common Lisp package (cl-growl) is using my USOCKET-UDP, that's a news for me. The Common Lisp UDP "market" is relatively small, only few users I have. I hope this new package will make the UDP package better. >> >> I wrote USOCKET-UDP mainly for my SNMP package (cl-net-snmp). At that time, USOCKET doesn't have UDP support, so I wrote USOCKET-UDP as a patch to exist USOCKET package. From one year ago, I became one of USOCKET maintainers, and current USOCKET trunk have merged all my UDP work, plus the new Digitool MCL port. Unfortunately, due to the lack support of SBCL and ECL on Windows platform, we haven't release the new USOCKET version for long time. Above is the background. >> >> For your first issue, I would like to see your patch on the HOST-TO-HBO part, first. (You didn't attach it with your mail actually) >> >> For your second issue, I don't quite understand your points. Are you saying USOCKET/Clozure currently cannot support SOCKET-SEND on "connected socket" or "unconnected socket"? >> >> I'm sure all bugs in USOCKET-UDP are fixable since we have all Clozure CL source code in hand to see the bahaviour of their internal functions. >> >> Wait for your next post. >> >> Regards, >> >> Chun Tian (binghe) >> >> >>> Hi, just recently i installed a Lisp library that uses your library usocket-udp, so, first let me thank you for you work on that library. >>> >>> I've had a few problems running a project (cl-growl) that uses your library. >>> >>> First on clozure's 'socket-send definition there's a call to 'host-to-hbo that should have a check for nil being passed as host. This was the first error i kept getting. I simply added a small check (patch is attached) which solved the problem. >>> >>> But the biggest problem i found concerns the fact that some implementations (namely SBCL) work with UDP Connected sockets while Clozure CL's implementation for instance will break. On calls to 'socket-send Clozure will be calling 'openmcl-socket:send-to which is basically a wrapper call for the C function sendto() which will (accordingly to the function documentation) return an EISCONN (56) complaining the socket is already connected. This behavior imho seems to break the 'unified' behavior the library attempts to achieve. >>> >>> I have no idea what the best path for achieving this unified behavior should be but i felt it was my obligation to let you know of these issues. >>> >>> >>> Sorry for the big post, >>> >>> Alex Paes >>> >>> >>> >> >> > > > <usocket.patch>

1 0

[usocket-devel] undefined functions
by Haris Bogdanović 07 Jul '10

07 Jul '10

When I try to load hunchentoot with asdf I get this errors: ; Undefined functions: ; USOCKET::%ADD-WAITER USOCKET::%REMOVE-WAITER USOCKET::%SETUP-WAIT-LIST USOCKET::WAIT-FOR-INPUT-INTERNAL When I try to load usocket with asdf I get: WARNING: wait-for-input not (yet!) supported... and when I try to start hunchentoot with: (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 8000)) I get: The function USOCKET::%SETUP-WAIT-LIST is undefined. [Condition of type UNDEFINED-FUNCTION] What can I do, I can't start hunchentoot ? I use emacs/sbcl/slime on windows. Thanks

3 6

[usocket-devel] Problem with :ready-only
by Daniel Weinreb 29 Jun '10

29 Jun '10

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 this argument exists; no caller seems to pass it at all! What's going on here? Thanks. -- Dan

2 5

[usocket-devel] [Patch]: Clisp can't find gethostname on Linux
by Stas Boukarev 28 Jun '10

28 Jun '10

I attached a patch which allows Clisp to find gethostname on Linux. -- With Best Regards, Stas.

2 1

[usocket-devel] SBCL timeouts
by Pavel G. Koukoushkin 28 Jun '10

28 Jun '10

Hi! I do some corrections in a patch an here is it. Please answer where we can see this changes in release Pavel G. Koukoushkin Moscow, Russia

2 2

[usocket-devel] wait-for-input
by Daniel Weinreb 28 Jun '10

28 Jun '10

Hi. I just tried out the latest usocket, and found that wait-for-input does not work properly. To fix it, I changed the default value of the :read-only parameter from nil to t. What's going on with the :read-only parameter? No function in usocket passes this argument to wait-for-input. [Sorry if this is a duplicate email.]

1 0

[usocket-devel] %SETUP-WAIT-LIST is undefined
by Haris Bogdanović 26 Jun '10

26 Jun '10

Hi. When I try to start hunchentoot with: "(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 8000))" I get: "USOCKET::%SETUP-WAIT-LIST is undefined" ? What is the problem here ? I hope this mailng list is for asking questions from users. Thanks

2 1

[usocket-devel] USOCKET::%SETUP-WAIT-LIST is undefined
by Haris Bogdanović 26 Jun '10

26 Jun '10

Hi. When I try to start hunchentoot with: "(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 8000))" I get: "USOCKET::%SETUP-WAIT-LIST is undefined" ? What is the problem here ? I hope this mailng list is for asking questions from users. Thanks

1 0

[usocket-devel] Timeouts for sbcl
by Pavel G. Koukoushkin 24 Jun '10

24 Jun '10

Hi all! sb-bsd-sockets:socket-make-stream can get an :timeout keyword. And it is works! I think it must be used in sbcl backend in socket-connect function here is a patch *** usocket-0.4.1.orig/backend/sbcl.lisp 2010-05-06 14:26:15.000000000 +0400 --- usocket-0.4.1/backend/sbcl.lisp 2010-06-24 19:13:37.000000000 +0400 *************** *** 208,214 **** (sockopt-tcp-nodelay-p (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay))) (when deadline (unsupported 'deadline 'socket-connect)) - (when timeout (unsupported 'timeout 'socket-connect)) (when (and nodelay-specified ;; 20080802: ECL added this function to its sockets ;; package today. There's no guarantee the functions --- 208,213 ---- *************** *** 224,229 **** --- 223,229 ---- (sb-bsd-sockets:socket-make-stream socket :input t :output t + :timeout timeout :buffering :full :element-type element-type)) ;;###FIXME: The above line probably needs an :external-format Thanks a lot! Pavel G. Koukoushkin Moscow, Russia

1 0

[usocket-devel] wait-for-input does not work
by Daniel Weinreb 04 May '10

04 May '10

Hi. I just tried out the latest usocket, and found that wait-for-input does not work properly. To fix it, I changed the default value of the :read-only parameter from nil to t. What's going on with the :read-only parameter? No function in usocket passes this argument to wait-for-input. Thanks. -- Dan

1 0