gmane.lisp.usocket.devel

patch for Clozure CL

Faré — 2013-04-16T22:25:51

This patch makes usocket work much better on CCL.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Pacifism is a shifty doctrine under which a man accepts the benefits of the
social group without being willing to pay — and claims a halo for his
dishonesty. — Robert Heinlein

Automated-response: Rejected e-mail

Mail Delivery Subsystem — 2013-04-12T00:39:27

Warning: Malicious content within your e-mail was detected by our system. The message did not reach the intended recipient. Please check the content of your message and try again. If you believe this was in error, please forward this e-mail to support-rGvcZsxnnNT9RPGrWp62eOG/Ez6ZCGd0< at >public.gmane.org

Original message's header:
Received: from mail.common-lisp.net ( [50.7.166.114])
        by mailproc1.acceleration.net (VMS) with ESMTP id XEZ18626
        for <ryan-rGvcZsxnnNT9RPGrWp62eA< at >public.gmane.org>; Thu, 11 Apr 2013 20:39:26 -0400
Received: from alpha-cl-net.common-lisp.net (localhost [127.0.0.1])
by mail.common-lisp.net (Postfix) with SMTP id 517B13568B6
for <ryan-rGvcZsxnnNT9RPGrWp62eA< at >public.gmane.org>; Thu, 11 Apr 2013 17:39:17 -0700 (PDT)
X-Original-To: usocket-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
Received: from 86.47.17.174 (86-47-17-174-dynamic.b-ras1.mgr.mullingar.eircom.net [86.47.17.174])
by mail.common-lisp.net (Postfix) with SMTP id 24125356782
for <usocket-devel-F1HGIaG5STRyXA

Questions about exported symbols...

Patrick Stein — 2013-04-04T19:20:04

I keep hoping that #'GET-HOST-BY-NAME will be exported from USocket.  In poking around trying to see how hard that would be, it looks to me like the only backend that doesn't currently support it is ECL.  And, that backend only supports ECL under Windows as it is.

If I spend some time getting GET-HOSTS-BY-NAME working for ECL on Windows (and other systems), can we make GET-HOSTS-BY-NAME a non-optional feature of the backends and export GET-HOST-BY-NAME and some of its friends?


Also, I just looked through WAIT-FOR-INPUT trying to see the most efficient way that I can employ that function.  It looks like if I used MAKE-WAIT-LIST, ADD-WAITER, and REMOVE-WAITER in my code, then I could pass the wait-list into WAIT-FOR-INPUT so it doesn't have to construct one itself.  That'd be nice.  All of those functions are exported, but WAIT-LIST-WAITERS is not.  So, I would still need to either maintain a separate copy of the WAITERS for myself or use the :READY-ONLY option.  Can we export WAIT-LIST-WAITERS?

On a simi

Other issue on Clozure CL

Faré — 2013-03-30T05:16:43

Patch attached.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Every four seconds a woman has a baby.
Our problem is to find this woman and stop her.
_______________________________________________
usocket-devel mailing list
usocket-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

patch for openmcl

Faré — 2013-03-30T02:39:25

Also, you might want to rename openmcl.lisp to clozurecl.lisp.

Also, you might want to move to git.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Each new generation born is in effect an invasion of civilization by little
barbarians, who must be civilized before it is too late. — Thomas Sowell
_______________________________________________
usocket-devel mailing list
usocket-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

Detecting whether the other end has closed mysocket stream

Roger Sen Montero — 2013-03-13T16:24:07

Hi all!!

 The FAQ states:

 Reading from a stream which has been closed at the remote end signals an
END-OF-FILE condition, meaning that reading from the stream and detecting
that condition is the way to do it.

 But when a create a server with:

 :element-type 'character

 I'm able to get an "Unexpected end of file" condition on the server side
when the client disconnect.

 Unfortunately, when I create the server with:

 :element-type 'unsigned-byte

 I do not get the condition, so I'm unable to detect when a client has
disconnected.

 Also, is there any plan to support utf8 streams directly without creating
unsigned-byte sockets and converting from/to string to string-utf-8-bytes?


 thanks!

test suite state

Anton Vodonosov — 2013-03-07T01:36:07

Hello.

I would like to draw your attention to the usocket test results
collected by test-grid: http://common-lisp.net/project/cl-test-grid/library/usocket.html

Are those failures are bugs in the testsuite, or real usocket bugs?
Or maybe testsuite needs some kind of configuration before running it?

Best regards,
- Anton

fix for connection-stream external-format in CCL

Vsevolod Dyomkin — 2013-02-18T17:26:34

HI,

I've noticed a problem in the CCL backend, when the socket is created not
with the default external-format but with NIL external-format which causes
the fallback to ISO-8859-1 and is rather unfortunate. What's even worse is
that it's very hard to alter the format, while initializing it
from ccl:*default-external-format* makes it possible to control this
parameter.

So here's a small change that solves the problem. It's against v.0.5.5, but
I've looked at the code for 0.6.1 and didn't see any change there. If
someone points me to the sources, I can make a proper patch.

diff -u openmcl-new.lisp openmcl.lisp
--- openmcl-new.lisp 2013-02-18 19:18:25.482382100 +0200
+++ openmcl.lisp 2013-02-18 19:16:24.586378860 +0200
< at >< at > -97,6 +97,7 < at >< at >
   :local-port local-port
   :format (to-format element-type)
   :deadline deadline
