Sortie de Gambas 3.12

Posté par  (site web personnel) . Édité par Davy Defaud, Benoît Sibaud, ZeroHeure, claudex et palm123. Modéré par ZeroHeure. Licence CC By‑SA.
59
31
déc.
2018
Technologie

Gambas est un langage de programmation orienté objet, basé sur un interpréteur BASIC, et une plate‐forme de développement complète comportant, entre autres, un compilateur, un interpréteur, un ensemble 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.

Il neige

La précédente dépêche datant de septembre 2012, profitons de la sortie de la version 3.12 pour présenter comment le langage a évolué depuis six ans.

Nous invitons ceux qui ne connaîtraient pas Gambas à lire préalablement la présentation du logiciel sur le site Web, ainsi que la dépêche précédente.


Comme dans la dépêche précédente, il y a quelques coups de gueules, mais ils sont cette fois répartis dans le texte (et partiellement édulcorés en modération).

Sommaire

Un nouveau compilateur « à la volée »

L’évolution majeure de la version 3.12 est l’abandon de l’ancien compilateur, basé sur une vieille version de LLVM, et la réécriture d’un nouveau compilateur « à la volée ».
Ce compilateur traduit le « bytecode » Gambas en langage C pendant l’exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.

Cette méthode de compilation a le désavantage d’être plus lente que la génération de code classique. Mais elle a le gros avantage de ne pas dépendre de l’API souvent peu fiable offerte par chaque compilateur C. Contrairement à l’ancien compilateur, le prise en charge du langage est complète. De plus, il y a maintenant la possibilité de désactiver certains tests comme la vérification des accès aux tableaux ou les tests de division par zéro, afin de gagner en vitesse, mais au risque de possibles plantages de l’application.

Remarque : Apparemment les développeurs de Ruby ont eu la même idée !

Coup de gueule no 1

L’API de génération de code de LLVM a été refaite entre LLVM 3.5 et LLVM 3.6. C’est quoi cette manie de sortir une version mineure d’une bibliothèque sans assurer de rétro‐compatibilité ?

Développement d’applications Web avec interface graphique

Une autre évolution majeure est la possibilité de développer des applications Web depuis l’environnement de développement, à la manière des applications graphiques classiques.

Nouveau composant et prise en charge de l’environnement de développement

Cette fonctionnalité repose sur un nouveau composant, gb.web.form, qui ajoute à l’environnement de développement un nouveau type de formulaire graphique, les WebForm. Ces « formulaires Web » servent à définir les différents écrans de votre application Web, qui pourront être soit des pages HTML classiques, soit des boîtes de dialogues modales. Le composant offre ensuite de nombreux contrôles graphiques Web qui vont peupler vos différents formulaires, à la manière d’une interface graphique locale classique.

Voici par exemple un formulaire d’une application Web de gestion de radio Internet :

Un formulaire Web dans l’environnement de développement

Principe de fonctionnement

Le principe retenu diffère sensiblement des habitudes à la mode : votre application, une fois compilée, devient un script CGI, et pratiquement tout est géré au niveau du serveur.

Le navigateur de l’utilisateur est principalement utilisé comme un terminal graphique, le HTML devenant le protocole de description de l’interface. On utilise le minimum de JavaScript possible. Les actions de l’utilisateur sont envoyées à l’application sous forme de requêtes XML/HTTP qui répondent en envoyant le code JavaScript nécessaire au rafraîchissement de la page. L’état de l’interface graphique est mémorisée dans la session de chaque utilisateur.

C’est bien évidemment plus lent que les applications Web s’exécutant majoritairement dans le navigateur, et cela offre moins de possibilités. Mais cela fonctionne pas mal.

Voici le résultat du formulaire précédent dans le navigateur Chrome :

Le résultat dans Chrome

Il y aurait encore beaucoup à dire sur ce composant !

Autres évolutions majeures

Changements dans l’infrastructure de développement

Le développement de Gambas a été migré de Subversion vers Git. Le référentiel étant maintenant stocké sur gitlab.com.

Après environ 18 mois d’utilisation, je peux confirmer que git est plus puissant, plus rapide, plus pratique et plus fiable. Il n’y a franchement rien à redire.

D’autre part, les listes de diffusion ont été migrées depuis SourceForge vers un serveur privé maintenu par un utilisateur de Gambas. Le gestionnaire de bogues, quant à lui, est depuis longtemps un logiciel développé en Gambas et hébergé par la société qui m’emploie. Ne reste plus donc que le site Web sur SourceForge. Sans doute pas pour longtemps !

Prise en charge de nouvelles architectures et systèmes d’exploitation

La prise en charge des systèmes autres que GNU/Linux et des architectures autres que i386 et x86_64 a été améliorée.

Gambas devrait normalement se compiler sans souci sur les systèmes :

  • FreeBSD ;
  • NetBSD ;
  • GNU/kFreeBSD ;
  • Cygwin.

Ainsi que sur les architectures :

  • ARM ;
  • ARM64 ;
  • PowerPC64.

Il y a même eu des modifications pour Hurd !

Serveur de publication de logiciels écrits en Gambas

Gambas dispose maintenant d’un serveur de publication de logiciels écrit lui‐même en Gambas. Il permet de publier et d’installer tout type de logiciel écrit en Gambas.

L’environnement de développement dispose d’une interface graphique permettant de lister les logiciels publiés, de les filtrer, de les installer et de les désinstaller. Il permet aussi de publier très facilement votre projet.

Remarque : Les programmes d’exemples auparavant fournis avec les sources sont désormais stockés sur le serveur de publication.

Serveur de publication

Améliorations de l’environnement de développement intégré

Nouvel éditeur d’images

L’éditeur d’images a été entièrement réécrit et amélioré :

  • possibilité d’avoir des sélections multiples ;
  • opérations booléennes sur les sélections, grâce au nouveau composant gb.clipper (voir plus loin) ;
  • rotation, étirement, duplication de sélections ;
  • sélection par baguette magique ;
  • balance des couleurs, floutage, opacité ;
  • coloriage, désaturation, transformation d’une couleur en transparence.

Nouvel éditeur d’images

Prise en charge de Git

Le gestionnaire de versions intégré prend maintenant en charge Git en plus de Subversion, et son interface a été revue. L’intégration de Git à l’IDE possède un mode de fonctionnement similaire à subversion, elle a en plus la gestion des branches.

