❌

Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraĂźchir la page.

GIMP 3.0 RC2 est sorti

Note : cette dĂ©pĂȘche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC2 du 27 dĂ©cembre 2024 (en anglais).

AprĂšs la premiĂšre sĂ©rie de retours de la communautĂ©, nous sommes heureux de partager la deuxiĂšme version candidate de GIMP 3.0 ! Les gens nous ont donnĂ© des commentaires trĂšs utiles sur la premiĂšre version candidate et nous avons pu corriger de nombreux bugs.

C’est notre petit cadeau sous le sapin 🎄 pour vous tous ! (NdM: disons fourrĂ© dans la galette/le gĂąteau des rois dĂ©sormais ?)

GIMP 3.0 RC2: écran de démarrage

Écran de dĂ©marrage de la nouvelle version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC2

Sommaire

Corrections de bugs importantes

Plusieurs correctifs ont été apportés depuis la version RC1. Nous souhaitons mettre en évidence les bugs les plus importants afin que les utilisateurs en soient informés et puissent effectuer des tests supplémentaires. Pour plus de détails sur les autres correctifs de bugs, veuillez consulter notre page NEWS sur GitLab.

Migration des paramĂštres de la 2.10

Lors des tests communautaires, nous avons dĂ©couvert que les paramĂštres des utilisateurs de la 2.10 n’étaient pas migrĂ©s vers GIMP 3.0 en raison de certaines hypothĂšses incorrectes dans le code d’importation. Étant donnĂ© que la plupart des dĂ©veloppeurs utilisent exclusivement GIMP 3.0 depuis un certain temps, nous n’avions pas remarquĂ© ce problĂšme. Le bug devrait maintenant ĂȘtre corrigĂ©, nous demandons donc des rapports de bugs si des prĂ©fĂ©rences 2.10 ne sont pas importĂ©es correctement dans RC2. Notez que si vous avez dĂ©jĂ  utilisĂ© 3.0 RC1, vous devrez d’abord supprimer ces configurations, sinon RC2 n’essaiera pas d’importer les prĂ©fĂ©rences 2.10 (assurez-vous de sauvegarder vos paramĂštres bien sĂ»r !).

Console Windows

Dans les versions de dĂ©veloppement 2.99, les versions Windows lançaient automatiquement un affichage de console en plus de GIMP lui-mĂȘme. C’est trĂšs utile pour les dĂ©veloppeurs Windows pour voir les messages de dĂ©bogage, mais la console n’était pas destinĂ©e Ă  ĂȘtre affichĂ©e pendant les versions stables. Comme nous avons modifiĂ© notre processus de construction pour utiliser Meson au lieu d’Autotools, nous avons appris que nous devions apporter des modifications supplĂ©mentaires pour empĂȘcher l’affichage de la console. Cela devrait ĂȘtre corrigĂ© maintenant grĂące Ă  Jehan - si vous voyez toujours la console sous Windows, veuillez remplir un nouveau rapport de bogue !

Problùmes de polices d’interface utilisateur manquantes sur macOS

Il y a un problĂšme de longue date oĂč certains utilisateurs de macOS ne voyaient que des symboles « Unicode manquants Â» au lieu des textes d’interface dans GIMP (Ă  la fois dans la version 2.10 et dans la version 3.0). Cela Ă©tait dĂ» Ă  un bug dans Pango, la bibliothĂšque que nous utilisons pour les mises en page de texte. Ce problĂšme a Ă©tĂ© rĂ©solu avec la rĂ©cente version Pango 1.55.0, nous encourageons donc tous les empaqueteurs macOS tiers Ă  mettre Ă  jour vers cette version lorsqu’ils construisent GIMP pour le distribuer.

GIMP 3.0.0 RC2 : le package officiel de macOS contient dĂ©sormais Pango sans polices cassĂ©es

Si vous aviez ce problĂšme de polices cassĂ©es sur macOS (Ă  gauche), il est dĂ©sormais rĂ©solu (Ă  droite) - captures d’écran de rapporteurs de bug - GIMP 3.0.0 RC2

Intégration de darktable

AprĂšs la sortie de la version 3.0 RC1, nous avons reçu des rapports de certains utilisateurs indiquant qu’ils ne pouvaient toujours pas importer et exporter d’images entre GIMP et darktable. Nous avons travaillĂ© avec les dĂ©veloppeurs de darktable pour Ă©liminer les bugs restants, de sorte que l’intĂ©gration entre darktable 5.0.0 et GIMP 3.0 RC2 devrait dĂ©sormais fonctionner pour tout le monde. Cependant, veuillez dĂ©poser un nouveau rapport de bogue si vous continuez Ă  rencontrer des problĂšmes pour connecter les deux !

Améliorations

Bien que l’objectif principal du dĂ©veloppement de la version 3.0 RC2 ait Ă©tĂ© la correction de bugs et le peaufinage, certaines nouvelles fonctionnalitĂ©s ont Ă©galement Ă©tĂ© implĂ©mentĂ©es.

API de filtre GEGL

De nombreux anciens wrappers d’API pour les opĂ©rations GEGL ont Ă©tĂ© supprimĂ©s dans la version RC1. Bien que cela ait rĂ©duit la dette technique, cela a Ă©galement causĂ© des problĂšmes Ă  de nombreux dĂ©veloppeurs de greffons et de scripts tiers qui souhaitaient porter leurs greffons vers la version 3.0. Alors que notre plan initial Ă©tait d’implĂ©menter la nouvelle API publique de filtre aprĂšs la sortie de la version 3.0, les commentaires de la communautĂ© nous ont convaincu de l’ajouter pour la version 3.0 RC2.

Applying filters through libgimp 3.0.0 API (Script-fu et al.) - GIMP 3.0.0 RC2

Application de filtres via l’API libgimp 3.0.0 (Script-fu et al.) - GIMP 3.0.0 RC2

Le travail de Jehan permet aux dĂ©veloppeurs d’appliquer des effets de filtre soit immĂ©diatement, soit de maniĂšre non destructrice. Vous pouvez voir des exemples de la maniĂšre de procĂ©der en C, Python et Script-Fu dans la requĂȘte de fusion, ou en recherchant gimp-drawable-filter dans le navigateur de procĂ©dures de GIMP. Nous avons Ă©galement commencĂ© Ă  utiliser l’API de filtre dans nos scripts Python pour crĂ©er automatiquement des effets d’arriĂšre-plan flou pour le programme d’installation Windows, et avec cette mĂȘme API en C, Alx Sa a ajoutĂ© la prise en charge de l’importation de l’ancien style de calque Color Overlay de Photoshop.

Nous sommes preneurs des retours et des rapports de bugs d’auteurs de greffons et de scripts qui utilisent la nouvelle API de filtrage dans leur travail ! Nous avons Ă©galement prĂ©vu d’autres mises Ă  jour pour GIMP 3.0.

Espaces de fusion de calques et composition dans les fichiers XCF

Les discussions entre les experts en science des couleurs Elle Stone et Øyvind KolĂ„s ont rĂ©vĂ©lĂ© un autre domaine nĂ©cessitant des amĂ©liorations dans le cadre de notre projet Color Space Invasion. Plus prĂ©cisĂ©ment, les images avec des profils de couleurs qui ont des courbes de reproduction des tons non perceptives peuvent ne pas ĂȘtre rendues correctement lorsqu’elles sont dĂ©finies sur certains modes de calque.

Øyvind a implĂ©mentĂ© une correction pour ce problĂšme en ajoutant un espace perceptuel appropriĂ© par dĂ©faut Ă  des modes de calque spĂ©cifiques. Bien que nous pensions que cette amĂ©lioration ne devrait pas avoir d’impact sur les fichiers XCF plus anciens, n’hĂ©sitez pas Ă  rapporter tous problĂšmes de compatibilitĂ© avec la version 3.0 RC2 !

Paquets

AppImage

GrĂące aux efforts continus de Bruno Lopes et avec l’aide de Samueru et de la communautĂ© AppImage, notre AppImage expĂ©rimentale fonctionne dĂ©sormais sur la plupart des distributions Linux. Nous souhaitons encourager davantage de tests, dans l’espoir de pouvoir la proposer comme une autre version Linux en plus de notre Flatpak. Vous pouvez consulter les instructions pour installer les paquets expĂ©rimentaux AppImage sur notre page de tĂ©lĂ©chargement des versions de dĂ©veloppement.

Flatpak

Notre flatpak journalier a maintenant un App-ID dĂ©diĂ© org.gimp.GIMP.Nightly. Cela signifie principalement qu’il peut ĂȘtre installĂ© cĂŽte Ă  cĂŽte avec le flatpak stable tandis que les deux sont visibles dans vos menus (plus besoin de sĂ©lectionner quelle version doit ĂȘtre affichĂ©e avec flatpak make-current).

Mais cela signifie Ă©galement que tous ceux qui avaient le flatpak journalier jusqu’à prĂ©sent ne verront pas de mise Ă  jour arriver de sitĂŽt. Afin de continuer Ă  utiliser le flatpak journalier, dĂ©sinstallez celui existant et installez le nouveau avec ces commandes :

flatpak uninstall org.gimp.GIMP//master
flatpak install https://nightly.gnome.org/repo/appstream/org.gimp.GIMP.Nightly.flatpakref

⚠ Rappel : le flatpak journalier contient le code de dĂ©veloppement actuel tel qu’il se prĂ©sente dans le dĂ©pĂŽt source. Parfois, il peut mĂȘme ĂȘtre trĂšs cassĂ© ou rendre vos fichiers de projet invalides. Nous ne le recommandons pas pour la production ! Utilisez cette version pour nous aider Ă  dĂ©boguer en signalant les problĂšmes ou si vous aimez vraiment les risques pour tester les derniĂšres fonctionnalitĂ©s.

Améliorations du greffon BMP

Le nouveau contributeur Rupert Weber a Ă©tĂ© trĂšs occupĂ© depuis la derniĂšre mise Ă  jour avec de nouvelles mises Ă  jour de notre greffon BMP. Quelques points de son travail Ă  mettre en avant :

  • Les fichiers BMP sont dĂ©sormais importĂ©s sans perte dans leur prĂ©cision d’origine, plutĂŽt que d’ĂȘtre convertis en prĂ©cision entiĂšre de 8 bits.
  • Le greffon prend dĂ©sormais en charge le chargement de fichiers BMP avec compression RLE24 et Huffman.
  • Nous chargeons dĂ©sormais les fichiers BMP par morceaux plutĂŽt que d’essayer de charger l’image entiĂšre en une seule fois. Des travaux connexes nous permettent Ă©galement de charger des fichiers BMP beaucoup plus volumineux.
  • Rupert a Ă©galement effectuĂ© beaucoup de nettoyage et de maintenance du code, afin de rendre le greffon plus facile Ă  maintenir Ă  l’avenir.

Mises Ă  jour diverses

  • Jehan a apportĂ© quelques amĂ©liorations d’usage de la console Python. Vous pouvez dĂ©sormais utiliser les raccourcis Ctrl+R et Ctrl+S pour parcourir votre historique de commandes, et Page prĂ©cĂ©dente et Page suivante vous permettent dĂ©sormais de faire dĂ©filer l’historique en plus des touches flĂ©chĂ©es Haut et Bas.

History search in Python Console - GIMP 3.0.0 RC2
Recherche dans l’historique de commande (console Python) - GIMP 3.0.0 RC2

  • Alx Sa a implĂ©mentĂ© le chargement des fichiers CMJN PAM dans le greffon PNM.

  • Sous Windows, nous avons Ă©galement ajoutĂ© la possibilitĂ© d’ouvrir des images via des raccourcis Windows (fichiers .lnk) directement depuis la boĂźte de dialogue de sĂ©lection de fichiers. Ce travail est Ă©galement rĂ©alisĂ© par Alx Sa.

  • D’autres modifications et amĂ©liorations ont Ă©tĂ© apportĂ©es au thĂšme. En particulier, le style du « curseur compact » a Ă©tĂ© considĂ©rablement amĂ©liorĂ© aprĂšs les commentaires et le travail de Denis Rangelov. Denis a Ă©galement crĂ©Ă© de nouvelles icĂŽnes pour la boĂźte de dialogue de navigation ancrable, remplaçant les doublons par des symboles distincts. Anders Jonsson a Ă©galement rĂ©visĂ© le thĂšme et supprimĂ© certaines solutions de contournement qui Ă©taient nĂ©cessaires dans GIMP 2.10, mais qui ne sont plus nĂ©cessaires avec nos nouveaux thĂšmes 3.0.

  • Idriss Fekir a apportĂ© des amĂ©liorations Ă  notre code de chargement de polices XCF, pour amĂ©liorer la compatibilitĂ© lors de l’importation d’anciens fichiers XCF.

Aperçu des changements depuis la version 2.10

Pour ceux qui n’ont pas suivi de prĂšs le dĂ©veloppement de GIMP, cet article ne couvre que les changements progressifs depuis la derniĂšre version. Ils ne rĂ©pertorient pas tous les changements ou amĂ©liorations apportĂ©s Ă  GIMP 3.0 - ce serait un article trĂšs long !

Bien que nous aurons des notes de version complĂštes pour la version finale 3.0, nous avons pensĂ© qu’il serait utile de rĂ©sumer quelques-uns des changements majeurs apportĂ©s au cours du processus de dĂ©veloppement de la version 2.99 :

  • Le travail initial de portage de GIMP vers GTK3 a eu lieu dans 2.99.2. Cette version a Ă©galement introduit la sĂ©lection multi-calque, ainsi que des modifications initiales de l’API et des amĂ©liorations de la gestion de l’espace colorimĂ©trique.
  • D’autres mises Ă  jour de l’API ont Ă©tĂ© effectuĂ©es dans 2.99.4, notamment la possibilitĂ© de gĂ©nĂ©rer automatiquement des interfaces utilisateur de greffon en fonction des entrĂ©es de l’utilisateur. Diverses amĂ©liorations de convivialitĂ© ont Ă©galement Ă©tĂ© apportĂ©es, ainsi que l’introduction de l’outil expĂ©rimental Paint Select.
  • 2.99.6 a apportĂ© davantage de mises Ă  jour de l’API et de travaux internes. D’autres fonctionnalitĂ©s destinĂ©es Ă  l’utilisateur incluent la possibilitĂ© de placer des guides en dehors du canevas, une meilleure prise en charge du pavĂ© tactile et une meilleure prise en charge des diffĂ©rentes mĂ©tadonnĂ©es de couleur PNG.
  • Le pipeline de dĂ©veloppement a Ă©tĂ© considĂ©rablement amĂ©liorĂ© dans 2.99.8, permettant des temps de construction et une automatisation plus rapides. La prise en charge de nouveaux formats de fichiers tels que PSB et JPEGXL a Ă©tĂ© ajoutĂ©e dans cette version, ainsi que la prise en charge des pilotes Windows Ink de tablette graphique.
  • 2.99.10 a introduit des « ensembles de calques Â», remplaçant l’ancien concept de calques liĂ©s. La dynamique de peinture a Ă©tĂ© rationalisĂ©e dans cette version, ainsi que la premiĂšre version de la boĂźte de dialogue de bienvenue.
  • La prise en charge de la liaison anticipĂ©e CMJN a Ă©tĂ© implĂ©mentĂ©e dans 2.99.12. Les thĂšmes de l’interface graphique CSS ont Ă©galement fait l’objet d’une refonte majeure dans cette version, ainsi que davantage de prise en charge de formats de fichiers et d’amĂ©liorations majeures de Script-Fu.
  • 2.99.14 a vu l’introduction de contours non destructifs pour l’outil de texte. L’outil d’alignement a Ă©galement Ă©tĂ© rĂ©visĂ©, la mise Ă  l’échelle des thĂšmes et des icĂŽnes a Ă©tĂ© amĂ©liorĂ©e et les sĂ©lections flottantes ont Ă©tĂ© largement remplacĂ©es dans le flux de travail.
  • Le portage GTK3 a finalement Ă©tĂ© achevĂ© dans 2.99.16. La fenĂȘtre contextuelle de recherche / a Ă©tĂ© mise Ă  jour pour afficher le chemin du menu pour toutes les entrĂ©es, ainsi que pour permettre de chercher parmi les filtres.
  • Les filtres non destructifs ont Ă©tĂ© introduits pour la premiĂšre fois dans 2.99.18. Des amĂ©liorations majeures de la gestion des couleurs ont Ă©galement Ă©tĂ© apportĂ©es, et de nouvelles options d’extension automatique des limites de calque et d’accrochage ont Ă©galement Ă©tĂ© implĂ©mentĂ©es.

GEGL

Tout comme pour GIMP, la version 0.4.52 de GEGL a Ă©tĂ© corrigĂ©e. Øyvind KolĂ„s a corrigĂ© certaines Ă©tiquettes gĂ©nĂ©riques « EntrĂ©e auxiliaire Â» pour qu’elles soient plus significatives. Elles seront Ă©galement visibles dans les filtres de GIMP. Il a Ă©galement amĂ©liorĂ© la prĂ©cision du traitement des couleurs de certains filtres. Thomas Manni, contributeur de longue date, a Ă©galement corrigĂ© les plantages lorsque certains filtres Ă©taient exĂ©cutĂ©s sur de trĂšs petits calques.

Statistiques de sortie

Depuis GIMP 3.0 RC1, dans le dĂ©pĂŽt principal de GIMP :

  • 73 rapports ont Ă©tĂ© fermĂ©s comme CORRIGÉS.
  • 71 demandes de fusion ont Ă©tĂ© acceptĂ©es.
  • 277 commits ont Ă©tĂ© poussĂ©s.
  • 18 traductions ont Ă©tĂ© mises Ă  jour : bulgare, catalan, chinois (Chine), chinois (TaĂŻwan), danois, finnois, gĂ©orgien, islandais, italien, letton, lituanien, norvĂ©gien nynorsk, persan, portugais, russe, slovĂšne, suĂ©dois, ukrainien.

