bork it... or not!

LPOTM (LaTeX package of the moment) : todonotes

Petit package fort utile lors de la rédaction de documents en LaTeX^[1] : todonotes (inclu dans texlive-latex-extra).

Il permet d’ajouter des bulles en marge difficiles à louper lors de la relecture et de générer également un listing de “todonotes“ :

Pour générer cette note, la commande \todo{Texte} suffit. Et \listoftodos permettra d’afficher une table des choses restantes à faire (forcément déprimante). Point intéressant : on peut lui demander de respecter l’option “draft” de documentclass. Ainsi les notes et listes de notes n’apparaitront qu’en mode “draft” mais pas en mode “final”.

Un petit problème de placement dans la marge peut apparaître (ligne partant dans le mauvais sens, ça a été mon cas), mais comme l’indique l’auteur cela peut être réglé avec \setlength{\marginparwidth}{2cm} en attendant une évolution du package (assez récent).

Ressources :

• Documentation sur CTAN : http://www.tex.ac.uk/tex-archive/he…
• Blog de l’auteur : http://midtiby.blogspot.com/2008/07…
• Code source sur Github : http://github.com/henrikmidtiby/tod…

by on 2010-08-13 14:27 · permalink

State of the Map 2010

Me voilà de retour de vadrouille, il est donc grand temps de revenir sur mon séjour express en Espagne avec mon frère Thomas à la 4ème conférence annuelle OpenStreetMap : State of the Map, les 10 et 11 juillet 2010. Nous y avions proposé une conférence sur MapOSMatic en mars, qui a été acceptée.

Nous avons passé un excellent week-end lors de cette conférence. La communauté OpenStreetMap, que nous ne connaissions par vraiment, est particulièrement accueillante. Il était d'ailleurs intéressant de constater qu'elle est un peu disjointe de la communauté du logiciel libre, et l'aspect communautaire/crowdsourced d'OSM vient pour beaucoup avant son aspect libre. Nous avons donné notre présentation de MapOSMatic le dimanche midi devant une salle presque comble, et le moins que l'on puisse dire est que MapOSMatic a reçu un accueil plus que chaleureux de la part de la communauté OpenStreetMap !

La conférence en elle-même était très bien organisée, avec beaucoup de talks intéressants. La météo pendant le week-end était bien évidemment excellente à cette période de l'année en Espagne. Je regrette juste de ne pas avoir eu un peu plus de temps pour visiter le centre de Girona et faire une petite visite touristique de la vieille ville. Ça sera pour un autre voyage en Espagne !

Thomas et moi avons fait un compte-rendu de la conférence sur le blog de MapOSMatic. N'hésitez pas à aller le lire; vous y trouverez également un lien vers les slides de notre présentation !

by Maxime Petazzoni (maxime.petazzoni@bulix.org) on 2010-07-19 14:19 · permalink

Tying Mono and OpenCL

One of the cool buzzword these days beside parallel computing is GPGPU as in General Purpose GPU.

The base idea of GPGPU is to allow a programmer to tape in the parallel processing capacities of a GPU to do something different than pixel crushing (even though it mostly boils down to that very application most of time).

GPGPU isn’t new and for a long time vendors have provided their own rather low-level toolkit to program arbitrarily a GPU. As often, someone stepped up one day and proposed a unified API on top of all the vendor specificities. In our case, that API is a standard defined by the Khronos group (think OpenGL) and is named OpenCL.

OpenCL defines both a high-level C API to manipulate GPU (plus other friends) and a C-like intermediate language that is compiled and ultimately run on the device. It’s actually the same model as shader programming.

In the pursuit of Mono world-domination and following the implementation of PLinq that strived to be an easy way for programmer to access the multicore architecture of our processors via Linq, I hereby introduce GLinq (unoriginal acronym for GPU Linq) which this time use your graphic card to execute Linq queries via OpenCL.

GLinq is still much in its infancy and currently only support the Linq’s Select operator but I hope to be able to implement several other operators (at least the classic Where-Aggregate combo). The end goal is also to provide a new set of operator to allow OpenGL code to access the results of the computation without doing a roundtrip between CPU and GPU.

As I said previously, GLinq has the same design goal as PLinq which was to provide a totally new execution model for programmer in the most transparent way possible and with little modification to existing code. In our case, this prerequisite is rather tricky since you are juggling between two totally different worlds.

GLinq tries to provide that seamless experience with two features. The first one is the use of expression trees and C# compiler lambda magic to automatically capture the sense of a C# expression and rewrite it to OpenCL intermediate language. The second one is an automatic mapping of C# types and methods (e.g. Math class functions) to corresponding OpenCL symbols without however sacrificing OpenCL specificities which are also exposed through a C# API (not complete).

