Monday, October 31, 2011

Insight into an GObject's lifetime.

My favourite Space Station

I just needed a quick way to get an overview over the lifetime of a specific instance of a Vala class.
Thus I need some informations about it's creation - and more important - it's destruction time.
robster pointed me to gobject-list a small library which is preloaded and tracks gobjects' _ref and _unref calls - so a great tool for vala code.

It's simple to get it up and running on Fedora:
$ sudo yum install libunwind-devel glib2-devel
$ git clone git://
$ make
$ cd /path/to/myapp/
$ LD_PRELOAD=/path/to/ myvalaapp | grep MyClass

More can be found in Danielle's initial post and more about vala's memory management can be found here.

Friday, October 28, 2011

Expressing vapi dependencies in automake.

Today I ran into trouble defining dependencies between different vala files I use within presence.
Automake allows to define dependencies based on targets (like a library libui.a or sources ui.c). But how can I add a dependency on a .vapi? (This dependency might be needed, because app is using some code from libui.)

If I just add a dependency on the library level, make fails when looking for the library while generating the C-Code. Look at the following example:

app_SOURCES = main.vala
app_LIBADD = libA.a libB.a

In the above example main.vala already needs informations about libA and libB when valac is generating the C-Code. But this doesn't work in a parallel build, when libA or libB's vapi is not yet generated.
So I needed to tell automake/make somehow to depend on the .vapi files of libA/libB - but how? Automake doesn't know about vapis and doesn't provide any targets for them.

But it seems as this can be solved like this: You can tell automake to depend on the .c file corresponding to your .vala (and so .vapi) file, as the .c file is generated at the same time the vapi is generated. And - oh wonder - automake has targets for the c files generated by valac, therefor it's possible to use the .c files as dependencies when you mention them in the _SOURCES part of the target in question.

app_SOURCES = main.vala libA.c libB.c
app_LIBADD = libA.a libB.a

Adding the .c files to the sources doesn't do any harm, but allows app to depend on the availability of (a) the vapis and (b) the libs for libA and libB. So dependencies on both levels (code generation and linking).

Have a look at this for my real world example.

There is a high probability that I've missunderstood or forgot something. Hints and comments are welcome.

Thursday, October 27, 2011

Fixed: Suspend and Resume on Lenovo x121e

Lately - after using suspend and resume extensively - I've quickly noticed, that the wireless card doesn't come back to live after resume. After filing a bug and getting help - it was somewhat dump not to update my bios after right away - I got the bug fixed using this BIOS/EFI update from Lenovo.
While burning the ISO onto a CD-ROM I found this bug: When nautilus removes the CD drive from the system and doesn't eject the CD-ROM when pressing the "eject" button in nautilus' sidebar.
A last word regarding suspend and resume - I am not completely convinced that the wireless always returns from suspend ...

substanziell - Backup your document. is a nice document authoring and publishing for the web - but sometimes it has it hickups and you can loose parts of your document. No good, but - hey - let's make backups.
After exporting your cookies (using some Export cookies Firefox add-on), you can use the following while-loop to backup your progress regularly into a a clean git repository.
while true ; 
do \
  curl -O -b cookies.txt \$USERNAME/$DOCUMENTNAME.latex ; \
  git commit -asm"Auto-save." ; \
  sleep 60 ; \
And thanks to _mql for getting back some lost lines.

Friday, October 21, 2011

Da sein - Introducing presence a tool for »videoconferencing«

Intended purpose: Use this application to transmitt audio and video in an n-to-m-peers fashion in quite high quality and with a hopefully low latency. This can be the case in scenarios like connecting video walls, e-lecture or simple bi-directional two people communication.

Intended audience and requirements: This application is designed for an elite circle of users who are in a situation with:
  • no NAT problems, e.g. IPv6 users
  • one multicast domain or access to their DNS records
  • quite high bandwidth, like 2 Mb/s
  • secured transport way, aka VPN or or non-public network
  • multi-core systems (single core Intel Atoms are a no-go), but something like an AMD E-350
  • Fedora 16

Design: Trageting a very specific need (near-realtime bi-directional a/v transmission in a good quality, not caring about bandwidth and security) this tool also doesn't follow public standars like RFCs, but more builds ontop of available features (e.g. gstreamers rtpgstpay). On the other side standards are use:
  • RTSP stream control
  • dirac video codec
  • vorbis audio codec
  • mdns service discovery
  • Mx based interface
  • Fulscreen mode
  • IPv6 support
