Sortie de Gambas 3.3

Posté par (page perso) . Édité par Davy Defaud, Adrien Prokopowicz, NeoX, baud123, Pierre Jarillon, Benoît Sibaud et Florent Zara. Modéré par j. Licence CC by-sa
Tags :
56
30
sept.
2012
Technologie

Gambas est un langage de programmation orienté objet, basé sur un interpréteur BASIC, et une plate‐forme de développement complète. Il comporte, entre autres, un compilateur, un interpréteur, un tas de modules complémentaires (appelés composants) et un environnement de développement intégré. Le tout est distribué sous licence GNU GPL v2 ou supérieure.

Gambas 3 est sorti le 31 décembre 2011, il y a maintenant neuf mois.

Profitons donc de la sortie de Gambas 3.3 pour faire un point sur les nouvelles fonctionnalités de ce langage de programmation.

Pour plus d’informations sur Gambas, la lecture de la précédente dépêche est vivement conseillée, ainsi que la consultation du site du logiciel.

Gambas Almost Means BASIC !

Sommaire

Compilation à la volée (just‐in‐time)

L’évolution majeure depuis la version 3.2 est le compilateur à la volée (en anglais just in time), qui consiste à traduire le code d’une fonction en assembleur au moment de sa première exécution, et à exécuter le code assemblé à la place du code interprété.

Les meilleurs gains de performances sont obtenus dans les calculs de bas niveau et dans le déroulement du flot de contrôle. Il n’y a bien sûr aucune amélioration pour le code des composants écrits en C ou en C++.

Il y a donc tout intérêt à cibler précisément ce qui doit être compilé dans un projet, car la compilation a un coût en mémoire et en temps (la première fois que la fonction est exécutée). Par exemple, il n’y aurait aucun gain significatif à compiler intégralement l’environnement de développement.

Pour indiquer qu’une classe doit être compilée à la volée, il suffit d’ajouter le mot‐clef FAST en début de classe.
Pour ne compiler qu’une fonction, il suffit d’ajouter le mot‐clef FAST en début de déclaration de fonction.

FAST Private Sub FastDrawFractalRect(hImage As Image, XO As Float, YO As Float, SF As Float, X As Integer, Y As Integer, W As Integer, H As Integer)

  Dim I, J, K, C, CC As Integer
  Dim XF, YF, XF0, YF0, XF1, YF1 As Float

  ...

End

La compilation à la volée est ainsi utilisée par l’environnement de développement pour accélérer l’analyse du profilage (voir le paragraphe suivant).

Elle permet aussi à l’exemple Fractal de tourner quasiment en temps réel sur mon double cœur :

Exemple 'Fractal'

Voici les résultats de trois bancs d’essai écrits en Gambas, en Python et en Perl :

────────── ────────── ────────── ────────────────
Python Perl Gambas Gambas + JIT
─────────── ────────── ────────── ────────── ────────────────
Polynom 133 s 319 s 100 s 9,20 s
Primes 27,6 s 43,0 s 20,4 s 5,95 s
N-Body 22,4 s 33,3 s 20,8 s 3,07 s
─────────── ────────── ────────── ────────── ────────────────

Pour plus de détails sur ces bancs d’essai, veuillez consulter le wiki de Gambas.

Ce compilateur « à la volée » a été écrit par le Suédois Emil Lenngren. Il se base sur LLVM 3.1 ou toute autre version postérieure. Il fonctionne sur les architectures i386 et x86_64, mais pas encore sur ARM à cause de bogues dans LLVM.

À ma connaissance, aucune distribution n’utilise pour l’instant LLVM 3.1, mais cela ne saurait tarder. En attendant, sur Ubuntu 12.04, il vous faudra compiler LLVM 3.1 à la main, sachant que toute utilisation combinée avec OpenGL plantera, car celui‐ci essaiera d’utiliser LLVM 3.0. Visiblement, il n’a pas été prévu de pouvoir utiliser deux versions différentes de LLVM dans le même processus. :-)

Profileur

Un profileur a été ajouté à l’environnement de développement dans la version 3.2.

Lorsque le mode « profilage » est activé, le débogueur intégré de Gambas 3 mémorise le temps d’exécution de chaque ligne de code interprétée. Une fois l’exécution terminée, le résultat du profilage est affiché dans une fenêtre similaire à ce qu’on peut trouver dans kcachegrind.

Fenêtre du profileur

Les temps d’exécution reportés sont basés sur l’horloge réelle, et non sur le temps processeur utilisé par le processus, comme peut l’indiquer un outil comme Valgrind ou la commande time du shell.

Si quelqu’un a une solution pour pouvoir mesurer le temps processus de manière précise…

Gambas 3 tourne sur Raspberry Pi

Gambas sur Raspberry Pi

Après de très longues heures de compilation sous l’émulateur ARM de QEMU et quelques corrections de bogues, Gambas tourne sur Raspberry Pi.

Remerciement à Wally pour la photographie ci‐dessus (NdM : l’auteur de l’article ne possède pas de Raspberry Pi).

…et sur MK802

Gambas sur MK802

Et, ne faisons pas de jaloux, merci à joem pour cette photographie‐là.

Pages HTML dynamiques dans le style de PHP ou ASP

Gambas possède un composant gb.web depuis la version 2. Ce composant permet de transformer un projet Gambas en script CGI. Il offre un ensemble de classes permettant de décoder une requête HTTP, de forger la réponse, et de gérer les sessions.

Depuis Gambas 3.2, la génération de pages HTML dynamiques dans le style des pages PHP ou ASP a été ajoutée.

Il s’agit de pages HTML normales au milieu desquelles on peut insérer du code Gambas, à l’aide de balises spéciales. En voici un exemple, tiré d’une capture d’écran de l’éditeur de l’environnement de développement :

Exemple de WebPage

Voici la signification de quelques balises :

Balise Signification
<%%> Imbriquer un code Gambas quelconque.
<%=%> Insérer le résultat d’une expression dans le flux HTML. L’expression est correctement échappée grâce à l’instruction Html$().
<<Page>> Inclure la WebPage Page à l’intérieur de la WebPage courante.
<%/%> Insérer la variable CGI SCRIPT_NAME.

Ces pages dynamiques sont transformées par le compilateur en une unique méthode Render(). Cette méthode exécute le code imbriqué tel quel, et envoie la partie HTML directement vers la sortie standard.

Ce composant va continuer à évoluer afin d’offrir de plus en plus de facilités pour le développement d’applications Web en Gambas.

Un serveur HTTP embarqué est prévu pour la prochaine version, afin de faciliter le débogage de ce genre d’applications, et, pourquoi pas, permettre de réaliser un site complet autonome avec un serveur Web en un seul fichier exécutable. :-)

Réécriture du composant XML

