Syndiquer le contenu
Mis à jour : il y a 3 heures 20 min

Node.js passe la sixième vitesse

12 mai, 2016 - 10:20

Node.js est la principale implémentation du langage JavaScript côté serveur. Elle utilise V8, le moteur JavaScript de Google Chrome, et vient d’atteindre la version 6.0.0 le 26 avril 2016.

La montée de version de V8 vers la version 5.0 a d'ailleurs permis une meilleure prise en charge d'ES6, avec 93 % des fonctionnalités couvertes. Parmi les autres nouveautés, on trouve des performances accrues (notamment pour le chargement des modules), une meilleure stabilité et utilisabilité des API JavaScript (notamment Buffer et File System).

Peu de temps après la sortie de la version 6.0.0, des failles OpenSSL ont été annoncées, ce qui a conduit à la sortie d'une version 6.1.0.

Les différentes versions

Ce n'est pas facile de suivre les différentes branches de node.js suite au fork io.js, qui a ensuite refusionné avec node.js. Toutefois, la situation n'est que temporaire et on devrait y voir plus clair d'ici la fin de l'année. En attendant, voici un petit résumé :

  • node.js 0.10 : une vieille version, qui est toujours celle packagée par Debian notamment, est en phase de maintenance jusqu'à octobre 2016 (ensuite, ce sera les oubliettes)
  • node.js 0.12 : pareil, mais la phase de maintenance durera jusque décembre 2016
  • node.js 4 : c'est la version LTS actuelle. Elle sera en LTS Active jusqu'avril 2017, puis passera en phase de maintenance pour une année supplémentaire
  • node.js 5 : c'est juste une version de développement et elle s'arrêtera dans 2 mois
  • node.js 6 : c'est également une version de développement (current) et deviendra une version LTS en octobre 2016. D'ici là, il pourra encore y avoir des changements assez conséquents (montée de version de V8 notamment).

Donc, pour le moment, il est recommandé d'utiliser node.js 4 en production et de commencer à faire tourner des tests avec node.js 6 dans les environnements d'intégration continue pour détecter les régressions. À noter que pas mal de modules npm compilés sont en train d'être corrigés pour node.js 6.

Npm3

Node.js 5 et 6 viennent avec npm3 et non plus npm2. Ce changement est majeur.

Avec npm2, les dépendances d'une dépendance s'installaient dans le répertoire node_modules de la dépendance. Et donc, on pouvait avoir un même module avec deux versions différentes au sein d'un même projet, si deux dépendances incluaient ce module dans des versions différentes. Avec npm3, ce n'est plus le cas. Toutes les dépendances (directes et indirectes) sont installées dans le node_modules du projet.

Ce changement a permis de régler pas mal de problèmes sous Windows, où les dépendances de dépendances de dépendances de… (vous voyez l'idée) avaient des chemins très longs, trop longs pour Windows. Il permet également de s'assurer qu'un module n'est installé qu'une seule fois par projet, ce qui est très utile pour les projets front-end qui utilisent npm.

Par contre, le passage à npm3 n'a pas que des bons côtés. Ce changement a introduit pas mal de régressions et la situation commence juste à se stabiliser. Npm3 est également de façon notoire bien plus lent que npm2.

ES6, ES7 et la suite

ES6, ou ES2015, la version actuelle du standard qui décrit le langage JavaScript est le fruit d'un long travail et les implémentations des moteurs JavaScript supportent la plupart des fonctionnalités. Que ce soit chez Google, Mozilla, Microsoft ou Apple, on est proche des 100 %, avec jusque quelques bugs sur des cas très particuliers ou la volonté de ne pas implémenter les Tail Calls Optimisation (car ils posent des problèmes).

Pour autant, tout n'est pas rose. Les nouvelles fonctionnalités ne sont pas aussi optimisées que le reste. Les benchmarks montrent qu'il est fréquent que du code ES6 soit entre un et trois ordres de grandeur plus lent que son équivalent en ES5. Les moteurs vont combler ces différences mais cela risque de prendre encore quelques mois ou années.

Autre point noir : les modules d'ES6. L'équipe derrière node.js a fait une proposition pour prendre en charge les modules d'ES6 (en disant que s'ils vont faire les modules d'ES6, ce sera de cette façon, mais il se peut aussi qu'ils ne fassent rien car ils considèrent que les modules d'ES6 sont une mauvaise chose et que le standard devrait étudier à nouveau cette question). Cette proposition n'a pas plu à une partie de la communauté car elle introduit l'extension .mjs, ce qui va poser problème pour les modules qui seront utilisables à la fois par node.js et les navigateurs. On a donc eu le droit à une contre-proposition et les noms d'oiseau ont volé une nouvelle fois sur Twitter. La situation semble enlisée pour le moment.

ES7, ou ES2016, est beaucoup plus léger. C'est principalement l'arrivée de l'opérateur ** pour calculer des puissances et de Array.prototype.includes pour savoir si un élément fait partie d'un tableau.

Par contre, on attend toujours async/await. Cette solution devrait permettre d'écrire du code asynchrone de manière beaucoup plus propre et est même décrite comme la solution miracle depuis plusieurs années. Seul problème, aucun moteur JS ne l'a implémentée pour le moment.

Télécharger ce contenu au format Epub

Lire les commentaires

Meilleures contributions LinuxFr.org : les primées d'avril 2016

12 mai, 2016 - 01:07

Stop à la procrastination. Après une pause de quelques mois, nous reprenons la bonne habitude de récompenser ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, patchs, etc.). Vous n'êtes désormais pas sans risquer de gagner un abonnement à GNU/Linux Magazine France ou encore un livre des éditions Eyrolles ou ENI. Voici les gagnants du mois d'avril 2016 :

Abonnement d'un an à Linux Magazine France

Livres des éditions Eyrolles et ENI

Les livres qu'ils ont sélectionnés sont en seconde partie de la dépêche. N'oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Certains gagnants n'ont pas pu être joints ou n'ont pas répondu. Les lots ont été ré-attribués automatiquement. N'oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d'une dépêche. En effet, c'est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu'à GNU/Linux Magazine France, aux éditions Eyrolles et ENI.

Les livres sélectionnés par les gagnants :

                        Télécharger ce contenu au format Epub

Lire les commentaires

Le MMORPG Ryzom sur Steam depuis le 6 mai 2016

11 mai, 2016 - 15:32

La sortie du MMORPG Ryzom est disponible sur la plateforme de distribution Steam depuis le 6 mai 2016.

Qu'est-ce que Ryzom ?

Ryzom est un MMORPG de science-fantasy basé sur un monde vivant unique : une planète-plante aux paysages envoûtants, sauvage, peuplée de mille dangers. Vous pouvez y incarner une des quatre races humanoïdes du jeu, contribuer à la reconquête de leur civilisation perdue et influer sur l'évolution du monde.

Jeu sandbox au PvP consensuel, au roleplay très présent et à la communauté mature, Ryzom a la spécificité de ne pas limiter ses personnages en classes et dispose d'un système évolué de récolte et d'artisanat. L'alignement des personnages sur une des nations et factions proposées peut évoluer pour mieux suivre le roleplay de chacun.

Bande-annonce : https://www.youtube.com/watch?v=oZVKC5oAk9M

Données techniques

Ryzom est jouable sous Windows, Linux et Mac OS X. Son interface est disponible en allemand, anglais, espagnol, français et russe.

Tarifs

Ryzom est jouable en version gratuite jusqu'au niveau 125, sans limitation de temps.

Plusieurs tarifs d'abonnement sont proposés pour accéder à la version complète qui offre la possibilité d'atteindre le niveau 250, davantage de moyens de stockage et double la vitesse d'acquisition des points d'expérience.

Particularité

Ryzom est l'un des rares MMORPG commerciaux à être entièrement open source : client, serveur, outils, et média, ce qui offre aux joueurs une opportunité unique de s'impliquer dans le développement du jeu, notamment à travers des projets libres Ryzom Core et Ryzom Forge.

Principales améliorations effectuées à l'occasion de la sortie de Ryzom sur Steam Améliorations visuelles
  • Améliorations du rendu (FXAA, filtrage anisotrope, bloom amélioré) ;
  • Correction et régénération de toutes les textures ;
  • Support d'Optimus pour les cartes NVIDIA.
Améliorations techniques
  • Utilisation d'OpenGL comme pilote 3D par défaut pour toutes les plateformes et cartes graphiques ;
  • Mise à jour de toutes les bibliothèques externes ;
  • Support du 64-bits et des dernières versions de toutes les plateformes ;
  • Amélioration du support des compilateurs (GCC 5, MinGW, Visual C++ 2012, 2013 et 2015) ;
  • Amélioration du support du HTML dans le jeu (nouvelles balises, suppression de la dépendance à libwww, correctifs, etc.) ;
  • Nouvelle version multiplateforme du programme de configuration ;
  • Support du format GIF ;
  • Support des noms de fichiers unicodes sous Windows.

Amélioration de la sécurité
  • Hachage des mots de passe en SHA-512 au lieu de DES ;
  • Mise-à-jour du certificat SSL.
Confort et améliorations diverses
  • Amélioration du texte en jeu
  • Générateur aléatoire de nom lors pour la création de personnage ;
  • De nombreuses optimisations, améliorations et corrections de bugs ;
  • Correction de nombreux warnings ;
  • Utilisation de tous les coeurs par défaut ;
  • Détection de la quantité de mémoire disponible sur la carte graphique et utilisation de la qualité adéquate ;
  • Synchronisation verticale supportée sous toutes les plateformes ;
  • Utilisation de XAudio2 comme pilote audio par défaut sous Windows ;
  • Gros refactoring de l'interface afin de créer un éditeur WYSIWYG.

Pour plus d'informations sur Ryzom, veuillez visiter http://www.ryzom.com ou rendez-vous sur la page Steam de Ryzom à l'adresse http://store.steampowered.com/app/373720/.

Télécharger ce contenu au format Epub

Lire les commentaires

Picoloop un séquenceur musical

11 mai, 2016 - 12:38

Picoloop est un séquenceur musical que je développe depuis 2013. Ce logiciel est une « groovebox » logicielle permettant de jouer des séquences de 16 pas. Chaque pas peut contenir une note et un ensemble de paramètres permettant de modifier la tessiture du son joué.

Ce logiciel permet de créer de la musique à partir d'un ordinateur Linux/Windows ou d'une console de jeu PSP, GP2X, Dingoo. Il s'inspire fortement des logiciels Nanoloop (non-libres) développés par Oliver Wittchow un Allemand spécialiste du développement de séquenceur sur GameBoy, GameBoy Advance et Android.

Picoloop est en licence BSD.

Sommaire Histoire de Picoloop

En 2010, j'ai découvert deux logiciels qui ont modifié sur le long terme mon approche de la musique.

Nanoloop

Le premier, Nanoloop, est un séquenceur synthétiseur embarqué dans une cartouche de GameBoy Advance permettant de jouer de la musique électronique. Pour de nombreux utilisateurs, ce logiciel dont je m'inspire très fortement dispose d'une ergonomie tout simplement parfaite.

Je qualifierai même d'oeuvre d'art ce logiciel sur un point de vue ergonomique mais aussi sur ses nombreuses qualités d'un point de vue musical.

Il permet entre autres de jouer quatre pistes monophoniques en stéréo. Il s’intègre avec des instruments midi. Il permet de créer une musique tout à fait cohérente et travaillée.

LGPT

Le second, LGPT, est un séquenceur échantillonneur s'inspirant des trackers des années 90 que l'on trouvait sur Amiga, Atari et DOS. Ce logiciel fonctionne sur de nombreuses consoles portables sous Linux et permet de jouer 8 pistes contenant des samples.

Le label http://www.hexawe.net/ publie des albums qui sont composés uniquement avec ce logiciel. D'ailleurs, la plupart des musiques des albums sont publiées avec le fichier LGPT associé.

Picoloop

Après deux années à me balader avec ces deux logiciels dans mon sac à dos, je me suis dit : « je suis capable de développer mon logiciel, qui répondra à mes besoins et souhaits ».

Je connaissais la programmation C/C++ sous Linux mais je n'avais encore jamais développé de logiciel graphique et sonore sur des plateformes embarquées. J'ai donc commencé à bricoler divers main.c. Je suis arrivé à mettre en place une interface graphique et lui faire jouer des plips et des plops. J'ai porté cette interface sur la plateforme Dingoo, une console portable sous Linux. Et là… je suis clairement tombé dedans.

Séquenceurs menu et affichage

Le séquenceur propose 4 pistes dans lesquelles on retrouve des patterns (les séquences).

Voilà à quoi ressemble le séquenceur graphiquement :

L'affichage est composé de trois élements :

  1. le séquenceur dans une matrice 4x4 de 16 pas
  2. le menu situé en bas, les crochets indiquent le menu sélectionné
  3. les infos courantes situées à droite
  • les pas 1, 7, 10 et 15 seront joués.
  • le cutoff et la résonance sont les paramètres en cours de modification, on peut le voir sur la deuxième ligne de texte à droite
  • la tête de lecture du séquenceur se trouve au pas numéro 8 en vert sombre affiché également à droite (numérotation commençant à 0).
  • le curseur de sélection se trouve sur le pas 7 en vert clair et je suis en train de modifier la hauteur du cutoff et de la résonance pour ce pas.
Le séquenceur

Il permet de jouer de 16 à 128 pas par piste.

BPM

Le BPM (vitesse de lecture en Beat Par Minutes) et le swing (décalage temporel du temps des pas), peuvent être modifiés globalement pour les 4 pistes, en fonction du type de musique que l'on souhaite créer.

Swing

Le swing, parfois appelé groove dans certains séquenceurs, permet de modifier la vitesse de lecture des pas pairs et impairs. Picoloop permet de modifier ce swing de 25 à 75 pour les quatre pistes simultanément.

  • Un swing à 50 donne le même temps de lecture pour chaque pas, on a donc une vitesse de lecture homogène entre les pas.
  • Un swing à 75 permet de lire les pas pairs deux fois plus vite que les pas impairs.
  • Un swing à 25 permet de lire les pas impairs deux fois plus vite que les pas pairs.
TimeDivision

Chaque piste peut profiter d'un temps de divisions temporelles différent. Cela permet de faire varier la vitesse de lecture d'une piste par rapport à une autre. L'utilité pratique d'une telle fonctionnalité est de créer de longues nappes de synthé que l'on fait varier très lentement. Par exemple un temps de division de 8 permet de lire une piste de 16 pas à la même vitesse qu'une piste de 128 pas. Ce qui est très pratique, mais finalement peu disponible dans les séquenceurs à pattern.

Ergonomie du séquenceur

La modification d'un pattern s'effectue en temps réel pendant que le séquenceur joue le pattern. L'ensemble des paramètres de synthèse de chaque synthétiseur peut être modifié pour chaque pas, ce qui donne une variation élevée du son joué par un pattern. Cette ergonomie est similaire à Nanoloop et est proche des séquenceurs Elektron.

Chargement et sauvegarde des patterns

Un menu Load/Save permet de sauvegarder le pattern qui est actuellement joué sur une piste. On peut si on le souhaite sauvegarder et charger indépendamment chaque piste et non les quatre en même temps. Ce qui permet de faire des micro-variations dans ce que l'on joue.

Le chargement d'un pattern s'effectue en temps réel et non à la fin d'un pattern. Cette méthode adaptée au jeu en temps réel, et utilisée typiquement sur les synthétiseurs Volca, augmente le panel de variations possible que l'on peut appliquer à des patterns de 16 pas.

Plateforme

J'ai développé Picoloop pour qu'il fonctionne sur des consoles de jeu mais aussi sur PC.

L'idée est assez simple, je souhaitais :

  • disposer d'un bloc-note musical avec moi ;
  • pouvoir utiliser les pistes créées sur ce bloc-note directement avec mes synthés mais aussi sur un CPU ayant des performances supérieures aux consoles de jeu ;
  • disposer d'un code ayant une portabilité élevée afin de pouvoir le faire évoluer vers les nouvelles plateformes qui sortiront dans le futur ;

Picoloop fonctionne donc sur Linux, Windows mais aussi sur les autres plateformes sur lesquelles j'ai eu le temps de le porter.

Le choix des bibliothèques utilisées par le code du logiciel a été effectué dans un souci de portabilité. J'utilise SDL 1.2 pour l'affichage car SDL 1.2 est encore disponible sur beaucoup de plateformes. RtAudio pour la gestion du son et RtMidi pour la partie Midi (en cours de développement et partiellement implémenté).

PSP et Dingoo

Ici une photo de Picoloop sur plateformes Dingoo avec le système Linux OpenDingux et PSP avec un firmware permettant l’exécution de homebrew (code "maison").

Moteur de synthèse Picosynth

Un synthétiseur soustractif 32 bits 2 oscillateurs utilisant uniquement des entiers que j'ai développé spécialement pour valider le concept de l'application dans un environnement sans virgule flottante. Il utilise une synthèse soustractive très simplifiée. Il permet de jouer des sons très simples.

Picodrum

Un synthétiseur soustractif 32 bits dédié aux rythmes. Il s'inspire très fortement du moteur Picosynth. Il permet de jouer des "kicks", des "hats" et des "snares".

DBOpl

Un synthétiseur FM 2 opérateurs utilisant un code source d'émulation de carte OPL2. Ce type de synthèse était utilisé typiquement sur les jeux DOS.

Cursynth

Un synthétiseur soustractif 2 oscillateurs développé par Matt Tytel disponible également sous Debian en ligne de commande.

Twytch

Également appellé Helm, un synthétiseur soustractif 2 oscillateurs développé également par Matt Tytel. Ce synthétiseur est plus complet et plus varié que Cursynth.

PBSynth

Encore un autre synthétiseur soustractif 2 oscillateurs. Ce synthé a été développé il y a plusieurs années par un amateur de développement logiciel et de musique, à la base pour la plateforme GP2X. Celui-ci occupe très peu de CPU, il fonctionne en entier et virgule flottante et peut être joué sur une console de jeu type PSP.

MDA Drumsynth

Un synthétiseur rythmique développé par la société MDA qui l'a mis en opensource par la suite.

Code source et binaire

Le code source de ce logiciel est hébergé sur GitHub. Le forum du développement du logiciel se trouve hébergé sur chipmusic.org. La dernière version des binaires pour Windows et PSP se trouve sur Dropbox.

Étant seul sur le développement de ce projet que j'effectue par passion, je n'ai pas créé de paquets pour Debian, Redhat et autres versions de Linux. Cependant le logiciel n'est pas compliqué à compiler et le README contient les instructions liées à la compilation sous Linux. Si vous souhaitez contribuer à la création d'un paquet pour votre distribution préférée vous êtes bien évidemment les bienvenus.

Si vous souhaitez contribuer à ce logiciel, je vous invite à soumettre vos diffs au format "diff -Naur" directement dans la partie "issue" dans Github en précisant le tag git sur lequel s'applique ce patch.

Exemples de production

Les deux premiers lien musicaux utilisent Open303 et Cursynth qui sont des synthèses qui demandent une FPU très puissante : comprendre PC desktop ou laptop supportant au moins SSE et fournissant 1 Gflops. Un PC laptop bas de gamme d'il y a quatre ans en est capable.
En clair le code utilisé tourne sur PC et il n'est pas optimisé suffisamment pour tourner sur de l'embarqué, il demande à vue de nez 500 Mflops pour fonctionner correctement par piste, et il y a quatre pistes. Ces tracks n'ont pas été testés sur processeur ARM avec NEON mais les processeurs ARM tablette et smartphone ne sont probablement pas encore en mesure de gérer suffisamment de FLOPS en CPU pour arriver à soutenir 4 voix avec un calcul flottant de ce type.

Le troisième utilise picodrum, picosynth et Dbopl, en gros ce qu'il est possible de sortir sur une PSP ou une Dingoo avec du calcul entier (int long) et pas de FPU. C'est une synthèse moins couteuse que les deux tracks précédentes.

Licence Dialogue entre un attentif modérateur et l'auteur :

« Concernant la dépêche sur Picoloop en cours de modération sur LinuxFr.org : d'abord merci d'avoir rédigé et soumis une dépêche sur LinuxFr.org. L'équipe de modération s'interroge sur une information manquante qui est généralement attendue par nos lecteurs, à savoir la licence du logiciel.

Après un examen rapide, je dirais, sauf erreur, concernant le dépôt Git :

  • rien dans le README global
  • amsynth/ : GPLv2+
  • biquad_filter/ : licence libre basique
  • chip/gb : GPLv2
  • chip/opl2 : GPLv2+
  • PGCPE : licences propriétaires (dont "Not for reproduction (electronic or hardcopy) except for personal use." par exemple). Ça paraît problématique.
  • cursynth: GPLv3+ (potentiellement un souci avec le GPLv2 strict vu plus haut)
  • lgptsampler : GPLv2+
  • mda_drumsynth : GPLv2+
  • midi : une BSD modifiée avec une demande optionnelle d'envoi des modifications
  • open303 : pas d'info de licence, propriétaire donc
  • pbsynth : pas d'info de licence, propriétaire donc
  • picoloop : non concluant, a priori un mélange de licences plus du non spécifié
  • twytch : GPLv3+
  • vopm : non concluant, je dirais propriétaire

La dépêche évoque Picoloop, Picosynth, Picodrum, DBOpl, Cursynth, Twytch, PBSynth et MDA Drumsynth. Pourrait-on connaître la licence de chacun de ces logiciels ? Idéalement l'ajout d'un fichier COPYRIGHT contenant la licence dans chaque répertoire, la mention de la licence dans le README et l'utilisation d'entêtes serait pratique pour déterminer la licence de chaque code. Voir par exemple http://www.gnu.org/licenses/gpl-howto.fr.html pour la GPL. »

La réponse courte

Je vais placer une licence BSD sur le répertoire Picoloop, le code source du logiciel. Ça me semble le plus adapté en fonction de la façon dont je développe ce logiciel. Si une personne souhaite le reprendre un jour il pourra le faire évoluer vers un type de licence plus adapté au cycle de vie de ce logiciel. Je vais intégrer un fichier LICENCE en fonction de ce que j’aperçois dans chaque répertoire, tu as déjà fait un gros bout du boulot. Je répond à ce mail une fois que c'est effectué avec le nom des fichiers et les explications du pourquoi.

La réponse longue

Tu soulèves une question très intéressante mais aussi très longue à détailler et expliquer, j'ai toujours repoussé à plus tard et je n'aurais sans doute pas dû.
Je me suis intéressé uniquement à l'aspect conception du logiciel, les licences pour moi c’était annexe tant que le code semblait être BSD, GPL, MIT et autres licence opensource. Je n'ai toujours pas tranché très clairement la licence qui peut s'appliquer au programme en lui même pour différente raison que je vais décrire. Je vais donc partir par défaut sur la BSD.

Tout d'abord je vais détailler un peu le dépôt github.com/yoyz/audio :

  • Le répertoire "." du git contient les codes sources d'origine sans modification
  • Le répertoire "picoloop" du git contient le programme Picoloop et ses dépendances pour compiler avec gcc/g++ make, en clair le minimum vital pour ne pas avoir à ramener 15 dépendances pour que le binaire puisse fonctionner.

Je ne travaille que dans le répertoire "picoloop" du git pour faire évoluer le logiciel et patcher les moteurs sonores. Je travaille dans le répertoire "." du git pour importer des moteurs sonores. C'est pour ça d’ailleurs que le git s'appelle « audio » et non « picoloop », car un jour j'y ajouterai d'autres programmes qui dépendront de ces moteurs de synthèse. Les imports de code de moteurs de synthèse se font dans le répertoire "." afin de garder une trace des sources originales. J’intègre au final dans Picoloop quand un moteur sonore est fonctionnel tel quel avec un "build.sh" et un "main.c" permettant de valider un helloworld dessus. Par exemple je n'utilise pas encore VOPM, ni PGCPE, enfin celui-ci il va falloir que je creuse pour savoir où il se trouve j'en ai pas de souvenir.

Ensuite le programme Picoloop dans le répertoire du même nom est scindé en deux grosses briques :

  1. le séquenceur qui utilise les bibliothèques RtAudio, RtMidi, SDL1.2, DirectX ;
  2. les plugins moteurs de synthése qui sont dans des licences très variées comme tu as pu le voir.

L'ensemble des .c/.cpp du répertoire picoloop et des répertoires fils sont compilés dans des .o. J'ai donc besoin de l'ensemble des codes des moteurs de synthèse que j'utilise et du séquenceur pour fabriquer le binaire. Il n'est pas possible d'utiliser des .so et donc de désolidariser chaque bout de code, bien que ce soit portable sous Unix, car la PSP ne les prend pas en charge de la même façon, Windows également. Et donc ça demanderait pas mal de boulot pour arriver à un résultat incertain. Donc, pragmatiquement, je suis obligé d'avoir l'ensemble des codes sources pour que ça fonctionne. Et tout ces codes sources dans des licences variées.

Je penche fortement du coup pour une licence BSD pour Picoloop, ce qui laisse à quiconque le soin de faire ce qu'il souhaite des sources sans se préoccuper trop de l'aspect juridique lié aux licences. Pour la simple raison que si la GPL2 est sans doute incompatible avec la licences MIT qui est incompatible avec la tataouinepouetpouet licence, ça ne m’intéressera absolument pas. Qu'est ce que tu en penses vu la construction du soft ?

Dans le monde de la MAO, il y a peu de codeurs (moins de 10) par projet et le code source tombe très souvent aux oubliettes au bout de quelques années. Et avec ce prérequis d’insérer un lot de .h et de .o avec licences variées dans un exécutable, le mieux serait peut-être qu'il soit en BSD au final afin de tout simplifier. Mon intérêt c'est de faire un logiciel qui me plaît et qui plaît aux gens ; si un jour je souhaite faire de l'argent avec, ou si une autre personne souhaite faire de l'argent avec, que ce soit faisable sans devenir un casse-tête juridique. Je pense donc que laisser les sources sans patch et avec patch dans le même arbre ça peut aider à démystifier ce casse-tête, s'il se présente un jour.

