After some fiddling, I found out: it works perfectly. The only thing that’s blocking the 3D feature is that the samples I tried were not in HD. Apparently the TV requires the source file to have a 1920×1080 resolution. Once you got the file in the right format, it works like a charm and you can enable the 3D feature via the on-screen menu.

Here is a quick command to re-encode a clip in the right resolution and in a format that the TV can definitely read:

$> mencoder 3d-sample-in.avi -vf scale=1920:1080 -o 3d-sampe-out.avi \\
   -oac mp3lame -ovc lavc -lavcopts vbitrate=2200

Mencoder is part of the mplayer software package. I have not optimized the above line for performance or size… using different encoder options may result in a much better result.

Preface:

This is a series of posts that explain how to get to a nicely colored shell by tweaking your .bahsrc.

I am aware that each of these hints has been discussed on the Internet forever. However, it took me a little while to get all into my .bashrc, so I hope this will be useful for someone.

Colorful directory listings (ls)

Getting color to ls is fairly easy. You basically just turn it on. However, depending on your OS, you may have to push different buttons to get it working.

For OS X, adding

CLICOLOR=1

to your .bashrc is already enough. I tested it for iTerm and the OS X Terminal and both worked like a charm.

For Linux, things are slightly more tricky because you need to tell ls that it should use colors.

Therefore, adding

CLICOLOR=1

to your .bashrc will only produce colorful directory listings if you do

ls --color=auto

This is somewhat inconvenient but luckily, there are aliases. Just add:

export CLICOLOR=1
alias ls='ls --color=auto'

to your .bashrc and you’re done.

Making the colors more colorful

If you find the colors too dark or too bright for your terminal settings, you may want to adjust the colors of the different file types.

For OS X you can simply do this by overwrituing the variable LSCOLORS with your own settings:

export LSCOLORS=dxfxcxdxbxegedabagacad

The ugly string indicates your color preferences. It is well explained in the manpages for ls (man ls). Just search for LSCOLORS.
I’ll add a brief explanation anyway:

The string is composed of pairs of color indexes (e.g., dx, fx, cx, dc, … in the example). Each letter is a color index. The first letter indicates the foreground color (d=brown) the latter the background color (x=default foreground or background = invisible). The position also matters. The first pair defines colors for directories, the second defines symlinks, etc. All this is explained quite neatly in the man pages so I hope you forgive me if I don’t repeat it all.

For Linux things work a bit different again (sigh!)

Here the variable is not LSCOLORS but LS_COLORS (great job, OS X and Linux guys!)

So you could set the following in your .bashrc

LS_COLORS='di=33:fi=0:ln=95:pi=5:so=5:bd=5:cd=5:or=37:mi=0:ex=31:*.rpm=90'

In contrast to OS X, the pairs are named here. di stands for directory, fi for file, ln for a symlink…
The numbers stand for colors and you can even add multiple numbers for one thing if you like to have underlined, flashing or otherwise fancy-looking colors.

If you want to delve deeper into the topic I suggest to follow this LINK. It explains the whole color concept quite well.

Making it work cross platform

If you intend to use the same .bashrc across Linux and Mac systems you might want to add some smartness to this.

Here is some example code. I think it is simple enough to go without further explanation:

# don't do this for dumb terminals
if [ "$TERM" != "dumb" ]; then
 if [ $(uname) == "Linux"  ]; then
   # Linux
   alias ls='ls --color=auto'
   LS_COLORS='di=33:fi=0:ln=95:pi=5:so=5:bd=5:cd=5:or=37:mi=0:ex=31:*.rpm=90'
 else
   # OS X   
   alias ls='ls -G'
   export LSCOLORS=dxfxcxdxbxegedabagacad
 fi
 #This is for everyone       
 export CLICOLOR=1
fi

I may have stolen parts of the above example code from here and there. I tried to figure out where it all came from but it is so basic that determinung the exact origin is impossible. If you feel that you deserve credit for it, please tell me and provide a link to your blog/post/whatever.