Dans la version 3.2 de Gambas, le composant XML a fait peau neuve. Le changement le plus flagrant est sans doute la nouvelle interface DOM. L’ancienne version possédait une interface DOM très incomplète, si bien que personne ne l’utilisait, les utilisateurs devant alors se rabattre sur l’interface SAX.

À présent, le composant XML présente une nouvelle interface, se rapprochant autant de l’esprit KISS « Gambassien » que de la norme W3C.

Elle vous permet, entre autres, de naviguer et de rechercher dans votre arbre XML, au moyen des classiques relations parent‐enfants, mais aussi via des expressions régulières ou même des règles CSS. Les classes peuvent également être héritées pour vous permettre de gérer vos documents et vos nœuds à votre sauce.

Ceci dit, l’interface SAX n’est pas non plus en reste, les classes Reader et Writer ayant, elles aussi, eu droit à leurs améliorations.

La plus notable est le remaniement de l’algorithme interne d’analyse syntaxique, permettant de travailler sur des documents XML incomplets, et donc sur n’importe quel flux Gambas contenant du XML (qui peut être un fichier, une connexion réseau TCP, une sortie de processus, un périphérique externe…), en entrée comme en sortie.

En outre, si vous utilisez l’interface de lecture SAX, vous pouvez désormais stocker les nœuds lus en mémoire pour y accéder plus tard via l’interface DOM.

XmlTalk

Outre ces changements importants, un sous‐composant HTML a également fait son apparition, ré‐implémentant (ou surchargeant) les classes DOM XML afin de vous permettre de générer plus aisément vos documents XHTML/HTML5 (gestion des feuilles de style et scripts, des méta‐données…), et peut‐être dans le futur des éléments HTML complets, tels que les tableaux, les listes, les formulaires…

Composant multimédia basé sur la bibliothèque GStreamer

gb.media est un nouveau composant apparu dans la version 3.2. Il offre une interface simplifiée à la bibliothèque GStreamer.

GStreamer permet de construire un graphe d’éléments permettant de jouer n’importe quelle donnée multimédia gérée par ses greffons, et plein d’autres choses encore…

Le composant Gambas s’inspire fortement de ce qui précède. Il permet :

  • de créer et de relier entre eux tout type d’élément GStreamer ;
  • de regrouper un ensemble d’éléments dans un élément conteneur unique ;
  • de créer un élément « lecteur multimédia » simplement par une classe dédiée offrant accès aux réglages audio, vidéo, aux sous‐titres et aux greffons de visualisation, etc. ;
  • de récupérer les tags associés aux données multimédia en temps réel.

J’ai créé un lecteur multimédia (appelé de manière originale MediaPlayer) comme exemple d’utilisation de ce composant :

MediaPlayer jouant une vidéo

MediaPlayer jouant de l'audio

GStreamer a l’air assez sensible : la manipulation du graphe d’éléments pendant la lecture d’un fichier peut provoquer un plantage de l’application. Mais peut‐être les choses s’amélioreront‐elles lors du passage à GStreamer 1.0 ?

Bibliothèque scientifique GNU

La bibliothèque scientifique GNU offre toute une panoplie de fonctions permettant d’effectuer des calculs mathématiques.
Attention : cette bibliothèque ne permet pas de faire de calcul symbolique !

Comme la GSL est un gros monstre, seule une petite partie en a pour l’instant été implémentée dans le composant gb.gsl : il s’agit de la gestion des nombres complexes, des vecteurs, des polynômes et des matrices.

Ces quatre objets mathématiques sont intégrés au langage autant que possible :

  • la conversion entre tableaux, vecteurs, polynômes et matrices est implicite ;
  • les cœfficients des vecteurs, des polynômes et des matrices peuvent être indifféremment des nombres réels (Float) ou des nombres complexes. La conversion entre les différents types de données gsl sous‐jacents est transparente ;
  • l’interpréteur a été modifié pour que les opérateurs arithmétiques standard puissent être utilisés sur les objets mathématiques ;
  • la conversion d’un objet mathématique en chaîne de caractères génère une chaîne lisible ou bien une expression Gambas pouvant être utilisée par Eval() ;
  • le compilateur a été modifié pour pouvoir saisir des nombres complexes sous la forme d’un nombre réel suivi de la lettre i. Le nombre i (i2 = -1) doit être écrit 1i pour éviter de le confondre avec une variable de même nom.

Voici un petit exemple :

Exemple de l'utilisation de gb.gsl

L’exécution de la fonction précédente donne :

P = 2x^3+x^2+2x+1
P(i+1) = -1+8i
P(x) = 0 => x = -0,5
V = [1 i]
iV = [i -1]
A = [[i 0][1 i]]
A(V) = [i 0]
A^2 =[[-1 0][2i -1]]

La bibliothèque GSL dispose de nombreuses autres fonctionnalités : permutations, calcul de valeurs propres, nombres aléatoires, fonctions statistiques, équations différentielles, interpolation, etc. Elles seront implémentées au fur et à mesure en fonction des besoins.

Composant POP3 et MIME basé sur la bibliothèque gmime

Deux nouveaux composants, gb.net.pop3 et gb.mime permettent de récupérer ses courriels depuis un serveur POP3.

gb.net.pop3 implémente la communication réseau et le protocole POP3 côté client, tandis que gb.mime décode la structure MIME d’un message et de ses pièces jointes.

Le client POP3 peut communiquer en clair ou bien par SSL en se basant sur le programme openssl.

gb.mime permet aussi de construire des messages MIME. Ceci sera utilisé par le composant gb.net.smtp dans une prochaine version de Gambas.

Composant NCurses

Le composant gb.ncurses introduit dans la version 3.3 est une interface à la bibliothèque ncurses. Il a été développé par Tobias Boege.

Ce composant est dans un état expérimental, mais il permet déjà de jouer à Pong !

Le célèbre Pong

Le but de Tobias est qu’à terme ce composant devienne similaire aux composants graphiques, en offrant un jeu de contrôles permettant de développer des interfaces complètes.

Tâches d’arrière‐plan

L’interpréteur Gambas n’est pas « multi‐threadé », car les ordinateurs sont des machines à états et les threads sont pour les gens qui ne savent pas programmer les machines à états.

Néanmoins, il y avait le besoin de pouvoir lancer des tâches d’arrière‐plan sans interrompre l’interface du programme principal. C’est ce qu’offre la nouvelle classe Task apparue dans la version 3.3.

Une tâche d’arrière‐plan est une classe héritant de Task et dont le code est implémenté dans une fonction publique Main. Elle est exécutée par un fork de l’interpréteur, et communique avec le programme principal par l’intermédiaire de ses sorties standard.

Empaquetage des projets

L’empaquetage des projets est maintenant beaucoup plus fiable depuis la version 3.3.

Les paquets générés ont des dépendances envers les paquets binaires Gambas de la distribution cible, et c’est là que commencent les problèmes !

