When the program is run from the terminal, the output is as expected: a single line containing "foobar". However, when the output is sent to a pipe or redirected to a file, two lines appear in the output. (Actually, the problem was a bit more complicated: there were
if(fork() == 0)
n fork()calls and there were exactly
nadditional copies of the output). After a bit of digging around and not finding any obvious fault, I asked about it on IRC.
It turned out that
stdoutis fully buffered when it is attached to a pipe or a file. What happened is that
fork()duplicated also the internal I/O buffers, which got flushed after the child process exited, thus producing extra output. I solved the problem by inserting a
fflush(NULL);statement before forking, which flushes buffers of all output streams.
So long Foxit, Acrobat Reader is still my favorite PDF reader.
std::bitset<1000000000>and created an instance of the sieve class within the
mainfunction (i.e., allocated on the stack).
When I ran the program, it crashed with stack overflow. Since VC in debug mode implements stack overflow checking, the stack trace was not very helpful -- the program crashes within the
_chkstkfunction. But in my simple test program, the only possible cause of stack overflow could be the instance of the sieve class which contains the bitset member. After lowering the sive's limit to 1000, the program worked fine. It was kinda surprising to learn that
std::vector, internally uses an array instead of dynamically allocated storage. (I confirmed this conjecture also by reading the source code of in the corresponding header file.)
git rmon wrong files. With subversion, if you do
svn revertbefore commit, the old copy of the file gets restored (and, of course, removal will not be scheduled for commit).
git checkoutshould, in theory, do the same. Googling about the problem, I found a tip that I should use
git reset. However, neither did that restore the accidentally deleted files. Finaly, I experimented a bit and found out that
git reset --harddoes the trick. Before experimenting, I did, of course, make a backup of the whole repository to another place.
Now, I'm going back to subversion, which is much more intuitive to use. My work is too valuable to be stored in version control system with which I must experiment to achieve even the simplest of operatons. Yes, I found the
--hardoption in the documentation, but its explanation was so opaque that I wasn't sure whether it would achieve what I wanted.
Next time I'll be wanting to use a DVCS, I'll use Mercurial, as before.
Now, midst in the financial crisis, I've gotten interested in how the economy works in general. Like, the stock market, how can perpetual economic growth be sustainable (in the long run it's exponential), etc. I would also like to know about things that are relevant for real life, like loan calculations, nominal and effective interest rates, forms of long-term savings, etc. And I know zilch about these things.
These things should be a part of basic high-school education. But no, we've been (and today's pupils are still being) overloaded with a bunch of meaningless historical and geographical facts that can be looked up in any online or offline encyclopedia. Among other meaningless stuff that is mostly irrelevant for the practical side of living in the modern world.
Currently I'm busy with writing my PhD, but first priorities on my reading list (after having finished the PhD) are introductory books in macroeconomy, capitalism, and game theory.
assert(pthread_mutex_trylock(&mtx) == EBUSY)
There is no way to check that the current thread holds the mutex. However, if another thread has locked the mutex, one may hope that
EPERMerror code (I don't think that the pthread library is obliged to check for every possible error condition).
Take Win32, and the
TryEnterCriticalSectionfunction which returns, according to the documentation: "If the critical section is successfully entered or the current thread already owns the critical section, the return value is nonzero. If another thread already owns the critical section, the return value is zero."
Since I actually expect that the current thread already owns the mutex, the "or" clause in the first sentence makes it impossible to implement even the (weaker) sanity check which is possible under POSIX. Kinda shame.