Finally switched from Ubuntu to Linuxmint after the 14.04 release. The distribution installed so many packages that I would never use, and the Unity desktop rendered slow on my old thinkpad 🙁
After trying Linuxmint 17 in VirtualBox, I found the color of its default theme is not so good. The mixture of grey and light green, sometimes made it a bit hard to detect borders. It also made me feel comfortless when using eclipse:
So I managed to reuse the default theme of Ubuntu within the cinnamon desktop from Linuxmint:
Here’s what I did:
1
# sudo apt-get install light-themes
This installs the Ubuntu themes. Now edit the theme to add support for Nemo:
1
2
# cd /usr/share/themes/Ambiance/gtk-3.0/
# sudo vi gtk-main.css
Add one line to the end of the file:
CSS
1
@import url("apps/nemo.css");
Create the new nemo.css file:
1
2
# sudo cp apps/nautilus.css apps/nemo.css
# sudo vi apps/nemo.css
Replace all “nautilus” with “nemo”, “Nautilus” with “Nemo”:
1
2
:%s/nautilus/nemo/g
:%s/Nautilus/Nemo/g
Updated Aug 14: Alternative color in Nemo is not available. It seems to be a bug(LP#945430) in the ubuntu theme.
Now open your “Themes” configuration, go to “Other settings” tab. Set “Controls” to “Ambiance”, set “Icons” to “ubuntu-mono-dark”, set “Window borders” to “Ambiance”.
Currently reading C++ Templates: The Complete Guide these days. Just summarize confusions about template function overload & specialization.
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <iostream>
usingnamespacestd;
template<typenameT>
voidfoo(T){
cout<<"in foo(T)"<<endl;
}
/* overload only */
template<typenameT>
voidfoo(T*){
cout<<"in foo(T *)"<<endl;
}
/* full specialization of foo(T *) */
template<>
voidfoo<int>(int*){
cout<<"in foo(int *)"<<endl;
}
intmain()
{
/* The compiler does overload resolution before it looks at specializations. */
foo(newint);
return0;
}
It first selects foo(T *) over foo(T), and use the specialized version foo<int>(int *).
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <iostream>
usingnamespacestd;
template<typenameT>
voidfoo(T){
cout<<"in foo(T)"<<endl;
}
/* overload only */
template<typenameT>
voidfoo(T*){
cout<<"in foo(T *)"<<endl;
}
/* full specialization of foo(T) */
template<>
voidfoo<int*>(int*){
cout<<"in foo(int *)"<<endl;
}
#if 0
/* function partial specialization, not allowed in c++ specification. */
template<typenameT>
voidfoo<T*>(T*){
cout<<"in foo<T *>(T *)"<<endl;
}
#endif
intmain()
{
/* The compiler does overload resolution before it looks at specializations. */
foo(newint);
return0;
}
Here it just selects foo(T *). The foo<int *>(int *) version is not a specialization of it, and is not selected.
Note the syntax of function partial specialization(if possible) here.
Difference between overload and specilization from the book:
In Chapter 12 we discussed how class templates can be partially specialized, whereas function templates are simply overloaded. The two mechanisms are somewhat different.
Partial specialization doesn’t introduce a completely new template: It is an extension of an existing template (the primary template). When a class template is looked up, only primary templates are considered at first. If, after the selection of a primary template, it turns out that there is a partial specialization of that template with a template argument pattern that matches that of the instantiation, its definition (in other words, its body) is instantiated instead of the definition of the primary template. (Full template specializations work exactly the same way.)
In contrast, overloaded function templates are separate templates that are completely independent of one another. When selecting which template to instantiate, all the overloaded templates are considered together, and overload resolution attempts to choose one as the best fit. At first this might seem like an adequate alternative, but in practice there are a number of limitations:
– It is possible to specialize member templates of a class without changing the definition of that class. However, adding an overloaded member does require a change in the definition of a class. In many cases this is not an option because we may not own the rights to do so. Furthermore, the C++ standard does not currently allow us to add new templates to the std namespace, but it does allow us to specialize templates from that namespace.
– To overload function templates, their function parameters must differ in some material way. Consider a function template R convert(T const&) where R and T are template parameters. We may very well want to specialize this template for R = void, but this cannot be done using overloading.
– Code that is valid for a nonoverloaded function may no longer be valid when the function is overloaded. Specifically, given two function templates f(T) and g(T) (where T is a template parameter), the expression g(&f) is valid only if f is not overloaded (otherwise, there is no way to decide which f is meant).
– Friend declarations refer to a specific function template or an instantiation of a specific function template. An overloaded version of a function template would not automatically have the privileges granted to the original template.
<__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>},
members of std::_Vector_base<int, std::allocator<int> >::_Vector_impl:
_M_start = 0x804c040,
_M_finish = 0x804c04c,
_M_end_of_storage = 0x804c050
}
}, <No data fields>}
(gdb)
Under Ubuntu 14.04(Trusty), the 4.8 version of debug package should be installed:
1
# sudo apt-get install libstdc++6-4.8-dbg
There’s an additional step. Since GDB in Trusty is built with python3, not python2, and the python scripts for pretty printers are in python2 syntax. A simple conversion is required:
As title, the key is to set an attribute(PTHREAD_PROCESS_SHARED) to the mutex/condition variable using pthread_mutexattr_setpshared() or pthread_condattr_setpshared(). Without these function calls, the parent in the following code will not get signaled forever.
I’m running Ubuntu 12.04 as host, with VirtualBox 4.2.22. This tutorial should cover guests including Windows XP, CentOS and Ubuntu.
1. Settings in VirtualBox
In the settings page, Check “Enable Serial Port”, set “Port Number” to “COM1”. This is the port number in the guest. If the guest is a Linux, COM1 is shown as /dev/ttyS0, and COM2 is shown as /dev/ttyS1.
Set “Port Mode” to “Host Pipe”, check “Create Pipe” and set “Port/File Path” to “/tmp/vbox”. Seems it utilizes a named pipe. These settings work even if the host does not have a physical serial device.
2. Install minicom
1
2
# sudo apt-get install minicom
# sudo minicom -s
The second command setups minicom with an interactive menu. Select “Serial port setup”, and set “Serial Device” as “unix#/tmp/vbox”(without quotes). “Save setup as dfl” and “Exit from Minicom”.
3. Verity the serial device in guest
Now boot your Linux guest. Run the following command, and it should output something like:
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
...
The guest here is CentOS5, and the serial device is /dev/ttyS0.
4. Communication via serial device
Start minicom on your host:
1
# minicom
Echo something from your guest and redirect to /dev/ttyS0. You host should get the message in minicom.
1
# echo "sent from rhel5 guest" > /dev/ttyS0
To read from the host, cat the device in guest so that you can do the input in minicom:
1
# cat /dev/ttyS0
5. Kernel configuration
CentOS5 comes with grub1, /etc/grub.conf is modified directly to allow the boot information to also be sent to our serial device. The original boot entry looks like:
That’s all for CentOS 5/6. There’s no need to modify /etc/inittab or /etc/securetty file as required in ArchLinux. These OS will do it for you.
Now, reboot your guest CentOS. The boot information should now displayed in your minicom. Finally, it will provide you with a login shell.
You can verify that there’s a new line added into /etc/inittab to enable getty(8) and execute a login shell:
1
co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav
And ttyS0 is also added into /etc/securetty.
6. Ubuntu guest settings
Ubuntu 12.04 come with grub2. We do not modify /boot/grub/grub.cfg, we modify /etc/default/grub instead, so that the serial console parameters will remain even after you update your kernel. Open it, modify the following line to:
One additional step for Ubuntu, is to enable getty(8) for serial console by your own. Ubuntu uses upstart init system, we need to create a file called /etc/init/ttyS0.conf containing the following:
1
2
3
4
5
6
7
8
9
10
# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.
start on stopped rc or RUNLEVEL=[12345]
stop on runlevel [!12345]
respawn
exec /sbin/getty -L 115200 ttyS0 vt102
Reboot you Ubuntu guest, and the serial device should work as it is with CentOS. More info, please refer to the official wiki.
7. Windows guest settings
The serial device shows as COM1 in Windows XP as previously set. With a simple echo and redirect, our host can receive the message.
8. Windows as host
Settings of VirtualBox under Windows is almost the same as that under Linux. But we set “Port/File Path” to “\\.\pipe\vbox”, instead of “/tmp/vbox”. After the configuration of kernel and getty(8), we can use PuTTY to connect. Simply set “Connection type” to “Serial”, and “Serial line” to “\\.\pipe\vbox”.