Informatique
Saturday, 22 August 2020
|
Écrit par
Grégory Soutadé

Let's play with some strangefun C stuff related to macro implementation in GCC compiler.

In the next code, we will work on this kind of structure which is a basic implementation of a matrix structure :

typedef struct {
  int width;
  int height;
  double* data;
} matrix;

In a standard algorithm implementation, we would use malloc() for at least .data field. But, in embedded world, it's preferable to use static allocations (if we use "static" matrices with known parameters).

Use an array as a C macro parameter

First trap of our compiler. We want to statically initalize an array like this :

#define STATIC_ARRAY(_name, _values) double _name[] = _values

STATIC_ARRAY(myArray, {0.0, 0.1, 0.2};

Compilation returns this error :

b.c:5:38: error: macro "STATIC_ARRAY" passed 4 arguments, but takes just 2
STATIC_ARRAY(myArray, {0.0, 0.1, 0.2});

The second argument is not considered as an array, but a list of arguments. My question is WHY ??? This seems a non sense as the goal of macros is to copy paste without interpretation.

Solution I found is to use a variadic macro parameter. This will only works for one array value.

#define STATIC_ARRAY(_name, ...) double _name[] = __VA_ARGS__

STATIC_ARRAY(myArray, {0.0, 0.1, 0.2});

In flight shadow array

Another problem come if I make a more complex macro to initialize my structure. Basically, we may do something like this :

#define STATIC_MATRIX(_name, _width, _height, ...)          \
  static matrix _name = {.width = _width, .height=_height, .data=__VA_ARGS__}

STATIC_MATRIX(myMat, 2,2, {0.0, 0.1, 0.2, 0.3});

Which give a wonderful error :

b.c:13:1: warning: braces around scalar initializer
STATIC_MATRIX(myMat, 2,2, {0.0, 0.1, 0.2, 0.3});
^
b.c:13:1: note: (near initialization for ‘myMat.data’)
b.c:13:28: error: incompatible types when initializing type ‘double *’ using type ‘double’
STATIC_MATRIX(myMat, 2,2, {0.0, 0.1, 0.2, 0.3});

The correct way to initialize our structure is to declare an array and affect it to .data field. We can embbed this declaration in macro definition :

#define CONCATENATE_DIRECT(s1, s2) s1##s2
#define CONCATENATE(s1, s2) CONCATENATE_DIRECT(s1, s2)

#define STATIC_MATRIX(_name, _width, _height, ...)          \
  static double CONCATENATE(static_darray_,__LINE__)[]=__VA_ARGS__; static matrix _name={.width=_width,.height=_height,.data=CONCATENATE(static_darray_,__LINE__)}

This a bit long, but it works ! The macro creates two statics objects, one named by user and one which is unique thanks to line number concatenation. Note, that we cannot split it on two lines due to line number in the name.

We can modify this macro (or create a new one) by removing static attributes. In this case, be careful if you define it in an header, and use it in two separate file at the same line. It could be interesting to use static objects or not depending on variables usage.

Another improvement could be to create const array if data is not updated. Thus, compiler can use a the same memory space for multiple matrix arrays with the same values.

Last but not least. Here, the created array has a variable length that depends on value in parameter. We can fix its size with :

static double CONCATENATE(static_darray_,__LINE__)[_width*_height]
Monday, 15 June 2020
|
Écrit par
Grégory Soutadé

ClearFog base board

For a project, I need to run java on an ARMv7 core. I could have used my Cubox server, but I don't have enough memory to run web services & java in parallel. Fortunately, I could find a SolidRun ClearFog Base board. This board is mainly network focused and only have an old dual Cortex A9 with 1GB of memory which is quick reached by today web applications, but it should be okay with a single one (I hope).

SolidRun provides documentation & ready to use OS (Debian FreeBSD, Yocto, OpenWRT), so board start should take less than one half hour. Nevertheless, documentation is split in multiple files, and there is no step by step guide. Moreover, Debian images seems crafted (we can't read main ext4 partition). After 2 hours of fails I started to turn crazy ! Here is my step by step tutorial.

The goal is to install Debian on an 8GB SDCard

1) Get an 8GB SDCard and delete all partitions thanks to gparted (or fdisk).

2) Within gparted create an ext4 partition that starts at 4MB with 8GB length

3) Download target Debian images from SolidRun resources. You should take .tar.xz file which is a compressed tar file of root filesystem.

4) Go to SDCard main partition and extract data from Debian image (using sudo)

cd /media/soutade/UUID/
sudo tar -Jxvf ~/clearfog/sr-a38x-debian-buster-20200218.tar.xz
sync

5) Update fstab with your new SDCard UUID

sudo emacs etc/fstab

6) Download U-Boot for base-sdhc variant

7) Burn it to SDCard at address 512 (first sector). We assume SDCard is /dev/sdb (check it before applying this command)

sudo dd if=u-boot-clearfog-base-sdhc.kwb of=/dev/sdb1 seek=1 bs=512
sync

8) Configure ClearFog switches to start using SDcard (Off Off On On On)

9) Insert SDCard into the board, connect serial line USB to your computer

10) Power up the board and start serial line screen

sudo screen -L /dev/ttyUSB0 115200

11) Stop U-Boot process by hit a key