35 personnes ont contribuĂ© Ă  des modifications ou des correctifs Ă  la base de code de GIMP 3.0.0 RC2 (l’ordre est dĂ©terminĂ© par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

  • 12 dĂ©veloppeurs pour le code principal : Jehan, Alx Sa, Michael Schumacher, Anders Jonsson, Lloyd Konneker, Øyvind KolĂ„s, Idriss Fekir, Andre Klapper, Jacob Boerema, Michael Natterer, Rupert Weber, Thomas Manni.
  • 11 dĂ©veloppeurs de plug-ins ou modules : Jehan, Lloyd Konneker, Alx Sa, Rupert Weber, Daniel NovomeskĂœ, Jacob Boerema, Aki, Bruno, Ryan Sims, Simon Munton.
  • 19 traducteurs : Alan Mortensen, Cheng-Chia Tseng, KolbjĂžrn StuestĂžl, RĆ«dolfs Mazurs, Jiri Grönroos, Sveinn Ă­ Felli, Alexander Shopov, Aurimas Černius, Marco Ciampa, Danial Behzadi, Hugo Carvalho, Jordi Mas, Anders Jonsson, Ekaterine Papava, Julia Dronova, Luming Zh, Martin, Michael Schumacher, Youri Chornoivan.
  • 2 concepteurs de thĂšmes : Alx Sa, Anders Jonnson.
  • 2 contributeurs Ă  la documentation : Jehan, Bruno.
  • 5 contributeurs pour la compilation, l’empaquetage ou l’intĂ©gration continue : Bruno, Jehan, Lloyd Konneker, Alx Sa, Jacob Boerema, Rupert Weber.

Contributions sur d’autres dĂ©pĂŽts du GIMPverse (l’ordre est dĂ©terminĂ© par le nombre de commits) :

  • GEGL 0.4.52 est composĂ© de 31 commits de 16 contributeurs : Øyvind KolĂ„s, Sam L, Thomas Manni, lillolollo, Alan Mortensen, Anders Jonsson, Ekaterine Papava, Hugo Carvalho, Jordi Mas, Juliano de Souza Camargo, KolbjĂžrn StuestĂžl, Lukas Oberhuber, Luming Zh, Marco Ciampa, Martin, Yuri Chornoivan.
  • ctx a enregistrĂ© 48 commits depuis la sortie de la RC1 par 1 contributeur : Øyvind KolĂ„s.
  • gimp-data a enregistrĂ© 6 commits de 5 contributeurs : Anders Jonsson, Jehan, Sevenix, Alx Sa et Denis Rangelov.
  • gimp-test-images (nouveau rĂ©fĂ©rentiel pour les tests de prise en charge des images) a enregistrĂ© 2 commits de 1 contributeur : Rupert.
  • La version gimp-macos-build (scripts d’empaquetage pour macOS) a reçu 5 commits de 1 contributeur : Lukas Oberhuber.
  • La version flatpak a reçu 4 commits de 2 contributeurs : Bruno Lopes, Jehan.
  • Notre site Web principal a reçu 29 commits de 3 contributeurs : Jehan, Alx Sa, Andrea Veri.
  • Notre site Web de dĂ©veloppement a reçu 16 commits de 2 contributeurs : Jehan, Bruno Lopes.
  • Notre documentation pour GIMP 3.0 a reçu 157 commits de 10 contributeurs : Andre Klapper, KolbjĂžrn StuestĂžl, Jacob Boerema, Alan Mortensen, Anders Jonsson, Marco Ciampa, Jordi Mas, Yuri Chornoivan, Alx Sa, Jiri Grönroos.

N’oublions pas de remercier toutes les personnes qui nous aident Ă  trier dans Gitlab, Ă  signaler les bugs et Ă  discuter des amĂ©liorations possibles avec nous. Notre communautĂ© est Ă©galement profondĂ©ment reconnaissante envers les guerriers d’Internet qui gĂšrent nos diffĂ©rents canaux de discussion ou comptes de rĂ©seaux sociaux tels que Ville PĂ€tsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via les scripts git, des erreurs peuvent se glisser dans ces statistiques. N’hĂ©sitez pas Ă  nous dire si nous avons oubliĂ© ou mal classĂ© certains contributeurs ou contributions.

Autour de GIMP

Miroirs de téléchargement

GNOME a abandonnĂ© l’utilisation de miroirs lors de sa derniĂšre mise Ă  jour d’infrastructure. Comme nos miroirs de tĂ©lĂ©chargement sont hĂ©bergĂ©s par eux, on nous a demandĂ© si nous voulions Ă©galement faire la mĂȘme chose. En tant que projet communautaire, nous apprĂ©cions tous ceux qui contribuent un miroir pour rendre GIMP plus accessible dans leur rĂ©gion. Par consĂ©quent, nous avons dĂ©cidĂ© de continuer Ă  utiliser des miroirs pour distribuer GIMP.

Si vous souhaiter contribuer à un miroir pour votre région, voici la nouvelle procédure :

Comment devenir un miroir officiel (mise à jour de la procédure)

  1. Créez une demande de miroir sur le tracker gimp-web
  2. Dites-nous pourquoi vous souhaitez crĂ©er un miroir de GIMP, pour quels autres logiciels libres vous en contribuez dĂ©jĂ  un, quelle est votre configuration, l’emplacement du serveur

  3. Parlez-nous de vous : ĂȘtes-vous une organisation ou un particulier ? Donnez-nous le nom et l’URL spĂ©cifiques Ă  afficher dans la liste des sponsors de miroir.
  4. Une fois que nous aurons terminé de vérifier votre organisation, les identifiants rsync seront échangés de maniÚre sécurisée, vous permettant de synchroniser votre miroir avec le serveur source
  5. Il n’y a rien de particulier Ă  faire pour apparaĂźtre sur la page des sponsors qui sera mise Ă  jour rĂ©guliĂšrement via des scripts. Pourtant, cela peut prendre quelques jours, voire quelques semaines parfois. Ne vous inquiĂ©tez donc pas si le nom de votre organisation n’apparaĂźt pas immĂ©diatement !

🛈 Nous vĂ©rifions automatiquement Ă  intervalles alĂ©atoires que les miroirs sont mis Ă  jour suffisamment rapidement et que les donnĂ©es correspondent pour des raisons de sĂ©curitĂ© Ă©videntes.

Changements dans les miroirs

De plus, depuis la publication de la nouvelle 3.0RC1, un nouveau miroir a été ajouté :

  • Sahil Dhiman, Mumbai, Inde

Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous garantissons que tout le monde peut avoir un accÚs rapide au téléchargement de GIMP.

Financer des exécuteurs ("runner") GitLab

Le dĂ©pĂŽt de code de GIMP est Ă©galement hĂ©bergĂ© sur la plateforme GitLab de GNOME. Andrea Veri a demandĂ© si nous pouvions financer un exĂ©cuteur [NDA: un "runner" est une sorte de serveur dĂ©diĂ© Ă  la compilation ou Ă  l’intĂ©gration continue de maniĂšre gĂ©nĂ©rale] sur la plateforme, ce qui permet Ă  tout projet sur la plateforme de tester la construction de son logiciel avant, pendant et aprĂšs les modifications de code. AprĂšs un vote du comitĂ© de GIMP, nous avons acceptĂ© et sommes dĂ©sormais les sponsors d’un exĂ©cuteur CI/CD x86 !

Télécharger GIMP 3.0 RC2

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

  • Paquets Linux flatpaks pour x86 et ARM (64 bits)
  • Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
  • Paquet MSIX (aperçu GIMP) pour x86 et ARM (64 bits)
  • Paquets macOS DMG pour le matĂ©riel Intel
  • Paquets macOS DMG pour le matĂ©riel Apple Silicon

D’autres paquets rĂ©alisĂ©s par des tiers devraient Ă©videmment suivre (paquets de distributions Linux ou *BSD, etc.).

🛈 Notes:

  • Les 2 paquets DMG macOS seront probablement en retard, car nous attendons la validation de la mise Ă  jour Apple par la Fondation GNOME avant de pouvoir signer nos paquets.
  • Le paquet MSIX prend gĂ©nĂ©ralement quelques jours ouvrables de validation par Microsoft. (le paquet MSIX est disponible)

Et ensuite ?

GrĂące au grand nombre de retours que nous avons reçus pour notre premier candidat Ă  la version finale, nous sommes en mesure de vous prĂ©senter cette deuxiĂšme version qui en est d’autant plus robuste. Comme vous l’avez vu, quelques surprises supplĂ©mentaires 🎁 sont arrivĂ©es avec les corrections de bugs, notamment la nouvelle API de filtre, qui a dĂ©clenchĂ© la prise en charge de l’importation de l’ancien effet Color Overlay de PSD, des modes de fusion et de composition amĂ©liorĂ©s, et plus encore. Nous avons pensĂ© que cela valait la peine de rompre le gel des fonctionnalitĂ©s pour ces changements et que cela fera toute la diffĂ©rence !

Avec cette deuxiĂšme version candidate, nous sommes plus proches que jamais de la version 3.0.0 de GIMP. Comme d’habitude, nous attendons avec impatience les nouveaux rapports de problĂšmes de la communautĂ© qui nous permettront de finaliser la version 3.0.0 ! đŸ€—

N’oubliez pas que vous pouvez faire un don et financer personnellement les dĂ©veloppeurs de GIMP, afin de donner en retour et d’accĂ©lĂ©rer le dĂ©veloppement de GIMP. L’engagement de la communautĂ© aide le projet Ă  se renforcer ! đŸ’ȘđŸ„ł

🎅🎄🎉 Et bien sĂ»r, toute l’équipe vous souhaite de joyeuses fĂȘtes de fin d’annĂ©e (MAJ de Jehan) nos meilleurs vƓux pour la nouvelle annĂ©e ! đŸ„łđŸ„‚đŸŽ†

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans et un quart

La derniĂšre dĂ©pĂȘche annuelle sur les nouveautĂ©s dans Haiku a dĂ©passĂ© la longueur maximale tolĂ©rĂ©e par Linuxfr (et Ă©tĂ© finalement dĂ©coupĂ©e en plusieurs parties publiĂ©es sĂ©parĂ©ment). Aussi, les nouveautĂ©s sur Haiku seront dĂ©sormais publiĂ©es trimestriellement, pour faire face Ă  l’augmentation d’activitĂ© dans le projet.

Sommaire

Ce rapport est basĂ© sur les rapports mensuels d’activitĂ© d’aoĂ»t, septembre et octobre publiĂ©s sur le site de Haiku. Il couvre les changements de code survenus entre hrev57901 et hrev58291 de Haiku.

Certains des changements mentionnĂ©s dans ce rapport font partie des derniers dĂ©veloppements du mois d'aoĂ»t, et Ă©taient dĂ©jĂ  prĂ©sents dans la version R1 bĂȘta 5 qui a Ă©tĂ© publiĂ©e dĂ©but septembre 2024.

Les corrections de bugs sont appliquĂ©es sur la branche bĂȘta 5 si elle est concernĂ©e, mais les nouveaux dĂ©veloppements sont mis dans la branche principale et seront disponibles uniquement dans les « nighlty builds Â» (constructions journaliĂšres) puis dans la prochaine version, qui sera probablement Ă©tiquetĂ©e R1 bĂȘta 6.

La version R1 est trĂšs attendue, mais la feuille de route comporte toujours environ 600 bugs et demandes d’amĂ©lioration. Jusqu’à ce qu’ils soient tous traitĂ©s (corrigĂ©s, devenus obsolĂštes ou dĂ©placĂ©s vers une version plus tardive), Haiku continue de publier des versions bĂȘta.

Applications

Amélioration et corrections de textes de messages dans diverses applications (humdinger).

L’application Switcher — permettant de naviguer rapidement entre les diffĂ©rentes fenĂȘtres et applications Ă  l’aide d’un menu qui apparaĂźt lorsque la souris se trouve sur les bords de l’écran — peut Ă  nouveau ĂȘtre compilĂ©e. Cette application n’est pas terminĂ©e et non intĂ©grĂ©e dans Haiku par dĂ©faut pour l’instant (nephele).

Dans les préférences de disposition clavier, des icÎnes avaient disparu de certains menus suite à un problÚme dans une modification précédente. Ces icÎnes sont maintenant de retour (jscipione).

Les rĂ©glages de polices de caractĂšres de WebPositive peuvent faire des retours Ă  la ligne dans le texte d’exemple utilisĂ© pour visualiser la police choisie (correction rĂ©cupĂ©rĂ©e depuis la fenĂȘtre de rĂ©glage des polices du systĂšme, qui utilise une variante du mĂȘme code). (nipos).

Le raccourci clavier « muet » permet d’alterner entre l’activation et la dĂ©sactivation du son, au lieu de toujours passer en mode muet (korli).

Plusieurs applications pouvaient ouvrir leurs fenĂȘtres en dehors de l’écran si leur derniĂšre position enregistrĂ©e n’était pas bonne (aprĂšs un changement de rĂ©solution d’écran par exemple). L’appel de la fonction MoveOnScreen() aprĂšs la crĂ©ation d’une fenĂȘtre permet de rĂ©gler ce problĂšme (korli, pinaraf, waddlesplash).

Icon-O-Matic ouvre ses dialogues de sĂ©lection de fichiers dans le dossier oĂč se trouve l’icĂŽne en cours d’édition (nipos).

Il est possible de sélectionner une famille de polices directement dans FontDemo (nipos).

Améliorations du mode sombre

Modifications faites par nipos et nephele.

Depuis la version bĂȘta 5 de Haiku, il est beaucoup plus simple de configurer un thĂšme de couleurs dans Haiku (avec seulement 3 couleurs Ă  sĂ©lectionner, les autres Ă©tant calculĂ©es automatiquement).

Cependant, toutes les applications et contrĂŽles graphiques ne se comportent pas forcĂ©ment trĂšs bien, en particulier si on choisit une couleur de fond de fenĂȘtres sombre. Ce trimestre, on trouve donc des amĂ©liorations sur ColumnListView (contrĂŽle permettant l’affichage de donnĂ©es en listes, en arbre et en colonnes), et dans les applications Debugger, Mail (en particulier les marqueurs de portions de message citĂ©es), WebPositive, ResEdit, FontDemo, Cortex, Sudoku et Tracker (les fenĂȘtres de configuration des permissions de fichiers et de statut de copie de fichiers), ainsi que dans les prĂ©fĂ©rences de disposition clavier (couleur des touches de clavier affichĂ©es), et de configuration des Ă©crans et des Ă©crans de veille. Ces applications utilisaient encore quelques couleurs codĂ©es « en dur Â» qui ne s’adaptaient pas automatiquement au thĂšme choisi.

En outre, les formules de calcul utilisées pour générer le thÚme de couleurs ont été améliorées pour donner de meilleurs résultats dans le cas de couleurs sombres, assurant de conserver un bon contraste entre tous les éléments graphiques et une meilleure cohérence des couleurs.

AboutSystem

L’application AboutSystem donne quelques informations sur la machine (RAM, CPU), et surtout affiche les noms des dĂ©veloppeurs et les messages de copyright et clauses de licences obligatoires de logiciels libres qui sont embarquĂ©s dans Haiku.

Correction d’un crash Ă  cause d’une information de copyright mal enregistrĂ©e (madmax).

Mise Ă  jour des crĂ©dits Ă  l’occasion de la version Beta 5 : ajout des nouveaux membres de l’équipe, et passage dans la catĂ©gorie « anciens dĂ©veloppeurs » de certaines personnes qui ne participent plus pour l’instant. (waddlesplash).

DĂ©bogueur

Haiku est fourni avec un dĂ©bogueur graphique permettant d’investiguer facilement les problĂšmes dans les applications.

Waddlesplash a amĂ©liorĂ© le dĂ©sassembleur pour mieux dĂ©coder les adresses mĂ©moire calculĂ©es Ă  partir de la valeur d’un registre CPU. La correction a Ă©tĂ© remontĂ©e dans la bibliothĂšque tierce Zydis, utilisĂ©e pour le dĂ©sassemblage.

Il a Ă©galement modifiĂ© le code du Debugger pour ne pas essayer de tĂ©lĂ©charger des informations de debug lorsque l’outil est lancĂ© en mode non-interactif (dans le cas d’une test suite automatisĂ©e par exemple). Plusieurs autres problĂšmes qui pouvaient causer un plantage du debugger ou un blocage dans un Ă©tat invalide (avec l’application qui ne s’arrĂȘte jamais) ont Ă©tĂ© Ă©galement traitĂ©s.

DriveSetup

L’outil DriveSetup permet de modifier la table de partitions et de formater les partitions avec diffĂ©rents systĂšmes de fichiers.

Pour les partitions de type « Intel » (MBR), lorsqu’on crĂ©e une premiĂšre partition, par dĂ©faut elle est marquĂ©e automatiquement comme partition active. Auparavant il fallait cocher une case pour cela, et de nombreux utilisateurs oubliaient de le faire, ce qui pouvait rendre le systĂšme impossible Ă  dĂ©marrer (korli).

Dans certains messages, le nom des partitions n’était pas mis entre guillemets, ce qui pouvait prĂȘter Ă  confusion avec des noms de partitions choisis maladroitement (ou judicieusement, selon de quel point de vue on se place). Maintenant le nom de la partition est clairement identifiable dans le message (humdinger).

HaikuDepot

HaikuDepot est le frontal graphique du gestionnaire de paquets de Haiku. L’application est maintenue par apl et se compose d’une interface graphique native dĂ©veloppĂ©e en C++ et d’un webservice dĂ©veloppĂ© en Java qui permet de stocker des mĂ©tadonnĂ©es supplĂ©mentaires sur les paquets : captures d’écrans, notes et revues des utilisateurs, liste des paquets Ă  mettre en avant.

  • Refactoring du « language model Â», de la gestion des chemins, de la rĂ©cupĂ©ration des donnĂ©es des paquets, de l’affichage des auteurs de paquets, de la gestion des notes donnĂ©es par les utilisateurs. (apl)
  • FenĂȘtre des conditions d’utilisation: correction de la couleur du texte, correction d’un crash si on clique dans la fenĂȘtre avant que le texte soit chargĂ©. (apl et jscipione)
  • Le bouton « Ouvrir » permettant de lancer une application installĂ©e ne fonctionnait pas toujours (apl).
  • AmĂ©lioration de la sĂ©lection d’un icĂŽne par dĂ©faut pour les paquets qui n’ont pas d’icĂŽne inclus (apl).

La liste de paquets mis en avant a Ă©tĂ© revue, un nouveau mainteneur (Michel) se charge de la tenir Ă  jour avec des rĂšgles mieux dĂ©finies : une sĂ©lection d’applications populaires (sur suggestion de participants aux forums de discussion) ainsi que des applications mises Ă  jour rĂ©cemment. Si vous utilisez Haiku, n’hĂ©sitez pas Ă  passer un peu de temps Ă  Ă©valuer et noter les applications, peu de personnes le font et il est difficile d’exploiter les donnĂ©es de façon pertinente si beaucoup d’applications n’ont reçu qu’un seul vote.

Horloge

L’application horloge permet d’afficher l’heure (sans surprise). Elle propose diverses apparences de cadrans, peut ĂȘtre redimensionnĂ©e, et incrustĂ©e dans le bureau sous forme d’un replicant.

Un bug dans l’application conduisait Ă  afficher une heure alĂ©atoire (non initialisĂ©e) pendant quelques centiĂšmes de secondes au dĂ©marrage avant de commencer Ă  afficher l’heure courante (OscarL)

Les aiguilles de l’horloge Ă©taient dĂ©calĂ©es de quelques pixels et ne pointaient pas prĂ©cisĂ©ment lĂ  ou elles devraient (dovsienko).

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il affiche le bureau et toutes les fenĂȘtres de navigation et de recherche de fichiers. Il se distingue par son utilisation de la navigation dite « spatiale Â», oĂč chaque dossier s’ouvre dans une fenĂȘtre sĂ©parĂ©e dont la taille et la position Ă  l’écran sont mĂ©morisĂ©es.

jscipione continue son travail d’amĂ©lioration du Tracker (cela comporte de nombreux changements qui sont encore en gestation). Ce trimestre, les changements intĂ©grĂ©s permettent :

  • la dĂ©sactivation d’entrĂ©es du menu « Nouveau » lorsque les opĂ©rations ne sont pas disponibles,
  • la mise Ă  jour dynamique de certains menus en fonction des opĂ©rations disponibles,
  • la prĂ©servation de la sĂ©lection aprĂšs une opĂ©ration de copie oĂč de dĂ©placement (avec quelques problĂšmes d’affichage corrigĂ©s au passage),
  • des corrections de bug sur le choix de couleurs utilisĂ©es dans la fenĂȘtre « Ouvrir avec »,
  • la possibilitĂ© de crĂ©er un lien symbolique lorsqu’on fait un drag and drop depuis un dossier virtuel,
  • utilisation de la police de caractĂšres « menu » de façon cohĂ©rente dans tous les menus.

Il a Ă©galement travaillĂ© sur des tĂąches de fond, sans changements visibles pour l’instant. Le code du Tracker provient de BeOS et est un peu vieillissant. Il est souvent nĂ©cessaire de faire beaucoup de nettoyage avant de pouvoir dĂ©velopper de nouvelles fonctionnalitĂ©s sans casser autre chose. Cette fois-ci, on trouve entre autres une refonte de la gestion des raccourcis claviers, la fermeture automatique des fenĂȘtres en double lors du passage en mode « navigation spatiale », et divers crashs liĂ©s Ă  la gestion des menus popup.

humdinger a également travaillé sur le Tracker pour améliorer certains messages concernant la copie et la création de fichiers, pour les rendre plus faciles à traduire.

humdinger a Ă©galement travaillĂ© sur l’organisation du menu « templates » (affichĂ© quand on fait un clic droit -> nouveau
 et permettant de crĂ©er diffĂ©rents types de fichiers Ă  partir de fichiers de rĂ©fĂ©rence). Ce menu peut maintenant ĂȘtre organisĂ© en plusieurs sous-menus Ă  l’aide d’une nouvelle option « New template folder », pour les personnes qui utilisent cette fonctionnalitĂ© avec de nombreux fichiers de rĂ©fĂ©rence au point d’avoir besoin de les organiser.

La fenĂȘtre de requĂȘtes (recherche de fichiers en fonction de leurs attributs Ă©tendus indexĂ©s dans le systĂšme de fichiers) permet maintenant d’afficher en temps rĂ©el les rĂ©sultats lorsqu’on Ă©dite une requĂȘte. En outre, il est possible de filtrer les rĂ©sultats pour afficher uniquement les fichiers contenus dans un rĂ©pertoire donnĂ© (auparavant, on pouvait au mieux restreindre par volume disque). Ces changements ont Ă©tĂ© rĂ©alisĂ©s dans le cadre du Google Summer of Code par CalistoMathias, avec Ă©galement une participation de jscipione, humdinger et waddleplash pour finaliser le travail.

Correction d’un crash du Tracker lors de changements de rĂ©solution d’écran (OscarL).

Terminal

Le Terminal permet d’exĂ©cuter des applications en ligne de commande.

Lors du changement de la taille de texte du Terminal, ce dernier ajuste le nombre de lignes et colonnes de texte visibles, au lieu de redimensionner sa fenĂȘtre (nipos).

Prise en compte de la sĂ©quence d’échappement ANSI pour effacer l’historique de dĂ©filement (CodeForEvolution).

PowerStatus

L’application PowerStatus affiche des informations sur les batteries pour les ordinateurs portables.
sen a effectué plusieurs améliorations pour les systÚmes avec plusieurs batteries:

  • Gestion de plusieurs emplacements pour batteries qui ne sont pas forcĂ©ment tous utilisĂ©s,
  • Meilleur calcul des alertes de batterie faible,
  • Prise en compte de la dĂ©connexion de batteries pendant le fonctionnement du systĂšme.

Outils en ligne de commande

La commande profile (qui permet d’analyser les performances d’autres applications et du systĂšme) peut maintenant afficher le nombre d’évĂšnements qui n’ont pas pu ĂȘtre enregistrĂ©s par l’analyseur systĂšme (waddlesplash).

La commande package_repo update (utilisée pour mettre à jour un dépÎt de paquets avec de nouveaux logiciels) peut maintenant fonctionner sans avoir accÚs au contenu complet des fichiers packages à inclure dans le dépÎt (seuls les noms des paquets et quelques autres métadonnées sont réellement nécessaires).

La commande package_repo list dispose d’une option -f pour afficher le nom de fichiers correspondant aux paquets contenus dans un dĂ©pĂŽt de paquets. Les fichiers peuvent ainsi ĂȘtre tĂ©lĂ©chargĂ©s facilement par un outil tiers. (waddlesplash)

Ces deux modifications sont utiles en particulier pour la ferme de build de HaikuPorts, qui souhaite hĂ©berger les fichiers dans des buckets S3 afin de simplifier l’infrastructure et de rĂ©duire les coĂ»ts de fonctionnement.

Amélioration du format de sortie de la commande launch_roster pour indiquer le statut des services et pas simplement leur nom (kallisti5 + waddlesplash).

Ajout dans strace du décodage des drapeaux de configurations de mutex (par exemple MUTEX_SHARED) (waddlesplash).

Serveurs

Les serveurs sont des applications fonctionnant en tùche de fond et qui implémentent une grande partie des fonctionnalités du systÚme.

app_server

app_server est le serveur graphique qui se charge de l’affichage du bureau et des fenĂȘtres.

madmax a travaillĂ© sur la gestion des polices de caractĂšres: correction de problĂšmes de verrouillage pour Ă©viter des accĂšs concurrents au gestionnaire de polices par plusieurs fils d’exĂ©cution, amĂ©lioration du traitement de l’ajout et du retrait de polices, et une optimisation pour Ă©viter de scanner deux fois de suite les dossiers de polices au dĂ©marrage.

waddlesplash a complĂ©tĂ© ce changement en dĂ©plaçant une partie du code de gestion des polices pour Ă©viter que d’autres parties de l’exĂ©cution soient bloquĂ©es par l’initialisation des polices, qui peut prendre beaucoup de temps (quelques secondes) au dĂ©marrage du systĂšme.

waddlesplash a corrigĂ© un problĂšme de calcul de dĂ©lai d’expiration (probablement sans consĂ©quence, dĂ©couvert par hasard en investiguant un autre problĂšme).

jscipione a corrigĂ© un problĂšme de rafraĂźchissement de l’affichage lorsque des fenĂȘtres sont empilĂ©es, qui pouvait conduire Ă  ne pas bien effacer la barre de titre dans certains cas.

Un clic simple sur le coin bas-droite de la fenĂȘtre (coin de redimensionnement) dĂ©clenchait par erreur une minimisation de la fenĂȘtre concernĂ©e (madmax).

media_server

Le media_server prend en charge les flux audio et vidĂ©o et permet de router ces flux entre diffĂ©rentes applications ainsi que depuis et vers le matĂ©riel (cartes son, cartes d’acquisition vidĂ©o, webcams
).

Travaux effectués par waddlesplash:

Correction de problĂšmes de calculs de temps dans le mixeur audio (problĂšmes dĂ©couverts suite Ă  l’amĂ©lioration de la dĂ©tection d’erreurs dans BTimeSource, mentionnĂ© plus haut), et ajout de contrĂŽles d’intĂ©gritĂ© supplĂ©mentaires lors du dĂ©marrage du mixeur.

Cela corrige plusieurs bugs qui faisaient que le systĂšme n’avait pas de son au dĂ©marrage pendant un certain temps, avant que soudainement ça se mette Ă  fonctionner.

D’autre part, des amĂ©liorations de performance sur la programmation des Ă©vĂšnements, et des corrections de crash sur la connexion et dĂ©connexion des nƓuds mĂ©dia vers la sortie audio, et sur le nƓud multi-audio avec certaines cartes sons qui exposent des types de contrĂŽles invalides.

D’autres changements sont en cours pour pouvoir changer la sortie audio sans avoir besoin de redĂ©marrer le serveur mĂ©dia, mais ça ne fonctionne pas encore.

registrar

Le registrar surveille quelles sont les applications déjà lancées et fournit divers services de communication entre applications, en particulier pour le presse-papier.

Ajout de vĂ©rification d’erreurs si un message de rĂ©cupĂ©ration du contenu du presse-papier Ă©choue. Cela peut arriver si on a mis beaucoup de donnĂ©es dans le presse-papier et qu’il n’y a plus assez de mĂ©moire disponible.

Des corrections du cĂŽtĂ© de la libbe permettent maintenant de gĂ©rer ces erreurs et de ne pas faire planter l’application concernĂ©e.

input_server

L’input_server` se charge des pĂ©riphĂ©riques d’entrĂ©e (clavier, souris
)

AmĂ©liorations la validation des donnĂ©es des fichiers de configuration de souris, qui dans certains cas pouvaient empĂȘcher la souris de fonctionner. Refonte de la gestion des accĂšs concurrents Ă  la liste des pĂ©riphĂ©riques, pour supprimer des verrous inutiles et permettre les accĂšs Ă  la liste mĂȘme si un thread de gestion d’un pĂ©riphĂ©rique est bloquĂ©. (madmax)

Les codes de touches pour la touche power et la touche \_ des claviers japonais s’étaient retrouvĂ©s assignĂ©es Ă  des valeurs identiques (cela semble provenir tout droit de changements datant de BeOS, car ces touches non prĂ©sentes sur un clavier de PC amĂ©ricain classiques sont assez mal documentĂ©es). La documentation a Ă©tĂ© mise Ă  jour pour mieux expliquer quels sont les codes utilisĂ©s, et les diffĂ©rents pilotes (PS2, USB) ont Ă©tĂ© harmonisĂ©s pour utiliser les mĂȘmes codes (x512 et PulkoMandy).

Le code power pourra Ă©galement ĂȘtre utilisĂ© par un pilote GPIO sur les machines oĂč c’est nĂ©cessaire (souvent non compatibles PC).

net_server

Le net_server se charge de toutes les opérations liées au réseau.

mmlr a corrigé un problÚme dans le client DHCP, qui utilisait certaines variables sans les initialiser.

package_daemon

Le package_daemon vĂ©rifie la cohĂ©rence des paquets installĂ©s avec leurs dĂ©pendances, crĂ©e les dossiers de transactions et de sauvegarde de l’état passĂ© du systĂšme, et se charge de lancer les scripts d’activation et de dĂ©sactivation de paquets. L’accĂšs au contenu des paquets est en revanche traitĂ© dans le noyau par le systĂšme de fichier packagefs.

Changement des couleurs des fenĂȘtres « problĂšmes » et « rĂ©sultats » qui apparaissent quand il y a des conflits ou d’autres problĂšmes de rĂ©solution de dĂ©pendances lors de l’activation des paquets (jscipione).

Kits

Les « kits » sont les composants de la bibliothĂšque standard de Haiku. Il s’agit principalement d’une convention de documentation et d’organisation de code source pour regrouper des fonctionnalitĂ©s liĂ©es entre elles.

Interface

L’interface kit` permet l’ouverture de fenĂȘtre et l’ajout de contrĂŽles d’interface graphiques Ă  l’intĂ©rieur de ces derniĂšres.

Les objets BBitmap (permettant de stocker une image « raster ») avec le flag ACCEPT_VIEWS (permettant d’attacher une « vue" pour dessiner dans le bitmap ne sont plus automatiquement effacĂ©s. Cela permet de crĂ©er un bitmap Ă  partir de donnĂ©es existantes, puis de dessiner autre chose par-dessus. Ce changement corrige un problĂšme de compatibilitĂ© avec BeOS, et permet aussi d’utiliser cette mĂ©thode dans l’implĂ©mentation de WebKit pour Haiku (ZardShard).

Un changement prĂ©cĂ©dent avait causĂ© un problĂšme de compatibilitĂ© d’API avec BeOS, qui dĂ©clenchait dans certains cas une rĂ©cursion infinie et un crash lorsqu’on essayait de faire dĂ©filer une BListView par glisser-dĂ©placer (par exemple dans l’application Wonderbrush). Waddlesplash a corrigĂ© ce problĂšme, et jscipione a Ă©galement ajoutĂ© quelques amĂ©liorations sur la mise Ă  jour des items sĂ©lectionnĂ©s lorsqu’on effectue cette opĂ©ration.

Il est maintenant possible d’afficher des « checkmarks » (coche indiquant une option activĂ©e) sur les items de menus disposĂ©s en « matrice ». Habituellement les menus sont soit disposĂ©s sur une ligne, soit sur une colonne avec les items les un au-dessous des autres. Le mode « matrice » permet de s’affranchir de ces restrictions pour disposer les items librement avec du code applicatif.

Mise Ă  jour en direct des couleurs dans les contrĂŽles BSpinner, refonte de l’hĂ©ritage des couleurs de la vue parente, et changement de la couleur de fond des boutons en mode sombre (jscipione).

Centrage vertical des dates dans BCalendarView (permettant d’afficher un calendrier) (nipos).

Factorisation de code dans BView pour l’envoi des donnĂ©es BShape vers app_server (x512).

La méthode de debug BPoint::PrintToStream affiche maintenant les coordonnées avec des décimales, permettant de détecter les points qui ne sont pas alignés avec la grille de pixels (ayu-ch).

Les boĂźtes de texte marquĂ©es comme « invalides » ont maintenant un fond rouge. La bordure rouge utilisĂ©e prĂ©cĂ©demment n’était pas assez visible (nephele).

Media

Le media kit permet aux applications de s’interfacer avec le media server, et fournit en plus une interface standardisĂ©e pour les codecs audio et vidĂ©o.

Ajout d’assertions dans la classe BTimeSource pour empĂȘcher les applications d’envoyer des temps avec un « drift » infĂ©rieur ou Ă©gal Ă  0. Le « drift" est utilisĂ© comme multiplicateur et diviseur dans les calculs d’horloge, donc les valeurs infĂ©rieures ou Ă©gales Ă  0 causent des problĂšmes. Ceci a Ă©tĂ© mis en Ă©vidence par des corrections au niveau du noyau (voir plus loin dans la dĂ©pĂȘche) et a ensuite permis de trouver encore d’autres problĂšmes en particulier dans les add-ons media (waddlesplash).

Locale

Le « locale Â» kit permet la traduction des applications, le formatage des nombres en fonction des prĂ©fĂ©rences de chaque pays, la gestion des fuseaux horaires, et toutes les autres problĂ©matiques liĂ©es Ă  l’internationalisation. Il s’agit principalement d’un enrobage de la bibliothĂšque ICU pour faciliter son utilisation avec les types natifs de Haiku.

Meilleure gestion des erreurs si la bibliothĂšque ICU ne peut pas ĂȘtre initialisĂ©e (waddlesplash).

Support

Le support kit contient diverses méthodes et classes utilitaires et génériques.

ContrĂŽle d’intĂ©gritĂ© des donnĂ©es lors de la dĂ©serialisation de BMessage (waddlesplash).

Correction d’incohĂ©rence de nommage de paramĂštres de fonction entre les fichiers .cpp et .h dĂ©tectĂ©s par cppcheck (mt).

Pilotes de périphériques

Les pilotes sont indispensables pour assurer le fonctionnement de Haiku sur une grande variĂ©tĂ© de matĂ©riel. Certains sont dĂ©veloppĂ©s Ă  partir des spĂ©cifications du matĂ©riel spĂ©cifiquement pour Haiku, et d’autres ont Ă©tĂ© adaptĂ©s de travaux rĂ©alisĂ©s pour d’autres systĂšmes d’exploitation.

Le niveau de logging par défaut a été abaissé dans certains pilotes afin de ne pas trop polluer le journal systÚme, en particulier:

  • Suppression de messages indiquant qu’aucun matĂ©riel compatible avec le pilote n’a Ă©tĂ© dĂ©tectĂ©,
  • Suppression de certains logs de debug dans les pilotes audio HDA et usb_audio.

Processeurs et Ă©conomie d’énergie

Renommage du pilote intel_cstates en x86_cstates puisque les processeurs récents de chez AMD sont également pris en charge par ce pilote.

Appel Ă  ce pilote Ă  plus d’endroits dans le noyau pour mettre les processeurs en veille ou au ralenti quand ils ne sont pas utilisĂ©s.

RĂ©seau

virtio_net

Le pilote virtio_net (carte rĂ©seau utilisĂ©e dans les machines virtuelles) implĂ©mente maintenant le « checksum offloading » pour les protocoles IP, TCP et UDP. En effet, dans le cas de ce pilote, les vĂ©rifications et calculs de sommes d’intĂ©gritĂ© doivent ĂȘtre faits de toutes façons du cĂŽtĂ© de la machine hĂŽte, il est donc inutile de les refaire dans la machine virtuelle.

Au passage, correction de quelques erreurs dans ce driver, et en particulier de problÚmes de calcul de taille de buffers en mémoire.

broadcom750x

Utilisation des interruptions par messages (MSI) lorsque c’est nĂ©cessaire pour certaines versions du matĂ©riel (waddlesplash).

 vmxnet

Nouveau pilote portĂ© depuis FreeBSD qui permet d’utiliser l’interface rĂ©seau paravirtualisĂ©e de VMWare (CodeForEvolution).

 Couches de compatibilitĂ© BSD

Haiku utilise des pilotes réseau venus de FreeBSD et OpenBSD, cela permet de mutualiser les ressources et de ne pas perdre du temps à réinventer la roue. Une couche de compatibilité permet de réutiliser les pilotes avec trÚs peu de modification dans leur code et une simple recompilation.

Cette approche est Ă©galement utilisĂ©e par d’autres systĂšmes d’exploitation comme RTEMS.

La couche de compatibilitĂ© a reçu des corrections de problĂšmes sur l’allocation de mĂ©moire dĂ©diĂ©e aux transferts DMA, ainsi qu’un problĂšme sur le calcul de la taille d’un buffer de rĂ©ception, qui empĂȘchait les pilotes de fonctionner sur certains matĂ©riels.

 TCP

Waddlesplash a travaillĂ© sur l’amĂ©lioration de l’implĂ©mentation de TCP :

  • Refonte de la gestion des ACK reçus dans le dĂ©sordre,
  • AmĂ©lioration du code de dĂ©bogage pour investiguer des crashs du noyau remontĂ©s par quelques utilisateurs,
  • Modification du code de mise Ă  jour de la taille de fenĂȘtre TCP pour Ă©viter d’envoyer inutilement des changements de taille,
  • Correction de calcul du temps d’aller-retour,
  • ImplĂ©mentation du redimensionnement dynamique de la fenĂȘtre de rĂ©ception (auparavant, elle Ă©tait de taille fixe),
  • Ajout d’assertions Ă  divers endroits dans la pile rĂ©seau pour dĂ©tecter les problĂšmes Ă  la source.

Ces amĂ©liorations permettent au trafic TCP d’ĂȘtre au moins 10 fois plus rapide, selon le type de connexion utilisĂ©, et rĂšgle un problĂšme de lenteur des tĂ©lĂ©chargements depuis Haiku qui Ă©tait prĂ©sent depuis assez longtemps.

 Ethernet

Du cĂŽtĂ© d’Ethernet, quelques amĂ©liorations et nettoyages sur le calcul de la MTU (taille maximale d’un paquet qui peut ĂȘtre envoyĂ©). Pour l’instant, la dĂ©couverte du « path MTU », la MTU du chemin complet entre deux machines, n’est pas encore disponible. Haiku ne s’autorise donc pas Ă  envoyer du trafic plus large qu’une trame Ethernet standard, mĂȘme si cela pourrait ĂȘtre possible pour le rĂ©seau local. Il reste donc une amĂ©lioration potentielle des performances rĂ©seau dans certains cas.

 UNIX domain sockets

Les sockets UNIX sont une mĂ©thode de communication entre processus standardisĂ©e par POSIX, utilisĂ©e surtout par des logiciels portĂ©s depuis d’autres systĂšmes (les applications natives pour Haiku utiliseront plus volontiers des BMessages ou des ports).

AmĂ©lioration et nettoyage du code autour de la gestion des donnĂ©es annexes dans les sockets UNIX. Correction de petites fuites de mĂ©moire et d’un kernel panic qui pouvait se produire lors de la fermeture d’un socket (waddlesplash).

USB

ImplĂ©mentation de l’USB « Super Speed Plus », qui permet des connexions USB avec un dĂ©bit pouvant atteindre 10 gigabits par seconde (korli).

Refonte et consolidation du comptage de rĂ©fĂ©rences dans la pile USB, ce qui met en Ă©vidence sous forme de kernel panic des cas oĂč les choses ne sont pas bien faites. Ce n’est pas agrĂ©able, mais c’est tout de mĂȘme mieux qu’une corruption mĂ©moire difficile Ă  investiguer (waddleplash).

DĂ©codage des descripteurs USB Audio v2 dans la commande listusb, mais pas encore dans le pilote usb_audio qui implĂ©mente pour l’instant seulement la version 1 (gscrain).

PCI

Correction de problĂšmes d’accĂšs au bus PCI sur les machines Ă©quipĂ©es de ACPI. Suite Ă  une modification prĂ©cĂ©dente, les accĂšs sur 8 ou 16 bits Ă©taient convertis en accĂšs sur 32 bits, mais ce n’est pas le comportement attendu. En particulier, certains registres effacent automatiquement leur contenu lorsqu’ils sont lus, ou bien les donnĂ©es accessibles en lecture et en Ă©criture ne sont pas les mĂȘmes. (PulkoMandy)

Il n’est donc pas possible de lire une valeur sur 32 bits, remplacer 8 bits, et rĂ©Ă©crire 32 bits pour simuler une Ă©criture sur 8 bits dans un registre.

Les accĂšs sont Ă  nouveau traitĂ©s correctement, ce qui permet Ă  Haiku de fonctionner Ă  nouveau normalement sur les machines concernĂ©es par ce type d’accĂšs au bus PCI (cela dĂ©pend du matĂ©riel et des pilotes).

Périphériques de stockage

Petites améliorations de performances dans le pilote NVMe (waddlesplash).

Modification du pilote AHCI/SATA (waddlesplash) :
- Suppression de code dupliquĂ© pour utiliser Ă  la place des fonctions communes partagĂ©es avec d’autres pilotes,
- Correction d’une confusion entre adresses 32 et 64 bits qui empĂȘchait de dĂ©marrer la version 32
bits de Haiku sur certains systĂšmes avec plus de 4Gio de RAM.

La pile SCSI prend mieux en compte les restrictions sur les adresses DMA. Chaque pilote de pĂ©riphĂ©rique qui implĂ©mente SCSI peut indiquer ce qu’il est capable de faire, et la pile SCSI fait en sorte que les demandes de transferts DMA respectent ces contraintes, ce qui Ă©vite aux pilotes de devoir dĂ©couper par eux-mĂȘmes les transferts en unitĂ©s qu’ils sont capables de traiter (waddlesplash).

ACPI

ACPI est une interface standardisĂ©e avec le matĂ©riel. Elle permet la gestion d’énergie (extinction de la machine par exemple), ainsi que l’accĂšs Ă  du matĂ©riel annexe tels que les boutons on/off, la dĂ©tection de rabat de l’écran sur un PC portable, le contrĂŽle des LEDs indicatrices ; ainsi que la dĂ©couverte de matĂ©riel non connectĂ© sur le bus PCI (comme certains modules eMMC dans des tablettes et ordinateurs Ă  bas coĂ»t).

La spĂ©cification Ă©tant assez complexe, la bibliothĂšque ACPICA est utilisĂ©e pour implĂ©menter les bases de ACPI. Ensuite, des pilotes dĂ©diĂ©s permettent d’exposer chaque pĂ©riphĂ©rique ACPI.

Mise à jour de ACPICA avec la derniÚre version publiée par Intel (publiée en mars), et un peu de nettoyage afin de pouvoir intégrer quelques patchs dans la version upstream de ACPICA (PulkoMandy).

Ajustement du pilote ACPI pour mapper sa mĂ©moire physique en « write back » au lieu de dĂ©sactiver complĂštement le cache. C’est nĂ©cessaire sur ARM64, car le cache permet d’intercepter les accĂšs mĂ©moire non alignĂ©s. Correction de problĂšmes liĂ©s au fait que la mĂȘme zone de mĂ©moire physique pouvait ĂȘtre mappĂ©e plusieurs fois avec des configurations diffĂ©rentes, ce qui est impossible (dĂ©clenche une « machine check exception ») (oanderso).

Graphiques

AvancĂ©es sur la prise en charge des cartes graphiques Intel de gĂ©nĂ©rations Tiger Lake, Ice Lake et Gemini Lake (ttmfx, ilzu, PulkoMandy). L’utilisation de ces cartes graphiques reste assez limitĂ©, sans accĂ©lĂ©ration matĂ©rielle et sans possibilitĂ© d’utiliser plusieurs Ă©crans pour l’instant.

virtio

Les pilotes virtio permettent l’utilisation de matĂ©riel virtuel dĂ©fini pour tirer le meilleur parti des machines virtuelles. PlutĂŽt que de copier le fonctionnement d’un matĂ©riel existant, l’interface peut ĂȘtre conçue pour rendre le travail plus simple aussi bien pour l’hĂŽte que pour le systĂšme virtualisĂ©.

Correction de problĂšmes dans l’allocation des files de messages virtio et amĂ©lioration de la gestion des erreurs (mmlr).

VĂ©rification de l’état du pĂ©riphĂ©rique aprĂšs une rĂ©initialisation, et correction d’un accĂšs mĂ©moire hors limite dans le pilote virtio_pci (korli).

PS/2

Les ports PS/2 ont disparu de la plupart des machines depuis de nombreuses annĂ©es, mais le protocole est encore utilisĂ© pour les claviers des ordinateurs portables ainsi que pour certains touchpads. Ces derniers utilisent de nombreuses extensions peu standardisĂ©es et mal documentĂ©es pour offrir des fonctions avancĂ©es qui n’existaient pas Ă  l’époque des souris Ă  deux boutons.

Le driver reçoit ce trimestre une refonte de la gestion des verrous entre ses différents composants, pour essayer de régler quelques problÚmes de synchronisation (waddlesplash).

SystĂšmes de fichiers

ram_disk et ramfs

ram_disk est un pĂ©riphĂ©rique bloc (block device) qui stocke ses donnĂ©es en RAM (non persistante au redĂ©marrage). Il peut ĂȘtre formatĂ© avec n’importe quel systĂšme de fichier.

ramfs est un systĂšme de fichiers qui stocke ses donnĂ©es en RAM, sans passer par un block device. Cela permet de meilleures performances (pas besoin de journalisation par exemple), une meilleure intĂ©gration avec le cache de fichiers (la mĂ©moire peut ĂȘtre partagĂ©e directement entre ramfs et le cache), et de s’affranchir des limites habituelles des pĂ©riphĂ©riques de bloc (par exemple: une taille fixe connue lors de la crĂ©ation du systĂšme de fichiers).

Un utilisateur a remontĂ© un problĂšme de compatibilitĂ© avec POSIX. Si on utilise mmap() sur un fichier stockĂ© dans un ramfs, et que la taille du fichier n’est pas un multiple de la taille des pages de mĂ©moire, la fin de la derniĂšre page pouvait contenir des donnĂ©es alĂ©atoires. Selon la spĂ©cification POSIX, il faut que cette zone soit remplie avec des 0, et le compilateur clang dĂ©pend de ce comportement pour implĂ©menter une lecture rapide des fichiers sources compilĂ©s.

Le problÚme a été corrigé, avec au passage une commonalisation de code entre ramfs et ram_disk, de petits ajustements de performances, et un peu de nettoyage.

Enfin, la prioritĂ© des allocations mĂ©moires de ces deux pilotes a Ă©tĂ© abaissĂ©e, ce qui permet d’éviter un gel du systĂšme s’il n’y a plus de mĂ©moire disponible.

Le pilote ramfs continue d’ĂȘtre stabilisĂ©, quelques problĂšmes qui pouvaient encore causer des kernel panic ont Ă©tĂ© corrigĂ©s.

packagefs

packagefs est un systĂšme de fichier virtuel qui expose le contenu de fichiers de packages au format hpkg. Des paquets peuvent ĂȘtre ajoutĂ©s et supprimĂ©s pendant le fonctionnement du systĂšme, et il n’est pas nĂ©cessaire d’extraire leurs donnĂ©es sur disque.

Plusieurs améliorations faites par waddlesplash :

  • Ajout de vĂ©rifications de la bonne utilisation de verrous entre diffĂ©rents threads et corrections de problĂšmes mineurs qu’elles ont mis en Ă©vidence,
  • AmĂ©lioration du message d’erreur si on essaie d’activer deux paquets qui entrent en conflit.

Un reproche qui est souvent fait au packagefs est d’avoir augmentĂ© les besoins en RAM de Haiku, en effet, depuis la version Beta 1 de Haiku, la configuration mĂ©moire minimum recommandĂ©e est de 384Mio de RAM, alors que les versions prĂ©cĂ©dentes se contentaient de 128Mio.

  • Utilisation d’object_cache` (un allocateur mĂ©moire pour des objets qui font tous la mĂȘme taille) dans diffĂ©rents endroits de packagefs pour rĂ©duire sa consommation de mĂ©moire,
  • Utilisation de listes chaĂźnĂ©es simples au lieu de listes chaĂźnĂ©es doubles lĂ  oĂč ça ne pose pas de problĂšme de performances,
  • Suppression de champs constants dans certaines classes,
  • « inlining » des compteurs de rĂ©fĂ©rences pour rendre les structures de donnĂ©es plus compactes,
  • RĂ©organisation des structures pour rĂ©duire le padding,
  • Retrait des « dĂ©pĂŽts d’objets » dans les arĂšnes d'allocation,
  • DĂ©coupage des allocations en plusieurs zones distinctes,
  • Utilisation de verrous moins fins (par exemple, avoir un seul verrou pour tout un dossier au lieu de un par fichier),
  • Utilisation d’un « bump allocator » pour les objets Ă  courte durĂ©e de vie.

La rĂ©duction de consommation mĂ©moire avec ces changements est de prĂšs de 20%, soit environ 15Mio sur une installation de rĂ©fĂ©rence. En effet, un gain de quelques octets sur le stockage d’informations sur un fichier est multipliĂ© par plusieurs milliers de fichiers prĂ©sents sur le disque, ce qui fait que chaque petite optimisation est intĂ©ressante. Cependant, les investigations ont aussi permis de dĂ©couvrir d’autres problĂšmes encore plus importants qui n’étaient pas directement liĂ©s au packagefs, on en reparle un peu plus loin.

Un autre changement a Ă©tĂ© fait par waddlesplash, non seulement pour packagefs mais aussi pour d’autres endroits oĂč le mĂȘme code Ă©tait utilisĂ© : La fonction pour calculer un hash de chaĂźne de caractĂšres utilisait un algorithme obsolĂšte. Elle a Ă©tĂ© remplacĂ©e par hashdjb2 qui gĂ©nĂšre moins de collisions.

FAT

FAT est un systÚme de fichier développé par Microsoft. Il est utilisé en particulier sur les cartes SD et les clés USB, ainsi que pour les partitions systÚmes EFI. Bien que sa conception soit quelque peu obsolÚte, il reste donc indispensable.

Le pilote FAT de Haiku, qui provenait tout droit d’un code source publiĂ© par Be, a Ă©tĂ© remplacĂ© dans la version beta 5 par une nouvelle version basĂ©e sur le code de FreeBSD. Ce nouveau pilote reçoit depuis des amĂ©liorations rĂ©guliĂšres par Jim906, le dĂ©veloppeur qui s’est chargĂ© du portage du code de FreeBSD.

Ce trimestre, le pilote reçoit des corrections sur l’initialisation des « media bytes » dans l’en-tĂȘte des partitions, des amĂ©liorations de performances pour rĂ©duire le temps nĂ©cessaire au montage d’une partition FAT, ainsi qu’une meilleure gestion des erreurs dans le traitement des noms de volumes. Il est Ă©galement possible de monter les volumes FAT de taille supĂ©rieure Ă  2TiO.

BFS

BFS est le systĂšme de fichier hĂ©ritĂ© de BeOS et utilisĂ© pour les partitions natives de Haiku. Il propose une trĂšs bonne implĂ©mentation des attributs Ă©tendus (sans limite de taille, et typĂ©s) et permet en plus d’exĂ©cuter des requĂȘtes sur ces attributs pour localiser trĂšs rapidement les fichiers rĂ©pondant Ă  certains critĂšres.

L’implĂ©mentation du systĂšme de fichier BFS est assez mĂ»re et reçoit habituellement peu d’évolutions. Cependant, il reste toujours des possibilitĂ©s d’amĂ©liorer les performances.

C’est le cas de la fonction de recherche de blocs libres. Les blocs sont chacun reprĂ©sentĂ©s par un bit dans une structure indiquant s’ils sont disponibles ou pas. La recherche de blocs libres se faisait bit Ă  bit, mais il est possible de gagner beaucoup de temps en testant 64 bits d’un coup pour savoir tout de suite qu’ils reprĂ©sentent tous des blocs occupĂ©s, et passer directement aux 64 bits suivants. Cela amĂ©liore les performances de la crĂ©ation et du redimensionnement de fichier, en particulier sur les architectures RISC-V (waddlesplash).

Query parser

Plusieurs systĂšmes de fichiers conçus pour BeOS ou Haiku (bfs, ramfs, et packagefs) permettent l’utilisation d’attributs indexĂ©s par le systĂšme de fichiers qui permettent d’effectuer des requĂȘtes pour localiser des fichiers comme dans une base de donnĂ©es.

Depuis la version beta 5 de Haiku, ces 3 systĂšmes de fichiers partagent le code utilisĂ© pour parser une requĂȘte (envoyĂ©e sous forme de texte) et la convertir en une opĂ©ration de recherche exĂ©cutable.

Ce parser pouvait dans certains cas (requĂȘtes trop complexes) dĂ©clencher volontairement un kernel panic. Celui-ci a Ă©tĂ© remplacĂ© par une « simple » erreur, remontĂ©e Ă  l’application qui a dĂ©clenchĂ© la requĂȘte. L’application aura la charge de remonter cette erreur Ă  l’utilisateur, et de l’inviter Ă  simplifier sa demande.

block_cache

Le cache de blocs, comme son nom l’indique, stocke en mĂ©moire RAM une copie de certains blocs des systĂšmes de fichiers. Cela permet d’accĂ©lĂ©rer les opĂ©rations bas niveau sur le systĂšme de fichier, en particulier pour mettre en cache des structures internes du disque. Il complĂšte le file_cache, qui lui se trouve Ă  un niveau plus haut, et met en cache uniquement le contenu des fichiers lus et Ă©crits par les applications.

Le seul changement notable sur le block_cache est le retrait de paramÚtres inutilisés dans certaines fonctions, afin de simplifier le code (waddlesplash).

kernel

Une correction de bug sur le blocage des threads avec timeout (par exemple, l’attente d’un mutex ou d’un sĂ©maphore avec un dĂ©lai maximum): dans certains cas, une fonction pouvait retourner B_TIMED_OUT pour d’autres raisons que l’expiration du timer. Ce n’était pas traitĂ© correctement, et le noyau supposait que le timeout avait expirĂ©, alors qu’il s’agissait d’autre chose. Des vĂ©rifications supplĂ©mentaires permettent de traiter ce cas correctement.

Correction de problĂšme sur la programmation des timeouts « absolus temps-rĂ©el ». Comme leur nom l’indique, ils rĂ©fĂ©rencent l’horloge « real time » (qui essaie de suivre l’heure et la date « rĂ©elle », par opposition Ă  l’horloge systĂšme qui est basĂ©e sur l’uptime de la machine, mais garantit de ne jamais faire de saut ou revenir en arriĂšre). Ces timers ne fonctionnaient pas du tout (ou alors, seulement sur un coup de chance), et restaient probablement bloquĂ©s pendant une durĂ©e beaucoup plus longue que demandĂ©. Au passage, nettoyage du code de gestion des timers.

Dans le code de gestion des interruptions: ajout d’assertions pour investiguer un bug dans les addons vmware ou virtualbox.

Correction d’un bug dans l’implĂ©mentation de kqueue qui produisait un blocage au dĂ©marrage de la libevent (qui utilise maintenant kqueue pour Haiku).

Des petites amĂ©liorations de performances: sur l’allocateur mĂ©moire du noyau, sur l’utilisation de verrous dans la gestion de la mĂ©moire virtuelle, des fuites de mĂ©moire dans l’allocation de page, des amĂ©liorations sur la dĂ©tection de rĂ©fĂ©rences devenues invalides (jpelczar + waddlesplash).

Le script de link du noyau refuse maintenant les sections inconnues avec un message d’erreur, au lieu de simplement les ignorer (korli).

Correction du dĂ©compte du temps CPU utilisĂ© par le thread en cours d’exĂ©cution, pour donner des rĂ©sultats plus fiables dans les applications qui affichent l’utilisation CPU (waddlesplash).

Refactorisation du dĂ©compte du temps d’exĂ©cution des appels systĂšmes. Seul le temps passĂ© dans l’exĂ©cution du syscall est prise en compte, sans mesurer la mise en place d’un appel systĂšme et du retour vers l’espace utilisateur (qui ne peuvent de toutes façons pas ĂȘtre mesurĂ©es de façon fiable depuis le noyau). Cela rend l’affichage des durĂ©es d’exĂ©cution dans strace plus facile Ă  interprĂ©ter (waddlesplash).

RĂ©duction de la taille maximale des tampons mĂ©moire pour stocker des dirent Ă  8Kio. La plupart des applications n’utilisent pas un tampon aussi large, et les quelques-unes qui le faisaient ont Ă©tĂ© modifiĂ©es pour rĂ©duire la taille. Cette rĂ©duction permet d’utiliser un allocateur spĂ©cialisĂ© beaucoup plus rapide, ce qui devrait compenser les rares cas oĂč le tampon est trop petit pour rĂ©cupĂ©rer tout le contenu d’un dossier en une seule fois (waddlesplash).

Correction de plusieurs problĂšmes dans le systĂšme de gestion des ressources faibles (qui essaie de libĂ©rer de la mĂ©moire quand il n’y en a plus assez de disponible). Dans certains cas, le systĂšme finit par geler ou dĂ©clencher un kernel panic, alors qu’il devrait toujours ĂȘtre possible de refuser des demandes d’allocation mĂ©moire venant de l’espace utilisateur, et de conserver suffisamment de mĂ©moire libre pour au moins afficher proprement une erreur.

Amélioration de la gestion des mutex (exclusions mutuelles entre threads):

  • Ajout d’assertions pour dĂ©tecter des cas de rĂ©veil d’un thread qui ne devrait pas l’ĂȘtre.
  • Correction d’un problĂšme introduit rĂ©cemment et investiguĂ© Ă  l’aide de ces nouvelles assertions.
  • L’ABI des locks est identiques entre les builds du kernel en version debug ou release, ce qui permet de ne pas avoir besoin de recompiler tous les pilotes dans le mĂȘme mode que le kernel. Les pilotes compilĂ©s en mode release vont dĂ©clencher une erreur de symbole manquant si on essaie de les utiliser avec un noyau en mode debug, dans l’autre sens, il n’y a pas de problĂšme. Auparavant, dans les deux cas on obtenait des crashes ou un gel complet du systĂšme, difficile Ă  investiguer et faisant perdre du temps.
  • Ajout d’assertions dans plusieurs cas pour dĂ©tecter les utilisations incorrectes des rw-locks. Certaines activĂ©es par dĂ©faut, et d’autres uniquement sur demande Ă  la compilation du noyau en raison de coĂ»t de vĂ©rification trop importants.
  • Correction de mauvaises utilisations des rwlocks ainsi dĂ©tectĂ©es.

GĂ©nĂ©ralisation de l’utilisation de fonctions utilitaires partagĂ©es pour la conversion des timespec en durĂ©es en microsecondes. Cela permet aux fonctions concernĂ©es (entre autres kqueue) de bĂ©nĂ©ficier de contrĂŽles de validitĂ© supplĂ©mentaires (waddlesplash).

Ajout d’informations de debug supplĂ©mentaires dans la sortie de la commande slab_object du debugger du noyau.

RĂ©activation de la calibration du TSC Ă  partir d’informations du CPUID lorsque Haiku s’exĂ©cute dans un hyperviseur, comme c’était dĂ©jĂ  le cas lorsqu’il s’exĂ©cute directement sur une machine physique. Le TSC est un timer interne du CPU qui permet des mesures de temps trĂšs rapides (une seule instruction CPU) mais dans une Ă©chelle de temps arbitraire qu’il faut corrĂ©ler avec le « vrai » temps. Cela peut ĂȘtre fait soit Ă  l’aide d’une mesure empirique (mĂ©thode historique), soit Ă  l’aide d’informations sur cette horloge disponibles dans les informations retournĂ©es par l’instruction CPUID.

Affichage de plus de fonctionnalités du CPU reconnues dans les logs de debug pour les processeurs x86 (korli).

Ajout d’un raccourci clavier (Control+D) pour quitter le debugger noyau et reprendre l’exĂ©cution normale si possible (Ă©quivalent Ă  la commande continue ou co) (mmlr).

Le chargement des pilotes de pĂ©riphĂ©riques se fait en prioritĂ© depuis les dossiers non-packaged avant de rechercher les fichiers dans les paquets logiciels, ce qui permet de tester facilement une version modifiĂ©e d’un pilote - sauf si les dossiers non-packaged sont dĂ©sactivĂ©s dans la configuration du noyau (korli).

VFS

Le VFS (virtual file system) est le composant de Haiku qui gĂšre l’accĂšs aux fichiers. Il fait l’intermĂ©diaire entre les appels systĂšmes liĂ©s aux fichiers (open, read, write
) et les systĂšmes de fichiers eux-mĂȘmes. Il implĂ©mente autant que possible ce qui peut ĂȘtre mis en commun entre tous les systĂšmes de fichiers: rĂ©solution de chemins relatifs, vĂ©rification de permissions


Cela rend plus facile l’écriture d’un nouveau systĂšme de fichiers, qui peut alors se concentrer sur les aspects bas niveau et la gestion de ses structures de donnĂ©es.

Ajout de vĂ©rifications d’intĂ©gritĂ©s supplĂ©mentaires dans le VFS pour dĂ©tecter des bugs dans les systĂšmes de fichiers le plus rapidement possible, au lieu d’obtenir un crash du noyau difficile Ă  investiguer un peu plus tard.

Retrait d’un scan du bus SCSI et des pilotes associĂ©s par le device manager pour rĂ©duire un peu le temps de dĂ©marrage.

Correction d’un gros problĂšme dans l’API du noyau IORequest qui aboutissait Ă  une confusion entre la taille totale d’une requĂȘte et l’offset de la derniĂšre donnĂ©e transfĂ©rĂ©e (les transferts ne commençant pas forcĂ©ment Ă  l’offset 0). La consĂ©quence Ă©tait l’écrasement de donnĂ©es dans le cache de fichiers, dĂ©clenchant des crashes du noyau avec des messages d’erreur incomprĂ©hensibles Ă  propos des structures de pages. Correction d’un problĂšme de calcul d’offset qui faisait que certaines opĂ©rations Ă©taient considĂ©rĂ©es comme rĂ©ussies, alors qu’il y avait en fait une erreur.

Correction de problĂšmes de dĂ©comptage de rĂ©fĂ©rences et de gestion du cache Ă  l’interface entre ramfs et VFS, mis en Ă©vidence lors du travail de portage de Firefox.

Ajout d’une acquisition de rĂ©fĂ©rence sur un vnode qui manquait dans le cache de fichiers (waddlesplash).

Améliorations du cache d'entrées, dont en particulier la mise en cache du hash des noms de fichiers, pour éviter des comparaisons de chaßnes de caractÚres inutiles.

Gestion de la mémoire

La gestion de la mĂ©moire virtuelle est une des tĂąches essentielles d’un systĂšme d’exploitation. Elle garantit l’isolation entre les diffĂ©rents processus, permet d’utiliser la mĂ©moire physique le mieux possible (Ă©ventuellement en dĂ©plaçant certaines allocations peu utilisĂ©es vers un espace d’échange sur disque), et permet aussi aux diffĂ©rents processus de se partager des donnĂ©es.

Il s’agit Ă©galement d’un composant trĂšs sollicitĂ©, et dont les performances impactent beaucoup le comportement du systĂšme. Une mauvaise gestion de la mĂ©moire peut fortement ralentir le systĂšme ou le rendre instable.

Ajout d’assertions dans le code gĂ©rant les pages de mĂ©moire, pour essayer d’intercepter ce type de correction plus rapidement si elles se reproduisent.

Dans l’arbre des areas globales : ajout d’assertions pour dĂ©tecter les identifiants d’areas dupliquĂ©s (chaque area doit bien sĂ»r avoir un identifiant unique).

ImplĂ©mentation de PAT (Page Attribute Table) pour les processeurs x86. Les PAT permettent de configurer des zones de mĂ©moires qui peuvent ou ne peuvent pas ĂȘtre mises en cache (complĂštement ou en write-through). Elles remplacent les MTRR en permettant un contrĂŽle plus fin et plus flexible. Au passage, nettoyage de l’implĂ©mentation des MTRR (prĂ©servĂ©e pour les processeurs plus anciens incompatibles avec PAT), ajout de nouvelles commandes dans le debugger noyau. Renommage des constantes B_MTR_* pour indiquer prĂ©cisĂ©ment leur rĂŽle indĂ©pendamment des dĂ©nominations utilisĂ©es dans les registres MTRR qui ne sont pas trĂšs claires (mmlr).

Lorsque le systĂšme utilise PAT, ajout d’assertions pour dĂ©tecter les tentatives d’accĂ©der Ă  la mĂȘme zone de mĂ©moire physique avec des configurations de cache diffĂ©rentes. Elles ne sont pas activĂ©es lorqu'on utilise les MTRR, car ces derniĂšres ne permettent pas une configuration aussi fine (waddlesplash).

Ajout d’informations supplĂ©mentaire dans le message de kernel panic indiquant qu’une page devrait ĂȘtre libre mais qu’elle ne l’est pas. Modification de la commande page du debugger noyau pour rĂ©cupĂ©rer la liste des espaces d’adressage depuis les structures du kernel plutĂŽt que d’itĂ©rer sur tout l’espace d’adressage (ce qui pouvait fonctionner sur un espace 32 bit, mais pas en 64 bit).

Correction du code de « guarded heap » du noyau qui ne compilait plus. Il s’agit d’un allocateur mĂ©moire plus lent mais avec de nombreuses vĂ©rifications d’intĂ©gritĂ© pour dĂ©tecter les dĂ©bordements de tampons, double free, et autres problĂšmes de gestion de la mĂ©moire dans le noyau (kallisti5).

Le fichier swap est automatiquement supprimĂ©, et l’espace disque libĂ©rĂ©, lors de la dĂ©sactivation de la swap. Auparavant, un redĂ©marrage Ă©tait nĂ©cessaire (waddlesplash).

Correction d’un problĂšme dans l’allocation de mĂ©moire « early boot » (avant que l’allocation normale soit mise en place), qui empĂȘchait le dĂ©marrage sur les systĂšmes pouvant gĂ©rer de grandes quantitĂ©s de mĂ©moire (plusieurs centaines de Gio) (waddlesplash).

libroot

La libroot regroupe tous les composants de la librairie standard C (parfois dĂ©coupĂ©e en libc, libm et libpthread pour d’autres systĂšmes). Elle contient en plus un certain nombre d’extensions spĂ©cifiques Ă  Haiku et Ă  BeOS.

Changements effectués par waddlesplash, sauf mentions spécifiques:

Nettoyage de code dans la classe WeakReferenceable, une classe de comptage de références intrusive qui autorise les références "faibles".

Correction de problùmes dans le code d’interfaçage avec ICU pour la conversion de dates (nipos et waddlesplash).

libnetwork

Nettoyage de code de compatibilitĂ© avec BeOS dans la libnetwork, pour faire en sorte qu’il ne soit plus du tout compilĂ© sur les architectures n’offrant pas de compatibilitĂ© avec BeOS.

Compatibilité POSIX

ImplĂ©mentation minimale de mknod et mknodat dans le seul cas spĂ©cifiĂ© par POSIX, qui permet de rĂ©aliser une opĂ©ration Ă©quivalente Ă  mkfifo. La gestion des devices dans Haiku est trĂšs diffĂ©rente de celle utilisĂ©e traditionellement par UNIX, et ne se prĂȘte pas Ă  l’implĂ©mentation des autres utilisations de ces fonctions.

Rectification de l’implĂ©mentation des fonctions *at (par exemple linkat) qui permettent de rĂ©aliser une opĂ©ration Ă  partir d’un descripteur de fichier au lieu d’un path. Dans la libroot, ces fonctions envoyaient la valeur -1 aux appels systĂšmes pour implĂ©menter AT_FDCWD. La valeur de AT_FDCWD a Ă©tĂ© modifiĂ©e pour choisir autre chose que -1 (qui est souvent utilisĂ© pour indiquer une erreur dans le code de retour d’autres fonctions). Les appels systĂšmes acceptent pour l’instant les valeurs -1 et AT_FDCWD, mais rejettent maintenant toutes les autres valeurs nĂ©gatives.

Remplacement d’une partie du code de gestion des flux d’entrĂ©e-sortie par la version de la glibc. La bibliothĂšque libroot est un patchwork d’implĂ©mentations provenant de la glibc, de musl, et de divers BSD, un objectif Ă  terme est d’essayer de se rapprocher d’une de ces implĂ©mentations, mais on ne sait pas encore trop de laquelle. En tout cas, le code des I/O provient majoritairement de la glibc afin d’ĂȘtre trĂšs compatible avec ce qui Ă©tait utilisĂ© dans BeOS.

La fonction gmtime retourne une struct tm avec le champ tm_zone contenant la chaĂźne "GMT" (waddlesplash).

Correction de la conversion des "surrogate pairs" dans la fonction mbrtowc.

Mise en conformitĂ© de l’implĂ©mentation des threads avec POSIX :

  • Ajustement de code d’erreurs retournĂ©s par les fonctions
  • Suppression de la possibilitĂ© de retourner EINTR depuis un rwlock
  • Correction de deadlocks dans les barriers
  • Correction de plusieurs problĂšmes dans l’implĂ©mentation des sĂ©maphores anonymes.

Mise en place systĂ©matique de l’utilisation de _DEFAULT_SOURCE pour protĂ©ger les extensions Ă  la norme POSIX, ce qui permet de les activer automatiquement via l’inclusion de features.h lorsque c’est possible.

Nettoyage de quelques fichiers d’en-tĂȘte, dont en particulier <sys/select.h>, pour Ă©viter de polluer l’espace global avec des macros et des dĂ©finitions en double (waddlesplash).

Prise en compte correcte du drapeau O_NONBLOCK lors de l’ouverture d’un FIFO (korli).

runtime_loader

Le runtime_loader est le composant responsable du chargement en mĂ©moire des exĂ©cutables et du lancement de nouveaux processus. Il rĂ©alise la rĂ©solution des dĂ©pendances et la recherche des bibliothĂšques partagĂ©es nĂ©cessaires pour l’exĂ©cution d’un programme.

Il reçoit des Ă©volutions suite au portage d’applications complexes venues de Linux, qui nĂ©cessitent souvent plusieurs dizaines de bibliothĂšques partagĂ©es.

Correction de problÚmes détectés en testant un portage expérimental et instable de Firefox: crash du runtime_loader dans certains cas si on charge une bibliothÚque (via dlopen ou load_add_on) dont il manque des dépendances.

Retrait de l’option -fno-builtin dans les drapeaux de compilation du runtime_loader, comme cela avait dĂ©jĂ  Ă©tĂ© fait pour la majoritĂ© de la libroot. Cela permet Ă  gcc de remplacer des appels Ă  des fonctions standardisĂ©es par une implĂ©mentation inline plus performante (waddlesplash).

Outils de debug

DĂ©veloppement d’outils pour enregistrer ce qu’il se passe pendant le dĂ©marrage du systĂšme et dĂ©tecter d’éventuels problĂšmes de latence, de 'lock contention', etc. Au passage, correction de divers problĂšmes liĂ©s Ă  ces outils : les barres de dĂ©filement de DebugAnalyzer, les permissions noyau dans transfer_area, etc.

Amélioration de la remontée des valeurs de retour des appels systÚmes vers strace sur les plateformes x86 32-bit.

Pour terminer, un changement rĂ©alisĂ© par mmlr : amĂ©lioration de l’allocateur mĂ©moire "guarded heap" pour le rendre utilisable plus facilement, y compris comme allocateur pour tout le systĂšme. Cet allocateur permet de dĂ©tecter les accĂšs au-delĂ  de la fin d’une zone mĂ©moire allouĂ©e avec malloc(), ainsi que les accĂšs Ă  de la mĂ©moire dĂ©jĂ  libĂ©rĂ©e, mais au prix d’une consommation mĂ©moire nettement plus Ă©levĂ©e qu’un allocateur classique. La disponibilitĂ© d’un espace d’adressage de 64 bits permet de limiter les cas oĂč une adresse mĂ©moire est initialement utilisĂ©e pour une allocation, puis libĂ©rĂ©e et allouĂ©e Ă  nouveau pour autre chose.

Un problĂšme de gestion d’erreur dans l’interfaçage entre le Debugger et le noyau pouvait conduire Ă  un gel complet du systĂšme dans certains cas de plantage du debug_server, en particulier s’il n’y a plus assez de mĂ©moire RAM disponible.

Bootloader

Ajout d’une vĂ©rification manquante pour prendre en compte l’option « BlockedEntries » dans le bootloader. Cette option s’appelait prĂ©cĂ©demment « EntriesBlacklist » mais a Ă©tĂ© renommĂ©e pour utiliser un terme non entachĂ© de racisme. L’ancien nom continue de fonctionner pour ne pas casser les installations existantes, mais n’est plus documentĂ©.

Augmentation de la taille maximum autorisĂ©e pour les allocations « standard » sur la pile. L’allocateur mĂ©moire du bootloader traite sĂ©parĂ©ment les allocations de grande taille, mais ces allocations ne sont pas correctement libĂ©rĂ©es lors du transfert de contrĂŽle vers le noyau, en particulier sur les machines utilisant un BIOS non EFI. Pour l’instant, une correction complĂšte du problĂšme semble compliquĂ©e Ă  mettre en place, mais la modification permet de libĂ©rer de la mĂ©moire allouĂ©e pour l’accĂšs au packagefs (le bootloader a besoin d’y accĂ©der pour trouver le noyau, qui est stockĂ© dans un paquet). Ce changement permet de libĂ©rer plusieurs dizaines de Mio de mĂ©moire, et complĂšte les changements mentionnĂ©s plus haut sur la gestion des paquets aprĂšs dĂ©marrage. Il est possible de configurer Haiku pour fonctionner avec moins de 100Mio de mĂ©moire (waddlesplash).

RĂ©paration de la rĂ©-initialisation des ports sĂ©rie sur le bootloader EFI. Le port sĂ©rie est utilisĂ© Ă  des fins de debug, mais il peut ĂȘtre accĂ©dĂ© de plusieurs façons diffĂ©rentes (en adressant directement le matĂ©riel, ou bien via des services EFI dĂ©diĂ©s). Le bootloader doit passer d’une mĂ©thode Ă  l’autre Ă  diffĂ©rentes Ă©tapes du dĂ©marrage: accĂšs direct au port physique dans les premiĂšres Ă©tapes (en dĂ©tectant s’il est bien prĂ©sent Ă  une adresse standard), accĂšs via les services EFI une fois ceux-ci initialisĂ©s, puis Ă  nouveau accĂšs direct au matĂ©riel aprĂšs l’arrĂȘt des services EFI pour la derniĂšre Ă©tape de passage de contrĂŽle au noyau (cette fois-ci Ă  une adresse qui peut ĂȘtre configurĂ©e dans les options du bootloader et du noyau). Ce fonctionnement ne s’insĂšre pas forcĂ©ment trĂšs bien dans la logique du bootloader, qui n’avait Ă  l’origine pas Ă©tĂ© conçu pour une gestion aussi complexe des entrĂ©es-sorties (VoloDroid).

Réduction de la quantité de logs liés à la mise en place de SMP (gestion de plusieurs processeurs) dans le bootloader pour BIOS (waddlesplash).

Le menu de dĂ©marrage affiche la version (numĂ©ro 'hrev') du paquet systĂšme correspondant Ă  chaque point de restauration disponible, ce qui facilite l’identification des Ă©tats qui correspondent Ă  un changement de version du systĂšme, et pas une simple installation, dĂ©sinstallation ou mise Ă  jour de paquets logiciels (waddlesplash).

Documentation

Haiku Book

Le « Haiku Book » est un projet de documentation des APIs publiques de Haiku. Il doit Ă  terme remplacer le « Be Book », qui documente les APIs de BeOS, mais ne peut pas ĂȘtre mis Ă  jour Ă  cause de se license CC BY-NC-ND. Actuellement, il faut jongler entre ces deux documentations.

La documentation de B_INFINITE_TIMEOUT (constante permettant d’indiquer Ă  certaines fonctions qu’on veut les exĂ©cuter sans timeout, et attendre indĂ©finiment) a Ă©tĂ© mise Ă  jour pour indiquer explicitement que sa valeur numĂ©rique est INT64_MAX (waddlesplash).

Correction de fautes de frappe dans la documentation des API liées aux entrées clavier (drea233).

Haiku Interface Guidelines

Ce document prĂ©sente les bonnes pratiques et conventions pour la conception d’interfaces graphiques fonctionnant avec Haiku.

Ajout d’une section sur la gestion des fichiers rĂ©cemment utilisĂ©s et la façon dont ils peuvent ĂȘtre exposĂ©s aux utilisateurs.

Wiki et documentation interne

Le wiki contient des informations utiles aux développeurs de Haiku.

La documentation « interne" documente le fonctionnement de Haiku en s’adressant principalement aux contributeurs du systĂšme, par opposition aux personnes qui souhaitent seulement dĂ©velopper ou porter des applications.

Mise Ă  jour de la page « release cookbook » indiquant toutes les Ă©tapes Ă  suivre lors de la publication d’une version de Haiku.

Notes d’administration systùme : mise à jour des instructions pour instancier des machines Google Cloud Platform (kallisti5).

SystĂšme de build, environnement de compilation

La compilation d’un systĂšme d’exploitation complet n’est pas chose facile. D’autant plus pour Haiku, qui prĂ©sente les particularitĂ©s suivantes:

  • Utilisation de deux versions de gcc (gcc 2.95.3 et gcc 13) pour la version 32 bit de Haiku, afin d’assurer la compatibilitĂ© binaire avec BeOS,
  • PossibilitĂ© de compilation croisĂ©e depuis Linux, Mac OS et d’autres systĂšmes, ou depuis un hĂŽte Haiku,
  • Compilation d’outils pour la machine hĂŽte de la compilation croisĂ©e, avec si nĂ©cessaire une couche de compatibilitĂ© permettant d’écrire ces outils en utilisant des API et fonctionnalitĂ©s spĂ©cifiques Ă  Haiku,
  • PossibilitĂ© de compiler des applications pour un systĂšme hĂŽte existant (une autre version de Haiku) Ă  des fins de test,
  • Compilation d’un systĂšme complet (noyau, bibliothĂšques, applications, image disque) en une seule opĂ©ration.

Pour ces raisons, l’utilisation d’un systĂšme de build haut niveau (CMake, Meson
) s’avĂšre plutĂŽt complexe. L’utilisation de make ou de ninja directement serait de trop bas niveau. Le choix de Haiku est donc d’utiliser l’outil jam, qui est malheureusement assez peu populaire et tombĂ© Ă  l’abandon dans sa version originale. Haiku maintient un fork de jam qui est concurrent de ceux maintenus par Boost et par Freetype.

Reformatage des fichiers Jamfile pour lister une seule cible par ligne au lieu de les rassembler, cela facilite les rebase et résolutions de conflits (x512).

Mise à jour de paquets en préparation pour la version beta 5: OpenSSL 3, Python 3.10, et autres mises à jour diverses (PulkoMandy, waddlesplash, kallisti5).

Ajout de l’inclusion de <features.h> dans <sched.h>. Le fichier d’en-tĂȘte features.h configure la visibilitĂ© des extensions GNU et BSD aux fichiers d’include standards C et POSIX, en fonction d’options de ligne de commande du compilateur. L’inclusion de ce fichier permet d’utiliser facilement et par dĂ©faut ces extensions (PulkoMandy).

Mise à jour des marque-pages fournis par défaut avec le navigateur WebPositive (waddlesplash).

Ajout des en-tĂȘtes de la bibliothĂšque linprog dans le paquet haiku_devel. Ces en-tĂȘtes sont nĂ©cessaires pour les applications associĂ©es au systĂšme de layout d’interfaces graphiques ALM (korli).

Correction de fautes de frappe dans des commentaires (jmairboeck) et d’un problĂšme de compatibilitĂ© C89 dans un en-tĂȘte systĂšme (waddlesplash).

La taille des images « nightly build » de Haiku est maintenant de 650 Mo, ce qui laisse un peu plus de place disponible pour les utiliser et crĂ©er quelques fichiers (jscipione).

Diverses corrections pour une nouvelle fois essayer de faire fonctionner la compilation de Haiku avec Clang (waddlesplash, oanderso). Les choses en sont toujours au mĂȘme point depuis plusieurs annĂ©es, avec des corrections de temps en temps mais quelques parties du systĂšme qui ne fonctionnent toujours pas correctement.

La compilation du profil « nightly » n’a plus besoin de gĂ©nĂ©rer le paquet haiku_source contenant le code source de Haiku. Ce paquet est inclus uniquement dans les images de releases (pour faciliter le respect strict de la licence GPL de certains composants de Haiku), mais, pour des raisons de dĂ©pendances entre cibles dans le systĂšme de build, il Ă©tait tout de mĂȘme gĂ©nĂ©rĂ© pour les autres profils, ralentissant la compilation (waddlesplash).

Améliorations du script ./configure (jessicah, OscarL et waddlesplash):

  • Le script vĂ©rifie que les options passĂ©es fournies sont valides, et rejette immĂ©diatement les configurations incohĂ©rentes plutĂŽt que de laisser la compilation Ă©chouer bien plus loin.
  • Validation que l’interprĂ©teur Python sĂ©lectionnĂ© existe bien, et uniformisation de la syntaxe utilisĂ©e pour choisir un interprĂ©teur avec la façon dont c’est fait pour d’autres outils.
  • DĂ©tection des options disponibles pour demander Ă  wget de rĂ©-essayer un tĂ©lĂ©chargement en cas d’échec, ce qui permet d’assurer la compatibilitĂ© avec wget2.
  • Utilisation automatique d’une version moderne de GCC pour compiler les outils « hĂŽtes » lors de la compilation Ă  partir d’une machine hĂŽte fonctionnant sous Haiku en version 32 bit, en ignorant le compilateur par dĂ©faut qui est gcc 2 pour des raisons de compatibilitĂ© avec BeOS.

RĂ©organisation du code source de libroot pour dĂ©placer les implĂ©mentations de malloc dans des sous-dossiers sĂ©parĂ©s, et faciliter l’expĂ©rimentation avec d’autres implĂ©mentations de malloc. L’allocateur hoard2 utilisĂ© actuellement n’est pas adaptĂ© aux architectures 64 bits, une tentative a Ă©tĂ© faite il y a quelques annĂ©es avec rpmalloc, mais ce dernier pose des problĂšmes sur les
architectures 32 bits. Des investigations sont en cours avec l’implĂ©mentation de malloc d’OpenBSD.

L’outil de dessin Wonderbrush est maintenant disponible sur toutes les architectures. Historiquement, le code de Wonderbrush n’était pas libre, mais une version gratuite Ă©tait offerte aux utilisateurs de Haiku. Le dĂ©veloppeur principal de Wonderbrush n’est plus trĂšs actif sur le projet et a dĂ©cidĂ© de publier les sources, ce qui a permis de recompiler le programme en version 64 bits et plus tard sur les autres architectures non x86. Mais ces nouvelles versions n’avaient jamais Ă©tĂ© incluses dans Haiku (PulkoMandy).

Nettoyage et centralisation des dĂ©finitions prĂ©processeur pour la compatibilitĂ© avec BeOS. DĂ©sactivation de la compatibilitĂ© avec BeOS dans le noyau, la compatibilitĂ© avec les pilotes et modules noyau de BeOS n’étant plus assurĂ©e depuis quelque temps dans Haiku.

Suppression de définitions de rÚgles obsolÚtes et inutilisées dans le Jamfile permettant de construire le fichier package_repo (CodeforEvolution).

Remise en service du test DiskDeviceManagerTest qui ne compilait plus (waddlesplash).

ARM & PowerPC

Actuellement, Haiku est disponible officiellement pour les architectures x86 32 et 64 bits. Une version RISC-V 64 bits expĂ©rimentale est Ă©galement disponible mais pas encore totalement intĂ©grĂ©e dans le dĂ©pĂŽt de code principal, des discussions sont en cours sur la bonne façon de faire certains changements nĂ©cessaires. Les versions ARM (32 et 64 bits) et PowerPC sont les prochaines cibles sur la liste. La premiĂšre, car c’est une architecture trĂšs populaire, la deuxiĂšme plutĂŽt pour des raisons historiques : c’est l’une des architectures sur lesquelles fonctionne BeOS.

Renommage de structures qui Ă©taient initialement spĂ©cifiques Ă  l’architecture x86, mais qui sont finalement utilisĂ©es Ă©galement sur d’autres CPU sans nĂ©cessiter de changements (waddlesplash).

RĂ©paration de la console de texte du chargeur de dĂ©marrage OpenFirmware qui Ă©tait cassĂ©e depuis l’adaptation pour OpenBOOT sur les machines SPARC (zeldakatze).

Sur ARM, utilisation de la bonne instruction CPU pour mettre le processeur en veille quand il n’y a rien à faire (archeYR).

oanderso continue le travail sur le portage ARM64:

  • Correction de plusieurs problĂšmes liĂ©s Ă  la gestion du cache et de la MMU dans le bootloader, ce qui permet de dĂ©marrer le noyau dans une machine virtuelle sur un hĂŽte Apple M1.
  • Correction de l’implĂ©mentation des timers dans le kernel qui ne fonctionnait pas dans les environnements virtualisĂ©s.
  • Quelques avancĂ©es sur la gestion de la MMU : ImplĂ©mentation de la table de translation de la mĂ©moire virtuelle, du traitement des exceptions matĂ©rielles (dĂ©fauts de page), des TLBs.
  • Synchronisation du cache d’instructions.
  • Correction de problĂšmes de double lock.

Ajout de messages sur le port sĂ©rie traçant l’exĂ©cution de mĂ©thodes spĂ©cifiques Ă  une architecture qui ne sont pas encore implĂ©mentĂ©es. Ceci permet de dĂ©tecter facilement quelle est la prochaine fonction Ă  implĂ©menter (waddlesplash).

Nettoyage et documentation du fichier ArchitectureRules pour simplifier la configuration des options en ligne de commande du compilateur (qui doit savoir traiter deux versions de gcc et clang) (waddlesplash).

Commentaires : voir le flux Atom ouvrir dans le navigateur

Deno 2.0 est lĂ 

Le temps oĂč Node.js rĂ©gnait en maĂźtre comme la solution incontournable pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur est-il rĂ©volu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mĂ©riter une dĂ©pĂȘche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dĂ©pĂȘche, Ă  l'occasion de la sortie de sa version 2.0

Sommaire

Titre de l'image

Pour rappel

Deno est un runtime JavaScript et TypeScript. Il a vu le jour suite au constat de Ryan Dahl (crĂ©ateur aussi de Node.js), que Node avait des problĂšmes de conceptions, et qu'il Ă©tait nĂ©cessaire de repartir de zĂ©ro en tenant compte de l'expĂ©rience de Node pour ne pas refaire les mĂȘmes erreurs. Il imagine Deno comme un runtime avec un modĂšle de sĂ©curitĂ© par dĂ©faut plus strict. Les programmes Deno n'ont pas accĂšs au systĂšme de fichiers, au rĂ©seau ou Ă  l'environnement, sauf si on leur accorde explicitement ces permissions. Deno est Ă©crit en Rust, et se base sur le moteur JavaScript V8 de Google. Deno se distingue Ă©galement de Node en offrant la possibilitĂ© d'importer les dĂ©pendances via des URL, mettant en cache chaque module lors de l’importation pour amĂ©liorer la vitesse d’exĂ©cution.

La mascotte !

La premiĂšre chose notable quand on passe de Node.js Ă  Deno, c'est sa mascotte ! En effet, mĂȘme si Node.js possĂšde bien une petite tortue comme mascotte, celle-ci n'est utilisĂ©e nulle part ! Personnellement, j'ai toujours trouvĂ© bien plus chouettes les projets qui ont des petites bestioles comme mascotte (Mozilla, Tux 
). Et chez Deno, le dinosaure mascotte est omniprĂ©sent sur tout le site. Et en plus, Ă  l'occasion de la version 2.0, on peut habiller notre dino sur la home page du projet ! Et ça c'est cool ! Voici le mien, qui est en compagnie de Ferris, la mascotte officieuse de Rust !

Mon dino

Bon, comme je ne suis pas sĂ»r que tout le monde partage ma passion pour les mascottes, on va passer au cĂŽtĂ© plus technique ! đŸ€Ł

Deno 1.x, des dĂ©buts difficiles !

La version 1.0 sortie en mai 2020 a du mal Ă  se faire une place et reste dans l'ombre de son grand frĂšre. En effet, mĂȘme si Deno offre un grand lot de nouveautĂ©s et est plus sĂ©curisĂ© par dĂ©faut, la trĂšs large adoption de Node et le fait que les projets dĂ©veloppĂ©s pour Node ne sont pas forcĂ©ment compatibles avec Deno rend l’adoption de ce dernier difficile. De plus, l'utilisation de CDN plutĂŽt que d'installer les dĂ©pendances localement (dans le rĂ©pertoire node_modules) a certes de nombreux avantages, mais cela rend votre projet dĂ©pendant de disponibilitĂ© du rĂ©seau ou peut entraĂźner des problĂšmes de performances si le CDN est Ă©loignĂ© gĂ©ographiquement.

Les nouveautés de la version 2.0

Deno est désormais 100% compatible avec Node.js, et un gestionnaire de paquets officiel a vu le jour. Vous pouvez maintenant utiliser deno add et deno removepour ajouter ou retirer un paquet à votre projet.

Autour du projet Deno, JavaScript Registry (JSR) un dĂ©pĂŽt de paquets JavaScript universel !

Le registre NPM s'est construit autour de Node.js afin de gĂ©rer facilement les dĂ©pendances de nos projets. Il a donc Ă©tĂ© dĂ©veloppĂ© pour Node.js Ă  une Ă©poque oĂč Node Ă©tait la seule solution pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur. En prĂšs de 15 ans, le registre NPM a rassemblĂ© un peu moins de 3 millions de paquets et a trĂšs largement rempli sa mission toutes ces annĂ©es. Mais aujourd'hui, la situation a changĂ©, il existe plusieurs runtimes pouvant exĂ©cuter du code JavaScript (ou TypeScript) cĂŽtĂ© serveur. Et du cĂŽtĂ© front-end, les frameworks se sont multipliĂ©s et sont devenus de plus en plus complexes et nĂ©cessitent aussi l'utilisation d'un gestionnaire de paquets. Un registre de paquets fondĂ© autour de Node.js uniquement est donc beaucoup moins pertinent qu'en 2010.
C'est donc pourquoi, Ă  l'initiative du projet Deno, un nouveau registre de paquets JavaScript et TypeScript universel pointe aujourd'hui le bout de son nez. Il s'agit donc de JSR (JavaScript Registry).

Dans JSR, quand on va sur la page d'un paquet, en haut Ă  droite, on a les logos des environnements compatibles avec le paquet :

Titre de l'image

Performances du runtime

Niveau performance, ça donne quoi ?

On voit souvent l'affirmation que Deno serait plus rapide que Node.js. Mais ça donne quoi en rĂ©alitĂ© ?

J'ai voulu faire un petit test sans prĂ©tentions pour voir ce que ça donne. Je voulais faire des tests plus poussĂ©s sur diffĂ©rents systĂšmes d'exploitation et architectures, mais par manque de temps, le test sera donc fait sur un seul systĂšme et un seul ordinateur et il s'agit d'un Mac
 Un comble pour LinuxFr.org, mais c'est l'ordinateur que j'avais Ă  disposition Ă  ce moment-lĂ . Mais sinon, je ne porte pas spĂ©cialement Apple dans mon cƓur, bien au contraire !

J'ai testĂ© l’exĂ©cution d'une mĂȘme API sur Node. et Deno pour voir les diffĂ©rences de performance entre ces solutions. Pour ce test, j'ai utilisĂ© une API Rest que j'ai dĂ©veloppĂ©e pour le site de la sociĂ©tĂ© AudioSoft. J'ai fait la mĂȘme requĂȘte POST 10 fois sur la mĂȘme route avec les mĂȘmes donnĂ©es. Il est important de prĂ©ciser que c'est la premiĂšre fois que je fais ce genre de tests, et que je ne fais peut-ĂȘtre pas tout dans les rĂšgles de l'art. Il y a des Ă©lĂ©ments extĂ©rieurs Ă  Node et Deno qui peuvent influencer les scores. Notamment, la base de donnĂ©es utilisĂ©e pour le test Ă©tait accessible via Internet, et des diffĂ©rences de dĂ©bit ont pu fausser les tests.

Test sur un MacBook Pro (2,6 GHz Intel Core i7 6 cƓurs, AMD Radeon Pro 5300M 4 Go Intel UHD Graphics 630 1536 Mo, 16 Go 2667 MHz DDR4) sous macOS Sonoma

Node: Le temps moyen pour exécuter le test de 126 millisecondes
Deno: Le temps moyen pour exécuter le test de 93 millisecondes

Performances du gestionnaire de paquets

Comme dit précédemment, Deno c'est aussi un gestionnaire de paquets. J'ai donc trouvé intéressant de tester les principaux gestionnaires de paquets sur différents environnements.
Pour ce test je me base sur la mĂȘme API Rest que pour le test prĂ©cĂ©dant, les dĂ©pendances Ă  installer pour cette API sont : bcrypt, body-parser, dotenv, express, jsonwebtoken, mariadb, multer, mysql2, nodemailer, et sequelize. Le test a Ă©tĂ© fait sur un MacBook Pro. Pour effectuer ce test, le cache des gestionnaires de paquets ont Ă©tĂ© nettoyĂ©s et les fichiers-verrous supprimĂ©s.

Avec NPM, l'installation a mis 10 secondes.

Avec Deno, l'installation a mis 1 seconde.

Avec Bun, l'installation a mis 3 secondes.

On voit trĂšs clairement que NPM est beaucoup plus lent que ses deux concurrents. L'Ă©cart est plus faible entre Deno et Bun. Mais Deno est bien le plus rapide des trois.

Avant de rĂ©aliser ce test, j'en ai effectuĂ© un en oubliant de nettoyer le cache et de supprimer package-lock.json. Les rĂ©sultats Ă©taient alors 8 secondes pour NPM, 5 secondes pour Deno et 4 secondes pour Bun. Il est logique de constater que NPM est plus rapide, en revanche, je trouve surprenant que Deno et Bun aient Ă©tĂ© ralentis. Il est possible que les gestionnaires de paquets aient parcouru package-lock.json pour garder les versions prĂ©sentes dans ce fichier, ce qui les aurait tous les trois ralentis. Et NPM a peut-ĂȘtre pu bĂ©nĂ©ficier de son cache (car je l'utilise bien plus que les deux autres sur mon ordinateur), Deno et Bun eux n'avaient peut-ĂȘtre pas grand-chose dans leurs caches, ont donc Ă©tĂ© ralentis. Il est donc important de supprimer les lockfile en cas de migration d'un projet.

Comme je le disais plus haut, c'est la premiĂšre fois que j'effectue ce genre de test comparatif. Si vous avez des conseils sur les bonnes mĂ©thodes pour faire des tests plus fiables, ça m’intĂ©resse !

Deno 2.1 est lĂ 

Étant donnĂ© que j'ai mis environ un siĂšcle pour rĂ©diger cette dĂ©pĂȘche, Deno 2.1 est sortie entre temps ! đŸ€Ł
Je vous liste donc les principales nouveautĂ©s apportĂ©es Ă  la version 2.1 sans les commenter 😉

  • Support natif de WebAssembly (Wasm) : Il est dĂ©sormais possible d'importer directement des modules Wasm, simplifiant leur utilisation et amĂ©liorant les performances.
  • Version Long Term Support (LTS) : Deno 2.1 inaugure la premiĂšre version LTS, garantissant des correctifs de bugs et des amĂ©liorations de performance pendant
 Six mois
 On n'est pas encore aux 30 mois des versions LTS de Node.js
 Cela viendra peut-ĂȘtre plus tard. 🙂
  • Commande deno init --npm vite : Cette commande simplifie la crĂ©ation de nouveaux projets en utilisant des outils comme Vite, en automatisant l'initialisation et en rĂ©duisant la configuration manuelle.
  • Gestion des dĂ©pendances : Introduction de la commande deno outdated pour gĂ©rer les mises Ă  jour des dĂ©pendances JSR et npm.

Conclusion

Si vous ĂȘtes dĂ©veloppeur Node.js, je vous conseille de vous intĂ©resser Ă  Deno, et mĂȘme Ă  Bun. Je ne sais pas si ces deux runtime sont totalement prĂȘts pour des projets en production (par exemple, Deno 2.1 n'a que 6 mois de durĂ©e de vie, ce qui est plutĂŽt contraignant pour les serveurs.). Mais peut-ĂȘtre que dans un futur proche, il sera cohĂ©rent de migrer vers l'un de ces deux-lĂ .

Commentaires : voir le flux Atom ouvrir dans le navigateur

FreeCAD 1.0

FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problÚme de dénomination topologique.

Nouveau logo FreeCAD

Sommaire

La derniĂšre dĂ©pĂȘche sur FreeCAD remonte Ă  avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (aoĂ»t 2023). Cette version 1.0 a portĂ© le nom de 0.22 pendant son dĂ©veloppement.

Qu'est-ce que FreeCAD ?

Exemple 1 utilisation

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramĂ©trique de CAO 3D open source sous licence LGPL. FreeCAD est destinĂ© Ă  l'ingĂ©nierie mĂ©canique et Ă  la conception de produits mais — Ă©tant trĂšs gĂ©nĂ©rique — il s'adapte Ă©galement Ă  une gamme plus large d'utilisations autour de l'ingĂ©nierie, telles que l'architecture, l'analyse par Ă©lĂ©ments finis, l'impression 3D et d'autres tĂąches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le systÚme de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la mĂȘme apparence et les mĂȘmes fonctionnalitĂ©s sous toutes les plateformes.

Historique

La toute premiĂšre version de FreeCAD est sortie en 2002. FreeCAD est dĂ©veloppĂ© en C++, Qt et Python et son cƓur repose sur les bibliothĂšques OpenCASCADE (ou OCCT) spĂ©cialisĂ©es dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaßnées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complÚte, à jour et traduite dans de nombreuses langues.

Le problÚme de dénomination topologique

C'Ă©tait un des points noirs de FreeCAD jusqu'Ă  cette version 1.0.
Il faut imaginer que dans ce logiciel, la modĂ©lisation d'une piĂšce (dans le sens objet physique) passe par une suite d'opĂ©rations mathĂ©matiques et gĂ©omĂ©triques en dĂ©finissant Ă  chaque fois des contraintes ou des paramĂštres. Une opĂ©ration est par exemple la crĂ©ation d'un trou borgne de 5 mm sur telle face Ă  10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arĂȘte, etc.

Ainsi, petit à petit, la piÚce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opĂ©rations successives est toujours prĂ©sent et modifiable. À tout moment, il est possible de modifier une des Ă©tapes intermĂ©diaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opĂ©ration s'applique Ă  un Ă©lĂ©ment prĂ©cis et existant de la piĂšce Ă  ce moment-lĂ  (une face ou une arĂȘte par exemple). Dans FreeCAD ces Ă©lĂ©ments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrĂ©mental. Si l'objet a 13 faces Ă  une des Ă©tapes, les faces seront numĂ©rotĂ©es de Face1 Ă  Face13. Chaque opĂ©ration est rattachĂ©e Ă  l'identifiant de l'Ă©lĂ©ment (Face5 par exemple).

Et le problĂšme se situe Ă  ce niveau : lors d'une modification d'une Ă©tape intermĂ©diaire, il arrive souvent que cela change la gĂ©omĂ©trie globale de la piĂšce et donc que les nombres de faces ou d'arĂȘtes augmentent ou diminuent. Et FreeCAD rĂ©attribue alors ces identifiants uniques aux diffĂ©rents Ă©lĂ©ments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un trÚs fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problĂšme arriver : si une des opĂ©rations suivantes dans l'historique Ă©tait de faire un perçage sur la Face6 qui est maintenant devenue la Face3
 Toute la modĂ©lisation part en vrille.

Ce problÚme de dénomination topologique est documenté sur le wiki de FreeCAD : problÚme de dénomination topologique.

Pour Ă©viter cela, il Ă©tait conseillĂ© de suivre un ensemble de bonnes pratiques de modĂ©lisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'Ă©volution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intĂ©gration de codes correctifs de cette problĂ©matique. Les notes de version indiquent tout de mĂȘme que tout n'est pas rĂ©solu, et qu'il y aura d'autres amĂ©liorations dans les prochaines versions. Cette petite vidĂ©o en anglais vous montre la diffĂ©rence de comportement entre la version 0.21 et 0.22dev (qui a servi de base Ă  la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage dĂ©signe la fonctionnalitĂ© de regrouper plusieurs Ă©lĂ©ments afin d'obtenir un objet fonctionnel. Ce peut ĂȘtre, par exemple, une boĂźte constituĂ©e d'un couvercle sur charniĂšres maintenues par des vis avec des rangements amovibles Ă  l'intĂ©rieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de libertĂ© des Ă©lĂ©ments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grùce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tÎt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisĂ©es dans la conception mĂ©canique. C'est dans celui-ci que sont dessinĂ©s les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre consĂ©quent d'amĂ©liorations et de nouvelles fonctionnalitĂ©s rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animĂ©es.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinĂ©s aux Ă©quipes de MaĂźtrise d'ƒuvre impliquĂ©es dans la conception d'une opĂ©ration construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcĂ©ment le lot commun des visiteurs de LinuxFr.org, rĂ©sumons la situation:

  • L'atelier Arch, pour Architecture, exploite depuis longtemps les capacitĂ©s de crĂ©ation 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenĂȘtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

  • Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien Ă©crit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de crĂ©ation d'objets qui s'avĂšrent redondants pour certains avec ceux de l'outil Arch tout en implĂ©mentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la gĂ©omĂ©trie, mais aussi du prix, des donnĂ©es mĂ©caniques, physiques, des fiches produit, du planning 


  • L'approche BIM tend Ă  se gĂ©nĂ©raliser dĂšs lors que la complexitĂ© et le coĂ»t du projet le justifient. Elle repose (en thĂ©orie) sur un format d'Ă©change IFC (pour Industry Foundation Class).
    Il est ouvert et au format texte.
    Oui avec vim, c'est possible de bidouiller ;)
    mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go 


L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Titre de l'image
Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grùce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme trÚs souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi aprÚs un appel à concourir auprÚs de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la crĂ©ation en 2021 de l'association FPA (voir plus haut), d'autres dĂ©veloppeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont crĂ©Ă© dĂ©but 2023 la sociĂ©tĂ© amĂ©ricaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intĂ©rĂȘt pour la sociĂ©té ». Malheureusement, aprĂšs environ 2 ans, Brad Collette informe de l'arrĂȘt de la sociĂ©tĂ© ONDSEL, faute d'avoir trouvĂ© un marchĂ©.

La sociĂ©tĂ© voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalitĂ©s commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses amĂ©liorations Ă  FreeCAD pour intĂ©gration et que son cloud Ă©tait disponible sous forme de module dans FreeCAD. Ces amĂ©liorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intĂ©grĂ© d'assemblage ainsi que les trĂšs nombreuses nouvelles fonctionnalitĂ©s de l'atelier Sketcher.

La sociĂ©tĂ© ONDSEL avait dĂ©taillĂ© sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient Ă©galement un blog en anglais intĂ©ressant, oĂč ils abordent plusieurs thĂ©matiques, notamment sur l'Ă©volution de CATIA ou bien la liste des nouveautĂ©s agrĂ©mentĂ©e de nombreuses animations.

Dans l'annonce de cet arrĂȘt, Brad Collette revient Ă©galement sur ce qu'ils ont apportĂ© au projet FreeCAD. Tout ce qu'ils ont dĂ©veloppĂ© Ă©tait en open source et dĂ©jĂ  intĂ©grĂ© pour la plupart Ă  FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Les langues peu documentées et le libre : quelques enjeux scientifiques

Comme beaucoup de domaines scientifiques, la documentation de la diversitĂ© linguistique entretient une relation forte avec les mondes du Libre. Dans cette dĂ©pĂȘche, je vous propose de dĂ©couvrir ce domaine Ă  travers la prĂ©sentation de plusieurs logiciels et ressources libres ou en accĂšs ouvert. La documentation des langues Ă©tant un thĂšme peu courant sur LinuxFr.org, on commencera par une prĂ©sentation de cette problĂ©matique. Nous continuerons par une description des deux ressources principales existantes pour cataloguer et se repĂ©rer au sein de cette diversitĂ© linguistique. Je parlerai ensuite d’ELAN et de FLEX, deux logiciels utilisĂ©s pour annoter des enregistrements audio-visuels, une Ă©tape clef dans l’analyse linguistique, et qui permet le partage et la rĂ©utilisation de ces enregistrements. Enfin, aprĂšs un court passage sur la question de l’archivage, je prĂ©senterai deux compilations de corpus de documentation en accĂšs libre, une pratique rĂ©cente qui permet de nouveaux questionnements quantitatifs sur les langues orales peu documentĂ©es, et qui contribue Ă©galement Ă  la transparence et la traçabilitĂ© des analyses linguistiques.

    Sommaire

    L’étude des langues Ă  travers le monde

    Actuellement, environ 7000 langues ont Ă©tĂ© recensĂ©es Ă  travers le monde. Ce chiffre ne peut ĂȘtre qu’une approximation car, il n’y a pas de consensus sur la dĂ©finition de ce qu’est une langue. Une difficultĂ© par exemple est de dĂ©finir Ă  quel moment une langue est distincte d’une autre. Lorsqu’il y a variation, mais intercomprĂ©hension, de nombreux linguistes s’accordent Ă  dire qu’il s’agit alors de dialectes d’une mĂȘme langue, et donc, lorsqu’il n’y a pas intercomprĂ©hension, alors il s’agit diffĂ©rentes langues. Cette perspective considĂšre que tout le monde parle un dialecte (que ce soit celui de rĂ©fĂ©rence, ou un plus rĂ©gional comme celui de Paris, de Marseille, du QuĂ©bec), la langue n’étant qu’une abstraction permettant de regrouper les diverses pratiques langagiĂšres. En ce qui concerne l’intercomprĂ©hension, ce critĂšre n’est malheureusement pas absolu car elle peut varier selon les personnes et leur parcours personnel. Et lorsqu’on considĂšre l’évolution d’une langue Ă  travers le temps, sa diachronie, dĂ©finir ce qu’est une mĂȘme langue Ă  travers ses Ă©volutions temporelles se complexifie d’autant plus.

    Si certaines langues ont Ă©mergĂ© rĂ©cemment, on pense assez souvent aux langues dites crĂ©oles (le Bichelamar, les crĂ©oles malais, Ă  Madagascar ou au Cap Vert), ou Ă©galement lorsque certains dialectes se distinguent suffisamment pour ne plus ĂȘtre intercomprĂ©hensibles, la tendance actuelle est surtout Ă  la disparition massive des langues. Cette disparition est souvent rapportĂ©e Ă  travers la mort des derniers locuteurs et locutrices, on peut aussi considĂ©rer qu’une langue meurt lorsqu’elle n’est plus parlĂ©e d’une part, et qu’elle disparait si elle n’est pas documentĂ©e. Si certains aujourd’hui se questionnent sur la corrĂ©lation entre la diversitĂ© culturelle et la diversitĂ© Ă©cologique, il est Ă©vident que la disparition des langues correspond Ă©galement Ă  des inĂ©galitĂ©s et des tensions socio-politiques.

    Bref, la documentation des langues, c’est un sujet actuel, et d’un point de vue scientifique, la perte de cette diversitĂ© aura de tristes consĂ©quences sur la connaissance des langues et de l’univers des possibles languagiers, encore souvent sous-estimĂ© :

    • l’article The myth of language universals : Language diversity and its importance for cognitive science d’Evans donne un bel aperçu du dĂ©bat qui existe entre les linguistes fonctionnalistes, notamment les approches gĂ©nĂ©rativistes telles que proposĂ©es par Noam Chomsky. Pourtant, rĂ©guliĂšrement Ă  travers la documentation des langues, des catĂ©gories cognitives jusque-lĂ  non-soupçonnĂ©s, voire rejetĂ©es car non-observĂ©es, sont identifiĂ©s. Nous nous sommes rendu compte rĂ©cemment qu’un quart des langues grammaticalisaient l’emploi d’évidentiels, ces morphĂšmes qui indiquent la source d’une information. Au niveau de l’odorat, des neurologistes pensaient que si nous n’avions pas de termes abstraits pour catĂ©goriser les odeurs, c’était liĂ© au fait que notre cerveau ne le permettait pas. La description des termes liĂ©s Ă  l’odorat en Jahai (par ici si vous souhaitez Ă©couter du Jahai), qui possĂšde donc des termes spĂ©cifiques pour catĂ©goriser les odeurs, a montrĂ© le contraire.
    • accĂ©der Ă  des facettes non-matĂ©rielles de la prĂ©histoire, non-accessibles Ă  travers l’archĂ©ologie. La documentation des langues nous permet d’accĂ©der, dans une certaine mesure, aux termes et aux concepts utilisĂ©s durant les diffĂ©rentes prĂ©histoires Ă  travers la comparaison des langues et de leurs structures. Les travaux sont nombreux et anciens en ce qui concerne les langues europĂ©ennes, mais les recherches en linguistique historique (ou comparĂ©e) portent Ă©galement sur toutes les langues connues Ă  travers le monde. Les chercheurs et chercheuses de ce domaine collaborent assez rĂ©guliĂšrement avec les archĂ©ologues pour retracer les mouvements de population.
    • mettre au point des systĂšmes d’écriture pour les langues orales, ou simplement des traitements de texte adaptĂ© aux Ă©critures existantes. Parfois, certaines personnes savent Ă©crire dans la ou les langues officielles du pays, mais ne connaissent pas d’écriture pour une de leurs langues rĂ©gionales. C’est ainsi souvent le cas pour les personnes au Vanuatu. Le pays reconnait mĂȘme le droit d’enseigner les langues locales Ă  l’école, mais il n’existe que trĂšs rarement des ressources (que ce soit les personnes ou les manuels) pour cela. Parfois, les gens ne connaissent tout simplement pas de systĂšme d’écriture.

    Quelques concepts et termes liés à la documentation des langues

    Comme tout domaine de recherche, la terminologie et les concepts linguistiques Ă©voluent au grĂ© des discussions et peut se distinguer de l’usage attendu des termes. Une Ă©tape importante dans la documentation d’une langue est la production d’une grammaire dĂ©crivant les structures linguistiques de cette langue. De nombreux linguistes estiment alors qu’on peut dire que cette langue est dĂ©crite. Il ne faut pas se tromper cependant, aucun linguiste ne considĂšre qu’une langue est alors complĂštement dĂ©crite. Une grammaire ne contient que quelques aspects estimĂ©s actuellement essentielles par les linguistes de terrain. Ces points sont, le plus souvent, une description du systĂšme phonologique d’une langue (c’est-Ă -dire comment les sons d’une langue sont organisĂ©s les uns vis-Ă -vis des autres), des morphĂšmes et des processus morphologiques associĂ©s (la conjugaison, l’expression de la possession, les dĂ©clinaisons, les genres, les classifications, etc.) d’une langue et souvent un dĂ©but de description des processus syntaxiques. Il existe de nombreuses approches pour dĂ©crire les faits linguistiques, et la description d’une langue se fait souvent en dialogue avec les pratiques et terminologies qui ont Ă©tĂ© employĂ©es dans l'aire linguistique concernĂ©e.

    Depuis l’article Documentary and descriptive linguistics de Nicholaus Himmelman, qui a promu la distinction entre la documentation linguistique et la description linguistique, on accorde beaucoup plus d’importance Ă  la production d’un corpus d’enregistrements annotĂ©s. On dit alors d’une langue qu’elle est documentĂ©e si des enregistrements annotĂ©s, de prĂ©fĂ©rences audio-visuels, de cette langue existe. Enfin, il existe la problĂ©matique de l’outillage d’une langue, c’est-Ă -dire si ses locuteurs et locutrices ont accĂšs ou non aux outils informatisĂ©s, du traitement texte aux dictionnaires informatisĂ©s en passant par la reconnaissance vocale, la transcription automatique, voire aujourd’hui aux modĂšles de langues et autres ressources nĂ©cessitant des corpus beaucoup plus grands.

    Les catalogues et base de donnĂ©es pour l’identification des langues

    Une problĂ©matique rĂ©currente dans le domaine des langues est de clairement identifier la langue sur laquelle on travaille. Cependant, identifier une langue, ce qui relĂšve ou non de cette langue, oĂč elle est parlĂ©e, est l’enjeu de nombreux dĂ©bats, souvent politique, et n’est pas une tĂąche simple. Quoi qu’il en soit, il existe des ressources, bases de donnĂ©es, qui proposent d’associer Ă  des noms de langues, endonymes ou exonymes, des codes pour rendre leur identification univoque.

    L’Ethnologue et l’ISO 639 : une norme gĂ©rĂ©e par le Summer Institute of Linguistics (SIL)

    Ethnologue, Languages of the World, ou plus simplement l’Ethnologue, est une base de donnĂ©es dĂ©veloppĂ©e et maintenu par l’organisme Ă©vangĂ©lique SIL, Summer Institute of Linguistic depuis 1951. Elle vise Ă  recenser toutes les langues du monde. L’ISO 639 est une norme issue de ce catalogue, Ă©galement maintenue par le SIL. Cet organisme est trĂšs actif au niveau de la documentation des langues et de la crĂ©ation d’écritures, car un de ses objectifs est de traduire la Bible dans toutes les langues du monde. Historiquement, l’Ethnologue est un des premiers catalogues dont l’objet a Ă©tĂ© de recenser les langues. Si cette norme semble le plus souvent suffisamment exhaustive pour les besoins liĂ©s Ă  l’informatique, aprĂšs tout, les internautes consultent Internet en trĂšs peu de langue, d’un point de vue linguistique, il possĂšde de nombreuses lacunes.

    La liste SIL des langues

    Un premier souci est la nĂ©cessitĂ© d’avoir une granularitĂ© plus importante que simplement la langue. Les linguistes travaillent sur des dialectes et des variĂ©tĂ©s, sur des familles de langues, et parfois ont travaillĂ© sur des distinctions qui n’ont parfois plus cours. Afin de pouvoir associer ces ressources Ă  des langues, ou des entitĂ©s linguistiques particuliĂšres, l’approche du SIL ne suffit pas.

    Enfin, la gestion du catalogue par un organisme religieux, donc avec parfois d’autres enjeux qu’uniquement scientifiques, le fait qu’il s’agisse d’une norme, donc la nĂ©cessitĂ© de collaborer avec l’ISO, et le fait que seule une partie du catalogue est accessible (il faut un abonnement pour accĂ©der Ă  la totalitĂ© de la ressource) rend la ressource moins pertinente pour de nombreux linguistes. Ces limites ont poussĂ© des linguistes Ă  proposer une ressource alternative.

    Glottocode : par le Max Planck Institute for Evolutionary Anthropology.

    Le projet Glottolog, initialement dĂ©veloppĂ© par Sebastian Nordhoff et Harald Hammarström, catalogue non seulement les langues du monde actuelles et passĂ©s, les familles de langues et leurs diffĂ©rentes branches, mais Ă©galement « les restes Â» des hypothĂšses de langues ou de regroupements historiques. Cette granularitĂ© permet de retrouver les documents associĂ©s Ă  chacun de ces objets. Si le catalogue est dĂ©diĂ© aux langues moins connues, les langues les plus centrales sont elles aussi rĂ©pertoriĂ©es. Il s’agit actuellement du catalogue mis en avant par les linguistes documentant les langues Ă  travers le monde. L’application Glottolog est disponible via la licence MIT.

    Aperçu du Glottolog à travers la liste des langues

    Si aux premiers abords, la liste des langues du Glottolog ne se distingue pas franchement de celle de l’ISO 639, c’est parce qu’il faut regarder plus en dĂ©tail pour comprendre les diffĂ©rences essentielles entre les deux ressources. Notons tout de mĂȘme la colonne « Child dialects » : « Dialectes enfants », et les champs vides au niveau des colonnes Top-level-family et pour la langue Abai Tubu-Abai Sembuak dans la colonne « ISO-639-3 Â». La colonne « Child dialects » reprĂ©sente une information qui n’est pas documentĂ© dans l’ISO 639, ce n’est pas son objet aprĂšs tout, mais qui est intĂ©ressant pour les linguistes travaillant sur cette langue, indiquant qu’un minimum de donnĂ©es sociolinguistiques sont disponibles. Les champs vides dans la colonne « Top-level family » sont dus au fait que ces langues sont des isolats, c’est-Ă -dire que la linguistique comparĂ©e ne trouve pas de correspondances significatives entre cette langue et d’autres langues qui permettraient de les regrouper en une famille. Enfin, le vide dans la colonne ISO-963-3 rĂ©vĂšle que la langue Abai Tubu-Abai Sembuak ne possĂšde pas d’entrĂ©e dĂ©diĂ©e dans la norme.

    Ainsi, lorsque l’on consulte une langue en particuliĂšre, ici le Nisvai, on voit apparaitre tous les embranchements existants associĂ©s Ă  cette langue :

    La langue Nisvai dans le Glottolog

    Cette vue de l’arborescence associĂ©e Ă  une langue particuliĂšre rĂ©vĂšle tous les embranchements auxquels peut⁻ĂȘtre associĂ©e une langue. Et Ă  chacun de ces embranchements, si des ressources linguistiques ont Ă©tĂ© identifiĂ©es par les mainteneurs du Glottolog, celles peuvent ĂȘtre proposĂ©es. Cette fonction permet aux linguistes de trouver des ressources sur les langues proches, non pas gĂ©ographiquement (mĂȘme si en pratique c’est le plus souvent le cas), mais d’un point de vue gĂ©nĂ©alogique.

    Les autres

    Il existe d’autres initiatives pour cataloguer les langues du monde, que ce soit la liste proposĂ©e par Wikipedia, la liste de la CIA ou encore The Linguasphere Register, mais ces initiatives ne sont pas aussi pertinentes du point de vue de la documentation des langues.

    Documenter les langues

    ELAN : des schĂ©mas d’annotation flexibles

    ELAN est un des logiciels libres (GPL3) les plus utilisĂ©s par les linguistes pour annoter des enregistrements audio et vidĂ©o. Il permet d’élaborer des structures d’annotation complexes permettant ainsi de rendre compte des analyses que les linguistes souhaitent associer Ă  un enregistrement. Ces couches d’annotation sont reliĂ©es les unes aux autres par des relations logiques, avec le plus souvent une couche de rĂ©fĂ©rence indexĂ©e temporellement Ă  l’enregistrement. Les annotations les plus courantes sont une transcription, une traduction et une annotation morphologique. Mais des nombreuses autres analyses peuvent ĂȘtre incluses, que ce soit les parties du discours, les rĂ©fĂ©rences et anaphores, l'animĂ©itĂ©, mais aussi les gestes, la structuration du discours, les signes pour les sourds et malentendants.

    Extrait d’une narration prĂ©sente dans DoReCo, et vue sur les diffĂ©rentes couches d’annotation pouvant ĂȘtre associĂ©s Ă  un enregistrement.

    Dans cette capture d’écran issu d’un texte de DoReCo retravaillĂ© par l’auteur, on aperçoit un extrait de quelques secondes d’une narration nisvaie. Il s’agit d’un des modes de visualisation des annotations proposĂ©es par ELAN pour reprĂ©senter les diffĂ©rentes couches d’annotation. Certaines de ces annotations ont Ă©tĂ© rĂ©alisĂ©es Ă  la main par l’auteur, d’autres ont Ă©tĂ© retravaillĂ©es par les algorithmes mis en place par DoReCo, puis manuellement corrigĂ©s. Enfin, il y a Ă©galement des couches d’annotation de la prosodie par le biais de SLAM+.

    FLEX : gĂ©rer un projet de documentation

    FLEX est un logiciel dĂ©veloppĂ© par le SIL et dont le code source est rĂ©gie par la licence LGPL 2.1. Il est conçu davantage pour coordonner l’ensemble d’une documentation linguistique, de la gestion des textes Ă  l’élaboration d’un dictionnaire, en passant par les analyses linguistiques. En revanche, il ne gĂšre pas rĂ©ellement l’annotation d’enregistrements. De nombreux linguistes l’utilisent en complĂ©ment d’ELAN.

    Si le logiciel est prometteur sur le papier, Ă  chaque fois que je l’ai essayĂ©, j’ai Ă©tĂ© rebutĂ© par son cĂŽtĂ© usine Ă  gaz, et surtout ses nombreux plantages notamment lorsqu’on essaie de gĂ©rer des fichiers multimĂ©dia avec. Et il en est de mĂȘme pour les autres logiciels dĂ©veloppĂ© par le SIL, tel que SayMore pour gĂ©rer les mĂ©tadonnĂ©es des enregistrements, WeSay pour faire des dictionnaires en collaboration avec les locuteurs et locutrices, Ă  chaque fois que je les ai essayĂ©s, enthousiasmĂ© par leurs fonctionnalitĂ©s, j’ai Ă©tĂ© déçu par le fait qu’ils ne fonctionnaient pas correctement sur mon ordinateur.

    Aperçu de Flex

    Cette capture d’écran illustre un des modes de saisie de FLEX, ici la vue tabulaire du lexique, qui permet de rentrer et gĂ©rer les dĂ©finitions des lexĂšmes (les entrĂ©es du dictionnaire) de maniĂšre assez rapide. On aperçoit dans la partie en haut Ă  gauche les autres modes d’édition du lexique, et en dessous les autres catĂ©gories liĂ©es Ă  la gestion d’un projet de documentation : Texts & Words, Grammar, Notebook et Lists. C’est Ă  travers la catĂ©gorie Texts & Words que l’on peut par exemple importer des textes transcrits, voire des fichiers ELAN pour peupler la base de donnĂ©es lexicales. Grammar permet de dĂ©crire les paradigmes grammaticaux, FLEX propose d’ailleurs quelques algorithmes qui aident Ă  la construction des paradigmes grammaticaux. Notebook et Lists servent Ă  la gestion du projet, le premier pour prendre des notes diverses, et le second pour crĂ©er des listes, en particulier des tĂąches encore Ă  rĂ©aliser.

    Et il y en a bien d’autres encore

    Il existe de nombreux autres logiciels similaires, tels qu’EXmaralda pour l’annotation des enregistrements (surtout utilisĂ© en Allemagne Ă  ma connaissance), Sonal (non libre, et dont le dĂ©veloppement semble arrĂȘtĂ©) qui est utilisĂ© par les sociologues et les anthropologues pour une annotation thĂ©matique de leurs entretiens, Anvil, qui semble intĂ©ressant mais que je n’ai jamais rĂ©ellement vu utilisĂ©, ou enfin le vieux Transcriber qui lui Ă©tait encore employĂ© par certains projets il y a quelques annĂ©es. Rentrer dans le dĂ©tail de tous ces logiciels dĂ©passerait le cadre d’une dĂ©pĂȘche comme celle-ci, mais Ă©numĂ©rer la diversitĂ© logicielle montre qu’il s’agit d’un secteur un minimum dynamique, d’ailleurs la question de la transcription et de l’annotation des enregistrements ne se limite pas du tout qu’au domaine de la documentation des langues du monde.

    L’archivage et la compilation de corpus

    Afin de conserver et partager les corpus et donnée enregistrées par les linguistes, chercheurs voire simplement les personnes ayant documenté une langue, il existe des archives, le plus souvent en ligne. Il y a en France par exemple Pangloss, géré par le LACITO, dédié aux langues orales, ou ORTOLANG, plus générique, pour les corpus de langue. En Océanie, il y a Paradisec. Il y a aussi ELAR, autrefois à Londres, et qui a déménagé récemment à Berlin récemment.

    Ces archives proposent diverses interfaces pour dĂ©poser, gĂ©rer et parfois mĂȘme consulter les enregistrements et les annotations rĂ©alisĂ©s par les linguistes et leurs collaborateurs·e·s. À noter que pour ces archives, Ortolang dĂ©crit son architecture logicielle qui repose sur des briques ouvertes, en revanche concernant Paradisec et Pangloss, bien que leur statuts soient sĂ»rement similaires du fait de la dĂ©marche gĂ©nĂ©rale de ses ingĂ©nieurs, je n’ai pas trouvĂ© de liens vers les logiciels employĂ©s. Quant Ă  ELAR, le logiciel utilisĂ© est Preservica, une solution propriĂ©taire qui, quand on a le malheur de devoir l’utiliser, fonctionne bien lentement.

    La compilation de corpus, si elle se rapproche de l’archivage en ce qu’il s’agit Ă©galement de recueillir, conserver et publier les corpus des linguistes, correspond Ă©galement Ă  une Ă©dition particuliĂšre de ces corpus. La compilation de corpus est rĂ©alisĂ© Ă  travers la mise en place de processus de qualitĂ©, d’annotations et de conventions particuliĂšres. Les deux compilations de corpus prĂ©sentĂ©es ici sont des compilations de corpus de documentation de langues orales. Les enregistrements ont Ă©tĂ© systĂ©matiquement annotĂ©s en utilisant une convention nommĂ©e les gloses interlinaires (le nom fait en fait rĂ©fĂ©rence Ă  la pratique ancienne d’insĂ©rer des explications entre les lignes d’un texte. En pratique aujourd’hui, ce n’est plus vraiment ce que font les linguistes, puisque le travail est informatisĂ© et les annotations ne sont plus entre les lignes, mais, le terme a cependant Ă©tĂ© conservĂ©).

    DoReCo

    DoReCo est une compilation de 52 corpus en accĂšs ouvert (NdR : auquelle l’auteur a contribuĂ©). La compilation a nĂ©cessitĂ© la mise en place de processus de qualitĂ© afin d’assurer la cohĂ©rence de l’ensemble et de fournir un certain nombre de garanties quant aux qualitĂ©s du corpus.

    Les langues dans DoReCo

    Une premiĂšre qualitĂ©, et l’une des originalitĂ©s de DoReCo, est de proposer un alignement temporel est trĂšs fin. La durĂ©e de chaque phonĂšme, de chaque morphĂšmes, de chaque mot (ici suivant la dĂ©finition de la personne Ă  l’origine du corpus, car la dĂ©finition d’un mot n’a rien d’une Ă©vidence) et enfin de chaque groupe de souffle est fournie. Une deuxiĂšme qualitĂ© a Ă©tĂ© de s’assurer que pour l’ensemble des retranscriptions, chacun des termes et des morphĂšmes possĂšde une glose, c’est-Ă -dire qu’ils possĂšdent une explication linguistique.

    La compilation totalise une centaine d’heures d’enregistrements audio, en grande majoritĂ© des narrations monologiques. À noter que les corpus de la compilation sont accĂšs ouvert, via une licence Creative Commons, mais que les droits d’utilisation varient d’un corpus Ă  l’autre. Les donnĂ©es sont accessibles aux formats d’ELAN : .eaf, de Praat : . TextGrid, TEI.xml, et.csv.

    Multi-CAST

    Multi-CAST est Ă©galement une compilation de 18 corpus de documentation de langues diffĂ©rentes. Les textes annotĂ©s via le logiciel ELAN. Contrairement Ă  DoReCo, l’alignement temporel des annotations n’est pas rĂ©alisĂ© de maniĂšre prĂ©cise, mais manuellement, par les personnes Ă  l’origine du corpus, Ă  l’échelle de l’énoncĂ©. Les textes sont Ă©galement en grande majoritĂ© des narrations monologiques. L’originalitĂ© de cette compilation de corpus vient du fait que les textes contiennent trois couches d’annotation particuliĂšres : GRAID, Grammatical Relations and Animacy in Discourse, (voir), puis RefIND et ISNRef (Referent Indexing in Natural Language Discourse, voir Schiborr et al. 2018).

    La page d’accueil de Multi-Cast

    Cette compilation de corpus est aussi disponible dans plusieurs formats. XML Ă©videmment, puisque c’est le format natif d’ELAN, mais aussi TSV et il existe Ă©galement un paquet pour R. Tout cela est disponible via la licence CC-BY 4.0.

    Conclusion

    J’espĂšre que vous avez apprĂ©ciĂ© cette introduction Ă  la documentation des langues Ă  travers les logiciels libres. L’idĂ©e est surtout d’attiser la curiositĂ©, car il reste Ă©videmment encore de nombreux aspects ou points Ă  discuter et Ă  approfondir. La prochaine fois que j’aborderai le thĂšme de la documentation linguistique ici, j’espĂšre que ça sera pour prĂ©senter mon application basĂ©e sur Django pour faire de la lexicographie.

    Il y a Ă©galement un autre sujet sur lequel j’aimerais bien Ă©changer ici prochainement : la question des licences des donnĂ©es collectĂ©s et la nĂ©gociation lorsque l’on travaille avec des personnes Ă  tradition orale. Si ouvrir l’accĂšs aux donnĂ©es de recherche et aux corpus peut sembler ĂȘtre une Ă©vidence pour certains, il ne faut pas oublier que souvent, les chercheurs et chercheuses de terrain collectent des informations personnelles, que la connaissance n’est pas forcĂ©ment considĂ©rĂ©e comme un bien public et les enregistrements, notamment les narrations, qui ne sont pas forcĂ©ment perçues comme des fictions, sont souvent couverts par des droits locaux. Enfin, ouvrir ses donnĂ©es de recherche, si c’est permettre Ă  d’autres de rĂ©utiliser ses donnĂ©es, requiert beaucoup de travail de la part des linguistes, c’est une tĂąche longue, ingrate et surtout peu valorisĂ©e. Alors qu’il est de plus en plus prĂ©caire d’ĂȘtre chercheur en sciences humaines, il est aussi difficile de demander Ă  ces chercheurs et chercheuses de consacrer une grande partie de leur temps Ă  des tĂąches qui ne leur permettront pas de se constituer un CV, nĂ©cessaire si l’on souhaite avoir un poste stable (c’est-Ă -dire plus de deux ans).

    Label sans IA : ce texte a Ă©tĂ© rĂ©digĂ© sans aucun aide de la part d’une LLM.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ❌