gmane.lisp.usocket.devel

Re: Questions about exported symbols...

Patrick Stein — 2013-04-17T13:36:06

On 2013-04-17, at 2:55 AM, Chun Tian (binghe) wrote:


To me, I think the most reasonable would be to export WAIT-LIST-WAITERS and a SOCKET-READABLE-P function that returns whether the state is :READ or not.  Of course, it wouldn't be obvious that one has to WAIT-FOR-INPUT to make sure the SOCKET-READABLE-P is up-to-date.  Another approach might be to have WAIT-FOR-INPUT take a function to call on the readable sockets.  This would discourage anyone from disassociating the WAIT-FOR-INPUT and the READABLE state.

  (labels ((handle-socket-input (socket)
              … do something …))
    (wait-for-input my-wait-list :timeout 0 :ready-func #'handle-socket-input))

and inside WAIT-FOR-INPUT:

  (when ready-func
    (dolist (sock (wait-list-waiters socket-or-sockets))
      (when (eq (state sock) :read)
        (funcall ready-func sock)))

I could go either way….


I just noticed that each USOCKET instance tracks which WAIT-LIST (if any) it is part of.  I wasn't expecting that.  I was expecting to be abl

Re: patch for Clozure CL

Chun Tian (binghe — 2013-04-17T09:22:04

Hi again,

Thanks for clarifications.  I'll analyze your patch deeply, to see if other backends could learn something from your CCL work.

--binghe

On 2013-04-17, at 16:00, Faré <fahree-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: patch for Clozure CL

Faré — 2013-04-17T08:00:49

On Wed, Apr 17, 2013 at 3:50 AM, Chun Tian (binghe)
<binghe.lisp-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:
Yes, a combination of the two previous patches,
plus a third patch we use at work that I had previously failed to send
(signal vs error).

Looking forward to the results!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The main reason Santa is so jolly is because
he knows where all the bad girls live.

Re: Questions about exported symbols...

Chun Tian (binghe — 2013-04-17T07:55:51

Hi Patrick

Thanks for your suggestion.  I'll try to fix GET-HOST-BY-NAME for ECL to support non-Windows platforms soon.

I think it's reasonable to export more interfaces for WAIT-FOR-INPUT to make it more efficiency for advanced users, but some of exist symbols (i.e. STATE) may be too simple that it could be conflict with other packages or user application, therefore I'm thinking a prefix WFI- or just WAIT- for all these potential new exports. Do you have any suggestion?

Regards,

Chun Tian (binghe)

On 2013-04-05, at 3:20, Patrick Stein <pat-5H+6OO5gLOfQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: patch for Clozure CL

Chun Tian (binghe — 2013-04-17T07:50:42

Hi Faré

Thank you very much.  I've merged your latest patch, and I guess it's a combination of your previous two patch mails, right?

I'm a little busy (on commercial Lisp projects) these months, therefore I'm so sorry to usocket users that some bugs and feature requests cannot be handle quickly.  I'll hurry up from today and resolve all pending work before the end of this month and make a new release.  (On the other side, if any one want to maintain usocket together with me, it's more than welcome.  However, I myself do have some long-term dev plans, just haven't got time to implement …)

Regards,

Chun Tian (binghe)

On 2013-04-17, at 6:25, Faré <fahree-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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

Fwd: Detecting whether the other end has closed mysocket stream

Roger Sen Montero — 2013-03-21T22:48:46

Samuel,

 (forwarded to the mailing list also)

 Basically, as I understand the problem, is that lisp LISTEN does not
notify end of file/connection and characters avaiable in the same manner
READ-CHAR-NO-HANG (and the character stream system) does. LISTEN returns
false on char not available and end-of-file. READ-CHAR-NO-HANG (as well as
READLINE) uses conditions.

 So, my question is, is there any different way (using usockets) of
identifying when a non-char connection is closed?

 Thanks!




---------- Forwarded message ----------
From: Roger Sen Montero <roger.sen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Date: Thu, Mar 21, 2013 at 8:07 PM
Subject: Re: Detecting whether the other end has closed my socket stream
To: Samuel Edwin Ward <seward-aMouf+oUVTClnMjI0IkVqw< at >public.gmane.org>


Samuel,

 I have identified the issue to a call to a listen when waiting to read the
socket so I can multiplex multiple socket reading.

http://paste.lisp.org/display/136157

With the current code COLLECT-INPUT (listen stream)

Re: Detecting whether the other end has closed mysocket stream

Roger Sen Montero — 2013-03-21T00:00:31

Samuel,

 Let me create a simple test case from the current code and I'll post it
here.


El miércoles, 13 de marzo de 2013, Samuel Edwin Ward escribió:

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!

Re: test suite state

Chun Tian (binghe — 2013-03-07T02:21:02

Hi Anton

I'll try to improve the test results. (50% were real usocket bugs I think)

Thanks for reminding.

--binghe

Il giorno 07/mar/2013, alle ore 09:36, Anton Vodonosov <avodonosov-o+MxOtu4lMCHXe+LvDLADg< at >public.gmane.org> ha scritto:

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

Re: fix for connection-stream external-format in CCL

Chun Tian (binghe — 2013-02-19T05:29:27

Hi Vsevolod

Thank you for your suggestion.  Your patch has been applied to USOCKET trunk, and I'll release 0.6.1 (current version is actually 0.6.0.1) before the end of this month.

P. S. You can get latest USOCKET source code from SVN:

  svn://common-lisp.net/project/usocket/svn/usocket/trunk

Regards,

Chun Tian (binghe)

在 2013-2-19，1:26， Vsevolod Dyomkin 写道：



_______________________________________________
usocket-devel mailing list
usocket-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

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 >

Re: Add (socket-option ... :tcp-no-delay) for stream-usocket?

Jan Moringen — 2013-02-14T10:41:06

Thanks, I appreciate it very much.

Kind regards,
Jan

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

Chun Tian (binghe — 2013-02-14T09:15:13

Hi Jan

Thanks for your suggestion, the feature for :tcp-no-delay will be added soon and easily. I think at least CLISP/SBCL/Allegro/Clozure/LispWorks will be supported first, rest platforms may need some more investigations.   The only thing I haven't decided, is to use :TCP-NO-DELAY or just :NO-DELAY for the option name, depend on related exist feature provided by CLISP.

Regards,

Chun Tian (binghe)

Il giorno 13/feb/2013, alle ore 22:35, Jan Moringen <jmoringe-If1cxaH3S3JVgF+RW+Bo1SZEdBbF94EN< at >public.gmane.org> ha scritto:

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

Re: [ANNOUNCE] usocket 0.6.0

Chun Tian (binghe — 2012-12-27T03:22:21

Sorry … suddenly found that ECL actually has no 'sb-bsd-sockets:sockopt-broadcast, I've made a small fix to make sure it compiles in ECL correctly. So that's 0.6.0.1 now. I'll do more careful tests next time.

Il giorno 26/dic/2012, alle ore 23:59, Chun Tian (binghe) <binghe.lisp< at >gmail.com> ha scritto:

>