Concernant les moteurs de synthèse dont la licence semble problématique voici ce que j'ai trouvé :

  • Open303 : MIT
  • PGCPE : celui-ci je ne l'ai pas vu dans mon code ? Je ne pense pas l'utiliser, il doit traîner dans le "." du git — enfin ça ne me dit rien, mais c'est sans doute un bout de code qui suit un autre bout de code. Très souvent des moteurs sonores sont publiés par des codeurs indépendants sur leur page personnelle. On retrouve très souvent ces bouts de code avec des émulateurs qui sont publiés avec leurs source. D'ailleurs j'encourage tous ces petits gars à publier leur code, même s'ils ne fournissent pas l'infra ./configure et autre pour que ça tourne, juste un bout de code permettant une réutilisation.
  • Pbsynth : le code a été publié avec le binaire Linux Gp2x sur le site Openhandleds. L'auteur ne répond plus à ses courriels, il a sans doute changé d'adresse. Je ne saurais dire quelle est la licence de ce bout de code logiciel, l'auteur a laissé les sources et le binaire volontairement sur le site Openhandhelds. En suivant le fil du README, je pense qu'il ne s'est jamais plus préoccupé de la suite des événements, même s'il a songé un jour à en faire un produit. Donc je ne sais pas, je l'ai contacté, il y a plus d'un an, il ne m'a jamais répondu.
  • Vopm, je viens de lui envoyer un courriel sam_kb CHEZ yahoo.co.jp, c'est un Japonais qui publie des VST freeware pour Windows avec le code source, et là je ne sais pas quel est la licence et j'avoue ne pas lui avoir posé la question précédemment ; je n'utilise pas son code source dans Picoloop, du moins pas encore, mais j'y songe.
Du coup, si je résume
  • Open303 utilise une licence MIT, et il est utilisé dans le code
  • PGCPE il faut que je creuse, sûrement dans le "." du git, mais pas dans Picoloop le logiciel ;
  • Picoloop, on va dire BSD pour que rien ne coince, je vais mettre un fichier LICENCE ;
  • Et concernant ces logiciels qui se trouvent dans "picoloop/Machine" (les moteurs de synthèse) :
    • Picoloop : BSD
    • Picosynth : BSD
    • Picodrum : BSD
    • DBOpl : GPLv2 audio/picoloop/Machine/Dbopl/adlib.h
    • Cursynth : GPLv3
    • Twytch : GPLv3
    • PBSynth : je ne le saurais sans doute jamais
    • MDA Drumsynth : opensource, mais quelles licences ? sur Sourceforge ils disent GPLv2 et MIT, mais je n'en suis pas certain.
Je viens de mettre à jour le git avec tes recommandations.

Voici l'arbre des licences :

dossier licence picoloop BSD picoloop/Machine/MidiOutSystem BSD picoloop/Machine/Cursynth GPLv3 picoloop/Machine/Twytch GPLv3 picoloop/Machine/Dbopl GPLv2 picoloop/Machine/MDADrum GPLv2 picoloop/Machine/Open303 MIT picoloop/Machine/PBSynth Inconnue ; l'auteur a disparu dans la nature picoloop/Machine/Picosynth BSD picoloop/Machine/Picodrum BSD

Tout le reste du repo git, le répertoire "." n'est pas lié au logiciel Picoloop. J'y dépose ce dont j'ai besoin pour travailler, mais on peut construire le logiciel rien qu'à partir du répertoire "picoloop".

C'est donc lié à ma méthode de travail et lié à la construction du logiciel.
Du coup, seul PBSynth pose un souci et je ne vois pas bien comment résoudre ce problème.

Télécharger ce contenu au format Epub

Lire les commentaires

Les journaux LinuxFr.org les mieux notés du mois d'avril 2016

10 mai, 2016 - 23:06

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois d'avril passé.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 18 de l'année 2016

10 mai, 2016 - 14:12

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Numerama] Quels sont les 9 projets open source financés par DuckDuckGo?

Par Julien Lausson, le samedi 7 mai 2016. Extrait:

Le site DuckDuckGo dévoile le nom des neuf lauréats qui ont droit à une enveloppe de 25 000 dollars pour poursuivre le développement de leur projet open source.

Lien vers l'article original: http://www.numerama.com/tech/168426-quels-sont-les-9-projets-open-source-finances-par-duckduckgo.html

[Developpez.com] Emploi: l'open source est un domaine porteur, mais les talents restent une denrée rare

Par Michael Guilloux, le vendredi 6 mai 2016. Extrait:

L'univers des technologies reposant sur l'open source s'agrandit et la demande de professionnels dans ce domaine suit la tendance. La fondation Linux en partenariat avec Dice, un site de recherche d'emploi pour les professionnels de la technologie, vient de publier son rapport annuel sur l'emploi dans le monde open source, l Open Source Jobs Report. À la fois recruteurs et professionnels de l'open source ont été interrogés pour avoir un aperçu du paysage de l'emploi dans le domaine.

Lien vers l'article original: http://www.developpez.com/actu/98431/Emploi-l-open-source-est-un-domaine-porteur-mais-les-talents-restent-une-denree-rare-revele-l-Open-Source-Jobs-Report-de-2016

[Monde qui bouge] Petit périple dans le paysage des Communs

Par Dominique Nalpas, le mercredi 4 mai 2016. Extrait:

Un concept qui ne fait pas toujours l’unanimité et suscite même des inquiétudes mais qui se développe de plus en plus, à Bruxelles comme ailleurs. Essai de décryptage.

Lien vers l'article original: http://www.mondequibouge.be/index.php/2016/05/petit-periple-dans-le-paysage-des-communs

[Defimedia.info] Techno: les hackers mauriciens ne sont pas des pirates

Par Patrice Donzelot, le mercredi 4 mai 2016. Extrait:

Redonner aux «hackers» leurs lettres de noblesse et mettre en avant les talents des Mauriciens dans le codage, tels sont les objectifs de passionnés locaux regroupés dans le collectif ‘hackers.mu’. Le premier message que ces férus d’informatique expliquent, c’est qu’un ‘hacker’ n’est pas un pirate.

Lien vers l'article original: http://defimedia.info/techno-les-hackers-mauriciens-ne-sont-pas-des-pirates-27618

[L'OBS] Loi numérique: tout ce que les sénateurs ont changé

Par Andréa Fradin, le mardi 3 mai 2016. Extrait:

Le Sénat vient de boucler ses discussions sur le texte d’Axelle Lemaire. Il le marque d’une certaine défiance vis-à-vis de l’open data et d’une vive offensive contre les plateformes comme Airbnb et leurs utilisateurs.

Lien vers l'article original: http://rue89.nouvelobs.com/2016/05/03/loi-numerique-tout-les-senateurs-ont-change-263930

Et aussi:

Voir aussi:

[InformatiqueNews.fr] Pourquoi pas un SGBD open source?

Par La rédaction, le mardi 3 mai 2016. Extrait:

Alors que le marché des bases de données s’est stabilisé autour du trio Oracle/IBM/Microsoft et plus récemment SAP, les bases de données open source ont gagné en maturité et deviennent un choix réaliste.

Lien vers l'article original: http://www.informatiquenews.fr/sgbd-open-source-46861

[We Demain] Un projet à 15 millions de dollars pour démocratiser l'éducation grâce au logiciel libre

Par Lara Charmeil, le lundi 2 mai 2016. Extrait:

Issues de 33 pays, 136 équipes vont développer des logiciels éducatifs à destination des enfants défavorisés. Les projets lauréats seront testés en Tanzanie. À l'origine de cette opération inédite, la fondation XPrize, l'UNESCO et le Programme alimentaire mondial.

Lien vers l'article original: http://www.wedemain.fr/Un-projet-a-15-millions-de-dollars-pour-democratiser-l-education-grace-au-logiciel-libre_a1822.html

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie du langage Pharo et de son environnement de développement en version 5.0

10 mai, 2016 - 12:04
Parlons de Pharo

Comme chaque année depuis maintenant près de 7 ans, nous sommes heureux de vous annoncer la nouvelle version de Pharo : Pharo 5.0

Qu'est ce que c'est ?

Pharo est un langage de programmation orienté objet, en Smalltalk, fun et addictif. C'est aussi un environnement de développement complet et qui évolue. Son environnement est capable d'inspecter et de modifier ses objets pendant l’exécution.

Quoi de neuf ? Le Mooc

Vous pouvez dés aujourd'hui vous inscrire et participer au Mooc sur Pharo. Vous y (ré)apprendrez des choses concernant la programmation orientée objet, certains mécanismes, la syntaxe de Pharo et plein d'autres choses. Tout ça au travers d'exercices, et de vidéos explicatives. NdM : voir aussi le journal de lepieru.

Les livres

Pour les fans de lectures sur papier, nous avons l'honneur de vous annoncer que le livre « Enterprise Pharo » sera disponible en version papier. Pour le moment il n'existe qu'en version PDF, mais plus pour longtemps. Nous vous conseillons de jeter un œil sur Updated Pharo By Exemple qui est une version mise à jour du livre « Pharo By Exemple ».

Les ajouts
  • La PharoVM a changé, elle est maintenant basé sur Spur et rend Pharo 35% plus rapide.
  • UnifiedFFI remplace NativeBoost pour fournir une Foreign Function Interface à la compatibilité spur.
  • GTool inclut maintenant GTDebugger.
  • Il est maintenant possible d'ajouter des Breakpoint sans devoir taper du code.
  • QualityAssistance fait partie du navigateur Nautilus, pour indiquer immédiatement le code incorrect ou les bugs.
  • Un widget FastTable pour implémenter facilement des grosses listes, gros tableaux, gros arbres.
  • Nouveau navigateur Catalog pour chercher et installer des projets externes.
Les contributions Pillar

Vous pouvez en apprendre d'avantage dans le Linux Mag du mois d'Avril 2016. Pour résumé, Pillar est un langage balisé écrit en Pharo capable de transformer vos documents pillar en document LaTeX ou HTML de manière extensible et polymorphe.

OpenGL

Voici quelques vidéos qui vous montre la puissance d'OpenGL dans Pharo :

Cette nouvelle version d'OpenGL dans Pharo utilise UFFI.

Pour finir Ce qui vous attend l'année prochaine

Comme tous les ans, une nouvelle version de Pharo devrait arriver. Dans Pharo 6.0, vous aurez enfin la possibilité de versionner vos projets à l'aide de Git. Le gestionnaire de paquets devrait être entièrement repensé. Bien sûr, il y aura encore des corrections de bugs. Mais nous vous donnons rendez-vous l'année prochaine pour partager ces améliorations.

Contributeurs à l'article LinuxFr.org
  • Marion Noirbent
  • Valentin Rickewaert
  • Maxime Roeland
  • Thibault Arloing
  • Yann Dubois
Télécharger ce contenu au format Epub

Lire les commentaires

Crystal, un langage proche de Ruby, en version 0.16

8 mai, 2016 - 22:53

Crystal est un langage de programmation, encore jeune. Il s'inspire de Ruby pour la syntaxe mais vise des performances proches du C. La version 0.16 vient de sortir, avec un nouvel algorithme pour l'inférence de types. À noter, le compilateur de Crystal est écrit en Crystal.

Voici à quoi ressemble un serveur HTTP basique écrit en Crystal :

# A very basic HTTP server require "http/server" server = HTTP::Server.new(8080) do |context| context.response.content_type = "text/plain" context.response.print "Hello world, got #{context.request.path}!" end puts "Listening on http://0.0.0.0:8080" server.listenUne syntaxe proche de Ruby

Comme on peut le voir dans l'exemple ci-dessus, la syntaxe est très proche de celle de Ruby. C'est un des objectifs du langage. Ceci dit, la compatibilité avec Ruby n'en fait pas partie.

On retrouve ainsi des classes similaires à celles de Ruby :

class Person def initialize(name : String) @name = name @age = 0 end def name @name end def age @age end end

Ou la notion de blocks :

def twice yield yield end twice do puts "Hello!" end Typage statique

Mais il existe également des différences avec Ruby. Par exemple, Crystal a un typage statique et des génériques :

class MyBox(T) def initialize(@value : T) end def value @value end end int_box = MyBox(Int32).new(1) int_box.value # => 1 (Int32) string_box = MyBox(String).new("hello") string_box.value # => "hello" (String)

En général, l'inférence de types permet de ne pas spécifier les types des variables et méthodes, mais vous pouvez de manière optionnelle le faire :

def add(x : Number, y : Number) x + y end Bindings avec le langage C

Crystal permet de déclarer des bindings avec le langage C. Et, fait notable, ces bindings peuvent être déclarés en Crystal. Voici un exemple pris de la bibliothèque standard pour s'interfacer avec la libyaml :

@[Link("yaml")] lib LibYAML alias Int = LibC::Int PARSER_SIZE = 480 type Parser = Void* struct VersionDirective major : Int minor : Int end # ... fun yaml_parser_initialize(parser : Parser*) : Int end Génération et évaluation de code au moment de la compilation

Le meta-programming de Ruby est très puissant mais aussi très coûteux en performances. Crystal a donc choisi une autre voie : les macros. Celles-ci permettent d'éviter d'avoir à écrire beaucoup de code répétitif sans impacter de manière notables les performances.

Une macro reçoit un noeud AST et va générer du code lors de la compilation.

macro define_method(name, content) def {{name}} {{content}} end end # Va générer: # # def foo # 1 # end define_method foo, 1 foo #=> 1 Concurrence et parallélisme

Crystal permet actuellement de construire des programmes concurrents avec des primitives comme les fibers et channels, mais la jeunesse du langage se fait sentir sur ces aspects.

On peut séparer des tâches à effectuer dans des fibers. Chaque fiber a un contexte propre et est comparable à une goroutine en Go par exemple. Les fibers sont coopératives et ne vont passer la main à une autre fiber que de manière explicite (par opposition aux threads, qui sont pré-emptifs).

Il existe également une fiber un peu particulière, l'Event Loop, qui gère tous les I/O.

Enfin, les fibers communiquent entre elles via des channels.

require "socket" channel = Channel(String).new spawn do server = TCPServer.new("0.0.0.0", 8080) socket = server.accept while line = socket.gets channel.send(line) end end spawn do while line = gets channel.send(line) end end 3.times do puts channel.receive end

Ainsi, Crystal permet déjà de structurer son code pour gérer la concurrence, mais est limité de la même façon que le JavaScript pour le parallélisme : une seule fibre peut s'exécuter à un moment donné.

Compilation vers du code natif efficace

Crystal profite de LLVM pour compiler vers du code natif. Les performances sont au rendez-vous. Par exemple, dans ce benchmark, Crystal se retrouve entre C/C++ et Go/Node (et donc loin devant Ruby).

Télécharger ce contenu au format Epub

Lire les commentaires

Mageia propose un concours artistique pour sa version 6

8 mai, 2016 - 21:38

Mageia.org a ouvert son traditionnel concours artistique pour sa prochaine version : Mageia 6. Le concours se débute le samedi 7 mai 2016 et sera clôturé le 23 mai 2016 inclus. Pour rappel, Mageia est un système d’exploitation libre, basé sur GNU/Linux. C’est un projet communautaire, soutenu par une association française loi 1901, baptisée Mageia.org, constituée de contributeurs élus.

L’Atelier — équipe en charge du design et de l’identité de Mageia entre autres — a ouvert son concours hier en espérant que nombre d’entre vous serez intéressés et tentés de prendre vos pinceaux, de partir à l’assaut de GIMP, Inkscape & Co pour proposer vos créations !

Mageia fournira un fond d’écran officiel, dix fonds supplémentaires et plein d’autres détails qui rendront Mageia plus attirante. L’Atelier choisira dix fonds d’écrans provenant de différents contributeurs pour les intégrer aux « fonds d’écran supplémentaires ».

Mageia reste une distribution qui repose sur sa communauté, toutes les propositions sont donc les bienvenues.

Vous trouverez toutes les informations nécessaires (aspects techniques, licence, etc.) sur le blog.

Télécharger ce contenu au format Epub

Lire les commentaires

Agenda du Libre pour la semaine 19 de l'année 2016

8 mai, 2016 - 16:33

Calendrier web, regroupant des évènements liés au Libre (logiciel, salon, atelier, install party, conférence) en France, annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 37 événements est en seconde partie de dépêche.

Sommaire Agenda du Libre pour la semaine 19 de l'année 2016 [Montpellier] Formation sécurité informatique et cryptographie - Le lundi 9 mai 2016 de 08h30 à 13h00.

Montpel’libre premier centre formateur Tails en France a le plaisir de vous proposer un nouveau cycle de formation, cryptographie et sécurité informatique. En partenariat avec
Merci d’avoir choisi de participer aux ateliers « Sécurité Informatique et Cryptographie » organisés par Le Club de la Presse et Montpel’libre.
Formation Crypto, séance de préparation, premier module :

[Kunheim] Formation Linux - Le lundi 9 mai 2016 de 18h00 à 22h00.

Tous les lundis à partir de 18h00 jusqu'à 22h00 venez découvrir ou vous former sur Linux et les logiciels libres.
Ces séances de formation ont lieu à la salle "Kegreiss" au 56 rue principale - Kuhneim - face à la mairie - cette salle est accessible aux personnes à mobilité réduite.
Nous vous attendons nombreux. Le Team Linux

[Montpellier] WikiPermanence - Le lundi 9 mai 2016 de 18h00 à 20h00.

Une WikiPermanence est une rencontre physique entre des wikipédiens chevronnés et de nouveaux ou futurs wikipédiens qui souhaitent acquérir des connaissances et des conseils sur le fonctionnement de Wikipédia. Il ne s’agit pas d’une simple rencontre entre wikipédiens : la WikiPermanence est là pour répondre aux questions, permettre des démonstrations, offrir une aide aux premiers pas et, si cela se fait régulièrement, permettre un suivi.
N’hésitez pas à venir : c’est sans inscription, et vous l’aurez deviné, libre et gratuit !
Wikipédia est une encyclopédie libre rédigée collaborativement par des milliers d’internautes. Mais, saviez-vous que vous pouviez y participer ? En apportant des connaissances, en créant ou améliorant des articles, en prenant des photos, ou simplement en corrigeant des fautes, vous pouvez contribuer à ce grand projet d’encyclopédie collaborative.

[Nantes] Atelier Wikipédia Femmes et féminisme - Le lundi 9 mai 2016 de 18h30 à 21h30.

Atelier de contribution à Wikipédia.
L'objectif de cet atelier est de rendre les femmes plus visibles sur Wikipédia en écrivant des biographies de personnages féminins ou des articles en lien avec le féminisme. Ouvert à tou.te.s.
Cet atelier a lieu à l'Espace Simone de Beauvoir, 15 du quai Ernest Renaud, Nantes, arrêt ''Gare maritime'' de la ligne 1 du tramway.

[Champs-sur-Marne] FOSS4G-FR : logiciels libres pour la géomatique - Du mardi 10 mai 2016 à 08h00 au jeudi 12 mai 2016 à 18h00.

Le FOSS4G-fr 2016 est un événement dédié à la géomatique Open Source et aux données géographiques libres, organisé par l'association OSGeo-fr. Il aura lieu du 10 au 12 mai 2016 à l'ENSG (École Nationale des Sciences Géographiques) à Marne-la-Vallée, France.
Cet événement comprend deux jours de conférences précédés d'une journée de workshops. Il vous permettra de découvrir les dernières tendances et technologies du domaine, ainsi que certaines de leurs applications concrètes.
Cet événement s'adresse tant aux utilisateurs qu'aux développeurs d'outils géomatiques Open Source. Retrouvez plus d'informations sur le site de l'événement: http://foss4g.osgeo.fr.

[Villetaneuse] Sécurité, sûreté et confidentialité - Le mardi 10 mai 2016 de 09h00 à 18h00.

Deuxième événement du Printemps de l'innovation Open Source, organisé par le GTLL de Systematic et l'Irill, présidé par Roberto Di Cosmo
Sécurité, Sûreté et Confidentialité
Programme dirigé par Laure Petrucci, directrice du Laboratoire d'Informatique de Paris Nord (LIPN), Université Paris 13, et Roberto Di Cosmo, directeur de l'Irill, Inria, professeur à l'Université Paris-Diderot

[Teyran] Notions PC - Le mardi 10 mai 2016 de 09h00 à 10h00.

Les bases du tableur LibreOffice Calc
Téléchargement, installation et première approche du logiciel PAO Scribus
Réaliser une présentation type « diaporama » avec LibreOffice Impress

[Castelnau-le-Lez] Atelier de développement et programmation - Le mardi 10 mai 2016 de 10h00 à 12h00.

Cet atelier de développement est essentiellement axé sur les langages du Web : html, css (même si ce ne sont pas des langages à proprement parler) javascript et PHP, possibilité aussi d’utiliser Ajax, Jquery, Sqlite et MySql, mais il peut aussi aborder d’autres langage à la demande.
Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.
Entrée libre et gratuite sur inscription.

[Castelnau-le-Lez] Section GNU/Linux - Le mardi 10 mai 2016 de 10h00 à 12h00.

L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien. Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi d’adapter l’acquisition de nouvelles compétences au rythme de chacun.
Vous pourrez y aborder plusieurs thèmes :
Présentation de Linux

[Brignoles] Atelier Libre - Le mardi 10 mai 2016 de 18h30 à 21h30.

Les membres de l'association GULLIVAR (Groupe d'Utilisateurs de Logiciels Libres de l'Intérieur du Var) vous invitent à une soirée atelier / présentation logiciel libre qui aura lieu le 10 mai 2016, dans la salle des Saint Anges, chemin de San Sumian à Brignoles à partir de 18h30.
À 19h30, l'atelier / présentation.
Cette soirée est ouverte à tous, adhérents et sympathisants.

[Paris] Tuppervim #45 - Le mardi 10 mai 2016 de 20h00 à 22h00.

Le tuppervim est un évènement mensuel organisé dans les locaux de Mozilla.
Il a lieu un mardi du mois (généralement le premier).
Le texte suivant a été honteusement copié du site http://tuppervim.org

[Sète] Atelier Gimp et Jeu Vidéo Hedgewars - Le mercredi 11 mai 2016 de 10h00 à 17h00.

Gimp de 10h00 à 12h00 :
Gimp offre de nombreuses fonctionnalités. Il peut être utilisé comme un simple programme de dessin, comme un programme de retouche photo, comme un système en ligne de traitement par lot, comme un générateur d’image pour la production en masse, pour convertir un format d’image en un autre. GIMP est extensible. On peut lui ajouter de nombreux « Greffons » (plug-ins). Une interface de scripts bien développée permet de créer des procédures, les scripts, regroupant plusieurs opérations.
Video Game Workshop Hedgewars de 14h00 à 17h00 :

[Montpellier] Atelier Gimp - Le mercredi 11 mai 2016 de 17h00 à 18h30.

Retouchez vos images et vos photos grâce à un logiciel libre, puissant et gratuit, The GIMP, souvent comparé à Photoshop. Avec ce logiciel simple d’utilisation pour une prise en main rapide et basique, vous pourrez redimensionner vos images, transformer les couleurs, appliquer des filtres, modifier de nombreux paramètres et bien d’autres choses encore.
Plusieurs ateliers vous seront proposés :
Mardi 19 avril 2016 de 17h00 à 18h30

[Rennes] Apéro du Libre - Le mercredi 11 mai 2016 de 19h00 à 22h00.

L'association Actux vous donne rendez-vous pour un nouvel Apéro du Libre, mercredi 11 mai 2016 à partir de 19h, au Papier Timbré, 39 rue de Dinan à Rennes (au croisement de la rue d'Échange).
Les Apéros du Libre sont des rencontres conviviales autour d'un verre, pour discuter, échanger et parfois troller entre utilisateurs et curieux de logiciels et culture libres.
L'apéro est traditionnellement ponctué d'un quiz sans enjeu autour du Libre.

[Béziers] Conférence et débat : Le libre en bibliothèque - Le jeudi 12 mai 2016 de 09h00 à 17h00.

Montpel’libre et la Médiathèque André Malraux de Béziers vous proposent une conférence sur le thème : Comment la bibliothèque s’intègre à la communauté du libre ?
À la fin de notre intervention nous inviterons les participants à venir visiter l’espace de démonstration Jerry qui sera situé dans le corridor de la galerie, où vous pourrez y voir plusieurs machines, elles seront présentées à différents stades de jerryfication (machine complète, machine complète mais ouverte, pièces détachées, ordinateurs reconstitués fonctionnant sous systèmes d’exploitation libres…)
Bus lignes n°3, 19, 20 et 21 du réseau de transports urbains de la Communauté d’Agglomération Béziers Méditerranée vous amènent directement à la médiathèque.

[Paris] Langages et Outils pour la Fiabilité Logicielle - Le jeudi 12 mai 2016 de 14h00 à 19h00.

Troisième événement du Printemps de l'innovation Open Source, organisé par le GTLL de Systematic et l'Irill, présidé par Roberto Di Cosmo
Langages et outils pour la fiabilité logicielle - Printemps de l'Innovation Open Source
Programme dirigé par Emmanuel Chailloux (LIP6/UPMC, Irill), Roberto Di Cosmo (Irif, Irill, Inria, UPD), Fabrice Le Fessant (Inria, OCamlPro)

[Mauguio] Infolibres - Le jeudi 12 mai 2016 de 17h00 à 19h00.

L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à apprivoiser votre système GNU/Linux au quotidien. Le contenu de l’atelier s’adapte aux problèmes des personnes présentes.
Vous pourrez y aborder entre autre :
Tous les jeudis de 17h00 à 19h00 :