Of course, the GLinq API is still a transcription of standard Linq so you use it in the same way via the GpuEnumerable class. At the moment, the only input support are Range and Repeat but that will easily be changed to support any kind of IEnumerable.

Below is an example of the kind of query you can already execute:

var query = GpuEnumerable.Range (-20, 50)
			 .Select ((i) => i * -2 + 3)
			 .Select ((i) => Math.Abs (i))
			 .Select ((i) => ExtraMath.Ldexp ((float)i, 2f))
			 .Select ((i) => (int)i);

foreach (var i in query)
	Console.Write ("{0}, ", i.ToString ());

From what you can see, there are a lot of select operators here. It comes from the fact that the compiler is only able to convert a pure expression lambda to its corresponding expression tree. You can circumvent this limitation by building yourself the expression tree or by using any compiler/interpreter that outputs expression trees (e.g. IronPython, IronRuby, Bechamel).

On a final note, there is an acknowledged bug in at least NVidia implementation of OpenCL which makes Mono doesn’t play nice with it. This is due to the fact that (most) OpenCL implementations use LLVM for code generation/optimization which in turns mess with Mono internal working.

This problem is going to be fixed in the next NVidia driver iteration but as a work-around you can apply this simple patch to mono. I put SIGWINCHSIGXFSZ there because it looks cool and seems generally unused but any other should do the trick.

Code in its proof-of-concept form is living here: http://git.neteril.org/glinq/

by on 2010-06-18 18:07 · permalink

Zencomic 0.3 – « Holy Crêpe »

I’m proud to announce the next release of Zencomic, the comic strip-driven productivity enhancer that periodically makes your day funnier by showing comic like Dilbert or XKCD in a bubble.

New stuff

This release packs a fair number of internal change, UI polishing and a good deal of new comic providers for your pleasure.

Comic backends

Among comic newcomers, you will find Trollcats joining their lolz counterparts and the duo Garfield and Garfield Minus Garfield (contributed by Alan Mc Govern) for even more fluffy fun (or not).

Welcome to the laziest cat on Earth

Cosmetic changes

In Window mode, the comic are now correctly resized to take reasonable space on your screen. A link to the original strip is also supplied at the bottom of the window.

The preferences panel has been overhauled to be less cluttered and provide direct management of comic addins in the UI. It’s also now hopefully completely WM proof when it comes to showing up focused.

Loaded addins configuration

Misc

• Comic are shuffled randomly and served in a round-robin fashion to avoid duplicate fun
• Zencomic haz a new icon
• Repository has been autotool-ified so that you can directly and easily build from git master
• Refactorised addin code

New icon with my poor artistic foo

Download

Tarball: http://neteril.org/projects/zencomic/zencomic-0.3.tar.gz
Git repository: http://git.neteril.org/zencomic/

Cheers!

by on 2010-05-09 22:27 · permalink

Écran noir après mise à jour vers Ubuntu 10.04

Comme après environ chaque mise à jour majeure, quelque soit la distribution ou la machine concernée, je me suis retrouvé hier face à une démission pure et simple du chipset graphique. Cette fois ci cela s’est traduit par un écran noir juste après la séquence de préchargement, et avant la fenêtre de login.

En général il y a autant de causes et de solutions que de personnes, donc je ne parlerai que de mon cas : un Thinkpad X40^[1] avec un chipset graphique Intel.

Il se trouve que si l’on démarre en mode recovery (via le grub), on possède la possibilité de démarrer dans un mode failsafe et notamment dans un mode graphique “de secours”, vu que le Thinkpad ne possède pas franchement de grandes capacités graphiques (mort aux cons qui pensent qu’un pc n’est fait que pour les jeux vidéos), ce mode de secours est strictement identique au mode “normal”, du moins de ce que j’en ai vu.

Si ce mode “failsafe graphics” fonctionne correctement, il vous suffit alors d’ouvrir une console en root, puis

cp /etc/X11/xorg.conf.failsafe /etc/X11/xorg.conf

et de redémarrer !

by on 2010-05-04 19:05 · permalink

Recent updates in MapOSMatic

The following blog post was cross-posted on the MapOSMatic blog earlier today.

MapOSMatic recently passed an important milestone in its history. A few weeks ago, we served our 10,000th rendered map (Saint-Laurent-en-Grandvaux, Jura, France) ! We are very pleased with this accomplishment and feel it is important for us to continue improving the MapOSMatic service for our users. We are working on several objectives in parallel:

