Salut !
Merci du partage, je trouve l'article bien complet, il suscite l'espoir que nous aussi on peut y arriver :) Je l'ai lu plusieurs fois en diagonale mais je vais essayer de m'y plonger sérieusement.
Cependant j'ai eu l'impression que les détails et le contexte sont inversés, par exemple tu expliques comment trouver la carte utilisée après avoir donnés des listing de code (je sais on appelle pas ça comme ça en vérilog mais j'ai oublié).
Et je crois que les explications et exemples de taptempo sont données après ces listings. Perso j'ai pas réfléchi de suite à ce que ça pouvait être et j'ai cherché dans ton article de quoi il en retournait.
Aussi pour le matériel de brocante que tout le monde n'a pas, on peut très bien le remplacer par un petit bouton poussoir et un simple multimètre numérique, voir couplé avec une capacité pour lisser un peu la pwm, n'est-ce pas ?
Je connais quelqu'un qui subit la décision de la direction d'intégrer un framework de chez Intersystem : l'object script
Le framework "évolue" en assurant la rétrocompatibilité sur des décennies…
Il m'a montré comment coder une boucle for et la manipulation de script : de l'obfuscation en puissance.
Je travaille dans la périphérie de saint Étienne (lieu du poste). Mais du bon cote, donc je reste a moins de 20 minutes en voiture du travail (sauf que bouchon le matin donc plutôt 30)
La gare est a deux minutes a pied de chez Moi, mais ma femme préfère le bus car plus fiable hélas.
La nouvelle ligne de tramway va passer juste devant mon taf, donc théoriquement je suis a 30 minutes du taf correspondance inclus
Suis content d'être sorti de la ville : je suis toujours dans un milieu urbain avec des commerces a proximité, 1000 m2 de terrain dans une impasse me règle le PB du vis a vis. Le climat est aussi meilleur car nous sommes en plaine
Jamais je ne monterai sur Paris ou sa périphérie.
Je suis content pour ceux qui négocie du remote dans cette région, j'espère en avoir dans les années a venir, apres 15 ans de la boîte ça devrait être possible.
Et près de mon taf c'est le technopole c'est pas pratique et assez vilain pour du résidentiel
J'ai bien apprécié la note et les commentaires, qui m'ont donné d'autres pistes pour la réalisation d'une box domotique.
Je voulais connaître les performances d'isolation de ma maison dans le temps, et selon l'humidité, pour avoir une idée du bon moment pour lancer mon poele à granules.
Il y a bien la station netatmo mais je trouve que ça douille.
Je voulais bien essayer de les bricoler moi-même mais je voulais me rapprocher des interfaces "standardisées".
Dans les derniers liens sur les comm' on a des capteurs RF dans des boitiers à 10 $ environ.
Et puis des procédés de fabrication & d'assemblage à porté de main pour un bricoleur occasionnel.
cool donc :)
Par contre en interne dans ma boite sur une pré-étude il s'est avéré que l'ESP32 serait à préférer aux 8266, qui le remplacerait pour pas cher (3e le module), et est beaucoup plus puissant tout en présentant la possibilité de faire du bluetooth…. Texte du lien
La réalité peut-être autre pour le grand public…
Bonjour,
Merci de cette réponse.
De ma petite expérience Frama-C (Linux Mag), on visait beaucoup plus haut. Je vois la norme MISRA-C comme l'un des premiers échelons de garantie de qualité du code, connu de tous (puisque c'est une norme).
Et c'est n'est pas si simple a appliquer dans mon cas, sans passer par une revue de code.
Qu'on me corrige si je me trompe mais pour moi cet outil ce rapproche plus de frama-C que de cppcheck.
De souvenir avec Frama-C il fallait écrire du code pour l'analyse de source. Mais enfin c'était peut-être pour des fonctions de "couverture de code".
Pour de l'embarqué (monde des uC) c'est toujours compliqué vu que l'on a des dépendances sur le matériel, et que l'outil qui s'exécute sur le PC ne peut réaliser une analyse complète (j'ai vu que ces analyseurs compilait le code).
Pour moi l'intérêt serait confirmé si l'outil pouvait répondre la conformité du code par rapport à la norme MISRA-C. Et forcément ça demande plus que de la détection de bug/faille.
On ajoutera à ça le besoin d'avoir des métriques "personnalisées" dans les métriques.
Pour un client j'avais utilisé OClint :
- analyse statique basée sur LLVM
- système d'intégration de métriques personnalisée sous la forme d'un fichier de conf et de DLL permettant de vérifier la convention de nommage et autres regles basées sur des regex permettant d'analyser l'AST généré ou le nombre cyclomatique d'une fonction.
- à ça vous ajoutez la génération d'un rapport type tableur pour toutes les anomalies, que l'on pouvait trier par niveau de gravité.
Pour l'analyse statique, comme il fallait compiler les fichiers que l'on avait un projet type 'Makefile générique', on a utilisé bear pour générer une base JSON de compilation de fichiers individuel (que sait générer cmake).
Ca marchait très bien sous Linux x86.
Mais voilà pour de l'embarqué uC ca perd de sa saveur car la compilation n'est plus possible à moins d'avoir un LLVM configuré pour la cible ou un code source instrumenté pour permette une analyse partielle.
On doit avoir le même pb avec cet outil non ?
Bon c'est exact, il n'a pas dit exactement que ça ne marchait pas, mais simplement que le projet n'était pas dans le but d'offrir quelque chose de plus stable, mais de plus rapide. Donc il a supposé que Meson n'a pas été écrit dans le but de corriger les problèmes constatés par ailleurs et que cela ne valait pas la peine de l'essayer.
Concernant le tour des solutions existantes, Meson a déjà été cité par ici
Et le problème c'était que ça ne marchait pas ! L'article étant de 06/2018, écrit par apparemment un habitué des builds multi-plateformes je me pose quelques questions, bien que vous listiez en fin un liste de success stories.
Je n'ai pas de problème à l'utilisation des autotools,
et je dirais même que l'utilisation des autres outils suit sensiblement les mêmes étapes.
Le problème c'est de packager avec les autotools : il te faut maitriser plusieurs langages (M4, Make, bash, et je crois encore un autre…) dont certains ne vont servir qu'à ça.
CDT est un outil très populaire finalement, il est utilisé par beaucoup de distributeurs qui intègrent leur SDK à Eclipse.
Portable : oui et non….
Nous l'utilisons indirectement, les conf de build doivent être adaptées pour la personne qui build sous Linux.
A l'époque les makefiles générés utilisait des chemins en absolu, ce qui rendait impossible l'usage d'un script pour la compilation en CLI, sur un autre poste.
Maintenant je ne sais pas je n'ai pas trouvé les Makefile ("internal builder is used, generate Makefile automatically")
Très intéressant comme retour d'expérience, as-tu testé également qmake ? il est certe associé à Qt mais peut-être utilisé pour un projet indépendant il me semble.
Lui aussi dispose d'outils pour gérer du multi-plateforme puisque c'est également l'objectif du framework d'être présent sur les OS desktop/mobiles.
Je suis plutôt d'accord avec les évaluations des autotools, make et cmake.
Make reste un bon candidat pour des petits projets, c'est simple pratique. Si on a déjà notre "makefile générique" on s'en sort à bon compte. Sous windows il m'est arrivé d'utiliser "git bash" couplé à mingw pour une génération à base de Makefile.
Les autotools c'est l'usine à gaz avec en plus les syntaxes à maîtriser : M4, bash, Make, etc…
L'on m'avait dit à l'époque que c'était plus pour gérer les chaînes de compilation UNIX que les OS, ce qui explique pourquoi Windows est très mal supporté (ou pas du tout) et tout le travail du configure de vérifier les capacités de la chaîne de compilation.
cmake je m'en suis juste servi à l'occasion et j'ai trouvé ça plus "fonctionnel", plus abordable, avec la capacité à générer des fichiers projets pour nos IDEs.
Je trouve cela bien de partager d'autres carte pour un prix équivalent.
Mais je pense qu'ici on vend non seulement la carte mais mais aussi la mise en oeuvre complète d'un solution répondant à ce qui est exigé (à mon avis) pour le l'IoT.
Si je paie 25e et que je veux apprendre à concevoir ce type de carte, je peux espérer plus d'aide ici qu'en achetant un produit bon marché à 10e vendu sur un site chinois.
Je dis pas que les sites chinois font de la mauvaise cam, mais que la barrière de la langue et le profil du vendeur feront que vous devrez surement vous débrouiller avec ce que vous avez.
Quand au masquage des ITs pour protéger l'intégrité d'une variable, c'est en règle général vrai de la protéger mais tout dépend de ce que l'on fait…
- C'est vrai si l'on écrit sur cette donnée à partir d'un calcul qui utilise sa valeur courante.
- C'est un peu moins vrai si d'un côté on se contente d'écrire une valeur déterminée (0)
- Ca l'est encore moins quand on écrit sur la donnée d'un côté et que l'on se contente de la relire de l'autre (exemple des FIFOs non bloquante producteur/consommateur).
Il faut rappeler aussi que l'usage des mutex ou verrou bloquant est réservée interthread, et que l'IT devra utiliser les routines non bloquantes.
Attention aussi en masquant une IT, on peut désactiver plusieurs traitements qui ne sont pas concurrents, ou exposer une zone critique lorsque l'on réactive l'IT alors qu'il ne le faudrait pas (car le contexte appelant a désactivé l'IT).
Je voulais juste signaler que ST à racheté Atollic qui développe l'IDE Atollic TrueStudio, beaucoup plus plébiscité dans le monde professionnel.
Cette IDE est maintenant distribuée dans sa version qui est était alors une pro (analyse hard fault, des viewer de consommation mémoire, etc….).
C'est aussi une IDE basée sur Eclipse + CDT
Je la conseillerai plutôt car :
- maintenant l'IDE officielle
- plus stable à l'usage
- Linux / Windows officiellement supporté.
Je conseillerai aussi d'utiliser STMCube (HAL et middle ware) et son configurateur CubeMX, sachant que le toolkit graphique emwin est distribué gratuitement par le biais de ST, et que son forum officiel est bien actif.
Le configurateur MX à quelques défauts, mais il vous permet de configurer simplement les clocks, d'activer ou pas les périphériques, et de générer le projet atollic pour de nombres cartes comme la Nucléo.
Quand j'ai lu la dépêche, pour moi clairement Gimp va reposer sur des architectures modernes, et commencer boiter sur des plus anciennes.
Par exemple créer des threads utilise des ressources, car ta CPU au simple coeur va passer du temps à switcher entre eux.
Idem avec l'utilisation de ressources matérielles….
Bon mais s'il existe un paquet précompilée pour ta machine (ou si tu souhaites le compiler) ça vaut le coup d'essayer, car en effet c'est plus intéressant un atelier découverte avec un outil récent.
J'ai juste remarqué que l'on parlait de classes bilingues Français-Breton (il ne faut pas une majuscules), et après vérification sur Wikipedia le Breton n'est pas juste un dialecte - comme je le croyais - mais bien une langue à part entière, du moins d'un point de vue "académique" puisque l'Etat refuse de se conformer à la loi Européenne en ce qui concerne les langues régionales. Il fait bien ce qu'il l'arrange avec l'Europe !
cloc utilise des expressions rationnelles, alors que Tokei a de vrais analyseurs
une expression rationnelle reste une méthode d'analyse après tout.
A préciser donc : "… lexicaux et syntaxiques" ?
Cela serait intéressant que tu explicites ce que tu sais ;).
J'utilise pour mes besoins pro/personnel : keepass2 (.net)
Comme j'ai un vieux mac book je me suis penché sur des alternatives car je ne suis pas arrivé à faire tourner keepass2 (avec Mono ou crossover) :
- j'ai utilisé keepassX, mais PB de compatibilité avec la bdd de keepass (il me semble que ce n'est plus le cas).
- keeweb en version webapp. Mais possibilité de l'utiliser en ligne
- keepass2 for android.
En plus des mots de passe j'utilise un fichier clé que je stocke sur un drive donc j'aime bien la possibilité de keeweb d'aller le chercher directement.
keepass2/firefox ont des extensions pour des échanges via clic-droit, mais je suis satisfait de l'auto-type avec ctrl+V.
J'ai bien essayé d'initier ma compagne à leur utilisation mais sa réaction c'est : "ppfffff … un mot de passe pour gérer des mots de passe… pffff".
# bon article
Posté par Selso (site web personnel) . En réponse à la dépêche TapTempo en Verilog. Évalué à 2.
Salut !
Merci du partage, je trouve l'article bien complet, il suscite l'espoir que nous aussi on peut y arriver :) Je l'ai lu plusieurs fois en diagonale mais je vais essayer de m'y plonger sérieusement.
Cependant j'ai eu l'impression que les détails et le contexte sont inversés, par exemple tu expliques comment trouver la carte utilisée après avoir donnés des listing de code (je sais on appelle pas ça comme ça en vérilog mais j'ai oublié).
Et je crois que les explications et exemples de taptempo sont données après ces listings. Perso j'ai pas réfléchi de suite à ce que ça pouvait être et j'ai cherché dans ton article de quoi il en retournait.
Aussi pour le matériel de brocante que tout le monde n'a pas, on peut très bien le remplacer par un petit bouton poussoir et un simple multimètre numérique, voir couplé avec une capacité pour lisser un peu la pwm, n'est-ce pas ?
cdlt,
[^] # Re: je sais pas vous...
Posté par Selso (site web personnel) . En réponse à la dépêche TapTempo en Verilog. Évalué à 3.
Bien tu cliques sur le lien en fin d'article…
# des problèmes dont on se passerait bien
Posté par Selso (site web personnel) . En réponse au journal J’ai testé pour vous : se faire usurper son identité. Évalué à 2.
Un grand merci pour ton retour d'expérience et surtout ton conseil !
Les échanges avec la police sont regrettables vraiment.
# objectscript par intersystem
Posté par Selso (site web personnel) . En réponse au sondage Quelle est la technologie la plus obsolète sur ou avec laquelle j'ai dû travailler récemment ?. Évalué à 1. Dernière modification le 13 décembre 2019 à 10:52.
Je connais quelqu'un qui subit la décision de la direction d'intégrer un framework de chez Intersystem : l'object script
Le framework "évolue" en assurant la rétrocompatibilité sur des décennies…
Il m'a montré comment coder une boucle for et la manipulation de script : de l'obfuscation en puissance.
[^] # Re: langage obsolète ?
Posté par Selso (site web personnel) . En réponse au sondage Quelle est la technologie la plus obsolète sur ou avec laquelle j'ai dû travailler récemment ?. Évalué à 0.
c'est vraiment ta pensée ou tu ironises ? j'ai un petite doute pardon si tu te sens insulté.
# De l'eloignement confortable
Posté par Selso (site web personnel) . En réponse au sondage Logement : pourquoi habite‐t‐on loin de son activité ?. Évalué à 1.
Je travaille dans la périphérie de saint Étienne (lieu du poste). Mais du bon cote, donc je reste a moins de 20 minutes en voiture du travail (sauf que bouchon le matin donc plutôt 30)
La gare est a deux minutes a pied de chez Moi, mais ma femme préfère le bus car plus fiable hélas.
La nouvelle ligne de tramway va passer juste devant mon taf, donc théoriquement je suis a 30 minutes du taf correspondance inclus
Suis content d'être sorti de la ville : je suis toujours dans un milieu urbain avec des commerces a proximité, 1000 m2 de terrain dans une impasse me règle le PB du vis a vis. Le climat est aussi meilleur car nous sommes en plaine
Jamais je ne monterai sur Paris ou sa périphérie.
Je suis content pour ceux qui négocie du remote dans cette région, j'espère en avoir dans les années a venir, apres 15 ans de la boîte ça devrait être possible.
Et près de mon taf c'est le technopole c'est pas pratique et assez vilain pour du résidentiel
# merci pour les commentaires
Posté par Selso (site web personnel) . En réponse à la dépêche Un thermomètre OSHW basé ESP8266. Évalué à 1. Dernière modification le 25 février 2019 à 11:05.
J'ai bien apprécié la note et les commentaires, qui m'ont donné d'autres pistes pour la réalisation d'une box domotique.
Je voulais connaître les performances d'isolation de ma maison dans le temps, et selon l'humidité, pour avoir une idée du bon moment pour lancer mon poele à granules.
Il y a bien la station netatmo mais je trouve que ça douille.
Je voulais bien essayer de les bricoler moi-même mais je voulais me rapprocher des interfaces "standardisées".
Dans les derniers liens sur les comm' on a des capteurs RF dans des boitiers à 10 $ environ.
Et puis des procédés de fabrication & d'assemblage à porté de main pour un bricoleur occasionnel.
cool donc :)
Par contre en interne dans ma boite sur une pré-étude il s'est avéré que l'ESP32 serait à préférer aux 8266, qui le remplacerait pour pas cher (3e le module), et est beaucoup plus puissant tout en présentant la possibilité de faire du bluetooth….
Texte du lien
La réalité peut-être autre pour le grand public…
[^] # Re: intérêt de l'outil limité pour de l'embarqué.
Posté par Selso (site web personnel) . En réponse au journal IKOS, un analyseur statique développé à la NASA. Évalué à 0.
Bonjour,
Merci de cette réponse.
De ma petite expérience Frama-C (Linux Mag), on visait beaucoup plus haut. Je vois la norme MISRA-C comme l'un des premiers échelons de garantie de qualité du code, connu de tous (puisque c'est une norme).
Et c'est n'est pas si simple a appliquer dans mon cas, sans passer par une revue de code.
# intérêt de l'outil limité pour de l'embarqué.
Posté par Selso (site web personnel) . En réponse au journal IKOS, un analyseur statique développé à la NASA. Évalué à 1.
Qu'on me corrige si je me trompe mais pour moi cet outil ce rapproche plus de frama-C que de cppcheck.
De souvenir avec Frama-C il fallait écrire du code pour l'analyse de source. Mais enfin c'était peut-être pour des fonctions de "couverture de code".
Pour de l'embarqué (monde des uC) c'est toujours compliqué vu que l'on a des dépendances sur le matériel, et que l'outil qui s'exécute sur le PC ne peut réaliser une analyse complète (j'ai vu que ces analyseurs compilait le code).
Pour moi l'intérêt serait confirmé si l'outil pouvait répondre la conformité du code par rapport à la norme MISRA-C. Et forcément ça demande plus que de la détection de bug/faille.
On ajoutera à ça le besoin d'avoir des métriques "personnalisées" dans les métriques.
Pour un client j'avais utilisé OClint :
- analyse statique basée sur LLVM
- système d'intégration de métriques personnalisée sous la forme d'un fichier de conf et de DLL permettant de vérifier la convention de nommage et autres regles basées sur des regex permettant d'analyser l'AST généré ou le nombre cyclomatique d'une fonction.
- à ça vous ajoutez la génération d'un rapport type tableur pour toutes les anomalies, que l'on pouvait trier par niveau de gravité.
Pour l'analyse statique, comme il fallait compiler les fichiers que l'on avait un projet type 'Makefile générique', on a utilisé bear pour générer une base JSON de compilation de fichiers individuel (que sait générer cmake).
Ca marchait très bien sous Linux x86.
Mais voilà pour de l'embarqué uC ca perd de sa saveur car la compilation n'est plus possible à moins d'avoir un LLVM configuré pour la cible ou un code source instrumenté pour permette une analyse partielle.
On doit avoir le même pb avec cet outil non ?
[^] # Re: on en a déjà parlé dans la meson.
Posté par Selso (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 1. Dernière modification le 08 octobre 2018 à 17:08.
Bon c'est exact, il n'a pas dit exactement que ça ne marchait pas, mais simplement que le projet n'était pas dans le but d'offrir quelque chose de plus stable, mais de plus rapide. Donc il a supposé que Meson n'a pas été écrit dans le but de corriger les problèmes constatés par ailleurs et que cela ne valait pas la peine de l'essayer.
# on en a déjà parlé dans la meson.
Posté par Selso (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 2.
Concernant le tour des solutions existantes, Meson a déjà été cité par ici
Et le problème c'était que ça ne marchait pas ! L'article étant de 06/2018, écrit par apparemment un habitué des builds multi-plateformes je me pose quelques questions, bien que vous listiez en fin un liste de success stories.
[^] # Re: Un nouveau standard ?
Posté par Selso (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 2.
Je n'ai pas de problème à l'utilisation des autotools,
et je dirais même que l'utilisation des autres outils suit sensiblement les mêmes étapes.
Le problème c'est de packager avec les autotools : il te faut maitriser plusieurs langages (M4, Make, bash, et je crois encore un autre…) dont certains ne vont servir qu'à ça.
[^] # Re: Eclipse
Posté par Selso (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 0.
CDT est un outil très populaire finalement, il est utilisé par beaucoup de distributeurs qui intègrent leur SDK à Eclipse.
Portable : oui et non….
Nous l'utilisons indirectement, les conf de build doivent être adaptées pour la personne qui build sous Linux.
A l'époque les makefiles générés utilisait des chemins en absolu, ce qui rendait impossible l'usage d'un script pour la compilation en CLI, sur un autre poste.
Maintenant je ne sais pas je n'ai pas trouvé les Makefile ("internal builder is used, generate Makefile automatically")
# Le gral n'a pas été trouvé.
Posté par Selso (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 1.
Très intéressant comme retour d'expérience, as-tu testé également qmake ? il est certe associé à Qt mais peut-être utilisé pour un projet indépendant il me semble.
Lui aussi dispose d'outils pour gérer du multi-plateforme puisque c'est également l'objectif du framework d'être présent sur les OS desktop/mobiles.
Je suis plutôt d'accord avec les évaluations des autotools, make et cmake.
Make reste un bon candidat pour des petits projets, c'est simple pratique. Si on a déjà notre "makefile générique" on s'en sort à bon compte. Sous windows il m'est arrivé d'utiliser "git bash" couplé à mingw pour une génération à base de Makefile.
Les autotools c'est l'usine à gaz avec en plus les syntaxes à maîtriser : M4, bash, Make, etc…
L'on m'avait dit à l'époque que c'était plus pour gérer les chaînes de compilation UNIX que les OS, ce qui explique pourquoi Windows est très mal supporté (ou pas du tout) et tout le travail du configure de vérifier les capacités de la chaîne de compilation.
cmake je m'en suis juste servi à l'occasion et j'ai trouvé ça plus "fonctionnel", plus abordable, avec la capacité à générer des fichiers projets pour nos IDEs.
# quand on discute du prix
Posté par Selso (site web personnel) . En réponse à la dépêche Microcontrôleur de DEL basé sur ESP8266. Évalué à 1.
Je trouve cela bien de partager d'autres carte pour un prix équivalent.
Mais je pense qu'ici on vend non seulement la carte mais mais aussi la mise en oeuvre complète d'un solution répondant à ce qui est exigé (à mon avis) pour le l'IoT.
Si je paie 25e et que je veux apprendre à concevoir ce type de carte, je peux espérer plus d'aide ici qu'en achetant un produit bon marché à 10e vendu sur un site chinois.
Je dis pas que les sites chinois font de la mauvaise cam, mais que la barrière de la langue et le profil du vendeur feront que vous devrez surement vous débrouiller avec ce que vous avez.
# infos complémentaire sur l'accès concurrent aux variables
Posté par Selso (site web personnel) . En réponse au journal TapTempo sur STM32F469i-Discovery. Évalué à 0.
Quand au masquage des ITs pour protéger l'intégrité d'une variable, c'est en règle général vrai de la protéger mais tout dépend de ce que l'on fait…
- C'est vrai si l'on écrit sur cette donnée à partir d'un calcul qui utilise sa valeur courante.
- C'est un peu moins vrai si d'un côté on se contente d'écrire une valeur déterminée (0)
- Ca l'est encore moins quand on écrit sur la donnée d'un côté et que l'on se contente de la relire de l'autre (exemple des FIFOs non bloquante producteur/consommateur).
Il faut rappeler aussi que l'usage des mutex ou verrou bloquant est réservée interthread, et que l'IT devra utiliser les routines non bloquantes.
Attention aussi en masquant une IT, on peut désactiver plusieurs traitements qui ne sont pas concurrents, ou exposer une zone critique lorsque l'on réactive l'IT alors qu'il ne le faudrait pas (car le contexte appelant a désactivé l'IT).
# L'environnement de dev pour STM32
Posté par Selso (site web personnel) . En réponse au journal TapTempo sur STM32F469i-Discovery. Évalué à 0.
Bonjour,
Je voulais juste signaler que ST à racheté Atollic qui développe l'IDE Atollic TrueStudio, beaucoup plus plébiscité dans le monde professionnel.
Cette IDE est maintenant distribuée dans sa version qui est était alors une pro (analyse hard fault, des viewer de consommation mémoire, etc….).
C'est aussi une IDE basée sur Eclipse + CDT
Je la conseillerai plutôt car :
- maintenant l'IDE officielle
- plus stable à l'usage
- Linux / Windows officiellement supporté.
Je conseillerai aussi d'utiliser STMCube (HAL et middle ware) et son configurateur CubeMX, sachant que le toolkit graphique emwin est distribué gratuitement par le biais de ST, et que son forum officiel est bien actif.
Le configurateur MX à quelques défauts, mais il vous permet de configurer simplement les clocks, d'activer ou pas les périphériques, et de générer le projet atollic pour de nombres cartes comme la Nucléo.
[^] # Re: le genre d'outil qu'il faudrait ailleurs
Posté par Selso (site web personnel) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à -2.
Merci je connais, pas très fiable (le premier) / exploitables (le second) ces outils, hélas.
# le genre d'outil qu'il faudrait ailleurs
Posté par Selso (site web personnel) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à -1.
Pouaaaah !! Tous ces changements !!
Il y en a une un peu gadget qui devrait également équiper de série notre navigateur préféré :
Trop souvent je vois Firefox consommer des ressources sans vraiment comprendre la raison.
[^] # Re: Configuration minimale
Posté par Selso (site web personnel) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à 0.
Quand j'ai lu la dépêche, pour moi clairement Gimp va reposer sur des architectures modernes, et commencer boiter sur des plus anciennes.
Par exemple créer des threads utilise des ressources, car ta CPU au simple coeur va passer du temps à switcher entre eux.
Idem avec l'utilisation de ressources matérielles….
Bon mais s'il existe un paquet précompilée pour ta machine (ou si tu souhaites le compiler) ça vaut le coup d'essayer, car en effet c'est plus intéressant un atelier découverte avec un outil récent.
[^] # Re: Intégration
Posté par Selso (site web personnel) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à 3.
C'est le genre de commentaire que l'on devrait mettre en affiche sur ce site, github, et d'autres espaces ouvert aux contributeurs.
# langue Bretonne ?
Posté par Selso (site web personnel) . En réponse à la dépêche À Bégard en Bretagne, Debian a le vent en poupe dans le milieu scolaire. Évalué à -1.
J'ai juste remarqué que l'on parlait de classes bilingues Français-Breton (il ne faut pas une majuscules), et après vérification sur Wikipedia le Breton n'est pas juste un dialecte - comme je le croyais - mais bien une langue à part entière, du moins d'un point de vue "académique" puisque l'Etat refuse de se conformer à la loi Européenne en ce qui concerne les langues régionales. Il fait bien ce qu'il l'arrange avec l'Europe !
# Et TuxGuitar qui est disponible sous Android
Posté par Selso (site web personnel) . En réponse à la dépêche LinuxMAO — Éditorial d’avril 2018. Évalué à 1.
Je profite des nouvelles sur les softs pour signaler que l'outil d'édition de partition tuxguitar est maintenant disponible sous Androïd.
Les souces pour Android sont packagé avec l'archive 'PC' dans des répertoires préfixés avec Android.
# préciser la comparaison.
Posté par Selso (site web personnel) . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 2.
Merci pour ce partage, mais…
une expression rationnelle reste une méthode d'analyse après tout.
A préciser donc : "… lexicaux et syntaxiques" ?
Cela serait intéressant que tu explicites ce que tu sais ;).
# alternatives...
Posté par Selso (site web personnel) . En réponse au journal KeePassXC-Browser et gestion des mots de passe. Évalué à 0.
J'utilise pour mes besoins pro/personnel : keepass2 (.net)
Comme j'ai un vieux mac book je me suis penché sur des alternatives car je ne suis pas arrivé à faire tourner keepass2 (avec Mono ou crossover) :
- j'ai utilisé keepassX, mais PB de compatibilité avec la bdd de keepass (il me semble que ce n'est plus le cas).
- keeweb en version webapp. Mais possibilité de l'utiliser en ligne
- keepass2 for android.
En plus des mots de passe j'utilise un fichier clé que je stocke sur un drive donc j'aime bien la possibilité de keeweb d'aller le chercher directement.
keepass2/firefox ont des extensions pour des échanges via clic-droit, mais je suis satisfait de l'auto-type avec ctrl+V.
J'ai bien essayé d'initier ma compagne à leur utilisation mais sa réaction c'est : "ppfffff … un mot de passe pour gérer des mots de passe… pffff".