
Tuesday, 28 December 2010
Tuesday, 23 November 2010
A callgraph for C programs
Egypt neither analyzes source code nor lays out graphs. Instead, it leaves the source code analysis to GCC and the graph layout to Graphviz, both of which are better at their respective jobs than egypt itself could ever hope to be. Egypt is simply a very small Perl script that glues these existing tools together.
Code reuse at its best. Give it a try.
Thursday, 18 November 2010
Brillant corporate inteligence
Don't worry though. Now it'll be renamed to #define ORACLE.
PS: Kind of related is the story about Oracle breaking everything after a %s/Sun/Oracle in the JVM [1], though in that case I'm more inclined to blame sloppy programmers.
[1] http://it.slashdot.org/story/10/07/28/2121259/Oracles-Java-Company-Change-Breaks-Eclipse
Tuesday, 12 October 2010
Easier inbox count with Gmail Favicon script
There's a very cool script to add to your browser but first:
- Do you try to keep your inbox count in 0 (but usually fail miserably)?
- Do you like (need!) to be notified when a new mail arrives?
- Do you like Opera?
If you meet this conditions then you are very sick and need professional help. In the meantime, go and check Gmail Favicon Alerts 3, a cool script which changes gmails favicon to show your current email count. It works on Opera but it makes it crash. Most likely the script is not the one to blame here...
Thursday, 7 October 2010
Template Metaprogramming XVI: Appendix
Monday, 4 October 2010
mv, mf, Ubuntu's "did you mean?"
Some time ago I found about Ubuntu's "did you mean" thingy on console. It's very cool. Of course, I found it after makeing a typo on the console, I wrote mf instead of mv. Ubuntu suggested I was trying to use "mv", but I could install "mf", if I wanted to. I was a little bored, so I researched a little bit what mf is.
Turns out mf is metafont, a programming language to define vector based fonts (!), kind of like postscript. It's written by Donald Knuth, and there are three bits of trivia which make this post somewhat meaningful:
- The program's version number asymptoticaly aproaches e, right now it's on version 2.718281
- rtfm! The section on comments says: Warning: Type design can be hazardous to your other interests. Once you get hooked, you will develop intense feelings about letterforms; the medium will intrude on the messages that you read. And you will perpetually be thinking of improvements to the fonts that you see everywhere, especially those of your own design.''
- And lastly, on the bugs section: On January 4, 1986 the ``final'' bug in Metafont was discovered and removed. If an error still lurks in the code, Donald E. Knuth promises to pay a finder's fee which doubles every year to the first person who finds it. Happy hunting.
Thursday, 30 September 2010
To log or not to log
Logging is nice, we all know that. It saves you from having to stay up all night checking when and why your applications fails. It servers to blame the support guys for not reading it. It's useful to stress test your RAID.
But logging where you shouldn't is a pain in the ass waiting to happen.
When designing an application you should choose between domain level objects, wiring objects, library level objects, helper objects, etc. Your logging should be mostly in the wiring of your applications, not in the helper objects and very rarely in the domain level objects. These objects, when well designed, are supposed to be tested and to be run in a production environment with many different loggers. If you log in the middle of your business object you may end up writing logs through cout when you're testing, or worse, when you're supposed to be logging in syslog.
Monday, 27 September 2010
Know where your objects live
If you work in an environment where memory management is part of your responsibility then you should be aware of the corner cases in which memory management may come and bite you in the ass. Object ownership is one of those areas.
If you are going to take ownership of an object you need to be very explicit about it. A common (and mostly wrong) pattern is taking ownership of an object, by default. Things work great until you end up with a production coredump after trying to free an invalid pointer.
Foo f1;
Foo *f2 = new Foo;
class BadList {
Foo *f1, *f2;
BadList(Foo *f1, Foo *f2) :f1(f1), f2(f2) {}
~BadList(){ delete f1; delete f2; }
}
Seen like that it's more than obvious, but I have seen even experieced programmers fall in this caveat. Related reading: Oh shit the stack.
Friday, 24 September 2010
Thursday, 23 September 2010
Template Metaprogramming XV: Gemini
This is the end. My only reader, the end. After 15 chapters of template metaprogramming you should have learned why staying away from them is a good idea, but if you have been following this series then you should know now when and why they could be useful.
These posts were a compendium of mostly isolated data I found during my travels through the depths of metaprogramming tricks, there are books and people much more capable than me if you want to learn more about this subject (Modern C++ Design by Andrei Alexandrescu comes to mind).
The whole idea of having a cache and a virtual template method was nice, but after seeing the result I decided it was best to have a factory method and an IDL. It may not be so l33t, but whoever has to maintain the code after me will be grateful.
This is the last post on this topic because I feel I have written most, if not everything, I can transmit through this medium but also for an important reason, most likely I won't be working with C++ code so much from now on [1] so there won't be as many chances for me to see the dark, insane, side of this beautiful (in its own way) programming language in a programming language. I know most of you must have barely skimmed through these articles, but I still hope you enjoyed them.
[1] That's right, I'm leaving C++ for the dark side of development, I'll be working with Java from now on. Keep in mind this article may have been written a long time before it's published.
[2] Wow, it was a long time since I used the meta-post category
Tuesday, 21 September 2010
Redshift: Cool your monitor
I've been trying Redshift the last few days. It's a really cool (pun intended) and simple program. It just sits there all day long, doing nothing. Yeap, it's just one more pointless thing on your ps -ef list, up until noon, when it comes to life: it will adjust your monitor's temperature, gradually, from a cool color to a warmer color.
Say what?
I know what you are thinking. "Why the hell did I eat so much cake?". And probably something like "WTF? Monitor temperature? Mine is running cool, k thx bye" too. The monitor temperature (color temperature, to be more accurate) is the percieved temperature of an object emiting light at the specific wavelength of that color:
So, a blueish color means a higher temperature, and it's the natural ambience light color you see during the day. Towards the night the color temperature begins too cool down towards a more orange color. This is the temperature Redshift changes.
So what?
Fair question. After a couple million years our brains got used to seeing a hot color temperature during the day (do I have any reader that old?) so staring at a blue monitor all day will keep you awake all night long, the theory being that switching its temperature towards a reder color will help you sleep at night.
Does it work?
Probably not, but that doesn't make it any less cool (pun not intended). I think if you fine-tune this app to your sleeping hours it may be of some use, because otherwise you'll get a very dark screen at 5pm (don't you people know the timezone in Argentina is FOOBAR'd).
Thursday, 16 September 2010
Quote of the week
It seems making a compile fail is actually quite easy. That’s what I have most experience with.
From "Template metaprogramming", chapter 10 by me
Tuesday, 14 September 2010
Template Metaprogramming XIV: Marathon
If you remember previous entry, we got our evil device to the point of getting a specific instance using only a type hint. Now we need to put all the code together. I won't add much to the code, you should be able to parse it yourself.
/***********************************************/
struct NIL {
typedef NIL head;
typedef NIL tail;
};
template <class H, class T=NIL> struct LST {
typedef H head;
typedef T tail;
};
/***********************************************/
/***********************************************/
template <class X, class Y> struct Eq { static const bool result = false; };
template <class X> struct Eq<X, X> { static const bool result = true; };
/***********************************************/
/***********************************************/
template <class Elm, class LST> struct Position {
private:
typedef typename LST::head H;
typedef typename LST::tail T;
static const bool found = Eq<H, Elm>::result;
public:
static const int result = found? 1 : 1 + Position<Elm, T>::result;
};
template <class Elm> struct Position<Elm, NIL> {
static const int result = 0;
};
/***********************************************/
/***********************************************/
template <typename LST, int N> struct Nth {
typedef typename LST::Tail Tail;
typedef typename Nth<Tail, N-1>::result result;
};
template <typename LST> struct Nth<LST, 0> {
typedef typename LST::head result;
};
/***********************************************/
/***********************************************/
template <typename Lst> struct Instances {
typedef typename Lst::head Elm;
Elm instance;
Instances<typename Lst::tail> next;
};
template <> struct Instances<NIL> {};
/***********************************************/
/***********************************************/
template <int N, typename TypeLst> struct NthInstance {
// This one isnt easy...
// This is the next type in the list
typedef typename TypeLst::tail TypeNext;
// * Nth::result is the Nth type in Lst (i.e. char, int, ...)
typedef typename NthInstance<N-1, TypeNext>::NthInstanceType NthInstanceType;
// * typename Nth::result & is a reference to said type and the ret type
template <typename InstancesLst>
static NthInstanceType& get(InstancesLst &instances_lst) {
return NthInstance<N-1, TypeNext>::get(instances_lst.next);
}
};
// Remember, just for fun we choose a 1-based system (wtf..)
template <typename TypeLst> struct NthInstance<1, TypeLst> {
typedef typename TypeLst::head NthInstanceType;
template <typename InstancesLst>
static NthInstanceType& get(InstancesLst &instances_lst) {
return instances_lst.instance;
}
};
/***********************************************/
class Facade {
typedef LST<int, LST<char, LST<double> > > Lst;
Instances<Lst> instances;
public:
template <typename PK> int find(PK) {
return Position<PK, Lst>::result;
}
template <typename PK>
// This is a difficult one... it should be parsed like this:
// 1) Get the desired instance position using Position::result
// 2) Get the type @ the desired position with NthInstance::Type
// 3) Define said type as a return type (with an & at the end, i.e. make
// it a reference to the return type)
typename NthInstance< Position<PK, Lst>::result, Lst >::NthInstanceType&
get_instance(PK) {
const int idx_position = Position<PK, Lst>::result;
typedef typename NthInstance<idx_position, Lst>::NthInstanceType IdxType;
IdxType &idx = NthInstance<idx_position, Lst>::get( instances );
return idx;
}
};
#include <iostream>
int main() {
Facade f;
int &a = f.get_instance(1);
char &b = f.get_instance('a');
double &c = f.get_instance(1.0);
a = 42; b = 'n'; c = 4.2;
std::cout << f.get_instance(1) << "\n";
std::cout << f.get_instance('a') << "\n";
std::cout << f.get_instance(1.0) << "\n";
a = 43; b = 'm'; c = 5.2;
std::cout << f.get_instance(1) << "\n";
std::cout << f.get_instance('a') << "\n";
std::cout << f.get_instance(1.0) << "\n";
return 0;
}
The only thing missing now is a map, to convert a primitive type to an index type, but that's trivial and so it will be left as an exercise for the reader (?). We just implemented the most evil code in the whole world. Next time, the conclusions.
Thursday, 9 September 2010
Sorting by random in bash and mocp random updated
Random is nice. And now you can sort by random your output using sort -R. Why would this be useful? Well, I updated my mocp random script with a oneliner:
mocp -c && find -type d | sort -R | head -n1 | awk '{print """$0"""}'; | xargs mocp -a
Tuesday, 7 September 2010
C++ linking WTF
It is a commonly accepted fact that a succesfuly compiled application serves as enough proof of its correctness, but common wisdom doesn't say a thing about linking. If you like linker WTF moments, you'll love this snippet. Can you guess why won't it compile?
struct Foo {
static const int x = 0;
static const int y = 1;
int z(bool x){
return (x)? Foo::x : Foo::y;
}
};
int main() {
Foo z;
std::cout << z.z(true);
return 0;
}
Well, it does compile (gotcha!) but it just won't link. Yet it seems so simple... let's add some more mistery to this WTF moment, try this change:
int z(bool x){
int t = Foo::x;
return (x)? t : Foo::y;
}
Holy shit, now it compiles? WTF? Some more strangeness:
int z(bool){
return (true)? Foo::x : Foo::y;
}
And again, now it compiles. WTF? I'll make a final change, this one should give you a clue about why it won't compile. Revert all changes back to the original code but add this two lines after Foo:
const int Foo::x;
const int Foo::y;
Though weird at first, now you should have a clear picture:
- The first case doesn't compiles: x and y are declared in struct Foo, yet the linker doesn't know in which translation unit they should be allocated.
- The second and third cases... well I'm not sure why does this compiles but it's probably because the linker can asume in which translation unit x and y should be allocated. I'm to lazy to check.
- In the last case we explicitly say where should x and y be. According to standard, this is how these two ints should be declared.
So, some linker strangeness. Beware, it's easy to get trapped by this one.
Thursday, 2 September 2010
Vim Sexual Care
Tuesday, 31 August 2010
Template Metaprogramming XIII: Heart of Darkness
Last time we had a virtual template dispatch problem... we got to the point of knowing which was the index of the cache we were searching for, now we need to actually retrieve an instance of that cache. That's a problem. Why? To begin with, there are no instances, only types!
The next logical step would be to create a Map device, to map a list of types to a list of instances... let's see how can we do that, in pseudocode
instances( H|T ) <- [ create_instance(H), instances(T) ]
instances( NIL ) <- NIL
Looks easy. How can we map that to c++?
template <class Lst> struct Instance {
typedef typename Lst::head Elm;
Elm instance;
Instance< typename Lst::tail > next;
};
template <> struct Instance<NIL> {};
#include <iostream>
using std::cout;
int main() {
typedef LST<int, LST<char, LST<float> > > Lst;
Instance<Lst> lst;
lst.instance = 1;
lst.next.instance = 'a';
lst.next.next.instance = 3.1;
std::cout << lst.next.instance << "n";
return 0;
}
All those next.next.next.instance look ugly. Let's use some more meta-magic to get the Nth instance (why not a [] operator? several reasons, you can't mix non-const ints with templates nicely, there would be problems to define the return type... all those options are workable but it's easier if we do this in another device.
template <typename LST> struct Nth {
typedef typename LST::tail Tail;
typedef typename Nth::result result;
};
template <typename LST> struct Nth {
typedef typename LST::head result;
};
Remember that one from the toolbox? Now we know how to get a specific index position, yet getting the instance is a different problem (the Nth device returns a type, not an instance). We should do something different, the problem is knowing the return type. What's the return type for the Nth instance of the Instances list?
type <- Nth(TypesLst, Type)
type var <- NthInstance(InstancesLst, N)
Not so easy, right? This is the translated C++:
template <int N, typename TypeLst> struct NthInstance {
// This one isnt easy...
// This is the next type in the list
typedef typename TypeLst::tail TypeNext;
// * Nth::result is the Nth type in Lst (i.e. char, int, ...)
typedef typename NthInstance<N-1, TypeLst>::NthInstanceType NthInstanceType;
// * typename Nth::result & is a reference to said type and the ret type
template <InstancesLst>
static NthInstanceType& get(InstancesLst &instances_lst) {
return NthInstance::get(instances_lst.next);
}
};
// Remember, just for fun we choose a 1-based system (wtf..)
template <typename TypeLst> struct NthInstance<1, TypeLst> {
typedef typename TypeLst::head NthInstanceType;
template <InstancesLst>
static NthInstanceType& get(InstancesLst &instances_lst) {
return instances_lst.instance;
}
};
And the code from fetching the instance itself is even more difficult, so I'll leave that for next time.
Thursday, 26 August 2010
Date time WTF
Tuesday, 24 August 2010
Template Metaprogramming XII: You Really Got a Hold on Me
Remember our virtual template method problem, from the other time? (I know, I said the answer was scheduled for a week after that post, but then I just forgot about it). May be we could avoid the virtual part by keeping a list of all our caches... how would we know which one should we dispatch the message to? Easy, using templates.
Instead of a list let's keep two, for twice the fun. One for the rows cache, another for the PKs. We can use PK to know which ROW Cache should we choose. Let's try to write a pseudo code for it:
ROW get_row(PK id) {
pos <- Position of PK in pks_lst
return cache[ pos ].get_row( id )
}
Doesn't look too hard. Building on our previous toolbox, let's use Eq, Position and the definition of a list:
struct NIL {
typedef NIL head;
typedef NIL tail;
};
template < class H, class T=NIL> struct LST {
typedef H head;
typedef T tail;
};
template <class X, class Y> struct Eq { static const bool result = false; };
template <class X> struct Eq<X, X> { static const bool result = true; };
template <class Elm, class LST> struct Position {
private:
typedef typename LST::head H;
typedef typename LST::tail T;
static const bool found = Eq<H, Elm>::result;
public:
static const int result = found? 1 : 1 + Position<Elm, T>::result;
};
template <class Elm> struct Position<Elm, NIL> {
static const int result = 0;
};
class Facade {
typedef LST<int, LST<char, LST<float> > > Lst;
public:
template <class PK> int find(PK) {
return Position< PK, Lst >::result;
}
};
#include <iostream>
using std::cout;
int main() {
Facade f;
std::cout << f.find(1.0) << "\n";
return 0;
}
Great, now we can find an element on a list of types. The real virtual dispatch for the next entry :D
Thursday, 19 August 2010
MySQL upsert, Oracle merge
How many times have you seen this "pattern"?
unsigned int row_count = foo->update();
if (row_count == 0) {
foo->insert();
}
Wouldn't it be nice if you could write all that in a single line? Say, something like
foo->update_or_insert_if_it_doesnt_exists();
Well, good news, you can! Obviously it's not standard SQL, nothing useful ever is, but even so I think using an upsert (who comes up with those names?) can be quite good for your health.
So, how do you use it? It's easy;
INSERT INTO Table ( col1, col2 )
SELECT 'a', 'b'
ON DUPLICATE KEY UPDATE col1 = 'a', col2 = 'b';
Go on, try it, I'll wait. What? It didn't work? Oh, I forgot, you need to create a unique key so the engine can recognize when there is a duplicate key (say, 'create index unique on col1'). Try it now.
Nice, isn't it? Oracle has its own version of upsert, called merge (at least the name is better) but it itches a little bit when I write about Oracle, so go and check this page instead.