Dans tous les cas, rien n’empêche d’utiliser la ligne de commande dès que l’on a d’autres besoins. Git est si vaste, qu’il est difficile de proposer une interface graphique qui soit simple sans devoir restreindre les fonctionnalités.

Gestionnaire de versions (1)
Gestionnaire de versions (2)

Mode fichier unique

L’environnement de développement peut être maintenant utilisé pour éditer des fichiers uniques, sans devoir créer de projet pour cela. Cette fonctionnalité est très pratique pour éditer rapidement une image, ou bien pour examiner une base de données SQLite.

Édition d’une base de données SQLite

Modèles de projet

La boîte de dialogue d’ouverture de projet a été revue : elle se base maintenant sur une liste de modèles de projet. Cette liste est extensible à volonté. Il suffit de créer de nouveaux projets dans le répertoire ~/.local/share/gambas3/template/, et ils seront pris en compte en tant que nouveaux modèles.

Police Gambas dédiée à l’édition de code

Une police appelée « Gambas » est maintenant installable dans votre répertoire personnel à partir de l’écran des options. Il s’agit d’une police bitmap existant en deux tailles, 9 et 10 points, et en deux variantes, normale et grasse. Elle contient de nombreux caractères Unicode et, même si elle n’est pas complète, elle est largement plus utilisable que nombre de polices bitmap existantes.

Police Gambas

Améliorations diverses

Quelques améliorations diverses :

  • possibilité de désactiver un point d’arrêt ;
  • prise en charge des fichiers au format patch ;
  • le créateur de paquets gère maintenant les applications indépendantes du toolkit graphique ;
  • complétion automatique des noms de fichiers ;
  • en cas de plantage de l’environnement de développement, les fichiers modifiés sont automatiquement sauvegardés ;
  • la boîte de dialogue d’ouverture de projet a été revue ;
  • l’aide hors ligne est téléchargeable depuis l’écran des options ;
  • la compression des fichiers JavaScript et CSS a été améliorée ;
  • les fichiers PNG peuvent être automatiquement compressés si l’outil pngquant est présent ;
  • la gestion des thèmes sombres a été grandement améliorée ;
  • le gestionnaire de sessions du bureau est pris en charge ;
  • l’interface du débogueur a été revue ;
  • fenêtre d’insertion de caractères spéciaux ;
  • etc.

Accès aux bases de données

Le système d’accès aux bases de données a été amélioré :

  • les connexions définies dans l’environnement de développement sont accessibles à l’exécution, et les mots de passes éventuellement associés et stockés dans le porte‐clefs du bureau sont automatiquement récupérés ;
  • les « collations » de champs sont maintenant gérées, lorsqu’elles sont prises en charge par le type de bases de données sous‐jacent ;
  • une classe SQLRequest a été ajoutée, elle permet de construire une requête SQL en tenant compte automatiquement des différences de syntaxe entre les SGBD ;
  • la propriété Connection.LastInsertId permet de récupérer la dernière valeur générée par un champ auto‐incrémenté ;
  • le composant gb.db.mysql permettant d’accéder aux bases de données MySQL est plus rapide, grâce à l’implémentation d’un cache interne de méta‐données ;
  • le composant gb.db.sqlite3 permettant d’accéder aux bases de données SQLite 3 a été complètement récrit en C ; il est maintenant plus fiable, plus rapide et consomme moins de mémoire ;
  • le composant gb.db.odbc peut maintenant recevoir une chaîne de connexion ODBC complète comme nom d’hôte de la base de données ;
  • le composant gb.db.form, qui offre des contrôles graphiques liés aux bases de données, a reçu pas mal de corrections.

D’autre part, le gestionnaire de bases de données de l’environnement de développement offre maintenant la possibilité de stocker la structure d’une base de données dans le projet. Cette structure est ensuite utilisée à l’exécution pour créer automatiquement de nouvelles bases de données à l’identique, par l’intermédiaire de la méthode Connections.Create().

Composant éditeur de texte

L’éditeur de texte avec coloration syntaxique a été complètement récrit en Gambas. Il est implémenté dans le nouveau composant gb.form.editor. Cet éditeur offre toutes les fonctionnalités de l’ancien, et apporte les nouveautés suivantes :

  • barre de défilement avec prévisualisation du texte ;
  • complétion automatique des parenthèses, des crochets et des séparateurs de chaînes ;
  • plus de colorations syntaxiques ;
  • passage à la ligne automatique ;
  • défilement fluide ;
  • mise en évidence de la structure de contrôle courante ;
  • mise en surbrillance de la chaîne de recherche courante.

Et comme l’éditeur est écrit en Gambas, il est possible de l’utiliser dans des applications GTK+.

Nouvel éditeur de texte avec coloration syntaxique

Composant émulateur de terminal

Le nouveau composant gb.form.terminal implémente un contrôle émulateur de terminal compatible VT-100 complet, intégralement écrit en Gambas. Il permet enfin à l’environnement de développement d’afficher la sortie du projet en cours dans un vrai terminal.

Exemple de fonctionnement du contrôle TerminalView

Accès aux cartes

gb.map est un nouveau composant qui permet l’affichage de cartes au format tuile, telles que OpenStreetMap, Google, Microsoft Earth et autres.

Le composant fournit une classe Map représentant la carte à afficher : elle est capable de superposer un nombre arbitraire de calques provenant de serveurs de tuiles différents, ainsi que des calques affichant des formes vectorielles. Il fournit aussi un contrôle MapView qui se charge d’afficher la carte et qui permet d’interagir avec via la souris. Les transformations entre les différents systèmes de projection et de coordonnées sont gérés par l’outil cs2cs du projet Proj.

Exemple :

────────────────────────────────────────────────────────────────────────────────────────
Public Sub Form_Open()

  MapView1.Map.AddTile("OpenStreetMap", "http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png", Null).Copyright ="© OpenStreetMap contributors"

  ' Centrer sur Paris
  MapView1.Map.Center = MapPoint(48.866667, 2.333333)
  MapView1.Map.Zoom = 5

End
────────────────────────────────────────────────────────────────────────────────────────

Exemple de contrôle MapView

Composants d’interfaces graphiques

Toolkits graphiques

