networked application with libuv
Amirouche Boubekki
(12 Oct 2020 06:52 UTC)
|
Re: networked application with libuv
Lassi Kortela
(12 Oct 2020 08:06 UTC)
|
Re: networked application with libuv
Amirouche Boubekki
(12 Oct 2020 12:29 UTC)
|
Re: networked application with libuv Lassi Kortela (15 Oct 2020 18:44 UTC)
|
Re: networked application with libuv
Amirouche Boubekki
(17 Oct 2020 09:16 UTC)
|
Re: networked application with libuv Lassi Kortela 15 Oct 2020 18:44 UTC
> Yes. I did not come to this suggestion lightly. The thing is relying > on raw POSIX or Windows API is error prone That's definitely true. Even for those who don't use it, its source code and issue tracker is excellent documentation. > and does not work all the time because you need errno. > The advantage of libuv is that a) it does not expose errno What does this mean? > b) it is > portable across many platforms, runtimes (windows, POSIX, musl, glic), > and scheme implementations. Definitely an asset. And libuv doesn't seem to have any dependencies on third-party libraries. >>> If we have cross platform bindings for that it will allow us to create >>> a couple portable implementations for on-going pre-srfi like http, p2p >>> and cell-terminal. Possibly others like database drivers? >> >> All of those are useful for sure. But should probably not depend on >> libuv specifically. > > I am sure you know that sample implementations are useful to drive the > specification of useful libraries forward, and give a baseline that > may work on many schemes. libuv will allow us to build and test > network libraries on many schemes. Definitely a useful implementation tool, as long as the interfaces specified in SRFIs also work without libuv. We probably can't convince most/all Scheme implementations to ship it; a few don't even use C. > I am not sure what I am supposed to do? I suggest I will work on libuv > bindings, that work can benefit many Scheme implementations especially > those that support r6rs-pffi. Gambit in particular, might not benefit > from those bindings directly, higher level libraries will abstract the > uv-specific bits, so it will be useful eventually. > > Guile can benefit from libuv bindings even if they have their own > socket-port machinery. Loko is not interested in C bits. I'm not familiar in detail with the other implementations; you know better than I do. > AFAIU, CML based on ports is compatible with libuv when you have custom ports. > > Consider the libuv bindings just a chime to bring as much Scheme > implementation onboard the network party. Sounds excellent.