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

[usocket-devel] BUG: dangling references to split-sequence package
by Andy Chambers 13 Jan '10

13 Jan '10

There is a dangling reference to split-sequence but split-sequence itself is no longer marked as a dependency in the defsystem spec. This means that usocket cannot currently be loaded using asdf unless split-sequence has already been loaded by some other system. The attached patch just replaces calls to split-sequence:split-sequence with corresponding calls to cl-utilities:split-sequence. Also I think a few of the tests might need to be rewritten. Both before and after applying this patch, 6 out of 15 tests fail for me. Regards, Andy Chambers (format t "type: ~a version: ~a" (lisp-implementation-type) (lisp-implementation-version)) type: SBCL version: 1.0.18.debian (usocket-test:run-usocket-tests) Doing 15 pending tests of 15 tests total. USOCKET-TEST::MAKE-SOCKET.1 USOCKET-TEST::MAKE-SOCKET.2 #<USOCKET:UNSUPPORTED {B075EB9}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.1 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT "127.0.0.0" USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B075EB9}>. #<USOCKET:UNSUPPORTED {B20A2B1}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.2 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT #(127 0 0 0) USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B20A2B1}>. #<USOCKET:UNSUPPORTED {B3A5D81}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.3 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT 2130706432 USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B3A5D81}>. #<USOCKET:UNSUPPORTED {B5461D9}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-FAILURE.1 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:NETWORK-UNREACHABLE-ERROR NIL) (USOCKET:SOCKET-CONNECT 2130706432 USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) :UNREACH) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B5461D9}>. #<USOCKET:UNSUPPORTED {B9C8229}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-FAILURE.2 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:HOST-UNREACHABLE-ERROR NIL) (USOCKET:SOCKET-CONNECT USOCKET-TEST::+NON-EXISTING-HOST+ 80 :TIMEOUT 0) :UNREACH) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B9C8229}>. USOCKET-TEST::SOCKET-CONNECT.1 USOCKET-TEST::SOCKET-CONNECT.2 USOCKET-TEST::SOCKET-CONNECT.3 USOCKET-TEST::SOCKET-STREAM.1 USOCKET-TEST::SOCKET-NAME.1 USOCKET-TEST::SOCKET-NAME.2 USOCKET-TEST::SOCKET-NAME.3 Test USOCKET-TEST::SOCKET-NAME.4 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS (NIL NIL) (LET ((USOCKET-TEST::SOCK (USOCKET:SOCKET-CONNECT USOCKET-TEST::+COMMON-LISP-NET+ 80))) (UNWIND-PROTECT (USOCKET:GET-LOCAL-ADDRESS USOCKET-TEST::SOCK) (USOCKET:SOCKET-CLOSE USOCKET-TEST::SOCK)))) Expected value: #(192 168 1 25) Actual value: #(192 168 0 3). 6 out of 15 total tests failed: USOCKET-TEST::SOCKET-NO-CONNECT.1, USOCKET-TEST::SOCKET-NO-CONNECT.2, USOCKET-TEST::SOCKET-NO-CONNECT.3, USOCKET-TEST::SOCKET-FAILURE.1, USOCKET-TEST::SOCKET-FAILURE.2, USOCKET-TEST::SOCKET-NAME.4. NIL CL-USER> -- ---- Andy Chambers Formedix Ltd

2 1

[usocket-devel] cl-utilities dependency
by Attila Lendvai 12 Jan '10

12 Jan '10

hi, any reason not depending on alexandria instead? cl-utilities with its split-sequence is a headache: it has a s-s but not a .asd file, so i can not drop the repo-less s-s in favor of cl-utilities. but if i keep them both, then it brainlessly redefines, which stops the build... -- attila

1 0

Re: [usocket-devel] [drakma-devel] Drakma - problem with http-request on SBCL 1.0.34
by Erik Huelsmann 08 Jan '10

08 Jan '10

Did we (usocket developers) miss a function argument? Chun, shouldn't we at least accept it? Bye, Erik. On Thu, Jan 7, 2010 at 9:33 PM, Fred Gibson <fred(a)streamfocus.com> wrote: > I've found a small problem in Drakma's http-request where in a call to > usocket:socket-connect it sent the key :nodelay which doesn't exist > for sbcl's socket connect version, so I changed that call in drakma to > this: > > (usocket:socket-stream > (usocket:socket-connect host port > :element-type 'octet > #+:openmcl :deadline > #+:openmcl deadline > #-:sbcl :nodelay > #-:sbcl t)) > > Then it seemed to work just fine. > > My best, > > Fred Gibson > > Founder / Software Developer > http://www.streamfocus.com > > (c)2010 Organon Technologies LLC > > _______________________________________________ > drakma-devel mailing list > drakma-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel >

3 4

