Categories
Programming Python

pyAggr3g470r 3.4

Cette nouvelle version de pyAggr3g470r comprend diverses améliorations et corrections mineures de bugs. Une archive est disponible ici.

Principaux changements:

  • les fonctions d’export (epub, HTML et texte) fonctionnent à nouveau;
  • possibilité de modifier l’icône d’un flux, de changer son nom ainsi que son adresse;
  • correction d’un bug sur la page de détails des articles;
  • améliorations mineures du code (surtout au niveau de la gestion de la base MongoDB) et performances;
  • actuellement en test avec plus de 35.000 articles.
Categories
Programming

Go: Channels et Goroutines

Je me suis lancé dans l’apprentissage du langage Go. Lorsque Go a été lancé publiquement en 2009 je m’y étais intéressé que de loin, à mon regret. Car finalement ce langage est bien intéressant et présente certains avantages, particulièrement concernant la programmation concurrente. Ce qui peut résoudre des problèmes de programmation réseau. Pour le moment les aspects qui me plaisent le plus sont donc les channels et les goroutines.

Voici une illustration avec le problème du producteur/consommateur:

package main

import ("fmt")

var done = make(chan bool)
var cake = make(chan int)

func produce (firstname string) {
    for i := 0; i < 10; i++ {
        fmt.Printf("%s make cake %d\n", firstname, i)
        cake <- i
    }
    done <- true
}

func consume (firstname string) {
    for {
      cake_number := <-cake
      fmt.Printf("%s eat cake %d\n", firstname, cake_number)
   }
}

func main () {
   go produce("Alice")
   go consume("Bob")
   go consume("Maxime")
   <- done
} 

Aux lignes 24, 25 et 26 nous lançons 3 goroutines. Il s'agit en fait de 3 threads. Alice va faire des gâteaux pendant que Bob et Maxime vont les manger.

À la ligne 6 nous définissons un channel nommé cake. On peut voir un channel comme un tube FIFO (First In, First Out). Tant que l'envoie de données (cake <- i) dans le tube n'est pas terminé, il n'est pas possible de recevoir des données (cake_number := <-cake) de l'autre côté. Ce qui permet de synchroniser des goroutines sans utiliser de mutex ou autres verrous.

Voici donc le résultat de l'exécution de ce petit programme:

cedric@kubuntu:~$ 6g produc-consum.go
cedric@kubuntu:~$ 6l -o produc-consum produc-consum.6
cedric@kubuntu:~$ ./produc-consum 
Alice make cake 0
Alice make cake 1
Bob eat cake 0
Alice make cake 2
Maxime eat cake 1
Alice make cake 3
Bob eat cake 2
Alice make cake 4
Maxime eat cake 3
Maxime eat cake 4
Alice make cake 5
Alice make cake 6
Bob eat cake 5
Alice make cake 7
Maxime eat cake 6
Alice make cake 8
Bob eat cake 7
Alice make cake 9
Maxime eat cake 8
Bob eat cake 9

Personnellement j'aime assez l'idée des channels. Voici un autre exemple intéressant.

Categories
Computer Programming Python

Sort this messy list

Avec l’odrinateur que j’utilisais en 2007 le tri à bulles s’exécutait en 41.33 secondes sur une liste de 10.000 éléments (avec Python 2.5.1c1). Maintenant il s’exécute en 8.62 secondes (avec Python 3.2.2).

Je pense que je vais essayer de faire tourner certains de ces tris sur plusieurs coeurs. Le résultat devrait être surprenant.

En attendant, tu peux aussi faire ces tests sur ton ordinateur.

Voici le détail des résultats:

Algorithme/Nb elements				500				1000				5000				10000

Tri Insertion			0.0400000000			0.1900000000			4.7000000000			18.6900000000
Tri Fusion			0.0100000000			0.0200000000			0.1100000000			0.2500000000
Tri Natif			0.0000000000			0.0000000000			0.0000000000			0.0100000000
Tri Bulle			0.1000000000			0.4100000000			10.2800000000			41.3300000000
Tri Selection			0.2100000000			0.8300000000			20.6900000000			84.2100000000
Tri Selection 2			0.0400000000			0.1600000000			3.9700000000			15.8300000000
Tri Insertion 2			0.0300000000			0.0800000000			2.1100000000			8.6000000000
Tri Casier			0.0300000000			0.0700000000			0.3100000000			0.6200000000

Temps exprimé en secondes.
Version de Python : Python 2.5.1c1
Date du Test : 28/05/2007