En effet, beaucoup de distributions sont incapables d’empaqueter correctement Gambas en dépit des instructions disponibles sur le wiki.

En particulier pour OpenSUSE, Debian et Ubuntu. Il est impératif de ne pas utiliser les paquets officiels, et d’utiliser à la place les paquets réalisés par des utilisateurs de Gambas bienveillants.

Le générateur de paquets

Pour tenter de contourner ce problème, Sebastian Kulesz est en train de réaliser une sorte de make spécifique à Gambas qui permettra d’installer un programme écrit en Gambas n’importe où en lançant cette commande directement depuis une archive des sources.

Environnement de développement

Voici les améliorations principales de l’environnement de développement.

L'environnement de développement

1. Déclaration automatique des variables locales

Lors de la frappe de la touche ENTRÉE, l’éditeur détecte l’affectation à une variable non déclarée. Dans ce cas, le type de l’expression affectée est calculé, puis utilisé pour ajouter automatiquement la déclaration de variable adéquate en début de fonction.

L’analyseur de type d’expression a encore quelques petits défauts. Par exemple, il ne prend pas en compte la structure WITH … END WITH.

2. Amélioration de l’éditeur de formulaires

Toute modification d’un formulaire (création de contrôle, destruction de contrôle, déplacement, changement de taille, modification d’une propriété) est maintenant annulable.

Le contrôle situé en‐dessous de la souris est maintenant mis en évidence par un cadre semi‐transparent. Ceci facilite les manipulations des contrôles qui n’ont pas de bordure.

Les contrôles peuvent être marqués individuellement comme non traduisibles. Ceci s’applique aux propriétés de texte.

3. Liste automatique de notes de commentaires

Les commentaires commençant par un des mots‐clefs TODO:, FIXME: ou NOTE: sont automatiquement répertoriés dans une liste.

Liste de tâches

4. Historique des déplacements

Les déplacements du curseur au sein d’un même fichier, ainsi que le passage d’un fichier à un autre, sont mémorisés dans un historique global qu’il est, bien sûr, possible ensuite de parcourir, un peu comme dans un navigateur Web.

Cette fonction n’est pas encore parfaite.

5. Autres améliorations

Voici quelques autres améliorations en vrac :

  • il est possible de définir des signets dans chaque éditeur ;
  • la recherche de chaînes de caractères dans l’ensemble du projet a été optimisée. Elle est maintenant beaucoup plus rapide ;
  • il est possible de configurer le serveur mandataire du navigateur d’aide basé sur WebKit ;
  • la boîte de dialogue de bienvenue a été simplifiée pour les petits écrans, et optimisée pour les processeurs lents (bienvenue aux ARM !).

Interpréteur et compilateur

1. Nouvelles instructions

  • GOSUB : la fameuse instruction BASIC a finalement été ajoutée. Elle permet d’appeler une portion de code située à l’intérieur d’une fonction, et d’en revenir lorsque l’instruction RETURN est rencontrée. C’est assez moche, mais cela permet d’éviter un appel de fonction toujours coûteux en temps d’exécution.

  • ON GOTO, ON GOSUB : il s’agit des instructions BASIC classiques permettant de se brancher sur une étiquette en fonction de la valeur d’une variable.

  • Base64(), UnBase64() : ces deux fonctions permettent de coder une chaîne de caractères en base64 ou bien le contraire.

  • CHMOD, CHOWN & CHGRP : ces trois instructions sont le pendant des commandes système de mêmes noms. Elles permettent respectivement de modifier les autorisations, le propriétaire et le groupe d’appartenance d’un fichier.

  • Les fonctions MkBool$(), MkShort$(), MkInt$(), etc., font leur retour. La fonction Swap$() échange les octets contenus dans une chaîne de caractères. Cet ensemble de fonctions permet de transformer une suite de données binaires en chaîne de caractères, afin, par exemple, de l’envoyer sur une socket.

2. Avertissements

Le compilateur de la version 3.3 émet maintenant des avertissements lors des cas suivants :

  • lorsqu’une variable locale, une variable privée, un argument de fonction, ou bien une fonction privée est inutilisée ;
  • lorsqu’une variable locale ou un argument de fonction surcharge un symbole global.

L’environnement de développement affiche ces avertissements dans un onglet dédié du panneau d’information :

Liste d'avertissements

3. Optimisation de la pile

La pile de l’interpréteur est plus rapide : depuis la version 3.1, sur une idée d’Emil Lengrenn, la pile de l’interpréteur n’est plus allouée par malloc() mais par mmap(), exactement comme la pile du processus.

Par conséquent, elle grandit de manière automatique et les gains de performance sont conséquents, dès lors qu’on utilise beaucoup la récursivité !

4. Optimisations UTF-8

L’UTF-8, c’est génial. Celui qui l’a inventé aussi. Il n’y a qu’un seul problème, c’est lorsque vous devez trouver la position en mémoire d’un caractère à partir de son index.

Comme un caractère UTF-8 peut faire entre 1 et 4 octets, on est virtuellement obligé de parcourir toute la chaîne. Ce qui commence évidemment à poser problème lorsque la longueur de la chaîne de caractères est de plusieurs centaines de milliers d’octets.

Pour optimiser cela, la version 3.3 introduit un système de cache interne des dernières positions calculées dans la dernière chaîne de caractères UTF-8 traitée.

Cela permet d’accélérer grandement la coloration syntaxique de lignes très longues dans l’éditeur.

Pour information, la coloration syntaxique du code Gambas est faite en C. Toutes les autres (HTML, SQL, C, JavaScript, CSS) sont gérées par le composant gb.eval.highlight écrit en Gambas.

5. Support des nombres complexes

Si le composant gb.gsl n’est pas utilisé, et qu’un programme fait référence à un nombre complexe, le composant gb.complex est automatiquement chargé.

Ce composant offre une gestion complète de l’arithmétique des nombres complexes. Mais, contrairement à gb.gsl, il n’offre aucune fonction transcendantale complexe.

Composants graphiques

Les deux composants graphiques (gb.qt4 basés sur Qt 4 et gb.gtk GTK+ 2.0) sont sans doute les plus subtils. Plus d’une centaine de bogues ont été corrigés dans ces composants depuis la version 3.0, dont certains (trop !) sont des contournements de bogues présents dans les bibliothèques sous‐jacentes.

Par dessus ces deux composants graphiques « natifs », vous trouvez un ensemble de contrôles programmés intégralement en Gambas. Ils se situent dans les composants gb.form et gb.db.form, ce dernier regroupant les composants reliés à des requêtes de bases de données.

Les principales modifications apportées depuis la version 3.0 sont les suivantes :

1. Prise en charge des tablettes graphiques

Comme GTK+ impose l’activation explicite de cette prise en charge pour chaque widget, seul le contrôle DrawingArea peut capturer les événements générés par les périphériques d’entrée « étendus ». Pour ce faire, il faut explicitement définir sa propriété Tablet à TRUE.