Re: [usocket-devel] Multiprocess MCL usocket
by Chun Tian (binghe) 07 Jan '10

07 Jan '10

Committed as r514. Thanks very much. Your idea on using a lock is also useful for some other CLs, I think. --binghe 在 2010-1-7，01:13， Terje Norderhaug 写道： > Binghe, > > Below is an upgrade to the usocket MCL backend that allows a socket server to be shared between multiple processes. It adds a lock so only one process at a time polls for an established connection for the socket. > > (defclass passive-socket (socket) > ((streams :accessor socket-streams :type list :initform NIL > :documentation "Circular list of streams with first element the next to open") > (reuse-address :reader reuse-address :initarg :reuse-address) > (lock :reader socket-lock :initform (ccl:make-lock "Socket")))) > > (defmethod socket-accept ((socket passive-socket) &key element-type &aux (lock (socket-lock socket))) > (flet ((connection-established-p (stream) > (ccl::with-io-buffer-locked ((ccl::stream-io-buffer stream nil)) > (let ((state (ccl::opentransport-stream-connection-state stream))) > (not (eq :unbnd state)))))) > (with-mapped-conditions () > (ccl:with-lock-grabbed (lock nil "Socket Lock") > (let ((connection (shiftf (car (socket-streams socket)) > (socket-open-listener socket element-type)))) > (pop (socket-streams socket)) > (ccl:process-wait "Accepting" #'connection-established-p connection) > connection))))) > > > -- Terje Norderhaug > terje(a)in-progress.com > > > >

1 0

[usocket-devel] patches for usocket mcl backend and tests
by james anderson 06 Jan '10

06 Jan '10

good evening; please find attached patches for the mcl back-end and the tests. the system names follow from the local conventions for asdf systems, but the other changes should be generally useful. given these changes mcl 5.2 passes all 15. i cross-checked with openmcl ("Version 1.3-r11936 (DarwinPPC32)") which succeded as well. * test/test-usocket.lisp : added timeout arguments to the no-connect tests, as both mcl and openmcl otherwise hang : added mcl to the caught conditions for failure tests : wrapped typep tests to force t/nil : corrected #\newline to be #\linefeed : added a +local-ip+ variable * test/usocket-test.asd : changed dependencies to be fully qualified * usocket.asd : modified dependency to use cl-utilities (by fully qualified system name) * backend/mcl.lisp : handle-condition : corrected to formulate the error argument as required for the respective error class : socket-connect : reinstated with-mapped-conditions : socket-listen : reinstated with-mapped-conditions : socket-accept : reinstated with-mapped-conditions : %*-wait operators : added no-op versions

3 4

[usocket-devel] r507 : open-mcl : socket-connect scales the timeout value incorrectly
by james anderson 03 Jan '10

03 Jan '10

good evening; in the openmcl backend, socket-connect[1] converts the timeout value to internal runtime units, but (at least for a tcp connection) the respective ccl operator[2] intends to convert from seconds to milliseconds ---- [1] http://trac.common-lisp.net/usocket/browser/usocket/trunk/backend/ openmcl.lisp?rev=499#L89 [2] http://trac.clozure.com/ccl/browser/trunk/source/level-1/l1- sockets.lisp#L774 socket-connect -> make-socket -> make-ip-socket -> make-tcp-socket -> make-tcp-stream-socket

2 1

Re: [usocket-devel] [info-mcl] USOCKET?
by Chun Tian (binghe) 03 Jan '10

03 Jan '10

Hi, > On Jan 2, 2010, at 11:42 PM, Chun Tian (binghe) wrote: >> Your file has been committed into USOCKET trunk [1], and I'll use it as my work base. What you didn't implement is the WAIT-FOR-INPUT-INTERNAL function, which used to detect if there's anything available to read in a group of sockets (it's based on select() on UNIX). I'll try to investigate how MCL do this job if you don't have a quick solution. > > It seems like WAIT-FOR-INPUT-INTERNAL is like the CONNECTION-ESTABLISHED-P local function within SOCKET-ACCEPT in the usocket MCL backend draft that I sent you? Or is it more like LISTEN in Common Lisp? It's more like LISTEN, but it can listen on multiple connections at the same time. So, do you have any idea on how to implement it? And please notice: the WAIT-FOR-INPUT-INTERNAL should wait on "socket" but "stream", because that's what USOCKET API defined. And, more important, having that function wait on "sockets" could make the function also fit into usage of UDP sockets which doesn't have correspond stream objects. > > One important detail is that the MCL OpenTransport module establishes connections for passive streams on a port in a FIFO manner. That is, the first passive stream stream created with (ccl::open-tcp-stream NIL ...) will be the first to be connected. Hence you only have to test the top queued passive tcp stream for whether it is an established connection rather than poll all the streams in the socket. > > -- Terje

1 0

Re: [usocket-devel] [info-mcl] USOCKET?
by Chun Tian (binghe) 03 Jan '10

03 Jan '10

Hi, Terje USOCKET Support on MCL (at least RMCL) is already in my plan. There're some higher priority tasks on USOCKET side, like full support of SBCL and ECL on win32, etc., and every USOCKET maintainer is busy working on other projects (ABCL, BKNR, ...). So if MCL users can wait, I promise the MCL backend of USOCKET will be coming in *no later than a month*, or if someone here is interested in helping us, patches are most welcome. --binghe > Does somebody know of an MCL backend for the USOCKET portable tcp/ip > socket interface? > > http://common-lisp.net/project/usocket/ > > -- Terje Norderhaug > terje(a)in-progress.com > > > > > _______________________________________________ > info-mcl mailing list > info-mcl(a)clozure.com > http://clozure.com/mailman/listinfo/info-mcl

2 2

Re: [usocket-devel] ECL and MSVC
by Chun Tian (binghe) 02 Jan '10

02 Jan '10

Hi, there I just built out a ECL binary on MSVC, now I'm starting looking into this issue. ECL team maintains a really good code base on all supported platforms ... --binghe > Ive actually done that and hunchentoot displays nothing on the simple test > website. Oh well... Let me know how your test of the 'patch' goes... > > -----Original Message----- > From: Chun Tian (binghe) [mailto:binghe.lisp@gmail.com] > Sent: Tuesday, December 29, 2009 2:33 AM > To: Seth Burleigh > Subject: Re: [usocket-devel] ECL and MSVC > > As I know these test code never been used for long time, we're working on > bring them back ... > > I think you should use a real networking package which built upon USOCKET, > i.e. hunchentoot > > --binghe > > 在 2009-12-29，01:43， Seth Burleigh 写道： > >> Perhaps im doing these tests wrong since I really have never used sockets. >> All I did was load the usocket-test.asd and go (usocket:run-usocket-tests) >> If im reading the code right, it attempt to make a connection on 127.0.0.0 >> at port 15213 for the first test. Surely there has to be something > listening >> for it in order for it to receive it correctly? Using commview and the >> loopback sniffer, no activity is reported at 127.0.0.0. >> >> >> -----Original Message----- >> From: Chun Tian (binghe) [mailto:binghe.lisp@gmail.com] >> Sent: Monday, December 28, 2009 10:19 AM >> To: Seth Burleigh >> Subject: Re: [usocket-devel] ECL and MSVC >> >> Hi, Seth >> >> Thanks for these tests. I suggest you using WireShark (or something else >> eq. to "tcpdump") to try to capture if there's really IP packets sent out > by >> USOCKET functions. If USOCKET really send them, things should be easier >> then. >> >> --binghe >> >> 在 2009-12-28，23:26， Seth Burleigh 写道： >> >>> Hmm.. I tried testing it on clisp and ecl. On ecl it failed 13/15 times. >> On >>> clisp , currently, it has failed the first 3 tests with timeout errors. > I >>> even had clisp running with admin rights. Maybe it’s the firewall or my >>> win7 operating system. I"ll have to look into this deeper. >>> >>> -----Original Message----- >>> From: Chun Tian (binghe) [mailto:binghe.lisp@gmail.com] >>> Sent: Monday, December 28, 2009 8:48 AM >>> To: Seth Burleigh >>> Cc: usocket-devel(a)common-lisp.net >>> Subject: Re: [usocket-devel] ECL and MSVC >>> >>> Hi, Seth >>> >>> Sorry for the delay response. I still doesn't have a chance to try build > a >>> MSVC-based ECL by myself and test USOKET on it, but I think you're right. >>> However, after searching in MSDN, I found a better presentation: >>> >>> #include <time.h> >>> >>> That is, <time.h> instead of "time.h", better followed C programming >> style. >>> >>> Please give me two days try it by myself, and I'll merge it soon. >>> >>> Regards, >>> >>> Chun Tian (binghe) >>> >>> 在 2009-12-28，06:20， Seth Burleigh 写道： >>> >>>> So I searched for it, it looks like you just >>>> #+(and :ecl :msvc) #include “time.h” >>>> For a msvc build, I think, instead of just including “sys/time.h” >>>> >>>> Though im not sure, it builds, but I haven’t tried any tests. >>>> _______________________________________________ >>>> usocket-devel mailing list >>>> usocket-devel(a)common-lisp.net >>>> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel >>> >>> >> >> > >

1 1

[usocket-devel] ECL and MSVC
by Seth Burleigh 28 Dec '09

28 Dec '09

So I searched for it, it looks like you just #+(and :ecl :msvc) #include "time.h" For a msvc build, I think, instead of just including "sys/time.h" Though im not sure, it builds, but I haven't tried any tests.

2 1