Gambas prend toujours en charge les toolkits graphiques Qt et GTK+, et offre une API identique pour les deux composants, ce qui permet à une application graphique d’utiliser indifféremment l’un ou l’autre toolkit, voire de décider lequel utiliser en fonction du bureau courant. Un nouveau composant gb.qt5 prend en charge la bibliothèque Qt 5, tandis qu’un nouveau composant gb.gtk3 gère la bibliothèque GTK+ 3. Il y a donc maintenant quatre composants d’interface graphique qui ont tous la même interface.

Les autres modifications principales sont les suivantes :

  • l’API de dessin standard est maintenant la classe Paint, qui implémente un modèle similaire à Cairo ; des fonctions de tracé de texte avec ombres ont été ajoutées, ainsi que quelques fonctions de dessin utilitaires ;
  • les fenêtres avec composante alpha sont maintenant prises en charge ;
  • l’ancienne API de dessin GTK+ 2 a été abandonnée et Cairo est utilisé partout dans les composants GTK ;
  • les sessions du bureau sont maintenant gérées, la propriété Application.Restart permet de définir la commande à exécuter par le gestionnaire de sessions pour rétablir l’application à l’ouverture du bureau ;
  • la gestion du multi‐écran s’est amélioré (par exemple, les boîtes de dialogues doivent apparaître et se centrer dans l’écran de leur fenêtre parente).

Coup de gueule no 2

Chaque nouvelle version mineure de GTK+ 3 octroyait le divin plaisir de voir une partie de la bibliothèque ne plus fonctionner. À tel point que certains m’ont suggéré de ne plus tenter de la prendre en charge dans Gambas.

Je crois que GTK+ 3 est la pire bibliothèque que j’ai jamais dû utiliser, en termes d’absence de rétro‐compatibilité

Ce que j’espère : que GTK+ 3 était en réalité une version bêta permanente de GTK+ 4, et que tout ira bien à l’avenir.

Réécriture de contrôles en Gambas

De nombreux contrôles natifs ont été réécrits en Gambas, et fonctionnent donc de manière identique avec Qt ou GTK+. Ils sont implémentés dans le nouveau composant gb.gui.base, qui sert de base pour tout le code écrit en Gambas commun à tous les toolkits graphiques.

Grâce à cette réécriture et cette mise en commun poussée, il a été possible d’implémenter les fonctionnalités suivantes : les vues avec défilement affichent maintenant des ombres intérieures, et supportent automatiquement un défilement fluide.

Ajout de nombreux nouveaux contrôles

  • ColorPalette : un sélecteur de couleurs choisies parmi une palette ;
  • DirBox : un champ texte couplé à une sélection de répertoire ;
  • DocumentView : un contrôle permettant de visualiser tout type de document ;
  • FileProperties : un contrôle qui affiche les propriétés d’un fichier et la taille des répertoires ; taille qu’il calcule dans une tâche d’arrière‐plan ;
  • FontBox : un champ texte couplé à une sélection de police ;
  • ImageView : un contrôle permettant de visualiser une image à différents niveaux de zoom ;
  • ListEditor : un contrôle permettant d’éditer et de réordonner une liste d’éléments ;
  • MessageView : un panneau d’affichage de messages qui apparaît ou disparaît automatiquement ;
  • SliderBox : le regroupement d’un Slider et d’une SpinBox, similaire à ce qui existe dans GIMP ;
  • Spinner : l’affichage d’une animation d’attente sous forme de traits en rotation ;
  • Spring : un contrôle « ressort » qui est l’équivalent d’un Panel dont la propriété Expand vaut True ;
  • SwitchButton : un bouton On/Off.

Gestion de la barre d’icônes du bureau

La gestion de la barre d’icônes a été revue. Désormais, si une barre d’icônes prenant en charge le protocole DBus de freedesktop.org est détectée, ce protocole est automatiquement utilisé par l’intermédiaire du composant gb.dbus.trayicon. Autrement, et pourvu que cela soit encore géré par le bureau courant, c’est l’ancien protocole X11 qui est utilisé.

Coup de gueule no 3

Les développeurs de KDE, GNOME (et Unity) ont réussi l’exploit de se mettre d’accord sur un protocole DBus de barre d’icônes système, et de l’implémenter chacun de manière incompatible.

Par conséquent, la gestion des icônes par DBus ne fonctionne intégralement qu’avec le bureau KDE. Pour tout autre bureau, la gestion du protocole est aléatoire, certaines choses fonctionnant et d’autres non.

Jeux d’icônes intégrés

Le composant gb.form.stock fournit deux jeux d’icônes complets pour Gambas : un en couleur et un monochrome. Ils sont composés d’images PNG de 32 × 32 pixels, qui sont ensuite automatiquement étirées en fonction des besoins. Ces deux jeux d’icônes permettent d’écrire des applications graphiques qui ne dépendent pas du jeu d’icônes standard du bureau.

Jeux d’icônes intégrés

Composants multimédias

Prise en charge de GStreamer

Le composant gb.media est maintenant basé sur GStreamer 1.0. Sa stabilité a été grandement améliorée, même si tout n’est pas parfait, à cause, entre autres, de la grande fragilité de l’API de GStreamer.

Les fonctionnalités suivantes ont été ajoutées :

  • la prise en charge des « capsfilter », c’est‐à‐dire des filtres de formats multimédias ;
  • l’interception des messages émis par les « pipelines » GStreamer ;
  • la capture de la trame vidéo en cours de traitement ;
  • la capture de la dernière image émise par un « pipeline » ;
  • la possibilité d’enchaîner deux flux multimédia sans coupure ;

D’autre part, un nouveau composant gb.media.form fournit un lecteur multimédia simple sous forme de contrôle graphique.

Prise en charge des scanneurs

gb.scanner est un nouveau composant qui est principalement un « wrapper » du programme scanimage fourni par le projet SANE.

L’acquisition d’une image s’effectue de la manière suivante :

────────────────────────────────────────────────────────────────────────────────────────
Dim hImg as Image
hImg = Scanners["hpaio:/net/HP_LaserJet_MFP_M426fdn?ip=192.168.1.25"].Scan()
────────────────────────────────────────────────────────────────────────────────────────

Toutes les options disponibles dans scanimage sont accessibles via la propriété Option de chaque objet Scanner. La possibilité de scanner plusieurs pages est offerte en mode asynchrone.

Composants réseau

