After realizing that some of the most valuable feeds I track are simple tumblelogs I decided to start my own tumble category. A lot of the time I find that I have stumbled upon a valuable link only to never find it again when I really need it. Now I will at least have a place to collect them, other than my ever growing list of bookmarks, and at the same time be able to share them with the world.
Anarchaia: A tumblelog by Christian Neukirchen is the tumblelog that ignited my love for tumblers. It has a healthy mix of technology, art and poetry and is updated almost daily.
SNES APU on a PC, a project to create an interface between the audio processing unit of a SNES with a PC.
POHMELFS is a new distributed networking filesystem for Linux which is showing remarkable results when compared to NFS or even localized filesystems.
Xpra, Persistent Remote Applications for X, is like screen but for X applications. This is something I think we have all been waiting for a very long time.
Epic take-apart: HP Color LaserJet 2600n, apparently these printers cost less new with fully loaded OEM toners than buying replacement toners does and for that reason people rather buy a new printer than only replace their toners. Evil Mad Scientist Laboratories got their hands on one of these throw-aways and decided to take it apart.
Google C++ Style Guide. If you need a good basis for your internal style guide or just some good ideas to expand an existing guide this is a good place to go. I do not agree with all of their rules though. I can also recommend the Ellemtel Telecommunication Systems Laboratories, Programming in C++, Rules and Recommendations, although it is slightly dated.
Bannalia: trivial notes on themes diverse is the personal blog of Joaquín M López Muñoz. A really smart guy doing some awesome stuff with C++ template metaprogramming which I have been enjoying for a couple of weeks now.
C++ FQA Lite, an interesting analysis of the well known C++ FAQ Lite by Marshall Cline.
LGD, since the Atari STe was my first computer Little Green Desktop has held a special place in my heart for a long time. Oh how I miss those old days when computers (as in hardware) were still exciting.
Practical Common Lisp, a free book for the beginner in common Lisp, a language which is far more interesting than the parentheses give light of.
I removed the “deathtrap” category today since that project never really panned out. The only two articles that were related to it have been transferred to the “personal” category.
I have been wondering what the references to “I put on my robe and wizard hat” in xkcd meant and decided to Google it. Apparently it is a reference to a guy, known primarily as Bloodninja, who enters cybersex chat rooms and role plays in unexpected ways. Turns out he is hilarious and you can read about his antics here.
Note: His material might not be 100% SFW.
While reading about “The Stalled Server Room” over at The Daily WTF I found this other great entry on the source control by shingle model. Apparently some guy, so afraid of using any tools to aid in his development, used an actual shingle in order to manage who had the right to modify the base libraries in the project.
Read the whole story titled “The Source Control Shingle“, it’s hilarious. Surprise, surprise, they are developing on Windows! ![]()
As you might already know I bought an ‘88 Camaro IROC last year. Being a moderately old car it of course requires some attention in order to keep it in good shape, that is also one of the reasons I got it since I felt the need for a new hobby. The undercarriage of the car had been sealed pretty well with corrosion protection but there were a few minor spots where rust had gotten a hold and the rear axle was mostly unprotected so I decided that is what I would spend my time on last autumn.
The idea was to remove as much of the rust as possible and seal the components to prevent them from future attacks. For that purpose I used a recirculating spot blaster and aluminum silicate blasting abrasive to clean up the worst parts and a steel wire wheel brush fitted on a standard drill to polish the blasted surface. Having never blast cleaned anything in my life it took a while to figure out the proper technique and hence it took me quite some time to clean up the surface but it was a learning experience and I actually enjoyed it.
Sadly the batteries in my camera ran out so I was never able to take any pictures of the polished axle but last week I was finally able to snap a photo of the end result. I’ve been driving the car and apparently have picked up a couple of seed capsules which stuck to the corrosion protection I put on. They account for all the small white spots that you see on the following picture.
My next project will be to convert the air conditioning system from R-12 to R-134a.
I’m working with an API for a closed source library that comes with a recommendation of using two separate threads when passing it data in order to ensure that the data pipelines are never empty. I’ve been doing it for a while but recently we had a lot of stability issues. After some digging I tried to rewrite the two threads into one that multiplexed the calls instead and suddenly stability was back again. I think that if you recommend that people access your API via threads it would be nice to indicate that some calls aren’t thread safe, but no.
I decided to design a generic type that would allow synchronized access to any kind of variable while utilizing RAII to ensure that it is unlocked automatically. The task turned out to be a little more complicated than I first expected but after some trial and error I came up with a solution that I found had a good functionality/aesthetic ratio.
template <typename T>
class SynchronizedVariable : public boost::non_copyable {
public:
class Accessor {
public:
T* operator->() {
return m_variable;
}
const T* operator->() const {
return m_variable;
}
private:
Accessor(const boost::recursive_mutex::scoped_lock& lock, T* variable) :
m_lock(lock),
m_variable(variable) { }
const boost::recursive_mutex::scoped_lock& m_lock;
T* m_variable;
friend class SynchronizedVariable<T>;
};
SynchronizedVariable(const T& variable) :
m_mutex(),
m_variable(variable) { }
SynchronizedVariable() :
m_mutex(),
m_variable() { }
const Accessor get() const {
return Accessor(m_mutex, &m_variable);
}
Accessor get() {
return Accessor(m_mutex, &m_variable);
}
private:
mutable boost::recursive_mutex m_mutex;
T m_variable;
};
SynchronizedVariable is the actual container for the variable and you can either pass it a constant reference to an existing instance which will be copied or create a new empty instance. The idea is that you should not be able to retain an external copy which can be accessed unprotected. It is of course possible to access the original instance if the variable is copied but this is a limited case of programming error.
Subsequent accesses to the variable must go through an instance of the SynchronizedVariable<T>::Accessor object which ensures that the variable is protected by a mutex and that it is automatically unlocked when the accessor goes out of scope. It is of course possible to add lock/unlock methods to it so that the user can limit the scope of the lock. Personally I try to limit all my scopes as much as possible, especially in areas of code which is executed frequently and during performance sensitive moments.
Accessor is storing the variable as a pointer rather than a reference. The reasoning behind this is that operator-> has to return a pointer so storing a reference does not make a lot of sense. There is also a lot of mutex locking/unlocking going on if you instantiate the accessor in frequently called small scopes so be prepared to dust off gprof if you suspect that this is the case.