+  :external-format ccl:*default-external-format*
   :nodelay nodelay
   :connect-timeout timeout)))
  (make-stream-socket :stream mcl-sock :socket mcl-sock)))
< at >< at > -107,6 +108,7 < at >< at >

Add (socket-option ... :tcp-no-delay) forstream-usocket?

Jan Moringen — 2013-02-13T14:35:36

Hi,

I like the new socket-option functions and I think methods

        socket-option (stream-usocket (eql :tcp-no-delay))
        (setf socket-option) (t stream-usocket (eql :tcp-no-delay))

should be added.

This addition would enable stream sockets obtained from socket-accept to
operate with TCP_NODELAY. As far as I can see, this is currently not
possible without unportable code like

        (setf (sb-bsd-sockets::sockopt-tcp-nodelay (usocket::socket s)) t)

What do you think?

Kind regards,
Jan

[ANNOUNCE] usocket 0.6.0

Chun Tian (binghe — 2012-12-26T15:59:17

Dear Lispers,

We're glad to announce the USOCKET 0.6.0 release.

Changes in this release:

* New feature: SOCKET-OPTION and (setf SOCKET-OPTION) for seting and geting various socket options.
* New feature: SOCKET-SEND now support an CCL-like OFFSET keyword for sending only parts of the whole buffer.
* New feature: [ECL] Added support for ECL DFFI mode on Windows. (no need for C compilers now)
* Bugfix: [ECL] ECL now list sb-bsd-sockets as a dependency but relies on REQUIRE. (patched by Juanjo)
* Bugfix: [ABCL] Make USOCKET compile warning-free on ABCL again: MAKE-IMMEDIATE-OBJECT was deprecated a while ago in favor of 2 predefined constants.
* Bugfix: [LispWorks] remove redundant call to hcl:flag-special-free-action. (reported by Kamil Shakirov)
* Bugfix: [CLISP] improved HANDLE-CONDITION for more CLISP environments.

For the new API, SOCKET-OPTION, initially we support following options:

* RECEIVE-TIMEOUT (SO_RCVTIMEO)
* REUSE-ADDRESS (SO_REUSEADDR), for TCP server
* BROADCAST (SO_BROADCAST), for UDP clie

Patches for ECL

Juanjo — 2012-11-18T01:10:23

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

test regressions on CLISP

Anton Vodonosov — 2012-07-17T22:37:25

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/bl

[patch] LispWorks6.1 backend fixes

Kamil Shakirov — 2012-04-17T08:30:10

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'.

[ANNOUNCE] usocket 0.5.5

Chun Tian (binghe — 2012-02-27T15:22:53

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-9+yMRgOv7naakBO8gow8eQ< at >public.gmane.org>

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

CLISP condition system change

Vladimir Sedach — 2012-02-17T01:09:25

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

new release?

Anton Vodonosov — 2012-02-13T00:06:42

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-3932531

Best regards,
- Anton

Problem in Lispworks 6.1

William P. Proffitt — 2012-02-03T22:14:11

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

more convenient :nodeay option - :if-supported

Anton Vodonosov — 2012-01-20T22:23:31

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

Unit tests failures on different lisps

Anton Vodonosov — 2011-12-28T23:07:23

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

patch: adding remote-host remote-port to socket-server stream handler functions

Matthew Curry — 2011-11-10T18:41:13

Hi all:

I had a need to know the remote socket and port for a tcp connection,
however the socket-server handler function did not have *remote-host*
and *remote-port* set (oddly it does set these for datagram sockets).
socket-server is mostly what I want, save this feature, which I have
modified the sources locally.

If it's alright with the devs, could this simple patch be committed to
the server.lisp file in the usocket tree?

Thanks,

-Matt
83c83,84
<                                (apply function (socket-stream client-socket) arguments)
---
_______________________________________________
usocket-devel mailing list
usocket-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

[ANNOUNCE] usocket 0.5.4

Chun Tian (binghe — 2011-10-01T15:04:00

Hi, Common Lispers

This is a new cumulative update release for USOCKET, version 0.5.4

Changes in this version:

* Bugfix: [ECL] Fixed for ECL's MAKE-BUILD by removing some unecessary code (reported by Juan Jose Garcia-Ripoll, the ECL maintainer)
* Bugfix: [ACL] Fixed for Allegro CL modern mode. (by Hans Hübner)
* Bugfix: [SBCL] SOCKET-CONNECT on TCP won't call bind() when keyword arguments LOCAL-HOST and LOCAL-PORT is not set. (reported by Robert Brown)

Special thanks (again) to:

Robert Brown <robert.brown< at >gmail.com>

for his reporting and patching on a big bug in SBCL's SOCKET-CONNECT function, which have unnecessary bind() calls previously.

If you want to download this release, please checkout

http://common-lisp.net/project/usocket/releases/

or just wait for new Quicklisp releases.

The API documentation page is still here:

http://common-lisp.net/project/usocket/api-docs.shtml

As usual, any feedback - bugs or hugs - is greatly appreciated,

Regards,

Chun Tian (binghe)
Glority Software Ltd.

P