En plus des nombreuses corrections de bogues apportées au composant réseau de base gb.net, les améliorations suivantes ont été apportées :

  • le composant gb.net.smtp, qui gère le protocole SMTP, a été entièrement réécrit en Gambas ; il est beaucoup plus fiable, et il gère maintenant les authentifications PLAIN et CRAM-MD5, ainsi que SSL et TLS ;
  • le composant gb.net.curl gère maintenant le procole ftps://. Il dispose d’une classe HttpForm pour facilement soumettre des formulaires HTTP, et d’une classe DownloadManager pour gérer des téléchargements multiples de manières asynchrone ;
  • gb.web.feed est un nouveau composant pour gérer les flux RSS ;
  • gb.httpd est un nouveau composant qui implémente un serveur HTTP embarqué simplifié, il est utilisé par l’environnement de développement pour déboguer les applications Web réalisées avec les composants gb.web ou gb.web.form.

Arithmétique multi‐précision

Le nouveau composant gb.gmp apporte à Gambas la possibilité de manipuler des nombres entiers et des nombres rationnels avec une précision arbitraire. Il est basé sur la bibliothèque GNU d’arithmétique multi‐précision.

Exemple :

────────────────────────────────────────────────────────────────────────────────────────
' Série convergente vers ℯ

Dim A, B As Rational
Dim I As Integer

A = 0
B = 1
For I = 0 To 17
  A += B / BigInt.Fact(I)
  Print A; Space$(30 - Len(Str(A)));; ":";; CStr(CFloat(A))
Next
────────────────────────────────────────────────────────────────────────────────────────
1                              : 1
2                              : 2
5/2                            : 2.5
8/3                            : 2.66666666666667
65/24                          : 2.70833333333333
163/60                         : 2.71666666666667
1957/720                       : 2.71805555555556
685/252                        : 2.71825396825397
...
7437374403113/2736057139200    : 2.71828182845905
────────────────────────────────────────────────────────────────────────────────────────

Composants utilitaires

Deux composants utilitaires ont été ajoutés.

Le premier, gb.util, regroupe des méthodes et des extensions pratiques de l’interpréteur :

  • lecture et décodage de fichiers CSV ;
  • conversion de dates au format UNIX ou RFC 822 ;
  • calcul du jour de Pâques ;
  • fonctions de création, déplacement et suppression de répertoires « intelligentes » ;
  • distance de Damerau‐Levenshtein entre deux chaînes de caractères ;
  • extraction du texte contenu dans un morceau de HTML ;
  • suppression des signes diacritiques ;
  • conversion d’une chaîne en expression phonétique (seul le Français étant implémenté).

Le second, gb.util.web, regroupe des méthodes indispensables à la programmation Web :

  • encodage vers JavaScript ;
  • encodage et décodage de flux JSON ;
  • manipulation d’URI.

Autres nouveaux composants

  • gb.args est un nouveau composant qui sert à analyser les arguments passés en ligne de commande à partir de leur description ;
  • gb.clipper est un nouveau composant basé sur la bibliothèque Clipper ;
  • le composant gb.data implémente maintenant les tas, les arbres radix et une interface de manipulation de graphes ;
  • gb.memcached est un nouveau composant qui implémente un client pour memcached ;
  • gb.openal est un nouveau composant basé sur la bibliothèque audio 3D OpenAL ;
  • gb.openssl est un nouveau composant qui offre une interface aux fonctions cryptographiques de la bibliothèque libcrypto du projet OpenSSL ;
  • gb.inotify est un nouveau composant qui permet de superviser les fichiers du système ; il se base sur l’interface inotify de Linux ;
  • gb.markdown est un nouveau composant qui implémente la gestion de la syntaxe Markdown, sous une forme légèrement différente de l’originale ;
  • le composant gb.report a été remplacé par le nouveau composant gb.report2, qui en est une amélioration ;
  • la bibliothèque SDL2 est maintenant prise en charge grâce aux nouveaux composants gb.sdl2 et gb.sdl2.audio ;
  • ennfin, gb.term est un nouveau composant permettant de manipuler les terminaux UNIX, avec une interface très proche de celle offerte par le système d’exploitation.

Améliorations du langage

Nouvelles syntaxes

  • If...Then...Else... peut maintenant s’écrire sur une seule ligne ;
  • Match est un nouvel opérateur qui implémente une comparaison par correspondance de modèle (« pattern matching ») en utilisant la bibliothèque gb.pcre ;
  • .[xxx] et !xxx sont deux nouveaux raccourcis pour les opérateurs de tableaux, à utiliser au sein d’une structure With...End With ;
  • le symbole ... peut‐être utilisé pour passer tous les arguments optionnels d’une fonction à une autre fonction ;
  • les constantes numériques peuvent être écrites en octal, sous la forme &Oxxx ;
  • les variables locales peuvent maintenant être déclarées n’importe où dans le corps d’une fonction, mais leur portée reste toujours celle de la fonction courante ;
  • il est possible de déclarer les variables de boucles directement au début des structures For et For Each ainsi : For I As Integer = 1 To 100 ;
  • il est maintenant possible d’accéder au contenu des chaînes de caractères avec l’opérateur de tableau ;
  • enfin, le compilateur émet un avertissement pour chaque variable locale ou globale qui n’a pas été initialisée.

Nouvelles fonctions

  • IsMissing() permet de tester l’absence d’un argument optionnel ;
  • Rand() retourne un nombre pseudo‐aléatoire entier ;
  • System.Log() permet d’écrire dans le journal système (c’est une interface à l’API syslog de la libc) ;
  • Url() et FromUrl() servent respectivement à encoder et décoder les URL ;
  • Move ... Kill ... permet de déplacer un fichier tout en supprimant la destination de manière atomique, cette fonctionnalité est indispensable dès lors que deux processus sont susceptibles d’écrire le même fichier en même temps ;
  • Assert permet d’insérer des assertions dans le code qui stoppent le programme en cas d’échec, ces assertions ne sont pas compilées lorsque vous générez un fichier exécutable.

Correction des fonctions de gestion du temps

La gestion des fonctions de date et heure est désormais cohérente. Il y a maintenant une claire séparation entre les fonctions qui interprètent une date en temps local et celles qui l’interprètent en temps universel (UTC). En particulier, les fonctions CStr() et CDate() sont maintenant réciproques, comme elles auraient dû l’être depuis le début, au prix d’une rétro‐incompatibilité.

