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

[usocket-devel] Other issue on Clozure CL
by Faré 30 Mar '13

30 Mar '13

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.

1 0

[usocket-devel] patch for openmcl
by Faré 30 Mar '13

30 Mar '13

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

1 0

[usocket-devel] Fwd: Detecting whether the other end has closed my socket stream
by Roger Sen Montero 21 Mar '13

21 Mar '13

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(a)gmail.com> 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(a)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(a)gmail.com>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(a)gmail.com> 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(a)gmail.com >> >> _______________________________________________ >> usocket-devel mailing list >> usocket-devel(a)common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel >> >> > > -- > Roger Sen Montero > roger.sen(a)gmail.com > -- Roger Sen Montero roger.sen(a)gmail.com -- Roger Sen Montero roger.sen(a)gmail.com

1 0

Re: [usocket-devel] Detecting whether the other end has closed my socket stream
by Roger Sen Montero 21 Mar '13

21 Mar '13

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(a)gmail.com<javascript:_e({}, 'cvml', 'roger.sen(a)gmail.com');>> > 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(a)gmail.com <javascript:_e({}, 'cvml', 'roger.sen(a)gmail.com');> > > _______________________________________________ > usocket-devel mailing list > usocket-devel(a)common-lisp.net <javascript:_e({}, 'cvml', > 'usocket-devel(a)common-lisp.net');> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel > > -- Roger Sen Montero roger.sen(a)gmail.com

1 0

[usocket-devel] Detecting whether the other end has closed my socket stream
by Roger Sen Montero 13 Mar '13

13 Mar '13

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(a)gmail.com

1 0

[usocket-devel] test suite state
by Anton Vodonosov 07 Mar '13

07 Mar '13

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

2 1

[usocket-devel] fix for connection-stream external-format in CCL
by Vsevolod Dyomkin 19 Feb '13

19 Feb '13

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 @@ -97,6 +97,7 @@ :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))) @@ -107,6 +108,7 @@ :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

2 1

[usocket-devel] Add (socket-option ... :tcp-no-delay) for stream-usocket?
by Jan Moringen 14 Feb '13

14 Feb '13

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

2 2

[usocket-devel] [ANNOUNCE] usocket 0.6.0
by Chun Tian (binghe) 27 Dec '12

27 Dec '12

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 client For usage of SOCKET-OPTION and (SETF SOCKET-OPTION), please directly take a look at "option.lisp" from USOCKET source code. We'll add documentation later. (Unfortunately, not all CL platforms were full supported at current time, but we'll fix the missing part soon) As usual, if you want to download this release, please check http://common-lisp.net/project/usocket/releases/ or just wait for next Quicklisp monthly dist updates. The API documentation page was here (but I haven't updated it for SOCKET-OPTION yet ...): http://common-lisp.net/project/usocket/api-docs.shtml As usual, any feedback - bugs or hugs - is greatly appreciated. P. S. Something currently still in progress: * New feature: CLISP support some advanced TCP features which CLISP's SOCKET interface not provide * New feature: Macintosh Common Lisp (MCL) support Datagram sockets (UDP), based on OpenTransport. * New feature: SOCKET-SHUTDOWN for TCP and UDP sockets. Regards, Chun Tian (binghe) USOCKET Team

1 1

Re: [usocket-devel] [Ecls-list] [ANN] ECL 12.12.1 released
by Chun Tian (binghe) 10 Dec '12

10 Dec '12

Hi, For the known issue #2, I'm glad to report that USOCKET has been prepared for the bytecode compiler recently (but not released yet). I've confirmed that Hunchentoot could load and run its test site correctly in ECL/Windows without a C compiler. Now I'm going to release USOCKET 0.6.0 before Christmas, ECL users are very welcome to test USOCKET on trunk and report issues back. Regards, Chun Tian (binghe) Il giorno 08/dic/2012, alle ore 05:46, Juan Jose Garcia-Ripoll ha scritto: > Announcement of ECL > =================== > > ECL stands for Embeddable Common-Lisp. The ECL project aims to > produce an implementation of the Common-Lisp language which complies > to the ANSI X3J13 definition of the language. > > The term embeddable refers to the fact that ECL includes a lisp to C > compiler, which produces libraries (static or dynamic) that can be > called from C programs. Furthermore, ECL can produce standalone > executables from your lisp code and can itself be linked to your > programs as a shared library. > > ECL supports the operating systems Linux, FreeBSD, NetBSD, OpenBSD, > Solaris (at least v. 9), Microsoft Windows and OSX, running on top of > the Intel, Sparc, Alpha and PowerPC processors. Porting to other > architectures should be rather easy. > > ECL is currently hosted at SourceForge. The home page of the project > is http://ecls.sourceforge.net, and in it you will find source code > releases, a CVS tree and some useful documentation. > > > Known issues > ============ > > * Cygwin's library is still broken: fork/exec fails to reload the > cygwin library, or ECL's compiled libraries in a completely random > fashion. For this reason we recommend using ext:system instead of > ext:run-program in that platform. > > * In Windows ECL comes with bytecodes compiler by default, because C > compilers are normally not avaiable. Unfortunately several > libraries out there are not prepared for this. If you plan to use > quicklisp and have a C compiler accessible to ECL, you may use > (ext:install-c-compiler) to switch back to the Lisp-to-C compiler. > > > Changes since last release > ========================== > > Some highlights of this release are: > > * Lots of bugs fixed. > > * The MOP has been fixed to work with the upcoming release of > Closer-MOP > > * ECL now produces a much more readable C code, with indentation and > more explicit declarations of variables. > > See file src/CHANGELOG or browse it online > > http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup > > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d_______________________________________… > Ecls-list mailing list > Ecls-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list

1 0