Hi binghe,
I found my old note in :iolib.usocket:
;;; At first, I tried to
;;; implement an iolib backend for usocket but found that was not the
;;; way to go due to heavy posix bias of the usocket backend
;;; interface. Implementing the usocket API directly is better.
The usocket internal bac
On 24/giu/2013, at 18:49, Tomas Hlavaty wrote:
> Hi binghe,
>
> the portability layer lives in the package :iolib.usocket and implements the
> usocket api. How would you implement and api without emulating another
> package's interface? Isn't the api the package's interface? If the user
>
Hi binghe,
the portability layer lives in the package :iolib.usocket and implements
the usocket api. How would you implement and api without emulating
another package's interface? Isn't the api the package's interface? If
the user loads iolib.usocket.asd, what else should he expect instead o
Sure. I don't mean my note as an counter argument to your approach.
Just noting the funny situation with multiplied API we have in Lisp.
BTW, Win32 socket API is based on BSD sockets.
24.06.2013, 14:37, "Chun Tian (binghe)" :
> You're right, and I want to support as much approaches as possible.
>
You're right, and I want to support as much approaches as possible.
A obvious fact is, there're also platforms not based on BSD sockets, at least
not pure. For example, all implementations on Win32, and MCL (based on
OpenTransport), Lisp machines, and ABCL running in JVM. I want to support all
Hi Anton,
in theory, it's a noble target. Problem is that there are inherently
non-portable things to consider, e.g. how does iolib handle control-c?
So for each supported implementation, there needs to be a bit of code
that cuts directly into the lowest level of the host lisp environment.
Hi Tomas
I think it's not quite polite to directly emulate another package's interface
(and creating other package's Lisp package), so you shouldn't expect after
loading IOlib.usocket, you got a package "usocket" with all functionalities of
usocket in it. However, with a slightly changed Lisp p
I also want to highlight the advantage of IOLib based sockets.
The underlying socket API provided by most of the OSes today is the same - BSD
sockets.
Various Lisp implementations multiply this basic API by proving their own,
distinct lisp versions of socket APIs.
On top of it we create a compat
Hi binghe,
you are welcome. Both iolib and usocket seem to be under the MIT
licence so I don't see a problem on that front.
However, shouldn't the code be merged into iolib only rather than
merging it into both iolib and usocket? The whole of the iolib winapi
port makes it quite a lot of c
Hi Tomas
Thank you! Then I guess you wouldn't mind if I merge your work into usocket as
the basis of the new IOlib backend? ^_^
--binghe
On 24/giu/2013, at 17:30, Tomas Hlavaty wrote:
> Hi all,
>
> just in case it might be somehow interesting, we've had iolib.usocket system
> for quite some
Hi all,
just in case it might be somehow interesting, we've had iolib.usocket
system for quite some time in
http://src.knowledgetools.de/tomas/winapi/index.html It is a simple
usocket compatibility layer on top of iolib (also works on Windows
winapi 32 and 64 bit). Not sure what the ipv6 sta
Hello.
24.06.2013, 11:22, "Chun Tian (binghe)" :
> To compile usocket with IOlib, user should push :usocket-iolib into their
> *feature* first.
I would like to propose to use some other solution than conditional controlling
compilation with *reatures*.
The disadvantage of the conditional compi
Hi.
On Mon, 2013-06-24 at 15:20 +0800, Chun Tian (binghe) wrote:
> 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
>
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
14 matches
Mail list logo
