Tuesday, October 29, 2013
I run Ubuntu on a VirtualBox system, where I had reserved somewhat too little diskspace for getting our build system to work there (esp. when you have to build a specific gcc version up-front). While it's no problem to increase the size of the virtualized disk within VirtualBox, the partitioning within this disk, particularly of the root partition (the one that Ubuntu is actually running on), might turn out to be difficult to change on -the-fly. I then found and applied GParted to assign the additional disk space to the root partition, which - despite a "potential data loss risk" warning - worked like a charm.
Wednesday, October 23, 2013
"A mutex is really a semaphore with value 1"While mutexes indeed are similar to binary semaphores, there is one significant difference: the principle of ownership. And fortunately Niall picked up that up in his excellent series on Mutexes vs. Semaphores. Here is part 1, part 2 and part 3.
No, no and no again. Unfortunately this kind of talk leads to all sorts of confusion and misunderstanding
Another one, more compact explanation comes from Michael Barr in Mutexes and Semaphores Demystified.
Tuesday, October 15, 2013
Original 1982 net.lang.c posting by Dennis Ritchie. "Several hundred kilobytes of source code, and maybe 3 installations", I guess that explains it :-)
From decvax!harpo!npoiv!alice!research!dmr Fri Oct 22 01:04:10 1982
Subject: Operator precedence
The priorities of && || vs. == etc. came about in the following way.
Early C had no separate operators for & and && or | and ||. (Got that?) Instead it used the notion (inherited from B and BCPL) of "truth-value context": where a Boolean value was expected, after "if" and "while" and so forth, the & and | operators were interpreted as && and || are now; in ordinary expressions, the bitwise interpretations were used. It worked out pretty well, but was hard to explain. (There was the notion of "top-level operators" in a truth-value context.)
The precedence of & and | were as they are now.
Primarily at the urging of Alan Snyder, the && and || operators were added. This successfully separated the concepts of bitwise operations and short-circuit Boolean evaluation. However, I had cold feet about the precedence problems. For example, there were lots of programs with things like
if (a==b & c==d) ...
In retrospect it would have been better to go ahead and change the precedence of & to higher than ==, but it seemed safer just to split & and && without moving & past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3 installations....)
Monday, October 14, 2013
Monday, October 07, 2013
I really wonder whether Sun/Oracle ever considered how the introduction of Java Stack Map Tables within the Java 6 classfile specification (optional back then), resp. their enforcement by the Java 7 bytecode verifier is hurting the existing Java Agent / Profiler ecosystem. The whole problem is summed up pretty well in Java 7 Bytecode Verifier: Huge backward step for the JVM.