[St Julien du Serre] Install-Party 3 - Le jeudi 12 mai 2016 de 18h30 à 22h30.

Soirée "libère ton ordi" au bistro associatif de St Julien-du-Serre (près Aubenas).
Atelier d’accompagnement et d’échange, retours sur vos installations (surprises? difficultés? etc.).
Le jeudi 12 mai 2016 de 18h30 à 22h30

[Lyon] Jeudi du Libre - Le jeudi 12 mai 2016 de 19h00 à 21h00.

Un jeudi par mois l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre) organise une conférence.
Les thèmes abordés sont variés en alternant des sujets techniques avec d’autres qui concernant les utilisateurs et les citoyens.
Soirée de conférence débat sur le thème suivant : Priorité au logiciel libre : point d’étape de l’April

[Lyon] Atelier Découverte - Le jeudi 12 mai 2016 de 19h00 à 21h00.

L'Association Lyonnaise pour le Développement de l'Informatique Libre anime des ateliers pour s’initier aux logiciels libres.
Atelier pratique et de partage de connaissances sur kodi/xbmc
Animé par : Quentin Lavorel, membre de l'ALDIL

[Lyon] Ateliers « découverte du numérique libre » - Le jeudi 12 mai 2016 de 19h00 à 21h00.

Ce Jeudi 12 mai 2016 : ateliers : découverte du numérique libre (gratuit) de 19h00 à 21h00
L’EPN des Rancy de la Maison Pour Tous, situé 249 Rue Vendôme – 69003 Lyon propose avec l’association Aldil des cycles d’ateliers nommés les jeudis de découverte du numérique libre.
Cet atelier propose des petits ateliers pour s’initier à #Linux, au fonctionnement de l’ordinateur ou encore découvrir la programmation (programme annoncé d’un mois sur l’autre en fonction de l’évolution des attentes …)

[Paris] Soirée de Contribution au Libre - Le jeudi 12 mai 2016 de 19h30 à 23h00.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.
Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).
Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

[Lyon] Conférence jeudi du libre - Le jeudi 12 mai 2016 de 19h30 à 21h00.

Ce Jeudi 12 mai 2016 :  Priorité au logiciel libre : point d'étape de l'April (gratuit) de 19h30 à 21h00
L’EPN des Rancy de la Maison Pour Tous, situé 249 Rue Vendôme – 69003 Lyon propose avec l’association Aldil des cycles de conférences nommés les jeudis du libre.
Cette conférence traitera de ce sujet : Priorité au logiciel libre : point d'étape de l'April de 19h30 à 21h00

[Tours] L'auto-hébergement et pourquoi pas chez-vous ? - Le jeudi 12 mai 2016 de 20h00 à 22h00.

Touraine Data Network dans le cadre de son objet "la défense et la promotion du réseau des réseaux Internet" vous propose un atelier sur l'auto-hébergement.
Venez découvrir les principes de l'auto-hébergement de ses propres services numériques: Pourquoi et comment ? L'essayer et pourquoi pas l'adopter !
Des ateliers complémentaires peuvent être organisés sur d'autres créneaux (essentiellement pour la mise en pratique l'atelier du jeudi soir étant la pour la découverte).

[Margencel] Les nouveaux loups du Web avec débat - Le jeudi 12 mai 2016 de 20h00 à 22h00.

Le documentaire Les nouveaux loups du Web sera accompagné d'un débat. Y participeront notamment :
Jean-Yves ROYER, militant pour la promotion du numérique libre, membre de l'April,
Loic GERVAIS, animateur à l'espace public numérique de la Ville de Thonon-les-Bains,

[Montpellier] Permanence « Les logiciels libres, parlons-en ! » - Le vendredi 13 mai 2016 de 17h00 à 19h00.

Le Faubourg Marché, qu’est-ce que c’est ?
Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00 (ou au delà sous réserve d’accord préalable), au 19, rue du Faubourg de Nîmes, 34000 Montpellier.
L’idée est de s’informer et d’informer les adhérents des diverses associations sur le fonctionnement du lieu et des associations, et notamment sur les 5 partenaires qui l’animent et lui permettent ainsi d’exister (autour.com, L’Accorderie, enercoop, modulauto, La Nef). Lors de cette permanence partagée vous pourrez rencontrer les associations La Graine (monnaie locale de Montpellier), éCOhabitons, Montpellier à pied, et bien sûr Montpel’libre.

[Marseille] Repair Café - Le vendredi 13 mai 2016 de 17h30 à 19h30.

Réparez vos objets cassés !
Pour lutter contre l’obsolescence programmée et favoriser le recyclage créatif,  Repair Cafés et l’association CercLL (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres).
Le vendredi 13 mai 2016, de 17h30 à 19h30, réparons ensemble nos outils informatiques, chez Tulavu l'Artyshop 5 rue Félix Éboué Marseille 13002

[Marseille] Soirée mensuelle - Le vendredi 13 mai 2016 de 19h00 à 23h30.

Le PLUG organise une soirée le vendredi 13 mai à partir de 19h.
Venez parler de logiciel libre, présenter vos bidouilles, chercher des réponses à vos questions, etc.
De l’expert au débutant, tout le monde, tous les usages, toutes les expériences sont bienvenus.

[Marseille] Mapathon Missing Maps - Le vendredi 13 mai 2016 de 19h00 à 22h00.

Venez découvrir comment contribuer à OpenStreetMap, le "Wikipedia de la carte", durant un « mapathon » !
(un événement convivial où l'on se retrouve pour cartographier, échanger et apprendre à utiliser les outils permettant de contribuer à OSM).
Cet événement s'inscrit dans le cadre de l'initiative globale Missing Maps, projet humanitaire qui vise à cartographier en amont les parties du mondes vulnérables aux catastrophes naturelles, crises sanitaires, environnementales, aux conflits et à la pauvreté.

[Le Tholonet] Réunion mensuelle de l'Axul - Le vendredi 13 mai 2016 de 20h00 à 23h55.

Les membres de l'Axul (Association du Pays d'Aix des Utilisateurs de Linux et des Logiciels Libres) vous invitent à leur réunion mensuelle qui aura lieu le vendredi 13 mai de 20h00 à 23h55 au 1er étage du centre culturel Georges Duby du Tholonet (859 avenue Paul Julien, à proximité de la place du marché) à Palette, premier village sur la D7n au Sud-Est d'Aix.
Ordre du jour
20h00 - 20h15 : Accueil

[Villeneuve d'Ascq] Libre à Vous - Le samedi 14 mai 2016 de 09h00 à 12h00.

Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres ?
Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.
C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

[Saint-Aunès] Permanence Emmabuntüs et Logiciels Libres - Le samedi 14 mai 2016 de 10h00 à 18h00.

Dans le cadre de notre partenariat avec la communauté Emmaüs, l’équipe de Montpel’libre vous donne rendez-vous chez Emmaüs pour une journée d’information et de sensibilisation à l’utilisation des Logiciels Libres. Nous vous présenterons Ubuntu et bien sûr l’une de ses dérivées Emmabuntüs.
Assistance à la vente sur les aspects techniques
Vous désirez un ordinateur à votre service ?

[Rezé] Carto party OSM - Le samedi 14 mai 2016 de 11h00 à 20h00.

Le principe d’une carto party OSM est de participer à la carte Open Street Map, libre de droit et collaborative.
Site de la carte : http://www.openstreetmap.org
Les sessions seront ouvertes y compris aux débutants.

[Fontenay-le-Fleury] Découvrir les scripts Bash - Le samedi 14 mai 2016 de 14h00 à 17h00.

Root66 organise un atelier samedi 14 mai 2016 à 14 hrs qui sera consacré à la découverte des scripts (programmes) Bash.
Quelques définitions et surtout de nombreux exemples allant du plus simple au plus élaboré ainsi qu'un support « papier » permettront aux visiteurs de découvrir ces outils si utiles, de les mettre en pratique, ou encore de les modifier pour les adapter à leurs besoins spécifiques.
Tout visiteur devra impérativement venir avec son ordinateur !!!

[Ivry sur Seine] Cours de l'Ecole du Logiciel Libre - Le samedi 14 mai 2016 de 14h00 à 18h00.

Présentation de l'E2L
Quel est le rôle de l'école du logiciel libre ?
Tout d'abord, ce n'est pas une école comme les autres. Elle n'a pas d'établissement fixe, pas de cours de récréation, pas de carte d'étudiant, ni de diplôme de fin d'année.

[Marseille] Initiation basique d’une distribution Linux - Le samedi 14 mai 2016 de 14h30 à 18h00.

L’association CercLL vous invite à l’ Atelier du Samedi Libre qui se déroule le samedi 14 mai avril 2016 de 14h30 à 18h00, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille.
Ces ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé.
Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

[Paris] Apéro Parisien du Libre - Le dimanche 15 mai 2016 de 20h00 à 23h00.

Comme chaque 15 de chaque mois, Parinux vous convie à l'Apéro Parisien du Libre (APL).
Cet événement aura donc lieu à l'endroit suivant :
La Belle Equipe 92 rue de Charonne, 75011 Paris Métro: Charonne - ligne 9 Faidherbe-Chaligny - ligne 8

Télécharger ce contenu au format Epub

Lire les commentaires

Je crée mon jeu vidéo E16 : Nouveautés

6 mai, 2016 - 15:35

«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.

Dans l'épisode 15, j'arrêtais… les systèmes à entités. Et j'avais un peu fait miroiter des nouveautés. Donc dans cet épisode, on va en parler de ces nouveautés. Depuis ce dernier épisode qui date quand même d'août dernier, je n'ai pas avancé d'un iota sur Akagoria même (ce qui veut dire que vous auriez pu avoir cet épisode depuis des mois !).

Sommaire

Il y a beaucoup de nouvelles fonctionnalités, je vais tenter à chaque fois de décrire la manière dont j'ai procédé pour les coder (qui n'est sans doute pas parfaite). J'ai mis cette nouvelle version d'Akagoria sur un dépôt github. Comme annoncé au dernier épisode, c'est une refonte complète du code, je suis donc reparti d'un dépôt vierge.

Fonctionnalités Messages et autre données

Tout d'abord, une grosse avancée est d'avoir mis beaucoup de données dans des fichiers textes au format YAML. Pour cela, j'ai fait un DataManager qui est responsable du chargement de toutes les données au démarrage, ce qui fait que tout le code lié à l'analyse lexicale du YAML est restreint à cette classe. Ensuite, on peut accéder aux données via des méthodes simples qui prennent en paramètre des clefs.

On verra par la suite que les dialogues, par exemple, sont dans ces fichiers textes et ce que ça peut apporter. Ici, je vais commencer par parler des différents messages qu'on peut avoir. Il y a d'abord tous les messages qui apparaissent dans l'interface du jeu, ils sont désormais tous dans un fichier et on peut récupérer les messages via une clef. Ensuite, il y a les messages de notification, pratiques pour signaler diverses choses au joueur : quand il vient d'arriver dans une nouvelle zone, quand il a gagné un niveau, quand il approche d'un danger, etc.

Tous ces messages de notification sont gérés dans MessageManager (ouais, je kiffe les managers) qui va se charger d'afficher les messages le temps voulu.

Voici par exemple le message de bienvenue :

Dialogues et traduction

Pour les dialogues, c'est quasiment pareil, ils sont tous dans un fichier. L'intérêt, c'est qu'il n'y a qu'une seule source pour les chaînes à traduire : ces fichiers. Le but est de n'avoir aucune chaîne à traduire dans le code. Pour l'instant, j'y arrive bien. Après, j'utilise une astuce. En effet, les chaînes de caractères dans un fichier YAML peuvent être entourées soit de guillemets simples ', soit de guillemets doubles ". Bon, en fait, il y a des différences entre les deux mais on les oublie pour l'instant. Par convention, les chaînes à traduire sont placées entre guillemets doubles. Par conséquent, on peut appeler xgettext en lui faisant croire que c'est du C et qu'il doit analyser toutes les chaînes de caractère, ça ne pose aucune problème. Et on se retrouve avec un fichier de traduction classique.

Vous aurez remarqué que les messages des captures d'écran sont en français. J'ai réalisé moi-même la traduction des quelques chaînes qui existent jusqu'à présent. Ça m'a permis de voir que ça marchait correctement. Techniquement, dans le code, j'ai utilisé Boost.Locale qui est capable de lire les fichiers générés par gettext. C'est très facile à utiliser et comme toutes mes chaînes sont dans des fichiers, j'ai juste besoin de faire la traduction au chargement des fichiers.

Une des difficultés a été de passer la chaîne traduite à SFML. En effet, SFML est un peu bête. Pour lui, une std::string contient uniquement de l'ASCII plutôt que de l'UTF-8. Et donc, pour que SFML comprenne que la chaîne utilisée contient des caractères hors de l'ASCII, il est obligatoire de la transformer en UTF-32 ! Heureusement, SFML fournit des fonctions de conversion. Ça reste assez pénible. J'ai fait un bout de code qui permet la conversion facilement. Ce choix de SFML est surprenant à l'heure où l'UTF-8 est partout.

En jeu, voilà à quoi ressemble un dialogue.

Le gros rectangle orange est un personnage non-joueur (faites travailler votre imagination). Le rond rouge indique qu'on peut interagir avec lui via un dialogue simple (c'est-à-dire qu'il ne donne pas de quête, il veut juste parler). De la même manière que pour les messages, il existe un DialogManager qui permet de faire avancer les dialogues et de les afficher. À la fin du dialogue, un événement de jeu est envoyé pour permettre éventuellement de modifier l'état global du jeu. Actuellement, la fin du dialogue avec ce premier personnage non-joueur charge un deuxième dialogue pour ce personnage non-joueur (qui est un résumé du premier dialogue). On verra où est codée cette logique un peu plus loin.

Une limite actuelle est que les sauts de lignes doivent être placés manuellement dans le texte. Pour aider à bien placer les sauts de ligne et à vérifier que le texte tient bien dans le rectangle de dialogue, j'ai fait un petit utilitaire appelé akagoria_dialog_validator qui va passer en revue tous les dialogues, en prenant en compte les traductions. Bon, ce n'est pas parfait, il y a de la duplication de code par rapport au jeu (danger !) mais ça fonctionne pour l'instant.

Sauvegarde

Un point important dans un jeu, ce sont les sauvegardes. En particulier dans un RPG à monde ouvert où il faut sauvegarder tout l'état du jeu actuel pour pouvoir le reprendre plus tard. Je me suis donc attaqué à cet aspect assez tôt de manière à voir les problèmes assez vite. J'ai utilisé Boost.Serialization, qui est un peu vieux par rapport à d'autres bibliothèque de sérialisation comme cereal qui gère le C++11, mais elle fait le travail très correctement.

Ensuite, il a fallu décider quoi sauvegarder. Pour l'instant, ça reste assez simple. J'ai sauvegardé les informations concernant le héros (sa position et ses points de vie/magie), les informations concernant les personnages non-joueurs (position, dialogue en cours), et les prérequis (dont on va parler un peu plus loin). J'utilise pour l'instant un format texte pour bien vérifier que j'ai toutes les informations dont j'ai besoin. Plus tard, je pourrai passer à un format binaire très facilement grâce à Boost.Serialization.

Pour finir une petite interface permet de charger et sauvegarder. J'ai volontairement limité les possibilités de sauvegarde à trois emplacements pour deux raisons : d'une part, je trouve que ça fait un peu vieille école ce genre de limitation, ça a un certain charme, j'aime bien ; d'autre part, ça évite de devoir taper à la main un nom puisque je garde à l'esprit que l'utilisateur peut vouloir utiliser une manette pour jouer. De toute façon, d'après mon expérience, trois emplacements sont très largement suffisants.

Visuellement, ça ressemble à l'image suivante qui est issue de l'écran de démarrage.

Dans le futur, j'aimerais indiquer le nom de la région dans laquelle se trouve le joueur pour l'aider à différencier les trois sauvegardes (en plus de la date).

UI et pilotage

Vous avez vu tout un tas de petits bouts d'interface utilisateur. Ces interfaces ont une couleur bien connue des fans de RPG. Techniquement, j'ai essayé de ne pas éparpiller le code qui affiche ces interfaces. J'ai donc fait tout un ensemble de classes qui gèrent les interfaces. Le code contient beaucoup de constantes pour faciliter les modifications. Ces classes sont ensuite utilisées dans les différents gestionnaires (managers) correspondants et sont affichées au besoin. Par exemple, s'il y a un dialogue en cours, on affiche l'interface de dialogue.

Pour piloter tout ça, ça n'a pas été simple. J'utilise une sorte de machine à état pour déterminer quoi faire quand. Toute la logique est encapsulée dans une classe de pilotage du jeu qui intervient directement dans la boucle de jeu. L'idée est que le personnage peut être dans différent mode : marche, dialogue, sauvegarde. Pour chaque mode, les touches n'ont pas la même utilité : haut et bas servent à avancer et reculer en mode marche, tandis qu'ils servent à choisir l'emplacement de sauvegarde en mode sauvegarde. Le pilote de jeu gère tout ça de manière transparente et fait passer d'un mode à l'autre en fonction des actions du joueur. Pour l'instant, la coordination reste assez simple. À noter qu'il y a un autre pilote pour l'écran de démarrage, ce qui montre que cette technique est assez flexible.

En jeu, ce sont les différents gestionnaires qui détectent qu'il faut passer dans un autre mode. Par exemple, les sauvegardes sont réalisées près d'un autel en forme d'étoile et avec des particules bleu ciel. Si on presse la touche action (X pour l'instant) suffisamment près d'un autel de ce type, le dialogue de sauvegarde apparaît.

Pour information, l'autre autel (celui forme de spirale avec des particules rouges) permet de remettre des points de vie. J'ai réalisé ces dessins moi-même avec Inkscape. Petit aparté, la vue de dessus est un vrai challenge (qui me plaît beaucoup), il faut imaginer comment donner une représentation horizontale à des objets qu'on a l'habitude d'imaginer verticalement. J'ai fait au mieux pour ces autels, mais j'aimerais bien savoir si ça rend suffisamment bien. N'hésitez pas à me le dire dans les commentaires.

Prérequis et événements

Une fonctionnalité importante pour pouvoir gérer le cours du jeu est le système de prérequis. Les prérequis permettent de savoir si une action est possible ou pas. Techniquement, c'est juste un ensemble d'identifiants. Pour l'instant, les prérequis peuvent être utilisés directement sur la carte avec Tiled sur des événements. Il était possible jusqu'à présent de déclencher un événement de jeu quand le personnage était dans une certaine zone. Cette fonctionnalité est utilisée pour changer d'étage par exemple et descendre dans des souterrains. Dorénavant, il est possible d'ajouter des prérequis sur la zone. Si le joueur a ces prérequis, alors l'événement de jeu est envoyé, sinon rien ne se passe.

Ce mécanisme va servir à implémenter une partie de la logique du jeu. Par exemple, on va pouvoir empêcher le joueur d'accéder à des endroits clos en mettant un prérequis qui sera accordé si le joueur réalise une certaine action. Les possibilités sont déjà assez importantes. La seule limitation que je vois pour l'instant est qu'il n'est pas possible de coder des conditions complexes puisque ces prérequis s'apparentent à des booléens. Je verrai bien à l'usage.

Un exemple d'utilisation est le message de bienvenue. En fait, le personnage commence sur une zone d'événement avec un prérequis qu'on donne automatiquement au chargement initial du jeu. Cet événement va afficher le message de bienvenue et le prérequis va être supprimé ce qui empêchera le message de bienvenue de réapparaître quand on repassera sur la zone.

Histoire

Dernière fonctionnalité du jour, le déroulement de l'histoire. C'est une partie haut niveau qui est généralement implémentée soit en utilisant des fichiers de configuration, soit en utilisant un langage de script type Lua pour pouvoir gérer des situations complexes avec des bouts de code. Pour ma part, actuellement, je reste avec du C++. J'ai mis la logique de l'histoire dans sa propre classe. Cette classe est simplement à l'affût des événements de jeu, comme la fin d'un dialogue, et met à jour l'état global du jeu (ajout de prérequis, apparition de personnages, ajout de dialogue à des personnages, etc).

Je ne compte pas introduire de fichier de configuration ni de langage de script pour cette partie. Dans le premier cas, il me semble que les possibilités seraient un peu trop limitées. Dans le second cas, il faudrait faire la traduction depuis les objets du jeu vers le langage de script et vice-versa, ce qui demanderait beaucoup de travail. Bref, je suis obligé de recompiler quand je modifie mon histoire mais ça me convient pour l'instant.

Et la suite ?

La suite, ça s'annonce funky. Déjà parce que je suis papa depuis quelques semaines et que ça change la vie (et le temps qu'on peut consacrer à un jeu qu'on développe sur son temps libre). Et ensuite, parce qu'il y a beaucoup de choses en attente. Je n'en parle pas maintenant (ouais, j'adore le suspense), mais il y a déjà trois épisodes en cours d'écriture (dont certains ont été commencés depuis un bout de temps) et je pense qu'il y en aura bientôt un quatrième ! Bref, la série ne s'arrête pas, le jeu non plus mais ça avance à son rythme.

Télécharger ce contenu au format Epub

Lire les commentaires

G'MIC 1.7.1 : quand les fleurs bourgeonnent, les filtres d'images foisonnent.

5 mai, 2016 - 10:57

La version 1.7.1 « Spring 2016 » de G'MIC (GREYC's Magic for Image Computing), infrastructure libre pour le traitement d'images, a été publiée récemment, le 26 avril 2016. Nous continuons notre série de présentation des possibilités et des avancées de ce logiciel libre, avec la description des nouveautés et des améliorations notables introduites depuis notre dernière dépêche sur ce sujet, datant de décembre 2015, qui avait été rédigée à l'occasion de la sortie de la version 1.6.8. Trois versions successives ont été publiées depuis (les versions 1.6.9, 1.7.0 et 1.7.1).
La deuxième partie de la dépêche détaille quelques uns des nouveaux filtres et effets disponibles dans le greffon G'MIC pour GIMP, qui reste l'interface de G'MIC la plus utilisée à ce jour. Nous abordons aussi les autres évolutions diverses du projet comme l'amélioration et la création d'autres interfaces d'utilisation ainsi que les avancées « techniques » réalisées au cœur du framework.

Sommaire 1. Le projet G'MIC en quelques mots

G'MIC est un projet libre ayant vu le jour en août 2008, dans l'équipe IMAGE du laboratoire GREYC (Unité Mixte de Recherche du CNRS située à Caen / France). Cette équipe est composée de chercheurs et d'enseignant-chercheurs spécialisés dans les domaines de l'algorithmique et des mathématiques du traitement d'images. G'MIC est distribué sous licence libre CeCILL (compatible GPL) pour différentes plateformes (Linux, Mac et Windows). Il fournit un ensemble d'interfaces utilisateurs variées pour la manipulation de données images génériques, à savoir des images ou des séquences d'images hyperspectrales 2D ou 3D à valeurs flottantes (ce qui inclut bien évidemment les images couleurs « classiques »).


Fig.1.1. Logo et (nouvelle) mascotte du projet G'MIC, logiciel libre pour le traitement d'image.

Notons qu'une première nouveauté relative au projet concerne Gmicky, la mascotte, qui a été entièrement redessinée, par David Revoy, artiste français bien connu des amoureux du graphisme libre, puisqu'il est à l'origine du fameux webcomics Pepper&Carott. Un grand merci à lui ! (à comparer avec l'ancien dessin de Gmicky toujours visible ici).

G'MIC s'est fait connaître essentiellement via son greffon disponible pour le logiciel GIMP, apparu en 2009, greffon qui propose plus de 460 différents filtres et effets à appliquer sur vos images, et qui ressemble aujourd'hui à ceci :


Fig.1.2. Aperçu de la version 1.7.1 du greffon G'MIC pour GIMP.

Mais G'MIC n'est pas qu'un greffon pour GIMP. Il fournit également une interface en ligne de commande, qui peut s'utiliser de manière complémentaire aux outils CLI proposés par ImageMagick ou GraphicsMagick. Cette interface CLI est, comme on peut l'imaginer, l'interface la plus puissante et la plus flexible du framework. Il existe aussi un service web G'MIC Online associé, pour appliquer des effets sur vos images directement à partir d'un navigateur web. D'autres interfaces basées sur G'MIC sont également développées (ZArt, un greffon pour Krita, des filtres pour Photoflow…) mais leur usage reste pour le moment plus confidentiel. Toutes ces interfaces se basent sur les bibliothèques C++ CImg et libgmic qui sont portables, thread-safe et multi-threadées (via l'utilisation d'OpenMP). Aujourd'hui, G'MIC possède plus de 900 fonctions différentes de traitement d'images, toutes paramétrables, pour une bibliothèque de seulement 6 Mio correspondant à un peu plus de 150 kloc de code source. Les fonctionnalités proposées couvrent un large spectre du traitement d'images, en proposant des algorithmes pour la manipulation géométrique, les changements colorimétriques, le filtrage d'image (débruitage, rehaussement de détails par méthodes spectrales, variationnelles, non-locales…), l'estimation de mouvement / le recalage, l'affichage de primitives (jusqu'aux objets 3d maillés), la détection de contours/la segmentation, le rendu artistique, etc. C'est donc un outil très générique aux usages variés, très utile d'une part pour convertir, visualiser et explorer des données images, et d'autre part pour construire des pipelines personnalisés et élaborés de traitements d'images (voir ces transparents de présentation du projet pour plus d'information sur les motivations et les buts de ce projet).

2. Sélection de nouveaux filtres et effets

Nous proposons ici un résumé des nouveaux filtres et effets les plus marquants récemment développés, et illustrons leur usage depuis le greffon G'MIC pour GIMP. Ces filtres sont bien sûr utilisables également depuis les autres interfaces disponibles (notamment avec gmic, l'interface en ligne de commande). Nous nous sommes restreints aux filtres les plus intéressants à expliquer et illustrer, car en réalité, ce sont plus d'une vingtaine de nouveaux filtres et effets qui ont fait leur apparition depuis la version 1.6.8.

