gabi38

Is there any area that google don't stick their nose in? Now they are also in the DB business??

What he has against BOOST?if any, Boost helps eliminating deps. Without it one would need to use multiple libs from different places to achieve common things like shared pointers etc. Not to mention most of it is just header files.

How would kqueue compare to Windows's IO completion ports in terms of performance?

How does it compare with flask?

How is this thing loads the kernel? I've read the http://bellard.org/jslinux/tech.html but it doesn't say, Does it loads it over the net or what?

This is bad because the optimizer ignores the imperfect reality about the big crowd of non standard programs. It actually punishes non standard programs (and probably the majority of programs out there are not 100% standard). So it is a bad and patronizing optimization

This kind of logic is the exact cause to the optimization problem described. We all know that in practice MAX_INT+1 is negative, and that many "non-standard" programs depends on it, but still, the optimizer is sticking to the C standard that no one follows just because it gives it a nice optimization chance. Bad..

Is it just me or the LLVMs idea that "If arithmetic on an 'int' type (for example) overflows, the result is undefined.. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true"." is incredibly stupid? Who said that undefined number is bigger than a defined one ??

So who the hell actually use OpenCL?

That it has a cool name..

The point I am trying to make is that this fundamental feature of message queues (limit their length to prevent the memory exploding) should be provided by Erlang and not reimplemented over and over again by developers.This is really a basic feature in any message queue

Well, that breaks the whole philosophy of async message passing in Erlang, where sending message always succeeds and is not dependent on the receiver. What you are suggesting is in fact limit the queue to be of size of 1 (if only one producer, or to the number of producers). This is not what queue is all about

Very needed book. In particular I am interested in limiting message queues in Erlang. I still don't get it - How one should deal with situations where messages are produced constantly in higher rate than consumed.. There is no protection in Erlang for this common scenario (I think)