Benoît Minisini a écrit 49 commentaires

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).

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.

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. :-)

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.

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.

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.

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 ?

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.

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

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.

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…

Ou pire encore : "codeur".

Ou encore pire, à la François Hollande : "programmateur".

Je conseille fortement le second lien : en s'amusant

C'est bien la première fois que du javascript me fait hurler de rire. La plupart du temps ce langage me donne des envies de meurtre…

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

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

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

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

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

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

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

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

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

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

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

J'ignorais l'existence de ces sites…

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

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

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

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

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

Qu'est-ce qu'il faut faire pour faire tourner mes trois benchmarks avec pypy ?

Gambas est-il typé statiquement ou dynamiquement?

Ah ! Bonne question…

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

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

D'autre part nous avons :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coup de gueule n°2

Ce n'est pas un problème de dialogue entre la Xlib et le serveur X, donc j'imagine que XCB utilise les mêmes routines pour analyser le fichier…

Coup de gueule n°3

J'avais envoyé un mail à pkg-gambas-devel@lists.alioth.debian.org, mais je n'ai jamais eu de réponse. Ce n'était peut-être pas le bon moyen ?

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

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

Il faut savoir que je n'ai pas écrit le code Python (ni le code Perl). Je les ai récupérés sur Internet puis traduit en Gambas. Je ne connaissais pas assez Python ni Perl pour améliorer le code récupéré - même si je me posais des questions sur le range(0,n).

Au niveau JIT, je suis forcément moins motivé, parce que dès que j'ai besoin de vitesse, je ponds du C moi-même. Et puis je soupçonne le JIT d'être gourmand en mémoire, je ne sais pas pourquoi.

Par contre, je suis convaincu de pouvoir améliorer la vitesse de l'interpréteur en basant le bytecode sur des manipulations de registres plutôt que sur des manipulations de pile.

Sinon quelqu'un m'a dit aussi qu'il travaillait sur un émetteur de code LLVM pour Gambas, mais je n'ai pas plus de détails, et je ne sais pas si ça va donner quelque chose.

Si je mets de côté le fait que jamais je n'aurais pu développer mon application sous Windows (d'une part parce que le résultat aurait été trop lourd, et d'autre part parce que je préfère être chômeur que devoir redévelopper sous Windows un jour), je pense que le critère du déploiement est le meilleur atout des applications Web.

Je me souviens encore de programmes d'installation générés par VB qui fonctionnaient correctement sur un poste Windows 2000, et qui refusaient de se lancer sur le poste voisin identique (même os, même version, mêmes applications).

Bref, le déploiement sur les postes clients demande du temps et pose des problèmes techniques, voire même politiques au sein de grosses sociétés au service informatique centralisé, déporté, et apathique.

Avec l'application Web, ils peuvent passer de 50 à 500 utilisateurs sans qu'on ait à intervenir de notre côté (enfin si, il faudra peut-être booster un peu la vm).

Cela dit, pour être honnête, il faut quand même un an pour convaincre ces mêmes grosses sociétés qu'il faut autre chose qu'Internet Explorer 6 pour faire tourner notre application Web. « ...passer à une autre version oulala faut qu'on fasse des tests c'est tout ou rien vous n'y pensez pas quoi Mozilla non c'est trop dangereux vous aurez Internet Explorer 8 à la rigueur. » :-)

Je vois qu'il y a des exemples pour me contredire (cf. commentaires plus haut), mais quelle est la nature de ces projets ? Pourquoi est-ce qu'un outil comme Gambas a été retenu plutôt qu'une application RoR / PHP / JavaEE / GWT / etc... ?

Je vais parler de ce qui me concerne : RoR, je connais très mal; JavaEE, je connais mal; GWT, je ne connais pas du tout. PHP, par contre, je connais : berk. Pour moi c'est une horreur cosmique, comme l'ASP. Je ne supporte pas de mélanger le HTML et le code. Qui a dit "javascript" ?!

L'avantage de développer mon application Web sous Gambas, c'est :

1. Chaque serveur est virtualisé, donc un Linux en mode texte avec 512 Mo de RAM, ça le fait. 512 Mo qui sert surtout de cache disque, les accès disques étant ce qui ralentit le plus. J'admets que cet argument est valable quel que soit le langage.

2. La table de hachage et le traitement de chaînes de caractères (miam les conversions de casse en UTF-8) est ce qui consomme le plus de temps CPU (merci valgrind). Gambas a l'air assez doué là-dessus.

3. Nous sommes une petite boite, je suis quasiment le seul à développer et maintenir cette application. Gambas possède un IDE complet, il est interprété, il compile très rapidement, et l'application Web est compilée en un seul fichier. Le temps de développement, de maintenance et de déploiement (une copie de fichier en SFTP) sont réduits d'autant.

4. Lorsqu'il y a un bug dans Gambas qui impacte le projet, il est fatalement corrigé assez vite. J'ai utilisé dans le passé suffisamment d'outils de Microsoft archi buggés (Visual Basic m'entends-tu ?) pour apprécier de contrôler la chaîne de développement de A à Z. Regardez le bug sur les tables de hachage non "randomisées" : j'ai pu le corriger en 15 minutes (ça a pris un peu de temps car l'article sur linuxfr explique bien le problème, mais moins bien la solution). Pour les applications basées sur un langage où ce bug n'est pas corrigé, elles peuvent trembler...

5. Le démarrage de l'interpréteur est rapide (disons que pour l'instant je ne sais pas faire mieux). Sachant que mon application Web est un script CGI, c'est important ! Et, en dépit du fait que c'est un script CGI, les temps de réponses sont largement satisfaisants. Si j'ai le temps, je mettrais le serveur HTTP dans l'interpréteur (ou le contraire), pour gagner du temps au linkage dynamique. Là ça devrait dépoter...

J'invite d'ailleurs tous les développeurs qui gèrent un projet et qui ont une petite douzaine d'années devant eux à créer leur propre langage pour leur propre besoin. :-)