Ça tient de la poésie autant que du génie logiciel.
Je n'avais pas vu ça comme ça, plus comme "un truc de geek" :-P
L'unité, c'est la fusion de tout cela et de plus, et même un maximum. Certains éléments n'ont par nature pas de place dans le navigateur (l'interface matérielle surtout) mais tout ce qui peut y entrer y ira. En fait, plein d'initiatives de ce style voient le jour depuis plusieurs années (Chrome OS, Mozilla et son Boot To Gecko, et d'autres encore), et donc pour une fois je me retrouve à l'avant de la vague technologique…
Dans le site, il y a toute la gestion de la documentation, la gestion des E/S fichiers (les entrées sont à refaire mais on peut sauver des fichiers), les outils de programmation en assembleur, et plus tard en graphique avec GNL puis en textuel avec des frontends HLL pour générer du GNL à partir de C/Pascal/FORTH/ce qu'on veut…
Actuellement je travaille sur le simulateur. Il se repose à la fois sur l'assembleur, l'éditeur et d'autres fonctionnalités développées pour les autres fenêtres : plus on ajoute de fonctions, plus le développement des autres pièces est facile et l'ensemble gagne en utilité et puissance. Pour le F-CPU, tout était distinct et donc pénible et désynchronisé, là une petite modif, on sauve et on recharge la page : tout est mis à jour automatiquement. Ah oui, mes 2 outils sont nano et grep :-)
Donc le principe de l'unité c'est de faciliter le développement. Un peu comme Linux et le système GNU, qui ont été conçus pour un développement facile, conçus dans l'optique de leur propre maintenabilité, ce qui favorise le développement des versions et du contenu et forme un système auto-entretenu. L'inventaire de Prévert n'a pas de cohérence apparente ou directe, alors que chaque fenêtre ou module ajouté au site augmente son utilité et utilisabilité, sert à quelque chose et même est nécessaire.
Le principe c'est aussi d'éviter au maximum d'installer des outils externes. C'est l'un des freins majeurs pour l'adoption d'un nouveau système. Installer, adapter, configurer, apprendre à se servir de, puis faire communiquer avec des outils parfois disparates… Si tout est intégré, alors l'installation se résume à avoir un navigateur "correct" (plus un Apache+PHP pour certaines fonctions annexes, et qqs petits trucs que je prépare). Ce qui revient au mantra "utilité et utilisabilité".
Il y a encore 10 ans je voyais JavaScript comme une plaie à éviter à cause de toutes les failles de l'époque et sa lourdeur pour le CPU. Avec les multicores actuels et les optimisations dynamiques, la situation a radicalement changé : notre Bellard national boote Linux dans votre navigateur http://bellard.org/jslinux/ et les jeux prolifèrent (en commençant par http://www.elizium.nu/scripts/lemmings/ ) donc tant qu'on n'a pas besoin de l'ultime performance, pourquoi embêter les gens en les forçant à installer X ou Y, compiler Z et râler à cause de telle ou telle librairie ? Personne ne fait d'effort de nos jours donc l'accessibilité est cruciale pour que les gens commencent à explorer à leur manière : en cliquant.
Ensuite, quelques réponses plus directes :
à maturité, je pense que le microcontrôleur continuera d'être "packagé" avec l'interface. C'est modulaire donc on peut séparer des trucs sans rien casser, comme prendre le contenu du dossier http://yasep.org/VHDL/ pour ne garder que les sources VHDL, ou récupérer YGWM pour faire d'autres sites (Laura utilise déjà YGWM pour coder http://ygllo.com/~llo/MetaFor/code/page_centrale.html ) donc ça dépend de ce dont on a besoin. Mais le tout forme un ensemble cohérent et je ne vois pas d'intérêt à découper.
Je ne suis pas sûr de comprendre ce que "son architecture finalisée" veut dire. Une architecture évolue naturellement, et avec un toolkit comme celui-ci, encore plus vite :-)
Qu'est-ce qu'on programme sur un microcontrôleur ? plein de choses… Par exemple le YASEP a eu un coup de boost lorsque j'ai songé l'utiliser pour un gros projet, où il aurait généré des séquences de signaux pour contrôler des LEDs de puissance. Si les mots "arduino", "PIC" ou "AVR" vous disent quelque chose, ça vous aidera à comprendre l'intérêt du microYASEP actuel. Le YASEP original avait été prévu pour gérer un SystemOnChip multimédia… et peut être utile en robotique.
Le framework est modulaire et pensé dès le début pour supporter d'autres architectures, par contre il faut forker pas mal de fichiers. Evidemment l'assembleur et la documentation devront être refaits et plein d'aspects doivent être adaptés… mais le framework seul ne tient pas debout, j'ai quelques exemples de code de démo mais ils ont juste un intérêt pour les programmeurs JavaScript.
Pour la dernière question, c'est déjà plus ou moins expliqué. Ensuite, j'ai fait ce qui est possible facilement, pratique, portable et dont les gens sont habitués.
[^] # Re: étonnant
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 7.
Bonjour Sygne,
Je n'avais pas vu ça comme ça, plus comme "un truc de geek" :-P
L'unité, c'est la fusion de tout cela et de plus, et même un maximum. Certains éléments n'ont par nature pas de place dans le navigateur (l'interface matérielle surtout) mais tout ce qui peut y entrer y ira. En fait, plein d'initiatives de ce style voient le jour depuis plusieurs années (Chrome OS, Mozilla et son Boot To Gecko, et d'autres encore), et donc pour une fois je me retrouve à l'avant de la vague technologique…
Dans le site, il y a toute la gestion de la documentation, la gestion des E/S fichiers (les entrées sont à refaire mais on peut sauver des fichiers), les outils de programmation en assembleur, et plus tard en graphique avec GNL puis en textuel avec des frontends HLL pour générer du GNL à partir de C/Pascal/FORTH/ce qu'on veut…
Actuellement je travaille sur le simulateur. Il se repose à la fois sur l'assembleur, l'éditeur et d'autres fonctionnalités développées pour les autres fenêtres : plus on ajoute de fonctions, plus le développement des autres pièces est facile et l'ensemble gagne en utilité et puissance. Pour le F-CPU, tout était distinct et donc pénible et désynchronisé, là une petite modif, on sauve et on recharge la page : tout est mis à jour automatiquement. Ah oui, mes 2 outils sont nano et grep :-)
Donc le principe de l'unité c'est de faciliter le développement. Un peu comme Linux et le système GNU, qui ont été conçus pour un développement facile, conçus dans l'optique de leur propre maintenabilité, ce qui favorise le développement des versions et du contenu et forme un système auto-entretenu. L'inventaire de Prévert n'a pas de cohérence apparente ou directe, alors que chaque fenêtre ou module ajouté au site augmente son utilité et utilisabilité, sert à quelque chose et même est nécessaire.
Le principe c'est aussi d'éviter au maximum d'installer des outils externes. C'est l'un des freins majeurs pour l'adoption d'un nouveau système. Installer, adapter, configurer, apprendre à se servir de, puis faire communiquer avec des outils parfois disparates… Si tout est intégré, alors l'installation se résume à avoir un navigateur "correct" (plus un Apache+PHP pour certaines fonctions annexes, et qqs petits trucs que je prépare). Ce qui revient au mantra "utilité et utilisabilité".
Il y a encore 10 ans je voyais JavaScript comme une plaie à éviter à cause de toutes les failles de l'époque et sa lourdeur pour le CPU. Avec les multicores actuels et les optimisations dynamiques, la situation a radicalement changé : notre Bellard national boote Linux dans votre navigateur http://bellard.org/jslinux/ et les jeux prolifèrent (en commençant par http://www.elizium.nu/scripts/lemmings/ ) donc tant qu'on n'a pas besoin de l'ultime performance, pourquoi embêter les gens en les forçant à installer X ou Y, compiler Z et râler à cause de telle ou telle librairie ? Personne ne fait d'effort de nos jours donc l'accessibilité est cruciale pour que les gens commencent à explorer à leur manière : en cliquant.
Ensuite, quelques réponses plus directes :
à maturité, je pense que le microcontrôleur continuera d'être "packagé" avec l'interface. C'est modulaire donc on peut séparer des trucs sans rien casser, comme prendre le contenu du dossier http://yasep.org/VHDL/ pour ne garder que les sources VHDL, ou récupérer YGWM pour faire d'autres sites (Laura utilise déjà YGWM pour coder http://ygllo.com/~llo/MetaFor/code/page_centrale.html ) donc ça dépend de ce dont on a besoin. Mais le tout forme un ensemble cohérent et je ne vois pas d'intérêt à découper.
Je ne suis pas sûr de comprendre ce que "son architecture finalisée" veut dire. Une architecture évolue naturellement, et avec un toolkit comme celui-ci, encore plus vite :-)
Qu'est-ce qu'on programme sur un microcontrôleur ? plein de choses… Par exemple le YASEP a eu un coup de boost lorsque j'ai songé l'utiliser pour un gros projet, où il aurait généré des séquences de signaux pour contrôler des LEDs de puissance. Si les mots "arduino", "PIC" ou "AVR" vous disent quelque chose, ça vous aidera à comprendre l'intérêt du microYASEP actuel. Le YASEP original avait été prévu pour gérer un SystemOnChip multimédia… et peut être utile en robotique.
Le framework est modulaire et pensé dès le début pour supporter d'autres architectures, par contre il faut forker pas mal de fichiers. Evidemment l'assembleur et la documentation devront être refaits et plein d'aspects doivent être adaptés… mais le framework seul ne tient pas debout, j'ai quelques exemples de code de démo mais ils ont juste un intérêt pour les programmeurs JavaScript.
Pour la dernière question, c'est déjà plus ou moins expliqué. Ensuite, j'ai fait ce qui est possible facilement, pratique, portable et dont les gens sont habitués.