2.1. Création de peintures à partir de photographies

Le filtre Artistic / Brushify tente de transformer une image en peinture. L'idée ici est de simuler (de manière simplifiée) le processus de création d'une peinture sur une toile blanche. On fournit une image modèle à l'algorithme, qui va dans un premier temps, analyser sa géométrie (principalement le contraste et l'orientation des contours), puis tenter de la repeindre en utilisant comme outil un unique pinceau (brush en anglais, d'où le nom de l'effet) qui va s'orienter localement pour s'adapter à la géométrie des contours de l'image.
En simulant suffisamment de coups de pinceaux, on obtient une image « peinte » plus ou moins fidèle à l'image modèle d'origine, en fonction de la forme et de la taille du pinceau utilisé, du nombre d'orientations autorisées, etc. Tout ceci étant réglable par l'utilisateur comme des paramètres de l'algorithme : ce filtre permet donc d'obtenir une grande variété de rendus différents.


Fig.2.1.1. Apercu du filtre « Brushify » dans le greffon G'MIC pour GIMP. La brosse qui va être utilisée par l'algorithme est visible en haut à gauche.

L'animation ci-dessous illustre cette grande diversité de résultats, avec le traitement d'une même image d'entrée (photographie d'une tête de lion), en variant les types de brosses et les paramètres utilisés par l'algorithme. Brushify peut être assez coûteux en termes de temps de calcul (suivant le nombre de coups de pinceaux à simuler), même si l'implémentation de l'algorithme est déjà parallélisée (les différents coeurs de calcul pouvant donner des coups de pinceaux simultanément).


Fig.2.1.2. Quelques exemples de rendus du filtre « Brushify » à partir d'une même image d'entrée, en utilisant des brosses différentes.

À noter qu'il est amusant d'invoquer ce filtre à partir de la ligne de commande (grâce à la fonction -brushify disponible dans gmic), pour traiter des lots d'images et des vidéos (un exemple de vidéo « brushifiée »).

2.2. Reconstruction de données manquantes à partir d'échantillons épars

G'MIC se dote d'une nouvelle fonctionnalité de reconstruction de données manquantes dans des images. Nous avons déjà évoqué ce problème classique de reconstruction en traitement d'images dans des dépêches précédentes (avec l'inpainting comme illustré ici ou encore ici). La nouvelle méthode d'interpolation ajoutée suppose quant à elle que l'on ne dispose que de données connues éparses, par exemple quelques pixels de couleurs dispersés ça et là dans l'image, plutôt que des blocs entiers de données contiguës connues. L'analyse et la reconstruction de la géométrie des structures présentes dans l'image devient alors un problème particulièrement difficile.

La nouvelle fonction -solidify de G'MIC permet de reconstruire des données images denses à partir de quelques points épars connus, en utilisant une technique de reconstruction multi-échelle basée sur les EDP de diffusion. La figure ci-dessous illustre les capacités de cette méthode, avec un exemple de reconstruction d'une image de goutte d'eau. On ne garde ici que 2,7% des données image (ce qui est vraiment peu !) et l'algorithme reconstruit une image entière, qui ressemble à celle d'origine (même si, bien entendu, tous les détails de l'image originale n'ont pas été reconstruits complètement). Plus on dispose d'échantillons, plus on est capable de reconstruire des détails.


Fig.2.2.1. Reconstruction d'une image à partir d'un échantillonnage épars.

Cette technique de reconstruction étant assez générique, plusieurs filtres différents se basant sur celle-ci ont pu être élaborés et ajoutés dans G'MIC :

  • Le filtre Repair / Solidify permet d'appliquer l'algorithme de reconstruction de manière directe, en reconstruisant par interpolation les zones marquées comme transparentes dans les images d'entrées. L'animation ci-dessous montre l'application de ce filtre pour la réalisation d'un effet de flou artistique sur les bords d'une image.


Fig.2.2.2. Aperçu du filtre « Solidify » dans le greffon G'MIC pour GIMP.

D'un point de vue artistique, les possibilités de ce filtre sont nombreuses. Il est par exemple très utile pour générer simplement des dégradés de couleurs de formes complexes dans des images, comme le montre les deux exemples de la figure ci-dessous (ou encore cette vidéo, qui détaille le processus)


Fig.2.2.3. Utilisation du filtre « Solidify » de G'MIC pour créer simplement des dégradés de couleurs aux structures géométriques complexes (images d'entrées à gauche, résultats du filtre à droite).

  • Le filtre Artistic / Smooth abstract reprend le principe utilisé pour l'image de la goutte d'eau vu précédemment : il échantillonne une image de manière éparse, en plaçant des points clés préférentiellement sur les contours présents dans celle-ci, puis tente de reconstruire l'image entière à partir de ces échantillons seuls. Si le nombre d'échantillons est faible, le filtre va génèrer une image continue par morceaux qui peut donc être vue comme une abstraction lisse de l'image d'origine (voir la figure ci-dessous).


Fig.2.2.4. Aperçu du filtre « Smooth abstract » dans le greffon G'MIC pour GIMP.

  • Le filtre Rendering / Gradient [random] permet quant à lui la création de fonds colorés. Le filtre plaçe des points de couleurs aléatoirement sur une image, et les interpole ensuite spatialement avec l'algorithme de reconstruction. On obtient facilement des fonds d'écrans psychédéliques composés de dégradés de couleurs qui partent dans toutes les directions (voir figure ci-dessous).


Fig.2.2.5. Aperçu du filtre « Gradient [random] » dans le greffon G'MIC pour GIMP.

  • Simulation de films argentiques : ce nouvel algorithme de reconstruction d'images à partir d'échantillons épars a également une grande utilité pour les nombreux filtres de simulation de films argentiques, présents dans G'MIC depuis quelques années déjà. La section Film emulation propose en effet un grand choix de filtres dont le but est d'appliquer des transformations colorimétriques, pour simuler le rendu qu'aurait eu une photo numérique si elle avait été prise avec un appareil argentique muni d'un certain type de pellicule. La figure ci-dessous montre par exemple quelques unes des 300 transformations colorimétriques qu'il est possible d'appliquer à partir de G'MIC.


Fig.2.2.6. Quelques unes des transformations colorimétriques disponibles dans G'MIC (parmi + de 300).

D'un point de vue algorithmique, ces algorithmes de transformation colorimétrique sont très simples à mettre en œuvre : on dispose pour chacune des 300 transformations d'une HaldCLUT, c'est-à-dire d'une fonction définissant pour chaque couleur (R,G,B) des pixels de l'image originale, une nouvelle couleur (R,G,B) à attribuer aux pixels de l'image résultante. Cette fonction n'étant pas forcément analytique, une HaldCLUT est généralement stockée sous forme discrétisée, et donne donc le résultat de la transformation colorimétrique pour toutes les couleurs possibles du cube RGB (soit 224 = 16777216 valeurs si on travaille avec une précision de 8bits par composante). La figure ci-dessous illustre la façon dont une transformation colorimétrique basée HaldCLUT s'applique sur l'ensemble des couleurs du cube RGB.


Fig.2.2.7. Principe d'une transformation colorimétrique utilisant une HaldCLUT.

Autant dire que, même en sous-échantillonnant l'espace RGB (sur 6 bits par composante par exemple) et en compressant sans perte le fichier de transformation colorimétrique correspondant, on se retrouve vite avec un fichier qui est relativement volumineux (entre 200 et 300 Kio par fichier). Multipliez ce nombre par 300 (le nombre de transformations colorimétriques disponibles dans G'MIC), et vous arrivez à un total de 85 Mio environ pour stocker l'ensemble de ces transformations. Un peu lourd à diffuser pour de simples filtres de changement de couleurs !

L'idée était donc de développer une méthode de compression avec pertes qui pourrait s'adapter spécifiquement aux données de type HaldCLUT, c'est-à-dire à des fonctions volumiques discrétisées à valeurs vectorielles, qui sont par nature relativement lisses par morceaux. C'est donc ce qui a été fait, en se basant sur l'algorithme de reconstruction de données images à partir d'échantillons épars. Cet algorithme fonctionne en effet avec des données images pouvant être volumiques. Il suffit donc d'extraire un nombre suffisant de points-clés significatifs dans le cube RGB pour permettre la reconstruction d'une HaldCLUT entière, avec une erreur de reconstruction suffisamment faible pour que le résultat de la transformation colorimétrique résultante soit indistinguable de la transformation colorimétrique originale.


Fig.2.2.8. Principe du codage et de la reconstruction d'une HaldCLUT à partir d'un nuage de points clés définit dans le cube RGB.

Donc, au lieu de stocker l'ensemble des couleurs d'une HaldCLUT, on n'en stocke plus qu'un sous-ensemble épars représenté par une liste de { point-clés, couleurs }, et on laisse l'algorithme de reconstruction faire son travail pour regénérer la HaldCLUT entière, avant de l'appliquer sur l'image à modifier. Suivant la complexité des HaldCLUTs à appliquer, plus ou moins de points clés sont nécessaires (ça peut varier de 30 à 2000).
Résultat des courses : On passe de 85 Mio pour le stockage des 300 HaldCLUTs de G'MIC à 850 Kio, soit un gain de compression de 99% ! D'un point de vue pratique, ce nouveau fichier décrivant toutes les HaldCLUTs compressées est facilement distribuable et installable avec le greffon, et un utilisateur peut donc appliquer toutes les transformations colorimétriques de G'MIC en restant hors-ligne (alors qu'auparavant, chaque HaldClUT était téléchargée lors de l'application d'une nouvelle transformation colorimétrique).

Ce nouvel algorithme de reconstruction d'images à partir d'échantillons épars a donc beaucoup d'intérêt, et nul doute qu'il sera réutilisé dans d'autres filtres prochainement.

2.3. Rendre des textures périodiques

Le filtre Arrays & tiles / Make seamless [patch-based] permet de transformer une texture d'entrée en la rendant tuilable, c'est-à-dire en permettant sa répétition sous forme de tuiles le long des axes horizontaux et verticaux, sans que l'on distingue de discontinuités visibles lorsque les bords de deux tuiles adjacentes sont mises bout à bout. C'est une opération qui peut s'avérer très difficile à réaliser si la texture d'entrée est complexe, par exemple avec peu d'auto-similarité, ou avec des changements de luminosités flagrants.
C'est le cas de l'exemple illustré dans la figure ci-dessous, avec une texture chair de saumon présentée sous forme de 4 tuiles disposées en configuration 2x2. L'éclairage de cette texture varie de gauche à droite (du plus sombre vers le plus clair). L'algorithme proposé permet ici de transformer la texture pour que le recollement devienne quasiment invisible. Notons que l'on cherche ici à préserver la texture d'entrée le plus possible, contrairement à l'algorithme de re-synthèse de texture qui était déja disponible, et qui cherchait plutôt à recréer de toute pièces une instance aléatoire d'une texture de taille quelconque ayant les mêmes caractéristiques que la texture modèle. Essayez de réaliser ceci manuellement, et vous vous rendrez compte de la difficulté du problème (qui pourrait paraître simple au premier abord).


Fig.2.3.1. Aperçu du filtre « Make Seamless » du greffon G'MIC pour GIMP, pour rendre des textures tuilables.

À noter que la création de ce nouveau filtre d'aide au tuilage a été suggérée par rewind dans les commentaires de la dépêche précédente sur G'MIC ! Les grands esprits se rencontrent sur LinuxFr.org :)
On peut imaginer de belles applications à ce type de filtres, notamment dans le domaine du jeu vidéo où tuiler des textures pour créer de grands mondes virtuels est monnaie courante. Un autre exemple de tuilage d'une texture complexe de mousse en (tuilage 2x2) est présenté dans l'animation ci-dessous.


Fig.2.3.2. Résultat du filtre « Make seamless » de G'MIC pour rendre tuilable une texture de mousse.

2.4. Décomposition d'une image en niveaux de détails

Un nouveau filtre de décomposition d'image en plusieurs niveaux de détails nommé Details / Split details [wavelets] a également été ajouté. Il implémente un algorithme de décomposition en ondelettes à trous. Pour les connaisseurs, c'est exactement le même algorithme que celui qui est proposé dans le greffon populaire Wavelet Decompose pour GIMP, avec ici en plus, une prévisualisation des échelles de détails et une implémentation parallélisée, tirant parti du multi-coeurs. La figure ci-dessous illustre son action sur un portrait. L'application de ce filtre décompose une image en plusieurs calques de sortie, de telle manière à ce que chaque calque contienne les détails de l'image à une échelle donnée, et que l'ensemble de ces calques de sortie superposés redonne bien évidemment le rendu de l'image d'origine.


Fig.2.4.1. Aperçu du filtre de décomposition d'image par ondelettes dans le greffon G'MIC pour GIMP.

On peut ainsi travailler sur chaque calque séparément, et ne modifier les détails de l'image que pour une échelle donnée. Il y a de nombreuses applications à ce type de décomposition, l'une des plus spectaculaires étant la possibilité de retoucher la peau dans des photos de portraits : les imperfections de la peau se retrouvent généralement sur les calques correspondant à des échelles de détails moyens, alors que la texture naturelle de la peau (les pores) se retrouvent sur les échelles de détails fins, et on peut donc sélectivement effacer les imperfections tout en conservant une texture de peau naturelle après retouche (voir l'animation ci-dessous ou encore ce lien pour un tutoriel détaillé de la procédure, en utilisant GIMP).
Vous avez sans doute déjà vu des photos publicitaires de mannequins ayant une peau exagérément lisse (façon poupée barbie). Dans ce cas, vous savez maintenant que l'infographiste responsable a vraiment fait une retouche de goret ! (le bien-fondé de l'utilité de telles retouches est un autre débat dans lequel on ne se risquera pas ici).


Fig.2.4.2. Un exemple d'utilisation du filtre de décomposition d'image en ondelettes, pour la retouche réaliste de la peau sur un portrait (suppression des imperfections).

2.5. Débruitage d'images par méthode « Patch-PCA »

G'MIC est aussi connu pour posséder de nombreux algorithmes variés de débruitage et de lissage d'images (plus d'une quinzaine à ce jour). Et bien, il en a maintenant un de plus ! Repair / Smooth [patch-pca] est un nouvel algorithme de débruitage d'image performant, basé patch qui a été ajouté à G'MIC. C'est un algorithme parallélisé, mais très coûteux en temps de calcul (probablement à éviter sur des machines à moins de 8 coeurs…). En contrepartie, il est capable de débruiter certaines images de façon parfois spectaculaire, en supprimant le bruit et préservant les détails de l'image, comme l'illustre la figure ci-dessous, avec une image contenant un niveau de bruit assez important. (En passant, merci à Jérome Boulanger pour ses conseils d'expert sur ce sujet).


Fig.2.5.1. Résultat du nouvel algorithme de débruitage d'image basé « patch » de G'MIC.

2.6. Effet « Droste » : la mise en abyme continue

L'effet Droste (aussi appelé mise en abyme) du nom de la marque de cacao ayant utilisé cet effet dans une de ses publicités, consiste à dessiner une partie de l'image dans elle-même, et ceci de manière récursive. Un filtre Deformations / Continuous droste a été récemment ajouté à G'MIC, mais n'a en réalité rien de très nouveau puisque c'est « juste » une réécriture complète du filtre Droste qui était déjà disponible dans le greffon Mathmap depuis quelques années. Mathmap était un greffon populaire pour GIMP, mais il ne semble plus évoluer, ni même maintenu, et l'effet Droste était l'un de ses filtres les plus complexes et les plus emblématiques. Martin « Souphead », un ancien utilisateur de Mathmap a donc pris le taureau par les cornes et s'est attelé à la conversion de ce filtre pour G'MIC. L'intérêt c'est qu'au passage, l'implémentation devient parallélisée. Pour celles et ceux intéressés par les aspects mathématiques de l'effet Droste, on ne peut que recommander la lecture de cette page didactique rédigée par un chercheur du CNRS, page qui contient des résultats amusants de création de séquences périodiques d'images utilisant cette effet.


Fig.2.6.1. Aperçu du nouveau filtre « Droste » pour la création d'une mise en abyme, dans le greffon G'MIC pour GIMP.

Avec ce filtre, tous les délires artistiques sont permis. Il est par exemple trivial de créer en quelques clics de souris le résultat présenté dans la figure ci-dessous : il suffit de détourer l'horloge, de rendre le fond transparent, et d'appliquer le filtre Droste de G'MIC, et voilà ! (à ne pas montrer aux gens stressés par le temps qui passe…).


Fig.2.6.2. Exemple de transformation d'image possible avec le filtre « Droste » de G'MIC.

2.7. Transformation équirectangulaire <-> zénith/nadir

Le filtre Deformations / Equirectangular to nadir-zenith est également un filtre initialement disponible dans Mathmap et qui a été transposé pour G'MIC. C'est un filtre utilisé dans le domaine assez restreint du traitement d'images de panoramas utilisant une projection cylindrique équidistante. Un tel panorama est en général obtenu comme la fusion de plusieurs photographies prises à des angles différents, la fusion étant effectuée de manière algorithmique (par exemple avec le logiciel libre Hugin). Lors de la fusion, il est très fréquent que des pans entiers d'images manquent dans le panorama généré, notamment au niveau des vues de dessus et de dessous (le zénith et le nadir, voir un exemple dans la figure ci-dessous).


Fig.2.7.1. Panorama obtenu par outil de fusion d'image. Certaines parties de l'image (zénith et nadir) sont manquantes.

Il est souhaitable de pouvoir resynthétiser l'information manquante dans ces zones. Mais comment faire ? La déformation induite par la projection cylindrique équidistante fait que la reconstruction directe est difficile dans ces zones (l'utilisation de l'outil de clonage n'est pas adapté par exemple). C'est là que le filtre de G'MIC intervient, en permettant de recréer des vues applaties du zénith et du nadir.


Fig.2.7.2. Récupération des vues applaties du zénith et du nadir de l'image précédente, grâce au filtre G'MIC du greffon pour GIMP.

Une fois ces vues calculées, il devient plus facile de boucher les trous, en utilisant par exemple un filtre de reconstruction de type Inpainting ou l'outil de clonage si on préfère faire ça manuellement.


Fig.2.7.3. Rebouchage des trous, par une technique quelconque (« inpainting » ou outil de « clonage » par exemple).

Il suffit ensuite d'invoquer ce même filtre, en inversant cette fois la transformation, et de réinsérer les zénith/nadir reconstruits dans l'image panorama originale, et le tour est joué. On obtient une belle image panorama complète (voir figure ci-dessous). Notez comme la déformation de l'image est importante dans ces zones, et comment il aurait été difficile de reboucher les trous en agissant directement sur l'image du panorama original.


Fig.2.7.4. Application de la transformation inverse, et insertion dans le panorama d'origine.

Les images présentées dans cette section ont été aimablement fournies par Morgan Hardwood. Morgan a d'ailleurs écrit un tutoriel détaillé sur cette technique de rebouchage d'images de panoramas, qui est consultable ici.

3. Autres améliorations et faits notables

Pour finir, voici en vrac quelques points marquants concernant le développement du projet G'MIC :

  • Le filtre Rendering / Kitaoka Spin Illusion est une autre conversion d'un filtre Mathmap réalisé par Martin « Souphead ». Il permet de générer un certain type d'illusions d'optiques comme le montre la figure ci-dessous (si vous êtes épileptiques, un conseil, fermez les yeux !)


Fig.3.1. Résultat du filtre « Kitaoka Spin Illusion ».

  • Le filtre Colors / Color blindness transforme une image en simulant différents types de daltonisme. Ce filtre peut être utile pour tester l'accessibilité de sites ou de documents graphiques aux daltoniens. Nous avons repris les transformations colorimétriques dont le lien apparaît sur le site Coblis, site qui propose également ce genre de simulation, en ligne. Les résultats obtenus avec le filtre G'MIC sont donc à priori strictement identiques, mais peuvent s'effectuer facilement sur des lots d'images par exemple.


Fig.3.2. Aperçu du filtre de simulation de différents types de daltonisme dans le greffon G'MIC pour GIMP.

  • Depuis quelques années maintenant, G'MIC intègre un évaluateur d'expressions mathématiques, très commode pour réaliser des calculs lors de l'application de filtres (nous en avions d'ailleurs déjà longuement parlé lors de la dépêche précédente). Cet évaluateur d'expression se dote de nouvelles fonctionnalités intéressantes, en particulier la possibilité de faire du calcul avec des variables de type complexe, vectoriel ou matriciel, mais aussi de créer ses propres fonctions mathématiques personnalisées. Par exemple, l'implémentation classique du rendu de l'ensemble de Mandelbrot, réalisé en estimant la convergence d'une suite complexe, peut s'écrire directement de la façon suivante en ligne de commande:
$ gmic 512,512,1,1,"c = 2.4*[x/w,y/h] - [1.8,1.2]; z = [0,0]; for (iter = 0, cabs(z)<=2 && ++iter<256, z = z**z + c); 6*iter" -map 7,2


Fig.3.3. Utilisation de l'évaluateur d'expression mathématiques de G'MIC pour calculer un rendu de l'ensemble de Mandelbrot.

Les possibilités de calcul en sont grandement développée, puisque l'on n'est plus limité à l'utilisation de variables scalaires, mais qu'on peut définir des filtres qui, pour chaque pixel d'une image d'entrée, vont pouvoir effectuer rapidement des résolutions de systèmes linéaires ou encore des décompositions en valeurs propres/vecteurs propres. C'est un peu comme si on disposait d'un mini-(mini)-Octave à l'intérieur de G'MIC. Le filtre Brushify décrit plus haut utilise d'ailleurs de manière intensive ces nouvelles possibilités. À noter que cet évaluateur d'expression possède son propre JIT pour accélérer le calcul d'une expression lorsqu'elle est réalisée sur plusieurs milliers de valeurs simultanément.

  • Une autre contribution technique importante a été apportée par Tobias Fleischer, avec la création d'une API C pour appeler les fonctions de la bibliothèque libgmic (bibliothèque des fonctionnalités de G'MIC possédant initialement une API C++). Comme l'ABI C est standardisée (contrairement à celle du C++), G'MIC peut donc plus facilement s'interfaçer avec d'autres langages que le C++. On peut par exemple imaginer dans le futur la création d'APIs G'MIC pour des langages, comme Python. En passant : si quelqu'un est motivé pour réaliser ce genre de choses, qu'il n'hésite surtout pas à nous contacter ! Tobias utilise actuellement cette nouvelle API C pour développer des greffons basés sur G'MIC respectant l'API OpenFX. Ces greffons devraient donc être utilisables indifféremment dans des logiciels d'édition vidéo comme After effects, Sony Vegas Pro ou encore Natron (voir figure ci-dessous). C'est un travail qui est toujours en cours.


Fig.3.3. Aperçu des greffons OpenFX basés sur G'MIC, tournant sous Natron.


Fig.3.4. Aperçu du script d'interfaçage G'MIC fonctionnant dans le VSE de Blender.

  • Certaines fonctionnalités de G'MIC ont également fait leur apparition dans le logiciel de montage vidéo non-linéaire Flowblade, grâce au travail acharné de Janne Liljeblad son programmeur principal (voir figure ci-dessous). Là encore, le but est de permettre d'appliquer des effets G'MIC sur des séquences d'images dans un but essentiellement artistique, comme le montre cette vidéo, ou encore celle-ci.


Fig.3.5. Aperçu d'un filtre G'MIC tournant sous Flowblade, éditeur non-linéaire de vidéos.

  • Notons également que de plus en plus de ressources extérieures faisant mention de G'MIC font leur apparition sur la toile : des tutoriaux et des articles de blog (ici, ici, ici…), ou encore des vidéos de démonstrations (ici, ici, ici, ici…). C'est très positif pour la visibilité du projet, et en même temps cela fait vraiment plaisir à voir. Merci donc à tout ces gens qui prennent le temps d'en parler de manière bénévole et désintéressée !
4. Comment tout cela va évoluer ?

