headers
Faré | 17 Apr 2013 00:25
Picon
Gravatar

patch for Clozure CL

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
Attachment (0001-Clozure-CL-fixes.patch): application/octet-stream, 2948 bytes
Permalink | Reply | 3 comments |
headers
Mail Delivery Subsystem | 12 Apr 2013 02:39

Automated-response: Rejected e-mail

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

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@...>; 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@...>; Thu, 11 Apr 2013 17:39:17 -0700 (PDT)
X-Original-To: usocket-devel@...
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@...>; Thu, 11 Apr 2013 17:39:12 -0700 (PDT)
Received: from unknown (HELO 9bc) ([183.90.140.102])
	by 86.47.17.174 with ESMTP; Fri, 12 Apr 2013 01:39:25 -0000
Message-ID: <001c01ce3715$953f5640$b75a8c66 <at> home9126f627b99bc>
From: "Paula Torres" <tbwestley@...>
To: <usocket-devel@...>
Subject: Don't disappoint your girl at night
Date: Fri, 12 Apr 2013 01:30:02 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-2";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Stein | 4 Apr 2013 21:20
Favicon
Gravatar

Questions about exported symbols...


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 similar note, even given the whole list of WAITERS, I still need to use the unexpected STATE function to
get the waiting state of each socket.  I'd propose adding a predicate that checks whether the state is :READ
or :READ-WRITE.  Or, we export STATE?  Or some reader for that state?  Or some predicate that returns true if
the state is :READ?

I'll gladly work on the above and submit patches if there's consensus….

Thanks,
Patrick
Permalink | Reply | 2 comments |
headers
Faré | 30 Mar 2013 06:16
Picon
Gravatar

Other issue on Clozure CL

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.
Attachment (0001-Clozure-CL-add-missing-argument-to-to-format.patch): application/octet-stream, 1018 bytes
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 0 comments |
headers
Faré | 30 Mar 2013 03:39
Picon
Gravatar

patch for openmcl

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
Attachment (0001-Clozure-CL-When-waiting-for-multiple-inputs-don-t-er.patch): application/octet-stream, 1776 bytes
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 0 comments |
headers
Roger Sen Montero | 21 Mar 2013 23:48
Picon

Fwd: Detecting whether the other end has closed my socket stream

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@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 <at> cytochro.me>


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) is not raising the end of file condition.

(defun collect-input (socket buffer &optional (end-char 13))
  (loop :with stream = (usocket:socket-stream socket)
     :with byte
     :while (listen stream)
     :doing
     (setf byte (read-byte stream))
     (when (= byte end-char)
       (return t))
     (vector-push-extend byte buffer)))


Taking out the listen and changing it to

:while t

 raises the condition correctly when the connection is closed from client side, but then I'm unable to multiplex.



On Thu, Mar 21, 2013 at 1:00 AM, Roger Sen Montero <roger.sen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
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ó:

Hi Roger/all,

I wasn't able to reproduce this with my setup; I seem to get the end of file condition either way.

I'm using usocket 0.6.0.1 on sbcl 1.0.54.0-185b926 on Mac OS 10.7.5.

Can you provide your versions and/or a runnable test case?

On Mar 13, 2013, at 12:24, Roger Sen Montero <roger.sen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

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! 



--
Roger Sen Montero
roger.sen <at> gmail.com



--
Roger Sen Montero
roger.sen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 0 comments |
headers
Roger Sen Montero | 21 Mar 2013 01:00
Picon

Re: Detecting whether the other end has closed my socket stream

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ó:
Hi Roger/all,

I wasn't able to reproduce this with my setup; I seem to get the end of file condition either way.

I'm using usocket 0.6.0.1 on sbcl 1.0.54.0-185b926 on Mac OS 10.7.5.

Can you provide your versions and/or a runnable test case?

On Mar 13, 2013, at 12:24, Roger Sen Montero <roger.sen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

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! 


--
Roger Sen Montero
roger.sen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 0 comments |
headers
Roger Sen Montero | 13 Mar 2013 17:24
Picon

Detecting whether the other end has closed my socket stream

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!  
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 0 comments |
headers
Anton Vodonosov | 7 Mar 2013 02:36
Picon
Favicon

test suite state

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
Permalink | Reply | 1 comment |
headers
Vsevolod Dyomkin | 18 Feb 2013 18:26
Picon
Gravatar

fix for connection-stream external-format in CCL

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>
                                            :local-host (when local-host (host-to-hostname local-host))
                                            :local-port local-port
    :input-timeout timeout
+                                           :external-format ccl:*default-external-format*
                                            :format :binary))
               (usocket (make-datagram-socket mcl-sock)))
  (when (and host port)

Best,

Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved
_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Permalink | Reply | 1 comment |
headers
Jan Moringen | 13 Feb 2013 15:35

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

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
Permalink | Reply | 2 comments |

Gmane