Je passe juste pour vous signaler que le projet n'est pas mort. Je réalisais le site de Valse, et après avoir tapé deux ou trois tutoriels en HTML pur, je me suis dit que ça serait sympa de pouvoir utiliser du MarkDown à la place. Sauf que la seule bibliothèque qui permet de faire ça en Vala n'est pas compatible Windows.
J'ai donc décidé de créer ma propre bibliothèque pour cela. Et je me suis que tant qu'à réinventer la roue, autant le faire bien : je vais utiliser un MarkDown proche de celui de ZdS, extensible et évidemment compatible Windows. Seulement là aussi j'ai rencontré une situation inconfortable : l'autocomplétion du Vala dans Atom (l'éditeur de code que j'utilise) est juste horrible.
Je me suis donc lancé dans la création d'un package, joliement nommé super-vala (vous sentez l'inspiration ? ). Pour le moment, c'est assez expérimental, mais je commence à avoir quelque chose d'assez intéréssant.
Bref. J'ai deux nouveaux projets sur les bras. Peut-être qu'ils ne seront jamais utilisables, peut-être que je les présenterai sur ZdS un jour … En tout cas, je voulais vous dire que je n'abandonnais pas Valse, que j'étais juste sur d'autres projets "liés" pour le moment.
Très beau projet tiens! Du bon boulot en tout cas. J'contribuerai probablement vu que j'compte coder le backend de mon site (Ricin) en Vala, histoire de rester dans la logique du logiciel que je développe (en Vala :D)
Très beau projet tiens! Du bon boulot en tout cas.
Merci beaucoup.
J'contribuerai probablement vu que j'compte coder le backend de mon site (Ricin) en Vala, histoire de rester dans la logique du logiciel que je développe (en Vala :D)
Ça serait vraiment chouette ! Par contre en ce moment le projet tourne un peu au ralenti vu que je suis surtout en train de travailler sur Valhalla.
J'ai jeté un coup d’œil à ton projet, ça à l'air vraiment sympa aussi. J'y contribuerait peut-être à l'occasion.
Après une grande pause de plus de mois sans coder, je me suis relancé sur Valse depuis quelques jours. J'ai notamment enfin réussi à mettre en place l'intégration continue avec Gitlab CI. Pour le moment ça ne sert pas à grand chose, mais par la suite j'espère pouvoir proposer les binaires à chaque nouveau commit (plutôt simple) et faire un package RPM et/ou APT à chaque nouvelle version (là il faut que je me renseigne un peu plus sur comment faire, mais d'après ce que j'ai pu voir, c'est chaud et surtout long).
Et puis surtout je viens de faire un commit qui va vous changer la vie (oupa) : le fameux, le tant attendu … Kill The Mod !1 Qu'est ce que ça veut dire clairement ? Je ne sais pas si vous vous souvenez du mot-clé mod qu'on utilisait à tout bout de champ dans les vues : c'est fini, on peut maintenant mettre le mot qu'on veut (d'où le Kill The Mod). Et en plus on peut aussi avoir plusieurs modèles par vues. Seule petite tâche à cette nouveauté, la syntaxe qui n'est pas géniale …
J'aurais préféré pouvoir mettre tout ça entre { } un peu comme si on écrivait du JSON, mais bon …
J'avance aussi sur poulp, le petit outils en ligne de commande qui devrait faciliter la vie de tout développeur Vala. Je me concentre sur l'installation de bibliothèques, de façon multi-plateforme. En effet, sous Linux un simple apt-get install libgee-dev ou dnf install libgee-devel suffisent, mais sous Windows. Et ne parlons même pas de Mac OS X… J'ai donc crée une interface web (vec Valse forcemment) pour gérer un dépôt de bibliothèques que poulp pourra télécharger. Le code est disponible ici, pour les curieux.
Voilà, comme toujours merci à tous ceux qui supportent le projet, et si vous voulez contribuer il ne faut pas hésiter, ça peut être l'occasion d'apprendre tout un tas de trucs. Et même si vous ne connaissez rien à Vala ou au Web, je me ferai une joie de vous aider.
En fait on aurait pu l'avoir bien plus tôt : Wizix avait déjà tout fait, et puis comme je ne sais pas me servir de git, je ne sais pas ce que j'ai fait, mais en gros, on a tout perdu… Oui, je suis un gros boulet. :honte: ↩
Je suis le développeur principal de Valum et je suis content de voir que d'autres gens (francophone de plus) s'intéressent à la programmation Web avec Vala.
D'abord, désolé pour l'absence du support sur Windows, j'ai pas le loisir (ni la motivation) de le tester. Je peux m'essayer par contre
J'ai remplacé waf par Meson il y a quelques mois, alors construire est beaucoup plus simple que jamais. Il est même possible d'utiliser le framework sans l'installer.
Je pense aussi traduire la documentation en français si ça peut en intéresser quelques-uns.
Quelques projets intéressants:
VSGI fournit une abstraction pour plusieurs protocoles (que Valse pourrait réutiliser)
libyaml-glib, redis-glib et je peux en nommer pas mal d'autres
En gros, je pense que l'idéal serait d'avoir un bon pool de libraries qui ciblent Vala et qui facilitent le développement Web.
Les sous-modules git peuvent servir de gestion de paquets primitif en attendant d'avoir quelque chose de plus élaboré. Un truc basé sur Meson serait vraiment intéressant.
D'abord, désolé pour l'absence du support sur Windows, j'ai pas le loisir (ni la motivation) de le tester. Je peux m'essayer par contre
J'ai remplacé waf par Meson il y a quelques mois, alors construire est beaucoup plus simple que jamais. Il est même possible d'utiliser le framework sans l'installer.
Ah très intéréssant je testerai surement ça alors, surtout que Valum est beaucoup utilisable que Valse pour le moment.
Quelques projets intéressants:
VSGI fournit une abstraction pour plusieurs protocoles (que Valse pourrait réutiliser)
libyaml-glib, redis-glib et je peux en nommer pas mal d'autres
En gros, je pense que l'idéal serait d'avoir un bon pool de libraries qui ciblent Vala et qui facilitent le développement Web. Je vais voir pour intégrer VSGI (et pourquoi pas Template-GLib) dans Valse.
Yep, ça serait vraiment bien, en effet.
Les sous-modules git peuvent servir de gestion de paquets primitif en attendant d'avoir quelque chose de plus élaboré. Un truc basé sur Meson serait vraiment intéressant.
Je ne connais pas du tout Meson, donc je ne vois pas comment ça fonctionnerait, mais pourquoi pas. Sinon, j'ai commencé un petit gestionnaire de paquets pour Vala, poulp, mais bon, si un sytème basé sur Meson est plus simple et mieux fait, autant l'utiliser.
D'abord, désolé pour l'absence du support sur Windows, j'ai pas le loisir (ni la motivation) de le tester. Je peux m'essayer par contre
J'ai remplacé waf par Meson il y a quelques mois, alors construire est beaucoup plus simple que jamais. Il est même possible d'utiliser le framework sans l'installer.
Ah très intéréssant je testerai surement ça alors, surtout que Valum est beaucoup utilisable que Valse pour le moment.
Plus que jamais! Pas besoin de rien installer, suffit de cloner le dépôt et le tour est joué. Tu peux consulter l'exemple suivant:
libyaml-glib, redis-glib et je peux en nommer pas mal d'autres
En gros, je pense que l'idéal serait d'avoir un bon pool de libraries qui ciblent Vala et qui facilitent le développement Web. Je vais voir pour intégrer VSGI (et pourquoi pas Template-GLib) dans Valse.
C'est pas tout à fait stable en ce moment. J'aimerais réécrire le modèle d'écoute sur GSocketAddress afin de pouvoir utiliser GInetSocketAddress, GUnixSocketAddress, … et peut-être découpler le code de GApplication afin d'avoir un serveur simple qui nécessite qu'une boucle d'événement pour opérer.
Yep, ça serait vraiment bien, en effet.
Les sous-modules git peuvent servir de gestion de paquets primitif en attendant d'avoir quelque chose de plus élaboré. Un truc basé sur Meson serait vraiment intéressant.
Je ne connais pas du tout Meson, donc je ne vois pas comment ça fonctionnerait, mais pourquoi pas. Sinon, j'ai commencé un petit gestionnaire de paquets pour Vala, poulp, mais bon, si un sytème basé sur Meson est plus simple et mieux fait, autant l'utiliser.
Je pensais aussi écrire un gestionnaire de paquet, mais c'est beaucoup de boulot. Meson te permet d'inclure une dépendance construite dans un sous-projet comme tu peux voir dans l'exemple ci-haut. Ça, c'est franchement bien.
J'ai terminé de réécrire le tout sur GSocketAddress et je vais lancer la version 0.3 de manière imminente (dès que Meson 0.36 sort en fait…). Voici un petit aperçu d'un serveur SCGI:
1
2
3
4
5
6
7
varscgi_server=Server.new("scgi",backlog:1024);scgi_server.set_application_callback(...);// faire le pont avec Valsescgi_server.listen(newInetSocketAddress(newInetAddress.loopback(SocketFamily.IPV4),3003);scgi_server.run();
Pour les autres protocoles, il suffit de remplaçer la chaîne de Server.new. VSGI support CGI, FastCGI et HTTP via libsoup-2.4. Je planifie rajouter Apache JServe Protocol et Lwan pour la prochaine release.
Une fois fait, je pense que ce serait bien d'envisager une version stable de VSGI afin de pouvoir l'utiliser avec Valse, non?
En passant, j'ai beaucoup progressé sur la traduction en français, mais j'essaye encore de voir comment publier de la doc multi-lingue avec ReadTheDocs. Si vous avez une petite idée, laissez moi savoir!
J'arrête Valse. J'arrête le Vala. En réfléchissant bien, je me dit que ce langage n'est qu'une perte de temps. Il va doucement mourir, dans son coin, parce qu'il n'a pas de vrai intérêt. Les outils ne conviennent pas : Valadoc.org a de nombreux défauts, déboguer du code est une horreur, il n'y a pas de vrai IDE, et installer des dépendances est trop complexe. On aurait pu créer ou améliorer les outils nécessaires, mais il aurait fallu le faire il y a dix ans. Aujourd'hui on a des langages comme Rust ou Crystal qui sont tout autant efficaces que Vala sur les quelques points qui rendait le langage intéressant (à savoir la vitesse et la légèreté tout en gardant un certain haut niveau, et la possibilité d'être réutilisé dans d'autres langages facilement). J'abandonne donc le Vala, Valse, poulp, Valhalla, le tuto sur Vala et tous mes projets liés au langage. Voilà.
Bon, j'ai réfléchi à ma décision d'arrêter Vala, et je suis revenu dessus. Même si Vala a des problèmes, sa syntaxe est l'une des seules que je supporte (je suis assez exigeant de ce côté là, et les seules syntaxes que j'aime sont celle de Vala et de Ruby). Les autres langages que j'ai pu essayer (Rust, Crystal, Ruby) ont eux aussi des problèmes (et parfois ça va plus loin que juste la syntaxe que je n'aime pas.
Je me dis donc qu'essayer de résoudre les problèmes de Vala est une meilleure solution que chercher une alternative, qui de toute façon risque elle aussi d'avoir des problèmes. De toute façon, je développe pour le fun, donc ce qui est important c'est que je prenne du plaisir. Et il n'y a qu'avec Vala que je m'amuse. Parce que c'est quand même drôle de passer deux heures à chercher d'où vient cette segfault. Par contre Valse ne sera peut-être pas la priorité, contrairement à poulp qui sera sûrement utile à plus de monde (genre tous les développeurs Vala, contre seulement ce qui veulent faire du web pour Valse). Je vous tiens au jus !
(Par contre il va falloir que j'arrête avec les copier/coller de messages entre les différents sujets)
Aujourd'hui, je ne vais pas vous parler de Valse, mais de poulp (comme je n'ai pas créé dee sujet dédié à celui-ci). Si vous ne vous souvenez pas/n'avez pas lu le début de la discussion, poulp est un petit outil en ligne de commande pour gérer ses projets et ses bibliothèques Vala. C'est un peu un équivalent de npm, mais pour Vala.
Depuis quelques jours, je me suis remis au développement de poulp, avec l'aide de SkyzohKey (merci beaucoup à lui d'ailleurs ). On a complètement tout réécrit beaucoup plus proprement et on a inclus plein de nouvelles choses. Et aujourd'hui, je lance une première version (ou plutôt RC, je ne garantit pas que ça soit 100% stable) pour que vous puissiez tester et nous faire des retours.
poulp RC1
Le nouveau logo de poulp
poulp se base sur un fichier poulp.json qui se trouve à la racine de votre projet et qui contient toutes les informations sur votre projet. Vous pouvez trouver un exemple ici. poulp contient ensuite plein de commandes qui permettent de manipuler votre projet à l'aide ce fichier poulp.json. Cette première version inclus les commandes suivantes :
init, qui sert à initialiser un nouveau projet en répondant à quelques questions. Un poulp.json sera créé et un modèle peut être utilisé (par exemple, un modèle d'application graphique avec GTK+3, qui contiendrait les fichiers window.ui, window.vala et main.vala avec le code de base dedans) ;
build, qui compile votre projet, sans que vous ayez à vous casser la tête (c'est-à-dire sans passer directement par valac et ses quarante-douze mille arguments ou par un Makefile), en se basanr sur ce qu'il y a dans votre poulp.json ;
repo, pour gérer vos dépôts distants (ajouter, supprimer, lister) ;
run, qui lance un script défini dans la section scripts de votre poulp.json. On peut par exemple avoir un script charger d'installer le résultat de la compilation ;
install, qui installe des paquets depuis des dépôts distants ;
lint, qui vérifie le style de votre code. On peut choisir de suivre les conventions de GNOME ou celles d'elementary OS (ou les deux à la fois). Mais pour le moment, elles ne sont pas complètement supportés (certaines règles sont assez dur à vérifier), surtout celles de GNOME. Je vous conseille donc d'utiliser celles d'elementary OS pour le moment ;
gen, qui génère un (ou plusieurs) fichier depuis un modèle. Par exemple, on pourrait faire poulp gen src/user-controller --template controller, pour générer un nouveau contrôleur Valse, à condition d'avoir le template controller d'installé ;
install et update, les deux commandes les plus intéréssantes, qui permettent respectivement d'installer et de mettre à jour des bibliothèques. Ces bibliothèques doivent se trouver dans un dépôt connu. J'ai créé un dépôt de test, que vous pouvez explorer ici. Normalement il est déjà connu de poulp.
Vous pourrez donc faire un sudo poulp install valse pour tester Valse ! Les paquest peuvent aussi installer des modèles (de projet ou de fichier). Vous pouvez par exemple faire un sudo poulp install gtk-template puis essayez un poulp gen fenetre --template window.
La commande poulp init
Tester
Ça serait vraiment super si vous pouviez prendre 5 minutes pour installer et tester poulp sur votre machine. Surtout que l'installation est super simple (au moins sur les distributions Linux basées sur RPM ou les dérivées de Debian). Voici comment faire.
CentOS (et tout système avec yum) : sudo wget https://bintray.com/bat41/rpm/rpm -O /etc/yum.repos.d/bintray-bat41-rpm.repo && sudo yum install poulp ;
Debian et dérivées : echo "deb https://dl.bintray.com/bat41/deb DISTRIBUTION main" | sudo tee -a /etc/apt/sources.list && sudo apt install poulp, avec DISTRIBUTION votre version de Debian.
Pour les autres systèmes, je ne sais pas comment faire de paquet, donc désolé. Pour Windows, je compilerai une version installable à la main à l'occasion. Et pour Mac OS X, là ça risque de devenir compliqué… Mais cette version est une version de test, pas une vraie release. Je précise aussi que ces paquets ne fonctionneront que sur les systèmes 64bits. Mais si vous ne pouvez pas installer poulp facilement, vous pouvez éventuellement le compiler vous-même (n'hésitez pas à demander si vous ne savez pas trop comment faire).
La première fois que vous lancez poulp, je vous conseille de le faire avec sudo, car il crée des fichiers de configuration dans /etc/.
Je vais aussi essayer de créer un site pour héberger facilement des paquets, parce que pour le moment c'est un peu la galère.
Le développement passe toujours sur Framagit, donc si vous voulez aider, il n'y a pas de problèmes !
Petite question (je suis sur mobile, je peux pas tester poulp pour l'instant) : pourquoi du json et pas du yaml ? Pour une utilisation par des humains, c'est bien plus agréable. Pour du transfert d'information machine-machine, je comprends le choix du JSON mais pour un fichier de configuration…
Tout simplement parce que bien qu'il existe une bibliothèque pour utiliser du YAML en Vala, celle pour faire du JSON est généralement fournie avec le langage, et je suis donc sûr que poulp tournera partout où Vala tourne sans problèmes. Après, poulp devrait normalement régler le problème de l'installation multiplateforme, donc si on arrive à avoir une version pour chaque système de YAML-GLib (la lib pour faire du YAML), pourquoi pas changer en effet. Par contre il faudrait que je le fasse assez rapidement, pour éviter de tout casser.
Et puis c'est aussi parce que je me suis pas mal inspiré de NPM, qui utilise du JSON, même si là c'est plus cohérent parce que JS et JSON sont très liés. Mais bon, ça aurait pu être pire : j'aurai pu choisir du XML.
Sous fedora, j'ai un conflit entre poulp et filesystem (un paquet, je sais pas trop ce qu'il fait). Y'a un truc que je peux faire pour t'aider à trouver le fichier qui pose problème ?
Dependencies resolved.
================================================================================================================================================================================================
Package Arch Version Repository Size
================================================================================================================================================================================================
Installing:
poulp x86_64 test-1 bintray--bat41-rpm 64 k
vala x86_64 0.30.2-1.fc23 updates 1.6 M
Transaction Summary
================================================================================================================================================================================================
Install 2 Packages
Total download size: 1.7 M
Installed size: 9.3 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): vala-0.30.2-1.fc23.x86_64.rpm 707 kB/s | 1.6 MB 00:02
(2/2): poulp-test.x86_64.rpm 26 kB/s | 64 kB 00:02
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 426 kB/s | 1.7 MB 00:04
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of poulp-test-1.x86_64 conflicts with file from package filesystem-3.2-35.fc23.x86_64
Error Summary
-------------
Euh… d'après ton message d'erreur il essaie de remplacer /usr/bin/, donc c'est cool que ça ne marche pas. Il faut que je vois pourquoi il fait ça par contre.
Cette ligne, non ? (J'ai vu le message This script is intended to be used only by gitlab-ci., juste que j'imagine que le build que tu as partagé n'est pas loin de ça.) P-ê qu'il pense que tu souhaites place poulp à /usr/bin, et non dedans, p-ê qu'un ajout de / devrait résoudre le problème ?
Je fais des tests en local, et ça à l'air de marcher. Par contre je vois que dnf n'a pas la dernière version du paquet, qui devrait être rc1 et pas test…
Alors, je pourrais (une seule ligne à modifier dans le code, si c'est pas beau ), mais ça risque de compliquer les choses, parce que du coup quand je veux obtenir le /home/ de l'utilisateur actuel quand on fait sudo poulp install truc (sudo est nécessaire ici), j'obtiens pas le vrai utilisateur mais root. Bon après, je pense que ça devrait pas être trop dur de trouver un moyen pour contourner ça. Je vais essayer de regarder ça.
Ou alors, je package les fichiers de config, ce qui me semble être la meilleure solution.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
). Pour le moment, c'est assez expérimental, mais je commence à avoir quelque chose d'assez intéréssant.
Mais cette version est une version de test, pas une vraie release. Je précise aussi que ces paquets ne fonctionneront que sur les systèmes 64bits. Mais si vous ne pouvez pas installer poulp facilement, vous pouvez éventuellement le compiler vous-même (n'hésitez pas à demander si vous ne savez pas trop comment faire). 
