Sophya merge requestshttps://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests2022-07-19T17:37:46+02:00https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/9Nettoyage et amélioration de la configuration des compilateurs2022-07-19T17:37:46+02:00GRASLAND HadrienNettoyage et amélioration de la configuration des compilateurs- Nettoyage du formatage des fichiers .inc (plus d'espaces blancs en fin de ligne)
- Suppression de code commenté qui n'est plus à jour par rapport au code actuel
- Utilisation de la norme C99 avec les extensions courantes comme M_PI
- S...- Nettoyage du formatage des fichiers .inc (plus d'espaces blancs en fin de ligne)
- Suppression de code commenté qui n'est plus à jour par rapport au code actuel
- Utilisation de la norme C99 avec les extensions courantes comme M_PI
- Suppression de compilateurs qui ne sont plus supportés par les version actuelles de Sophya
- Homogénéisation de la configuration entre compilateurs (-fPIC partout)
- Utilisation du niveau d'optimization maximal -O3
- Support de la transformation de x*y+z en Fused Multiply-Add sous clang (important pour la performance du calcul vectoriel dans BRVisibilityCalculatorV2).
Cette MR ne contient PAS l'optimisation des binaires pour le CPU cible (`-march=<quelque chose>`), car ce processus est malheureusement différent pour icc vs gcc/clang, et il n'y a pas de façon propre d'abstraire la différence. Donc tant qu'on supportera icc (qui a été récemment déprécié par Intel en faveur d'une migration vers clang sur le long terme), il faudra s'en tenir à l'utilisation de `-compopt`. J'ai [ajouté une note explicative](https://gitlab.in2p3.fr/SOPHYA/DocSophya/-/compare/371033d50e3fa9b14cd055d60421b3d3780e87f8...develop?from_project_id=1723) à DocSophya.https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/8Résolution du problème des pipelines "detached"2022-07-06T09:10:15+02:00GRASLAND HadrienRésolution du problème des pipelines "detached"D'après [la doc](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html), Gitlab marque désormais une distinction entre des pipelines de branches, qui s'exécutent tout le temps, et des pipelines de merge requests ("detached...D'après [la doc](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html), Gitlab marque désormais une distinction entre des pipelines de branches, qui s'exécutent tout le temps, et des pipelines de merge requests ("detached"), qui ne s'exécutent que lors d'une merge request.
Par défaut, rien ne s'exécute pour ces seconds pipelines. Mais en présence d'une directive "rules:" dans un job, la configuration par défaut est inhibée. Comme je n'utilise actuellement cette directive que dans un seul job, seul ce job tourne, sans que les jobs précédent n'aient été exécutés, et évidemment ça se passe mal.
Dans cette MR, je vais tester deux configurations. Une où l'ensemble des jobs s'exécutent dans les pipelines de merge requests, et une où aucun des jobs ne s'y exécute.https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/7Merging V=2.565 from develop into master2022-07-05T11:21:48+02:00Reza ANSARIMerging V=2.565 from develop into masterMerging V=2.565 from develop into master - Etape pour preparer la future release de SOPHYA (V=2.6 , ou bien 3.0 ?)Merging V=2.565 from develop into master - Etape pour preparer la future release de SOPHYA (V=2.6 , ou bien 3.0 ?)Reza ANSARIReza ANSARIhttps://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/6Utilisation de Kaniko pour la construction d'images Docker2022-03-21T16:00:10+01:00GRASLAND HadrienUtilisation de Kaniko pour la construction d'images DockerLe CC, dans leur grande sagesse, [viennent de bannir du jour au lendemain](https://gitlab.in2p3.fr/cc-in2p3-gitlab/maintenance/-/issues/184) une techno que j'utilisais pour construire des images de conteneurs (sortes de machines virtuell...Le CC, dans leur grande sagesse, [viennent de bannir du jour au lendemain](https://gitlab.in2p3.fr/cc-in2p3-gitlab/maintenance/-/issues/184) une techno que j'utilisais pour construire des images de conteneurs (sortes de machines virtuelles _light_) dans l'intégration continue. Je bascule donc sur la solution de rechange qu'ils recommandent.https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/5CI: Use a patched libsharp that does not use -march=native2022-03-09T14:58:36+01:00GRASLAND HadrienCI: Use a patched libsharp that does not use -march=nativelibsharp builds with the -march=native flag, which results in non-portable binaries, and that's not what we want on a CI system with multiple nodes :)libsharp builds with the -march=native flag, which results in non-portable binaries, and that's not what we want on a CI system with multiple nodes :)https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/4Implementation socket UDP2022-02-26T11:03:53+01:00GRASLAND HadrienImplementation socket UDPhttps://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/3WIP: Utilisation des types entiers de la norme C++2021-08-25T10:27:41+02:00GRASLAND HadrienWIP: Utilisation des types entiers de la norme C++Cette soumission se base sur !2 et ne devrait donc être évaluée qu'après coup.
Ici, l'idée est de simplifier l'interaction du code écrit en C++ récent avec SOPHYA en utilisant systématiquement dans l'implémentation SOPHYA les types enti...Cette soumission se base sur !2 et ne devrait donc être évaluée qu'après coup.
Ici, l'idée est de simplifier l'interaction du code écrit en C++ récent avec SOPHYA en utilisant systématiquement dans l'implémentation SOPHYA les types entiers qui sont désormais fournis par la norme C++.
Ainsi...
- int_1 devient un alias de int8_t
- int_2 devient un alias de int16_t
- int_4 devient un alias de int32_t
- int_8 devient un alias de int64_t
- Idem pour les versions non signées
- sa_size_t devient un alias de ptrdiff_t (et non size_t car il doit être signé)
---
Les premiers changements permettent au code utilisant les types entiers de taille fixe normalisés de stdint.h d'interagir sans soucis avec du code SOPHYA basé sur les types int_x.
Initialement, je voulais même migrer le code SOPHYA aux types stdint, mais il s'avère qu'en pratique, Sophya expose le nom des types entiers utilisés en interne de diverses manières (APIs émettant/recevant des chaînes de caractères avec ce nom dedans, enums nommées par rapport aux types entiers dans datatypes.h, APIs suivant une convention en U1/2/4/8...), donc j'ai trop peur de casser quelque chose ou de perturber les gens en effectuant cette migration.
En revanche, c'est possible de migrer TAcq aux types stdint, et c'est ce que je vais tenter après.
---
Je m'attends à ce que le point sur la modification de sa_size_t soit potentiellement plus polémique (peut créer des incompatibilités binaires si des données en sa_size_t sont écrites dans des fichiers), donc je suis prêt à revenir dessus.
Je me disais juste que si on est parti pour moderniser nos types entiers, ça vaut le coup d'enlever une "surprise" possible au niveau du size_t en se rapprochant des types indice standard du C/++.
---
Résout le bug #2https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/2Sélection de norme C++, avec C++11 minimum/par défaut2021-08-25T10:27:55+02:00GRASLAND HadrienSélection de norme C++, avec C++11 minimum/par défautCette MR permet de sélectionner la norme C++ utilisée, via le flag "-cxxstd" au script configure, qui accepte deux syntaxes différentes:
- Une syntaxe simple où on donne le numéro de version de la norme C++ souhaitée (98, 11, 17...) et ...Cette MR permet de sélectionner la norme C++ utilisée, via le flag "-cxxstd" au script configure, qui accepte deux syntaxes différentes:
- Une syntaxe simple où on donne le numéro de version de la norme C++ souhaitée (98, 11, 17...) et le script configure se charge de vérifier que SOPHYA est compatible, puis de générer le bon flag de dialecte pour le compilateur.
- Une syntaxe avancée où on donne directement un dialecte C++ spécifique au compilateur cible (ex: gnu++17 = C++17 avec les extensions GNU) et le script configure le passe tel quel au compilateur en croisant les doigts pour que ce soit compatible.
J'ai vérifié que ça compile chez moi (avec une tonne de warnings), mais je ne connais pas Sophya assez bien pour tester plus que ça.https://gitlab.in2p3.fr/SOPHYA/Sophya/-/merge_requests/1pascal, un grand classique2019-12-12T18:28:44+01:00Barrand Guypascal, un grand classiquepascal est, hélas, une cpp macro chez Windows/VisualC++ (et aussi chez Apple/Cocoa). Et donc sunitpcst.h ne compile pas ici. Un grand classique de la non portabilité. Geant4 a eu aussi le même problème. Je propose la même chose que ce qu...pascal est, hélas, une cpp macro chez Windows/VisualC++ (et aussi chez Apple/Cocoa). Et donc sunitpcst.h ne compile pas ici. Un grand classique de la non portabilité. Geant4 a eu aussi le même problème. Je propose la même chose que ce qu'ils ont fait. (Pour Cocoa, je me débarrasse du problème autrement).
MAIS, je proposerais aussi que vous changiez 'pascal()' en 'Pa()' pour évacuer le problème "once for all" !MagnevilleMagneville