Use malloc often, then memset everything. [don't do this at home]

The bad thing about that strategy is that it leads to complex code and non-obvious bugs. The following mini-tutorial is based on some slides I prepared for a small tutorial for our students at RWTH Aachen University.

I’d like to state that for the sake of simplicity I did not go into const correctness for variables and functions. Adding const correctness is left to the interested reader (just as we did the const correctness on the fly during the tutorial).

Memory is not just memory:

When writing basic C code, you have to distinguish between two types of memory. I’ll not go into details here but I’d like to point out the most obvious differences. If you’d like to know more about memory in C, I am confident that your google skills will get you to the right documents.

• Stack  - the simple kind of memory.

• Heap – the “shoot yourself in the knee”-kind of memory.

Try to use stack memory whenever possible. The reason? It’s simple, its bound to the current program context and if the program leaves the context its automatically freed. That means: the memory is automatically freed when you don’t need it any more.

Well, there are some reasons to still use heap memory:

Especially the third reason is tricky. I’ve seen [beginners/programmers] who used malloc just because they thought it would be the [only/most convenient] way to have a pointer to a piece of memory. The bottom line is: try to avoid malloc and heap memory whenever possible.

Avoid magic numbers in combination with malloc

Okay, now that we know that malloc is evil, it’s time to talk about using it right. Unfortunately, malloc seems to attract, so called, magic numbers. Let me give an example:

Bad:

malloc(20);
malloc(BUFF_SIZE+12);

This code is almost guaranteed to break as soon as anyone changes anything related to the memory. Moreover, you will drive your poor fellow students and colleagues crazy because they have no clue why 20 or 12 is the right magic number. Maybe 21 or 11 would be much better? Simply do’t do it but try to use sensible names or even better: sizeof.

Better:

malloc(sizeof(struct foo));

Here you can easily figure out why malloc allocates the amount of memory it does. We’re going to put at struct foo to that piece of memory. Great.

Avoid malloc completely

In many cases, malloc can be avoided completely. This will simplify the code and will add to its maintaiability. Let me give you a code example:

EXAMPLE 1

// the return value has to be freed. Don‘t forget it!
struct foo* bar(void){

    struct foo *baz;
    baz = malloc(sizeof(struct foo));

    // do something with baz
    ...

    return baz;
}
struct foo* baz;
baz = bar();

// do something fancy with baz for 80 lines
...

free(baz); // Phew, I am so proud that I remembered it!

Okay,  this code isn’t really bad by itself. It works and it will do whatever it was meant to do. However, it blocks programmer brain cycles. You as a programmer have to make sure that you remember to free baz in the end (and never remove it from there unless you remove baz). Otherwise the code will still do what it was supposed to do but as a little bonus, it will start eating up your memory if it is executed repeatedly.

It’s rather simple to avoid malloc and free here completely:

void bar(struct foo* baz){
    // do something with baz

    return baz;
}

...

struct foo baz;
bar(&baz);

// do something fancy with baz for 80 lines

The code still does the very same thing but there is no malloc and no free any more. We avoided the use of these two functions by creating an auto variable at the caller and by passing it to the callee. Oh, yes: Here you should definitely start thinking about const correctness in your code because the function bar will modify its parameter baz. This might not be obvious unless you a) put some comment there (yes, a bad option) or b) add const to all function parameters that are not modified by the function. However, that’s another story for another day.

EXAMPLE 2

unsigned int len;
len = string_oracle();

char* baz;
baz = malloc(len);

...

//do something with baz

foo(baz, len);

...

free(baz);

The reason why we used malloc in the above code is that we don’t know how long the length of the string baz will be. The len parameter comes from the mysterious string_oracle() function and there is no defined length since the nasty oracle may return anything. However, if the string oracle is not that mysterious but has an upper bound (e.g., LONGEST_STRING_LEN) for the length of the string, we can do the following:

unsigned int len;
len = string_oracle();

char baz[LONGEST_STRING_LEN];

...

//do something with baz

foo(baz, len);

...

The worst-case assumption that the string oracle will return a length smaller than LONGEST_STRING_LEN allows us to get rid of malloc and free. In many cases you can make such worst case assumptions.

If you read the above example carefully you will notice that the code is still a bit shaky. Of course, the contents of len must never be larger than LONGEST_STRING_LEN. Otherwise, the program [might/will] crash with a segmentation fault. Hence, you should check for the length of len and do some nice error handling.

Memset

For all I know, memset seems to be the best friend of malloc. You can be quite sure to see a memset wherever you see malloc. There is even a shorthand for the combination of memset and malloc: calloc. In some cases using memset and malloc is not a bad thing. However, in some cases it is a) unnecessary or b) may mask errors. I’ll give you two examples:

EXAMPLE 1

char* foo = "Hey, my code works!";
unsigned int len = 20; // len is the length of foo

char* bar;
bar= malloc(len);

// my advisor told me I should ALWAYS use memset 0!
memset(bar, 0, len);
memcpy(bar, foo, len);

printf("%s ... and it is totally braindead.\n", bar);

Here the memset is absolutely unnecessary because the code is first set to 0 and then completely overwritten. Of course, the code will work but it a) will do to much, and b) is too complicated. Complicated code attracts bugs , so why make it more complicated than it needs to be. just remove the memset.

Okay, now what is memset good for then? Initializing memory to 0 (zero) or any other value — memory that should be set to something for a reason. Okay, but memset can be tricky in that case, too. It might set too much memory to something – memory that is not supposed to be something. Let me give an example:

EXAMPLE 2

Compilers are pretty good in helping programmers to do the right thing. One very useful thing is that gcc can tell you when you forgot to initialize a variable. Just try:

$> gcc foobar.c -Wuninitialized –O1

on any c file foobar.c that tries to read an unitialized variable bar.foo3. The compiler will complain like this:

warning: ‘bar.foo3’ is used uninitialized in this function

Okay, now consider the following example code:

struct foo {
    unsigned int foo1;  // initialize to 1!
    unsigned int foo2;  // initialize to 2!
    unsigned int foo3;  // initialize to 3!
};