Nom générique de la machine : VAIO PCG-GRV616G
Système d'exploitation : Ubuntu 4.1.2-0ubuntu4 (Feisty Fawn) (avril 2007)
Noyau : Linux version 2.6.20-15-generic
Environnement de Bureau : Gnome 2.18.1
model name	: Intel(R) Pentium(R) 4 CPU 2.60GHz

============================================================================================================

Algorithme/Nb elements				500				1000				5000				10000

Tri Insertion			0.0400000000			0.1600000000			3.9200000000			16.0600000000
Tri Fusion			0.0000000000			0.0200000000			0.0900000000			0.1900000000
Tri Natif			0.0000000000			0.0000000000			0.0100000000			0.0100000000
Tri Bulle			0.0900000000			0.3800000000			9.2400000000			37.3700000000
Tri Selection			0.2000000000			0.7700000000			19.6400000000			78.8000000000
Tri Selection 2			0.0400000000			0.1500000000			3.5200000000			14.3500000000
Tri Insertion 2			0.0200000000			0.0700000000			1.8600000000			7.5800000000
Tri Casier			0.0400000000			0.0700000000			0.3400000000			0.6800000000

Temps exprimé en secondes.
Système d'exploitation : Mandriva 2007.1
Noyau : 2.6.24.4-desktop586-1mnb Linux
model name	: Intel(R) Pentium(R) D  CPU 2.66GHz

============================================================================================================

Algorithm/Nb elements				500				1000				5000				10000

Natif			0.0000000000			0.0000000000			0.0000000000			0.0100000000
Fusion			0.0000000000			0.0000000000			0.0200000000			0.0500000000
Selection			0.0400000000			0.1500000000			3.6200000000			14.3600000000
Casier			0.0100000000			0.0100000000			0.0700000000			0.1500000000
Insertion			0.0100000000			0.0400000000			0.7800000000			3.1500000000
Selection_Better			0.0100000000			0.0200000000			0.6700000000			2.5700000000
Insertion_Better			0.0000000000			0.0200000000			0.3600000000			1.5000000000
Bubble			0.0200000000			0.0800000000			2.2800000000			8.6200000000

Time in seconds.
Date : 2012/04/2012

System : Kubuntu 11.10
kernel : 3.0.0-17-generic
model name	: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Categories
Network Programming Python

pyClique

pyClique

Comme si j’avais trop de temps libre. Voici un nouveau projet: pyClique. Un peu proof of concept.

L’objectif sera de générer des graphes très simples et faire quelques opérations dessus (pas uniquement de trouver des cliques 😉 ). La structure de données se base sur cet essai. Des opérations très basiques sont déjà possibles: afficher un graphe en liste d’adjacence, en matrice, XML et charger un graphe à partir d’un fichier XML. Également quelques opérations pour trouver un chemin avec le poids le plus faible. Cerise sur le gâteau: affichage 3D du graphe.

Mais là n’est pas la finalité. Le but va être d’utiliser cette structure (basée sur les dictionnaires) afin d’instancier des agents SPADE (les noeuds que l’on peut voir sur la vue 3D ci-dessus) qui pourront communiquer sur un réseau d’hôtes en sélectionnant la meilleure route avec l’algorithme de Dijkstra (pour commencer).
Deux noeuds seront connectés de manière directe (de préférence) ou indirecte (via proxy, serveur intermédiaire, etc.). Le poids associé à une arête pourra représenter la qualité de la connexion (type de connection, charge actuel de l’hôte, majoration du coût du à la présence d’intermédiares, etc.). Dans l’exemple ci-dessus si les noeuds sont les agents, pour communiquer avec G le message de F passera donc par A, C et B.

Voici donc l’idée générale (c’est-à-dire avant que d’autres idées viennent tout chambouler) du projet. Cela ne devrait pas prendre beaucoup de temps à implémenter avec la base existante. Il s’agira essentiellement d’écrire une classe noeud implémentant un agent SPADE avec quelques caractéristiques pour fixer le poids entre deux agents.

Un petit projet sympa qui pourra devenir intéressant avec de la chance.

Categories
Programming Python

pyAggr3g470r – export PDF

pyAggr3g470r dispose maintenant d’un export des articles au format PDF. En plus des exports déjà existants: ePub, journal web, HTML simple et texte.

Voici un exemple (Playing with Qubes Networking for Fun and Profit) et un autre (Quand le ciel se couvre). Autant dire que l’export intégral d’une base de 25.000 articles peut prendre un certain temps.