Quelques petites observations :

  • Comme vous pouvez le constater, le développement du projet G'MIC se poursuit à un rythme soutenu. Ses fonctionnalités semblent intéresser de plus en plus d'utilisateurs (ce que confirme les statistiques de visites/téléchargements du site web), mais aussi de plus en plus de développeurs : aujourd'hui, on retrouve des intégrations ou des greffons (plus ou moins aboutis) basés sur G'MIC dans des logiciels libres aussi divers que GIMP, Krita, Blender, Photoflow, Flowblade, Veejay, EKD et dans un futur proche (du moins on l'espère) Natron.
  • L'un ne va probablement pas sans l'autre : le fait d'avoir des utilisateurs nous encourage à ajouter de nouvelles fonctionnalités régulièrement, ce qui attire aussi de nouveaux utilisateurs. Tant que ça fonctionne de cette façon, on essayera de continuer ! Car notons tout de même que tout ceci demande pas mal de temps (pour ma part, entre 10 et 15 heures par semaine en dehors de mes heures officielles de travail).
  • Tout ça pour redire un grand merci aux utilisateurs et aux contributeurs (toujours plus nombreux), aux curieux et à ceux qui font de la publicité au projet directement ou indirectement. Ça aide énormément !

En réalité, on ne sait pas encore comment le projet G'MIC va évoluer dans le futur, mais il y a déjà tellement de choses à faire dans le présent qu'on se concentre dessus pour le moment. On vous donne peut-être rendez vous dans quelques mois pour la suite des aventures de G'MIC. On vous invite également à rejoindre la communauté présente sur notre forum officiel sur pixls.us pour obtenir plus de renseignements et répondre à vos questions sur le projet. Et surtout, en attendant, n'hésitez pas à vous mettre au traitement d'images libre !

Télécharger ce contenu au format Epub

Lire les commentaires

LibraZiK 1.2 : Premier pas (20160429)

4 mai, 2016 - 14:38

LibraZiK est un projet qui a pour objectif de fournir un système robuste, prêt à l'emploi, et avec une documentation à jour, aux francophones souhaitant faire de la Musique Assistée par Ordinateur (M.A.O.).

LibraZiK est un studio audio-numérique complet fabriqué à partir de logiciels libres pour les ouvrages musicaux.

Après 3 mois de boulot, j'ai le plaisir de vous annoncer la disponibilité de LibraZiK 1.2 !

Au menu principal : tout LibraZiK a été reconstruit pour fournir une version 64 bits (version 32 bits toujours disponible également).

Regardons tout cela d'un peu plus près.

Sommaire

Alors, quoi de nouveau depuis le dernier billet concernant la version précédente ?

Une nouvelle image amorçable (DVD ou USB)

Avec, entre autres :

  • l'apparition d'une version 64 bits (la version 32 bits est également disponible),
  • une reconstruction de tous les paquets-logiciels de LibraZiK en version 64 bits et 32 bits,
  • une possibilité d'installation de l'image amorçable avec une connexion wifi,
  • de nouvelles documentations et mise à jour de documentations déjà existantes,
  • et pas mal de nouveautés logicielles que nous allons voir ci-dessous.
Côté logiciel : Nouveaux logiciels de musique
  • monobristol : un émulateur de synthétiseurs analogiques et autres orgues mythiques (genre les Rhodes, certains Korg et autres) ! À noter que LibraZiK lui fournit une traduction en français de son interface graphique,
  • patchage: pour faire des connexions entre vos logiciels plus intuitivement qu'avec QjackCtl,
  • lv2vocoder: un greffon "vocodeur" au format LV2,
  • ensemble de greffons cmt: une suite de greffons au format LADSPA,
  • autotalent: un greffon au format LADSPA qui permet de corriger les fausses notes chantées. Il peut bien évidemment être détourné de cette utilisation pour en faire des tas d'autres trucs ! C'est à vous de nous dire comment vous l'utilisez ! À noter que LibraZiK lui fournit une traduction en français de son interface graphique,
  • drumkv1, samplv1et synthv1: en greffons LV2 et en logiciels autonome, une trilogie comprenant un synthétiseur virtuel, un échantillonneur et une boîte à rythme,
  • giada, un boucleur audio et/ou MIDI,
  • mverb, un effet de traitement du son et, plus précisément, une belle petite réverbération, disponible en logiciel autonome ainsi qu'en greffon LV2, DSSI, LADSPA et VST grâce au travail de portage sous Linux de Filipe Coelho. LibraZiK commence à être sérieusement bien équipée du côté des réverbérations.
  • qjackrcd, un petit enregistreur tout simple bien pratique !
Mise à jour de logiciels de musique
  • nouvelle version de jalv.select apportant : une icône dans la zone de notification de la barre des tâches (systray), un tri alphabétique des greffons, des raccourcis-clavier pour plusieurs actions, une possibilité de le démarrer minimisé dans la barre des tâches, une possibilité de sélection des greffons et de leurs pré-réglages par le clavier,
    • playitslowly pour la correction d'un bogue : si vous paramétriez le départ de lecture à autre chose que 0 puis pressiez le bouton de rembobinage, alors la tête de lecture retournait à 0 avant de sauter jusqu'à la position de départ sélectionnée. Ceci pouvait occasionner un genre de ''crrrrounnnch'' du son dans certaines conditions. Maintenant, la tête de lecture va directement à la position de départ sans passer par le 0.
    • ardour4 passe en version 4.6 avec pas mal de nouveautés, voir ici (en anglais),
    • Grosse nouveauté ! nouvelle version 2.5.3 de ZynAddSubFX qui apporte notamment la possibilité d'utiliser certains de ces effets en externe grâce aux versions LV2 ou VST de ces effets, ce qui veut dire que vous allez pouvoir les utiliser partout encore plus facilement. À noter également que cette version voit le retour du greffon DSSI ! Création des pages de documentation pour ces greffons : zynalienwah, zynchorus, zyndistortion, zyndynamicfilter, zynecho, zynphaser, zynreverb.
Logiciels divers
  • ajout de vrms, petit utilitaire pour traquer les paquets non-libres sur votre système,
  • ajout de l'extension adblockplus pour iceweasel permettant de faire disparaître des publicités,
  • ajout de tout un tas d'outils bas-niveau pour le partitionnement des périphériques, et pour la reconnaissance et la manipulation de certains systèmes de fichiers,
  • nouveaux noyaux 4.4.6 en version "normaux", "basse-latence" et "temps-réel", pour système 64 bits et 32 bits (normal et PAE). Voir la page explicative concernant les noyaux,
  • nouvelle version de gparted pour ajouter la francisation de l'élément de menu,
  • ajout d'une optimisation permettant la prévisualisation des fichiers XCF (format natif des images du logiciel de dessin et/ou retouche photo "GIMP") . Ceci permet de voir des vignettes miniatures des fichiers *.xcf (de GIMP) sur votre bureau ou dans votre navigateur de fichiers Caja.
Côté documentation : Mise à jour Nouveaux tutoriels Autres
  • Mise en place d'un outil de suivi des bugs (et adaptation au thème graphique général du site) pour pouvoir remonter et garder une trace des améliorations possibles.
  • Mise à jour des greffons de dokuwiki (le logiciel qui sous-tend la documentation)
  • Création d'une fiche pour LibraZiK sur audiofanzine(merci sub26nico !)
Pour les testeurs
  • audacity 2.1.2 ,
  • drumgizmo 0.9.9 et dgedit (son éditeur de kit de batterie) 0~git20151217 ,
  • reZound et la traduction entière de son interface graphique. Documentation : reZound - tour d'horizon,
  • aseqjoy,
  • ardour4 passe en version 4.7 + support expérimental de l'importation de session ProTools,
  • une version du client de messagerie instantanée internet Pidginavec un ajout du support JACK (merci Janus1 du canal IRC),
  • hydrogen 0.9.7 pré-version de test.
Installer Librazik

Si vous êtes nouveau et que vous n'avez pas encore installé LibraZiK, ou bien, si vous voulez vous refaire un Live à jour, veuillez consulter cette documentation qui vous permettra de l'essayer sans l'installer. Vous pourrez, bien entendu, ensuite installer LibraZiK si vous le souhaitez.

Mettre à jour

À noter que si vous aviez un système 32 bits sur un ordinateur 64 bits et que voulez y mettre un système 64 bits, alors une réinstallation complète est le meilleur conseil qui puisse vous être donné.

Si vous aviez une version 32 bits et que vous restez sur une version 32 bits, alors vous n'avez pas besoin de réinstaller votre système. Il vous suffit de le mettre à jour régulièrement. Cette nouvelle version du Live permet simplement d'intégrer les nouveautés récentes de LibraZiK dans le Live.

Bonne ZiK !

Olivier

Télécharger ce contenu au format Epub

Lire les commentaires

Ancestris est disponible pour Haiku

4 mai, 2016 - 09:42

Conséquence directe de contacts lors des JDLL 2016 la distribution Haiku a intégré dans ses paquets le logiciel de généalogie Ancestris depuis le vendredi 22 avril 2016.

Ancestris est gratuit et libre (GPL v2), et il respecte la spécification GEDCOM version 5.52. Il est disponible pour Linux, BSD, Solaris, MAC et Windows. Il est écrit en langage Java et repose sur la plate-forme NetBeans d'Oracle.

Après Arch qui a été la première distribution Linux à mettre Ancestris dans ses dépôts, Haiku met officiellement Ancestris à disposition et ce en un seul et unique contact alors que pour les autres distributions cela traîne encore.

C'est un responsable de paquets d'applications Java qui a fait un paquet binaire, c'est disponible. Dans Haiku il est accessible sur le dépôt "clasqm".

Attention, la dernière alpha disponible n'a pas encore la gestion des paquets, il faut prendre une nightly build en attendant la bêta.

Merci de la part de l'équipe de développement/communication/diffusion d'Ancestris

Capture d'écran d'Ancestris 0.8 (cliquez dessus pour agrandir) :

Télécharger ce contenu au format Epub

Lire les commentaires

Second Open Source Innovation Spring du 3 mai au 28 juin 2016 #OSIS2016

3 mai, 2016 - 16:12

La précédente édition ayant plutôt bien fonctionné, l'IRILL (Institut de Recherche en Informatique et Logiciel Libre) et le GTLL (Groupe Thématique Logiciel Libre du pôle de compétitivité francilien Systematic) remettent le couvert pour un second printemps de l'innovation Open Source, OSIS de son petit nom, en lien avec le Paris Open Source Summit.

Il s'agit de huit conférences sous la même bannière pendant ce printemps (et début d'été !) du 3 mai au 28 juin sur Paris et l'Île-de-France. Le but est de mettre en valeur le travail des équipes de chercheurs français mais aussi la R&D des PME en logiciel libre, notamment auprès des industriels et des institutionnels. L'idée est de faire ressortir des innovation issues de l’Industrie et de la Recherche française, dont le succès et la visibilité se veulent mondial, sur les thèmes porteurs actuels (Big Data, IoT, Cloud, Qualité)

Sommaire Programme de l'OSIS 2016

Plus de quarante conférenciers sur huit conférences portant sur la qualité logicielle, la sureté et sécurité, l'Internet des objets, le déluge des données et l'info-nuagique, etc.

Si les interventions de mai sont déjà bouclées, celles pour juin sont encore en construction. Les informations seront mises à jour si besoin. Pour le programme détaillé, cliquez sur le titre de l'événement.

[IoT] L’Open Source pour l’Internet des Objets

Pour l'industrie des objets connectés, intégrer l'écosystème du libre est une nécessité et une assurance de pérennité.

  • Date : le 3 mai de 14h à 19h
  • Lieu : dans les locaux de Deloitte au 136 av. Charles de Gaulle à Neuilly sur Seine
  • Direction de programme : Pierre Ficheux, directeur technique d'Open Wide Ingénierie (groupe Smile), et Emmanuel Baccelli, directeur de recherche Inria (équipe INFINE) et coordinateur de la communauté RIOT
  • Intervenants : Pierre Ficheux (OpenWide), Emmanuel Baccelli (Inria, RIOT team), Philippe Coval (Samsung), Mark Burton (GREENSOCS), Philippe Krief (Eclipse Foundation), Jean-Paul Smets (NEXEDI) et Christophe.Reithler et Fabrice Dewasmes, (Tarkett/NeoPixl)
  • Informations et inscriptions (il reste très peu de places)
[Qualité Logicielle] Sécurité, sûreté et confidentialité

Le logiciel est devenu partie intégrante de tous les aspects de notre vie et de notre société, et cela pose de nombreux défis : il faut s'assurer qu'un logiciel fait bien ce pour quoi il est prévu (sûreté de fonctionnement), qu'il n'y a pas de comportements non autorisés (sécurité) et qu'il permet le respect de la confidentialité des données. Ce sont autant de défis importants qui sont interconnectés.

Lors de cette journée, académiques et industriels feront le point sur l'état de l'art. Ce sera une occasion unique de comprendre ce que font la recherche et l'industrie dans ces domaines critiques pour notre futur.

  • Date : le 10 mai de 9h à 17h
  • Lieu : Université Paris 13, Institut Galilée, Amphi B, à Villetaneuse
  • Direction de programme : Laure Petrucci, directrice du Laboratoire d'Informatique de Paris Nord (LIPN), Université Paris 13, et Roberto Di Cosmo, directeur de l'Irill, Inria, professeur à l'Université Paris-Diderot
  • Intervenants : Laure Petrucci (LIPN), Stefane Fermigier (GTLL), Jean Mairesse (CNRS), Catuscia Palamidessi (LIX), Benjamin Morin (ANSSI), Tayssir Touili (LIPN), John Regehr (TrustInSoft), Fabrice Kordon (LIP6), Véronique Delebarre (SafeRiver)
  • Informations et inscriptions
[Qualité Logicielle] Langage et outils pour la fiabilité logicielle
  • Date : le 12 mai de 14h à 19h
  • Lieu : locaux de l'IRILL, Université de Jussieu, Paris
  • Direction de programme : Emmanuel Chailloux (LIP6/UPMC, Irill), Roberto Di Cosmo (Irif, Irill, Inria, UPD) et Fabrice Le Fessant (Inria, OCamlPro)
  • Intervenants : Raphaël Amiard (Adacore), Léo Testard (Mozilla), Vincent Balat (BeSport et Université Paris-Diderot), Thierry Lecomte (Clearsy), Antoine Miné (LIP6 - Université Pierre et Marie Curie), Francesco Logozzo (Facebook)
  • Informations et inscriptions
[Cloud] Open Source pour le cloud et les conteneurs

L'Open Source est omniprésent dans les technologies Cloud et conteneur. Cette journée permettra d'apporter un éclairage académique et industriel autour de ces deux technologies. Nous aborderons l'optimisation des ressources gérées par ces technologies, quelles sont les manières d'architecturer les applications en utilisant des microservices, et les problématiques engendrées par la virtualisation de réseau associée aux machines virtuelles et aux conteneurs.

  • Date : le 17 mai de 10h à 19h
  • Lieu : Locaux d'Henix, 23-25 avenue du Docteur Lannelongue, Paris
  • Direction de programme : Frédéric Lepied (Red Hat) et Gilles Muller (Inria / LIP6)
  • Intervenants : Vivien Quéma (IMAG), Gaël Thomas (Telecom Sud-Paris), Pierre Sens, Gauthier Voron et Julien Sopena (LIP6), Olivier Barais et David Bromberg (IRISA), Emile Vauge (Containous), Christophe Sauthier (Objectif Libre), Sylvain Afchain et Chmouel Boudjnah (Red Hat), Hervé Leclerc (Alter Way)
  • Informations et inscriptions
[Big Data] PyData Paris

PyData conferences are a gathering of users and developers of data analysis tools in Python. The goals are to provide Python enthusiasts a place to share ideas and learn from each other about how best to apply the language and tools to ever-evolving challenges in the vast realm of data management, processing, analytics, and visualization.

We aim to be an accessible, community-driven conference, with tutorials for novices, advanced topical workshops for practitioners, and opportunities for package developers and users to meet in person.

A major goal of PyData events and conferences is to provide a venue for users across all the various domains of data analysis to share their experiences and their techniques, as well as highlight the triumphs and potential pitfalls of using Python for certain kinds of problems.

  • Date : le 14 juin de 9h à 18h
  • Lieu : Paris
  • Direction de programme : Alexandre Gramfort (Telecom ParisTech), Stéfane Fermigier (Abilian, GTLL), Gaël Varoquaux (Inria)
  • Intervenants : en cours de validation
  • Informations et inscriptions
[Big Data] Scikit-Learn Day Paris

The Scikit-Learn Day 2016 : for beginners, contributors and startup founders

  • Date : le 15 juin de 9h à 17h:
  • Lieu : Paris
  • Direction de programme : Alexandre Gramfort (Telecom ParisTech) et Gaël Varoquaux (Inria)
  • Intervenants : (en cours de confirmation)
  • Informations et inscriptions
[Qualité Logicielle] Frama-C Day

A one-day workshop by the Frama-C community, gathering both academic & industrial users around shared experiences and new perspectives.

  • Date : le 20 juin de 9h à 17h
  • Lieu : Paris
  • Direction de programme : Florent Kirchner, directeur du laboratoire Sûreté du logiciel, CEA List
  • Intervenants : (en cours de confirmation)
  • Informations et inscriptions
[Qualité Logicielle] Techniques de programmation web à l’état de l’art

Les applications web actuelles sont de plus en plus dynamiques et mélangent un calcul du côté du serveur web (et parfois serveur applicatif ou base de données) et un calcul dans le navigateur. Elles sont donc "multi-tier" c.à.d. à plusieurs étages.
Pour éviter la complexité intrinsèque de codage d'application multi-programmes, la tendance est de méta-programmer, donc de générer du code différent dans le serveur et le navigateur. Un concept fondateur est la notion de continuations. Le système HOP (et quelques autres) propose un langage unique qui mélange les calculs des deux côtés. Enfin, la tendance se dessine d'inverser le contrôle dans le développement Web, au profit du navigateur.
Cette demi-journée devrait intéresser tout développeur Web, notamment ceux qui sont effrayés par la complexité grandissante du flot de contrôle dans les applications Web.

  • Date : le 28 juin de 14h à 18h
  • Lieu : locaux de l'IRILL, Université de Jussieu, Paris
  • Direction de programme : Roberto Di Cosmo, IRILL, Inria, UPD et Basile Starynkevitch, CEA List, Laboratoire Sûreté du logiciel
  • Intervenants : Christian Queinnec (LIP6, UPMC), Manuel Serrano (Inria), Gregory Potdevin (Appcraft.fr) (provisoire)
  • Informations et inscriptions
Télécharger ce contenu au format Epub

Lire les commentaires

Sondage 2016 pour présenter votre GULL

3 mai, 2016 - 11:45

Ceci est un sondage 2016 pour connaître l'évolution des activités des GULL, Groupes d'Utilisateurs de Logiciels Libres depuis leur création. Merci de le transmettre à vos membres et non membres durant un atelier, pour le compléter avec votre association. Envoyez-nous vos réponses avant le 25 mai 2016 à vale-pada CHEZ gmx.com et t CHEZ thlf.me. L'analyse sera publiée sur LinuxFr.org et les sources archivées par l'April.

Pour mieux connaître votre GULL
  • 1 . Quel est le nom de votre GULL: ……………..
  • 2 . Quelle est l'année de création de votre GULL?: ……………..
  • 3 . Dans quels pays et département êtes-vous situé ? : ……………..
  • 4 . Combien de membres avez-vous eu en moyenne en 2015 ? : …..
  • 5 . Quel est le ratio homme / femme, membres de votre GULL ? …. (compléter par: 7 hommes, 3 femmes ou 70% hommes et 30% de femmes)
  • 6 . En 2015, dans quel type de structure accueilliez-vous les participants aux ateliers (install party, démo, des présentations) ? …………….. exemple: une salle dans la bibliothèque, maison de quartier, autre.
  • 7 . Pour présenter votre activité, annoncer les dates de rencontres et relayer les actualités, lequel de ces outils avez-vous mis en place? : un forum, un site Web, un compte Framasphère, Facebook, un blog, un wiki, Twitter, autre.
  • 8 . Mise en réseau :
    • 8.1 Avez-vous mis des liens vers des sites amis ou des activités connexes : oui / non
    • 8.2 Un annuaire des entrepreneurs locaux du Libre : oui / non
    • 8.3 Des actualités locales/régionales ou nationales sur le Libre : oui / non
    • 8.4 Des ressources comme des présentations ou des livres de références : oui / non
Les expériences de votre GULL
  • 9 . Quelles solutions ou services a apporté votre GULL lors de sa création : …………….. exemple: un service de proximité, une alternative, un témoignage en entreprise, logiciel…
  • 10 . Depuis votre création, quelles sont les 3 questions les plus fréquemment posées par les participants (install party) : ……………..
  • 11 . Ces dernières années, quelles sont les 3 questions les plus posées par les participants de vos ateliers (install party) : ……………..
  • 12 . Citez 3 de vos projets phares menés depuis la création de votre GULL et qui ont reçu un retour positif : …………….. exemple : contribuer et animer une journée du Libre (liens), préparer un stand aux RMLL avec les membres (liens), soutenir des entreprises du Libre (liens), autre.
  • 13 . Quels sont les freins majeurs à l'adoption du Libre que vous avez constatés : ……………. exemple: le manque de temps, les groupes de pression, le manque d'accompagnement au changement, améliorer sa communication, autre.
  • 14 . Quels sont les éléments mobilisateurs que vous avez constatés : …………….. exemple: animer sur une nouvelle version, un sujet d'actualité, inviter un entrepreneur, un chercheur, l'associer à d'autres associations et communautés (Open Street Map, Ubuntu-Fr…), autre.
En 2016, si vous regardez en arrière et ce que vous avez accompli
  • C'est-à-dire sur votre travail enthousiaste d'informer et animer des ateliers de proximité, de soutenir et échanger avec d'autres collectifs, organiser des événements du Libre:
  • 15 . Quelles sont les phases majeures que vous notez depuis le lancement de votre GULL? ……………..
  • 16 . Quelles sont les 5 évolutions majeures dans la communauté du Libre que vous retenez depuis dix ans ? ……………..
  • 17 . Quel élément ou chiffre illustre pour vous la force du Libre, ces dernières années? ……………..
  • 18 . Parce que nos communautés partagent, présentez-nous un de vos bons souvenirs dans l'aventure du Libre : un témoignage, un encouragement, une reconnaissance, un projet qui a grandi. Dans notre GULL, notre meilleur souvenir est "……………". N'hésitez pas à nous envoyer des photos, si vous souhaitez :-)

Merci à toutes et tous. Bonne rédaction.
Librement !

Tout savoir sur: Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 17 de l'année 2016

3 mai, 2016 - 11:19

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[LeMagIT] OS, poste de travail, suite bureautique: osez les alternatives!

Par Gene Demaitre, le vendredi 29 avril 2016. Extrait:

Les administrateurs réfléchissant à des alternatives libres aux postes de travail Windows devraient savoir ce qu’offre déjà la communauté.

Lien vers l'article original: http://www.lemagit.fr/conseil/OS-poste-de-travail-et-suite-bureautique-oser-les-alternatives

[Télérama] Hadopi supprimée en 2022: “Je ne m'attendais pas à ce que l'amendement passe”

Par Olivier Tesquet, le vendredi 29 avril 2016. Extrait:

La député Isabelle Attard a réussi, à la surprise générale, a faire passer un amendement qui prévoit en 2022 la fin de la haute autorité chargée de la lutte contre le téléchargement illégal. Elle s'en explique.

Lien vers l'article original: http://www.telerama.fr/medias/hadopi-supprimee-en-2022-je-ne-m-attendais-pas-a-ce-que-l-amendement-passe,141720.php

[Next INpact] Loi Numérique: les sénateurs grillent la priorité au logiciel libre

Par Marc Rees, le jeudi 28 avril 2016. Extrait:

Dans le cadre des débats autour du projet de loi Lemaire, les sénateurs ont finalement refusé d’accorder la priorité au logiciel libre dans la vie des administrations. En lieu et place, ils ont adopté un amendement du groupe socialiste se limitant à encourager ces licences.

Lien vers l'article original: http://www.nextinpact.com/news/99643-loi-numerique-senateurs-grillent-priorite-au-logiciel-libre.htm

Et aussi:

Voir aussi:

[Libération.fr] Grâce au numérique, le mouvement perpétuel

Par Amaelle Guiton, le jeudi 28 avril 2016. Extrait:

La création de plusieurs outils, dont la nouvelle version du site mise en ligne mercredi, vise à soutenir les rassemblements et à prolonger la lutte sur Internet.

Lien vers l'article original: http://www.liberation.fr/france/2016/04/28/grace-au-numerique-le-mouvement-perpetuel_1449290

Et aussi:

[ZDNet] Bureautique: le format ODF recommandé dans les administrations

Par Thierry Noisette, le lundi 25 avril 2016. Extrait:

La nouvelle version du référentiel général d'interopérabilité recommande le format ODF dans les administrations et pointe les défauts de l'OOXML de Microsoft. Le RGI s'appuie par ailleurs sur Wikipedia.

Lien vers l'article original: http://www.zdnet.fr/actualites/bureautique-le-format-odf-recommande-dans-les-administrations-39836012.htm

Et aussi:

Voir aussi:

[Next INpact] Au Sénat, nouvelle charge contre l'ouverture des codes sources des administrations

Par Xavier Berne, le mercredi 25 avril 2016. Extrait:

Alors que les discussions relatives au projet de loi Numérique doivent débuter demain au Sénat, un parlementaire vient de déposer un amendement s’opposant à l’ouverture du code source des administrations – au travers d’une argumentation qui risque d'en laisser plus d'un pantois.

Lien vers l'article original: http://www.nextinpact.com/news/99591-au-senat-nouvelle-charge-contre-l-ouverture-codes-sources-administrations.htm

Voir aussi:

Télécharger ce contenu au format Epub

Lire les commentaires

Bilan 2015 du MMORPG Ryzom

2 mai, 2016 - 23:55

Ryzom est un jeu de rôle en ligne massivement multijoueur (MMPORG) dans un monde de science-fantasy sur une planète végétale.

L'année 2015 a permis la mise en place de structures et d'outils indispensables à l'ajout de nouveautés en jeu. Ce travail de longue haleine, souvent ingrat et invisible des joueurs, a permis de poser les fondations qui permettront d'ajouter en 2016 ce dont nous rêvons et que nous avons promis à la communauté : du nouveau contenu.

Sommaire Général Implication officielle des projets libres Ryzom Core et Ryzom Forge dans l'évolution du jeu Ryzom

Les projets libres Ryzom Core et Ryzom Forge sont étroitement et officiellement impliqués dans le développement du jeu Ryzom. Auparavant, les équipes équivalentes de Ryzom, Ryzom Core et Ryzom Forge travaillaient chacune de leur côté, sans concertation directe ni choix décidés conjointement. Afin d'améliorer leur coordination et leur efficacité, ces équipes équivalentes ont été fusionnées. Voir le compte-rendu du Ryzom Forge meeting du 19 janvier 2015 pour en savoir plus.

Suivi du travail des équipes de Ryzom

Celui-ci se fait grâce à l'ajout d'une page "Suivi des Équipes" sur la page d'accueil du WebIG. Cette page remplace l'ancien "Suivi du Dev", et informe du travail de l'ensemble des équipes de Ryzom.

Développement

