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.
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 »
- Développement d’applications Web avec interface graphique
- Autres évolutions majeures
- Améliorations de l’environnement de développement intégré
- Accès aux bases de données
- Composant éditeur de texte
- Composant émulateur de terminal
- Accès aux cartes
- Composants d’interfaces graphiques
- Composants multimédias
- Composants réseau
- Arithmétique multi‐précision
- Composants utilitaires
- Autres nouveaux composants
- Améliorations du langage
- Tests de performances
- Conclusion
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 :
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 :
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.
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.
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.
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.
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.
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+.
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.
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
────────────────────────────────────────────────────────────────────────────────────────
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’unSlider
et d’uneSpinBox
, 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’unPanel
dont la propriétéExpand
vautTrue
; -
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.
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 procoleftps://
. Il dispose d’une classeHttpForm
pour facilement soumettre des formulaires HTTP, et d’une classeDownloadManager
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 composantsgb.web
ougb.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èquelibcrypto
du projet OpenSSL ; -
gb.inotify
est un nouveau composant qui permet de superviser les fichiers du système ; il se base sur l’interfaceinotify
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 composantgb.report2
, qui en est une amélioration ; - la bibliothèque SDL2 est maintenant prise en charge grâce aux nouveaux composants
gb.sdl2
etgb.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èquegb.pcre
; -
.[xxx]
et!xxx
sont deux nouveaux raccourcis pour les opérateurs de tableaux, à utiliser au sein d’une structureWith...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
etFor 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’APIsyslog
de lalibc
) ; -
Url()
etFromUrl()
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()
etExist()
des tableaux sont plus rapides ; - les instructions
Input
etLine Input
sont plus rapides ; - les conversion vers le type
Boolean
, et vers ou depuis le typeVariant
sont plus rapides ; - les opérateurs d’inégalité sont plus rapides ;
- les fonctions
Dir()
etRDir()
sont maintenant plus rapides de 20 à 40 %, grâce à l’utilisation defstatat()
, 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
- Le site Web de Gambas (479 clics)
- Le wiki de Gambas (147 clics)
- Gambas sur gitlab.com (154 clics)
# Bonne année 2019
Posté par tipic . É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 Benoît Minisini (site web personnel) . Évalué à 4.
Mais il ferait quoi, concrètement, ce composant dédié ?
[^] # Re: Bonne année 2019
Posté par tipic . É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 Benoît Minisini (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 tipic . É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 xavier philippon . É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.
[^] # Re: Bonne année à Gambas, son concepteur et ses utilisateurs.
Posté par Benoît Minisini (site web personnel) . Évalué à 9.
Il faudrait que quelqu'un se dévoue. :-) Ça devrait être faisable vu que des gens le font tourner sous Cygwin.
Personnellement, la dernière fois que j'ai touché à un Windows, c'était avec Windows XP. Je me suis enfui dès que j'ai pu, et je n'ai pas vraiment envie de réveiller ce traumatisme.
# que d'évolution !!!
Posté par exmachina . É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 Panhwein . É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 Benoît Minisini (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 ptit_poulet . É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 Benoît Minisini (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 HL . É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 Thierry Pasquier (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 Fabien Bodard . É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 Pinaraf . Évalué à 3.
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 tipic . É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 xcomcmdr . Évalué à 2. Dernière modification le 06 janvier 2019 à 10:07.
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 Fabien Bodard . É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.
# Compilateur « à la volée »
Posté par HL . Évalué à 5.
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 Benoît Minisini (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 HL . É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 :
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 jpllaroche (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 tipic . É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 devnewton 🍺 (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 Amaury Bouchard (site web personnel) . Évalué à 4.
Dans la dépêche il est écrit :
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 Benoît Minisini (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 degcc
ouclang
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 Amaury Bouchard (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 Benoît Minisini (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
etclang
,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 barmic . É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 Benoît Minisini (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 Amaury Bouchard (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 Benoît Minisini (site web personnel) . Évalué à 1.
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 lessetjmp()
/longjmp()
qui peuvent facilement mettre un compilateur dans les choux.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 Amaury Bouchard (site web personnel) . Évalué à 1.
Effectivement, c'est un bon cas d'usage.
# GTK+ / Les scanners
Posté par Jérôme Flesch (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).
[^] # Re: GTK+ / Les scanners
Posté par Benoît Minisini (site web personnel) . Évalué à 2.
J'ai lu l'article, cela ne me rassure pas plus que ça !
Sinon tous mes vœux de réussite pour ta bibliothèque. Son nom donne déjà envie de l'utiliser. :-)
# Commentaire supprimé
Posté par Selena . É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.