usocket-devel

usocket-devel@common-lisp.net

248 discussions

[Usocket-devel] use of unexported symbols in backend/openmcl.lisp
by R. Matthew Emerson 17 Dec '14

17 Dec '14

I notice that backend/openmcl.lisp uses many symbols that are internal to the ccl package. In some cases, even exported symbols (such as ccl:%null-ptr) are referenced using the ccl:: notation. This is bad practice, of course. It also causes usocket to be semi-broken on the development version of CCL: socket-connect uses the unexported symbols ccl::host-as-inet-host, ccl::port-as-inet-port, and ccl::inet-connect. These are no longer present. I could probably add them back for the sake of compatibility, but I would prefer not to have to do this. If there is functionality that usocket requires that is not available from a supported interface, I'd like to hear about it. The best way to do that would be to write tickets at http://trac.clozure.com/ccl.

2 2

[Usocket-devel] hunchentoot, usocket, ipv6
by Zach Beane 30 Nov '14

30 Nov '14

The latest release of hunchentoot, 1.2.28, depends on the "ipv6" branch of usocket. The master branch and the latest release don't have the ipv6 symbols that hunchentoot references. Is the ipv6 branch likely to be merged with master soon? Is there going to be a new usocket release soon? Thanks, Zach

2 1

[usocket-devel] Re: IPv6 support in usocket
by Chun Tian (binghe) 18 Sep '14

18 Sep '14

Hi Hans Now I'm going to support IPv6 in next major usocket release (0.7.0). Here's my ideas (of course, based on yours): 1. Add a new backend IOlib to support exist IPv4 functionality. To compile usocket with IOlib, user should push :usocket-iolib into their *feature* first. 2. Extend usocket code base to support IPv6 address and related host resolution and address conversations 3. Extend backends for IPv6 to support LispWorks, Allegro CL and IOlib first. (At this step your plan is done) All backends' native IPv6 implementation should have :IPv6 in their *features* 4. Write patches for SBCL and CCL to support IPv6 directly on their exist network interfaces. The purpose is to make unmodified SBCL/CCL working directly with my patches to get the ability to support IPv6 with their exist interfaces. Platforms with such modifications should have :usocket-ipv6 in their *features*. 5. Support more open source CL platforms (ABCL, CMUCL, ECL) by using above loadable patche approach. 6. Convert IPv6 patches to code patch on each free CL platforms themselves and send to maintainers of these CL platforms to get it merged. 7. For those platforms' new versions with IPv6 patches merged, USOCKET should turn to use their native implementation, but the support on exist old versions should remains in usocket code base for a quite long time. If you have any concern and suggestions, feel free to make your comments. Regards, Chun Tian (binghe) On 05/feb/2013, at 00:12, Hans Hübner <hans.huebner(a)gmail.com> wrote: > Hi Binghe, > > I would like to make Drakma and Hunchentoot support IPv6, and in order to do that, I need usocket to support IPv6. As most open source implementations do not support IPv6 in their socket APIs yet, it would probably be best to add a new backend for IOLib (which is pretty much identical to Allegro CL). Supporting Lispworks and Allegro CL would be done through their native APIs. > > What do you think about that? Do you have any plans? If not, I would try myself on the IOlib side of things first. > > Thanks, > Hans

6 30

[Usocket-devel] socket-listen lacks UDP support
by Robert Brown 21 Apr '14

21 Apr '14

The socket-listen function in backend/sbcl.lisp does not support ":type :datagram :protocol :udp". Instead, it always creates a stream TCP socket. I think the fix is to use code similar to that in socket-connect for UDP datagram sockets. Bob

2 1

[usocket-devel] mocl patch
by Hans Hübner 21 Jun '13

21 Jun '13

Hi Chun, do you have time to merge the mocl changes ( https://github.com/Wukix/usocket/commit/0b2955b6a327a51f7df140f89ad027b92f6…) into usocket? At this point, mocl is not yet released so there is no way to test the changes for most people, but it would be nice to have support in usocket so that once it is released, quicklisp libraries can be used without requiring a special usocket version. Thanks! Hans

2 1

[usocket-devel] [ANNOUNCE] usocket 0.6.1
by Chun Tian (binghe) 21 Jun '13

21 Jun '13

Dear Lispers, I'm glad to announce the usocket 0.6.1 release. Changes in this release: * New feature: [MOCL] Initial MOCL [1] support (TCP only, no W-F-I, patch from github.com/Wukix/usocket). * New feature: [MCL] Initial UDP support for Macintosh Common Lisp (MCL/RMCL). * New feature: Added TCP-NO-DELAY (TCP_NODELAY) support in SOCKET-OPTION, for TCP client * Bugfix: [CCL] Added (:external-format ccl:*default-external-format*) to SOCKET-CONNECT, to prevent it fallback to ISO-8859-1 on NIL. (Patch from Vsevolod Dyomkin) * Bugfix: [CCL] Performance improved WAIT-FOR-INPUT and other fixes. (patch from Faré <fahree(a)gmail.com>) For the new API SOCKET-OPTION (since 0.6.0), now we support following options: (however, now all backends are fully covered) * (0.6.0) RECEIVE-TIMEOUT (SO_RCVTIMEO) * (0.6.0) REUSE-ADDRESS (SO_REUSEADDR), for TCP server * (0.6.0) BROADCAST (SO_BROADCAST), for UDP client * (0.6.1) TCP-NO-DELAY (TCP_NODELAY) for TCP client 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: Some advanced TCP features for CLISP (not supported by its exist interface) * New feature: SOCKET-SHUTDOWN * New feature: IPv6 support * Bugfix: improved test suites. Regards, Chun Tian (binghe) USOCKET Team [1] http://wukix.com/mocl

1 0

[usocket-devel] Questions about exported symbols...
by Patrick Stein 17 Apr '13

17 Apr '13

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

2 2

[usocket-devel] patch for Clozure CL
by Faré 17 Apr '13

17 Apr '13

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

2 3

Don't disappoint your girl at night
by Paula Torres 12 Apr '13

12 Apr '13

Keep your wife entertained at night http://jetlinenews.co.uk/suit.html

1 0

Automated-response: Rejected e-mail
by Mail Delivery Subsystem 12 Apr '13

12 Apr '13

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(a)acceleration.net. 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(a)acceleration.net>; 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(a)acceleration.net>; Thu, 11 Apr 2013 17:39:17 -0700 (PDT) X-Original-To: usocket-devel(a)common-lisp.net 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(a)common-lisp.net>; 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@home9126f627b99bc> From: "Paula Torres" <tbwestley(a)inteliorg.com> To: <usocket-devel(a)common-lisp.net> 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 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437

1 0

← Newer
1
2
3
4
5
6
7
...
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