Les événements tablette génèrent les mêmes événements que la souris, excepté qu’une nouvelle classe Pointer permet de récupérer les propriétés de l’événement : coordonnées fractionnaires, pression du crayon, etc.

Qt et GTK+ ne fournissent pas exactement les mêmes propriétés pour ce genre d’événements. Pourquoi ? C’est encore un mystère pour moi… Heureusement, Gambas essaie de cacher cette disparité.

2. Réécriture du contrôle GridView en Gambas

Le contrôle GridView a été intégralement récrit en Gambas pour les raisons suivantes :

  • le contrôle natif de Qt est incapable de gérer un grand nombre de lignes ; le GridView en Gambas est plus rapide (si, si) et peut sans problème gérer plusieurs millions de lignes ;

  • il n’est plus nécessaire de programmer un GridView dans le composant gb.gtk ; on économise du code, de la maintenance, et surtout le comportement du contrôle est quasi‐identique, qu’on utilise gb.gtk ou gb.qt4 ;

  • il est maintenant possible d’ajouter des fonctionnalités au contrôle GridView qui étaient inexistantes dans le contrôle natif de Qt.

Contrôle GridView

Les contrôles TreeView, ListView et ColumnView risquent eux aussi d’être récrits en Gambas dans une prochaine version.

L’intérêt est que, même si l’on perd légèrement en performances ou en consommation mémoire, l’écriture d’un composant graphique à l’interface identique, qui serait basé sur d’autres bibliothèques que Qt ou GTK+, sera beaucoup plus facile.

3. Améliorations et optimisation du composant GTK+

Dans les précédentes versions, chaque contrôle de gb.gtk était forcé d’avoir sa propre fenêtre X11, contrairement à gb.qt4 où, par défaut, tous les contrôles étaient natifs, c’est‐à‐dire sans fenêtre X11.

Désormais, le comportement par défaut de GTK+ prévaut. C’est‐à‐dire que les contrôles n’ont plus leur propre fenêtre X11 et se comportent visuellement comme les contrôles de Qt.

Malheureusement, certains widgets GTK+ continuent à utiliser des fenêtres X11 malgré tout (TextBox, TextArea…), ce qui pose des problèmes de superposition à l’écran (les contrôles sans fenêtre X11 sont toujours situés derrière les contrôles avec fenêtre X11).

La solution retenue est que les contrôles de type Panel dont la propriété Background (couleur d’arrière‐plan) est définie, ont leur propre fenêtre X11. Ce « truc » permet de contourner les problèmes de superposition et d’avoir un programme qui se comporte visuellement de manière identique, qu’il utilise gb.gtk ou gb.qt4.

Enfin, l’algorithme d’arrangement automatique des conteneurs a été corrigé pour éviter les déclenchements redondants et donc inutiles. L’amélioration des performances lorsqu’on redimensionne un formulaire compliqué sont visibles. Mais Qt reste encore le plus rapide.

4. Gestion des thèmes d’icônes

Gambas dispose d’une classe Stock permettant de manipuler un stock d’icônes prédéfinies à partir d’une clef (open, save, left, etc.) et d’une taille quelconque.

Avant la version 3.3, l’utilisateur avait la possibilité d’utiliser un thème natif stocké dans le composant gb.form.stock, ou bien le thème du bureau courant (KDE, GNOME, Xfce, Mate ou LXDE), ou bien le thème d’un bureau spécifié explicitement.

Depuis la version 3.3, il est possible d’utiliser n’importe quel thème d’icônes installé sur le système, en spécifiant le nom de son répertoire de stockage (oxygen, hicolor, Amaranth, etc.).

Voici par exemple un morceau de l’environnement de développement sous KDE utilisant le thème d’icônes GTK+ « Foxtrot » :

Foxtrot !

5. Autres améliorations diverses

  • Les contrôles peuvent être exclus individuellement de la « chaîne de _focus_ », c’est‐à‐dire que l’appui sur la touche Tab les ignore.

  • Le contrôle SidePanel peut avoir des bordures transparentes, comme par exemple les séparations de Thunderbird.

  • Le composantgb.gtk.opengl permet d’utiliser OpenGL dans les applications GTK+.

  • Le composant gb.gui.opengl a été ajouté. Il permet d’utiliser le composant OpenGL correspondant au bureau courant (gb.qt4.opengl ou gb.gtk.opengl), dans le même principe que gb.gui.

  • Le composant gb.desktop qui sert d’interface aux fonctionnalités du bureau courant — tels que le gestionnaire de mots de passe, l’économiseur d’écran et le gestionnaire de fenêtres — est beaucoup plus fiable. La prise en charge de LXDE et de Mate a été finalisée. Une interface avec les associations entre les types MIME et les fichiers d’application *.desktop a été ajoutée.

Conclusion

Voilà, j’espère que ce petit tour aura éveillé l’intérêt de ceux qui ne connaissaient pas encore Gambas, ou fait découvrir des choses à ceux qui le connaissaient déjà.

Il y a eu, bien sûr, de très nombreuses autres modifications et corrections de bogues depuis la version 3.0, mais nous ne les aborderons pas toutes ici en détails.

Parlons maintenant un peu d’avenir, même si c’est toujours risqué :

  • il va falloir passer à Qt 5 et à GTK+ 3 ;

  • Wayland arrive beaucoup plus rapidement que prévu, cela nécessitera un profond nettoyage des composants graphiques afin d’en retirer toutes les spécificités X11 (coordonnées de souris globales, dialogue avec le gestionnaire de fenêtres, etc.). D’autre part, la « transparence réseau », introduite récemment dans Wayland, nécessitera la gestion simultanée de plusieurs pointeurs et curseurs dans la même fenêtre ;

  • Gambas tourne de mieux en mieux sur les plates‐formes ARM ; le developpeur se demande comment il serait possible de le faire tourner sur Android ;

  • amélioration à prévoir du composant Web de manière à rendre le développement d’applications Web en Gambas de plus en plus agréable.

Et pour terminer en beauté, le développeur qui, paraît‐il, est râleur, aimerait pousser trois petits coups de gueule :

Coup de gueule № 1

Je viens de lire que Qt 5 ne prendra plus en charge les tablettes — tandis que GTK+ 3, au contraire, va améliorer sa prise en charge des périphériques étendus.

J’espère qu’ils ne vont pas faire ça. Et plutôt que de supprimer une fonctionnalité essentielle, si la prise en charge du format SVG pouvait être déboguée, ça ne serait pas plus mal !

Coup de gueule № 2

En faisant tourner l’environnement de développement sous Valgrind, je me suis aperçu que 10 % du temps de démarrage étaient passés dans une unique fonction de la bibliothèque X !

Après analyse, il s’avère que l’initialisation des méthodes d’entrées X (X Input Method) doit analyser un fichier texte d’un demi‐mégaoctet, qui décrit toutes les possibilités de composition des touches du clavier.