Categories
Programming Python

pyAggr3g470r – export journal Web

pyAggr3g470r dispose maintenant d’un export des articles sous forme de journal Web (vraiment simple). De sorte à pouvoir exporter la base SQLite et de l’envoyer (via scp, ftp ou autre) sur un serveur.

Voici un exemple comprenant 24.999 articles (dont pas moins de 10.000 articles de L’essentiel).

Categories
Programming Python

Balloon prend de la hauteur

Depuis sa création quelques modifications apportés à Balloon le rendent déjà plus utilisable et moins bêta (il y a maintenant simplement un fichier de configuration à éditer). Une des améliorations majeures réside dans le fait que les push ne sont plus réalisés systématiquement après un commit. Balloon attend qu’une série de commits soit réalisée avant d’exécuter un push vers le serveur. Après quelques tests Balloon fonctionne plutôt bien (j’ai testé avec des fichiers textes et images de quelques méga-octets). Mais il y a encore du travail.

Lorsque le code sera un peu plus stable et mieux pensé, je n’aurai plus qu’à écrire la classe GitSync (à l’instar de HgSync) pour gérer les dépôts Git. En effet à terme Balloon pourra synchroniser plusieurs dossiers locaux (avec une racine différente) que ce soient des dossiers versionnés avec Git ou Mercurial.

Une des dernières étapes sera l’écriture d’un watcher pour Windows. Oui ce système dispose d’un noyau un peu primitif, ce n’est pas ma faute. inotify ne semble pas y être implémenté.
Pour le moment Balloon réagit aux événements: IN_CREATE, IN_DELETE, IN_MODIFY, IN_MOVED_FROM et IN_MOVED_TO. Pour la liste complète des événements voyez ce fichier: /usr/include/sys/inotify.h.

Le Wiki explique brièvement comment utiliser Balloon.

Categories
Programming Python

Balloon

Balloon est un nouveau petit projet.
Ce n’est pas le premier du genre. Et c’est une discussion aujourd’hui qui ma un peu motivée.

Ballon peut être vu comme une alternative à Dropbox avec versionnement des fichiers. Ballon pourra fonctionner avec Mercurial et Git (Mercurial pour le moment, mais bientôt Git car depuis aujourd’hui bitbucket supporte Git. Quelle coïncidence!).

Il manque encore deux ou trois modifications pour qu’il soit utilisable out of the box (gestion de plusieurs dépôts locaux, stockage des mots de passe en local). Mais ça fonctionne déjà très bien.
Pour le moment il suffit de créer un dépôt hg (privé ou public) sur votre serveur personnel (ou bitbucket, Google Code, etc.), puis de lancer Balloon sur vos différents ordinateurs avec l’adresse du dépôt hg. Les clients vont alors cloner le dépôt en local et surveiller les modifications. Par modification j’entends: ajout, suppression, renommage, modification du contenu. En fonction de l’événement détecté la commande hg appropriée est lancée de manière transparente, puis un push vers le dépôt hg est effectué. À partir de ce moment les autres clients via un simple pull détectent les modifications et mettent à jour leur dépôt local. Tout ça de manière transparente évidemment.

Et vous savez quoi? Ça fonctionne! Voici un premier test. Les messages des commits correspondent aux divers événements détectés sur mon dépôt local (Added quand j’ai ajouté un fichier, Removed quand j’ai supprimé un fichier, etc.).

Niveau sécurité une connexion HTTPS est utilisée et plus tard j’ajouterai une authentification avec certificat (mot de passe chiffré pour le moment).
Voyons ce que ça va donner.

Categories
Programming

C, Python & Ocaml ou les plaisirs simples de la vie

Un billet en trois parties qui aborde en premier lieu trois beaux langages de programmation bien différents et se ressemblant sur certains points. Ils réunissent expressivité et performance, style impératif et fonctionnel, typage dynamique (mais pas faible) et fort.

Je trouve qu’il est plutôt drôle de les comparer. Python semble sur certains points se situer entre le C et Objective Caml. Enfin c’est mon avis et ce que je constate parfois.

Pour Guido Van Rossum, Python devait être entre un language de script (interprété comme Shell) et le C (compilé) et ainsi tenter de réunir expressivité et performances avec des structures de données évoluées (dictionnaires, tuples, listes, etc.).
Python est donc un language impératif héritant de l’éducation de Guido Van Rossum et sur ce point est proche de C. Cependant il a un typage dynamique fortement typé (inutile de définir de manière explicite le type d’une variable, mais une fois fixé le type a souvent de l’importance). Au contraire le C a un typage très fort.