2015 a vu la création comme l'amélioration, pour les besoins de Ryzom, de plusieurs outils : l'outil de création de contenu Ryzom Arkitect, l'outil d'exportation graphique de divers formats (Blender et de nombreux autres) vers NeL sans passer par 3DsMax.
Plusieurs documentations ont été créées et mises à la disposition de tous ceux souhaitant créer du contenu dev pour le jeu.
De nombreuses améliorations et corrections de bugs ont été effectuées.

Voici les 14 principales tâches réalisées en 2015 :

1 - Amélioration de la sécurité
  • https://secure.ryzom.com n'accepte plus désormais SSLv3, il a reçu la note A+ sur le test ssllabs.
  • Mise à jour du certificat SSL x.509 sur RSYNC pour que les joueurs sous Linux puissent à nouveau créer des comptes.
2 - Amélioration de l'outil de création de contenu Ark

Cet outil, déjà à la disposition des bénévoles de Ryzom et de Ryzom Forge, est destiné à être ouvert à l'ensemble des joueurs de Ryzom courant 2016. L'ajout graduel d'une nouvelle interface rend peu à peu cet outil dev plus simple à utiliser par les joueurs non développeurs.

Parallèlement, la sécurité d'Ark a été accrue afin de répondre à l'utilisation de l'outil par tous.
De nouveaux modules sont ajoutés à Ark au fil des besoins des différentes équipes, enrichissant peu à peu les possibilités techniques de cet outil. Ce travail se poursuivra en 2016.

3 - Amélioration du "Patchlet"

Le Patchlet, ou "mini-patch", est une application permettant d'ajouter ou de modifier du contenu en jeu sans avoir à redémarrer le serveur. Son dysfonctionnement sous Mac a été corrigé en 2015.

4 - Création de l'outil libre (cc-by-SA) "Blender Exporting"

Cet outil, utilisable sur toutes les plateformes, a pour objectif de permettre aux infographistes de se passer de 3DsMax (logiciel propriétaire payant) en exportant directement leurs productions graphiques de Blender et d'autres logiciels vers NeL, le moteur libre de Ryzom. Le développement de Blender Exporting est financé par Winch Gate, la société propriétaire de Ryzom.

La première phase, en test, est l'outil d'export lui-même. Il convertit les modèles Blend au format NeL sans avoir trop besoin d'interactions de la part des artistes. La deuxième phase, en cours, consiste à créer un éditeur de propriétés et les mesh, pour permettre aux artistes de spécifier les effets avancés pour les mesh (comme la réflexion sur les modèles, le vent dans les arbres, etc). La troisième phase est la création de l'éditeur de zone.

En attendant la fin des tests, il est compilable. Il peut aussi être téléchargé via ryzom_tools_static_*.zip sur la page http://ryzom.kervala.net/clients/.

5 - Ajout de l'option de paiement PayPal pour remplacer PaySpan (PayByCash)

Il est maintenant possible d'acheter un ou plusieurs mois de jeu à Ryzom via PayPal et de cumuler plusieurs achats afin d'obtenir une durée de jeu personnalisée (2 fois 3 mois pour obtenir 6 mois par exemple).

Afin de répondre à une demande récurrente de la communauté de joueurs, cette application permet aussi à ceux le désirant de faire un don pour Ryzom via Paypal. À noter que, en raison des frais engendrés par Paypal, le prix du mois de jeu via cette option est plus élevé que via PaySpan : 1 mois : €8.95 / mois - 3 mois : €8.50 / mois - 1 an : €7.50 / mois.

6 - Création d'un système interne de gestion des tickets

L'outil externe de gestion des tickets utilisé par le Support de Ryzom étant devenu payant, un outil interne à Ryzom a été créé pour le remplacer. Ryzom est donc maintenant indépendant quant au système de gestion des tickets.

7 - Création d'items virtuels

Créer de nouveaux items réels est difficile et demande beaucoup de travail. Aussi le groupe dev a-t-il créé une version "simplifiée" des items réels : les items virtuels. Ceux-ci apparaissent en jeu dans un nouvel onglet de la fenêtre d'inventaire, nommé "Sac spécial".
Un correctif a été appliqué afin que les utilisateurs de Linux et Mac puissent visualiser ces items spéciaux.

8 - Réalisation de tutoriels dev

Ces tutoriels sont destinés à ceux souhaitant participer activement, côté dev, à l'ajout de contenu en jeu :

9 - Création d'un générateur de noms atysiens

Ce générateur de noms atysiens crée à la demande des noms pour des personnages fyros, matis, trykers, zoraïs ou maraudeurs.

10 - Changement de disques durs RAID

Un changement d'urgence de disques durs RAID du serveur de tests "Yubo" a été réalisé, suivi de la réinstallation complète de ce serveur. Par précaution, un changement préventif de disques durs RAID a aussi été effectué sur le serveur de jeu "Atys".

11 - Améliorations Dev pour préparer l'arrivée de Ryzom sur Steam

L'arrivée de Ryzom sur Steam est prévue courant mai 2016.
Pour en savoir plus sur l'arrivée de Ryzom sur Steam.

Afin de préparer au mieux cet évènement, Ryzom Core a effectué en 2015 un énorme travail pour mettre à jour les clients sur toutes les plateformes et corriger certains bugs.

  • Les clients sont prêts pour Linux 32 et 64 bits, Windows 32 et 64 bits et OS X. Ils sont pour le moment disponibles en test. Leur dernière version sera ensuite téléchargeable par Steam ou par le site web de Ryzom.
  • Des outils compilés pour Windows, OSX et Linux sont disponibles en fin de liste sur http://ryzom.kervala.net/clients/ (voir ryzom_tools_*)
  • Correction de nombreux bugs. Cf liste complète et simplifiée. Notamment, le bug faisant planter les utilisateurs de Mac passant un vortex avec le son du jeu activé a été corrigé, ainsi que celui empêchant certains utilisateurs de Linux de voir l'eau (correctif pour les cartes NVidia avec Optimus).
  • Mise à jour quotidienne des traductions des fichiers du client avec les corrections et les traductions manquantes transmises par l'Équipe de Traduction. Le tout est intégré dans les données de Steam.
  • Correction de la météo différente sous Windows, Linux et Mac.
  • Affichage de la page Réalité Virtuelle avec Occulus Rift.

12 - Correctif du pipeline permettant de créer une nouvelle zone

Le pipeline de création de nouvelles zones 3D (régions) a été corrigé. Il est maintenant possible de changer les fichiers existants et d'en créer de nouveaux, ce qui ouvre la porte à la création d'une nouvelle zone.

13 - Réorganisation et amélioration du forum de Ryzom

Les forums de Ryzom ont été réorganisés :

  • Création d'un forum "Bienvenue" afin de mieux accueillir les nouveaux joueurs.
  • Création d'un forum "Vos créations" afin de mettre en valeur les créations vidéos, graphiques, audios et écrites des joueurs.
  • Ajout de sous-forums dans les forums "Support Technique / Web Apps Bugs" et "Ryzom Forge".
  • Ajout d'une fonction de recherche dans les sous-forums.
  • Allongement de la longueur maximale des titres des sujets du forum pour permettre la publication non tronquée de titres en diverses langues.
14 - Correctifs divers déjà implémentés

Notamment :

  • Correction de l'affichage des titres, qui n'était pas mémorisé après reconnexion.
  • Amélioration du camp maraudeur : ajout de personnages non-joueurs (PNJ) d'avant-postes, réparation des donneurs de plan de matériel d'avant-poste, réparation des PNJ pour les appartements et halls de guilde maraudeurs.

Communication et Marketing

Voici les cinq principales tâches de communication réalisées en 2015 :

1 - Augmentation de la visiblité commerciale de Ryzom grâce à l'arrivée programmée de Ryzom sur Steam

