BlueDian a écrit 28 commentaires

Et je conseillerais aussi de déclarer variable en volatile

Merci pour ces exemples. C'est très parlant sur les possibilités de remarks.js.
Je vais (re)tester de ce pas.
Pour ma part, j'utilise qq chose de très similaire à remarks en ce moment, il s'agit de reveal.js, toujours du markup, mais que je génère depuis emacs (plus exactement un addon à org-mode le fait pour moi).

Bravo aussi pour la qualité des supports. Je trouve vos transparents particulièrement bien faits (pour en avoir fait sur les mêmes sujets et avec les mêmes choix de solution d'ailleurs, je trouve les vôtres bien meilleurs :-) ), certains sont peut-être parfois un peu denses à mon goût (mais les goûts et couleurs…).

Cela mériterait d'en faire des sous-partis dédiées (make, test unitaire, doxygen, astyle…) qui pourraient intéressées beaucoup de monde.

Merci pour ce complément d'informations

Re,

Je viens de comprendre grâce à wikipedia.

Meltdown utilise le fait que effectivement le micro-code peut faire l’accès à la mémoire avant que l'IT se déclenche (et interdise effectivement l'utilisation/visualisation de cette adresse), mais il la laisse qd même dans le cache (même si personne ne pourra en lire la valeur directement).

Mais le mal est fait car si on veut réutiliser cette adresse, le proc la prendra dans son cache et donc plus vite qu'une autre s'il devait aller la chercher en mémoire centrale.

L'astuce est d'utiliser cette adresse mémoire de manière détournée (dans un adressage indirecte par exemple).
On va dire pour mieux comprendre que l'on a droit de lire au-dessus de 0x500, mais pas entre 0x200 et 0x300. Et on veut pourtant connaître ce qui est contenue en 0x200 (supposons la valeur 10)

Il y a donc un premier programme qui va demander d'accéder par indirection à la mémoire en 0x500 + [la valeur contenue en mémoire 0x200]
Ce programme va être interrompu car on a pas le droit d'accéder en 0x200, mais il aura bien accéder à cette mémoire (en 0x510) et aura mis son contenu dans le cache…

Et ensuite un second programme qui lui va comparer les temps d’accès des mémoires de 0x500 à 0x600 (par exemple)
et par une mesure de leurs temps d’accès, on saura que l’accès à 0x510 est plus rapide, donc 0x200 contenait la valeur 10…

C'est le principe, bien sur il faut prendre en compte les tailles des pages and co…

C'est là où je ne comprend pas un truc : normalement la MMU bloque l’accès (même si c'est en lecture) à des pages interdites, je comprend pas comment le CPU peut éviter ainsi la MMU.

Merci pour tes réponses, je vais de ce pas essayer ;-)

Merci pour cet article, car je suis dans la même recherche que toi, mais tu as été beaucoup plus loin dans l'évaluation des différents modes possibles.

Comme toi, j'aimerais aussi arriver à une gestion plus simple (et moins fatiguante en terme d'activation) des raccourcis claviers, et en minimisant aussi l'effort de mémorisation.

Dans ta recherche, as tu aussi fait une comparaison des mode de gestion des menus/choix/complétion entre Lacarte/Icicles, ido, helm ou les keychord like ?

Pour ma part, je suis actuellement en période d'essai sur spacEmacs (sur une machine), mais en étant dans le mode, pardon style, non modal de spacEmacs (ou dans le style dit hybride). Je suis plutôt content aussi de l'utilisation de which-key car pas besoin de tout re-documenter.

Hydra, effectivement c'est une autre histoire pour l'aspect performance.

Un des autres points fort de spacEmacs est la gestion des configurations, la même chose est en cours de réflexion pour Nu-Mode ?

Gros utilisateur d'org-mode et de yasnipet, je suis justement content que spacEmacs est des trucs prévus par défaut, c'est prévu pour Nu-mode ?

En fonction de tes réponses, je ferais certainement un essai de ce mode.

Impressionnant !
En espérant qu'il s'intéresse aussi à l'un des problèmes d'Emacs, faire en sorte qu'il devienne multi-thread. Mais bon, cela ne touche pas que le cœur en C d'Emacs.