Optimisations

  • la fonction Split() est plus rapide ;
  • les accès aux tableaux et aux collections sont plus rapides, le benchmark sort est 25 % plus rapide ;
  • la plupart des méthodes Find() et Exist() des tableaux sont plus rapides ;
  • les instructions Input et Line Input sont plus rapides ;
  • les conversion vers le type Boolean, et vers ou depuis le type Variant sont plus rapides ;
  • les opérateurs d’inégalité sont plus rapides ;
  • les fonctions Dir() et RDir() sont maintenant plus rapides de 20 à 40 %, grâce à l’utilisation de fstatat(), et au moins grand nombre d’appels à stat() que des suppositions intelligentes sur le nombre de liens durs vers le répertoire courant rendent facultatifs ;
  • la recherche au sein d’une chaîne de caractères est maintenant environ quatre fois plus rapide en moyenne ;
  • les boucles utilisant des variables Integer sont 5 % plus rapides.

Tests de performances

Voici les résultats d’une série de six « benchmarks » consistant en six programmes écrits en Gambas, en Perl et en Python, dont les sources sont bien évidemment disponibles ici.

Les versions des différents langages utilisés sont :

  • Python 2.7.15rc1 ;
  • Perl 5.26.1 ;
  • Gambas 3.11.90 (version de développement du 2 novembre 2018).

Ils ont été exécutés sur un système Ubuntu 18.04 avec le noyau Linux 4.15.0-38-generic. Les temps d’exécution sont donnés en secondes.

───────── ───────── ───────── ──────────── ────────────────────────
Python Perl Gambas Gambas + JIT Gambas + JIT
(exécution uniquement)
─────────── ───────── ───────── ───────── ──────────── ────────────────────────
sort 3,93 6,36 4,76 0,84 0,25
polynom 9,94 13,40 8,04 0,84 0,75
primes 6,29 7,65 2,99 0,77 0,61
nbody 4,54 4,55 4,03 0,68 0,29
mandelbrot 5,34 4,24 3,06 0,22 0,10
string 8,94 1,81 1,41 1,49 1,40
─────────── ───────── ───────── ───────── ──────────── ────────────────────────

Par rapport aux tests précédents, on peut constater qu’il y a eu un gros effort d’optimisation sur les versions récentes de Perl et de Python. Malgré tout, Gambas reste en tête dans tous les tests, mis à part sort (il s’agit d’un tri à bulle sur un tableau d’entiers). On peut constater aussi que l’intérêt du compilateur « à la volée » réside dans l’optimisation des calculs, et qu’il n’apporte aucun gain significatif dans le traitement des chaînes de caractères.

Conclusion

Beaucoup de travail a été abattu au cours de ces six dernières années, mais il reste toujours de nombreuses choses à faire :

  • même si Wayland n’est toujours pas prêt (contrairement à ce qui avait été prédit dans la dernière dépêche), il faudrait peut‐être commencer à penser à éventuellement l’envisager ;
  • puisque Gambas prend en charge les architectures ARM, ce serait bien d’arriver à le faire fonctionner sur Android ; rien n’a bougé depuis la dernière dépêche ;
  • il y a beaucoup de composants qui sont mal voire pas du tout documentés dans le wiki ;
  • le composant gb.web.form mériterait une réflexion poussée sur la meilleure méthode pour implémenter les applications Web en Gambas ;
  • il serait sans doute intéressant d’implémenter une syntaxe différente du BASIC dans le compilateur.

Autrement, en dépit de quelques coups de gueule, associés en pratique à de nombreuses heures perdues à contourner les délires des autres les problèmes rencontrés :-), l’évolution du langage est plutôt satisfaisante. Les gens qui l’utilisent semblent être rarement déçus. Espérons donc, si vous tentez le pas, que vous l’apprécierez vous aussi.

Bonne année à tous les utilisateurs et développeurs de logiciels libres !

