Recover nvida driver on ubuntu 12.10

I have a GTX260 on my desktop. And yesterday I was playing around with "Addiion Drivers" in Software Update, and accidentally change the driver to something doesn't work for me.

So when I start my computer today it shows very disappointing 800 x 640

Anyway, I recovered the driver with following steps:

1. open a terminal Ctrl + Alt + t
2. install headers and sources for 12.10
    sudo apt-get install linux-headers
    sudo apt-get install linux-source
    sudo apt-get install linux-headers-`uname -r`

3. update nvidia-current
    sudo apt-get install nvidia-current

4. grep to see if nvidia-current is loaded now. If not, try to loaded it
    sudo depmod -a    // build modules dependency list
    sudo modprobe nvidia-current

5. reboot
   someone may argue you can just "sudo restart lightdm", but that doesn't work for me.

Hope this helps!

How much memory is taken by boolean array?

I run into a problem which is solved by BitSet. But I asked myself, why not just using an array of boolean?

This article gives the answer in Java. http://chrononsystems.com/blog/hidden-evils-of-javas-byte-array-byte

Basically, Java takes a byte, instead of a bit, to store a bool. So it ends up using an array of bytes.

Same for C++.

And think it over, malloc allocates memory in bytes, isn't it?

void* malloc (size_t size);

Allocate memory block

Allocates a block of size bytes of memory, returning a pointer to the beginning of the block.

So no wonder this happens.

Use Bitset instead.

ldd diagnose dependencies of a object file

Today I run into this error again: 

couldn't load file "/opt/tcl8.5.9/lib/yajltcl1.3/libyajltcl1.3.so": libyajl.so.2: cannot open shared object file:

 No such file or directory

Obviously, we are looking for libyajl.so.2 from libyajltcl1.3.so, but we can not. So I run

ldd /opt/tcl8.5.9/lib/yajltcl1.3/libyajltcl1.3.so:

linux-vdso.so.1 =>  (0x00007fff6d5ff000)

libyajl.so.2 => not found

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbc2d61c000)

/lib64/ld-linux-x86-64.so.2 (0x00007fbc2dbe4000)

I checked if libyajl.so.2  exists at all. It sits in /usr/local/lib. The immediate reason pop into my head is /usr/local/lib is not included in LD_LIBRARY_PATH. And that's the issue.

Solved :)

Undefined reference to template class functions

As the answer said this is a common question for c++ newbies. But I feel like marking it down on my blog. Here's the story:

This is a common question in C++ programming. There are two valid answers to this. There are advantages and disadvantages to both answers and your choice will depend on context. The common answer is to put all the implementation in the header file, but there's another approach will will be suitable in some cases. The choice is yours.

The code in a template is merely a 'pattern' known to the compiler. The compiler won't compile the constructors cola<float>::cola(...) and cola<string>::cola(...) until it is forced to do so. And we must ensure that this compilation happens for the constructors at least once in the entire compilation process, or we will get the 'undefined reference' error. (This applies to the other methods ofcola<T> also.)

Understanding the problem

The problem is caused by the fact that main.cpp and cola.cpp will be compiled separately first. Inmain.cpp, the compiler will implicitly instantiate the template classes cola<float> andcola<string> because those particular instantiations are used in main.cpp. The bad news is that the implementations of those member functions are not in main.cpp, nor in any header file included inmain.cpp, and therefore the compiler can't include complete versions of those functions in main.o. When compiling cola.cpp, the compiler won't compile those instantiations either, because there are no implicit or explicit instantiations of cola<float> or cola<string>. Remember, when compilingcola.cpp, the compiler has no clue which instantiations will be needed; and we can't expect it to compile for every type in order to ensure this problem never happens! (cola<int>, cola<char>,cola<ostream>, cola< cola<int> > ... and so on ...)

The two answers are:

• Tell the compiler, at the end of cola.cpp, which particular template classes will be required, forcing it to compile cola<float> and cola<string>.
• Put the implementation of the member functions in a header file that will be included every time any other 'translation unit' (such as main.cpp) uses the template class.

Answer 1: Explicitly instantiate the template, and its member definitions

At the end of cola.cpp, you should add lines explicitly instantiating all the relevant templates, such as

template class cola<float>;
template class cola<string>;

and you add the following two lines at the end of nodo_colaypila.cpp:

template class nodo_colaypila<float>;
template class nodo_colaypila<std :: string>;

This will ensure that, when the compiler is compiling cola.cpp that it will explicitly compile all the code for the cola<float> and cola<string> classes. Similarly, nodo_colaypila.cpp contains the implementations of the nodo_colaypila<...> classes.

In this approach, you should ensure that all the of the implementation is placed into one .cpp file (i.e. one translation unit) and that the explicit instantation is placed after the definition of all the functions (i.e. at the end of the file).

Answer 2: Copy the code into the relevant header file

The common answer is to move all the code from the implementation files cola.cpp andnodo_colaypila.cpp into cola.h and nodo_colaypila.h. In the long run, this is more flexible as it means you can use extra instantiations (e.g. cola<char>) without any more work. But it could mean the same functions are compiled many times, once in each translation unit. This is not a big problem, as the linker will correctly ignore the duplicate implementations. But it might slow down the compilation a little.

Summary

The default answer, used by the STL for example and in most of the code that any of us will write, is to put all the implementations in the header files. But in a more private project, you will have more knowledge and control of which particular template classes will be instantiated. In fact, this 'bug' might be seen as a feature, as it stops users of your code from accidentally using instantiations you have not tested for or planned for ("I know this works for cola<float> and cola<string>, if you want to use something else, tell me first and will can verify it works before enabling it.").

size_t is not unsigned int !!

I always consider size_t is just a typedef of unsigned int and that drops me to the torment today for hours. 

The thing I am trying to do is simple. It's a socket write and read. 

write:

...

size_t length = _value.size();

boost::asio::write(*sock, boost::asio::buffer((const char*)&length, sizeof(length)));

...

read:

...

int length = -1;

boost::asio::read(*sock,

            boost::asio::buffer(&length, sizeof(length)));

...

And this bit of code stirs up the whole program. 

After hours of probing around, I happened to find out the issue is caused by with size_t. Because its size is different from int on the receiver end.

Here is the nice explanation from wiki:

The C language provides the separate types size_t and ptrdiff_t to represent memory-related quantities. Existing types were deemed insufficient, because their size is defined according to the target processor's arithmetic capabilities, not the memory capabilities, such as available address space. Both of these types are defined in the stddef.h header (cstddef header in C++).

size_t is used to represent the size of any object (including arrays) in the particular implementation. It is used as the return type of the sizeof operator. The maximum size of size_t is provided via SIZE_MAX, a macro constant which is defined in the stdint.h header (cstdint header in C++). It is guaranteed to be at least 65535.

It's clearly said size_t is platform dependant. Cool, it's portable. With a small program, I found size_t is 8 bytes on my machine, and int is 4.

More info for size_t here : http://www.embedded.com/electronics-blogs/programming-pointers/4026076/Why-size-t-matters  Altougth I haven't read it, could be interesting.

fun!fun!fun!

Hadoop RPC is not RMI

I never closely looked IPC protocols in hadoop. Just run into this today, and luckily, found the explanation from the inventor:

Why use Hadoop IPC over RMI or java.io.Serialization? Here's what Doug has to say:

Why didn't I use Serialization when we first started Hadoop? Because it looked big-and-hairy and I thought we needed something lean-and-mean, where we had precise control over exactly how objects are written and read, since that is central to Hadoop. With Serialization you can get some control, but you have to fight for it.

The logic for not using RMI was similar. Effective, high-performance inter-process communications are critical to Hadoop. I felt like we'd need to precisely control how things like connections, timeouts and buffers are handled, and RMI gives you little control over those.

 I am going to brew my own RPC protocol in C++ as well !

c++ segmentation fault and undefined behaviour causes

1.I run into a issue when I call a function from a object it throws a Segmentation fault. It turns out to be the problem that I did n't make a copy of dynamic allocated elements when copying a object. The default copy constructor (and/or operator=) may not handle that correctly.

Details are explained well in this post:

http://www.cplusplus.com/forum/general/28420/

2. when you reference a item, but that item was deallocated already.
e.g.

class A {
    tcp::socket _sock;

public:
    void connect() {
        tcp::io_service _io_service;
        _sock = tcp::socket(_io_service);
    }
...
}

When connect() is called _sock is assigned with the connection socket. But _io_service is destructed when connect() finishes.

3. Destructor not virtual.