• improving the user experience on the website, adding new features and more translations;
• reducing the rendering latency to produce maps faster for our users;
• improving the maps and indexes themselves.
  

Today we rolled out on MapOSMatic a few changes that have been brewing and undergoing extended testing on our development setup, and as I write this post I am pleased to see that we are making good progress on these three main directions.

First and foremost, I think the most important update today comes from the addition of a Spanish translation of the MapOSMatic website (and the corresponding capability to generate maps and indexes internationalized for Spanish-speaking countries), contributed by Julio Costa Zambelli, Sebastian Borgwardt and Jean-Guilhem Cailton. We hope the availability of MapOSMatic in Spanish will help the Chile earthquake disaster response teams.

Next, we restored the bounding-box area input fields for specifying an exact zone to render by the coordinates of its top-left and bottom-right corners. We also added a new feature to the slippy map: by maintaining the Control key pressed, you can draw a rectangle directly on the map to precisely define the limits of the area you wish to render!

This update allows integrates better support for some languages :

• the index of the streets and amenities, as well as the map and index titles are now rendered through the Pango library, which allows to correctly render Arabic, Korean or Japanese characters;
• the index is now rendered right-to-left for RTL languages such as arabic. The first column is on the right, the last column on the left, the street names are on the right while the square locations are on the left;
• we also fixed a font problem with our Mapnik installation allowing for rendering of non-latin characters in the maps as well.
  

Small part of Seoul, South Korea

And finally, as advertised in a previous post about MapOSMatic improvements, we are now using a new version of the rendering daemon (the software in charge of processing the rendering requests queue and creating the maps and indexes). This new daemon lays the groundwork for future concurrent rendering and rendering jobs distribution which will help reducing the rendering latency, when completed. It also has better management of obsolete renderings, with the direct impact of no longer listing hundreds, if not thousands of maps we no longer have the rendered files for.

I would like to conclude this post by thanking, again, all the amazing contributors to MapOSMatic for their continuous feedback, ideas, bug reports and their celerity in providing translations updates when we add new features to MapOSMatic!

by Maxime Petazzoni (maxime.petazzoni@bulix.org) on 2010-03-20 23:15 · permalink

How to write a good changelog

I've just read through the Python 3.1 changelog, and it has encouraged me to write up something that I've wanted to say for a while, but never quite got round to: dear open source developer, please write good changelogs for your project.

What do I mean by changelogs? Historically, the term has meant something akin to "Our version control system sucks, we need to keep track of logical changes by hand". This leads to a "changelog" that looks something like this:

1999-03-24  Stan Shebs  address@removed

	* configure.host (mips-dec-mach3*): Use mipsm3, not mach3.
	
	Attempt to sort out SCO-related configs.  

	* configure.host (i[3456]86-*-sysv4.2*): Use this instead of
	i[3456]86-*-sysv4.2MP and i[3456]86-*-sysv4.2uw2*.
	(i[3456]86-*-sysv5*): Recognize this.

	* configure.tgt (i[3456]86-*-sco3.2v5*, i[3456]86-*-sco3.2v4*):
	Recognize these.

If you're like any developer not involved with the project, that changelog entry is a complete parse error. You have no idea what the actual change is, whether you should care, whether the change was cosmetic or semantic... A compiler analogy would be that if the version control logs are machine code, this is a barely decorated disassembly.

Humans generally don't want to read a disassembly of version control logs. They want to know what changed at a higher, human level, units of change that can be grokked in terms of new tools available to them, new syntax, new libraries, what they need to change in their data to ensure compatibility...

A good changelog doesn't just disassemble version control logs. It presents an executive summary of a whole slew of changes, in terms that make it clear why I, the end user, should be giving a damn.

Thanks for your attention.

by David Anderson on 2009-12-21 13:01 · permalink

HOWTO: Using a GNU screen inside another GNU screen

I found this feature this morning, and the irc folks being enthusiastic, I decided to blag about it.

I use GNU screen on a daily basis for almost three years. Not only able to provide an almost complete terminal emulation, with detach and reattach abilities, extensive keyboard bindings, tabs (a.k.a windows) management, Gnu screen is a versatile tool, although surprisingly more than often ignored by a lot of people.

There is a little reminder of what GNU screen consists in.

Requirements, or at least highly recommended setup

It is highly recommended to have a screenrc that provides a hardstatus line, the only practical way to distinguish one screen from another.

Here is mine:

