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 package name, the whole idea is possible, just like what CFFI tries to emulate UFFI by using a separated system "cffi-uffi.asd". Any way, this is something not cared by me, because I'm not the maintainer of IOlib.
What I cared is to make exist usocket users and applications live better without making any explicit code changes into their own code base. By using IOlib as a backend, usocket's WAIT-FOR-INPUT function now can directly use IOlib's strong I/O multiplexing facility and exceed the 512 fd limitation when using select(). I also care those platforms in which CFFI and IOlib is not available, so a plain usocket implementation is still needed. On 24/giu/2013, at 17:56, Tomas Hlavaty <tomas.hlav...@knowledgetools.de> wrote: > 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 code. It would be a shame to sacrifice the winapi part > especially when usocket is all about portability API. > > Also, as Anton pointed out, I find a separate system better solution than > pushing a feature. After all, usocket is an API. When implemented using > iolib, why would there be a need to use any code from the original usocket? > At the moment we simply asdf-load :iolib.usocket only and all systems > depending on usocket work as desired because the required usocket system and > usocket:* stuff is in place. > > Cheers, > > Tomas > > On 06/24/2013 11:33 AM, Chun Tian (binghe) wrote: >> 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 <tomas.hlav...@knowledgetools.de> >> wrote: >> >>> 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 status is though as we don't use that. IIRC >>> I still need to implement translation of iolib conditions to usocket ones, >>> but as a precondition for that is unifying conditions from iolib posix and >>> winapi backends. Otherwise, hunchentoot and cl-postgres work well on posix >>> and windows using this compatibility layer. >>> >>> Cheers, >>> >>> Tomas >>> >>> On 06/24/2013 11:12 AM, Anton Vodonosov wrote: >>>> Hello. >>>> >>>> 24.06.2013, 11:22, "Chun Tian (binghe)" <binghe.l...@gmail.com>: >>>>> 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 compilation is that when my >>>> application loads the usocket >>>> as a dependency, the application doesn't know how usocket will work, >>>> because it was dediced >>>> when usocket was compiled (possible during load of some other application). >>>> >>>> If you give little bit more details about he usocket-iolib functions, I >>>> can propose more concrete solutions. >>>> Very possible the proposal will be a separate ASDF system, usocket-iolib. >>>> >>>> Best regards, >>>> - Anton >>>> >