12) Setup kernel bootargs. Here we setup root filesystem read/write at startup, but it should be re mounted rw by fstab. Only root argument is mandatory

setenv bootargs root=/dev/mmcblk0p1 rw
env save
boot

The board should now start with a fresh Debian ! I suggest to connect within SSH which is more comfortable to use than serial line console. Login/password is debian:debian.

Have fun !

Wednesday, 13 May 2020
|
Écrit par
Grégory Soutadé

Capture Gnome Shell Generic Monitor

La version 2 de mon extension Generic Monitor pour Gnome Shell vient d'être validée ! Le choix de sortir une seconde version rapidement est volontaire. Il s'agissait de suivre le modèle RERO (Release Early, Release Often). La v1 posait la fonctionnalité de base, tandis que la v2 apporte (presque) tout ce qui manquait. Le but étant aussi de garder un code simple et réduit. Les principaux changements sont :

  • Ajout des signaux "onActivate", "onDesactivate", "onClick", "onRightClick", "onDblClick" et "onRightDblClick"
  • Ajout de la propriété box (left, center, right)
  • Refonte des exemples pour utiliser une classe de base qui manipule la partie DBus plutôt que de tout faire à la main à chaque fois
  • Passage de GPLv2 à GPLv3

La gestion des widgets (côté extension), migre du contrôleur principal à la classe MonitorWidget vu qu'elle prend déjà en charge la box.

C'est donc une version avec beaucoup d'interactivité, et une classe principale dans les exemple qui permet de construire très simplement des minis applications !

Thursday, 16 April 2020
|
Écrit par
Grégory Soutadé

Capture d'écran IWLA

3 ans se sont écoulés depuis la dernière version d'IWLA. C'est avant tout une histoire de flemme avec des commits restés trop longtemps en test (notamment la série d'août 2019), mais cela prouve aussi que le logiciel est relativement stable et répond au besoin. Cette nouvelle mouture apporte :

  • L'ajout d'un mode test (dry run)
  • De nouvelles règles pour la détection des robots (plus de 10 erreurs 404, affichage d'une page sans élément (hit), pas de page et pas de hit)
  • Un nouveau format de base de données qui réduit considérablement la taille à stocker : les statistiques de pages (vues et non vues), de hits (vus et non vus) ainsi que la bande passante sont désormais cumulés et non plus stockés jour par jour. Cette modification entraîne une incompatibilité avec les versions précédentes
  • La mise à jour des données depuis la branche de développement d'AWSTATS
  • Plugin top_pages_diff
  • La possibilité d'exclure une IP des statistiques
  • L'utilisation de cPickle à la place de Pickle
  • Les requêtes des robots ne sont plus sauvegardées (gain de place)
  • Quelques corrections de bug

Comme mentionnées, les modifications visent avant tout à réduire l'empreinte mémoire et disque du logiciel, ce dernier devant tourner sur un serveur avec seulement 1GB de RAM.

À vos téléchargements !

Sunday, 05 April 2020
|
Écrit par
Grégory Soutadé

La crise sanitaire actuelle pousse les entreprises à recourir autant que possible au télétravail. En tant qu'ingénieur logiciel, mon activité s'y prête plus facilement que dans d'autres domaines : un SSH/VNC auquel on pourra adjoindre Jabber, un webmail et un webex pour les réunion audio et roulez jeunesse ! Néanmoins, mon environnement de bureau principal est légèrement différent, de XFCE au travail, je passe à Gnome 3 à la maison. Ainsi, un gadget devenu indispensable n'est plus disponible : le Generic Monitor alias genmon. Indispensable car il me permet de connaître en temps réel le nombre de mail non lus de ma boîte mail.

Ce plugin XFCE permet d'exécuter à intervalle régulier un script, récupère sa sortie et l'affiche (avec un formatage HTML) dans la barre des tâches (en réalité, là où le plugin est instancié). S'il a plutôt tendance à être épuré, le bureau Gnome 3 permet de créer facilement des extensions en Javascript. Un équivalent de genmon n'existant pas, j'ai pris mon courage à deux mains pour le développer.

L'extension Gnome Shell Generic Monitor vient d'être officiellement acceptée !

Capture Gnome Shell Generic Monitor

Les sources (sous licence GPL) sont disponibles sur la forge.

Contrairement au plugin XFCE, celui de Gnome 3 ne lance pas de script, il ne fait qu'écouter via DBUS des requêtes applicatives. Cela ajoute de la souplesse en faisant tourner un ou des scripts simples "métiers", plutôt que d'avoir à développer des extensions spécifiques à chaque fois.

Un exemple Python est fourni, c'est un extrait du script qui tourne chez moi. En plus du nombre de mail, j'affiche également une icône lors de la réception d'un message Pidgin (pratique quand on a raté la notification sonore ou que l'on n'a pas le casque sur les oreilles). Autant j'ai pu être traumatisé à l'époque (plus de 10 ans, certes...) par CORBA, trouvé SOAP assez lourd, autant les wrappers DBUS (du moins Python et Javascript) sont simples à mettre en œuvre. Le seul point négatif : la documentation des extensions n'est pas très fournie, il faut souvent passer par la documentation GNOME (pour le langage C) ou directement regarder les exemples.