...

struct foo bar;

// my advisor told me I should ALWAYS use memset 0!
foo = memset(&bar, 0, sizeof(struct foo));

// when initialized, foo1 must always be 1, foo2 always be 2 and foo3 always 3
bar.foo1 = 1;
bar.foo2 = 2;
// oops. I am in a hurry. I'll do the rest tof the initialization later. 
...
if (bar.foo1 == bar.foo3) {...}

Now consider our hasty programmer did not do the rest of the initialization later (maybe he even forgot to put that comment there). As he diligently set the memory of bar to zero, bar.foo3 is initialized and the compiler can’t tell us something is wrong. Here memset masks a bug that would have been trivial to find (even the compiler will tell you) otherwise:

$> gcc foobar.c -Wuninitialized –O1
... (NOTHING!)

For more  evil examples of memset read this article. It explains what happens when you apply memset with non zero values (it doesn’t do what people expect for multi-byte types) and for more complext types (structs, objects, double pointers, etc.).

Well, this concludes my little tutorial. Thanks for reading and happy coding.

pbcopy copies stdin to the OSX clipboard. pbpaste copies the clipboard content to stdout. Combining both allows you to perform complex operations on your clipboard contents. Need an example:

pbpaste | fmt -s -w 80 | pbcopy

will format the text in your clipboard so that it breaks at a text width of 80 characters. very good if you need to write technical documents with fixed character width. I guess you can easily imagine any text-based workflow. Just think of what stream processing you can do with html tidy, aspell, etc.

Of course, putting your pbpaste/pbcopy chain to a script that you can conveniently run from any shell or binding it to a key combination will make the whole thing even more useful.

I found this works for OSX. Maybe there is an equivalent for Linux as well. Any hints?

RFC2828 is a must for everyone writing about network security:

http://www.ietf.org/rfc/rfc2828.txt

This post is an attempt to remove my confusion when using opendiff AKA filemerge. Opendiff is a very handy and quick tool for visually comparing files. However, the way it visualizes the portions of two files that are to be merged into one keeps confusing me. The symbol is an arrow, However, I always wonder whether the direction of the arrow symbolizes the direction of the changes (text at the blunt edge of the arrow will survive) or if the pointed part of the arrow points at the text that will survive.

The message to me is:

“THE TEXT AT THE ARROWHEAD WILL SURVIVE”.

Keep this in mind, Tobias!

svn propedit svn:log --revprop -r N --editor-cmd vim

of course, you have to replace N with the proper version number. Pick another –editor-cmd if you don’t fancy vim.

First create a wrapper file that will handle the calling of filemerge or vimdiff. I put it into ~/bin/svndiffwrap.sh

#!/bin/sh
DIFF="$(which opendiff)"
DIFF $6 $7

opendiff is the command line tool for filemerge. Put vimdiff there if you like vim better.

Next tell svn to use your beautiful shiny new script. Edit ~/.subversion/config search for diff-cmd and replace it with:

diff-cmd = /Users/heer/bin/svndiffwrap.sh

Of course /Users/heer/bin/ should be the path to your newly created script.  Next try svn diff and love it.

I am co-organizing the “Mobile Collaboration Systems” workshop in Aix-en-provence next week. The workshop will be a platform to share and discuss theories, understandings, experiences and lessons learned in the field of mobile collaboration systems. The workshop is held in conjunction with the COOP’10 conference.

From the call for papers: Mobile devices are expected to soon become the “primary computer” and tool for sharingand connecting with others. In our thriving world of mobile communication, technologicaladvances have brought a number of novel and improved ways of collaboration; in business, commerce, healthcare, education, and society in general. Collaboration can help to overcome the limitations of a single user, device, and network. However, creating mobile collaborative applications and systems requires careful consideration and design. This workshop aims to bring together designers, practitioners and researchers who share an interest in the study and design of mobile collaborative systems.

UPDATE: The workshop was very interesting and productive. We benefitted from a very diverse set of people, research areas and opinions. A perfect combination for a topic that spans social and technical aspects.

Large-scale municipal wireless networks are currently being established all around the world. These networks provide a rich set of local services, such as tourist guides, environmental information, pedestrian navigation, and local shopping guides. As recent financial failures of prominent municipal wireless networks show, it is economically challenging to achieve the bandwidth and coverage that is necessary for such a network. At the same time, Wi-Fi-sharing communities achieve high bandwidth and good coverage at a very low cost by capitalizing on the dense deployment of private access points in urban areas. However, from a technical, conceptual, and security perspective, Wi-Fi sharing community networks resemble a patchwork of heterogeneous networks instead of one well-planned, uniform and secure network as required for the economic success of a municipal Wi-Fi project. In this paper, we show how to realize municipal wireless services on top of a Wi-Fi-sharing infrastructure in a technically sound and economically attractive fashion while taking into account legacy devices and mobile clients. Our solution cleanly separates the roles of controlling and administering the network from providing bandwidth and wireless access. This allows municipalities to focus their resources on municipal wireless services instead of providing Wi-Fi access.