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

[usocket-devel] Patches for ECL
by Juanjo 18 Nov '12

18 Nov '12

Here https://dl.dropbox.com/u/23177754/usocket-ecl-patches-2012-11-18.patch you will find several fixes for usocket that improve integration with ECL. The problem is that usocket does not list sb-bsd-sockets as a dependency, but rather relies on REQUIRE. This makes it impossible to build standalone applications because they will crash when looking for the files associated to sb-bsd-sockets. Instead, with the current fix, ASDF is now capable of detecting that the library needs sb-bsd-sockets and link the program with it. Juanjo

2 1

[usocket-devel] test regressions on CLISP
by Anton Vodonosov 20 Jul '12

20 Jul '12

There are test regressions between quicklisp 2012-07-03 and quicklisp 2012-05-20 on CLISP. Failed tests cases: clisp-2.49-win: quicklisp 2012-07-03:connection-refused-error.1 ns-host-not-found-error.1 operation-not-permitted-error.1 timeout-error.1 udp-send.1 udp-send.2 wait-for-input.3 quicklisp 2012-05-20: ns-host-not-found-error.1 operation-not-permitted-error.1 timeout-error.1 udp-send.1 udp-send.2 wait-for-input.3 clisp-2.49-unix: quicklisp 2012-07-03: connection-refused-error.1 ns-host-not-found-error.1 operation-not-permitted-error.1 socket-failure.1 socket-failure.2 socket-no-connect.1 socket-no-connect.2 socket-no-connect.3 timeout-error.1 udp-send.1 udp-send.2 wait-for-input.3 quicklisp 2012-05-20: ns-host-not-found-error.1 operation-not-permitted-error.1 socket-failure.1 timeout-error.1 udp-send.1 udp-send.2 wait-for-input.3 Log files (in the same order): http://cl-test-grid.appspot.com/blob?key=216013 http://cl-test-grid.appspot.com/blob?key=170032 http://cl-test-grid.appspot.com/blob?key=190086 http://cl-test-grid.appspot.com/blob?key=167051

2 2

[usocket-devel] [patch] LispWorks6.1 backend fixes
by Kamil Shakirov 25 Apr '12

25 Apr '12

Hello, The attached patch removes redundant call to hcl:flag-special-free-action (on usocket) and replaces 'lispworks6.0' feature keyword with more general 'lispworks6' - LispWorks6.1 only defines 'lispworks6' and 'lispworks6.1'. -- --ska

2 2

[usocket-devel] [ANNOUNCE] usocket 0.5.5
by Chun Tian (binghe) 27 Feb '12

27 Feb '12

Hello, I'm sorry for the late release of new USOCKET updates, but here is the version 0.5.5 Changes in this release: * Enhancement: SOCKET-CONNECT argument :nodelay can now set to :if-supported (patch from Anton Vodonosov). * Enhancement: [server] adding *remote-host* *remote-port* to socket-server stream handler functions (suggested by Matthew Curry) * Bugfix: [LispWorks] Fixed UDP support for LispWorks 6.1 (patch from Camille Troillard by Martin Simmons). * Bugfix: [LispWorks] Stop using hcl:add-special-free-action for reclaiming unused UDP socket fds to improve multi-threading stablity (suggested by Camille Troillard). * Bugfix: [LispWorks] Fixed SOCKET-CONNECT on Windows, now LOCAL-PORT never have *auto-port* (0) as default value. Special thanks to LispWorks official, Martin Simmons <martin(a)lispworks.com> whom provided the patch for LispWorks 6.1 compatibility. (And with LispWorks 6.1 released with IPv6 support, now I'm seriously considering USOCKET should also start to support IPv6 in next major release) If you want to download this release, please check http://common-lisp.net/project/usocket/releases/ or just wait for next Quicklisp releases. The API documentation page was slightly updated for the new (:NODELAY :IF-SUPPORTED) support in SOCKET-CONNECT: http://common-lisp.net/project/usocket/api-docs.shtml As usual, any feedback - bugs or hugs - is greatly appreciated. (Due to my recent heavy and hard work on my local Lisp job -- porting a very big commercial Lisp application from single-threaded to multi-threaded model, I'm very sorry that I don't know enough time to release USOCKET 0.6.0 before the end of February, so I decide to release 0.5.5, the last 0.5.x series release. Once I've got my job stabilized again on mid next month, I'll start pushing more work on USOCKET, I promise) Best Regards, Chun Tian (binghe) Gensym Release Owner

1 0

[usocket-devel] CLISP condition system change
by Vladimir Sedach 17 Feb '12

17 Feb '12

Hi, In the repository version of CLISP, there's been some changes to the condition class hierarchy. usocket/backend/clisp.lisp line 685 reads: (system::simple-os-error Changing that to: (ext:os-error Should work for the current version (2.49 - simple-os-error inherited from os-error and the usocket condition argument accessors are otherwise generic) and the upcoming CLISP version. Vladimir

2 2

[usocket-devel] new release?
by Anton Vodonosov 13 Feb '12

