usocket-devel

usocket-devel@common-lisp.net

248 discussions

Shadowing special variables in threaded handlers
by Duncan Bayne 01 Jan '22

01 Jan '22

Hi, I'm trying to write some end to end tests for the germinal library, which uses usockets. What I'm trying, and failing, to do is to shadow special variables in my tests so that test-specific configuration is scoped just to the tests in question. This (tidied up) REPL session with a simple repro case using just usocket and usocket-server should give a sense of what I'm trying to achieve: CL-USER> (ql:quickload '(:usocket :usocket-server)) (:USOCKET :USOCKET-SERVER) CL-USER> (defvar *foo* "original value") *FOO* CL-USER> (defun create-server () (usocket:socket-server "0.0.0.0" 1965 (lambda (stream) (write *foo* :stream stream)) () :multi-threading t :element-type 'character :in-new-thread t)) CREATE-SERVER CL-USER> (let ((*foo* "shadowed value")) (create-server)) #<SB-THREAD:THREAD "USOCKET Server" RUNNING {10043A6933}> #<USOCKET:STREAM-SERVER-USOCKET {10043A67D3}> So what I'm hoping for here is for the socket server to return "shadowed value" when a connection is opened; of course that doesn't happen, because the handler runs in a new thread which is bereft of the let context: $ telnet localhost 1965 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. "original value" I'd appreciate any assistance here ... I'm somewhat new to Common Lisp with only a little commercial experience in it beyond hobbyist work. I don't know whether there's a "Lisp trick" I should be using to ensure the right context for the handler thread, or whether I need to refactor the library in question to not rely on special variables in the handler ... -- Duncan Bayne +61 420 817 082 | https://duncan.bayne.id.au/ I usually check my mail every 24 - 48 hours. If there's something urgent going on, please send me an SMS or call me.

3 6

Bug in vector-quad-to-dotted-quad etc.
by Frode Fjeld 12 Jan '21

12 Jan '21

Hello, and thanks for usocket. I tend to do my programming with *print-base* 16 and *print-radix* t. This exposed a bug in some of the functions in usocket.lisp that format IP addresses. For example, vector-quad-to-dotted-quad and hbo-to-dotted-quad, which I believe should use tilde D instead of tilde A in order to operate correctly. Thanks, -- Frode Fjeld

1 0

[release] usocket 0.8.2
by Chun Tian (binghe) 11 Jun '19

11 Jun '19

Changes in 0.8.2: (June 11, 2019) * General: now the HOST-OR-IP slot of NS-CONDITION has been exported. (#46) * Bugfix: NS-HOST-NOT-FOUND-ERROR condition has unbound HOST-OR-IP slot (#46) * Bugfix: [SBCL/LW] WAIT-FOR-INPUT waits only in the first call (when W-F-I is called with a single usocket, introduced in 0.8.0) (#50) (Thanks to @Hamayama for reporting/hints/testing the issue #50, which was introduced in 0.8.0.) Direct download link: https://common-lisp.net/project/usocket/releases/usocket-0.8.2.tar.gz https://common-lisp.net/project/usocket/releases/usocket-0.8.2.tar.gz.asc Repository: https://github.com/usocket/usocket https://gitlab.common-lisp.net/ctian/usocket -- Chun Tian

1 0

[release] usocket 0.8.1
by Chun Tian (binghe) 08 Mar '19

08 Mar '19

Changes: * New backend: clasp (patch from Christian Schafmeister, #45) * Bugfix: [SBCL] fixed loading usocket.asd in SBCL 1.5.0 Downloads: https://common-lisp.net/project/usocket/releases/usocket-0.8.1.tar.gz https://common-lisp.net/project/usocket/releases/usocket-0.8.1.tar.gz.asc —Chun Tian

1 1

[announcement] usocket 0.8
by Chun Tian (binghe) 04 Feb '19

04 Feb '19

Hi, I’m glad to release usocket 0.8, next major release since 0.7.9. [Changes in 0.8] * New backend (experimental): IOlib. (Push :USOCKET-IOLIB to *FEATURES* to enable this feature) * New feature: Optimized WAIT-FOR-INPUT for single-socket case (one-time consing) * New feature: Exported host-to-hostname (#42) * Bugfix: [SBCL] more robust/thread-safe WAIT-FOR-INPUT-INTERNAL [Downloads] it should appear in Quicklisp’s "Feb 2019” dist updates, or can be downloaded here: https://common-lisp.net/project/usocket/releases/usocket-0.8.tar.gz or from GitHub: https://github.com/usocket/usocket/releases/tag/v0.8 [Extra notes] usocket's networking functionalities are essentially based on the networking APIs provided by each supported Common Lisp platforms. There’re pros and cons: Pros: 1. the correctness of usocket’s API functions is based on the correctness of underlying CL platforms (which is usually reliable) 2. no dependency on dynamic loaded DLLs (with minor uses of FFIs if it goes beyond the features provided by underlying platforms, e.g. UDP on LispWorks) Cons: 1. the behavior of usocket API is not always consistent across all supported CL platforms. 2. complex FFI-based coding at usocket side introduces potential bugs whenever it goes beyond the features provided by CL platforms. 3. C constants in BSD socket API must be defined as literal numbers for each tested OSes; sometimes these values are wrong for an arbitrary new unsupported *nix platform. 4. backend code for each supported CL platforms (sometimes even for each OSes) must be maintained separately, which brings extra inconsistencies. I’ve been working for a long time on a new usocket backend: IOlib [1]. IOlib is a robust, feature-rich networking library based on CFFI and “libfixposix” library, and it’s behavior-consistent across all supported platforms. If you can correctly (which is not easy!) load IOlib in your working CL platforms of your working OS platform, e.g. SBCL/LispWorks on Linux/Mac, then it’s possible to use IOlib to do the actual networking work for usocket. And usocket’s WAIT-FOR-INPUT will now use Linux epoll() (or BSD/Mac kqueue()) to do the I/O multiplexing!! To enable this feature, just push a new feature keyword before loading usocket: > (pushnew :usocket-iolib *features*) > (asdf:load-system :usocket) To go back to the traditional backend, just restart your CL platform and load usocket normally without :usocket-iolib staying in *features*. What’s more interesting is the ability to dynamically “switch” backends without restarting the CL platform: > (asdf:load-system :usocket) ;; this loads usocket with traditional backend > ... > (pushnew :usocket-iolib *features*) > (asdf:load-system :usocket :force t) ;; this reloads usocket with IOlib backend I didn’t actually test the other direction, but in theory if :usocket-iolib gets removed from *features* and you call (asdf:load-system :usocket :force t) again, usocket will go back to the traditional backend. Currently there’re still many bugs in the IOlib backend, e.g. WAIT-FOR-INPUT doesn’t work quite properly, although all needed coding seems to be there. Thus please use with cautions, and I’ll continue fixing the IOlib backend in later updates. Regards, Chun Tian [1] https://common-lisp.net/project/iolib/

1 0

usocket-0.7.1
by Chun Tian (binghe) 30 Aug '18

30 Aug '18

Changes in 0.7.1: * New feature: GET-(RANDOM)-HOST-BY-NAME (now exported) prefer IPv4 on mixed IPv4/IPv6 (suggested by Mark H. David) * New backend: Symbolics Open Genera (Lisp machine) (patch from @Symbolics, #33) * Bugfix: [CLISP] fixed issues in server sockets and error handling. (patch from @vibs29, #28, #29) * Bugfix: [SBCL, ECL] Fix wait-for-input on Windows SBCL and ECL. (patch from Stas Boukarev, #30) * Bugfix: [LW] fixed non-existing system calls in LW 5.0 (comm::socket-set-tcp-nodelay) Sorry for long delay of this new release. [1,2] —Chun [1] https://github.com/usocket/usocket/tree/0.7.x <https://github.com/usocket/usocket/tree/0.7.x> [2] https://github.com/usocket/usocket/releases/tag/0.7.1 <https://github.com/usocket/usocket/releases/tag/0.7.1>

1 0

bug in host-to-vector-quad on lispworks (also host-to-vector-quad)
by Mark H. David 12 Jul '18

12 Jul '18

Running usocket-0.7.0.1 in LispWorks 7.1.0. In my system it happens currently that (get-hosts-by-name "localhost") returns the following list: (#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(127 0 0 1)) Then get-host-by-name simply takes the first of that list and returns it. Host-to-hbo expects the result of get-host-by-name to always be a vector quad, so the result of calling it with "localhost" is an error on the recursive call with the result of (get-host-by-name "localhost") => #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) The error message is due to falling out of the ecase: #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) fell through ETYPECASE expression inside USOCKET::HOST-TO-HBO. I observed that host-to-vector-quad gives the wrong result, a 16-byte instead of a 4-byte vector, due to the same root cause, but it will happen "randomly". The reason is it uses get-random-host-by-name, which chooses a random element of the same result list returned by (get-hosts-by-name "localhost"). For example, I just ran this in the REPL -- log: USOCKET> (loop repeat 10 for r = (host-to-vector-quad "localhost") when (not (= (length r) 4)) collect r) (#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1)) This seems to be LispWorks only. I tried this on SBCL and CCL, but I could not recreate similar problems. Also, not all MacOS installs seem to get this weird ipv6 localhost the way I do. I'm not sure why I'm getting this. I do not remember doing anything special or any kind of stuff with ipv6, but apparently something I've done has "infected" me with it. However, I can say I do not notice other networking issues on my system. Thanks, Mark

2 5

Not subscribed?
by Erik Huelsmann 27 Oct '16

27 Oct '16

On Oct 27, 2016 03:19, "Kaz Kylheku" <kaz(a)kylheku.com> wrote: > > Hi, > > I am positive I did not subscribe to this. The first posting I have > received was the usocket-0.7.0 announcement; before that, I never > heard of the project. Hi Kaz, Do you receive monthly password confirmations from common-lisp.net's MailMan program? If not, then you aren't subscribed. Maybe you should have a look at the message headers to see what route the message was delivered to you through. Regards, Erik > > According to your archives, there were some list postings in August: > > https://mailman.common-lisp.net/pipermail/usocket-devel/2016-August/thread.… > > I never received those because I wasn't subscribed at the time. > > So somehow I became subscribed between August and October, right? > Only thing is, I don't remember doing so. Doing so would have been > odd, given that I'm not working with Common Lisp + sockets at all at > the moment. > > I'm interested in finding out how I might have become subscribed, > if that is possible. > > >

3 2

usocket-0.7.0 released
by Chun Tian (binghe) 27 Oct '16

27 Oct '16

Hi Common Lispers, I’m glad to release usocket-0.7.0, a new major release. Starting from this version, we have made two systems “usocket” and “usocket-server” separated, the purpose is to minimize package dependencies and loaded code. Previously we have some vendor code borrowed from “split-sequence” and “portable-threads” package, now these duplicated code were removed. Instead, we directly depend on the original package. (portable-threads [1] is only needed by usocket-server and usocket-test). The LispWorks support has been carefully checked and confirmed working on version 4.4.x, 5.x, 6.x and 7.0. There’s no new API symbols in this release. However, (few) people who is using SOCKET-SERVER API, please change the dependency from “usocket" to “usocket-server”. (sorry for this change) Changes in 0.7.0: * General: Separated USOCKET and USOCKET-SERVER systems (only the server part depends on Portable-threads) * General: USOCKET (the client part) now depends on SPLIT-SEQUENCE (the exactly same vendor code is removed from usocket code base) * New feature: [LW] (SOCKET-OPTION :TCP-NODELAY) and its SETF version now works on LispWorks 4/5/6/7. * New feature: [LW] SOCKET-CONNECT now supports setting "tcp_nodelay" in version 4.x and 5.0. * Bugfix: [CCL] fixed issues in SOCKET-SHUTDOWN * Bugfix: [CLISP] fixed issues in WAIT-FOR-INPUT (Thanks to a patch by @vibs29, #27) * Bugfix: [LW] fixed loading in version <= 6.0 (actually 0.6.5 only fixed loading in LW 6.1) * Bugfix: [ECL] all compilation warnings were checked and fixed. 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. (or make a Git clone to usocket “master”, URL is given below) The API documentation page was here: http://common-lisp.net/project/usocket/api-docs.shtml Any feedback - bugs or hugs - will be greatly appreciated. Anyone is welcome to send pull request to our Git repository: https://github.com/usocket/usocket.git Some future directions: * More features in SOCKET-SERVER * New IOlib backend! * Add support for MKCL (this will be the 13th CL platform that we support) Regards, Chun Tian (binghe) USOCKET Team [1] Now Quicklisp starts to use my version at https://github.com/binghe/portable-threads

4 6

usocket-0.6.5 released
by Chun Tian (binghe) 19 Oct '16

19 Oct '16

Hello, usocket-0.6.5 is released: * New feature: SOCKET-OPTION and (setf SOCKET-OPTION) for :SEND-TIMEOUT (thanks to John Pallister) * Bugfix: Let (WAIT-FOR-INPUT NIL &TIMEOUT) return NIL with respect to TIMEOUT. * Bugfix: [LW] fixed loading in LispWorks 5.x & 6.x. * Bugfix: [LW] fixed SOCKET-SHUTDOWN in all versions. * Bugfix: [ABCL] Fixed incorrect IPv6 addresses (#26), patch from Elias Mårtenson (lokedhs) Regards, Chun Tian (binghe) University of Bologna (Italy)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel