Give icons to your weather
29.07.2009 | Categories: Ubuntu
How to graphically display weather info with Conky
As some of you may know, the new version of Conky will include built-in support for weather.
In this blog post, I'm going to talk about how to use this info to make an image for the current weather to be displayed to your desktop:
With weather enabled (use --enable-weather-metar or --enable-weather-xoap during the configuration step), you can get cloud cover and weather status by using the ${weather uri locid cloud_cover} and ${weather uri locid weather} directives. Lets concentrate for the time being on the weather metar data from the NWS (this will apply also to the weather info from weather.com but I plan to introduce upstream a new icon directive that will make it even easier for that).
The possible return values for cloud_cover are:
- clear
- partly cloudy
- cloudy
- overcast
- towering cumulus
- cumulonimbus
Those for weather are:
- drizzle
- rain
- hail
- soft hail
- snow
- snow grains
- fog
- haze
- smoke
- mist
- dust
- sand
- funnel cloud tornado
- dust/sand
- squall
- sand storm
- dust storm
The first thing to do is to find icons for those various weather states. There are plenty of good and free icons to be found on the internet, alternatively, if you register to the www.weather.com service you will get a complete set that matches their weather states.
You don't need an icon for each and every state, you can obviously collect various states together, like a snow icon for snow and snow grains, a rain icon for drizzle, rain, hail and soft hail, an overcast icon for overcast, towering cumulus and cumulonimbus etc.
Save the icons in a directory of your choice, and name them in accordance with the state they represent.
To retrieve the weather status we use a lua function. This lua function takes as input the icao of the station we want data for, evaluates the weather directives and construct the name of the icon we want to display in accordance to a set of rules. In the simple example I'm going to show, it is just using the cloud_cover returned as the icon name. Since this can also be a null string, we need to add an icon to cover for this case.
function conky_show_icon(icao)
local type
type = conky_parse("${weather
http://weather.noaa.gov/pub/data/observations/metar/stations/ "
.. icao .. " cloud_cover}")
if type ~= "" then
type = "${image /home/cesare/icons/" .. type .. ".png -p 0,30 -f 1800}"
else
type = "${image /home/cesare/icons/null.png -p 0,30 -f 1800}"
end
return type
end
Save this lua script in your root directory as weather_icons.lua.
We are almost set, all we need now is to add the following to our configuration file:
lua_load ~/weather_icons.lua
TEXT
${lua_parse conky_show_icon LIRA}
Substitude LIRA with your icao of choice and voilá! Hopefully a sunny face will show up on your desktop too.
Conky has now cairo support embedded
22.07.2009 | Categories: Ubuntu
Lua bindings for Cairo enable us to use Cairo within Conky!
A great feature is in the pipeline for the next release of Conky.
Not happy to have included built-in lua support, Brenden and co. have now included bindings for Cairo and Imlib2 as well.
This will allow us to use the whole Cairo API within Conky!
The following code snippet (inspired by cairographics.org) will show the concept. Save the following lua code into your home directory (lets call it cairo.lua):
-- Conky Lua scripting example
--
require 'cairo'
do
function conky_round_rect(cr, x0, y0, w, h, r)
if (w == 0) or (h == 0) then return end
local x1 = x0 + w
local y1 = y0 + h
if w/2 < r then
if h/2 < r then
cairo_move_to (cr, x0, (y0 + y1)/2)
cairo_curve_to (cr, x0 ,y0, x0, y0, (x0 + x1)/2, y0)
cairo_curve_to (cr, x1, y0, x1, y0, x1, (y0 + y1)/2)
cairo_curve_to (cr, x1, y1, x1, y1, (x1 + x0)/2, y1)
cairo_curve_to (cr, x0, y1, x0, y1, x0, (y0 + y1)/2)
else
cairo_move_to (cr, x0, y0 + r)
cairo_curve_to (cr, x0 ,y0, x0, y0, (x0 + x1)/2, y0)
cairo_curve_to (cr, x1, y0, x1, y0, x1, y0 + r)
cairo_line_to (cr, x1 , y1 - r)
cairo_curve_to (cr, x1, y1, x1, y1, (x1 + x0)/2, y1)
cairo_curve_to (cr, x0, y1, x0, y1, x0, y1- r)
end
else
if h/2 < r then
cairo_move_to (cr, x0, (y0 + y1)/2)
cairo_curve_to (cr, x0 , y0, x0 , y0, x0 + r, y0)
cairo_line_to (cr, x1 - r, y0)
cairo_curve_to (cr, x1, y0, x1, y0, x1, (y0 + y1)/2)
cairo_curve_to (cr, x1, y1, x1, y1, x1 - r, y1)
cairo_line_to (cr, x0 + r, y1)
cairo_curve_to (cr, x0, y1, x0, y1, x0, (y0 + y1)/2)
else
cairo_move_to (cr, x0, y0 + r)
cairo_curve_to (cr, x0 , y0, x0 , y0, x0 + r, y0)
cairo_line_to (cr, x1 - r, y0)
cairo_curve_to (cr, x1, y0, x1, y0, x1, y0 + r)
cairo_line_to (cr, x1 , y1 - r)
cairo_curve_to (cr, x1, y1, x1, y1, x1 - r, y1)
cairo_line_to (cr, x0 + r, y1)
cairo_curve_to (cr, x0, y1, x0, y1, x0, y1- r)
end
end
cairo_close_path (cr)
end
function conky_cairo_test()
if conky_window == nil then return end
local w = conky_window.width
local h = conky_window.height
local cs = cairo_xlib_surface_create(conky_window.display,
conky_window.drawable, conky_window.visual, w, h)
cr = cairo_create(cs)
conky_round_rect(cr, 0.7825*w, 0.0675*h, 0.1*w, 0.1*h, 0.04*w)
local pat = cairo_pattern_create_linear (0.0, 0.065*h,
0.0, 0.165*h)
cairo_pattern_add_color_stop_rgba (pat, 0, 0, 0, 0, 1.0)
cairo_pattern_add_color_stop_rgba (pat, 1, 0.6, 0.6, 0.6, 0.5)
cairo_set_source (cr, pat)
cairo_fill_preserve (cr)
cairo_pattern_destroy (pat)
cairo_set_source_rgba (cr, 0.5, 0, 0, 0.5)
cairo_set_line_width (cr, 10.0)
cairo_stroke (cr)
end
end
Now save the following code into a .conkyrc.cairo file, again into your home directory:
lua_load ~/cairo.lua
lua_draw_hook_pre cairo_test
TEXT
${color orange}SYSTEM ${hr 2}$color
$nodename $sysname $kernel on $machine
${alignc}${color red}${time %a %d %b}
${alignc}${time %H:%M}
Fire up conky with:
conky -d -f "Radio Space" -c .conkyrc.cairoand you should see this on your desktop:
So, start cranking up your conky and show the world the best desktop!
New Conky is on its way
22.05.2009 | Categories: Ubuntu
Should we enable lua and imlib2 support for the Ubuntu Conky package?
Conky is now in feature freeze for 1.7.1.
This release doesn't contain a huge number of changes, but it does have a couple really nice features such as Lua and IMLIB2 support, so hopefully we'll see some cool things from it.
The question now is if we should enable these features in the Ubuntu package or not.
I'm interested to hear Ubuntu Conky's user opinions, especially if there is anyone who is against introducing this change (obvious drawbacks are increased memory and disk footprints and possibly some cpu/timing overhead even if you won't be using these features).
I have now hardy and jaunty testing packages available from my PPA for you to check out.
Here are some basic 'how 2' articles upstream wrote about the new features:Can it be any better ... err!?
22.04.2009 | Categories: General
Oh well, I guess this just shows that I don't have a life
GNU/Linux races for Best Desktop
22.01.2009 | Categories: Ubuntu
Desktop Parade
La Repubblica, one of the two major Italian newspapers, has opened a competition for the most beautiful, original personal desktop.
I haven't checked all the pictures (there are already more than 1000) but from those few hundreds I sampled I could recognise twelve linux desktops: one Debian, five GNOME (one possibly UBUNTU and one definetively so, another one FEDORA), and six KDE, two of which definetively KUBUNTU while one was FEDORA.
On the other side I was amazed by the relatively high number of Macs and the quite small number of people that seem to be actually using Vista.
The sample is definetively not statistically correct but this would show a share of about 5% for GNU/Linux vs. 15% for Macs and the rest is mainly XP ...
There is no prize, they will just show what they consider the best pictures during an exposition (FotoGrafia Festival Internazionale di Roma) in Rome.
I haven't found any reference to any limitations (just the picture that has to be 800x600 pixels), so I suppose that everybody is free to partecipate (I have seen pictures from people not residing in Italy, while admittedly they could speak Italian). Pictures can be sent to this email address: fotografie@repubblica.it including your name, surname and place of residence.
Writing better Perl
21.01.2009 | Categories: Perl
From recursion to iteration
I already talked briefly in a recent blog post about iterators, and about how they can be used to convert a recursive program to an iterative one.
Lets see a practical application: find all dependencies of a binary package, including its dependencies.
My example will be based on Ubuntu (and to keep it simple to just the main pocket), but this should work on any other Debian or Debian based system (and the principle itself will be valid for any other system which handle package dependencies).
The simplest way to implement this would be through recursion: we should first code a find_package function that, given a package as input, produces all the dependancies, and then recurse through all the found dependencies to produce further results.
The following program does exactly that (I hardcoded my binary cache in there, if you want to check this out you would obviously have to adapt it to your system):
#!/usr/bin/perl use strict; use warnings; #prototype declaration sub find_depends($); #list of already processed depends my %seen; #hardcoded cache, change to suit your configuration my $cache = '/var/lib/apt/lists/it.archive.ubuntu.com_ubuntu_dists_hardy_main_binary-amd64_Packages'; open my $fh, "<$cache" or die "Cannot open cache $cache: $!\n"; find_depends($ARGV[0]); sub find_depends($) { my $package = shift; #stop conditions return if (!$package or $seen{$package}); #mark package as seen $seen{$package} = 1; #set record separator local $/=''; #reset cache pointer seek($fh, 0, 0); while(<$fh>) { #check if package record is found if (/^Package:\s$package$/m) { #extract depends line my $depends = (/^Depends:\s(.+)$/m) && $1; print "Package: $package\n Depends: $depends\n"; #extract and process dependencies foreach ( split(',|\|',$depends) ) { s/\s+//g; s/\([^)]+\)//; find_depends($_); } #stop processing last; } } return; }
This function is pretty simple, for each record in the cache, it checks if this is the record we are looking for; if it is it then proceeds to excerpt the dependencies (note that for simplicity this only handle Depends) and then for each of these dependencies it calls itself with that dependancy as input.
Well, it does the job, but, beside everything else, it doesn't produce its output in the way I like it.
If, for instance, you check the defoma package (mind that this could be different in your case), you will see that it has the following depends:
file, perl (>= 5.6.0-16), whiptail | dialog
The program is then going to check file, which has the following depends:
libc6 (>= 2.6.1-1), libmagic1, libmagic1 (= 4.21-3)
Then it is going to check libc6, and so on.
As you can see, it works depth first, which is all you can do with recursion.
However, I'd rather prefer to see first all the depends of the first level's depends and then all of those of the second and so on.
In other words, I'm interested in a breadth first search.
This could be done by transforming this version into an iterative one.
Mark Dominus talks about iterators and using them to transform recursion extensively in HOP Chapter 4 and 5, so I will only recap the main ideas here.
First of all, lets imagine having an array which contains already all the packages you are looking for.
Easy does it, you just scan it and print the results.
Obviously you don't have such an array, however, you can construct it iteratively.
Lets take the defoma package again as an example.
Our array will initially just contain this package. We then check its dependancies, since the package is already processed we take it out from the array, and we put into it the dependancies we have found: file, perl, whiptail, dialog.
Now, lets iterate again this array (that we could also call stack, or queue). We find the package file, so we take it out, and we fill it, from the end, with its dependancies.
The array should now look like this: perl, whiptail, dialog, libc6, libmagic1, libmagic1 (never mind the double entry for now).
Again, lets iterate though the array, we take out perl, and we fill the array, from its end, with its dependencies.
As you can see, this will also do the job. In practice we have used our own version of the stack (which perl uses to handle recursion) to keep track of which packages (or function calls) to track.
The following listing will implement this approach:
#!/usr/bin/perl use strict; use warnings; #prototype declaration sub find_depends($); #list of already processed depends my %seen; #hardcoded cache, change to suit your configuration my $cache = '/var/lib/apt/lists/it.archive.ubuntu.com_ubuntu_dists_hardy_main_binary-amd64_Packages'; open my $fh, "<$cache" or die "Cannot open cache $cache: $!\n"; *deps = find_depends($ARGV[0]); while (defined( deps() )) {} sub find_depends($) { my @queue = shift; return sub { #stop condition return unless (@queue); # return if package has been processed already my $package = shift @queue; return $package if $seen{$package}; #mark package as seen $seen{$package} = 1; #set record separator local $/=''; #reset cache pointer seek($fh, 0, 0); while(<$fh>) { #check if package record is found if (/^Package:\s$package$/m) { #extract depends line my $depends = (/^Depends:\s(.+)$/m) && $1; print "Package: $package\n Depends: $depends\n"; #extract and process dependencies foreach ( split(',|\|',$depends) ) { s/\s+//g; s/\([^)]+\)//; push(@queue, $_); } return $package; } } } }
find_depends is now a function factory. The function it returns (the iterator deps()), does now almost exactly what the recursive version was doing, the only difference is that it now also manages the array of packages to visit (and of course it doesn't recurse itself, the iteration is managed in the main program by calling the iterator in a while loop).
Note that here the return value of the iterator is not used, I could just return anything I wanted as long as its defined; the undefined value is used to stop the iteration.
If you check out this version, you will see that indeed I now print all my dependancies level by level:
it will check file, perl and whiptail first and then proceed with their dependencies: libc6, libmagic1, etc.
By modifying the way new entries are added to the array I can of course also modify this behaviour.
Well, I hope you enjoyed this, it is going to be my last blog post on perl for a while: I intend to work on my next OpenGL demo (fur rendering) for the next few weeks.
Testing a new comment system
18.01.2009 | Categories: Web
Comments
I'm testing a new comment system. Will it work? Will it be satisfying?
Writing better Perl
15.01.2009 | Categories: Perl
Typeglobs
Still on chapter 7 of HOP, there was something that puzzled me.
Suppose you have a silly function factory to produce power functions:
sub power { my $pow = shift; return sub { my $arg = shift; my $out = 1; foreach (1 .. $pow) { $out *= $arg; } return $out; } }
For simplicity I assume that power() can only get positive integers as input, and that no error checking is performed.
The factory can then be used to provide square, cube, etc. functions:
my $square = power(2); my $cube = power(3); my $fifth = power(5);
that can be invoked as follows:
$square->(4); #Produces 16 = 4 ** 2 $cube->(3); #Produces 27 = 3 ** 3 $fifth->(2); #Produces 32 = 2 ** 5
Now, what puzzled me was the following syntactic sugar that Mark Dominus makes for a similar example:
"If you don't like the extra arrows ... you can get rid of them by using Perl's glob feature"
Which, applied to my example, could be done like this:
*square = power(2); $a = square(4); #Sure enough, this also produces 16
This *var notation really looks like C. Now, this got me excited but, for the life of me, I couldn't recall any glob feature beside the glob function [1].
A quick search through my books didn't produce any sensible result. However, when I extended the search I stumbled against the solution to the arcane, the *var notation is used to access typeglobs!
[1] in Chapter 3 there is indeed a fleeting reference to the symbol table but I must have missed it ...
typeglobs
A typeglob is another of Perl basic data types. The star symbol (*) its really a sigil (like $, @, %, & etc.), which is telling us that the variable square is a typeglob (like $square would tell us that it is a scalar).
To understand what this data type is, and for what it can be used, we have to talk about a package's (or, differently said, a namespace) symbol table.
Every Perl package (including main) has an associated symbol table, a special hash-like data structure which stores the package's GLOBAL variables. The name of this structure is the package name followed by two colons at the end, for instance, it will be %main:: for that of the main package, or %foo:: for that of the package foo.
The following snippet will list the content of the symbol table of main:
foreach my $key (sort keys %main::) { print "$key = $main::{$key}\n"; }
As you can see from the output, there are some symbols which seem familiar:
ARGV = *main::ARGV ENV = *main::ENV INC = *main::INC SIG = *main::SIG STDERR = *main::STDERR STDIN = *main::STDIN STDOUT = *main::STDOUT
Can you see INC for @INC, ENV for %ENV, etc? To the right of these you will find the corrisponding typeglobs. To access the component of the typeglob, you can use the following keys:
SCALAR ARRAY HASH CODE IO GLOB FORMAT NAME PACKAGE
So, for instance, the following snippet:
my $a = *{$main::{ARGV}}{ARRAY}; print "@$a\n";
will just print @ARGV (note that we need to deference the typeglob to get its value).
As an example, the following function will return whether a given
glob is defined for the package main and what it refers to:
sub globtype { my $glob = shift; return unless (*{$glob}{PACKAGE} eq 'main'); my $name = *{$glob}{NAME}; return grep { defined *{$main::{$name}}{$_} } qw(SCALAR ARRAY HASH CODE IO FORMAT); }
Try this out on ARGV, INC or ENV and be surprised that there is a filehandler called ARGV and a scalar $ARGV (hmmm, thats why <ARGV> works and $ARGV contains the name of the file currently open...), or a hash %INC (which is used to cache the names of the files and modules that were loaded and compiled).
Concluding, if $var is a global variable, *var can be used to access its entry in the symbol table, or, in other words, acquire a REFERENCE to that object.
So, if you have a reference to a function, \&func, you can assign (or, better said, alias) it to a typeglob:
*var=\&func;
You can now access the function simply by using its alias: var. Since this is an object, not a reference, you don't need to deference it by using the deference operator ->.
Voilá, can it get any cooler!?
Writing better Perl
10.01.2009 | Categories: Perl
Function Factories
I'm still having lot of fun with Higher Order Perl.
I went through the whole book and now I'm going back chapter to chapter to explore them further.
A cool chapter is chapter 7: Higher Order Functions and Currying.
The concept I'm exploring right now is that of Function Factories.
In simple terms, a Function Factory is a function whose sole purpose is to produce other functions (hence the name).
Why would you need such a thing? Lets make an example, suppose you need to do something in your script as a function of user input, for instance print a message to the terminal if the user has choosen that kind of output, or draw something to the screen if the user has choosen that other option.
The "classical" way to do it would be to have some kind of if..else somewhere, or perhaps many triggered by a flag variable.
That is of course a valid way of doing it, even if the readability of your code could be somewhat compromised.
But what if you need to use different callbacks (either as a function of user input or because of some internal state change of your script)? Again, one could use some kind of if..else, however things start to be nasty, especially if you have to pass over this callback to another function (think about external library functions for instance).
In all these situations a Function Factory is ideal, for instance for the latter example you just pass as your callback the function which is built (following your specification) by your Function Factory!
As a practical example, lets see the following piece of code (granted you, its a silly example, what is important here is the concept):
#!/usr/bin/perl use strict; use warnings; use Getopt::Long; my $input='C'; GetOptions('A|a' => sub { $input = 'A' }, 'B|b' => sub { $input = 'B' } ); my $Print; sub do_something { $Print->{body}->(); } sub print_factory ($) { my $type = shift(@_); my $body = $type.$type; my ($print_header, $print_body, $print_footer); if ($type eq 'A') { $print_header = sub { print "Header A\n"; }; $print_body = sub { print "Body $body\n"; }; $print_footer = sub { print "Footer A\n"; }; } elsif ($type eq 'B') { $print_header = sub { print "Header B\n"; }; $print_body = sub { print "Body $body\n"; }; $print_footer = sub { print "Footer B\n"; }; } else { $print_header = sub { print "Header C\n"; }; $print_body = sub { print "Body $body\n"; }; $print_footer = sub { print "Footer C\n"; }; } return { header => $print_header, body => $print_body, footer => $print_footer }; } $Print = print_factory($input); $Print->{header}->(); do_something; $Print->{footer}->();
The interesting bit here is the print_factory function, which is our function factory.
We use that to build our Print function, which behaves differently as a function of user input.
If no options were given when the script was called, the script would print "Header C", as an header, then "Body CC" and then "Footer C" as a footer. If either -A or -B were passed, the script would print A or B instead of C.
The Print functions are produced when the function factory is called:
$Print = print_factory($input);After which, whenever any of the Print functions are called, only the ones we built will be executed.
Note that since Perl supports closure, the Print->Body function will correctly produce the right output.
You will find some practical applications in HOP (especially chapter 8), or in other perl scripts (for instance, I just stumbled upon what I simplified for this example in apt-rdepends).
Now, to make it even cooler, just use a dispatch table in the function factory <grin>.
Shredding again
08.01.2009 | Categories: Guitar
Are we doing it allright?
Few years (well, quite some years) ago, I used to play the guitar.
Taken by a sudden attack of precocious senility, yesterday I took my old guitar back from its grave, cleaned it and tuned it. I then sat back, with a big grin on my face, and a sullen look in my eyes. And I thought "And now!?".
So, after few pathetic tries, I managed to produce this.
Its a snippet from a studio I composed then, which my fingers are kind of remembering on their own (and blistering happily over it).
I was amazed how things were flowing back, and even though my performance suck bug time (and my fingers are hurting like hell) this really made me happy.
The sad part of it, is that the first thing I did was to hook up my stomp box to my audigy card, and then tried, for half an hour, to get sound back through linux, to no avail.
Needless to say, I switched to my XP partition (which was lying unused for several months now) and the bloody thing just played right there and then.
A hard hit for an OSS fanatic to take but here, I must admit defeat.
Higher Order Perl
17.12.2008 | Categories: Perl
Are you writing your Perl scripts C-style?
I do indeed ... fortunately I just stumbled on this book: Higher Order Perl.
Pretty much your run-of-the-mill basic computer science course, but, in Perl :-).
I'm right now on chapter 4, Iterators.
What is an iterator? Basically, its an object that permits to scan a list element by element. The immediate advantage of using it its that the list doesn't need to be in any place, can just be generated on-the-fly. The not-so-immediate advantage is that iterators can be used to replace recursion: basically, using your own version of the stack management. On top of that, one can stop, restart or traverse a tree not depth-first, all things which are very difficult (if not downright impossible) to do with recursion.
Perl already has iterators, think about filehandles or the glob function; chapter 4 will guide you on how to write your own versions.
Once one grasps the fundamental concept (which, I must say, took me a while), the chapter is just a breeze, you only hope it would not be over so quickly!
A definite recommendation; now, where would I find a printed version to go into my library ...
Smoke with gtk+ gui
09.12.2008 | Categories: OpenGL Demo
I have integrated the smoke demo with a gtk+ interface using gtkglext.
This include the possibility of taking screenshots, starting/pausing
the simulation, showing the fps and trimming some of the turbulence
parameters in real-time.
The rendering widget can be blown fullscreen and back to windowed.
Smoke
25.11.2008 | Categories: OpenGL Demo
Work is proceeding well with the smoke demo.
I wanted to add some turbulence but my graphic card doesn't support
noise; I would have to add it on the CPU. I'm also toying with the
idea of adding some lightning and hopefully shadow effect.
We shall see how this will develop.
Smoke
24.11.2008 | Categories: OpenGL Demo
I'm experiment again with my particle system and starts having some
half-decent smoke.
I'm now looking into some kind of turbulence effect, or adding
some fancy coloring to get a nice fire look.
Here are some preliminary images:
Picking
20.11.2008 | Categories: OpenGL Demo
Picking
Picking is the tecnique used to transform a position from screen space (for instance due to the user clicking on the screen) to eye (or object) space.
One easy way to see it is as the inverse of the transformation that takes a vertex in eye (or object) space and draws it to screen space.
This transformation follows these steps:
- The vertex is transformed from object to eye space with the modelview matrix
- It is then transformed to the frustum plane with the projection matrix
- Projected coordinates are transformed to normalised coordinates (in the range -1 to 1)
- And finally, normalised coordinates are tranformed to screen coordinates
To do the inverse transformation we have to repeat these steps backwards (I don't use it in my demo but there is a glu function that can be used to perform this; I prefer my version since it is optimised for speed).
In this demo I add a collision test between the ray which is computed with this tecnique and all objects in the scene by using Objects Aligned Bounding Boxes (OABB). This is usually called the broad search phase (in this case being an interception test of a ray with a box).
If the ray intersects an OABB, I proceed to the narrow search phase: I check all polygons for the model contained in the OABB to test if any of them is intersected by the ray. If it is, I modify the model animation with a "pain" sequence.
The md2 models I use in this demo are made by:
- ogro: Magarnigal <mellor@netgazer.net.au>
- bauul: Brian "EvilBastard" Collins <brian@zono.com>
- knight: James Green <james@perilith.com>
and were extracted from sauerbraten data.
The sample code is available for download here.
Skeleton Animation
01.11.2008 | Categories: OpenGL Demo
I modified the skeleton demo adding keyframe animation.
The demo now can act as a (admittedly poor) pose tool.
You can select the animation mode with the l-key and memorise a pose with the p-key. This latter will also dump the quaternions to stdout so that they could be saved in the .model file (two sample keyframes have been added to the one included with the tarball).
Skeleton Animation
31.10.2008 | Categories: OpenGL Demo
Skeleton Animation
Back in the Golden days of home computing, animated characters were simply 2D sprites which (when being clever) changed size as a function of the perceived distance.
When we finally could afford polygon based characters, animation was simply done by moving all the vertices in accordance to defined trajectories.
Even though the animation code was simple and the visual quality was pretty good (see the animation demo), due to the increasing visual quality requirements, and therefore increasing model size, the following disadvantages became evident:
- All the animations had to be precomputed and stored. Procedural animations were in most cases impossible.
- Memory footprint was becoming huge, since for each vertex we have to store the vertex properties (position, normal, bi-normal, texture coordinates etc.) for each frame of the animation, for each animation. For example even a mere 100th vertices model (very low-poly for today's standard) would need several Mb of memory.
- Producing these models was a difficult and time intensive jobs. All the vertices had to be manually moved for each frame of animation and for each animation sequence.
These reasons (especially the third one) prompted skeleton based animation.
In these animations, only a selected number of points (not necessarily vertices) are being moved, while all the others are slaved to these "control" points.
These control points are usually called bones (in analogy with anatomy) or joints (borrowed from robotics where these techniques were first developed).
As an added bonus, if we make bones into a hierarchical structure, we have the advantage that moving a single bone will automatically move all the children bones (think about rotating your shoulder or hip joints).
The data structure I used in this sample is very simple (and it can be made even simpler), every bone contains just the associated homogeneous transformation matrices (absolute and relative) and a pointer to the parent bone. All the vertices are linked to each bone by a weigthing matrix, so that more than one bone can contribute to the motion of a single vertex.
As I was only interested in implementing the algorithms, this code is absolutely not optimised for speed or memory.
The two most trivial optimisations that can be implemented are a weighting structure which only contains non-zero elements and using GPU or CPU SIMD instructions to do the matrix multiplications.
The excellent model I use in this demo is made by Raimon Deville (MetaDaemon) and is available for download here.
The sample code is available for download here.
Finding reverse build-depends with perl references
09.10.2008 | Categories: Perl
I'm having real fun with perl.
As a member of the Ubuntu motu-release team one of my duties is to assess Feature Freeze exceptions (FFe).
One of the zillion of things we have to consider for an FFe is if the package for which the FFe is asked has any dependency or build dependency.
The first is easy to assess (I use apt-cache for that), but the second?
There is a nice script which is part of the ubuntu-dev-tools package, but I found it not satisfying. Mainly, because it searches by substrings, so it may (and indeed it does) give false positives.
I tried to meddle with it, but the problem is that the script is a wrapper around grep-dctrl which seems to be quite user obstile.
Never mind, thats another good occasion to use perl! So, here is the result:
#!/usr/bin/perl -w
use strict;
sub print_usage {
print "Usage: rbd package [...]\nPrint reverse build-depends list of given package(s)\n";
exit;
}
print_usage unless(@ARGV);
foreach (0..$#ARGV) {
print_usage if($ARGV[$_]=~/^-/);
}
my @results;
my $package;
foreach (</var/lib/apt/lists/*Sources>) {
open FILE, "<$_" or die "Cannot open cache $_: $!\n";
while (<FILE>) {
if(/^Package:\s(.+)$/) {
$package=$1;
}
if(/^Build-Depend(?:s|s-Indep):\s(.+)$/) {
my $list=$1;
foreach (0..$#ARGV) {
push(@{$results[$_]}, $package) if($list=~/\b\Q$ARGV[$_]\E\b/);
}
}
}
close FILE or die $!;
}
foreach (0..$#ARGV) {
print "$ARGV[$_]\nReverse Build-Depends:\n";
if($results[$_]) {
my @sorted=sort(@{$results[$_]});
foreach my $package (@sorted) {
print " $package\n";
}
}
}
Might not be the nicest and user-friendly script but does the job, its fast and the output is mimicking apt-cache (and has the same limitations, ie. it relies on the local cache).
The nice thing is that I used this to learn something new, references.
So far I had been happy to use the basic data types provided by perl: scalars, arrays and hashes.
But this time, I needed something different, I needed an array of arrays (or a matrix, if you wish).
After a bit of googling around, I got the answer I was looking for.
What is a reference and how does it work?
A reference is a scalar which references another variable. If you know C, C++ or Pascal you may know what a pointer is, but the perl implementation only use typed pointers, ie. pointers to precise type of data.
To create a reference, you just add a backslash to any other variable.
All the following are valid references:
$ref_s = \$scalar $ref_a = \@array $ref_h = \%list
Now, suppose that we have an array of references, each of which is referring to another array ...voilá, we have got our array of arrays!
For example, if @array1, @array2 and @array3 are our arrays we simply fill our array of arrays with references to them:
my @array1 = qw(1 2 3 4 5);
my @array2 = qw(a b c d e);
my @array3 = qw("pippo" "pluto" "paperino");
my @array_of_arrays = (\@array1, \@array2, \@array3);
or even simpler:
my @array_of_arrays = \(@array1, @array2, @array3);Finally, lets print the result:
print "@array1\n@array2\n@array3\n@array_of_arrays\n";
If you run the script, you will get a result similar to this:
1 2 3 4 5 a b c d e "pippo" "pluto" "paperino" ARRAY(0x605050) ARRAY(0x632040) ARRAY(0x632220)
The problem is that if we print references, we won't access the original data which is referred to, we simply get the reference itself.
To deference the data, we have to use the deference operator: a couple of curly braces ({}) preceded by the type of data we want to access
If in the above example you change the final print statement to :
print "@array1\n@array2\n@array3\n@{$array_of_arrays[0]} @{$array_of_arrays[1]} @{$array_of_arrays[2]}\n";
you will get:
1 2 3 4 5 a b c d e "pippo" "pluto" "paperino" 1 2 3 4 5 a b c d e "pippo" "pluto" "paperino"
As you will see from my script, I declare my array of arrays simply as an array. You don't have to know beforehand what is the type of data your array will be filled with, this is done automatically by perl (and is called autovivification).
You may find many more details about references and how they can be used to create all kind of data structures in this Perl book. Even though it is for perl 5.6 I found it very useful.
Collect Ubuntu, Debian and upstream versions together
06.10.2008 | Categories: Ubuntu
I was talking with seb128 few days ago about things I could help with in the Desktop Team.
Seb mentioned that a web page listing Ubuntu, Debian and upstream versions of the packages maintained by the team, as well as a simple system to assign tasks, would be nice.
I thought that was the perfect excuse to finally learn some perl and php, so I set to the task and hacked this script together.
You can see the results here.
The script is tailored for Gnome packages, but can easily be changed to do the same thing for KDE, Xfce, Xorg or whatever other piece of software uses a central download location.
On top of that, its easily customisable from the command line, so that it can be used for just some packages one is particularly interested in.
The man page gives all the gory details, but lets make an example. Suppose you want to track the following packages:
All you need to do is to create a local packages list. This list is a csv file with the following fields:
package,upstream,blacklist,updater,watch
Where:
- package is the source package you want to track (must be a valid Ubuntu package name)
- upstream is the upstream name, if different from the Ubuntu one
- blacklist is used to avoid the package being looked up in the Gnome pool
- updater is the usual updater/uploader/maintainer; can be left blank
- watch is a watch line to be used to retrieve upstream versions
Examples of watch lines can be:
- ftp://ftp.gimp.org/pub/gimp/v2.4/gimp-([\d\.]+)\.tar\.bz2
- http://sf.net/conky/conky-([\d\.]+)\.tar\.gz
- http://bonrom.cbbknet.com/ \?download=RutilTv([\d\.]+)\.tar\.gz
The format should be compatible to that of watch lines of watch files version 2 (note that there is already a built-in logic to handle sourceforge hosted files).
Downloading from launchpad is not yet supported since this requires directory pattern matching (perhaps I will implement this in a later version).
For our example, the package list could be written as follows:
gnome-mplayer,,1,,http://code.google.com/p/gnome-mplayer/downloads/list \ http://gnome-mplayer.googlecode.com/files/gnome-mplayer-([\d\.]+)\.tar\.gz conky,,1,,http://sf.net/conky/conky-([\d\.]+)\.tar\.gz rutilt,,1,,http://bonrom.cbbknet.com/ \?download=RutilTv([\d\.]+)\.tar\.gz gelemental,,1,,http://www.kdau.com/files/gelemental-([\d\.]+)\.tar\.bz2 source-highlight,,1,,ftp://ftp.gnu.org/gnu/src-highlite/source-highlight-([\d\.]+)\.tar\.gz
Let's save it as example.txt.
The list can then be generated with the following command:
gen_list_html --packages rutilt source-highlight gelemental gnome-mplayer conky --input example.txt --text
Which will produce the following output:
rutilt 0.18-0ubuntu1 0.16-2 0.18 source-highlight 2.10-0ubuntu1 2.4-5.2 2.10 gelemental 1.2.0-3ubuntu1 1.2.0-3 1.2.0 gnome-mplayer 0.7.0-1ubuntu1 0.7.0-1 0.8.0 conky 1.6.1-0ubuntu2 1.6.1-1 1.6.1
First, the package name is printed, then the Ubuntu, Debian and finally upstream version.
I kept the textual output as basic as possible since I just use it while debugging.
One can of course modify it to generate a more readable output, or an output more suitable for automatic scanning.
To generate a fancy php file, just omit the --text option and redirect the output (or use the --output option).
The script requires just the perl, perl-base, libwww-perl, dpkg-dev and gzip packages to run which should already be installed on any developer's machine.
My utmost thanks go to the dad authors (which I took as inspiration for the comments handling) and the uscan ones (which drove the upstream scanning logic for packages not in a single download location).
gnome-mplayer/gecko-mediaplayer now available from my PPA
03.10.2008 | Categories: Ubuntu
gnome-mplayer/gecko-mediaplayer 0.8.0 are out
gnome-mplayer is a simple GUI for MPlayer. It is intended to be a nice tight player and to provide a simple and clean interface to MPlayer.
It can be used embedded in a gecko brower to play media on websites when used with gecko-mediaplayer. It is not highly dependent on the Gnome libraries (the main dependencies are GTK2, GLIB2 and DBUS), but the look and feel of the application is based on the Gnome HIG.
Quite a lot of changes in this version, so I'll just give a link to the whole changelog here.
Since it is too late to have these officially available from the Ubuntu repos, I have uploaded copies to my PPA. You can add the PPA to your sources.list:
deb http://ppa.launchpad.net/norsetto/ubuntu intrepid main
or simply download the debs from here:
gnome-mplayer 0.8.0 for i386
gnome-mplayer 0.8.0 for amd64
gecko-mediaplayer 0.8.0 for i386
gecko-mediaplayer 0.8.0 for amd64
Packages for Debian are currently in mentors.debian.net awaiting sponsorship:
http://mentors.debian.net/debian/pool/main/g/gnome-mplayer/gnome-mplayer_0.8.0-1.dsc
http://mentors.debian.net/debian/pool/main/g/gecko-mediaplayer/gecko-mediaplayer_0.8.0-1.dsc
Cloth Simulation
20.06.2008 | Categories: OpenGL Demo
The cloth demo has been added to the demo pages.
Cloth Simulation
19.06.2008 | Categories: OpenGL Demo
Some early shots from the Cloth Simulation demo.
The Shadow demo has been included in the Phoronix Test Suite
23.04.2008 | Categories: OpenGL Demo
Thanks to Michael and staff for including the shadow demo in their test suite!
If you run "phoronix-test-suite benchmark norsetto-shadow", it will run the test and show the results.
Updated the Shadow demo
22.04.2008 | Categories: OpenGL Demo
Added time slice parameter so that the fps are computed every t secs (default=5) and displayed also to stdout (Phoronix)
Updated the Landscape demo
24.03.2008 | Categories: OpenGL Demo
Added terrain and tree shaders, changed terrain textures, changed underwater shader, changed tree textures to atlas, changed sort algorithm to bsp tree plus some minor tweaks and fixes.
The procedural sky is now on-line
01.03.2008 | Categories: OpenGL Tutorial
Yuppie! This is marking the official start of this project as I envisioned it.
Comments
Sender: Michael Greb
Aliasing long functions is a great time saver and can make code clearer in some cases. An example from some code at $work:
Instead of having to repeatedly type out HostLib::log_msg("Some message to log") one can just use log_msg("Some message to log"). You can also use this to override functions in another namespace, useful for testing ie:
These of course can easily be abused but over-riding system in a quick test script can be handy to verify the correct command was attempted to be executed.