Currently presence is some kind of beta. Find out more on the appropriate page.

Tuesday, October 18, 2011

Update on EFI and Fedora 16 Live images.

Somehow Fedora 16 re-gained EFI support - after it was lost in the beginning of the Fedora 16 process. The trouble seems to be introduced partly because of the migration to grub2 or changes to anaconda.
But as of Fedora 16 TC1 also the Live CDs support EFI! Look here to learn how to make a bootable USB media from the iso you downloaded.

As we already know, the installation DVDs already support EFI, since rc3 (or so).
Participate and provide some feedback (e.g. via IRC or bugzilla) on bugs when testing out the media.

Thursday, October 13, 2011

Building gcc-4.3.4 on Fedora 15

Currently you need to rely on proprietary drivers to use CUDA or OpenCL on a GPU under Linux.

There is clover a OpenCL implementation capable of running on a CPU - but in my case I had to use CUDA. And CUDA requires gcc 4.3.4, which is not available for Fedora 15 natively, so we have to build it our self.
Actually it is quite straight to build it.
Install some requirements:
$ sudo yum install glibc-devel.i686 glibc-devel.x86_64 \
    gmp-devel mpfr-devel
Fetch the source:
$ mkdir gcc
$ cd gcc
$ curl -O \
And finally configure, build and install it. It took around 20minutes on my machine. I installed this gcc version not in my native PATH, as I didn't want any collisions, I choose ../build as a suitable destination. In this case you have to remember to modify your PATH and LD_LIBRARY_PATH environment variables. So the app (e.g. nvcc) in question is looking in the right path when calling gcc.
$ export DST="${PWD}/../build"
$ mkdir "$DST"
$ nice ./configure --prefix="$DST" \
    --with-gmp=/usr/lib/ --with-mpc=/usr/lib/ --with-mpfr=/usr/lib/
$ nice make -j8
$ make install
I can also consider adding the --program-suffix=4.3.4 to add the given suffix to all binaries, this makes sense when you install this build into %{_bindir} and %{_libdir}.
Finally you can launch nvcc or whatever application is requiring gcc-4.3.4.
$ PATH="${DST}/bin:$PATH" LD_LIBRARY_PATH="${DST}/lib64:${DST}/lib" \
    nvcc [...]

Wednesday, October 12, 2011

Hinterher - Tracing vala (c-) code with systemtap.


As many others I've read Richard's post on tracing shared library calls using SystemTap (stap). This reminded me about a problem with vala a while back, which was about how to profile vala code.
Taking the following snippet, we will trace the calls to of methods of the Foo class, for some profiling.
$ cat <<EOF > foo.vala
using Gee;

class Foo : Object
  public void do ()
    print ("done");

void main()
  var map = new HashMap ();
  map["one"] = 1;
  map["two"] = 2;
  map["forty"] = 40;
  print ("%d\n", map["forty"] + map["two"]);

  var f = new Foo (); (); ();
$ vala --pkg libgee-1.0 --debug --save-temps foo.vala
Have a look at the C-code derived from the vala snippet above and look at the function names, to build a regular expression for the to-be-watched function calls. It is important to compile the snippet using the --debug switch, this enables stap to look out for the functions in question.
Additionally we need the following stap snippet (normally found in .stp files), to add the appropriate hooks to the kernel. The following stap script get's compiled into a kernel module and watches the mathod calls on instances of the Foo class.
$ cat <<EOF > foo.stp

global last;

