Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gabi38
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
1.
▲
by
gabi38
15y ago
Is there any area that google don't stick their nose in? Now they are also in the DB business??
2.
▲
by
gabi38
15y ago
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.
3.
▲
by
gabi38
15y ago
How would kqueue compare to Windows's IO completion ports in terms of performance?
4.
▲
by
gabi38
15y ago
How does it compare with flask?
5.
▲
by
gabi38
15y ago
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?
6.
▲
by
gabi38
15y ago
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
7.
▲
by
gabi38
15y ago
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 tha
8.
▲
by
gabi38
15y ago
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 s
9.
▲
by
gabi38
15y ago
So who the hell actually use OpenCL?
10.
▲
by
gabi38
15y ago
That it has a cool name..
11.
▲
by
gabi38
15y ago
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 basi
12.
▲
by
gabi38
15y ago
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 produc
13.
▲
by
gabi38
15y ago
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 i