Val(a)IDE, environnement de développement intégré (EDI) pour le langage Vala, vient de sortir en version 0.7.2. Val(a)IDE est écrit en Vala et propose les fonctionnalités suivantes :
- Auto-complétion ;
- Coloration syntaxique ;
- Gestion de projets (compilation/exécution) ;
- Support des systèmes de construction externes (make, waf) ;
- Greffons : navigateur de symboles, gestionnaire de tâches, navigateur de fichiers…
Le code source et des paquets binaires pour différentes distributions GNU/Linux sont disponibles sur la page dédiée.
Principaux changements depuis la version 0.7.1
- L'auto-complétion fonctionne désormais pour l'ensemble des paquets Vala présents, à condition que ceux-ci soient définis dans les propriétés du projet ;
- Meilleure ergonomie, l'IDE devient plus « standard » et prévisible (demande de nom de fichier à la création, ouverture et fermeture automatique des onglets au fil de la navigation, mémorisation du dernier répertoire utilisé…)
- Très nombreuses corrections de bogues.
Planifié pour les prochaines versions
- Gestion de l'autocomplétion progressive ;
- Ajout d'un panneau Glade pour les projets GTK+/GNOME ;
- Migration vers GTK+3.
À noter que je ne suis pas le développeur original, ce dernier (sanpi) ayant publié les précédentes dépêches.
Aller plus loin
- Val(a)IDE 0.7.2 (539 clics)
- Téléchargement alternatif (35 clics)
- Branche Launchpad (26 clics)
- Page Vala sur GNOME.org (115 clics)
- Dépêche précédente (19 clics)
# Pourquoi Vala?
Posté par fredoche . Évalué à 10.
Cette question a des allures de troll, n’empêche que je n'ai pas trouvé beaucoup d'explications au choix de ce langage comme un de ceux de référence pour la plateforme gnome. Il est très peu répandu, et pourtant, de nombreuses applications gnome sont réécrites de zéro dans ce langage, notamment les jeux. En revanche, je peux totalement comprendre la perplexité des éventuels nouveaux contributeurs face à un langage qui n'a rien pour lui face aux autres, C/C++/C#/javascript équipés de bindings. En attendant, le populaire java reste toujours le parent pauvre de l’écosystème gnome avec des bindings peu documentés s'ils existent, même face à C#, alors que l'audience est incomparablement plus large.
Doucement sur le moinssage, j'aimerai bien avoir une esquisse d'explication avant :)
[^] # Re: Pourquoi Vala?
Posté par claudex . Évalué à 5.
Il a été développé pour Gnome. C'est donc logique.
Un des fondateurs de Gnome est un grand fan de .Net, ceci explique cela.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi Vala?
Posté par Tarnyko (site web personnel) . Évalué à 1.
Mais non, c'est une question parfaitement légitime :-).
Je ne peux pas parler pour GNOME, mais j'ai trouvé ça ici : a quality Vala 1.0 is an important part of the future of the GNOME Platform, because it will simplify the task of creating and maintaining excellent language-neutral libraries
Je le comprends comme ça : le code Vala se transcrit en C pur, dont les librairies résultantes peuvent être réutilisées/bindées facilement… à compléter ou corriger.
PS : c'est un peu exagéré de dire qu'il y a peu de bindings. Il y en a déjà pas mal.
[^] # Re: Pourquoi Vala?
Posté par Dr BG . Évalué à 5. Dernière modification le 31 décembre 2012 à 11:36.
C'est parce que la GLib est écrite en C, et manipule des objets grâce aux GObjects, ce qui est tout de même moins aisé qu'avec un vrai langage objet. Vala ne fait que générer du code C utilisant les GObjects mais avec une syntaxe plus sympa (similaire au C#).
Il n'y a aucune difficulté à apprendre le Vala car cela ressemble énormément à d'autres langages de programmation populaires. Le seul problème est à mon avis une documentation encore un peu faible.
J'avais essayé un peu il y a un ou deux ans et j'avais trouvé ça pas mal. J'ai rapidement pu produire du code. Bon, j'ai arrêté quand le code généré n'a plus voulu compiler (sans que le compilateur Vala ne se plaigne).
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet . Évalué à 4.
Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.
Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.
Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.
Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.
Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.
Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.
Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.
Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.
Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.
[^] # Re: Pourquoi Vala?
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 4.
Pour le premier désavantage de Vala je suis d'accord, c'est vrai que c'est chiant quand tu tombes sur un bug de Vala, même s'il faut espérer qu'à terme ça va devenir beaucoup plus marginal.
Par contre pour le deuxième point, sur le code «greppable», soit j'ai pas compris, soit ça s'applique à plus ou moins tous les langages objets (en C++, Java, … t'auras le même problème pour «grepper», non ?) et je suis pas persuadée que la solution de tout écrire en C soit pour autant forcément la meilleure pour tout le monde (je veux bien admettre que si tu maîtrises bien le C, GObject, etc, ça ne soit pas forcément si compliqué au final et que c'est une question d'habitude, mais je trouve que ça ne demande pas le même apprentissage).
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet . Évalué à 2.
Oui. Le C est un langage un peu plus verbeux, mais ça a des avantages.
[^] # Re: Pourquoi Vala?
Posté par Littleboy . Évalué à 6.
Ca fait longtemps (genre plus de 10 ans) que les IDE sont capables de ne te retourner les appels de methodes que pour des objets d'un certains type.
Si tu as ce probleme avec Vala, c'est plutot un manque des outils qu'un 'probleme' du langage.
[^] # Re: Pourquoi Vala?
Posté par Tarnyko (site web personnel) . Évalué à 1.
Exact. Pour éviter ce souci, les dernières versions des bibliothèques GNOME comprennent une surcouche nommée GObject-Introspection qui permet de régénérer des bindings "fiables" pour chaque nouvelle version de Vala.
Le problème se pose avec les autres biblios dont les bindings ont été écrits à la mano (GLUT par exemple).
Mais c'est valable aussi pour d'autres langages. Une solution que je préconise serait d'avoir une arborescence de paquets dédiés au langage, distincte de celle de la distro. On pourrait donc par exemple upgrader vers la dernière Ubuntu sans casser les bindings. Je songe à écrire une telle chose pour Vala, mais comme d'habitude le temps et le mécénat posent problème.
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet . Évalué à 1.
Je ne parlais pas des bindings, je parlais du fait que les mainteneurs d'applications doivent adapter le code pour utiliser les nouvelles API, si ils veulent rester à jour par rapport à GTK+ etc.
Si ce boulot est fait petit à petit, au fur et à mesure des versions, ça ne demande pas trop trop de temps. Mais si on rajoute les incompatibilités entre les différentes versions de Vala, ça rajoute du boulot supplémentaire, dont on se passerait bien.
[^] # Re: Pourquoi Vala?
Posté par Tarnyko (site web personnel) . Évalué à 1.
Ah mais c'est pareil dans n'importe quel langage utilisant des bibliothèques externes.
J'ai conscience que tu faisais un point général, mais la réponse que j'ai faite permettrait de résoudre (au moins par le bas) ce problème.
[^] # Re: Pourquoi Vala?
Posté par barmic . Évalué à 3.
grep est tout de même limité quelque soit le langage. Il faut une bonne expression régulière pour ne sortir que des méthodes et pas de variables du même nom par exemple et si tu as plusieurs méthodes avec des paramètres différents mais du même nom il devient inutilisable. Donc pour moi c'est un défaut assez limité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet . Évalué à -2. Dernière modification le 02 janvier 2013 à 13:46.
Tu as déjà vu une variable portant le nom gtk_text_view_new_with_buffer ?
Ça n'existe pas en C.
Là où grep fonctionne très bien pour du code C, pour d'autres langages comme Java il faut utiliser les fonctionnalités d'un IDE comme Eclipse (outil refactoring pour renommer une méthode ou une classe, par exemple).
Mais la verbosité du C est aussi utile pour la compréhension du code. Quand on a une hiérarchie importante de classes, le fait d'avoir le nom complet des fonctions permet de savoir de quelle classe elle vient, et donc on retrouve plus rapidement la documentation.
[^] # Re: Pourquoi Vala?
Posté par barmic . Évalué à 1.
C'est pas avec un exemple que tu démontre l'inexistence.
Par paramètres différents j'entends avec un nombre différents de paramètre (comme open(2) par exemple).
Éventuellement avec des règles de codages créées pour et bien suivi ça marche bien avec les méthodes, il reste les identifiants de variables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet . Évalué à 0.
Je ne vois pas où tu veux en venir.
Oui, dans des cas très particuliers, grep te sortira un ou deux résultats non voulus, mais le but premier est de savoir où est appelé telle ou telle fonction. Donc c'est très loin d'être grave…
[^] # Re: Pourquoi Vala?
Posté par barmic . Évalué à 5.
Je ne considère pas la fonction POSIX open comme un cas très particulier. Il y en a d'autres comme ça et tu peut en créer dans ton code.
Tu ne cherche jamais à savoir où est utilisée telle ou telle variable ou structure ?
Tant mieux pour toi. Je dis simplement que dans mon cas et je ne pense pas être le seul grep (ack, ag ou un quelconque outil du genre) est loin d'être parfait. Personnellement je ne m'en sert que pour trouver les définitions de variables et de fonctions dans un code que je connais mal et quelque soit le langage ça j'arrive assez bien à discriminer. Pour le reste je préfère m'en passer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.