function display_time () {
  now = gettimeofday_us ();
  delta = 0;
  if (last > 0)
    delta = now - last;
  last = now;

  printf ("%d (+%d):", now, delta);

probe begin {
  last = 0;
  printf ("ready\n");

# Modify to match the C signatures of teh methods in question
probe process("/home/fabiand/tmp/sl")
            .function("foo_[a-z]*") ? {
  printf ("\t%s %s\n", probefunc(), $$parms);
Now we've got the binary to trace and the script to watch the appropriate function calls, next is to compile/launch the script before we finally launch our binary.
$ sudo stap -tv foo.stp
And on a different terminal run the binary:
$ ./sl
This should get the above stap call, to spit out the following (or comparable) lines:
1318412226924288 (+0): foo_new 
1318412226924298 (+10): foo_get_type 
1318412226924309 (+11): foo_construct object_type=0x11afe30
1318412226924317 (+8): foo_class_init klass=0x11aff30
1318412226924324 (+7): foo_instance_init self=0x11a7180
1318412226924330 (+6): foo_do self=0x11a7180
1318412226924348 (+18): foo_do self=0x11a7180
First there is an absolute timestamp, followed by the delta between two (matched) function calls in brackets. The delta does not mean that the function call took so long, it is more the time between two function calls matching the regexp in the .stp file, so there can be an arbitary number of function calls between two listed ones.

Sunday, October 9, 2011

EFI ➫ Fedora

Ain't unicode chars nice? :)

Finally, after much work EFI (much thanks to the anaconda team and all those testers) support is quite mature in Fedora 16 Beta. There are still some issues (➫ bugzilla) but in general it's working.

Hardware: It's not easy to see if your hardware supports EFI booting, best is took in your BIOS and see if the magic EFI keyword appears somewhere.

Boot media: If you want to try out an EFI boot media you've got two or three common ways of doing so.
  1. First you try the Fedora 16 Beta DVD or netinst images.
    You can write those images to a DVD using nautilus (right click on the iso ...).
    Note: If you want to use them via a USB-stick you need to use the livecd-iso-to-disk tool, part of the  livecd-tools package. Also remember to pass the --efi switch. In generall it should look somewhat like the following example:
  2. $ sudo livecd-iso-to-disk --format --efi \
      Fedora16-DVD.iso  /dev/sdg

  3. The other way is to use the efidisk.img which can be found in the images directory of the DVD images. This image can be written to a USB-stick using dd:
    $ sudo dd if=efidisk.img of=/dev/sdg

Also note that the LiveCD images are not yet now bootable on a native EFI system.  Normally those systems will fall back to a legacy BIOS boot, which also makes it hard to determine if a system is booted via EFI or BIOS. (The path /sys/firmware/efi exists on systems booted via EFI)

EFI plus some boot optimizations can then finally lead to quick boot process.

Bodenständig - gswitcheroo reached some point.

Gswitcheroo, a small daemon to handle vgaswitcheroo, is now in a state that helps me.

Currently it suggests to switch to the discrete graphics card (an ATI card in my case), if an external monitor is detected non boot. If no external monitor is detected, it suggests to discable the discrete card, to save power. And because hybrid setups just appear in laptops, it usually makes sense to save some watts.

During the last weeks I've learned that it is not possible, to determin if a monitor is connected, when the discrete card is disabled. If I wanted to detect a hot-plugged monitor, I would need to do some polling (including turning the discrete card on and off), but this didn't seem to be to good, so I skipped it and just provided the basic functionality described above.

Wednesday, October 5, 2011

From vala to js - with emscripten.

Stumbling over emscripten again. A fun tool to compile llvm bytecode to JavaScript.
After installing some basic dependencies via
$ sudo yum install vala clang js
and a bit of glue (see below) and you can quickly run code written in vala using a JavaScript interpreter. All this can be done with all code clang compiles, so there is no more magic than normal involved.

$ cd /tmp
$ git clone
$ wget
$ unzip

Now that all software is in place, do some configurations by editing ~/.emscripten:

$ cat <<EOF ~/.emscripten
# path where you cloned emscripten
# I needed to link EMSCRIPTEN_ROOT/src/tmp to this path e.g. 

#LLVM_GCC=... # we don't have that on fedora
COMPILER_OPTS = ['-m64'] # Change to your arch!

SPIDERMONKEY_ENGINE = [os.path.expanduser('/usr/bin/js'), '-m']
CLOSURE_COMPILER = os.path.expanduser('~/tmp/emscripten/closure-compiler.jar')


Basically now everything is in place. Using the following snippet
struct FooBar
	int m;
	public void wtf ()
		stdout.printf ("Wtf!\n"); // The \n is important.

void main()
	FooBar f = FooBar (); ();

... we can compile and execute the whoole thing using the following lines:

$ valac --profile=posix --ccode vaem.vala
$ clang -emit-llvm -S -o vaem.ll vaem.c
$ ./ va/vaem.ll -o vaem.js
$ js -m vaem.js

We need to use the posix profile, otherwise we need to compile the whole glib/gobject system using emscripten. Another way of creating JavaScript from vala code is using maja.