On 24/11/2010, at 3:18 AM, Erick Tryzelaar wrote: >> >> is NP-hard, which is why production package managers like Debian can't >> effectively allow this option. > > > This feels like we might be trying to do too much with requirements.
Yeah. > First off, I'm not sure if we should be baking in the decision of > select/poll/epoll. That was only an example :) The concept is: instead of "conditional compilation" which in general sucks as an idea, have selection based on filtering. A more grand concept is: consider Open Unix Specification documents. There are huge set of functions, some required by Posix, some in RT extensions, some in X/Open standard, etc. There is a table (available as a PDF unfortunately) saying for each function which standard supports which function. We can add "BSD" and "OSX" and "Linux" as well. Now consider how we might handle this. Conditional compilation? Like this: if XOPEN or POSIX or LINUX do gen open: string -> int = " ..." elif BSD or MACOSX do gen open: string -> int = "..." endif I mean that REALLY sucks compared with gen open: string-> int = "..." requires XOPEN or POSIX or LINUX; gen open: string -> int = ".." requires MACOSX or BSD; don't you think? Assuming the meaning was the same. > I ran across some benchmarking that suggests that > epoll is not always better than poll in all circumstances: > > http://sheddingbikes.com/posts/1280829388.html Yes, and of course the notes relating to libev suggest also not to use kqueue and some others because they're broken. We might even use libev as the event manager: it sucks like all libraries because it uses callbacks, but that actually isn't a problem if it is control inverted by running it in a thread, which is where we do the polling anyhow. But I'm loathe to create another dependency on 3PLs. > > Second, the APIs of select, poll, and epoll are vastly different from > each other, so I'm not sure it would even make sense to have: > > proc foo () requires select or poll or epoll { > ... > } > > Because you'd still have to have something like: > > ... > macro if epoll do > foo_epoll () > else if poll do > foo_poll () > else > foo_select () > done > ... > > right? In general, yes, we can't get rid of conditional compilation yet. However things work now, and we can ONLY use conditional compilation around well formed statements and expressions, not arbitrary token strings as in C, and that hasn't proven to be much of a problem. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