Or, cette analyse se base sur les fonctions de flux standard de la libc (en particulier la fonction getc() qui est appelée pour chaque caractère lu !). Et les fonctions de flux de la libc sont très lentes.

C’est en les utilisant le moins possible que j’ai pu doubler la vitesse du compilateur de Gambas entre la version 2 et la version 3.

J’ai reporté le problème sur le _bugzilla de freedesktop.org, mais je n’ai pas de nouvelles depuis._

J’ai même corrigé la routine moi‐même, mais je n’ai pas réussi à compiler les bibliothèques X11. Trop de dépendances incompréhensibles…

C’est quand même dommage de dépenser autant de temps au lancement de chaque application Qt (et sans doute aussi GTK+) ! Mais notez que les applications KDE échappent sans doute à ce problème, vu qu’elles sont normalement lancées par le fork d’un unique exécutable.

Coup de gueule № 3

Dernier coup de gueule : que faut‐il faire pour espérer qu’un jour Debian, Ubuntu et openSUSE réussissent à empaqueter Gambas correctement ?

Je suis ouvert à toutes les solutions ! Excepté faire les paquets moi‐même, car je n’ai malheureusement pas le temps.

Voilà, j’ai râlé, je me sens mieux. Merci de votre attention, et vive le logiciel libre !

  • # Precisions

    Posté par . Évalué à  4 .

    À ma connaissance, aucune distribution n'utilise pour l'instant LLVM 3.1, mais cela ne saurait tarder. En attendant, sur Ubuntu 12.04, il vous faudra compiler LLVM 3.1 à la main, sachant que toute utilisation combinée avec OpenGL plantera, car celui-ci essaiera d'utiliser LLVM 3.0. Visiblement, il n'a pas été prévu de pouvoir utiliser deux versions différentes de LLVM dans le même processus. :-)

    Perdu! ArchLinux utilise LLVM 3.1 depuis un bon bout de temps (depuis le 22/05/2012 pour étre exact)

    Coup de gueule n°2

    Comment "contourner" le problème (si je ne trompe pas):
    https://wiki.archlinux.org/index.php/Kde#Speed_up_application_startup

    Sinon, bonne dépéche!

    • [^] # Re: Precisions

      Posté par (page perso) . Évalué à  5 .

      OK, j'ignorais. J'ai essayé le truc du ~/.compose-cache, mais ça ne fait rien… Et pourquoi avoir implémenté ça plutôt que de corriger la fonction de la librairie X11 en cause ?

      Sinon autres questions : qui a modifié la dépêche en rajoutant des fautes d'orthographes ? Pourquoi la fin est elle en italique ?

      • [^] # Re: Precisions

        Posté par (page perso) . Évalué à  9 .

        Au nom de mes collaborateurs dévoués, j'aimerai rappeler que la dernière étude des statistiques de fréquentation de linuxfr a révélé la prépondérance des commentaires (et trolls) sur les fautes d'orthographe. Ces commentaires contribuant à la lisibilité du site auprès des DSI et décideurs pressés (sinon ils ne comprenaient rien), le conseil nous emploie régulièrement à amender les dépêches trop bien écrites.
        Pour l'italique, je transmet votre requête à la commission de création de CSS boguées (CCC 666).

        Merci de votre intérêt envers nos services.

        Le président du comité d'information et surveillance des carences orthographiques (CISCO).

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Precisions

          Posté par (page perso) . Évalué à  2 .

          à corriger :

          • le dévellopeur, avec 2 P et un seul L, sinon il risque de s'envoller (oups).
          • "Qt 5 ne prendra plus en charge les tablettes" : ça serait bien de préciser "graphiques"

          Sinon ça semble vraiment bien Gamba, félicitation pour ce développement !

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Precisions

        Posté par . Évalué à  9 . Dernière modification : le 01/10/12 à 09:08

        « Pourquoi la fin est elle en italique ? »

        Je pense que l'Équipe de Rédaction, Canal Inquisition, a trouvé que tes coups de gueule n'étaient pas politiquement et éditorialement corrects pour un site à la stature internationale tel que LinuxFr. C'est acceptable sur ton blog, ton truiteur ou ton mur, mais ça ne l'est pas sur un site qui a une politique de rédaction claire, rigoureuse et stricte.

        À l'avenir, si tu veux pousser des coups de gueule, envoies-les à des sites d'amateurs franchouillards tels que Le Monde, Le Figaro, l'Observateur ou l'Express. Évites les sites professionnels bien propres sur eux tels que Atlantico, Slate ou LinuxFr !

        Plus sérieusement, Gambas est intéressant et c'est dommage que ce projet redoutablement maintenu n'a pas la visibilité qu'il mérite : chaque fois que je tombe dessus, on sent qu'il y a du sacré boulot derrière ! Pourvu que ça dure.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Precisions

        Posté par (page perso) . Évalué à  5 .

        Au fait j'oubliais: magnifique dépêche! Et bravo pour Gambas, ton travail - impressionnant - m'a toujours donné envie de me jeter dedans.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # UTF-8 est auto-synchronisant

    Posté par . Évalué à  5 .

    « Il n'y a qu'un seul problème, c'est lorsque vous devez trouver la position en mémoire d'un caractère à partir de son index. Comme un caractère UTF-8 peut faire entre 1 et 6 octets, on est virtuellement obligé de parcourir toute la chaîne. »

    Pas du tout ! Une des propriétés de l'UTF-8 est l'auto-synchronisation. C'est-à-dire qu'à partir d'une position quelconque dans un flux conforme, il suffit de rechercher un octet qui ne corresponde pas au motif 10xxxxxx pour trouver le début d'un caractère.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: UTF-8 est auto-synchronisant

      Posté par (page perso) . Évalué à  7 .

      C'est vrai que c'est un véritable avantage quand tu veux retrouver le 6054ème caractère de savoir qu'il est entre les 6054ème et 36324 octets.

      • [^] # Re: UTF-8 est auto-synchronisant

        Posté par . Évalué à  4 .

        Effectivement, je ne l'avais pas compris comme ça.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: UTF-8 est auto-synchronisant

        Posté par . Évalué à  2 .

        C'est vrai que c'est un véritable avantage quand tu veux retrouver le 6054ème caractère de savoir qu'il est entre les 6054ème et 36324 octets.

        C'est un argument souvent avancé contre UTF8 mais comme le dis Robert O'Callahan[1], quels sont les cas d'utilisation réels d'accès aléatoire à un caractère donné ? Le plus souvent, les algos de recherche sont plutôt itératifs (recherche de sous chaînes). On a pris l'habitude de manipuler des chaînes comme des tableaux (héritage du C) même pour des accès séquentiels. Combien de fois écrit-on :
        for (i = 0; i < n; i++)
        do_something(str[i]);

        On se fout un peu du i en question. On balaye la chaîne. C'était juste le seul moyen d'écrire ça en C vu qu'il n'y a pas d'itérateur/foreach.

        [1] http://robert.ocallahan.org/2008/01/string-theory_08.html

        • [^] # Re: UTF-8 est auto-synchronisant

          Posté par . Évalué à  6 .

          recherche de sous chaînes

          L'algo de « Knuth Morris Pratt » n'est pas itératif (du moins pas complètement). Il existe des technique pour être itératif (le cas classique) et faire des sauts selon quel caractère de la sous-chaîne n'a pas était reconnue. Je présume que c'est encore plus le cas pour les expressions régulière qui font des retours arrière plus ou moins fréquent. C'est aussi le cas de Boyer/Moore.

          Après je n'y connais rien en UTF8, hein. Je dis juste que la recherche de sous-chaîne peu demander des sauts si les sauts ont une complexité linéaire en O(n) (n le nombre de caractère à sauter, ça détruit leur performance (et il vaut peut être mieux se tourner l'algo d'Aho Corasick).

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Coup de gueule

    Posté par . Évalué à  4 .

    Coup de gueule n°2

    La vraie solution ne serait-elle pas d'utiliser XCB plutôt que Xlib ? Si j'ai bien compris XCB est asynchrone, elle utilise probablement une méthode plus efficace pour faire ce travail. Il faudrait donc plutôt voir du coté de Qt quand est-ce qu'ils passeraient à XCB.

    Coup de gueule n°3

    Je ne sais pas si ceux de gambas2 sont dut au packaging, mais il n'y a actuellement aucun bug reporté pour gambas3 chez Debian.

    Après faut bien comprendre que c'est comme tout projet libre, c'est au bon vouloir de quelqu'un pour packager gambas. Il peut même faire des erreurs.

    Le mieux reste de remonter les problèmes et de coopérer autant que possible avec le ou les responsable (comme pour n'importe quoi dans le libre au final).

    AMHA au lieu de se disperser à tenter de l'améliorer dans ubuntu et debian concentre-toi sur Debian. Ubuntu en récupéra les bien faits dès que ça passeras dans Debian Testing.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # des chiffres plus réalistes

    Posté par . Évalué à  2 .

    salut,

    certes, les backends llvm ont tjrs des perfs intéressantes mais en comparant des implémentations naives, le benchmark ne reflète qu'un avantage théorique qui n'a pas de lien avec la réalité. Je ne pense pas que ce benchmark est volontairement partial: il met juste en évidence ce que les développeurs de gambas s'attendaient à trouver.

    Toutefois, lorsque des problèmes de performance se posent, on se met a regarder le code (après lecture diagonale, on se débarrasse du double parcours de tableau dans la boucle qui creuse inutilement l'écart) et on utilise les outils adaptés (pdl en perl et je pense que ce serait numpy pour python).

    ça serait donc intéressant de voir des codes plus idiomatiques et pratiques remplacer les benchs existants.

    ensuite: comparer avec des langages dynamiques c'est pas très sport! les implémentations haskell ou go seraient plus courtes que leurs équivalentes gambas: quid des perfs dans ces deux languages?

    bref… si qq1 a un peu de temps libre, ça peut être intéressant de fournir à la communauté gambas des chiffres plus objectifs (je répète que je ne crois toutefois pas qu'il y ai eu un quelconque calcul propagandiste!)

    • [^] # Re: des chiffres plus réalistes

      Posté par (page perso) . Évalué à  8 .

      en tout cas on peut constater qu'il aura suffit d'un mec un peu motivé pour ajouter un JIT qui marche à gambas , là où python propose 42 solutions differentes dont aucune n'est finie, et là où perl attend son JIT depuis 15 ans

    • [^] # Re: des chiffres plus réalistes

      Posté par (page perso) . Évalué à  5 .

      Pourquoi ces trois benchmarks ? La raison est très simple : ce sont les trois seuls algorithmes que j'ai trouvés sur le net programmés à la fois en Perl et en Python.

      Et comme je ne maîtrise ni Perl ni Python, je ne suis pas vraiment capable d'écrire de nouveaux benchmarks, ni de corriger le code Perl ou Python des benchmarks existants.

      Mais si quelqu'un me propose un bout de code écrit en Perl et en Python, je ferais une joie de le convertir en Gambas et d'en faire un nouveau benchmark ! De même si quelqu'un m'explique comment utiliser le (les ?) compilateur JIT de Python pour le comparer avec celui de Gambas.

      J'aimerais bien comparer par exemple le traitement des chaînes de caractères, la rapidité des appels de fonctions récursifs, un programme en OpenGL, etc.

      Sinon pour haskell, je ne connais pas. Et je ne suis pas sûr que Go soit interprété : la comparaison est faite entre langages interprétés, pas entre langages "dynamique" ou pas — peux-tu m'expliquer d'ailleurs ce que tu entends pas là exactement ?

      • [^] # Re: des chiffres plus réalistes

        Posté par . Évalué à  2 .

        Sinon pour haskell, je ne connais pas.

        Haskell est gambas sont trop différents pour qu'une comparaison soit quelque peu pertinente. Pour la faire courte, Haskell est un langage fonctionnel pure, non strict et lazy. Il n'a pas de couche objet (Go non plus me semble t'il) et est compilé (même s'il est possible d’écrire des scripts). Bref rien à voir avec Gambas.

        A part ça, très beau boulot et excellente dépêche!

        • [^] # Re: des chiffres plus réalistes

          Posté par . Évalué à  1 .

          s/lazy/paresseux/

          C'est vraiment le point qui m'a posé le plus de problème lorsque j'ai voulu me mettre au Haskell (outre le fait de ne pas avoir de variable): c'est trop classe de pouvoir travailler avec des listes infinie et de pouvoir enchaîner des "sum zip map filter …" efficacement mais il faut bien réfléchir à quand ton code va être évaluer sinon les performances sont toutes pourries.

    • [^] # Re: des chiffres plus réalistes

      Posté par (page perso) . Évalué à  7 .

      Au passage j'ai juste lancé le bench polynom avec pypy.

      python2: 140s
      python3: 110s
      pypy1.9: 5s

      Ben quoi, il marche bien notre JIT python ;)

  • # Tablettes Wacom

    Posté par . Évalué à  1 .

    Dans le Coup de gueule n°1, les seules tablettes qui ne sont pas prises en charge sont les tablettes Wacom. Il ne s'agit pas de tablettes telles l'iPad ou la Galaxy Tab, mais de périphériques d'entrée basés sur un stylet (voir http://www.wacom.eu/index2.asp?pid=8001&lang=fr) qui ne disposent pas forcément d'un écran.

    Il s'agit d'un matériel assez spécifique (gestion de la pression de la pointe du stylet ou de la gomme virtuelle, principalement), et même s'il est extrêmement regrettable qu'il n'y ai pas vraiment de support pour ce type de matériel (au delà de la prise en charge en tant que souris), il ne faut pas confondre ce périphérique d'entrée avec les tablettes plus classiques (manipulables au doigt).

    • [^] # Re: Tablettes Wacom

      Posté par (page perso) . Évalué à  4 .

      Oui bien sûr il s'agit de tablettes graphiques.

      Ce que je ne comprends pas, et si j'ai bien compris le mail confus de la mailing-list Qt, c'est que comme le support des tablettes Wacom est défectueux sous Windows, on le retire de Qt. Alors que sous Linux je le trouve meilleur que celui de GTK+ par exemple.

      Depuis quand retire-t-on le support d'un périphérique avant de trouver une solution de remplacement ? Même si le support précédent est mal programmé. C'est idiot !

      • [^] # Re: Tablettes Wacom

        Posté par (page perso) . Évalué à  5 .

        Moi de ce que j'ai compris du fil, c'est que un mec proposait de le retirer de Qt4 en disant que ça pète les autres applis Qt et personne ne sait le réparer, et que les autres disent qu'ils peuvent utiliser un patch crado fait par Digia ou ajouter une option pour désactiver le support de la tablette (ou l'activer, suivant le comportement par défaut).

        Pour Qt5, le problème n'est pas qu'ils ont enlevé le support, mais que la partie entrées a été réécrite, et que personne n'a réécrit le support pour les tablettes Wacom. Le support reviendra dès que quelqu'un s'y collera (enfin, quelqu'un qui y comprend quelque chose…).
        Sachant que des petits joueurs genre Autodesk en ont besoin, on peut supposer que Digia mettra les ressources qu'il faut en temps voulu.

  • # Utilisation de programmes Gambas

    Posté par (page perso) . Évalué à  3 .

    C'est peut-être une question un peu bête, mais j'ai pas trouvé la réponse sur le site WEB, ni dans l'article (fort intéressant au passage ;-) ).
    J'ai bien compris que le packaging de Gambas pour divers distributions semble problématique, cela veut-il dire que si on a développé un programme avec Gambas, il est difficile de le faire tourner sous d'autre machines Linux?
    Comme se fait la distribution d'un programme Gambas?
    Est-ce que c'est des fichiers sources (comme pour Python/Perl par exemple) ou un binaire que l'on fourni?

    En tout cas, bravo pour le travail fourni, je suis vraiment impressionné!

    • [^] # Re: Utilisation de programmes Gambas

      Posté par (page perso) . Évalué à  5 .

      l'IDE propose un assistant qui créé des paquets binaires du projet pour tout un ensemble de distributions.

      Ces paquetages binaires ont des dépendances envers les paquets binaires Gambas de la distribution cible. Comme la dépendance est un nom de paquetage, si Gambas n'est pas empaqueté correctement, les noms ne vont pas correspondre, ou bien les paquets ne vont pas installer ce qu'il faut, et le paquet généré par l'IDE ne fonctionnera pas.

      L'idée de Sebastian est de créer un programme genre make spécifique à Gambas. Il suffira alors de distribuer uniquement l'archive des sources, de lancer ce make sauce Gambas à l'intérieur pour que le projet soit compilé sur le système, les dépendances résolues et le programme installé.

      Je ne sais pas encore comment tout ça va fonctionner dans le détail. Mais j'imagine que si les paquets d'une distribution sont incorrects, on pourra contourner ce problème en indiquant au programme make quoi installer pour telle distribution, ou bien où aller chercher des paquets corrects.

      Désolé je dis souvent "paquetage", mais c'est parce que j'ai fait mon service militaire.

      • [^] # Re: Utilisation de programmes Gambas

        Posté par . Évalué à  3 .

        Je ne sais pas encore comment tout ça va fonctionner dans le détail. Mais j'imagine que si les paquets d'une distribution sont incorrects, on pourra contourner ce problème en indiquant au programme make quoi installer pour telle distribution, ou bien où aller chercher des paquets corrects.

        Je pense que ça peut être utile de regarder comment c'est fait ailleurs. Actuellement un paquet de langages ont ce genre de mécanisme (qui n'est absolument pas lié au langage), les plus connu/utilisés sont probablement perl avec CPAN, python avec pip et Java avec les repository maven (ce dernier a lui aussi un builder qui permet d'installer automatiquement les dépendances (c'est d'ailleurs je trouve un problème de perl, il n'y a pas de mécanisme pour dire « j'installe ça qui n'est pas dans CPAN, il va automatiquement récupérer les dépendances CPAN », un autre problème étant la lourdeur d'installation d'un module depuis CPAN (y compris quand on retire les tests)), et pourtant j'adore ce langage).

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Typage statique ou dynamique?

    Posté par . Évalué à  2 .

    Gambas est-il typé statiquement ou dynamiquement?
    D'après les exemples que tu donne, cela ressemble plutôt à du typage statique donc la comparaison devrait plutôt être vis à vis de Java, non?

    PS: Intéressant tes coups de gueules.

    • [^] # Re: Typage statique ou dynamique?

      Posté par (page perso) . Évalué à  4 .

      Gambas est-il typé statiquement ou dynamiquement?

      Ah ! Bonne question…

      Gambas est typé statiquement, sauf qu'il possède le type Variant, qui peut contenir n'importe quel type, ainsi que le type Object, qui peut contenir n'importe quel type d'objet.

      D'autre part, le compilateur n'effectue aucune liaison de type et aucune optimisation : c'est l'interpréteur qui, à la première exécution du code, effectue les optimisations liées aux types de base, ainsi que les résolution de symboles — c'est-à-dire que Classe.Symbole est une recherche binaire dans une table de symboles à la première exécution, et un accès direct ensuite.

      D'autre part nous avons :

      • Les méthodes, qui retournent toujours un type spécifique (le cas du type Variant et du type Object étant spécial)

      • Et les "sous-routines" (c'est-à-dire les fonctions intégrées au langage, de Left$() jusqu'à Pointer@()) qui doivent juste respecter la règle qu'un même type en entrée générera toujours le même type en sortie (principe d'inférence).

      Enfin les méthodes de classes sont toutes "virtuelles" (dans le sens de C++), et l'héritage est entièrement dynamique (résolu par l'interpréteur).

      Pour résumer, je dirais donc que Gambas à l'air d'être typé statiquement, mais qu'à l'intérieur il est pratiquement typé dynamiquement.

      • [^] # Re: Typage statique ou dynamique?

        Posté par . Évalué à  3 .

        Gambas est typé statiquement, sauf qu'il possède le type Variant, qui peut contenir n'importe quel type, ainsi que le type Object, qui peut contenir n'importe quel type d'objet.

        Le "sauf que" est peut-être en trop: Scala a Any et Object mais on le considère quand même comme typé statiquement..

        Pour résumer, je dirais donc que Gambas à l'air d'être typé statiquement, mais qu'à l'intérieur il est pratiquement typé dynamiquement.

        Pas sûr de comprendre, même si l'implémentation se base sur du typage dynamique, si ça n'apporte pas le comportement d'un langage dynamique, c'est un langage à typage statique point.

  • # Popularité ?

    Posté par (page perso) . Évalué à  5 .

    Tu pourrais nous donner quelque chiffres sur la popularité de Gambas ? Et quelques exemples de programmes réels ?

    Côté utilisateurs, tu as plutôt des développeur power-user, ou des débutants en programmation ?

    • [^] # Re: Popularité ?

      Posté par (page perso) . Évalué à  1 .

      Tu pourrais nous donner quelque chiffres sur la popularité de Gambas ?

      Je viens de regarder, ça n’apparaît pas dans le TIOBE ni dans Lang-index :(
      Enfin, la bonne nouvelle, c'est que pour le deuxième, ça va changer, j'ai soumis le patch pour faire des stats sur Gambas :)
      Du coup, on en saura plus dans quelques jours.

      • [^] # Re: Popularité ?

        Posté par (page perso) . Évalué à  2 . Dernière modification : le 04/10/12 à 11:44

        Quand on voit que le basic est en 5eme place sur lang-index pour deux catégories…. on se dit qu'il y a de l'espoir! car "Gambas Almost Means Basic" !

        http://theotherdays.net

      • [^] # Re: Popularité ?

        Posté par (page perso) . Évalué à  3 .

        J'ignorais l'existence de ces sites…

        Ceci dit, ça ne me gêne pas en fait si Gambas n'est pas populaire, et par conséquent qu'il y ait des milliers de langages de programmations, certains plus populaires que d'autres :

        • Je n'aime pas trop la mentalité Sauron (one language to rule them all).

        • Si un langage existe, c'est bien qu'il doit répondre à un besoin réel, non ? (Brainf..k vous dites ?)

        • Je pense que chaque programmeur devrait écrire son langage de programmation. Comme un musicien qui exprimerait son langage musical en jouant ses propres compositions. Comme un comédien qui jouerait ce qu'il a à raconter. Et si on réfléchit bien, c'est toujours comme ça que ça devrait être.

        Après je comprends que ça rassure d'utiliser le langage que tout le monde utilise.

        • [^] # Re: Popularité ?

          Posté par . Évalué à  2 .

          Ceci dit, ça ne me gêne pas en fait si Gambas n'est pas populaire, et par conséquent qu'il y ait des milliers de langages de programmations, certains plus populaires que d'autres :

          La question n'était pas de savoir si beaucoup de monde utilise ou pas gambas, mais quel type d'utilisateurs il a (des gens qui découvrent la programmation (comme beaucoup d'utilisateurs de basic), des gens dont la programmation n'est pas le métier, des universitaires, etc).

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Popularité ?

          Posté par (page perso) . Évalué à  1 .

          Ceci dit, ça ne me gêne pas en fait si Gambas n'est pas populaire, et par conséquent qu'il y ait des milliers de langages de programmations, certains plus populaires que d'autres :

          Tout à fait d'accord, c'est juste un indicateur et le plus intéressant au-delà de ça, c'est l'évolution qui te permet de savoir si on en parle de plus en plus.

          Je n'aime pas trop la mentalité Sauron (one language to rule them all).

          Là, pas de problème non plus, chaque langage a ses spécificités.

          Je pense que chaque programmeur devrait écrire son langage de programmation. Comme un musicien qui exprimerait son langage musical en jouant ses propres compositions. Comme un comédien qui jouerait ce qu'il a à raconter. Et si on réfléchit bien, c'est toujours comme ça que ça devrait être.

          L'analogie n'est pas correcte, un musicien fait ses propres compositions sans ré-inventer le solfège et heureusement d'ailleurs !!
          Pour ce qui est d'écrire son propre langage de programmation, je suis moyennement d'accord car cela met en œuvre des connaissances qui ne pas nécessaires à tout programmeur.

          Après je comprends que ça rassure d'utiliser le langage que tout le monde utilise.

          Ça dépend des gens. Certains voudront en apprendre le plus possible pour répondre à leurs divers problèmes, d'autres diront que tel ou tel langage sait tout faire facilement.

          • [^] # Re: Popularité ?

            Posté par (page perso) . Évalué à  5 .

            Je pense que chaque programmeur devrait écrire son langage de programmation. Comme un musicien qui exprimerait son langage musical en jouant ses propres compositions. Comme un comédien qui jouerait ce qu'il a à raconter. Et si on réfléchit bien, c'est toujours comme ça que ça devrait être.

            L'analogie n'est pas correcte, un musicien fait ses propres compositions sans ré-inventer le solfège et heureusement d'ailleurs !!

            Si tu creuses, je t'assure que l'analogie est correcte : déjà je n'ai pas parlé de partition. Une composition n'implique pas forcément une partition.

            La majeure partie de la musique jouée dans le monde n'utilise pas de partition. Et un musicien n'est pas une boîte à musique dont le programme est la partition.

            Le solfège est un genre d'espéranto musical (largement occidental), et une même partition donnera deux musiques différentes jouée par deux musiciens différents (et au pire, on peut jouer la Marseillaise dans le style de Mozart).

            Pour ce qui est d'écrire son propre langage de programmation, je suis moyennement d'accord car cela met en œuvre des connaissances qui ne pas nécessaires à tout programmeur.

            J'exagérais un peu (hum) : j'ai écrit ces paragraphes en pensant non pas au côté pragmatique de l'activité "écriture de programmes", mais à son côté artisanal et artistique.

            Au moyen-âge, un ouvrier devenait maître après avoir réalisé un chef-d’œuvre, qui était à la fois une démonstration de son savoir-faire, une garantie pour ses clients, et une expression artistique personnelle.

            Dans le cas du programmeur, un chef-d’œuvre peut être n'importe quel type de logiciel bien sûr. Mais le plus cool, c'est langage de programmation, non ? :-)

            Le monde moderne se caractérise (entre autres) par l'uniformisation, et l'ouvrier (au sens large) n'a plus sa place dans le processus de production. Sauf s'il se contente d'être un numéro interchangeable, un simple rouage d'une machine qui le dépasse. Fini les corporations et l'art au sens premier du terme.

            Heureusement, ce n'est pas encore le cas dans le métier de programmeur, et le logiciel libre est un mouvement moyenâgeux qui rappelle les périodes où l'on construisait des cathédrales. Sauf qu'on y travaillait pour Dieu. Pour qui travaillons-nous ? :-)

    • [^] # Re: Popularité ?

      Posté par (page perso) . Évalué à  2 .

      Côté gros programmes, la dépêche précédente (cf liens) en contient quelques exemples dans les commentaires si ma mémoire ne s'amuse.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.