Cependant des fonctions comme map ou les listes en compréhensions lui donne quelques traits de languages fonctionnels, comme OCaml (preuve que Guido a l’esprit ouvert). Biensûr sur ce point il n’arrive pas à la cheville d’OCaml et c’est normal.

Ce qui est vraiment génial avec Python, c’est la liberté et l’expressivité du langage. Ce qui fait qu’on peut faire facilement à peu près ce que l’on souhaite. Voici par exemple deux petites comparaisons:

  • Ocaml et Python
    Sans être vraiment un langage fonctionnel Python de par son expressivité définit cette fonction d’incrémentation quasiment aussi simplement que OCaml. Grâce au listes en compréhension il peut même faire mieux parfois;
  • C et Python
    En le comparant à C on comprend de suite l’avante du typage dynamique (qui peut être dangereux), mais il sera parfois moins performant pour des calculs plus complexes (par exemple en cryptographie ou pour traiter des longues chaînes de caractères). Voici encore un excellent exemple.

Il y a donc évidemment plusieurs styles pour écrire du Python. Un(e) Pythonien(ne) reconnaîtra le bon.
Lorsque l’on sait un petit peu développer on sent facilement quel langage est le plus adapté dans une situation. Hormis pour des raisons de performances je n’utilisera plus le C pour calculer un PGCD, Fibonacci ou encore jouer avec une liste mais plutôt Ocaml. Je le faisais avant, je n’en ai plus besoin. Par dessus OCaml pour les listes je préfère de loin Python, parfois aussi pour des fonctions mathématiques. Pour des traitements sur des fichiers, chaînes de caractères, le C. Bref, mes trois langages favoris qui permettent de tout faire très bien.

La première partie très plaisante de ce billet se termine sur cette question: De votre côté, comment situez vous C, Python et OCaml?

§

Maintenant parlons du développeur de l’extrême (celui qui aime les lignes de code). Typiquement:

  • il aime écrire une classe en Java juste pour une fonction mathématique (exemple: incrémenter un nombre ou mise à la puissance avec gestion avancée des paramètres dans le build.xml d’Eclipse);
  • il écrit une classe en Java pour lire un fichier texte ou ouvrir une socket;
  • s’il tente de coder un petit morceau (par exemple factorielle) en OCaml, il utilisera une boucle for.

Très souvent ce malheureux Windowsien(ne) dégainera Eclipse pour générer automatiquement un tas de morceaux de codes inutiles. Ce n’est pas forcément un mauvais développeur, il est peut être juste simplement passé à côté de la programmation. Ce sera parfois la faute de l’école, souvent celle du monde de l’entreprise. Pour guérir c’est facile, il suffit de découvrir Python, Perl ou Ocaml. Attention toutefois, OCaml peut provoquer un choc assez violent chez un développeur Java de longue date.
Généralement les systèmes type GNU/Linux vous feront naturellement utiliser Python, Perl et C. OCaml ça sera par pur plaisir.

§

Pour finir passons à une autre catégorie de développeur, le fanatique. On remarquera que cette personne utilisera entre autres Python pour tout et n’importe quoi sans même savoir si Python est bon pour cela. Par exemple pour:

Ah zut, je crois qu’il y a un problème avec la liste. Vous pouvez chercher pour moi?
Certains au lieu de Python choisirons Perl. D’autres Java. Mais ces derniers, ont-ils vraiment choisi?

§

Encore une question: Y a-t-il un ordre d’apprentissage (au moins pour ces trois langages)?

Categories
Programming Python

Et de 20.000 articles

Ça y est pyAggr3g470r a franchi la barre des 20.000 articles. Il n’y a quasiment aucun impacts sur les performances, sauf peut être pour la page management qui permet d’effectuer divers statistiques sur l’ensemble de la base. Mais depuis peu il est possible de charger en mémoire qu’une partie de cette dernière.

Avant de sortir la nouvelle version j’attends que la mise à jour du wiki soit terminée, la procédure d’installation est déjà plus claire. L’installation est aussi encore plus simple qu’avant. Pas beaucoup plus facile, car ce n’était déjà pas très compliqué. Je veux aussi mettre à jour les captures d’écrans ainsi que la vidéo (ce qui est laborieux avec mon ordinateur).

La vidéo de ce billet montrait en Juin 2010 comment récupérer, lancer et utiliser pyAggr3g470r. Bientôt une nouvelle encore plus impressionnante 😉