shell /bin/zsh
attrcolor b ".I"
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' 
defbce "on"
term screen-256color
maptimeout 5
termcapinfo xterm* ti@:te@
hardstatus alwayslastline
hardstatus string '%{= kG}[%{G}%H%{g} %l][%=%{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u
)%?%{r})%{w}%?%+Lw%?%?%=%{g}][%{B}%d/%m %{W}%c%{g}]'
defnonblock 5

Of course, you should adapt this to fit your needs, only the lines beginning with hardstatus are relevant there.

Now that your GNU screen is properly configured, I can highlight the bullet point of this howto :)

Pictures are said to help comprehension. I say LIES!

My X terminal emulator is Terminator. Combined with GNU screen, you can obtain ... that...thing:

(click on the thumbnail to maximize)

Please bear with me, even if this caused some eye-melting :P

Some explanations: each zone delimited by light grey borders are in fact splits in Terminator. Gnu screen sessions are contained in the numbered splits.

1: err... not really a screen, I guess I'm tired and too lazy to correct the picture.

2: lwatch on dresda

3: lwatch on pandora

4: htop on dresda

5: htop on pandora

6: irssi on dresda

The only thing I had to do is to execute screen -e ^ee on pandora, therefore rebinding all default ^a (Ctrl+a) bindings to ^e (Ctrl+e).

Then you control the main screen with the default binding, while controlling the inner screen with these new binds (i.e ^ac to create a new window in the main screen, ^ec to do the same in the inner screen :)