Bonjour,

Cela ressemble effectivement à de l'IDM (Ingénierie Dirigé par les Modèles) ce que tu fait, mais sans en reprendre le vocabulaire. Du coup, c'est effectivement pas si simple de comprendre ce que réalise ton/tes outils. Pourrais tu donner plus d'informations sur ta réalisation par rapport à ceux déjà existants du domaine de l'IDM.
Pourrais tu aussi donner des liens web sur ta techno, un exemple serait parfait.

Si tu es toujours à Rennes, tu as de la chance car il y a une grosse communauté de l'IDM la-bas, mais aussi dans l'ouest (Brest, Nantes), avec pas mal d'outils développés dans cette région de France (ATL, Kermeta, Sodius…).

Je suis utilisateur depuis de nombreuses années d'org-mode, et je n'en ai pas encore fait le tour…
Sa communauté est extrêmement dynamique et tous les mois des nouveautés sympas apparaissent.

Un des aspects d'org-mode que j'aime beaucoup et qui n'a pas encore été présenté : c'est le mode babel. on peut ajouter des blocs de code (shell, lisp, ruby, python, R, ditaa, plantUML….) dans son texte et les rendre exécutables, appelez ces blocs de code entre eux en leur passant des attributs (et donc mélanger différents bouts de code écrits dans différents langages).

J'utilise beaucoup cet aspect pour de la programmation littéraire et commenter, par exemple, mes process d'installation.

En tant qu'enseignant, c'est plutôt pratique, et je peux générer très facilement du beamer (avec la génération de dessin décrit de manière textuel, voir plantUML ou ditaa par exemple).

Pour des exemples de babel, voici un lien sur le tutoriel de babel.

Pour les rétifs à Emacs et ses raccourcis de commandes complexes, et qui préfèrent une approche à la vim, je vous conseille spaceEmacs, installation et configuration simplifié et vous retrouvez les raccourcis vim.

Bonjour,

Plus d'infos (et de liens) sur le logiciel dans les Tesla ?
Je cherche des informations sur le sujet, mais je n'ai pas trouvé grand chose jusqu'à maintenant.