Aller plus loin

  • # Bonne année 2019

    Posté par  . Évalué à 8.

    Une année qui commence avec (des) Gambas au menu ne peut être qu'une excellente année. J'utilise Gambas presque au quotidien et le moins que l'on puisse dire est que c'est top. Développement rapide et fiable d'applications.

    Ce que j'aime : tout
    Ce qui me manque : un composant Jack et MIDI dédié.

    Merci !

    • [^] # Re: Bonne année 2019

      Posté par  (site web personnel) . Évalué à 4.

      Mais il ferait quoi, concrètement, ce composant dédié ?

      • [^] # Re: Bonne année 2019

        Posté par  . Évalué à 3. Dernière modification le 01 janvier 2019 à 22:27.

        Alors là, typiquement pour le midi, il permettrait de construire un programme pour envoyer des sysex comme :
        amidi -p hw:2,0,3 -S "F0 00 20 33 00 00 01 07 0F F0"

        Ce qui me permettrait de piloter mes synthétiseurs.
        Je me suis cassé la tête dessus, mais je n'ai abouti à rien.
        Quand à jack, toujours dans le domaine musical, et bien ce serait pour envoyer le son en temps réel directement depuis les api jack.
        Pour envoyer un fichier midi contenant un morceau de musique, je crois que c'est déjà possible.

        • [^] # Re: Bonne année 2019

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 02 janvier 2019 à 03:07.

          Je ne comprends pas : si tu peux faire ce que dont tu as besoin en ligne de commande, tu peux le faire, faute de mieux, depuis Gambas en exécutant la même ligne de commande avec l'instruction "Shell".

          Ou alors tu veux parler d'un composant qui permettrait de parler MIDI sans devoir déterminer les octets à envoyer soi-même ?

          Et quel son veux-tu envoyer vers Jack ? Le composant GStreamer ne permet-il pas de faire ce que tu veux ?

          • [^] # Re: Bonne année 2019

            Posté par  . Évalué à 4.

            Tout a fait. Pour l'heure c'est ainsi que je procède concernant le MIDI.
            Mais bon je me disait qu'un composant dédié serait mieux.
            D'autre part je pense que tu as raison. J'avoue que Gambas + tous les programmes en terminal, c'est juste de la balle. Je n'aime pas non plus ré-inventer la roue.
            Actuellement comme je fais de l'édition, en utilisant latex, j'utlise Gambas pour tout ce qui est réarrangement des pdf (pdfjam, pdftk), reconnaissance de caractère (tesseract)… imagemagick, impression in-quarto etc… Ce qui me permet d'automatiser pas mal de travail.
            Idem pour les besoins du réseau en entreprise, ou la compilation et conversion de video avec ffmpeg.
            La dernière chose faite en gambas est un affichage d'annonce sur écran (47 pouces ou plus grand) en automatisant un rendu web (html, javascript). Auparavent j'utilisait Firefox. Mais voilà, avec tous les changement de version de FF, plus moyen de le lancer directement en plein écran. C'est bête mais il fallait envisager une autre solution. Un petit coup de gb.qt5.webkit et 5 lignes de code plus tard, j'ai exactement ce que je souhaite : une appli de rendu web dédiée.
            Ça c'est vraiment la force de Gambas et cela apporte un gain de temps considérable.
            Au final, en écrivant ces lignes, je me rend compte que mes questions au sujet du MIDI et de qjack sont sans fondements. Je me giffle et je reviens.
            Concernant le language, j'aime c'est tout. J'ai commencé comme toi en BASIC avec à l'époque QBasic. Entre le Qbasic et le fortran le choix était restreint sur ces vieilles machines.

  • # Bonne année à Gambas, son concepteur et ses utilisateurs.

    Posté par  . Évalué à 5.

    Et bien, à part bonne année, je n'ai rien à ajouter.
    Enfin si, un portage sur WinXX que je puisse l'utiliser au boulot.

  • # que d'évolution !!!

    Posté par  . Évalué à 4. Dernière modification le 01 janvier 2019 à 17:20.

    Bonne anée à tous
    que d'évolution depuis la version 0.1 que j'utilisais pour adapter mes prog vb6 sous linux !!!

    Un grand bravo aux devs

  • # Pourquoi en basic?

    Posté par  . Évalué à 3. Dernière modification le 01 janvier 2019 à 17:42.

    J'admire ton project, mais je voudrais savoir pourquoi le basic ?

    • [^] # Re: Pourquoi en basic?

      Posté par  (site web personnel) . Évalué à 10.

      Je vois plusieurs raisons :

      1) J'ai appris la programmation sur un Hector Lambda puis sur Amstrad, donc en faisant du BASIC (et de l'assembleur Z80).

      2) Au début de mon travail, j'ai été obligé de travailler avec Visual Basic™ sous Windows XP (le premier était encore plus bugué que le second). J'ai aussi vu des jeunes stagiaires ne connaissant que Windows s'échanger des disquettes de TurboPascal piratées pour pouvoir programmer. Je me suis donc dit qu'il faudrait un langage sous Linux, dans le même principe que VB mais sans les bugs, et qui soit le plus facile possible d'utilisation tout en ne faisant pas de concession au niveau de la rigueur et de la puissance.

      3) Les ordinateurs de ma génération étaient fournis avec un Basic, un manuel souvent bien fait pédagogiquement parlant, et rien d'autre. D'où l'équation Basic = apprentissage de la programmation.

      4) Je suis plus soucieux du fond que de la forme. Autrement dit la syntaxe d'un langage n'est pas ce qui me gène le plus.

      Après je comprends tout à fait qu'on puisse être allergique à la syntaxe du BASIC. Mais, comme avec la plateforme .Net, il est tout à fait possible d'écrire un second compilateur pour Gambas qui traduirait une syntaxe complètement différente.

      J'aimerais bien d'ailleurs avoir une syntaxe du style C/Java/JavaScript. Mais cela ne se programme pas en cinq minutes…

      • [^] # Re: Pourquoi en basic?

        Posté par  . Évalué à 3.

        Au boulot les contraintes font que je ne fais que du PowerShell. Alors forcément je me fais insulter dès que je parle de PowerShell que ce soit au boulot ou ici même dans quelques secondes :D mais j'avoue que j'aime bien ce langage. Un langage de script mais orienté objet.
        Donc du coup en lisant cette dépêche j'ai l'impression (mais je peux me tromper) que je pourrai retrouver en Gambas ce que je trouve sous PowerShell ?

        • [^] # Re: Pourquoi en basic?

          Posté par  (site web personnel) . Évalué à 5.

          Je ne connais pas PowerShell, mais j'imagine que tu parle d'écrire des fichiers scripts en Gambas.

          C'est possible. Il faut juste que la première ligne de ton fichier texte soit #!/usr/bin/env gbs3, et que le fichier texte soit exécutable. Tout est expliqué ici.

          Les fichiers scripts sont transformés à la volée en projet autonome, puis compilés, et enfin exécutés. Le résultat de la compilation est mis en cache afin que les prochaines exécutions ne nécessitent plus de compilation.

      • [^] # Re: Pourquoi en basic?

        Posté par  . Évalué à 1.

        Quand j'ai vu la présentation j'ai pensé à en particulier la dernière version, Visual Basic 6.

        Je n'ai pas encore vu un environnement de dév de la sorte sous Linux (environnement tout intégré, avec GUI, etc.), c'est chose faite, bravo. :)

        C'est encore utilisé en entreprise, et je pense que ça va l'être jusqu'à ce qu'il ne soit plus possible d'installer l'IDE sur un OS pris en charge par Microsoft. (C'est déjà le cas sur les Windows Server en 64 bits). Beaucoup ne souhaitent pas s'en séparer.

        Peut-être qu'il y aura de la demande sous Windows si une version y sort. Le plus difficile sera la migration du code basé sur des bibliothèques COM comme ADO ou DAO, principalement à cause du côté « spaghetti » que je sens typique du code legacy pondu avec. :D

        • [^] # Re: Pourquoi en basic?

          Posté par  (site web personnel, Mastodon) . Évalué à -1.

          comme environnement intégré similaire, il existe livecode inspiré d'HyperCard et multiplateforme

          • [^] # Re: Pourquoi en basic?

            Posté par  . Évalué à 1.

            Je comparerais plutôt livecode a un windev avec un code assez limité. Il fait parti des meta language. Ces outils pratiques dans un sens ont des limites bien précise eux aussi quand on s'attaque au vrai multiplateforme. Gambas certes a une IDE de type RAD. Mais est avant tout un interpréteur indépendant supportant un langage complet.

        • [^] # Re: Pourquoi en basic?

          Posté par  . Évalué à 3.

          Je n'ai pas encore vu un environnement de dév de la sorte sous Linux (environnement tout intégré, avec GUI, etc.), c'est chose faite, bravo. :)

          Il y a également Lazarus (Freepascal) qui est pas mal du tout en tout intégré. J'attends que Gambas 3.12 soit dans ma debian pour jouer un peu avec, par contre l'absence de support de windows va m'empêcher de le mettre en avant auprès de connaissances qui n'ont pas accès à mieux aujourd'hui que Excel/Access et les macros :/

      • [^] # Re: Pourquoi en basic?

        Posté par  . Évalué à 3. Dernière modification le 05 janvier 2019 à 23:09.

        Je ne vois pas vraiment pourquoi on pourrait être allergique au BASIC. A cause du nom ? qui fait basique = guignol en apprentissage ?
        En programmation la logique du programmeur fait tout.
        Je sais encore pourquoi je hais le C++… et son héritage multiple, et le java et son héritage pas multiple mais ses bibliothèque mouvantes.
        Ce fut douloureux jusqu'à je comprenne enfin ce que signifiait le mot "concept".
        Du coup "language efficace" j'aime assez.
        Finalement bas niveau comme le C c'est top et haut niveau comme basic c'est top.

        • [^] # Re: Pourquoi en basic?

          Posté par  . Évalué à 2. Dernière modification le 06 janvier 2019 à 10:07.

          Je ne vois pas vraiment pourquoi on pourrait être allergique au BASIC.

          Perso je préfère avoir beaucoup moins à écrire (par exemple pour ouvrir et fermer un bloc de code ou déclarer une méthode, ou encore déclarer une variable), tout en ayant les mêmes avantages (haut-niveau, pas de gestion bas-niveau de la mémoire à se farcir, etc.).

          Python, Ruby, C#, Java et d'autres remplissent ces critères.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Une bonne année aussi

    Posté par  . Évalué à 8.

    Je profite de cette tribune pour faire mon méa culpa concernant le manque de documentation sur certains composants :-).

    Les composants les plus mal documentés étant parmis les miens, mais je vais arranger ça.

    Voila !

    Sinon une des grandes forces de gambas est dans le soin apporté a la cohérence des interfaces. Ainsi mixer plusieurs composants parfois me fais un peu penser aux pipes.

    Un des objets vraiment sympa pour ça est l'objet image que l'on peut simplement acquérir a partir de plusieurs sources différentes et rediriger vers de nombreux types d'afficheurs assez simplement. D'autres objets comme DrawingArea (le caneva sauce gambas) ou bien gridview sont des briques tellement ouvertes qu'elle sont souvent à la base de nombreux autres widgets (IconView, ListView, Editeur, etc).

    Cette idée de classes réutilisable est vraiment à la base de tout et rend l'apprentissage des différents composants très facile.

    Merci à tous pour cette belle réalisation.

    Je souhaite a Gambas encore de nombreuses années de belles choses.

    Mélange de genres gb.report + gb.map

  • # Compilateur « à la volée »

    Posté par  . Évalué à 5.

    Ce compilateur [« à la volée »] traduit le « bytecode » Gambas en langage C pendant l'exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.

    Cette méthode de compilation a le désavantage d'être plus lente que la génération de code classique. Mais elle a le gros avantage de ne pas dépendre de l'API souvent peu fiable offerte par chaque compilateur C.

    J'essaie de comprendre ce passage. Qu'est-ce qui est peu fiable dans l'API et en quoi cette méthode s'en affranchit-elle ?

    • [^] # Re: Compilateur « à la volée »

      Posté par  (site web personnel) . Évalué à 10.

      C'est d'abord en rapport avec le coup de gueule n°1 : Un développeur, Emil Lenngren, avait écrit un compilateur just-in-time pour Gambas basé sur LLVM. Or, du jour au lendemain, c'est-à-dire lors du passage de LLVM 3.5 à LLVM 3.6, plus rien ne compilait, car LLVM avait décidé de changer leur API.

      Si les librairies dont on dépend peuvent rendre votre programme complètement inutilisable lors d'un changement de version mineure, alors on bâtit sur du sable.

      Du jour au lendemain, les heures passées à programmer le composant doivent être jetées à la poubelle.

      J'ai donc ensuite regardé du côté de gcc. Malheureusement, l'API de gcc pour écrire un compilateur JIT est toujours en alpha, et même si j'avais plus confiance, je me méfiais quand même.

      En traduisant le bytecode Gambas en code C, on ne dépend plus que de la norme du langage. Et cette norme (ISO C99 en l'occurrence) ne peut pas changer du jour au lendemain sans prévenir, au gré des volontés de développeurs qui ne respectent pas le principe de rétro-compatibilité.

      Dans le genre, GTK+ n'est pas mal non plus. A chaque nouvelle version mineure de GTK+3, le développeur est obligé de faire des prières et d'espérer que son programme sera toujours fonctionnel voire compilable sans devoir en récrire des parties importantes.

      En conclusion, et même si j'ai du casser la rétro-compatibilité de Gambas deux ou trois fois (pour corriger des bugs), je trouve cette façon de faire absolument honteuse.

      • [^] # Re: Compilateur « à la volée »

        Posté par  . Évalué à 1.

        Merci, à présent je comprends mieux.

        Par contre j'ai l'impression que tu regroupes trois problèmes différents :
        - Un compilo (LLVM) qui casse la rétro-compatibilité de son API en maintenant le numéro de version majeure (pas bien)
        - Un compilo (GCC/JIT) qui est en alpha (bien, ils préviennent que ça peut casser)
        - Une bibliothèque (GTK+) qui casse la rétro-compatibilité en maintenant le numéro de version majeure (pas bien)

        En effet, dans ton message il est dit :

        […] l'API souvent peu fiable offerte par chaque compilateur C.

        Le seul concerné des trois est LLVM.

        GTK+ (GTK+ 3 en fait) n'est pas offert par GCC il me semble. Et s'ils font nawak, convertir en C ne va pas changer grand chose j'imagine.

        (Je précise que je n'ai que peu voire pas d'expérience dans le sujet, donc les corrections sont les bienvenus.)

  • # je regarde souvent ton évolution par curiosité....

    Posté par  (site web personnel) . Évalué à 3.

    Bravos , beaucoup de travail…. on est très loin du basic à papa ;), ton constant effort devrait en faire réfléchir beaucoup.

    JPL @bientôt

    • [^] # Re: je regarde souvent ton évolution par curiosité....

      Posté par  . Évalué à 1.

      Effectivement tout ce qui me gonflait en MS Basic, n'existe plus dans Gambas, et sur le coup je me souviens, en travaillant en visual basic avec opengl ou encore avec l'api (en son temps) de la carte son DSP2416 de Yamaha, le problème du calcul en virgule flottante était un truc ahurissant.
      Il fallait déclarer une exception avec un resume pour qu'enfin le calcul soit correct sans erreur d'exception … après 20 boucles… Enfin …on était des pionniers…soit !
      Quand au basic à "papa", maintenant faut arrêter :-) et on peut sans rougir.

  • # A quand un Gambas sur vieille console?

    Posté par  (site web personnel) . Évalué à 2.

    J'ai vu que certaines vieilles consoles sont programmables en basic. A quand un portage de Gambas sur ces machines ? :-)

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Concernant le compilateur JIT

    Posté par  (site web personnel) . Évalué à 4.

    Dans la dépêche il est écrit :

    Ce compilateur traduit le « bytecode » Gambas en langage C pendant l’exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.

    Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.

    Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.

    • [^] # Re: Concernant le compilateur JIT

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 janvier 2019 à 22:17.

      Non, je n'y ai pas pensé. Je connaissais le compilateur, mais je ne savais pas qu'il avait une librairie.

      On peut déjà essayer d'utiliser tcc à la place de gcc ou clang pour voir la différence de rapidité à l'exécution. Je vais voir ce que ça donne…

      Notez que c'est un des avantages d'utiliser un compilateur externe : on peut passer de gcc à clang ou à autre chose au gré des envies.

      • [^] # Re: Concernant le compilateur JIT

        Posté par  (site web personnel) . Évalué à 2.

        Oui, utiliser tcc à la place de gcc permettrait déjà de voir si le code C produit est bien compatible (je ne sais pas si vous utilisez des spécificités de la norme C11 ; il me semble que tcc n'est compatible qu'avec la norme C99, qui est quand même 12 ans plus vieille). Il faudrait aussi regarder si tcc supporte toutes les plateformes que Gambas supporte.
        Et je serais aussi curieux de voir le résultat en terme de performance (sachant que tcc sera plus rapide à compiler, mais produira du code moins rapide ; c'est vraiment ce qui se rapproche le plus d'une compilation JIT).

        Est-ce que le fait de pouvoir choisir le compilateur est vraiment primordial ? (c'est une vraie question)
        Je trouve que c'est plus "propre" d'avoir un compilateur qui contienne tout ce dont il a besoin, plutôt que de passer par des programmes externe. On pourrait dire qu'utiliser une librairie externe versus un programme externe ne change pas grand-chose ; mais très concrètement je pense qu'une installation de Gambas peut embarquer des librairies (c'est assez commun), mais plus difficilement embarquer gcc ou clang.

        • [^] # Re: Concernant le compilateur JIT

          Posté par  (site web personnel) . Évalué à 1.

          Le support de tcc sera ajouté dans la version 3.12.2. Comme attendu, le temps de compilation est négligeable, mais le résultat est sensiblement plus lent.

          D'ailleurs, pour ce qui de gcc et clang, gcc est plus lent à compiler, mais le code généré est plus performant.

          Je publierai un tableau de benchmark pour chaque compilateur avec les résultats chiffrés.

          • [^] # Re: Concernant le compilateur JIT

            Posté par  . Évalué à 2.

            Je présume que tu ne remet jamais en cause le résultat de la compilation ? (Hotspot dans la JVM compile en utilisant des hypothèses et il peut au court de la vie de l'application remettre en cause ses hypothèses) Si c'est le cas le temps de build est probablement négligeable sur les appli qui ne s'arrêtent pas immédiatement après avoir rendu un travail instantané (genre ls ou grep).

            • [^] # Re: Concernant le compilateur JIT

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 11 janvier 2019 à 18:33.

              A priori en Java toutes les méthodes sont destinées par défaut à être compilées en JIT, éventuellement en se basant sur des heuristiques pour prendre la décision (par exemple si une méthode est appelée au moins quatre fois. C'est juste un exemple, je n'en sais rien).

              Pour l'instant en Gambas, c'est uniquement explicite, rien n'est remis en cause (si c'est bien ça que tu voulais dire). Si l'utilisateur marque une fonction à compiler, elle sera compilée, même si ça ne sert à rien, et elle restera compilée jusqu'à la fin du programme.

          • [^] # Re: Concernant le compilateur JIT

            Posté par  (site web personnel) . Évalué à 1.

            Donc tu as testé, le code C produit est bien du C99 compatible avec TCC ? Cool.

            Pas de plan d'utiliser la librairie alors ?

            • [^] # Re: Concernant le compilateur JIT

              Posté par  (site web personnel) . Évalué à 1.

              Donc tu as testé, le code C produit est bien du C99 compatible avec TCC ? Cool.

              Oui, sauf que j'ai un cas ou tcc me compile un code qui fait un « segfault ». Mais je pense que c'est un problème avec les setjmp() / longjmp() qui peuvent facilement mettre un compilateur dans les choux.

              Pas de plan d'utiliser la librairie alors ?

              Non, je n'en vois pas trop l'utilité pour l'instant, le temps de compilation par tcc étant négligeable. Ou alors plus tard : on pourrait l'utiliser par défaut si aucun compilateur n'a été trouvé (par exemple).

              • [^] # Re: Concernant le compilateur JIT

                Posté par  (site web personnel) . Évalué à 1.

                Non, je n'en vois pas trop l'utilité pour l'instant, le temps de compilation par tcc étant négligeable. Ou alors plus tard : on pourrait l'utiliser par défaut si aucun compilateur n'a été trouvé (par exemple).

                Effectivement, c'est un bon cas d'usage.

  • # GTK+ / Les scanners

    Posté par  (site web personnel) . Évalué à 6.

    Quelques bonnes nouvelles:

    Les critiques concernant les problèmes de compatibilité dans GTK+ 3 ont été entendues par les développeurs de GTK+: « GTK+ 4.0 ne sera pas GTK+ 4 ».

    Pour le support des scanners, pour avoir un truc plus propre et multiplate-forme, je travaille actuellement sur une bibliothèque: Libinsane. Je ne suis plus très loin de sortir la version 1.0 (fin du mois j'espère).

  • # Commentaire supprimé

    Posté par  . Évalué à -1. Dernière modification le 09 janvier 2019 à 19:48.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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