Finally, the relevant part in man screen:

       -e xy
            specifies the command character to be x and the character generat‐
            ing a literal command character to y (when typed after the command
            character).  The default is "C-a" and `a', which can be  specified
            as  "-e^Aa".  When creating a screen session, this option sets the
            default command character. In a multiuser session all users  added
            will  start off with this command character. But when attaching to
            an already running session, this option changes only  the  command
            character  of  the  attaching  user.  This option is equivalent to
            either the commands "defescape" or "escape" respectively.

I really enjoy it, it's like a Christmas present for all BOFHs, blinking like a Christmas Tree when some jerk is trying to mess with your servers/networks :D

by Romain Boissat (r.boissat@gmail.com) on 2009-10-15 22:07 · permalink

Changement du moteur de planet sur bork.it

Ce matin, j'ai remplacé sur bork.it l'ancien moteur Moonmoon (en PHP), par Planet-Venus, en Python.

Le principal problème que posait Moonmoon était qu'il vérifiait les mises à jour des blogs regroupés lorsqu'un visiteur y accédait. Or, dès qu'un blog était indisponible, il attendait lamentablement une réponse qui n'arrivait jamais

Le problème ne pose plus désormais, la mise à jour étant effectuée par une crontab et seul le rendu statique est mis en ligne.

Normalement j'ai fait en sorte de pas broyer les flux rss.

by Benjamin Collet on 2009-10-11 09:47 · permalink

OpenMoko, le téléphone dont vous êtes le héros

Il y a pire que la crise financière, la grippe H1N1, ou autres fléaux de notre monde moderne ; il y a la folie furieuse dépensière du frangin. Ainsi, suite à une pulsion consumériste, nous avons finalement craqué avec Benoit, et nous avons fait chacun l'acquisition d'un Neo Freerunner (comprendre pour le non-geek un téléphone libre).

Pour ma part, cela faisait un moment que j'avais l'intention de changer de téléphone et de faire des infidélités à Nokia. Et puis, il était hors de question que j'achète des trucs de geeks capitalistes du genre avec une pomme, commençant par i et finissant par e. Je n'étais pas plus tenté par une "solution clé en main" de type android (HTC par exemple). Et puis les iPhones, ca explose à la figure des gens dans le Sud, mais malheureusement pas des "oueches oueches" qui écoutent du rap à fond vomis par les ridicules haut-parleurs de leur engin. Bref, il me fallait un truc plus idéologiquement compatible avec mes convictions de libriste. Et pour mes premières impressions, je ne suis pas déçu par l'acquisition de mon NeoFreeRunner.

Packaging

Dans une belle boite, on trouve son téléphone ainsi que des adaptateurs secteur, un câble USB standard et un kit main-libres. Par contre, le ton est donné pour ce qui va se révéler être la quête du Graal de la bidouille, on ne trouve pas de manuel d'utilisation :-) En guise d'introduction, on tombe sur une simple citation de Lao-Tseu, qui laisse un arrière-gout de "bienvenue dans la démerde !". Mais bon, on est linuxien ou on ne l'est pas.

OM2008

Distribution officielle (du moins, suite à l'achat chez Bearstech) disponible "out of the box", mais les fonctionnalités ne permettent pas de tester pleinement le téléphone et tous ses accessoires, et le nombre d'applications étant très faible, il faut rapidement en tester une autre. Par ailleurs, chose déroutante, lors de la saisie du code PIN, un clavier avec uniquement des lettres est proposé, et ce n'est qu'après avoir compris qu'il fallait tracer un trait au stylet de haut en bas que l'on peut passer au clavier "à chiffres", qu'on se sent presque tiré d'affaire. L'envie de faire quelque chose réellement de mon téléphone, ainsi que la curiosité nous ont alors poussé avec Benoit à en tester une autre.

Hackable:1

Rien que le nom, cela donnait envie de tester ! La distribution en elle-même est sympa, elle est fournie avec le support de pas mal de bidules intégrés au téléphone, mais je n'ai malheureusement pas réussi à faire fonctionner le Wifi. Il me semble que l'utilisation des accéléromètres pour effectuer des rotations de l'écran m'avait d'abord scotché et séduit. Mais je n'avais toujours pas l'impression d'avoir un véritable retour sur la tenue sur batterie de l'appareil. C'est d'ailleurs une petite déception de manière générale quelque soit le peu de distributions testées, on ne sait jamais si le téléphone va tomber en panne dans les deux minutes ou si cela peut tenir 3 jours. Suite à l'essai d'un coup de fil avec Benoit, on a trouvé que le son était bien trop faible pour être utilisable.

SHR (testing)

Distribution là-aussi plutôt bien fournie, mais certains trucs refusaient de "tomber en marche", comme le Wifi par exemple. Par contre, prendre des traces avec TangoGPS semblait fonctionner plutôt bien. Toutefois, j'ai trouvé la mise en veille un peu idiote (surtout quand on est en chemin pour mapper avec le précédent logiciel). Et la tenue sur batterie n'était pas spécialement satisfaisante.

Et puis il aurait été dommage de s'arrêter en si bon chemin sur le pèlerinage de la distribution de mes rêves pour téléphone libre.

QtMoko

Distribution à base de Qt, et si cette bibliothèque permet de faire de très jolies choses sur PC de bureau, je trouve que sur systèmes à ressources restreintes, les produits qui en découlent sont plutôt longs à réagir ; bref cela manque de réceptivité, mais c'est un constat que l'on peut faire sur un peu toutes les distributions que j'ai testées pour l'instant. Et je n'ai pas encore réussi avec la reconnaissance d'écriture à produire un caractère "P", ce qui est assez déroutant lorsqu'il s'agit d'écrire mon prénom ou mon pseudonyme.

En guise de conclusion

Pour l'instant, ma carte SIM reste scotchée dans mon ancien nokia, car je ne suis pas satisfait des différentes distributions testées pour être persuadé de changer de téléphone. Mais derrière ce constat peu gratifiant pour le téléphone, je ne désespère pas de trouver l'environnement de mes rêves, joli, avec tout une flopée d'applications pour téléphoner, envoyer des SMS, agenda, contacts, SIP, et plus si affinités ... Je ne manque pas de tester et de découvrir à chaque fois des choses que j'ignorais sur ce "jouet de geek", et je compte aussi sur Benoit pour me faire partager ses découvertes :-)

Idéologiquement je reste satisfait de mon achat, maintenant, il est sur que je ne m'attendais de toutes façons pas vraiment à l'utiliser directement en remplacement de mon ancien mobile. D'une part il faut un certain temps d'adaptation - quel que soit le produit - et d'autre part le cas du Neo FreeRunner est quand même tout à fait particulier. A suivre donc !

by pedrov (pierre.mauduit@gmail.com) on 2009-09-23 08:53 · permalink

Suspend and hibernate on a Thinkpad X40

Making suspend and hibernate working on Debian Lenny on a Thinkpad X40 with a minimal installation is pretty easy, but can become a real pain in the ass neck if you miss a step.

First of all, you must install the following packages:

• hal
• dbus
• consolekit
• acpid
• uswsusp
• gnome-power-manager

Then, add youself to the powerdev group:

adduser <login> powerdev

Make sure thinkpad_acpi kernel module is loaded.

If you want to be able tu use the Thinkpad (or Access IBM) blue button, you must edit /etc/acpi/thinkpad-thinkpad.sh and replace acpi_fakekey $KEY_PROG1 by acpi_fakekey $KEY_MACRO (for an unknown reason, it seems that Xorg is not able to retrieve $KEY_PROG1 (#148) keycode from /dev/input/eventx). The keycode associated is now 239, you can bind it using xmodmap or xbindkeys.

Don't forget to put gnome-power-daemon on your session startup script (~/.config/openbox/autorun.sh in Openbox).

You should now be able to use either special shortcuts such as Fn-F4/Fn-F12 and gnome-power-manager buttons in the tray icon.

by Benjamin Collet on 2009-08-17 02:10 · permalink

ViM: Improved Python syntax and TextMate style highlighting

Recently, I saw through reddit a nice post about an improved syntax highlighting for python, and a nice color scheme which port the TextMate style to ViM. Reading this post, I was pretty amazed by the clear looking of the provided screenshot. So I decided to install, and use, both of these addons. Sadly, nothing went fine. I spent few hours trying to see what was going wrond, before finding out. The color scheme was written for ViM with GUI like GViM, and I still use the old-school CLI one.

So, I tweaked a bit the color file, to have approximately the same rendering than the one in GViM. While it's still not perfect, it is now pretty nice. You have to use 256 colors though (set t_Co=256 in your vimrc).

Here is the result :

And you can find the code here.

All you have to do is put the file in ~/.vim/colors/, and :colorscheme blackboard

by Maxime Ripard (maxime.ripard@anandra.org) on 2009-07-10 21:06 · permalink

Where is my static?

Today at work I was playing around with my classes in c++, in my current project, cleaning up prototypes for my getters, when suddenly blam the project doesn't link any more. Ld had decided that I had an undefined reference to one of my internal static const variables. This is the situation that spawned this article on how statics work in c++, as I obviously didn't quite grasp all the inner works before today.

As we all know the declaration of static objects are usually done as described below for all objects except ones from the int family.

In the header :

class MyClass {
  public:
    static const uint PLOP;
}

in the .cpp

const uint MyClass::PLOP = 42u;

but for ints you are also allowed to do the following (inline declaration):

In the header:

class MyClass {
  public:
    static const uint PLOP = 42u;
}

So what ?

Well it does two very different things!

The second case works fine in 90% of cases when you only use the constant by value. Which is the case when you use this constant only in tests for example.

Here we come to the source of the problem. This case works by propagation of constants, and doesn't allocate memory. So the first time you will try to call it by reference, maybe months after when you try to debug or add a feature, it explodes with some weird link error.

On the other hand, if you use the out-of-line method, the memory is correctly allocated once and for all and will allow the use of the reference.

So the best bet, to avoid bad surprises, is to always proceed as described in the first method.

At least I will got to bed a tad bit less stupid tonight, thanks to this discussion with Dave

by Fleurda (fleurda@fleurda.org) on 2009-06-24 09:55 · permalink

Transformer OpenStreetMap en monopoly géant

Ce que l'on peut faire avec un PostGreSQL / PostGIS, les données libres d'OpenStreetMap et un peu de bidouilles avec le générateur de cartes Mapnik est vraiment impressionnant ; ci-dessous, une tentative de génération Pseudo-3D des bâtiments d'une partie de la zone d'activités des Milles, à proximité d'Aix-En-Provence :

L'idée de creuser la question m'est venue lors d'une visualisation des cartes Google Maps près de San-Francisco. La prochaine étape sera d'étudier la "vraie 3D" vu que cela est possible directement dans PostGIS. Bref, j'aurais sans doute des tas de choses à montrer à l'occasion d'une présentation du projet à l'AXUL le vendredi 12 juin prochain, je pose un hôtel rue de la paix, je plaque mon travail et je me fais rentier !

by pedrov (pierre.mauduit@gmail.com) on 2009-05-31 13:51 · permalink

Lenovo Thinkpad X300 , battery management and tp_smapi

This article briefly presents a "solution" to the battery switching issue mentioned at the bottom of this blog entry.

Indeed, while having two batteries ensures a (very) long battery life, you have to switch manually from the secondary battery to the primary, in order to prevent deep discharges that harms lithium batteries.

Until now, I used to manage it by typing some aliases in my shell, but it is clearly not convenient nor reliable (Sometimes, I simply forget it).

But now, one little bash script and one line in your root's crontable, and the job's done :)

There is battery_switch.sh (deprecated, see baswim.sh below). It basically allows automatic switching to main battery when a given percentage level is reached by the secondary battery. Some parameters are available by editing variables values directly in the script, but only LOW_LEVEL is really interesting.

The cron line I use:

# sudo crontab -e

# m h  dom mon dow   command
*/5 *   *   *   *   /opt/bin/battery_switch.sh

Of course it is aware of your laptop's status. In fact, if it switched to the main battery (by forcing the main battery to discharge), and then you re-plug your laptop, it will cease to force discharge and will return to normal state.

Since I may not be clear, do a

tail -F /var/log/battery_switch.log

to get relevant information.

I hope that will help :)

EDIT: please find there baswim (battery switching improved) a new script that provides a *really* interesting feature: It permits to switch from one battery to another according to both remaining percentage and cycles count.
It follows this simple scheme:

1) Get batteries cycle status 
2) Decide which battery should discharge first based on cycles and remaining percentage
(above the low_level) 
3) Get AC status
3) If AC is unplugged, begin discharge with chosen battery
4) If needed by long unplugged operation, switch to the other battery

It basically a hack from the first script, there are some oddities (one line functions...) but hey it works (surprisingly)!

EDIT: A little but likely important update. This time, both scripts can handle two cases: one battery plus dvd-drive or both batteries.

EDIT:
If you want baswim to be a little more aware of acpi events,
you can make some symbolic links in /etc/acpi/battery.d and /etc/acpi/ac.d.

ln -s /opt/bin/baswim.sh /etc/acpi/battery.d/
ln -s /opt/bin/baswim.sh /etc/acpi/ac.d/

Then, baswim will be executed every time you plug or unplug your AC.

by Romain Boissat (r.boissat@gmail.com) on 2009-05-28 13:15 · permalink

Gnome et Conky

À l'occasion d'un borkage récent de ma fidèle Debian, je suis repassé à une Ubuntu (oui, je sais, je suis faible) 64 bits. Je n'ai pas encore eu le temps de réinstaller openbox, donc j'utilise Gnome pour l'instant.

Je suis aussi un fan de conky, un soft de monitoring s'incrustant dans le fond d'écran. Seulement voilà ... Conky ne sait pas faire de vraie transparence ... Donc à chaque redraw de sa fenêtre, il se remet par dessus les icônes, qui disparaissent.

La solution à ce problème, si vous le rencontriez, est relativement simple.

Ajoutez ces quelques lignes à votre .conkyrc :

own_window yes
own_window_type override
own_window_transparent yes
own_window_hints undecorated,below,skip_taskbar,skip_pager

Redémarrez conky, et voilà le résultat

by Maxime Ripard (maxime.ripard@anandra.org) on 2009-04-29 20:51 · permalink

Levels of abstraction

I promise, I can explain. It started out rather simply, then got a little out of hand. A week or so later, I'm still having an immense amount of fun.

It all started when Google gave me an awesome Christmas present: An HTC Dream. It's a very shiny mobile phone, and what's more, it's an unlocked developer edition. It's hacking time!

This is where things get a bit complicated. Lemme take you through the reasoning.

My first idea when I saw this beast was to try to get emulators running on it. A phone is nice, but a phone that can play vintage games is even better. I decided on playing with the Sega Genesis first, as I have rather fond memories of Sonic the Hedgehog.

First obstacle: Android (the open source OS that Google develops) currently can run only Java code. There is currently no open source Genesis emulator written in Java. Most of them are written in C, or in extreme cases, even in x86 assembler. There is currently no official way to execute native code on the android phone. I'd like to make this software available to everyone.

I therefore need to write a Genesis emulator in Java.

Okay, that should be simple. The Genesis is a relatively old console, so it can't be too elaborate. I mean, it's no PS3. All I need is an emulator for the CPU, a decoder for the ROM format, and some audio and graphics hookups within Android, and I should be good to go.

Well, first, the Genesis has three processors. A Motorola 68000 CPU, a Z80 sound processor, and a custom made graphics processor. Let's start with the 68k CPU. Apparently, there is no well known open source Java emulator for the 68k.

I therefore need to write a Motorola 68k emulator in Java.

But Java sucks. I mean, it's obviously a successful language, but I find no pleasure at all programming in Java. It is pure pain without an IDE on the level of Eclipse or Netbeans, and those IDEs aggravate me in various ways. The the the language language language is is is way way way too too too verbose verbose verbose (verbose verbose).

Plus, after consulting the 68k specs and sampling a few C implementations, it looks like an extremely repetitive task: most opcodes have around 20 variants, depending on addressing modes and various flag bits. It would be very tedious to implement this by hand, not only because it'd be in Java, but because it'd be even more mind numbing and uninteresting. However, the kinds of variants that are needed are quite amenable to be described at a high level, leaving the repetitive task of actual implementation to a program. And I can use a language that I enjoy for that, say, Python.

I therefore need to write a Motorola 68k emulator generator in Python.

After a bit of prototyping, I came to the conclusion that implementing this in Python would also be rather tedious, for a variety of reasons. First, I started off badly by writing a generator that goes straight from high level description language to a Java source code string, mushing several levels of abstraction together. Second, the description needed to generate the variants quickly lead me to combinatorial explosions, or to independent components that began interacting with each other in hilarious ways. Not good.

Plus, one day, when Android does have a supported way of running native code, I'd probably want an emulator in C or C++, running on the CPU directly, instead of under the Dalvik virtual machine. At which point all my work will have been for nothing.

I therefore need something of an emulator compiler, that parses the high level description into an execution tree for the opcode implementations, which a code generator then translates into a variety of output languages, such as Java, C++ or Brainfuck.

Python is nice, but I don't think that writing compilers is one of its fortes, despite what the PyPy folks appear to think. Manipulating the code representations is cumbersome at best, and the divide between the living Python code and the dead data it manipulates is rather wide. Manipulating code as data and vice versa is one of the often described merits of the Lisp family of programming languages. I've been wanting to get back to Common Lisp as a language and poke around with it more, and it feels like the ideal language in which to build a compiler. What could be more code-as-data-as-code than a program that takes apart a description of a program and puts it back together again in another form?

I therefore need to write an m68k emulator compiler in Common Lisp, at first targeting the Java programming language, and later possibly other languages.

And that is how, a week after Google gives me a mobile phone, I find myself writing Common Lisp code, for a compiler that compiles a lisp-like language into Java code, that will be compiled into Dalvik VM bytecode, running on an ARM-based embedded system, which when executed will emulate a Motorola 68000 CPU.

I feel like I've just had a Wikipedia attack. You know, that thing where you go to Wikipedia to look up something very specific, say how Tesla coils can be used to play music, and end up three hours later reading through an analysis of 14th century persian battle tactics, with no idea how you got there. That's kinda how I felt when I came up for air yesterday and looked back. "So, I got a phone... And now I'm writing a compiler... I'm pretty sure I have a good reason..."

Oh, and the emulator compiler is starting to work. I was very rusty in Common Lisp, but in a couple of days of hacking and prototyping, I'm starting to get somewhere. I can already generate the implementation of the simplest variant of the 68k ADD opcode. The "source" looks like this, with comments added

(instruction
   ;; Instruction name, with variant information.
   "add_dreg_to_dreg"

   ;; The description of the meaning of the 16 bits of the opcode.
   ((:literal 4 #b1101)      ; 4 constant bits, with the given binary value
    (output-register 3 dest) ; The output register, whose number is coded
                             ; over 3 bits. Its value is available in the
                             ; 'dest' variable.
    (:literal 6 #010000)     ; More constant bits, describing the addressing mode.
    (input-register 3 src))  ; Input register, similar declaration to dest.

   ;; How to perform this operation, in a subset of Common Lisp.
   (setf dest (+ src dest)))

The above instruction definition produces an opcode object that contains two things: information for the instruction decoder, so that it can identify this instruction, and the intermediate representation of the implementation of that instruction:

;; The constant bit values in the opcode, and the mask to test them,
;; for the instruction decoder.
(debug-print-opcode-mask the-above-opcode-object)

--> Output: 1101---010000---

;; The intermediate representation of the implementation.
(opcode-ast the-above-opcode-object)

--> (LET ((SRC (REGISTER-VALUE :DATA
                               (VM-OPCODE-BITS 3 0)))
          (DEST (WRITABLE-REGISTER-VALUE :DATA
                                         (VM-OPCODE-BITS 3 9))))
      (SETF DEST (+ DEST SRC)))

This opcode can then be fed to the Java code generator, to produce the output implementation:

(java-gen-opcode the-above-opcode-object)

--> public static void op_add_dreg_to_dreg(unsigned short opcode) {
      unsigned long src = mDataRegisters[(opcode >> 0) & 0x7];
      unsigned long dest = mDataRegisters[(opcode >> 9) & 0x7];
      dest = dest + src;
      mDataRegisters[(opcode >> 9) & 0x7] = dest;
    }

There is still a lot to be done. For one, the ADD opcode is supposed to update the CPU's state flags with information about the result of the addition. After that, the addressing modes other than to/from a numbered register must be supported. Implementing more opcodes will surely bring more things that need to be implemented.

Once a solid base is laid, a higher-still level of description must be layered on, so that all the variants of an instruction are produced from a single implementation definition. Once all that is done, a C++ backend would be nice. And why not attempt to generalize the compiler infrastructure, so as to support the compilation of emulators other than m68k CPUs?

By the time I get anywhere near that, I suspect that it will have become possible to easily write and release native code for Android, making all of my efforts unnecessary. But I don't care, this is damn fun!

Some people are of the opinion that I should get my head examined.

by David Anderson on 2008-12-29 05:43 · permalink