Vue lecture
Commentaires sur Doctolib lance une IA pour les médecins : elle pourra transcrire et analyser vos consultations par BoB
Et le secret médical dans tout ça ?… Un modèle local est acceptable, mais un outil connecté me semble aberrant.
À minima, le consentement doit être donné en amont.
Comment jouer à JCC Pokémon Pocket dès maintenant, un mois avant tout le monde ?
Tineco : la surprenante vérité sur sa prononciation après des années d’erreur
Sens interdit
Nintendo Switch 2 : un accessoiriste fait fuiter des informations sur son design
Nés le jour d’avant la honte
Commentaires sur 3 faits méconnus sur Better Call Saul, la série légendaire par boboss29
La série a dépassé Break Bad en profondeur de scénario, de développement des personnages, et même dans l’histoire. D’ailleurs, c’est à la fois la génèse de sa série mère et sa conclusion. Breaking bad prend une toute autre saveur après le visionnage de Better Caul Saul.
Minetest, l'autre pays du minage - « Libre à vous ! » du 10 septembre 2024 - Podcasts et références
Deux-cent dix-septième émission « Libre à vous ! » de l’April. Podcast et programme :
sujet principal : « Minetest : l’autre pays du minage »
la chronique « Que libérer d’autre que du logiciel » avec Antanak, sur la pratique de double système d’exploitation
la chronique « Pépite libre » de Jean-Christophe Becquet, vice-président de l’April, sur le thème « L’Accueillette : un outil d’autodiagnostic de lieux d’accueil »
Rendez‐vous en direct chaque mardi de 15h30 à 17h00 sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.
- lien nᵒ 1 : Radio Cause Commune
- lien nᵒ 2 : Libre à vous !
- lien nᵒ 3 : Podcast de l'émission
- lien nᵒ 4 : Les références pour l'émission et les podcasts par sujets
- lien nᵒ 5 : La transcription de l'émission
- lien nᵒ 6 : S'abonner au podcast
- lien nᵒ 7 : S'abonner à la lettre d'actus
Commentaires : voir le flux Atom ouvrir dans le navigateur
Commentaires sur Révolution médicale : une femme guérit du diabète grâce à un médecin chinois par BoB
Super nouvelle, ça change des recherches orientées vers la rentabilité (maladie = médicament à vie, l’éradication étant peu lucrative)
Voici l’avis de Nintendo et du père de Mario en ce qui concerne l’IA
Haiku a 23 ans - Haiku R1 bêta 5 (partie 3 : documentation, finances et GSOC)
Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.
Cette troisième (et dernière) partie présente les nouveautés dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent à Haiku d’employer un développeur à plein temps de façon durable.
Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.
- lien nᵒ 1 : dépêche de l'année précédente pour les 22 ans
- lien nᵒ 2 : Site web de Haiku
- lien nᵒ 3 : Documentation utilisateur
- lien nᵒ 4 : Documentation d'API
- lien nᵒ 5 : Documentation pour les développeurs
- lien nᵒ 6 : Les rapports financiers de Haiku, inc.
- lien nᵒ 7 : Contributions GSoC pour Haiku
- lien nᵒ 8 : Haiku a 23 ans - Haiku R1 beta 5 (partie 2 : le noyau)
- lien nᵒ 9 : Haiku a 23 ans - Haiku R1 beta 5 (partie 1 : applications)
- lien nᵒ 10 : Haiku a 23 ans - Haiku R1 beta 5
Sommaire
Documentation
La documentation de Haiku se découpe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les développeurs qui travaillent sur les composants du système.
Ces documents sont complétés par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre à programmer en C++ avec Haiku, ou encore un document de référence pour la conception d’interfaces graphiques et un autre pour le style graphique des icônes.
Documentation d’API
La documentation d’API de BeOS était assez complète et de bonne qualité. L’entreprise Access Co Ltd qui a hérité de la propriété intellectuelle de BeOS a autorisé le projet Haiku à la réutiliser et à la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas être mise à jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutées par Haiku ou les différences entre les deux systèmes.
Il est donc nécessaire de réécrire une nouvelle documentation à partir de zéro. Ce travail est assez ingrat lorsqu’il s’agit de re-décrire ce qui est déjà très bien expliqué dans la documentation existante. La nouvelle documentation a donc tendance à se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h
, et des exemples de code d’applications existantes pour découvrir toutes les possibilités offertes.
Il ne semble pas utile de lister chaque fonction ou méthode qui a été documentée. On peut mentionner une page d’explications sur la bibliothèque C standard, comprenant des liens vers les spécifications POSIX qui documentent déjà la plupart des choses, et quelques détails sur les différences avec d’autres systèmes.
Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exécutant dans le noyau.
Documentation interne
La documentation interne était à l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dépôt Git de Haiku. Depuis 2021, ces fichiers ont été rassemblés et organisés à l’aide de Sphinx, qui permet de mettre à disposition une version navigable en HTML et de donner une meilleure visibilité à ces documents.
D’autres pages sont petit à petit migrées depuis le site web principal de Haiku, qui n’est pas un très bon support pour de la documentation, et bénéficiera un jour d’une refonte pour être plus tourné vers les utilisateurs que vers les développeurs.
Quelques nouvelles pages ajoutées cette année:
- Une documentation sur l’utilisation de divers outils de complétion de code automatique avec le code source de Haiku
- Une page présentant l’organisation du code source et les principaux dossiers et sous-dossiers
- La documentation de l’outil
rc
utilisé pour compiler les « resources » attachées aux exécutables a été intégrée - Le système de fichier FAT a reçu également une page de documentation à l’occasion de sa réécriture
Un point sur le financement
L’association Haiku inc qui gère le compte en banque de Haiku publie chaque année un rapport financier.
Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit également une compensation financière de Google pour le temps passé à encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette année est de 3 300$.
Les plateformes de don les plus utilisées sont Paypal et Github sponsor. Ce dernier est recommandé car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donné arrive donc sur le compte de Haiku. Tous les autres opérateurs ont un coût, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mélange des deux.
En 2023, l’association a reçu 25 422$ de dons et a dépensé 24 750$. Elle dispose d’une réserve confortable de 100 000$ (accumulés avant 2021, alors qu’il n’y avait pas de développeur salarié) ainsi que d’environ 150 000$ en cryptomonnaies.
Les dons en cryptomonnaies sont pour l’instant bloqués sur un compte Coinbase suite à des problèmes administratifs (le compte n’est pas correctement déclaré comme appartenant à une association, il faudrait donc payer un impôt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour régler ce problème.
Du côté des dépenses, le poste le plus important est le paiement de 21 000$ à Waddlesplash, développeur employé par Haiku inc pour faire avancer le projet Haiku. Il travaille à temps partiel et avec un salaire très bas par rapport au marché, comme cela a été fait pour les précédents contrats entre Haiku inc et d’autres développeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi à plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme à condition de puiser dans les réserves de trésorerie).
Le reste des dépenses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intégration continue, hébergement cloud pour les dépôts de paquets) pour environ 3 000$.
Il faut enfin compter environ 500$ de frais Paypal, puis quelques dépenses administratives (déclaration de changement d’adresse de l’association, déclaration d’embauche) pour des montants négligeables (moins de 10$ au total).
En 2024, l’objectif fixé en janvier était de récolter 20 000$ de dons supplémentaires. Cet objectif a été atteint dès le mois de juillet, et a donc été révisé pour tenter d’atteindre les 30 000$. Cela permettra de rémunérer Waddlesplash pour un plus grand nombre d’heures cette année, ou bien d’envisager l’embauche d’une deuxième personne si un ou une candidate se présente parmi les personnes contribuant au projet (l’embauche d’une personne extérieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rémunération raisonnable).
Google Summer of Code
Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme où des étudiants (et d’autres participants pas forcément étudiants, ces dernières années) sont payés par Google pendant deux mois pour découvrir la contribution à des projets de logiciels libres.
Ce programme a été monté par « l’Open source program office » de Google. Leur intérêt est de défendre leur image d’entreprise sympathique (bien mise à mal ces dernières années, c’est devenu un géant de la publicité en ligne et de l’aspiration des données personnelles), et de contribuer à la richesse d’un écosystème de logiciels libres dont ils bénéficient beaucoup. Cela permet aussi d’encourager des personnes à s’essayer au développement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothétiques ou très indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars à ce programme.
Une équipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idées » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilité de choisir parmi les candidats qui ont répondu à cette offre (en respectant les critères de non-discrimination imposées par Google ainsi que les embargos imposés par les USA), et d’assurer l’encadrement des personnes sélectionnées. Google rémunère les participants, et dédommage les projets participants pour le temps investi.
Cette année les développeurs de Haiku encadrent cinq participants :
Calisto Mathias — Re-design de la fenêtre de recherche de fichiers
Le système de fichier BFS utilisé par Haiku permet l’exécution de requêtes (comme une base de données) exploitant les attributs étendus des fichiers, qui peuvent être indexés.
Ce système permet de faire beaucoup de choses, et la fenêtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface résultante est trop complexe, et peu de personnes prennent le temps de concevoir des requêtes améliorant leur façon de travailler, se cantonnant aux quelques exemples fournis.
L’objectif de ce projet est de refondre l’interface de cette fenêtre pour obtenir quelque chose de plus intuitif, et également d’afficher en temps réel les résultats de la requête dès qu’elle est modifiée, pour encourager les utilisateurs à expérimenter avec des requêtes plus complexes.
Daniel Martin — Virtualisation matérielle accélérée avec NVMM
Haiku n’est pas encore parfait, et certaines tâches nécessitent encore l’utilisation d’autres systèmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.
L’objectif de ce projet est de permettre d’utiliser Haiku comme système principal, et de lancer les autres systèmes dans des machines virtuelles. Cela sera réalisé à l’aide d’un portage de NVMM, qui a été développé à l’origine par NetBSD et Dragonfly BSD. Cette bibliothèque a l’avantage d’être bien documentée et conçue pour faciliter son adaptation vers d’autres systèmes.
NVMM sera complétée par l’utilisation de QEMU qui pourra fournir un « front-end » à cette mécanique.
Diego Roux — Pilote pour les cartes sons virtuelles VirtIO
Pour les personnes utilisant Haiku dans une machine virtuelle, il est intéressant d’utiliser autant que possible la famille de périphériques VirtIO.
Il s’agit de périphériques virtuels conçus sans s’inspirer de matériel existant, et plutôt pour avoir l’interface la plus simple possible entre la machine virtualisée et son hôte.
Haiku dispose déjà d’un jeu de pilote Virtio relativement complet (réseau, stockage de masse, affichage graphique). Le but de ce projet est de compléter cet ensemble avec un pilote pour les cartes son VirtIO.
trungnt2910 — Portage de GDB
Haiku dispose de son propre débugger (appelé Debugger, de façon assez peu originale). Ce dernier présente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitée. Il souffre également de quelques problèmes de performances et d’un manque de prise en charge des fichiers exécutables et bibliothèques compilés avec autre chose que GCC. Il est également incapable de faire du debug à distance ou de s’intégrer dans une interface graphique existante (par exemple au sein d’un IDE).
L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version très ancienne était utilisée avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a été entièrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs évolutions et corrections ont été intégrées dans le système de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter).
Zardshard — Migration du navigateur web WebPositive vers WebKit2
Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exécute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nécessaires pour les navigateurs web modernes (que ce soit en termes de sécurité, ou en termes de fiabilité).
L’objectif de ce projet est de reprendre les travaux déjà entamés en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bénéficier d’une séparation entre l’interface graphique, la communication réseau, et le rendu HTML/CSS/JavaScript dans des applications séparées. Ainsi, un crash d’un de ces composants peut être récupéré de façon transparente sans faire disparaître toute l’application (et les données non enregistrées de l’utilisateur avec).
Le projet est également en bonne voie, un navigateur de test permet déjà d’afficher quelques pages ce qui montre que les bases sont en place. Il reste à régler de nombreux problèmes de rendu de texte, ainsi qu’à implémenter la gestion des entrées (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Test Zelda Echoes of Wisdom : comme un air de Breath of the Wild en 2D
The Legend of Zelda : Echoes of Wisdom
Nintendo CLO-001 : un mystérieux appareil qui pourrait bien changer la face du jeu vidéo
La longue agonie du Pamir
MicroPython: Cellule de charge et limite d'utlisation
Bonjour à tous,
Dans le projet Steam Belgian Knife (sbk.education), il y a l'utilisation d'une cellule de charge comme capteur de pesée ou de capteur force.
La cellule de charge est l'élément principale d'une balance électronique.
Cela ne sera malheureusement pas possible et nous verrons pourquoi
A propos de la cellule de charge
La cellule de charge est un élément mécanique prévu pour tolérer une déformation en fonction de la force qui y est appliquée.
Cette force résulte soit de la pesée d'un objet, soit d'un effort appliqué directement sur la cellule de charge (au bon endroit et dans la bonne direction).
La cellule de charge est composé d'un pont de Wheatstone, pont constitué de 4 résistances dont l'une d'entre elles est solidaire de la cellule de charge.
Lorsqu'une force déforme la cellule de charge, la résistance est également déformée et sa valeur change sensiblement.
Cela modifie l'équilibre du point de Wheatstone et modifie la tension de sortie d'un ordre de grandeur de l'ordre de quelques millivolts.
Cellule de charge |
Les différences de tensions est tellement faible qu'il faut faut employer un amplificateur. Le plus connu est le hx711, un amplificateur 24 bits qui prend en charge l'alimentation et la mesure d'une cellule de charge.
HX711 avec MicroPython
Le HX711 dispose d'une bibliothèque Arduino mais comme vous le savez c'est avant tout l'utilisation avec MicroPython qui nous intéresse.
Pour commencer, voici comment brancher le capteur sur un Raspberry-Pi Pico.
Source: esp8266-upy/hx711 |
La bibliothèque hx711 et sa documentation (en cours de constitution) est disponible sur le dépôt esp8266-upy/hx711 .
Une fois le fichier hx711.py copié dans sur la carte MicroPython, il est possible d'exécuter l'un des programmes de test.
La tare
Les gauches de contraintes et cellules de charges n'ont pas vraiment de "point Zero".
Ces capteurs sont plus ou moins contraint au repos... et passent dans un autre état de contrainte lorsqu'une masse/force est appliquée.
Il faut donc effectuer une tare qui lit l'état du capteur au repos et mémorise la valeur comme point Zero.
Les autres mesures se feront donc par rapport à ce point Zéro.
C'est exactement que fait une balance électronique lorsqu'elle est activée! Sa première opération consiste à réaliser une série de mesures pour déterminer le "point zéro" de repos (elle "tare").
C'est pour cela que l'affichage du "0" n'est pas immédiat sur une balance électronique.
Dans la bibliothèque la méthode HX711.tare() permet de réaliser cette opération.
test.py : mesure brute
ce simple programme de test qui affiche la valeur lue sur la cellule de charge.
from hx711_gpio import HX711 from machine import Pin import time pin_OUT = Pin(12, Pin.IN, pull=Pin.PULL_DOWN) pin_SCK = Pin(13, Pin.OUT) hx711 = HX711(pin_SCK, pin_OUT, gain=128) hx711.tare() while True: print( "---------------------------------" ) # Raw value of load cell. Not scaled, no offset compensation print( "read: ", hx711.read() ) print( "get_value: ", hx711.get_value() ) time.sleep_ms( 500 )
Ce script retourne des "valeurs brutes".
Après avoir étalonné mes masses de test, j'ai effectué un relevé des "valeurs brutes" retournée par la fonction get_value().
Remarque: je me serais attendu à une erreur plus petite sur le poids de 1 Kg.
Si l'on reporte les valeurs dans un graphique, nous pouvons voir qu'il y a une belle relation proportionnelle.
En appliquant la règle de trois, entre les masse et get_value(), ma cellule de charge de 5Kg présente un rapport d'échelle de 404.4715 (le facteur d'échelle est calculée pour une mesure en grammes).test_unit.py : mesure en gramme
Lorsque le facteur d'échelle est identifié (ex: 404.4715), il est possible d'obtenir la valeur de la mesure directement en grammes si e facteur d'échelle à été calculé pour une cellule de 5000 grammes (un gamme de valeur de 0 à 5000).
Dans l'exemple ci-dessous, set_scale() est utilisé pour mentionner le facteur d'échelle.
A partir de ce instant, la valeur retournée par get_unit() sera la masse (en grammes).
from hx711_gpio import HX711 from machine import Pin import time pin_OUT = Pin(12, Pin.IN, pull=Pin.PULL_DOWN) pin_SCK = Pin(13, Pin.OUT) hx711 = HX711(pin_SCK, pin_OUT, gain=128) hx711.tare() hx711.set_scale( 404.4715 ) # 5000gr Gauge with 128 bit gain. Output unit will be in grams while True: print( "get_units: %s gr" % hx711.get_units() ) time.sleep_ms( 500 )
La constante de temps!
Avez-vous déjà remarqué qu'une balance réagit relativement vite mais qu'il faut quelques secondes pour que la mesure soit stabilisée (surtout sur les balances de précision).
Ce même comportement s'applique aussi aux cellules de charges de cet article. La valeur augmente rapidement mais requière un certain laps de temps avant de se stabiliser près de la valeur finale.
J'ai ajouté un script plot_value.py qui attend la présence d'une masse pour effectuer une rafale de mesures toutes les 200ms jusqu'au retrait de la masse. En reportant les données dans un tableur, puis un graphique de l'évolution de la mesure en fonction du temps.
Source: esp8266-upy/hx711 - Cliquer pour agrandir |
La forme de la courbe ressemble furieusement à la courbe de tension d'un circuit RC.
En inspectant celle-ci, nous pouvons constater:
- Qu'il faut environ 4 secondes pour obtenir la valeur finale.
- Que la section droite de la courbe présente une courbure à partir 2/3 de la valeur finale (très intéressant!).
Suivez la démonstration suivante
A partir de la valeur finale connue (400000), on calcule la valeur à 66% (soit 266666).
Le report de cette valeur de 266666 sur le tracé coupe la courbe de lecture là où celle-ci décolle de la tangente (ligne verte).
Encore mieux, il faut à peine 1077ms pour atteindre 66% de la valeur finale.
Lecture rapide
En faisant une mesure à 1.077sec après que la mesure décolle du Zéro, nous obtenons une valeur indicative qu'il faut multiplier par 1.66 pour estimer le poids/force finale.
Il suffit d'attendre 3 secondes de plus pour lire la valeur finale et éventuellement corriger la valeur finale.
Incompatibilité avec la mesure de poussée
Rappelez vous, en début d'article, nous parlions d'un banc d'essai pour mesurer la poussée d'une fusée à eau.
Il faut savoir que la majorité de la poussée se produit durant les premiers 1/500 de seconde du lancement (cf. Planète Sciences > Fusée à eau, un superbe document).
Conclusion
La cellule de charge est un excellent outil permettant de mesurer force statique ou une masse.
Ce capteur ne conviendra pas pour la mesure de force dynamique (comprenez: qui change rapidement).
Note: il me faudra aussi poursuivre la documentation du pilote HX711 qui reste très embryonnaire.
Ressources
Commentaires sur La voiture électrique recule de 43.9% en Europe, mais que se passe-t-il ? par coupobol
En réponse à Oni.
Le bioéthanol me revient moins cher que électrique et je fais le plein en 3 minutes !
Commentaires sur Démarchage téléphonique : pourquoi recevez-vous des appels qui raccrochent après quelques secondes ? par Bob (MC Melun)
la pire plaie reste ces appels depuis un numéro 06 alors que la loi l’interdit…
Ce que je ne manque pas de rappeler avant généralement de me faire raccrocher au nez…
Sinon, un numéro inconnu qui veut me parler laisse un message sur la boite vocale ou me rappelle en effet, le reste, ben ça finit en liste noire
Commentaires sur Les dents du dragon : que signifie ce marquage qui va débarquer en France ? par Boby lewis
Encore un mec qui avait de la peinture à vendre et un élu corrompu qui y trouve son compte …