usocket-devel

usocket-devel@common-lisp.net

248 discussions

Re: [usocket-devel] [hunchentoot-devel] Hunchentoot on CLISP
by Hans Hübner 28 Feb '11

28 Feb '11

On Mon, Feb 28, 2011 at 4:19 AM, Andrew Pennebaker <andrew.pennebaker(a)gmail.com> wrote: > The "New York version" (hunchentoot:start (make-instance > 'hunchentoot:acceptor :port 4242)) > creates a stalling web server, never loading, never error'ing. > When I remove the code :ready-only t from line 377: > (when (usocket:wait-for-input listener :timeout +new-connection-wait-time+) > The New York version works fine. > Specs: > > Hunchentoot 1.1.1 > Quicklisp > CLISP > Mac OS X This sounds like a bug in CLISP or usocket. Usocket guys, do you know something about READY-ONLY on CLISP? -Hans

1 0

[usocket-devel] stack overflow installing usocket
by Mario Maio 05 Feb '11

05 Feb '11

I was trying to follow the steps found in http://www.adampetersen.se/articles/lispweb.htm, but I'm not able to install usocket using quicklisp in my Windows 7 / Emacs / CLISP environment, this is what happens in Emacs: CL-USER> (ql:quickload "usocket") ; Fetching #<URL "http://beta.quicklisp.org/dist/quicklisp/2011-01-10/systems.txt"> ; 78.15KB ================================================== 80,026 bytes in 1.29 seconds (60.67KB/sec) ; Fetching #<URL "http://beta.quicklisp.org/dist/quicklisp/2011-01-10/releases.txt"> ; 111.77KB ================================================== 114,451 bytes in 0.29 seconds (388.06KB/sec) To load "usocket": Install 1 Quicklisp release: usocket ; Fetching #<URL "http://beta.quicklisp.org/archive/usocket/2011-01-10/usocket-20110110-svn.t…"> ; 54.77KB ================================================== 56,082 bytes in 0.35 seconds (157.37KB/sec) ; Loading "usocket" [package usocket].. *** - Program stack overflow. RESET ;; swank:close-connection: NIL [2]> I might have done any stupid mistake, I'm a CLISP/Emacs newbie. Any help is appreciated. Thanks in advance.

1 0

[usocket-devel] "principle of least surprise"
by James Ashley 02 Feb '11

02 Feb '11

This stupid-simple patch lets you pass a wider variety of address specifications into socket-listen (Clozure's make-socket seems to require either an int or a string address). Well, I think it does, and I don't think it has much performance implications. But I'm a CL noob, and I won't pretend to know all that much about socket programming, so I could be totally wrong about this. Thanks, James --- backend/openmcl.lisp~ 2011-01-13 18:57:39.000000000 -0600 +++ backend/openmcl.lisp 2011-01-30 10:11:39.000000000 -0600 @@ -118,6 +118,7 @@ (backlog 5) (element-type 'character)) (let* ((reuseaddress (if reuse-address-supplied-p reuse-address reuseaddress)) + (real-host (host-to-hostname host)) (sock (with-mapped-conditions () (apply #'openmcl-socket:make-socket (append (list :connect :passive @@ -126,7 +127,7 @@ :backlog backlog :format (to-format element-type)) (when (ip/= host *wildcard-host*) - (list :local-host host))))))) + (list :local-host real-host))))))) (make-stream-server-socket sock :element-type element-type))) (defmethod socket-accept ((usocket stream-server-usocket) &key element-type)

2 1

[usocket-devel] ECL's DFFI (was Re: [Ecls-list] [ANN] ECL 11.1.1)
by Chun Tian (binghe) 17 Jan '11

17 Jan '11

Seems we should start research how to port exist ECL support code into DFFI as an additional feature, by detecting the #+DFFI feature. Any comment? > 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 git/CVS tree and some useful documentation. > > Known issues > ============ > > ECL's dynamic FFI (the one that does not rely on a C compiler) is now > implemented using libffi (See http://sourceware.org/libffi/). Until > another release in which the library might be bundled together with > ECL, users will have to make sure that this library is built and > available for this feature to be linked in (#+dffi). Otherwise only > the C-based foreign function interface will be available. > > Changes since last release > ========================== > > See file src/CHANGELOG or browse it online > > http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markup > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl_________________________________________… > Ecls-list mailing list > Ecls-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list

1 0

[usocket-devel] UDP receive timeout parameter (LispWorks)
by Kamil Shakirov 08 Dec '10

08 Dec '10

Hi List, As datagram socket-receive generic function allows to pass extra key parameters, would it be possible to add extra timeout parameter for LispWorks backend? The attached patch adds this feature. --ska

2 4

[usocket-devel] [patch] enable concurrent recv/send on mutiple UDP sockets in LispWorks 6.0
by Kamil Shakirov 08 Dec '10

08 Dec '10

Hello List, I had a hard time figuring out why my app running on LispWorks 6.0 couldn't receive and send messages via multiple UDP sockets concurrently until I discovered that a global lock was used on global recv/send buffers. Is there any reason why global recv/send buffers are used? The attached patch fixes the problem. Tested with LispWorks 6.0. --ska

2 3

[usocket-devel] Overview
by Simon Friedberger 26 Nov '10

26 Nov '10

Hello everybody, I'm looking for an overview or introduction on how to use usocket. I've hacked something up that seems to work but I'm not really clear on how things are supposed to be set up or torn down. I also don't really know what happens in case of a connection loss or other errors. Is there an abstract description of usockets behavior in these cases somewhere? Best regards Simon

1 0

Re: [usocket-devel] Wait-for-input/socket-accept for sbcl/win32
by Anton Vodonosov 07 Oct '10

07 Oct '10

Hello. Dmitry, I've tried the patch. It works, but not always. Sometimes I get this error: Socket error in "accept": 0 (Operaction completed successfully.) [Condition of type SB-BSD-SOCKETS:SOCKET-ERROR] Backtrace: 0: (SB-BSD-SOCKETS:SOCKET-ERROR "accept") 1: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-ACCEPT (SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument> #<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:4242, fd: 9 {248303C9}>) 2: ((SB-PCL::FAST-METHOD USOCKET:SOCKET-ACCEPT (USOCKET:STREAM-SERVER-USOCKET)) #<unavailable argument> #<unavailable argument> #<USOCKET:STREAM-SERVER-USOCKET {248309F9}>)[:EXTERNAL] 3: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>) 4: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK365]370)) 5: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 6: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 7: (SB-THREAD::CALL-WITH-MUTEX ..) 8: (SB-THREAD::INITIAL-THREAD-FUNCTION) I am testing it by running hunchentoot-1.1.0 on windows, with the recent SBCL+threads (the binay downloaded from http://dmitry-vk.livejournal.com/34529.html?thread=135905#t135905). I am not really sure if it's a bug in Usocket, or in SBCL. Best regards, - Anton

1 0

[usocket-devel] A IOlib backend of USOCKET?
by Chun Tian 05 Oct '10

05 Oct '10

Hi, I'm thinking of writing a IOlib backend for USOCKET. There's no doubt that IOlib is a better choice of CL networking library for people whom love (or at lest not hate) loading CFFI, C-based DLLs and lots of third party packages into their CL platforms. And, IOlib's io.multiplex package is also a better way to do "select" on multiple sockets. In my idea, there will be a new "usocket-iolib.asd" system, which depends on IOlib's networking part, and will load USOCKET core plus a special backend for IOlib. This backend just assume IOlib is a new platform, and use IOlib's networking API to implement all USOCKET API. Will this idea be helpful for any USOCKET user? Regards, Chun Tian (binghe)

4 3

[usocket-devel] [Patch] ns-try-again-condition is undefined.
by Stas Boukarev 28 Sep '10

28 Sep '10

ns-try-again-condition is used in several places, but is defined as ns-try-again. The attached patch renames it to ns-try-again-condition. -- With Best Regards, Stas.

2 3

← Newer
1
...
6
7
8
9
10
11
12
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel