le but est aussi que l'utilisateur puisse plus facilement installer un paquet hors dépôt et que l'application soit un minimum isolée au sein du système
Nix fait ça très bien. Par exemple, un utilisateur peut installer, de façon isolée et "immutable", un paquet de la logithèque avec :
nix-env -iA nixpkgs.emacs
Et il peut aussi installer n'importe quel logiciel contenant un fichier default.nix avec (par exemple depuis un dépôt github) :
Salut,
Et sinon, pourquoi ne pas plutôt s'inspirer des projets Nixos et Gnu Guix, qui font de la recherche et développent des gestionnaires de paquets depuis plus de 10 ans, pour résoudre ces problèmes ?
Oui, c'est un exemple intéressant à regarder, mais plus compliqué.
En JS, je pense qu'il faut quelques bibliothèques côté serveur mais on doit pouvoir s'en sortir facilement en pur-JS côté client.
Effectivement la partie canvas se retrouve dans les différentes techno mais ce n'est qu'un élément de l'appli. Il a aussi la couleur de la brosse, sa taille, etc, c'est-à-dire un modèle sur lequel on ajoute des fonctionnalités d'affichage et de mise à jour. Du coup, les technos sont bien ici des alternatives différentes : JS c'est "sans framework, à la main", Miso c'est un framework "à la angular/vue/react", Wt un framework encore différent.
Par contre, la première implémentation en wasm est effectivement un équivalent du canvas HTML5 et pourrait donc être utilisée avec les autres techno, de façon complémentaire, sauf que ce n'est pas toujours une bonne idée et qu'il vaut parfois mieux l'utiliser pour gérer toute l'appli (comme dans la seconde implémentation) donc de façon non complémentaire aux autres techno.
OpenCV a quelques fonctionnalités de capture et peut aussi utiliser gstreamer mais je n'en sais pas beaucoup plus. Pour le streaming, tu as parfaitement raison : l'exemple proposé n'est pas du tout le plus efficace, c'est juste pour s'amuser un peu avec quelques lignes de Haskell.
Salut,
Sur ton exemple, il me semble que le Makefile peut être raccourci en :
all: main
main: main.o hello.o
Make trouvera les dépendances automatiquement.
Et tu peux aussi profiter des variables d'environnement, par exemple pour compiler en debug et avec un autre compilateur :
Oui, la partie 2 contient une section sur Pistache (avec une petite illustration du fonctionnement asynchrone) et il y a une version avec Cpprestsdk sur le dépôt git. Pistache a un système description de service REST qui a l'air très intéressant mais je ne l'ai pas testé.
Oui effectivement, c'est un peu la mode actuelle de réduire la partie serveur à une API JSON et de gérer le reste côté client via des frameworks comme Vue.js ou React. C'est d'ailleurs pour ça que j'ai précisé dans l'article : "même si la tendance actuelle est plutôt de proposer une API côté serveur et de générer le code HTML côté client".
Les frameworks C++ proposent souvent des fonctionnalités pour gérer du JSON mais le but ici était plutôt de voir, pour une application donnée, les différents outils disponibles côté backend : frameworks asynchrones, frameworks basés templates (tntnet), frameworks basés widgets (wt), etc. Cf la partie 2…
Effectivement, les solutions présentées ici peuvent encore être optimisées. Par exemple dans la solution 2 (Dockerfile multi-stage sur base debian), l'appli est compilée en statique donc on doit pouvoir la déployer sur une image distroless ou sur un stratch + glibc.
Avec Nix, je pense qu'il faudrait "juste" configurer le projet en statique et dockerTools devrait à peu près se débrouiller pour déployer uniquement le nécessaire à partir de stratch.
Maintenant, pour des applis dans des langages comme go ou rust, si c'est pour déployer sur un PaaS, il ne faut pas s'embêter avec Docker mais déployer directement à partir du code source. C'est très simple et plutôt optimisé (dans cet exemple en Haskell, le slug déployé fait 11 Mo : https://nokomprendo.frama.io/tuto_fonctionnel/posts/tuto_fonctionnel_23/2018-07-01-README.html).
Wt est effectivement intéressant. En plus du système de widgets, il y a du templating, de la gestion de styles, des bases de données, des widgets évolués (charts, webgl… https://www.webtoolkit.eu/widgets), etc. Le tout est plutôt simple à utiliser et en C++ plutôt moderne. Cela dit, Wt n'est pas forcément adapté à toutes les applications web et sa licence est en GPL+commercial (à la Qt).
Quand j'aurai le temps, j'essaierai de faire des posts sur une appli Wt plus complète et sur une comparaison avec une appli webassembly + serveur léger.
Sinon, la gestion d'évènements via un gros switch-case me fait penser à la pompe à messages de l'API win32 sous windows 95. Dans mon souvenir, cette façon de faire devenait rapidement difficile quand le code grossissait.
Moi aussi j'ai vu le reportage d'arte "Thorium, la face cachée du nucléaire", sur les réacteurs à sels fondus. Ca a l'air génial… Trop en fait, ça ressemble presque à la propagande qu'on nous a déjà servie pour le nucléaire à fission. D'ailleurs même arte n'est pas d'une impartialité et d'une rigueur scientifique absolues. Mais surtout, c'est quoi le rapport avec les brevets logiciels de microsoft ?
Je ne reconnais pas complètement mon expérience personnelle dans ce que vous décrivez du calcul scientifique. Pour moi la popularité de Python tient surtout à sa simplicité et à son expressivité. Beaucoup de scientifiques ne sont pas des informaticiens et ont plutôt intérêt à utiliser Python/R/Matlab et à réserver C/C++/Fortran aux parties très calculatoires.
Concernant la popularité de Rust dans le calcul scientifique, ça m'étonne beaucoup. Rust a peut-être du potentiel pour implémenter les libs bas-niveau (BLAS & co) mais cet écosystème est déjà bien fourni, optimisé et mature. Quant à remplacer Python, je n'y crois pas une seule seconde, pour les raisons de simplicité/expressivité évoquées précédemment.
Par contre, le langage Julia, qui est à la fois performant et expressif, commence à devenir vraiment populaire dans le milieu.
Oui en théorie Docker résout le problème. Mais en théorie aussi les distributions proposent une logithèque et un système de packaging qui font que le problème n'existe juste pas. Et pourtant…
Ton lien est intéressant mais je t'invite à tester les exemples proposés. Perso, j'arrive à faire tourner l'exemple de xeyes mais pour android-studio ou même juste gimp ou geany, ça ne fonctionne pas. Donc bon, on est loin de la solution facile. Et je ne parle même pas de la solution cross-platform que "We will see that in another post" depuis 8 mois et encore moins du gpu qui mérite certainement un roman entier à lui tout seul (https://github.com/NVIDIA/nvidia-docker)…
Ce que tu décris est une implémentation classique d'un MVC en POO, mais un MVC ne peut pas s'implémenter comme ça en programmation fonctionnelle. D'autre part, pour le web frontend, l'aspect asynchrone est important et c'est pour cela qu'on utilise souvent des MVC unidirectionnels. Le MVC n'a pas vraiment de définition rigoureuse. Elm parle effectivement de Model-View-Update https://guide.elm-lang.org/architecture/ et chaque framework propose sa variante (MVP, MVE, MVVM, MVW…). Ici, j'ai préféré utiliser MVC dans un sens un peu général.
Je n'ai aucune expérience dans le mobile mais apparemment ça fait partie des objectifs de Reflex. Le projet Reflex-platform permet de compiler pour du natif, du web, android et ios (https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.md). Perso, je trouve que Reflex n'est pas complètement trivial et qu'il faut prévoir un peu de temps pour l'apprendre correctement, mais Reflex-platform peut aussi compiler du Miso; c'est peut-être un bon compromis (https://github.com/dmjio/miso/issues/367).
Pour immuable/immutable, oui c'est le même concept. Je crois que ce sont vraiment des synonymes mais immutable, ça fait un peu anglicisme.
Bon d'accord, tu as raison : C++ est un langage géré n'importe comment, qui provoque systèmatiquement des fuites mémoires, qui n'a pas d'outils d'analyse corrects et qui fait du lobbying pour empêcher le monde d'utiliser d'autres langages bien meilleurs. Allez salut.
Mais de quoi tu parles ? Il n'est pas question d'héritage, juste de faire une classe avec le pointeur en attribut privé, le create dans le constructeur et le delete dans le destructeur. Quand à "l'overhead" Rust est le premier à dire qu'il a les performances de "C++ avec le même niveau de vérification".
[^] # Re: Avenir de Linux
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre (2ᵈᵉ partie). Évalué à 3.
Nix fait ça très bien. Par exemple, un utilisateur peut installer, de façon isolée et "immutable", un paquet de la logithèque avec :
Et il peut aussi installer n'importe quel logiciel contenant un fichier
default.nix
avec (par exemple depuis un dépôt github) :[^] # Re: Avenir de Linux
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Apports de Fedora à l’écosystème du logiciel libre (2ᵈᵉ partie). Évalué à 3.
Salut,
Et sinon, pourquoi ne pas plutôt s'inspirer des projets Nixos et Gnu Guix, qui font de la recherche et développent des gestionnaires de paquets depuis plus de 10 ans, pour résoudre ces problèmes ?
[^] # Re: Nix et autres
Posté par nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 2.
Salut,
XSLT est également homoïconique et permet donc également de mixer codes et données (https://en.wikipedia.org/wiki/Homoiconicity#Implementation_methods). Par contre, je ne sais pas si c'est aussi pratique avec XSLT qu'avec les macro LISP.
[^] # Re: isPrefix
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (2/2). Évalué à 1. Dernière modification le 02 janvier 2019 à 15:54.
Bien vu, merci.
Apparemment il y a
starts_with
en C++20 qui devrait encore mieux convenir.[^] # Re: dessin basique > tableau blanc collaboratif
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Comparaison de technologies Web pour implémenter une application de dessin basique. Évalué à 1.
Oui, c'est un exemple intéressant à regarder, mais plus compliqué.
En JS, je pense qu'il faut quelques bibliothèques côté serveur mais on doit pouvoir s'en sortir facilement en pur-JS côté client.
[^] # Re: Complémentaire à AngularJS/Vue.js/React ...
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Comparaison de technologies Web pour implémenter une application de dessin basique. Évalué à 1.
Effectivement la partie canvas se retrouve dans les différentes techno mais ce n'est qu'un élément de l'appli. Il a aussi la couleur de la brosse, sa taille, etc, c'est-à-dire un modèle sur lequel on ajoute des fonctionnalités d'affichage et de mise à jour. Du coup, les technos sont bien ici des alternatives différentes : JS c'est "sans framework, à la main", Miso c'est un framework "à la angular/vue/react", Wt un framework encore différent.
Par contre, la première implémentation en wasm est effectivement un équivalent du canvas HTML5 et pourrait donc être utilisée avec les autres techno, de façon complémentaire, sauf que ce n'est pas toujours une bonne idée et qu'il vaut parfois mieux l'utiliser pour gérer toute l'appli (comme dans la seconde implémentation) donc de façon non complémentaire aux autres techno.
Pour le draw.js généré par webassembly ça donne ça (un fichier de 58k pas très lisible qui fait le lien avec le draw.wasm) : https://nokomprendo.frama.io/tuto_fonctionnel/posts/tuto_fonctionnel_32/images/draw_wasm/draw.js
[^] # Re: mapM_
Posté par nokomprendo (site web personnel) . En réponse au journal Un serveur de webcam en 35 lignes de Haskell. Évalué à 1.
Exact, merci pour l'info.
[^] # Re: balise video ?
Posté par nokomprendo (site web personnel) . En réponse au journal Un serveur de webcam en 35 lignes de Haskell. Évalué à 4.
OpenCV a quelques fonctionnalités de capture et peut aussi utiliser gstreamer mais je n'en sais pas beaucoup plus. Pour le streaming, tu as parfaitement raison : l'exemple proposé n'est pas du tout le plus efficace, c'est juste pour s'amuser un peu avec quelques lignes de Haskell.
# reprise d'un lien précédent
Posté par nokomprendo (site web personnel) . En réponse au journal Un serveur de webcam en 35 lignes de Haskell. Évalué à 2. Dernière modification le 14 décembre 2018 à 10:56.
Pour info, je l'avais déjà envoyé dans les liens mais là c'est une version rédigée plus complète.
# avec les règles automatiques de make
Posté par nokomprendo (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 4.
Salut,
Sur ton exemple, il me semble que le Makefile peut être raccourci en :
Make trouvera les dépendances automatiquement.
Et tu peux aussi profiter des variables d'environnement, par exemple pour compiler en debug et avec un autre compilateur :
[^] # Re: Alternatives
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (1/2). Évalué à 2. Dernière modification le 11 décembre 2018 à 16:23.
Oui, la partie 2 contient une section sur Pistache (avec une petite illustration du fonctionnement asynchrone) et il y a une version avec Cpprestsdk sur le dépôt git. Pistache a un système description de service REST qui a l'air très intéressant mais je ne l'ai pas testé.
[^] # Re: Alternatives
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (1/2). Évalué à 4. Dernière modification le 11 décembre 2018 à 01:11.
Oui effectivement, c'est un peu la mode actuelle de réduire la partie serveur à une API JSON et de gérer le reste côté client via des frameworks comme Vue.js ou React. C'est d'ailleurs pour ça que j'ai précisé dans l'article : "même si la tendance actuelle est plutôt de proposer une API côté serveur et de générer le code HTML côté client".
Les frameworks C++ proposent souvent des fonctionnalités pour gérer du JSON mais le but ici était plutôt de voir, pour une application donnée, les différents outils disponibles côté backend : frameworks asynchrones, frameworks basés templates (tntnet), frameworks basés widgets (wt), etc. Cf la partie 2…
[^] # Re: From scratch ?
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Déployer une application Web C++ sur Heroku avec Docker et Nix. Évalué à 4.
Effectivement, les solutions présentées ici peuvent encore être optimisées. Par exemple dans la solution 2 (Dockerfile multi-stage sur base debian), l'appli est compilée en statique donc on doit pouvoir la déployer sur une image distroless ou sur un stratch + glibc.
Avec Nix, je pense qu'il faudrait "juste" configurer le projet en statique et dockerTools devrait à peu près se débrouiller pour déployer uniquement le nécessaire à partir de stratch.
Maintenant, pour des applis dans des langages comme go ou rust, si c'est pour déployer sur un PaaS, il ne faut pas s'embêter avec Docker mais déployer directement à partir du code source. C'est très simple et plutôt optimisé (dans cet exemple en Haskell, le slug déployé fait 11 Mo : https://nokomprendo.frama.io/tuto_fonctionnel/posts/tuto_fonctionnel_23/2018-07-01-README.html).
[^] # Re: Wt <3
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Déployer une application Web C++ sur Heroku avec Docker et Nix. Évalué à 3.
Wt est effectivement intéressant. En plus du système de widgets, il y a du templating, de la gestion de styles, des bases de données, des widgets évolués (charts, webgl… https://www.webtoolkit.eu/widgets), etc. Le tout est plutôt simple à utiliser et en C++ plutôt moderne. Cela dit, Wt n'est pas forcément adapté à toutes les applications web et sa licence est en GPL+commercial (à la Qt).
Quand j'aurai le temps, j'essaierai de faire des posts sur une appli Wt plus complète et sur une comparaison avec une appli webassembly + serveur léger.
[^] # Re: Proposé en dépêche
Posté par nokomprendo (site web personnel) . En réponse au journal Déployer une application web C++ sur Heroku avec Docker et Nix. Évalué à 1.
Ok. Merci pour la dépêche et pour le commentaire de CrEv, qui est effectivement très intéressant.
[^] # Re: .
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Publication de l’Atlas toolkit 0.4 avec démonstrations en ligne. Évalué à 3.
Si j'ai bien compris, c'est un framework "widget-centric" et il en existe pour pas mal de langages : https://stackoverflow.com/questions/43157412/why-widget-centric-web-frameworks-arent-that-popular.
Sinon, la gestion d'évènements via un gros switch-case me fait penser à la pompe à messages de l'API win32 sous windows 95. Dans mon souvenir, cette façon de faire devenait rapidement difficile quand le code grossissait.
[^] # Re: Maintenant, c'est clair
Posté par nokomprendo (site web personnel) . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 3.
Moi aussi j'ai vu le reportage d'arte "Thorium, la face cachée du nucléaire", sur les réacteurs à sels fondus. Ca a l'air génial… Trop en fait, ça ressemble presque à la propagande qu'on nous a déjà servie pour le nucléaire à fission. D'ailleurs même arte n'est pas d'une impartialité et d'une rigueur scientifique absolues. Mais surtout, c'est quoi le rapport avec les brevets logiciels de microsoft ?
[^] # Re: HS interface
Posté par nokomprendo (site web personnel) . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 1. Dernière modification le 18 octobre 2018 à 21:30.
Le brevet sur la lisibilité des écrans n'a pas encore été open-sourcé.
[^] # Re: Espace disque partagé...
Posté par nokomprendo (site web personnel) . En réponse au journal Flatpak. Évalué à 3. Dernière modification le 16 octobre 2018 à 20:51.
Je ne reconnais pas complètement mon expérience personnelle dans ce que vous décrivez du calcul scientifique. Pour moi la popularité de Python tient surtout à sa simplicité et à son expressivité. Beaucoup de scientifiques ne sont pas des informaticiens et ont plutôt intérêt à utiliser Python/R/Matlab et à réserver C/C++/Fortran aux parties très calculatoires.
Concernant la popularité de Rust dans le calcul scientifique, ça m'étonne beaucoup. Rust a peut-être du potentiel pour implémenter les libs bas-niveau (BLAS & co) mais cet écosystème est déjà bien fourni, optimisé et mature. Quant à remplacer Python, je n'y crois pas une seule seconde, pour les raisons de simplicité/expressivité évoquées précédemment.
Par contre, le langage Julia, qui est à la fois performant et expressif, commence à devenir vraiment populaire dans le milieu.
[^] # Re: Docker
Posté par nokomprendo (site web personnel) . En réponse au journal Flatpak. Évalué à 6.
Oui en théorie Docker résout le problème. Mais en théorie aussi les distributions proposent une logithèque et un système de packaging qui font que le problème n'existe juste pas. Et pourtant…
Ton lien est intéressant mais je t'invite à tester les exemples proposés. Perso, j'arrive à faire tourner l'exemple de xeyes mais pour android-studio ou même juste gimp ou geany, ça ne fonctionne pas. Donc bon, on est loin de la solution facile. Et je ne parle même pas de la solution cross-platform que "We will see that in another post" depuis 8 mois et encore moins du gpu qui mérite certainement un roman entier à lui tout seul (https://github.com/NVIDIA/nvidia-docker)…
[^] # Re: Docker
Posté par nokomprendo (site web personnel) . En réponse au journal Flatpak. Évalué à 1.
A ma connaissance, Docker ne permet pas de générer et de lancer facilement une image d'appli graphique, avec accès au disque et au GPU.
[^] # Re: MVC
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Développement Web frontend en Haskell, Elm et Purescript. Évalué à 4.
Ce que tu décris est une implémentation classique d'un MVC en POO, mais un MVC ne peut pas s'implémenter comme ça en programmation fonctionnelle. D'autre part, pour le web frontend, l'aspect asynchrone est important et c'est pour cela qu'on utilise souvent des MVC unidirectionnels. Le MVC n'a pas vraiment de définition rigoureuse. Elm parle effectivement de Model-View-Update https://guide.elm-lang.org/architecture/ et chaque framework propose sa variante (MVP, MVE, MVVM, MVW…). Ici, j'ai préféré utiliser MVC dans un sens un peu général.
[^] # Re: Article sympa a lire
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Développement Web frontend en Haskell, Elm et Purescript. Évalué à 4.
Je n'ai aucune expérience dans le mobile mais apparemment ça fait partie des objectifs de Reflex. Le projet Reflex-platform permet de compiler pour du natif, du web, android et ios (https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.md). Perso, je trouve que Reflex n'est pas complètement trivial et qu'il faut prévoir un peu de temps pour l'apprendre correctement, mais Reflex-platform peut aussi compiler du Miso; c'est peut-être un bon compromis (https://github.com/dmjio/miso/issues/367).
Pour immuable/immutable, oui c'est le même concept. Je crois que ce sont vraiment des synonymes mais immutable, ça fait un peu anglicisme.
[^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 0.
Bon d'accord, tu as raison : C++ est un langage géré n'importe comment, qui provoque systèmatiquement des fuites mémoires, qui n'a pas d'outils d'analyse corrects et qui fait du lobbying pour empêcher le monde d'utiliser d'autres langages bien meilleurs. Allez salut.
[^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust
Posté par nokomprendo (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.
Mais de quoi tu parles ? Il n'est pas question d'héritage, juste de faire une classe avec le pointeur en attribut privé, le create dans le constructeur et le delete dans le destructeur. Quand à "l'overhead" Rust est le premier à dire qu'il a les performances de "C++ avec le même niveau de vérification".