13 Feb '12

Hello usocket developers. Do you think it's possible to make new usocket release before the next qucklisp update (till the end of February)? New release is desirable because it will allow drakma to run on CLISP, CMUCL and SCL by supporting the :nodelay :if-supported value. New drakma using this value is already included into quicklisp, but the usocket is not yet as it wasn't released. https://github.com/quicklisp/quicklisp-projects/issues/268#issuecomment-393… Best regards, - Anton

2 1

Re: [usocket-devel] Unit tests failures on different lisps
by Anton Vodonosov 05 Feb '12

05 Feb '12

Hello. You are right, CCL was just unable to load the library (It was sufficient for me to jus trun svn update of my CCL 1.7 distro; looks like previously my distribution was somehow incomplete - didn't have cdb files). Now the CCL 1.7 test results for usocket are exactly like results of CCL 1.6: 3 out of 24 total tests failed: USOCKET-TEST::OPERATION-NOT-PERMITTED-ERROR.1, USOCKET-TEST::UDP-SEND.1, USOCKET-TEST::UDP-SEND.2. Best regards, - Anton 04.02.2012, 14:45, "Chun Tian (binghe)" <binghe.lisp(a)gmail.com>: > Hi, Anton > > Today I've verified this issue, I think the issue you met is because you didn't set environment variable CCL_DEFAULT_DIRECTORY for CCL 1.7 properly. USOCKET need to use a Windows system function called "send", and to have this function, CCL will load its definition at runtime (when it's reading the form #_send), by loading a file called "win32-headers/libc/functions.cdb" (or in win64-headers). If CCL cannot find this file, it will not create the symbol WIN64::|send| at all. > > Hope this helps, > > Regards, > > Chun Tian (binghe) > > 在 2011-12-29，10:29， Anton Vodonosov 写道： > >> 29.12.2011, 03:07, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>> Some of the failures are probably bugs in tests, but other seems to be bugs in usocket itself. >>> For example CCL on Windows: >>> >>> Read error between positions 195 and 295 in C:/Users/anton/quicklisp/dists/quicklisp/software/usocket-0.5.4/vendor/ccl-send.lisp. >>> Unhandled ERROR is signaled: Foreign function not found: WIN64::|send| >> BTW, this particular error seems to be a regression on CCL 1.7 Windows. >> >> I just added test results for more CCL versions. You may compare CCL windows version: >> 1.7 64bit and 32bit have this error, but 1.6 64bit does not. >> >> _______________________________________________ >> usocket-devel mailing list >> usocket-devel(a)common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

1 0

[usocket-devel] Problem in Lispworks 6.1
by William P. Proffitt 04 Feb '12

04 Feb '12

Hello, I am getting a "#<USOCKET:TIMEOUT-ERROR 22CF0FAC>". In Lispworks 6.1 Professional, while using cl-smtp to send email. The issue appears to come from the "socket-connect" function in lispworks.lisp of usocket 0.5.4. Thanks, William

2 1

[usocket-devel] Unit tests failures on different lisps
by Anton Vodonosov 28 Jan '12

28 Jan '12

Hello. I am running the usocket tests (between others often-downloaded quicklisp libraries), on different lisps. The tests have different failures on different lisps. The results may be found here: http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html (the ok/fail links refer to the test logs with failure details). Some of the failures are probably bugs in tests, but other seems to be bugs in usocket itself. For example CCL on Windows: Read error between positions 195 and 295 in C:/Users/anton/quicklisp/dists/quicklisp/software/usocket-0.5.4/vendor/ccl-send.lisp. Unhandled ERROR is signaled: Foreign function not found: WIN64::|send| The variables described in README to configure the test suite - +non-existing-host+, +unused-local-port+, +common-lisp-net+ - have satisfying values (the defaults), and does not seem to be the failure cause for the failed tests. Best regards, - Anton

2 2

[usocket-devel] more convenient :nodeay option - :if-supported
by Anton Vodonosov 20 Jan '12

20 Jan '12

Hello. Today socket-connect option :nodelay if specified accepts T or NIL. And whatever value is passed, socket-connect signals the UNSUPPORTED exception on implementations where it is not possible to control the socket no-delay property. This dooms any usocket-using code which wishes to use :nodelay to be broken on implementations where it is not implemented (e.g. CLISP, CMUCL, ...). I think in most cases users would prefer "no delay if possible, otherwise just work as you can" behavior. For example drakma. On the implementations where it is possible, it will have maximum performance by specifying no-delay. But on other implementations it is desirable to work on usual socket. To support this in backward-compatible fashion I propose to introduce another value for the :nodelay option. :nodelay :if-supported. The meaning is obvious. Please see the patch attached. It is tested (by changing drakma to use :nodelay :if-supported) on all the implementations available to me: Allegro, CCL, CLISP, SBCL. Can't test on ECL and ABCL because of other obstacles (the last public release of ECL can't comile babel, and ABCL can't load cffi). Best regards, - Anton

2 1