L'auteur de PlantUML est très réactif et peut prendre en compte tes propositions d'améliorations (quand cela demande pas de grosses modifications de code, c'est souvent immédiat). L'auteur principal est français.

Je suis moi aussi un très gros utilisateur de plantUML car on peut l'intégrer dans une multitude d'outils (d'Emacs à libreOofice en passant par doxygen ou les wiki) et sa syntaxe est simple à assimiler. De plus, il couvre une très grande partie d'UML.

Concernant les diagrammes de séquence, effectivement, tu ne peux pas croiser tes messages, par contre, tu peux modéliser la perte de message (transition puit et source possible).
Pourquoi as-tu besoin de croiser tes messages (les relations d'ordres entre les messages UML sont toujours partielles, selon la norme) ?

Super, merci !

Guide sympa en plus !
Après une lecture en diagonale, je vais peut être enfin me décider à tester yocto !

Pour ma part, j'y vois un intérêt, à ma connaissance, OpenCV n'a pas un front end graphique très pratique (il faut plutôt passer par exemple par Qt), cette solution peut être vue comme une alternative.
Il y a parfois juste besoin d'une IHM simple dédiée pour des analyses d'images adaptées à un domaine donné (par exemple, comptez des impuretés dans une image venant d'un microscope).

Ou pas. C'est un détail d'implémentation

Je ne suis pas d'accord, pour moi, c'est justement la grande différence entre un sémaphore booléen et un mutex :
- https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-mutex/
- https://en.wikipedia.org/wiki/Semaphore_%28programming%29#Semaphores_vs._mutexes

Maintenant que certaines implémentations, pour des raisons d'optimisation (pas besoin de 2 classes/entités différentes entre un semaphore binaire et un mutex), te permettent de faire les deux avec une seule entité, pourquoi pas.

Bonjour,

Je ne suis pas certain de bien comprendre toutes tes remarques. Or, vu ton expérience d'ex mainteneur d'un framework d'objet actif, j'aimerais être certain de bien comprendre tes remarques.

Un objet actif c'est masquer derrière un proxy ayant une sémantique orientée objet quelque chose qui ne l'est pas du tout (appel de méthode local synchrone VS dispatch distant asynchrone).

Pour moi, les com entre objets actifs sont toujours asynchrones (par exemple par envoi de message dans des boites aux lettres). Tu es d'accord avec cela ?
Si oui, en gardant cette analogie avec les BAL, puis-je considérer que le proxy, c'est celui qui ecrit dans la BAL (ou les BAL) de l'objet actif (ou des objets actifs) les messages, c'est bien cela ? L'objet actif lui est en attente en lecture sur sa BAL. Des qu'un message arrive, il le traite alors et exécute ou non ses propres méthodes internes.

Bref, pour moi, cela reste fondamentalement asynchrone et très conception orienté objet (En conception OO, les objets communiquent par envoi de message).

C'est grosso modo le même problème que les systèmes de type RPC, connu depuis très longtemps mais après 20 ans on arrive toujours au même conclusion.

Du coup, je ne comprend pas cette comparaison avec le RPC (qui est pour moi une com synchrone, on reste dans l'appel de méthode avec attente, qu'il soit distant ou non).
Surtout que dans l'article que tu donnes, ce qu'ils me semblent critiquer dans le RPC, c'est justement cette volonté de vouloir conserver l'illusion du synchronisme alors que dans un monde distribué, c'est plutôt l'asynchrone qui est de mise.

Effectivement, ce postulat d'asynchronisme des com oblige le concepteur à penser à pas mal de chose (par exemple, tout besoin de com synchrone doit être transformée en 2 com asynchrone). Ce travail supplémentaire, c'est cela que tu critiques ?
Pour ma part, je trouve cela justement bien car on ne laisse rien d'implicite.
Et du coup, je comprend pas ta remarque sur les erreurs (j'imagine de com). Car pour moi, elles doivent être gérées par le concepteur (avec des com asynchrone, on n'a pas de garantie sur la réception du message, plus précisément par sa prise en compte par l'appelé). Il n'a pas le choix, et je ne comprend pas ta remarque sur ce pb de la gestion des erreurs.

Un modèle à objet actif, je veux bien au sein d'un unique processus mais ça me semble un mauvais compromis, vu que t'as le pire de deux mondes entre un truc mono-process bien designé qui va vite et une abstraction solide pour exprimer du parallélisme potentiellement distribué.

La non plus, je ne comprend pas trop le problème. Pour moi, un objet actif ne présente justement que des avantages pour passer à du multi-tâche car il permet d'isoler les parties ayant un vrai besoin de parallélisme (par rapport à la logique métier de l'applicatif). Ensuite, le mapping un objet actif = un thread/process/tache n'est pas toujours aussi simple certes, mais cela marche souvent.

[Note: vision biaisée d'un ex-mainteneur d'un framework à objet actifs…]

Ca m'intéresse de savoir lequel car utilisant celui de Quantum Leap (voir lien donné dans mon post précédant), je le trouve super et ne vois pas trop de problème.

Effectivement la description comportementale n'est pas forcément une machine à état.
Je trouvais pratique d'en parler pour décrire le principe de fonctionnement de l'objet actif (en me basant sur les notions classiques des MAE : événement, transition et etat).

Moi aussi, je suis un grand fan des objets actifs.

Je continue dans mes remarques sur ce texte.

Concernant les approches "objets actifs", plus que l'aspect message (qui n'est qu'un moyen de communiquer entre objet), j'insisterai plus sur l'aspect comportement et événement des objets actifs.
A un objet actif est associé une description comportementale (une machine à état typiquement) qui explique comment l'objet réagit (ou non) à des événements (internes ou externes). Effectivement, l'arrivé de message (envoyé par d'autres objets) génère un événement. Mais ce n'est qu'un sous ensemble des événements possibles arrivant sur l'objet actif.
Concrètement, un événement déclenche le franchissement d'une transition, franchissement déclenchant des actions de l'objet. L'arrivée ou la sortie d'un état peuvent aussi déclencher des actions.

Ces approches sont effectivement très intéressantes, mais ont aussi des limites : par exemple, impossible d'avoir des traitements bloquants lors des franchissements de transitions. Cela nécessite un certain soin dans leur conception.

Des framework ont été développés pour ce genre d'approche quand le langage de programmation utilisé ne supporte pas les concepts nativement. En C/C++, je suis assez fan de http://www.state-machine.com/psicc/.

Merci pour ce texte.
Puisque ce texte se veut avant tout didactique et pédagogique, cela mériterait d'être plus précis sur les différences entre verrous, sémaphore et mutex, surtout que le bout de code donné en exemple (tant que …) ressemble plus à une attente active…
Or l’intérêt du sémaphore, c'est justement d'endormir le tread/processus appelant si le sémaphore est vide. Du coup, une présentation des primitives P et V peut alors être utile.

Un mutex est lui aussi un sémaphore binaire, mais qui connaît celui qui possède son jeton. Il n'y a donc pas de blocage si un même thread tente de prendre plusieurs fois le même mutex (sans l'avoir libérer auparavant). Avec un sémaphore binaire, vous vous retrouveriez bloqué…

Je salue cette initiative, car quand on est, par exemple, malvoyant ou aveugle, et bien, ce n'est pas simple (quasiment impossible ?) de passer à du Linux sans aide extérieure. De plus, cette aide doit être spécifique et adaptée à ce type de public. Cela nécessite aussi tout un travail d'adaptation de l'environnement (raccourcis, configuration…).

En outre, si cette société contribue, comme elle l'indique sur son site web, au développement de logiciel libre et leur adaptation pour le public visé, je trouve cela encore mieux. Cela permet d'envisager une pérennisation de votre solution et son amélioration.

Tous mes veux de réussite à vous !

Merci pour ce super article.

Très bonne idée ! Je serais aussi très intéressé par un programme indépendant, pour parser du latex ou un texte brut !

Merci pour ta réponse. J'avais bien lu ta partie motivation.
Mon interrogation était que, comme dans les vieux éditeurs (Emacs par exemple), toutes les fonctionnalités que tu as développées (accès à des terminaux, parcours de documents html, pdf et man, parseur générique…) sont déjà dispo, je cherchais à connaître les raisons qui t'ont poussé à redévelopper des choses déjà existantes. Cela pourrait être la non connaissance de ces fonctionnalités dans ces "vieux" éditeurs, le plaisir de développer, le fait que ces vieux éditeurs sont trop basés sur des raccourcis clavier, la complexité de leur paramétrage… ou peut être tout autre chose ?

Et dans la première partie de ton post, on peut trouver des trolls aussi ? :)

On peut aussi ;-), mais je suis vraiment intéressé par la réponse de l'auteur sur ses motivations à développer ce type d'éditeur.

Bonjour,

Marrant de voir ton éditeur, cela ressemble à ce que emacs (voir même vi) font depuis 30 ans.
Pourquoi as tu décidé de la faire, pour le fun ou pour d'autres raisons ?
Plus dans une approche clickodrome que raccourcis clavier ?

---

Sinon, comme on est vendredi, je résiste pas pour la suite.
Trouverez vous le nombre de trolls cachés dans la suite de ce post ?

On peut diviser les programmeurs selon leur façon de travailler en deux trois quatre catégories :
1. ceux qui utilisent un IDE : un environnement de développement complet.
1. ceux qui travaillent avec des outils séparés : un éditeur de texte, usage du terminal et autres outils.
1. ceux qui utilisent un IDE et des terminaux, et un éditeur de texte, et d'autres outils.
1. ceux qui utilisent Emacs, un vrai éditeur de texte sachant dialoguer avec des outils externes

Allez, je retourne dans mon emacs ! Ah, ben je l'avais même pas quitté en fait ;-)

Bravo pour ce texte !
Joli exploit d'avoir aussi bien résumé ces différentes extensions.
J'attends avec impatience la suite, dont le formidable org-mode (pas simple à synthétiser, rien que sur babel, il y a de quoi faire ;-) ).