On Thu, 9 Sep 2010, Simen Endsj? wrote: > On 09.09.2010 07:19, Masahiro Nakagawa wrote: > > On Wed, 08 Sep 2010 23:53:13 +0900, Johannes Pfau > > <[email protected]> wrote: > > > > > On 08.09.2010 16:02, Masahiro Nakagawa wrote: > > > > > > > > I am thinking about std.event. > > > > This module supports system-dependent APIs(kqueue, epoll, etc...) and > > > > abstraction layer. > > > > > > > I think the best solution would be a wrapper / abstraction layer for > > > libev. All of the mentioned APIs (kqueue, epoll, select...) are broken > > > in some way, so writing a new event loop system in D will be painful and > > > it will take a long time until it gets stable. Also libev already has > > > support for more event sources (timer, periodic, signal, stat, ...). > > > > libev is a good library. I often use rev in Ruby programming. > > > > Can Phobos include this library? > > > > > > Masahiro > > Isn't it possible to add a new library not part of the standard where such > modules could be included? > xtrabos? Containing xtb.event, xtb.curl and other libraries with incompatible > licenses? Could also act as an incubator project for phobos.
Easy enough for minimal integration. The problem really starts when parts of phobos code want to depend on that library. At that point it stops becoming optional and adds one more layer of friction to people who want to play with D (and hopefully later use for real). Things like libc and libm are easy, they're a base part of the OS. Things like libcurl and libev are _often_ already installed on posix systems but not always, and almost never on windows systems. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