Ryzom a été greenlighté (obtention d'un feu vert) par la communauté de Steam, comme relaté dans les publications suivantes :

Cela signifie que l'ajout de Ryzom sur la plateforme de jeux Steam a été approuvée par cette dernière. Aussi, les équipes de Ryzom travaillent activement depuis plusieurs mois à cet ajout qui augmentera fortement la visibilité commerciale de Ryzom.

2 - Réalisation d'une nouvelle bande-annonce pour Ryzom

Cette bande-annonce, réalisée par un joueur, est visible sur YouTube, Vimeo, et sur le site d'EventArtWorks.

3 - Interview de David Cohen Corval, l’un des fondateurs de Ryzom, Directeur créatif à Nevrax

Cette interview a été réalisée fin 2015.

4 - Recensement des créations diverses autour de Ryzom

De nombreuses créations autour de Ryzom ont été réalisées par la communauté des joueurs au fil des ans. Malheureusement, celles-ci étaient pour la plupart difficilement trouvables car non répertoriées. C'est pourquoi le forum a été enrichi d'une section "Vos créations", qui liste les différentes catégories de créations :

5 - Marketing : faire parler de Ryzom sur les sites et forums de jeux

Un projet a été monté pour rendre Ryzom plus visible sur les différents forums et sites de jeux (plus d'info sur les forums).

Lore

La Lore est l'histoire du jeu. Elle est disponible sur le wiki Lore ou en version PDF. Un gros travail est effectué sur la Lore pour gommer les incohérences accumulées au fil du temps et l'ouvrir peu à peu aux joueurs. Voici les 4 principales tâches de Lore réalisées en 2015 :

1 - Travail sur la Lore maraudeure

La dernière faction implémentée en jeu, les Maraudeurs, voit sa Lore retravaillée et étoffée doucement. Un gros travail de fond a été fait en ce sens en 2015, même s'il n'a pas encore abouti à une publication publique, hormis la biographie de Melkiar. Celle-ci donne un avant-goût de ce qui sera dévoilé en 2016.

2 - Travail sur la Lore ranger

Un autre gros chantier est celui de la faction en cours d'implémentation, les Rangers, dont la Lore n'est pas encore publiée mais dont le contenu est peu à peu porté à la connaissance des joueurs de Rangers. Une publication sera bien sûre faite ultérieurement.

3 - Travail sur les thèmes principaux de la Lore : feu, goo, kitins…

Des documents sur les thèmes principaux de Ryzom : feu, goo, kitins… sont en cours de rédaction, à trois niveaux différents :

  • Niveau 1 : version publique ;
  • Niveau 2 : version interne à l'usage de l'équipe d'animation, qui comporte les éléments de Lore à porter à la connaissance des joueurs au fil des events ;
  • Niveau 3 : version ultra-privée à l'usage exclusif de l'équipe Lore.

4 - Travail sur le wiki Lore

Le Wiki Lore, enrichi conjointement par les équipes officielles de Ryzom et par les joueurs, remplace progressivement l'ancien Wiki de Ryzom, que les joueurs ne pouvaient pas éditer.

Un gros travail d'amélioration du wiki et d'intégration des pages de l'ancien wiki a été accompli, principalement sur le wiki francophone, ayant bénéficié de la participation de davantage de bénévoles :

Traduction et correction

L'équipe de traduction et de correction a accompli un gros travail dans l'ombre tout au long de l'année :

  • Traduction régulière des annonces officielles ;
  • Traduction régulière des annonces et textes d'events ;
  • Traduction des chroniques ;
  • Traduction régulière de tout le texte des rites, missions et events automatisés ajoutés dans ARK.

Elle s'est attelée fin 2015 à l'énorme tâche visant à corriger l'intégralité du texte en jeu (plus de 2 000 pages pour chaque langue), afin d'offrir aux joueurs une meilleure qualité de texte en jeu dans toutes les langues. Ce long travail se poursuivra début 2016.

Level Design et Ark

Voici les quatre principales tâches de Level Design et Ark réalisées en 2015 :

1 - Travail sur la Nouvelle Encyclopédie

Les vieux rites de l'Encyclopédie disponibles en jeu seront peu à peu remplacés par des rites novateurs et, à terme, plus nombreux que les rites actuels. Il était prévu que cette Nouvelle Encyclopédie commencerait à être implémentée en 2015. Hélas, d'autres impératifs de développement plus urgents, tels que l'ajout de l'option de paiement Paypal et la création d'un système interne de gestion de tickets, ainsi que l'indisponibilité du serveur de tests Yubo pendant plusieurs semaines, ont retardé le développement d'Ark, l'outil grâce auquel les rites seront ajoutés.

Cependant, le Level Design a préparé les scénarios de plusieurs rites, en attente de leur ajout en jeu par le Dev :

  • Le rite matis 50 (géographie) (en cours d'ajout) ;
  • Le rite zoraï 50 (géographie) (en attente d'ajout) ;
  • Le rite fyros 50 (géographie) (en attente d'ajout) ;
  • Le rite tryker 50 (scénario en cours).

2 - Travail sur l'ajout de nouvelles missions et de nouveaux métiers

Le Level Design de Ryzom Forge travaille à l'ajout de nouvelles missions :

  • Mission fyros : entretenir les feux des portes de Pyr ;
  • Mission tryker : attirer des herbivores dans un enclos ;
  • Mission zoraï : délivrer un produit zoraï aux tribus zoraïs d'Atys.

D'autres idées de missions sont en cours d'étude. Afin d'aider les bénévoles créant des missions, un workflow des missions a été publié. De même, la liste des objets popables a été rendue publique.

Un nouveau métier est aussi en préparation : celui de pêcheur.

3 - Travail sur le futur Rite Ranger

Le futur rite permettant à un Homin de devenir Ranger a été scénarisé en 2015, après un long et difficile travail préparatoire sur la Lore Ranger. Son implémentation est prévue pour 2016.

4 - Mise en jeu d'événements automatisés pour Halloween

Des événements entièrement scriptés ont été mis en jeu pendant les événements d'Anlor Winn (période d'Halloween) :

  • Les villes fantômes ;
  • Les Yubos zombies ;
  • Le labyrinthe dangereux.

Infographie

Plusieurs objets popables, équipables et d'appartement ont été réalisés en 2015, ou sont encore en cours de finalisation :

Des capsules (Image de fond avec le logo de Ryzom visible, en différentes tailles allant de la grande à la vignette) ont été réalisées pour Steam.

Support

L'équipe de support a été quotidiennement au service de la communauté pour répondre aux tickets, aux courriels et aux questions posées en jeu, mais aussi pour veiller au bon respect du Code de Conduite de Ryzom, tant en jeu que sur le forum. Elle s'est étoffée de six nouveaux membres en 2015. Les bénévoles de Ryzom Forge secondent le Support pour tous les problèmes de Ryzom liés à Linux et Mac.

Événements

L'Équipe d'animation a travaillé en parallèle sur plusieurs projets :

  • Scénarisation et mise en jeu de la fin de la séquence fyros sur Atreus ;
  • Scénarisation et mise en jeu de la séquence d'événements matis "L'Art de la Botanique", débutée en 2015, et qui se poursuivra tout au long de 2016 ;
  • Préparation du début de la prochaine séquence zoraï ;
  • Préparation du début de la prochaine séquence tryker ;
  • Préparation du début de la prochaine séquence fyros ;
  • Préparation et mise en jeu d'événements HRP joués lors de la Fête des Réfugiés (Pâques), d'Anlor Winn (Halloween) et Atysoël (Noël).

Musique et Son

Un groupe Musique a été créé en 2015. Son objectif est d'ajouter de la musique et des sons d'ambiance dans le jeu. Le tout sera sous license libre CC-BY-SA. Se référer aux Compte-rendus des réunions de Ryzom Forge pour en savoir plus.

L'année 2015 a été témoin d'une forte activité dans les coulisses de Ryzom. Tout ce travail accompli dans l'ombre devrait se concrétiser en débouchant en 2016 sur l'implémentation de nouveautés en jeu.

Télécharger ce contenu au format Epub

Lire les commentaires

OCaml 4.03

2 mai, 2016 - 16:23

La version 4.03.0 du langage OCaml est paru le 25 avril 2016. OCaml est un langage fonctionnel de la famille des langages ML (dont font partie SML et F#, ou Rust avec une définition élargie).

OCaml est entre autre utilisé pour implémenter le langage Coccinelle (régulièrement utilisé dans la communauté des développeurs du noyau Linux) ou MirageOS (ensemble de bibliothèques pour construire des unikernels). On compte aussi l'implémentation du langage Hack chez Facebook, l'interpréteur de référence pour le projet WebAssembly, ou encore l'analyseur statique de Code C Frama-C.

Il s'agit d'un langage fonctionnel multi-paradigmes fortement typé qui permet de mélanger librement les paradigmes fonctionnel, impératif et objet. Cette version 4.03 fait suite à la version 4.02 publiée en juillet 2015.

Sommaire En bref

OCaml fête ses vingt ans, c'est l'occasion de revenir sur l'évolution de la communauté de ce langage performant, et sur ses possibles évolutions futures.

Cette nouvelle version d'OCaml s'est concentrée sur les performances du code généré, à travers l'introduction d'une nouvelle phase d'optimisation Flambda ainsi qu'une amélioration de la latence du ramasse-miette lui-même. La gestion de la mémoire dans OCaml est automatique. À ce titre, le rôle du ramasse-miette est très important : que ce soit en termes de latence, vitesse ou de consommation mémoire.

La bibliothèque standard s'enrichit de nouvelles possibilités avec les éphémérons, et accueille des types de compatibilité standard pour faciliter la coopération entre les bibliothèques externes.

Les types algébriques, fonctionnalité importante dans un langage qui se base sur des types rigides pour l'élégance et la sécurité du code, ont été améliorés avec un mélange plus simple entre les types sommes (un choix entre sous-types) et les types enregistrés (plusieurs sous-types étiquetés par des noms, équivalent aux structures en C). Dans un registre plus avancé, la gestion des types algébriques généralisés (GADT) a été améliorée avec de nouvelles possibilités pour détecter des erreurs de logique à la compilation, une fonctionnalité centrale des langages ML, et des messages d'erreurs plus clairs.

Si cette version est riche en changements, le futur du langage est aussi riche en possibilités : de nombreuses nouvelles fonctionnalités peuvent être testées dans des branches expérimentales du compilateur : multicœur, implicites modulaires, opérateurs d'indexation.

De nombreuses autres améliorations mineures ont été apportées au langage et outils associés ; par exemple, une syntaxe non dépendante, plus lisible, pour les foncteurs.

Communauté Ocaml devient LGPL + linking exception

Un des aspects moins techniques de cette nouvelle version 4.03 est le changement de licence du compilateur. Précédemment, le compilateur OCaml et les bibliothèques et outils associés étaient distribués sous la licence Q Public License. À partir de cette version, ils sont publiés sous licence LGPL + linking exception. Cette exception à la liaison s'expliquant par le fait qu'OCaml lie les bibliothèques statiquement par défaut. Publier une bibliothèque OCaml sous licence LGPL est donc de facto équivalent à la publier sous licence GPL.

Github devient le dépôt officiel du compilateur

Un autre changement important, le dépôt github OCaml devient le dépôt officiel du code source d'OCaml.

Ce dépôt avait été introduit en janvier 2014 comme un miroir du dépôt svn officiel. Le but était alors d'expérimenter si passer à un dépôt git hébergé sur Github aiderait à attirer des contributeurs extérieurs. L'expérience fut concluante et le miroir est devenu l'original. L'ancien traqueur de bugs (Mantis) ne recevait qu'une douzaine de patchs par an, là où le dépôt Github a reçu 130 requêtes de tirage en 2014, 254 en 2015 et il y en a déjà 156 en 2016.

Le manuel de référence d'OCaml a été aussi intégré au sein du dépôt officiel. Si le manuel est relativement complet, il est parfois assez austère et certaines informations avancées sont manquantes ou difficilement accessibles. De ce fait, les utilisateurs doivent souvent se rabattre sur des tutoriels et articles de blogs. Cette version d'OCaml a vu un effort important pour améliorer cette lisibilité du manuel, mais il s'agit d'un travail de longue haleine et contributions ou remarques sont les bienvenues.

Ocamlbuild séparé du compilateur

Simultanément, il a été décidé de séparer Ocamlbuild, un outil d'aide à la compilation de bibliothèques et d’exécutable, du compilateur. Ocamlbuild vit désormais dans son propre dépôt. L'idée derrière cette séparation est de découpler les sorties du compilateur de celles d'Ocamlbuild afin de permettre à celui-ci d'évoluer à un rythme plus soutenu que celui du compilateur, et que ses améliorations deviennent utilisables avec des versions plus anciennes du compilateur.

Cette séparation a fait l'objet d'un long débat, certains mainteneurs d'Ocamlbuild pensant que ce changement ne modifierait pas le cycle de vie un peu trop calme d'Ocamlbuild (deux contributeurs actifs). D'aucuns ont soutenu au contraire qu'une fois libéré des contraintes de temps impliquées par la synchronisation avec le compilateur, il deviendrait bien plus facile d'attirer de nouveaux contributeurs. En particulier, s'il est nécessaire d'attendre 6 mois pour voir une correction intégrée au système de compilation, il est bien plus simple de modifier son propre projet plutôt que corriger le bug en amont.

OCaml a fêté ses 20 ans

Le 12 septembre 2015, le langage OCaml a fêté ses 20ans. \o/
Xavier Leroy, le BDFL du langage, a posté ce jour-là un message sur la liste de diffusion dans lequel il fait un rapide tour d'horizon des vingt années écoulées. Le langage s'appelait au départ Caml Special Light, avant de devenir Objective Caml puis finalement OCaml. Le design d'origine est toujours présent, mais il a acquis des fonctionnalités qui étaient encore des problèmes de recherche ouverts en 1995 comme : les objets et les classes avec inférence de types, les variants polymorphes, le polymorphisme de première classe ou encore les modules de première classe. Une histoire plus complète du langage se trouve sur le site ocaml.org. Ce dernier s'est également doté de règles de gouvernance en septembre dernier.

Amélioration du compilateur

La nouveauté majeure de cette nouvelle version est interne au compilateur, qui voit l'introduction d'un ensemble de nouvelles passes d'optimisations. Ces nouvelles passes d'optimisations reposent sur une nouvelle représentation intermédiaire : Flambda. En fonction des circonstances, le taux d'allocation (la mémoire allouée dynamiquement pendant l'exécution et gérée par le ramasse-miettes) du code généré par le compilateur natif peut diminuer de 20 à 30% sur du code réel.

Il faut toutefois noter que ces améliorations massives proviennent au moins en partie du fait que le compilateur natif d'OCaml n'effectuait que peu d'optimisations de haut niveau jusqu'à présent ; il se reposait plus sur sa représentation mémoire efficace pour obtenir des performances correctes.

Avec cette amélioration du compilateur, les commandes les plus communes pour compiler sont les suivantes :

ocamlopt -Oclassic file.ml ocamlopt file.ml ocamlopt -O2 file.ml ocamlopt -O3 file.ml

La première commande mime le comportement antérieur du compilateur (avec quelques optimisations de plus), la seconde fait une passe d'optimisation en exploitant les nouvelles possibilités offertes par Flambda, enfin les deux dernières font respectivement deux et trois passes d'optimisations. Chacune, sauf le mode classique, peut être complétée de l'option unbox-closures, dont le principe de fonctionnement est décrit plus loin. Voir la page de manuel pour plus de détails sur les options disponibles.

Pour l'instant cela augmente le temps de compilation de façon importante (même avec l'option -Oclassic) ce qui explique que Flambda n'est pas encore activé par défaut. À terme, l'objectif est d'amener la hausse du temps de compilation autour de 10 % pour -Oclassic, et entre 10 % et 20 % avec une passe : Flambda sera alors mis en place par défaut. Pour bénéficier de ces optimisations il faut utiliser une option de configuration du compilateur ou, pour les utilisateurs d'opam, utiliser le switch 4.03.0+flambda : opam switch 4.03.0+flambda.

Lorsque l'on cherche à optimiser du code, que ce soit manuellement en modifiant l'implémentation de l'algorithme, ou bien automatiquement en modifiant le code machine généré par le compilateur, il faut habituellement arbitrer entre des gains, ou pertes, en temps et en espace : le code est plus rapide mais il prend plus de place, il est moins rapide mais plus court (et incidemment, peut être moins sujet aux bugs car la vérification humaine est plus simple). En revanche si l'on peut gagner à la fois en temps et en espace, il n'y a pas à hésiter. Les optimisations apportées par Flambda n'échappent pas à la règle : les binaires générés peuvent être plus gros mais plus rapide (ce qui se traduit par une moins grande consommation de mémoire à l'exécution), ce qui se paye au prix d'un temps de compilation accru (plus ou moins en fonction des options d'optimisations choisies), mais au bénéfice d'une plus grande sûreté (le processus d'optimisation est automatisé dans le compilateur et donc moins sujet aux erreurs humaines) : le développeur à l'origine de Flambda expose sa vision dans son article de blog « Les optimisations que vous ne devriez pas faire : faire le travail du compilateur ».

Un des apports fondamentaux de Flambda au compilateur ocamplopt est une amélioration du processus d'extension en place (extension inline, ou inlining) qui consiste à remplacer un appel à une fonction par le code de la fonction elle-même. Une fois ce processus effectué d'autres optimisations deviennent possibles, nous présenterons donc son principe en premier.

Extension en place (inlining).

Comme exposé ci-dessus, l'inlining consiste à remplacer un terme f x par le code de la fonction f dans lequel on remplace toutes les occurrences de son paramètre par le terme x. Cela peut permettre, ensuite, certaines simplifications du code comme dans l'exemple ci-dessous :

let f x = x + 1 let g y = f (f y) (* pour remplacer le code de f dans celui de g, on le fait successivement en introduisant des variables fraîches, ce qui donne *) let g y = let r1 = y + 1 in (* première application de f *) let r2 = r1 + 1 in (* deuxième application de f *) r2 (* ce qui après remplacement des nouvelles variables par leur expression et simplification donne *) let g y = y + 2

Une compilation « naïve » de la fonction g qui consisterait à faire un double appel au code de f aurait eu pour exécution la version développée qui alloue deux variables temporaires et effectue deux appels de fonctions, c'est coûteux comparé à la version définitive optimisée. Bon, je rassure tout le monde : le compilateur ocamlopt savait déjà faire ce type de simplification. Mais il existait des cas plus évolués où sa stratégie d'inlining et de simplification ne permettait pas certaines optimisations comme dans le cas des fonctions récursives (fonctions pourtant utilisées à tour de bras dans un langage fonctionnel comme OCaml), ainsi que l'illustre l'exemple suivant :

(* on prend la fonction List.map qui consiste à appliquer une fonction à tous les éléments d'une liste et renvoie la liste résultante on peut la coder ainsi *) let rec list_map f l = match l with | [] -> [] | hd :: tl -> (f hd) :: list_map f tl (* on peut ensuite coder une fonction succ_map qui renvoie la liste de tous les successeurs des éléments d'une liste *) let succ_map l = let succ = (fun x -> x + 1) in list_map succ l (* on insère le code de list_map dans celui de succ_map avant son appel *) let succ_map l = let succ = (fun x -> x + 1) in let rec list_map' f l = match l with | [] -> [] | hd :: tl -> (f hd ) :: list_map' f tl in list_map' succ l (* une fois recopié on l'applique à notre cas *) (* maintenant le paramètre f de la fonction dupliquée est constamment égal à succ et on peut pratiquer la substitution dans le corps de list_map' *) let succ_map l = let succ = (fun x -> x + 1) in let rec list_map' f l = match l with | [] -> [] | hd :: tl -> (succ hd ) :: list_map' succ tl in list_map' succ l (* là on voit que le paramètre f n'est plus utilisé donc on peut supprimer toute référence à celui-ci *) let succ_map l = let succ = (fun x -> x + 1) in let rec list_map' l = match l with | [] -> [] | hd :: tl -> (succ hd ) :: list_map' tl in list_map' l (* enfin en remplaçant la fonction succ par son expression dans la boucle, on peut supprimer toute référence à celle-ci *) let succ_map l = let rec list_map' l = match l with | [] -> [] | hd :: tl -> (hd + 1) :: list_map' tl in list_map' l

Le processus décrit ci-dessus consiste en une spécialisation de la fonction List.map appliquée à la fonction succ. Au départ à chaque tour de boucle on a un appel à la fonction succ (ce qui est coûteux tant en temps qu'en espace), là où cet appel a disparu dans la version définitive spécialisée et optimisée. Néanmoins, le développeur peut se contenter d'écrire let succ_map = List.map succ et le compilateur se charge du reste : les optimisations que vous ne devriez pas faire : faire le travail du compilateur. Une autre stratégie utile d'optimisation proposée par Flambda consiste dans le unbox closure, c'est-à-dire examiner la représentation en mémoire des fonctions, afin d'éviter des appels inutiles à des fonctions et économiser l'allocation de mémoire.

Deconstruction des fermetures (unbox closure)

Dans un langage fonctionnel, il peut arriver des choses assez étranges : que les variables utilisées par une fonction ne soient plus accessibles dans l'environnement syntaxique quand elles sont exécutées. Par exemple :

let augmente n = let n2 = n + n in let plus_n2 x = x + n2 in plus_n2 let plus_n2' = augmente 3 let dix = plus_n2' 4

Dans cet exemple n2 n'est plus disponible au moment où on appelle plus_n2, il faut donc le stocker quelque part. Pour faire ça, le compilateur transforme ce code en ajoutant l'allocation d'un bloc mémoire qui permettra de stocker n2. Ce bloc est appelé une fermeture (ou clôture). Comme c'est quelque chose de très courant, OCaml a une représentation très efficace des fermetures, mais cela a quand même un coût. Parfois certaines fermetures sont introduites dans des environnements où les valeurs qui y sont stockées sont disponibles par d'autres moyens. Dans ces cas-là, l'optimisation unbox-closures permet de se passer de l'allocation de ces fermetures en passant les valeurs qui y seraient contenues en argument. Pour les connaisseurs, cela est assez similaire à une eta-expansion. Cette transformation n'est activée que quand l'option -unbox-closures est passée au compilateur.

Pour ceux que ça peut intéresser, schématiquement, la stratégie du unbox-closures a pour fonction de ramener les variables globales à des variables locales aux fonctions. Sur plus_n2 en un coup, ça fait grosso-modo

let augmente n = let plus_n2 x = let n2 = n + n in x + n2 in plus_n2 (* qui peut se simplifier en *) let augmente n = let plus_n2 x = x + n + n (* plus_n2 = fun x -> x + n + n *) in plus_n2 (* et si on passe à la fermeture ça donne *) let augmente = (fun n -> (fun x -> x + n + n)) (* mais la fermeture est vue du point de vue de plus_n2 à la manière d'un chroot, donc la fermeture contient le code fun n -> (fun x -> ... ) plus la façon d'accéder à n qui est hors de la portée syntaxique de plus_n2 *)

Et quand on appelle augmente 3, le compilateur comprend que l'on se retrouve dans une situation analogue à

let n = 3 let plus_n2' x = x + n + n (* qu'il simplifie par unbox-closures en *) let plus_n2' = (fun n -> (fun x -> x + n + n)) 3 (* puis par substitution en *) let plus_n2' = (fun x -> x + 3 + 3) (* et enfin par calcul *) let plus_n2' = (fun x -> x + 6) (* et la suite il le voit comme *) let dix = (fun x -> x + 6) 4 (* soit *) let dix = 10

Au fond, le compilateur exécute déjà une partie du code et stocke statiquement le résultat (c'est pour cela que la compilation est plus longue), au lieu de le recalculer à chaque exécution du programme.

Un peu plus de détails : en plus d'ajouter des arguments — ce qui demande pas mal de manipulations de fermetures pour être capable d'exposer la fonction optimisée, mais aussi la version originale avec l'ABI classique pour les appels indirects et les cas récursifs — il y a une analyse d'alias pour les cas qui ressemblent à

let f n l = let n2 = n + n in let stuff x = n2 + x in List.map stuff l

Après spécialisation:

let f n l = let n2 = n + n in let stuff x = n2 + x in let rec list_map_spécialisé f l = (* sachant que f = stuff, c'est une annotation portée par la fermeture *) match l with | [] -> [] | h :: t -> let resultat_de_stuff = let n2 = f.acces_dans_la_fermeture_de_stuff in h + n2 in resultat_de_stuff :: list_map_spécialisé f t in list_map_spécialisé stuff l

Du coup stuff ne peut pas être nettoyé parce qu'il est utilisé par le list_map et sa fermeture est utilisée. D'où l'utilité d' unbox-closures qui va retrouver cet accès, puis voir que stuff est dans l'environnement au point de déclaration de list_map_spécialisé et donc réécrire en

let f n l = let n2 = n + n in let stuff x = n2 + x in let n2' = f.acces_dans_la_fermeture_de_stuff in let rec list_map_spécialisé f l n2' = (* sachant que f = stuff, c'est une annotation portée par la fermeture *) match l with | [] -> [] | h :: t -> let resultat_de_stuff = h + n2' in resultat_de_stuff :: list_map_spécialisé f t n2' in list_map_spécialisé stuff l n2'

Puis l'analyse d'arguments morts va voir que f ne sert à rien et réécrire en

let f n l = let n2 = n + n in let stuff x = n2 + x in let n2' = f.acces_dans_la_fermeture_de_stuff in let rec list_map_spécialisé l n2' = match l with | [] -> [] | h :: t -> let resultat_de_stuff = h + n2' in resultat_de_stuff :: list_map_spécialisé t n2' in list_map_spécialisé stuff l n2'

Puis la propagation d'alias va voir que n2' est aussi n2 et nettoyer.

let f n l = let n2 = n + n in let rec list_map_spécialisé l n2' = match l with | [] -> [] | h :: t -> let resultat_de_stuff = h + n2' in resultat_de_stuff :: list_map_spécialisé t n2' in list_map_spécialisé stuff l n2 Attributs prédéfinis

Depuis OCaml 4.01, il est possible d'utiliser des attributs prédéfinis avec la syntaxe [@.. attribut] pour préciser le comportement du compilateur, par exemple pour activer des avertissements spécifiques sur une section critique du code. Le cru 4.03 apporte son lot de nouveaux attributs prédéfinis.

Avec l'accent sur l'optimisation dans cette version, il n'est guère surprenant de voir apparaître de nouveaux attributs qui permettent de contrôler les optimisations effectuées par le compilateur ou de vérifier qu'une optimisation a été bien appliquée.

Contrôle d'optimisations

Les attributs inline, unroll et specialise permettent d'indiquer qu'une fonction ou un foncteur devrait toujours (ou jamais) être incorporé en ligne (ou déroulée ou spécialisée pour les fonctions récursives).

module Float = struct let (+) = (+.) [@@inline] end let rec list_map fonction liste = match liste with | [] -> [] | tete :: queue -> fonction tete :: list_map fonction queue [@@specialise] [@@unroll 1]

Un autre attribut [@immediate] permet d'indiquer au compilateur qu'un type abstrait (dont l'implémentation a été cachée au compilateur) a une représentation immédiate qui ne contient pas de pointeurs. Les exemples principaux de types immédiats sont les types int, char, bool mais aussi les types sommes dont tous les constructeurs sont constants.

module M: sig type t [@@immediate] end = struct type t = A | B end

Cet attribut permet donc de marquer le type t comme un type immédiat, améliorant potentiellement les performances du code généré par le compilateur, sans exposer totalement sa représentation interne.

Vérification d'optimisations

En plus de pouvoir contrôler les optimisations effectuées par le compilateur, de nouveaux attributs permettent de vérifier que des optimisations sont bien appliquées. L'attribut [@inlined] demande au compilateur d'incorporer le code de la fonction ou du foncteur:

(f[@inlined]) ();; Si cela n'est pas possible, le compilateur émet un avertissement. Cela peut se produire si par exemple la provenance de la fonction ne peut être déterminée statiquement à la compilation.

Les attributs unroll et specialise ont aussi leur versions pour le point d'appel: unrolled et specialised:

let rec list_map fonction liste = match liste with | [] -> [] | tete :: queue -> fonction tete :: (list_map [@unrolled 3]) fonction queue let successeur_de_liste l = (list_map [@@specialised]) ((+) 1) l De manière similaire, l'attribut `[@tailcall]` demande au compilateur d'émettre un avertissement si l'appel de fonction annoté n'est pas un appel [récursif terminal](https://fr.wikipedia.org/wiki/R%C3%A9cursion_terminale) et ne peut être optimisé. let rec no_op l = match l with | [] -> () | _ :: q -> (no_op[@tailcall]) q;; (* ici l'appel est bien récursif terminal, et nous pouvons ne rien faire de façon optimisée *) Optimisation de l'appel de code C

L'interface entre OCaml et le C a été améliorée avec de nouveaux attributs qui permettent de spécifier si une fonction C n'effectue pas d'allocation de valeur OCaml [@@noalloc], ou bien si un de ses arguments utilise un entier non marqué ([@untagged]) ou un flottant non encapsulé ([@unboxed]).

Prise en charge de l'architecture System Z

IBM a contribué la prise en charge de l'architecture System_z, aussi appelée S390x, au compilateur natif. Malheureusement assez peu de monde aura accès à ce genre de machine pour pouvoir tester. Cette contribution est un assez fort signal de l'usage d'OCaml dans le secteur bancaire.

Amélioration du glaneur de cellules

Le glaneur de cellules (GC ou ramasse-miettte) d'OCaml est de la catégories des GC précis, générationnel, incrémental, avec une génération copiant et l'autre traçant et compactant. Ce fouillis de mots clefs veut dire:

  • précis: le GC est toujours capable de distinguer un pointeur des autres types de valeurs. C'est important pour pouvoir fournir les autres propriétés
  • générationnel: Le tas est segmenté en plusieurs parties (pour OCaml, 2), appelées générations, qui représentent des valeurs d'âges différents. En OCaml, il y a la jeune génération (appelé tas mineur, dans le contexte de OCaml) qui est un GC copiant, et le tas majeur qui est traçant et compactant.
  • traçant : le GC est fait en plusieurs phases :
    • il parcourt d'abord toutes les valeurs vivantes et marque toutes les valeurs qu'il a pu atteindre (phase Mark)
    • puis parcourt linéairement toute la mémoire pour effacer les valeurs non marquées (phase Sweep)
  • copiant : Toutes les valeurs vivantes sont parcourues et ré-allouées ailleurs (dans le cas d'OCaml dans le tas majeur)
  • compactant : quand le tas (majeur pour OCaml) devient trop fragmenté, une passe déplace toutes les valeurs pour former un bloc compact.
  • incrémental : (par opposition à 'stop-the-world') Le travail du GC est découpé en petites phases qui peuvent être faites au milieu de l'exécution du programme, permettant d'éviter des trop longues pauses du GC.

Ce choix de caractéristiques permet d'être très efficace et d'avoir des programmes réactifs. En effet, les algorithmes traçant et copiant n'ont pas les même avantages:

Le copiant est très rapide. Il ne doit traverser que les données vivantes, mais surtout, il n'y a jamais de fragmentation de la mémoire libre. Une allocation peut donc se faire très simplement : incrémenter un pointeur de la taille de l'objet à allouer, et vérifier s'il y a encore de la mémoire libre. Par exemple sur x86 cela se fait en 3 instructions dont 1 test que le processeur prédit correctement. C'est équivalent au coût d'une allocation sur la pile en C. De plus, comme seules les valeurs vivantes sont traversées, il n'y a aucun coût de nettoyage lié aux valeurs mortes. L'inconvénient majeur du GC copiant est d'utiliser une quantité de mémoire qui est le double de celle réellement allouée par le programme.

Le GC traçant est beaucoup moins efficace, mais par contre n'utilise pas beaucoup plus de mémoire que nécessaire.

Combiner les deux permet (au coût d'une complexité d'implémentation assez accrue) de bénéficier du faible coût d'allocation du GC copiant pour toutes les données temporaires. L'immense majorité des valeurs allouées dans un programme n'est utile que très peu de temps, et n'a donc pas besoin d'être copiée dans la vielle génération, où le coût d'allocation est élevé.

Les changements d'OCaml 4.03 permettent principalement de mieux découper les tranches de travail du GC traçant, pour que le temps de pause à chaque incrément soit à peu près uniforme.
C'est particulièrement utile pour ne pas avoir de grosses latences qui apparaissent pile au mauvais moment. Par exemple dans le cas d'une application qui doit faire du rendu à une fréquence fixe (comme un jeu), ou un serveur (cette modification a été financée par une entreprise de trading à haute fréquence).

Un autre ajout permet aussi d'utiliser, sous Linux, les grandes page mémoire, pour réduire les coûts liés à la gestion de ces pages ( Translation_lookaside_buffer )

Requête de tirage introduisant la modification
Poste de blog de Jane-street en parlant

Bibliothèque standard Éphémérons

Les éphémérons sont une forme de généralisation des pointeurs faibles : un pointeur faible est une référence qui n'empêche pas le ramasse-miette de collecter la valeur référée.

Ce type de donnée était déjà implémenté par OCaml à travers le module Weak de la bibliothèque standard. Il permet par exemple d'implémenter une forme de cache. Un exemple simplifié donnerait :

let cache f = let table_faible = Weak.create 1 in let cached_f x = match Weak.get table_faible 0 with | Some (x', y) when x = x' -> y | _ -> let y = f x in Weak.set table_faible 0 (Some (x, y)); y in cached_f

Cependant pour certaines utilisations, les pointeurs faibles sont trop limités.
Par exemple, on peut essayer de conserver en cache tous les couples entrées-sorties d'une fonction jusqu'au moment où l'entrée est réclamée par le ramasse-miette. Une idée serait de conserver une table faible d'entrées et une table de hachage associant entrée et sortie. Tout se passe bien alors, sauf si la sortie d'une fonction contient une référence à son entrée :

let f x = (x, x)

Dans ce cas-là, la table entrée-sortie va créer une référence visible par le ramasse-miette sur l'entrée et l'entrée ne sera jamais ramassée tant que la table est en mémoire.

Pour pallier ce problème, les éphémérons généralisent la notion de pointeur faible, en associant un ensemble de clefs avec une donnée présente ou non. Cette donnée ne va être conservée par le ramasse-miette que tant que toutes les clefs référencées par l'éphéméron sont en mémoire. De plus, cette donnée associée à l'éphéméron ne compte pas lorsque le ramasse-miette détermine si une des clefs doit être ramassée ou non. Cela nous permet de briser le cycle de références entre clefs et données.

Cela nous permet ainsi d'implémenter cette idée de cache entrée-sortie :

let cache (type e) f = let module H = struct type t = e let hash = Hashtbl.hash let equal = (=) end in let module Weak_table = Ephemeron.K1.Make(H) in let table = Weak_table.create 0 in let cached_f x = try Weak_table.find table x with | Not_found -> let y = f x in Weak_table.add table x y; y in cached_f Types de compatibilité

La bibliothèque standard d'OCaml couvre un nombre limité de fonctionnalités. Pour cette raison, il est souvent recommandé de la compléter par une des bibliothèques standard étendues que ce soit Batteries, Core ou containers. Ce modèle basé sur des bibliothèques tierces pose cependant des problèmes d'interopérabilité : il peut être délicat de faire interagir des fonctions ou bibliothèques basées sur des bibliothèques standards étendues différentes.

Pour diminuer le nombre de ces incompatibilités, la bibliothèque standard intègre désormais deux types de donnée ('a,'b) result et Uchar.t dans le but de servir de points de synchronisation entre les différentes bibliothèques tierces.

Le type 'a result représente le résultat d'un calcul qui peut réussir ou échouer

type ('a,'b) result = Ok of 'a | Error of 'b

tandis que le type Uchar.t représente une valeur unicode scalaire.

Ces deux types sont intégrés plus ou moins tel quel dans la bibliothèque standard. L'implémentation des fonctionnalités associées est laissée aux bibliothèques tierces; qui peuvent désormais s'accorder sur ces types communs.

Pour faciliter la compatibilité avec les versions antérieures d'OCaml, ces nouveaux types sont accompagnés de bibliothèques de compatibilités result et uchar présentes dans les dépôts opam qui exposent une interface uniforme quelle que soit la version d'OCaml.

Améliorations des types algébriques

Cette nouvelle version ne se contente pas d'améliorer les performances du code généré, elle apporte aussi son lot d'améliorations en terme de gestion des types algébriques.

Type enregistrement incorporé (Inline record) En particulier, il est désormais possible de déclarer des types enregistrements au sein de types somme. type 'a arbre = | Feuille of 'a | Noeud of { gauche:'a arbre; droite:'a arbre}

Auparavant, il était possible d'écrire :

type 'a noeud = {gauche: 'a arbre; droite:'a arbre} type 'a arbre = | Feuille of 'a | Noeud of 'a noeud

Cette approche fonctionne mais est moins lisible, en plus de s’étaler sur deux blocks au lieu d'un.

Cette nouvelle extension permet non seulement de mélanger plus aisément types somme et types enregistrement, elle peut aussi mener à une représentation mémoire plus efficace.
Par exemple, on peut définir une liste mutable

type 'a cellule = | Nil | Cons of { contenu: 'a; mutable suivant: 'a cellule }

plutôt que passer par une réference

type 'a cellule_bis = | Nil | Cons of { contenu: 'a; suivant: 'a cellule_bis ref }

ce qui a l'avantage d'éviter une indirection supplémentaire à cause de la référence.
Le module Queue de la bibliothèque standard a été réécrit pour faire usage de ces nouveaux enregistrements incorporés.

Ceci étant, ces types enregistrés incorporés présentent des restrictions et ne sont pas considérés comme des classes primaires. En particulier, ils ne peuvent pas exister en dehors du contexte de leur constructeur. Par conséquent, le filtrage de motif suivant

let estunefeuille = function Feuille _ -> None | Noeud x -> Some x

échoue en renvoyant This form is not allowed as the type of the inlined record could escape.

Types algébriques généralisés (GADT)

Les types algébriques généralisés (ou GADT) sont une généralisation des types sommes qui permet d'exprimer des relations relativement complexes entre les constructeurs d'un type, le type des arguments de ce constructeur et le type résultant. Bien utilisés, ces types algébriques généralisés permettent d'encoder dans le système de type lui-même des propriétés importantes des types de données ainsi définis.

Par exemple, en utilisant un type somme classique, on pourrait réimplémenter le type 'a list avec

type 'element liste = | Nil | Cons of 'element * 'element liste

Si on essaye d'écrire une fonction premier_element pour ce type, on se heurte au cas de la liste vide

let premier_element l = match l with | Cons (elt, _ ) -> elt | Nil -> (* que faire ici? *) raise Not_found (* émettre une exception peut être une solution *)

Avec les types algébriques généralisés, on peut coder directement la longueur de la liste dans le système de type, voire même définir une liste hétérogène.

type rien (* un type vide *) type 'elements liste_gadt = | Nil : rien liste_gadt (* la liste vide ne contient rien *) | Cons : 'element * 'elements liste_gadt -> ('element * 'elements) liste_gadt (* Cons prend un nouvel élément et ajoute son type à la liste de types de la liste *)

Avec ce nouveau type particulier, on peut maintenant écrire la fonction premier_element sans exception :

let premier_element ( l : ('element * 'elements) liste_gadt) = match l with | Cons( elt, _ ) -> elt

Cette fois-ci, l'appel de fonction premier_element Nil renvoie une erreur de type: Nil a pour type rien liste_gadt et le type rien est différent de 'element * 'elements et ce quel que soit 'elements.

Il est cependant important de noter que maintenir explicitement la liste de types de la liste dans le système de types introduit beaucoup de rigidité, et ce type 'elements liste_gadt n'est pas forcément pratique à utiliser hors de cas jouets. Cependant, il permet de mettre en évidence les interactions complexes entre les types algébriques généralisés et le filtrage de motif.

Motifs réfutables

Une des propriétés importantes du filtrage de motifs dans OCaml est que le compilateur peut vérifier que tout filtrage de motifs est à la fois exhaustif (tous les cas sont couverts), et non-redondant (toutes les branches dans le filtrage de motifs sont atteignables). Par exemple, pour le type somme simple 'elt liste, le filtrage de motif

let premier_element (l:'elt liste) = match l with | Cons (elt, _ ) -> elt

n'est pas exhaustif, tandis que

let premier_element (l:'elt liste) = match l with | Nil -> raise Not_found | Cons( elt, _ ) -> elt | Cons( elt, Cons( snd_elt, _ ) ) -> elt

est redondant parce que la troisième branche couvre un cas déjà traité par la seconde.

En présence de types algébriques généralisés, déterminer qu'un filtrage de motifs est à la fois exhaustif et non-redondant devient extrêmement complexe, voire indécidable (cf le résumé en pdf GADTs and exhaustiveness: looking for the impossible). De ce fait, le compilateur préfère émettre des avertissements lorsqu'il ne peut pas prouver qu'un filtrage de motifs est exhaustif. Cela peut mener à des faux positifs, et le compilateur peut alors suggérer des motifs qui sont en fait inatteignables. Pour pallier cette situation, OCaml 4.03 introduit la possibilité d'écrire des motifs réfutables, afin de demander au compilateur de faire plus d'efforts pour prouver que le motif est inatteignable.

Par exemple, une situation dans laquelle le compilateur émet des faux positifs apparaît si on construit un deuxième type de liste hétérogène qui possède au minimum un élément.

type 'elements liste_gadt_2 = | Premier_element: 'elt -> ('elt * rien) liste_gadt_2 | Cons: 'elt * 'elements liste_gadt_2 -> ('elt * 'elements) liste_gadt_2

On peut ensuite essayer de comparer deux listes de ces deux types différents comme suit :

let rec egal : type elements. elements liste_gadt -> elements liste_gadt_2 -> bool = fun l l' -> match l, l' with | Cons(x, Nil), Premier_element y -> x = y | Cons(x,l), Cons(y, l') -> x = y && egal l l'

Pour cette fonction, le compilateur se plaint que le filtrage de motif n'est pas exhaustif parce que le cas (Nil, _ ) n'est pas couvert. Or ce cas est impossible, puisque la liste des types éléments des deux listes sont les mêmes, donc forcément la première liste a au moins un élément. Depuis 4.03, il est possible de dire au compilateur de revoir sa copie en lui indiquant qu'il devrait pouvoir prouver que ce motif est réfutable

let rec egal : type elements. elements liste_gadt -> elements liste_gadt_2 -> bool = fun l l' -> match l, l' with | Cons(x, Nil), Premier_element y -> x = y | Cons(x,l), Cons'(y, l') -> x = y && egal l l' | Nil, _ -> .

Ici, la dernière clause se termine par un point ., pour indiquer que la clause est réfutable et n'est là que pour aider le compilateur à prouver ce point.

Un point important à noter est qu'une des raisons pour lesquelles l'exemple précédent est relativement complexe est que la détection de motifs réfutables a été fortement améliorée dans le compilateur, et il est relativement difficile de trouver des cas de faux positifs simples dans un usage "courant" des types algébriques généralisés.

Messages d'erreur améliorés pour les GADT

Les types algébriques généralisés sont clairement une des fonctionnalités les plus complexes d'OCaml. Les erreurs de type générées par un mauvais usage de ces types peuvent être particulièrement ésotériques.

Un des problèmes rencontrés pour générer des erreurs compréhensibles provient des types existentiels : un type existentiel est une variable de type qui apparaît dans le type d'un argument d'un constructeur GADT sans apparaître dans le type du GADT lui-même. Un exemple de type existentiel serait le paramètre `'a' dans le type de donnée suivant:

type affichable = Affichable: 'a * ('a -> unit) -> affichable let afficher (Affichable (elt,print)) = print elt

Dans ce type affichable, le constructeur Affichable prend en argument un élément de type a et une fonction d'affichage f pour ce type de donnée et renvoie une valeur de type affichable. Le paramètre de type 'a a donc disparu lors de l'application du constructeur Affichable: c'est donc un type existentiel.

Ce nom de type existentiel provient du fait que si on considère une valeur Affichable(elt,print), on sait qu'il existe un type 'a tel que elt soit de type 'a et print soit de type 'a -> unit. Cependant, l'information précise sur quel est ce type 'a a été complètement perdue. Une des conséquences de cette perte d'information est que ce type existentiel 'a ne peut échapper le contexte du constructeur. La fonction suivante est par exemple invalide :

let escape (Affichable(a,f)) = a

En effet, le système de type d'OCaml n'a pas assez d'information pour assigner un type
à a: il sait qu'il existe un type t tel que a:t et f:t->unit, mais n'a aucune autre information sur t. Dans les versions précédentes d'OCaml cela donnait lieu à l'erreur suivante

Error: This expression has type a#0 but an expression was expected of type a#0 The type constructor a#0 would escape its scope

Cette erreur est particulièrement difficile à comprendre pour le non-initié. Dans ce message d'erreur le compilateur essaye de dire qu'il a initialisé un type existentiel qui était appelé 'a dans la définition du type GADT avec le type a#0. Une erreur est ensuite apparue lorsqu'il a essayé d'unifier le type existentiel a#0 avec le type non-existentiel a#0 ce qui n'est pas autorisé parce que cela permettrait au type existentiel a#0 d'échapper au contexte du constructeur.

Pour éviter ces messages sibyllins, la nomenclature utilisée par le compilateur pour nommer les types existentiels a été substantiellement améliorée dans OCaml 4.03; même si elle est encore loin d'être parfaite.

  • Premièrement, les noms de type existentiel, et uniquement eux, sont préfixés par $

  • Un type nommé $Constr_'a correspond à un type existentiel introduit pour la variable de type nommée 'a dans la définition du constructeur Constr. L'erreur de type pour la fonction escape précédente devient donc

type affichable = Affichable: 'a * ('a -> unit) -> affichable let escape (Affichable(a,f)) = a (* Error: This expression has type $Affichable_'a but an expression was expected of type 'a The type constructor $Affichable_'a would escape its scope *)

Par rapport à la version précédente, le message d'erreur fait clairement la distinction entre le type existentiel $Affichable_'a$ et le type non-existentiel 'a qui étaient tous deux nommés $a#0 précédemment. L'origine du type existentiel $Affichable_'a
est aussi beaucoup plus claire.

  • Le nom $Constr est utilisé si la variable de type correspondante dans la définition du constructeur Constr était anonyme:
type any = Any : _ -> any let escape (Any x) = x;; (* Error: This expression has type $Any but an expression was expected of type 'a The type constructor $Any would escape its scope *)
  • Le nom $'a est utilisé si une variable de type existentiel sans nom précis a été unifiée avec une variable de type normale 'a au moment du typage.

Par exemple:

type ('arg,'result,'aux) fn = | Fun: ('a ->'b) -> ('a,'b,unit) fn | Mem1: ('a ->'b) * 'a * 'b -> ('a, 'b, 'a * 'b) fn let apply: ('arg,'result, _ ) fn -> 'arg -> 'result = fun f x -> match f with | Fun f -> f x | Mem1 (f,y,fy) -> if x = y then fy else f x;; (* Error: This pattern matches values of type ($'arg, $'result, $'arg * $'result) fn but a pattern was expected which matches values of type ($'arg, $'result, unit) fn Type $'arg * $'result is not compatible with type unit *)
  • Enfin si toutes les méthodes précédentes n'ont pas réussi à donner un nom plus spéficique à un type existentiel, le compilateur utilise simplement $n avec n un entier.
Vers le futur Plus de flambda

L'introduction de la nouvelle représentation intermédiaire est une première étape avant la mise en place de nombreuses nouvelle optimisations.

Passage à un cycle de versions plus court

OCaml a toujours eu un cycle de versions assez long où les versions étaient sorties « quand ça se stabilise ». Certains utilisateurs industriels en sont arrivés au point d'utiliser en production la version de développement. C'est un choix qui n'est pas complètement déraisonnable, celle-ci étant très peu souvent cassée, mais cela reflète néanmoins un problème. Suite à de nombreuses discussions au sein de l'équipe de développement, il a donc été décidé de passer à un cycle avec des versions à des dates presque fixes et beaucoup plus court. Le gel de la version 4.04 est prévu pour cet été.

Operateurs d'indexation

Non content de disposer de deux opérateurs d'additions dans la bibliothèque standard, OCaml se démarque également par son nombre de constructions syntaxiques pour accéder à un élément d'un tableau. En fonction de la famille de type auquel appartient le tableau, il faut utiliser:

  • a.(n) pour les tableaux (type 'a array)
  • a.[n] pour les chaînes de caractère (type string)
  • a.{k,l} pour les tableaux multidimensionnels (type ('a,'b,'c) Bigarray.t

De plus, ces 'opérateurs d'indexation' ne sont pas vraiment des objets de première classes dans le language OCaml. Il n'est pas vraiment possible de réutiliser ces opérateurs sans casse.

Pour pallier cet état de fait, une proposition était de transformer ces opérateurs d'indexation en objet de première classe. Cela permettrait par exemple d'avoir une syntaxe à la python pour des dictionnaires

let (.{}) dict x = Hashtbl.find dict x let (.{}<-) dict x y = Hashtbl.add dict x y let dict = Hashtbl.create 10 ;; dict.{"key"}<-0 ;; dict.{"key"} (* renvoie 0 *)

Cette proposition a cependant le désavantage qu'elle ne réduit pas le nombre d'opérateurs d'indexation, elle ne fait qu'accroître leur flexibilité.

Elle s'est retrouvée en conflit, avec une seconde proposition dont le but était de réduire le nombre d'opérateurs d'indexation et de détrôner les tableaux float array de leur rôle particulier au sein du compilateur. L'idée de cette seconde proposition est de définir une famille de types pour les tableaux, pour laquelle il serait possible d'utiliser la syntaxe a.(n) et ce quelque soit le type précis du tableau.

Les deux propositions s'étant retrouvées en conflit à la fin de la période d'intégration pour la version 4.03, il a été décidé de prendre le temps pour réfléchir posément à leur éventuelle intégration dans une future version.

Multicœur

Il y a une demande assez forte depuis longtemps pour un glaneur de cellule (GC) multicœur, mais malgré plusieurs prototypes abandonnés avec le temps ceci n'a jamais été intégré à OCaml. Un nouveau projet, lancé depuis environ 2 ans à Cambridge chez OCamllabs semble arriver à un point de maturité suffisante pour pouvoir être sérieusement testé. Ce développement est long, et est encore assez loin d'être terminé. C'est déjà un travail vraiment impressionnant, sachant que leur objectif (qu'il faut atteindre pour avoir une chance d'être accepté dans la distribution officielle) est d'être quasiment aussi efficace que le GC actuel sur du code séquentiel. C'est ambitieux car celui-ci est particulièrement efficace.

Implicites modulaires

OCaml est un langage très explicite. Cela se remarque en particulier au niveau des types numériques : il n'y a aucune conversion implicite entre entiers et nombres à virgule flottante. De manière similaire, une particularité d'OCaml est que le langage possède des opérateurs numériques séparés pour les entiers (+,-,*,/, etc…) et les nombres à virgule flottante (+.,-.,*.,/., etc…). Cette duplication est due à l'absence dans OCaml de polymorphisme ad-hoc. Deux exemples de polymorphisme ad-hoc seraient la surcharge de fonction à la C++ ou les classes de type à la Haskell.

Les implicites modulaires sont une proposition audacieuse (pdf) pour implémenter des fonctionnalités comparables aux classes de type à la Haskell en se basant sur les modules d'OCaml. Cette idée, directement inspirée des paramètres implicites utilisés en Scala, consiste à pouvoir utiliser des modules comme paramètres implicites de fonction. Par exemple, en Haskell, une fonction moyenne pourrait s'écrire

moyenne:: Num n => n -> n -> n moyenne x y = (x + y) / 2

Dans cette expression, Num n indique que le type n appartient à la classe de type Num et par conséquent implémente l'addition +, la division / et la conversion depuis un entier. En OCaml sans implicites modulaires, il est possible d'émuler ce concept en passant un module M de signature Num qui contient ces fonctions nécessaires comme argument de la fonction moyenne:

let moyenne (type a) (module N:Num with type t = a) x y = N.( x + y / from_int 2 )

Cependant, avec cette définition, il est nécessaire de passer le module N à la main à chaque usage de la fonction moyenne. Les modules implicites permettent de s'affranchir de cette limitation en passant N comme un module implicite

let moyenne {N:Num} x y = x + y / from_int 2

Il devient possible d'appeler moyenne 2 5 sans préciser le module ( sous conditions que +, / et from_int utilisent également le module implicite N ).
Avec cette définition, si les bon modules sont visibles, il est possible d'appliquer moyenne à la fois à des entiers et des nombres à virgule flottante sans avoir à repréciser le type. Il serait ainsi possible de se passer d'opérateurs numériques différenciés pour chaque type numérique.

Cependant, avec des paramètres implicites, une question importante est de savoir comment le compilateur choisit quels paramètres implicites sont utilisés. L'implémentation proposée pour ces implicites modulaires essaye d'être la plus explicite possible à ce niveau. Par exemple, un module ne peut être utilisé comme paramètre implicite que s'il a été déclaré comme disponible en tant que paramètre implicite.

Si cette proposition a été très bien reçue par la communauté OCaml, il reste néanmoins un travail important avant de pouvoir l'intégrer dans le compilateur. Pour tester ces nouvelles possibilités, un fork est disponible sur le dépot github.

Améliorations mineures

Cette nouvelle version s'accompagne aussi d'une ribambelle d'améliorations mineures que ce soit en terme d'usabilité, de sucre syntaxiques, de nouveaux avertissements ou encore un support étendu des extensions par points d'extension. En voici une liste longue mais non exhaustive.

Usabilité Sortie en couleur du compilateur

Le compilateur affiche désormais les messages d'erreur et d'avertissement en couleur, lorsqu'utilisé au sein d'un terminal qui supporte l'affichage en couleur.

Directives help pour l'interpréteur interactif

L'interpréteur interactif d'ocaml, que ce soit l'interpréteur standard ou sa version enrichie, utop, dispose d'un certain nombre de directives qui permettent de contrôler le comportement de l'interpréteur ou d'afficher des informations utiles. Ces directives étaient jusqu'à présent uniquement documentées dans le manuel de référence d'OCaml. Il est désormais possible d'utiliser la directive

#help;;

pour afficher une liste des directives disponibles avec une brève description de leur usage.

Commentaire de documentation gérés par le compilateur

Ceci est un changement de la 4.02.2, maturé dans la 4.03.0.

La syntaxe des commentaires en OCaml est (* pour commencer un commentaire et *) pour le terminer. La convention des commentaires de documentation est, depuis longtemps, de commencer les commentaires avec un * de plus:

val length : 'a list -> int (** Return the length (number of elements) of the given list. *)

C'est la forme des commentaires reconnue par l'outil OCamldoc qui génère les versions html des documentations. Le compilateur est donc maintenant aussi capable de comprendre cette convention, ces commentaires sont gardés dans les arbres de syntaxe, et en particulier sont disponibles dans les fichiers .cmt. Cela permet d'écrire plus simplement de meilleurs outils pour gérer la documentation. Par exemple ocp-index peut retrouver la documentation d'une fonction en même temps que son type. Un nouvel outil est en train de voir le jour pour remplacer OCamldoc, utilisant les informations de liaison et de typage pour gérer, entre autres, les liens entre modules de différents projets et les instanciations de foncteurs. Par exemple, cette documentation de la bibliothèque core de Janestreet.

Régularisation des constructeurs (::) et []

les constructeurs :: est [] étaient des exceptions gérés différemment des autres types algébriques. Par souci de régularisation ils est maintenant possible de les redéfinir. Ce n'est pas forcement une très bonne pratique, mais ça peut avoir des usages pour faire des DSL.

Un exemple hautement inutile: les listes de longueur paire et impaire.

type 'a liste_impaire = | (::) of 'a * 'a liste_paire and 'a liste_paire = | [] | (::) of 'a * 'a liste_impaire let a : int list_impaire = 1 :: [] let b : int list_paire = 2 :: 1 :: []

Notez en particulier que comme la syntaxe [1;2] est un sucre syntaxique pour 1 :: 2 :: [], il est donc possible d'écrire:

let a : int list_impaire = [1] let b : int list_paire = [2;1] Améliorations mineures de la syntaxe

Cette nouvelle version introduit aussi un certain nombre d'améliorations mineures de la syntaxe, offrant des raccourcis utiles dans certaines situations

  • omissions simplifiées de variables de type dans les types paramétrés

Il peut arriver que l'on ne souhaite pas préciser les paramètres d'un type paramétré. Une solution dans cette utilisation était d'utiliser un tiret bas _, par exemple (_,_) result. Cependant, cela demandait d'utiliser autant de tirets que de paramètres de type.
Il est désormais possible d'utiliser _ sans ce soucier du nombre de paramètre: _ result

  • syntaxe non dépendante pour les foncteurs : S1 -> S2
module type F = S -> S' (* plutôt que *) module type F = functor (M:S) -> S'

Cette nouvelle syntaxe pour les foncteurs est plus légères
mais ne couvre pas toutes les possibilités du système de modules, par exemple :

module type F = functor (M:S) -> (S' with type t = M.z)
  • annotations simplifiées de type sur les champs d'un enregistrement

Dans les rares cas où cela est utile, le type d'un champ peut être annoté directement sur l'étiquette associée

type ('gauche,'droite) paire = { gauche:'gauche; droite:'droite} {x:int list=[]; y:float list=[]};; (* plutôt que *) { x = ([]:int list); y = ([]:float list) }
  • annotation simplifiée pour le type retour d'une fonction
let f = fun x y : int list -> [x;y] (* remplace *) let f = fun x y -> ([x;y] : int list)
  • punning pour la copie d'objets
object val x=0 val y = 1 method update x = {< x >} end

à la place de method update x = {< x = x >}

  • raccourci pour types localement abstraits multiples
let f (type a b) (x:a) (y:b) = () (* plutôt que *) let f (type a) (type b) (x:a) (y:b) = ()
  • Notation hexadécimale pour les nombres à virgule flottante. Les nombres à virgules flottantes peuvent désormais être écrits en notation hexadécimale, ce qui peut être utile pour le calcul numérique.
let quinze = 0xF. let demi = 0xp-1
  • Notation octale pour les caractères

Il est désormais possible d'écrire des séquences d'échappements en octal au sein des chaîne de caractères:

let neuf = "\o071";; Avertissement sur les filtrages fragiles

Cet nouvel avertissement un peu particulier peut être contrôlé à travers un attribut prédéfini [@warn_on_literal_pattern]. Il permet de marquer l'argument d'un constructeur d'un type somme comme étant là à but purement informatif. Tout usage du filtrage de motif sur cet argument émet un avertissement pour signaler qu'il n'y a aucune garantie que l'argument soit stable. En particulier, la bibliothèque standard utilise cet avertissement pour indiquer que certains messages renvoyés par des exceptions sont purement informatifs. L’intérêt principal est d'aider à l'écriture de code plus facilement maintenable dans le temps en empêchant les utilisateurs de dépendre du texte précis d'un message, alors que celui-là pourrait potentiellement subir une correction orthographique.

Extensions de syntaxe par point d'extensions

Apparues dans la version 4.02, les extensions de syntaxe par points d'extension ou extensions ppx implémentent un nouveau mécanisme pour l'écriture d'extensions de syntaxe pour OCaml. Ce mécanisme a pour but d'apporter une alternative plus simple, composable et rapide aux préprocesseurs camlp4/5.

La différence fondamentale entre extensions ppx et camlp4/5 est le point application de ces extensions. Les extensions basées sur les préprocesseurs campl4/5 transforment un code source en du code ocaml au niveau textuel:

code source X → extension campl4 X → code source OCaml

Cela permet notamment de réécrire totalement la grammaire et syntaxe d'OCaml.
Cependant, cela pose des problèmes de composabilité. Si deux extensions campl4 A et B implémentent deux langages OCaml + A et OCaml + B, combiner ces deux extensions nécessitent d'écrire une nouvelle extension A+B afin de pouvoir reconnaître le langage OCaml + A + B. De plus, puisqu'une extension campl4 transforme un code source écrit dans le nouveau langage en code source ocaml, le compilateur a besoin de re-analyser la sortie de l'extension camlp4.

Les points d'extension ont pour but d'éviter ces écueils des extensions camlp4 en partant du principe que la majorité des extensions de syntaxe n'ont pas besoin de réécrire complètement la grammaire d' OCaml. L'idée de base des extensions ppx est de laisser le travail d'analyse syntactique au compilateur OCaml et d'implémenter les extensions ppx comme des transformations au niveau de l'arbre syntaxique abstraite d'OCaml.
Puisqu'ils travaillent au niveau de la syntaxe abstraite d'OCaml, les extensions ppx ne peuvent donc plus complètement transformer la syntaxe d'OCaml mais peuvent uniquement réinterpréter la syntaxe existante. Cette restriction garantit que les extensions ppx peuvent travailler ensemble et que l'utilisateur n'a pas besoin de réapprendre une syntaxe complètement différente pour chaque extension. Cependant, pour donner plus de marge de manœuvres aux extensions ppx, l'analyseur syntaxique d'OCaml reconnaît et transforme en arbre syntaxique abstraite valide une grammaire légèrement plus étendue que la grammaire OCaml vanilla. En particulier, les points d'extensions de la forme

let f x = [%extension expression] x [%%extension phrase ]

représente des nœuds de l'arbre syntaxique abstraite étendue qui doivent être transformés en nœuds valides par un transformateur ppx sous peine d'erreur du compilateur.
Ces nœuds d'extensions peuvent ensuite être complémentés par par des attributs [@attributs] qui associent des métadonnées aux nœuds de l'arbre syntaxique abstraites et des chaînes de caractères bruts {delimiteur| ""''"" |delimiteur} qui permettent de s'affranchir de la syntaxe d'OCaml de manière délimitée.

Avec cette structure, il est bien plus facile de composer les extensions ppx : une extension donnée n'a besoin que de modifier ses nœuds d'extensions en laissant intact le reste de l'arbre syntaxique. Les extensions ppx peuvent donc être appliquées en série par le compilateur, avec un nombre limité de conflits potentiels entre extensions. À la fin de cette série de transformations, le compilateur n'a plus qu'à vérifier que l'arbre syntaxique abstraite obtenue correspond bien en un arbre syntaxique abstraite vanilla:

OCaml + ppx → analyseur syntactique OCaml → AST étendu → extensions ppx → AST étendu → vérification de l'AST → compilation standard

Les avantages par rapport au modèle camlp4 sont donc l'utilisation d'une seule grammaire OCaml + ppx en entrée pour le compilateur, la possibilité de chaîner les extensions de syntaxe puisqu'elles travaillent sur la même représentation et la possibilité d'analyser qu'une seule fois le code source. Un des inconvénients des extensions ppx vient du fait qu'elles doivent partager la même syntaxe, ce qui peut mener à certaines lourdeurs syntactiques. Pour faciliter l'utilisation de ces extensions, de nouvelles constructions ont été ajoutées à la grammaire étendue d'OCaml depuis la version 4.02.

Raccourcis d'extension

Dans OCaml 4.02.3, certains mot-clefs disposaient d'une syntaxe raccourcie pour les nœuds d'extensions commençant à ce mot-clef:

let%extension f x = () (* équivaut à *) [%%extension let f x= () ]

Ces raccourcis ont été généralisés à tous les mots-clefs pour lesquels un tel sucre syntaxique fait sens.

Opérateurs d'extension

Depuis la version 4.02.3, certains opérateurs sont réservés pour les extensions ppx. Il s'agit des opérateurs commençant par un croisillon # et contenant au moins deux croisillons #:

let ( ##% ) f x = f x

Il est à noter que la définition d'opérateurs commençant par des croisillons en général n'est possible que depuis 4.02.3. Ces opérateurs présentent l'intérêt de lier plus fortement que l'application de fonction. Cette forte précédence est exploitée par exemple par l'extension de syntaxe de javascript_of_ocaml pour implémenter l'appel de méthode sur les objets javascripst.

Littéraux d'extension

Dans OCaml vanilla, il existe quatre classes différents de litéraux pour les entiers: 1 pour les entiers marqués utilisés par OCaml, 1n pour les entiers natifs non marqués, 1l pour les entiers 32 bits et 1L pour les entiers 64 bits. De la même manière, les littéraux flottants représentent forcément des flottants 64 bits.

OCaml 4.03.0 lève cette limitation dans la grammaire étendue ppx. Il est désormais possible d'appliquer un caractère modal (de f à z ou de F à Z) à n'importe quel littéral numérique. De tels littéraux modifiés pourraient par exemple être utilisés pour implémenter une syntaxe plus naturelle pour les quaternions ou complexes

let quaternion = 1.0i + 2.0j + 3.0r let entier_de_gauss = 1i + 2r

Ces littéraux modifiés ne sont cependant valides que dans la grammaire étendue et doivent être traduits en une forme syntactique vanilla par une extension ppx pour être utiles.

Nœud d'extension prédéfini

Une nouveauté relativement surprenante est l'apparition d'un nœud d'extension prédéfini [%extension_constructor] dans le compilateur. Originellement, les nœuds d'extension ont été introduits pour permettre aux extensions ppx d'étendre de façon contrôlée la syntaxe d'OCaml. Ce nœud d'extension inclus au sein du compilateur lui-même est donc relativement exotique. Il s'applique dans des cas particuliers en lien avec les types sommes ouverts introduits avec OCaml 4.02 et permet de calculer le numéro d'un constructeur ajouté au type somme:

type t = .. type t += X of int | Y of string let x = [%extension_constructor X] let y = [%extension_constructor Y] let b = x<>y;; - : b = true

Pourquoi utiliser un nœud d'extension ici ? Simplement parce que cela permet de ne pas avoir à construire une valeur valide du type t pour pouvoir demander au compilateur le numéro assigné au constructeur. Cette construction a été introduite pour pouvoir gérer les types extensibles dans les extensions ppx gérant la sérialisation/dé-sérialisation. C'est à priori inutile pour un usage 'normal' du langage.

Remerciements

Cette dépêche collaborative n'aurait pas été possible sans le concours de kantien, chicco, Lucas, VictorAche, BAud, Ontologia, Nicolas Boulay et les corrections de Yves Bourguignon, gim, Snark, Nÿco, Nicolas Casanova, Storm, ɹǝıʌıʃO, KlakPlok, anaseto, come, eggman, theblatte, Anthony Jaguenaud, SamWang_le_retour_7, patrick_g, Dinosaure.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de kdenlive 16.04.0

2 mai, 2016 - 15:01

Une version majeure du logiciel de montage vidéo kdenlive est sortie, la 16.04.0. Elle corrige un certain nombre de bogues et autres instabilités. Il faut dire que le passage à KDE Frameworks 5 (KF5) ne s’est pas fait sans mal, en passant de la dernière version 0.9.10 sous Qt4 vers les versions sous KF5, je me suis retrouvé avec plein de bogues et d’effets qui ne marchaient plus en partie en raison d’un environnement KF5 pas forcément encore bien abouti sur ma Mageia 5. Au final, ça semble s’améliorer sensiblement et on retrouve (enfin) le niveau de stabilité de la 0.9.10 avec des fonctions supplémentaires.

Pour illustrer le tout on commence par une petite copie d’écran :

Sans rentrer dans le détail du journal des modifications, les évolutions marquantes sont :

  • dans le champ moniteur :
    • un champ timecode (le curseur de temps) a fait son apparition dans la fenêtre de moniteur de clip et de projet. Ça peut être utile pour se repérer finement, d’autant qu’on peut faire bouger le curseur par unité de 50e de seconde,
    • les marqueurs de début et de fin de zone du moniteur de clip peuvent maintenant être déplacés à la souris,
    • on peut choisir un effet dans le champ correspondant (cf. copie d’écran) et le glisser dans la fenêtre de moniteur (clip ou projet) pour que celui‐ci soit appliqué,
    • dans le champ moniteur on peut voir le niveau audio du clip ou du projet,
    • on peut également afficher le nombre d’images par seconde (fps) par le menu accessible avec le bouton droit de la souris (Current Monitor OverlayMonitor Overlay Timecode) ;
  • dans le champ de la timeline :
    • rajout d’une fonction « match frame », si vous placez le curseur sur la timeline et en choisissant dans le menu accessible avec le bouton droit Clip in project bin, le moniteur renvoie directement sur la même image du clip original ;
  • dans le champ effet :
    • rajout d’un bouton « split compare », c’est assez génial car il permet dans le moniteur d’avoir la moitié de la vue avec l’effet et l’autre moitié sans effet, très pratique !
    • maintenant, on a enfin du son quand on joue avec l’effet de ralentissement/accélération de la vidéo. Auparavant, j’étais obligé de passer par OpenShot Video pour pouvoir le faire en réimportant ensuite ma séquence vidéo,
    • on peut mettre les effets qu’on utilise le plus souvent en favoris facilement accessibles en les sélectionnant puis, à partir du bouton droit de la souris, Add Effect to Favorites ;
  • dans le menu Project :
    • apparition d’une fonction intéressante pour pouvoir intégrer un compteur à sa vidéo (ProjectGeneratorCounter),
    • de la même manière, on peut rajouter une mire TV ou du bruit de fond, utile pour créer un générique.

  • dans les titres, on peut rajouter un gradient de couleur, ainsi qu’une ombre portée ;
  • à noter également qu’on peut maintenant copier un clip (Duplicate Clip), très utile pour les titres.

Bref, plein de bonnes raisons de vous mettre à la vidéo, évidemment sous notre environnement préféré.

Télécharger ce contenu au format Epub

Lire les commentaires