LUGE 2020.1 - Appel à présentations

[Nicolas_Bats]

La prochaine rencontre de notre groupe n'est pas encore planifiée mais je suis certain que cette période de confinement saura stimuler (ou libérer) la créativité de bon nombre d'entre nous. Le sujet est donc d'ores et déjà ouvert pour que vous puissiez exprimer vos idée.

Ce fil de discussion est dédié à recueillir vos propositions de sujet que vous souhaiteriez aborder sous la forme de présentation ou autre (n'hésitez pas à être innovant !) lors de cet après-midi.

Règles spécifiques à ce fil de discussion :

• Un message = un sujet.
• La personne qui poste le message est responsable de "l'animation" du temps alloué sur le sujet si celui c’est retenu.
• Pas de discussion sur ce fil, vous pouvez bien entendu en créé un spécifique si vous le souhaitez.
• Chacun peut voter, à l'aide de la petite étoile en bas de chaque post (compliment/kudo), pour les sujets qu'il préfère afin d'indiquer aux organisateurs les sujets les plus attendus.

NB : le contenu final de la rencontre sera décidé en fonction des votes, mais aussi de la cohérence des thèmes retenue.

Merci d'avance pour toutes vos propositions !

Nicolas

[Nicolas_Bats]

Scripting en LabVIEW

[Desruelle_luc]

Salut à tous,

personnellement je suis intéressé par un LUGE virtuel. Je pensais avoir un peu de temps avec le confinement, finalement je suis plus occupé que d'habitude. Mais je peux toujours me fabriquer du temps, d'ici le 5 mai, c'est juste une histoire d'organisation. A+ Luc

[Nicolas_Bats]

LabVIEW Project Providers

[Nicolas_Bats]

Code Reuse

[Mathieu_R.]

DAQmx : pourquoi je trouve ce driver génial !

Quelle part des fonctionnalités de ce driver pensez-vous connaître ? Exploiter dans vos applications ?

Présentations de quelques fonctionnalités "avancées" que j'espère vous faire découvrir.

[Solutest-Brice_Blanc]

DQMH et plugin

Salut à toi le lugiste, je propose une petite présentation sur un problème que je viens de résoudre concernant la possibilité de créer des plugins DQMH. Malgré la littérature extensive concernant DQMH, je n'ai pas trouvé de post ou de document précisant la technique pour y arriver. C'est pourquoi je propose cette présentation et ma solution que l'on pourra bien-sur discuter. A bientôt derrière vos micros 😞

Brice

[Nicolas_Bats]

Vous pouvez accéder à la rencontre à l'adresse suivante : https://bit.ly/LUGE-2020_1

A toute à l'heure, début des présentations 16h30 !

[Mathieu_R.]

...vous êtes invité à vous connecter à partir de 16h15, le temps de découvrir l'outil (au besoin), de se dire bonjour, et de couper les micros pour laisser la parole à Nicolas !

A tout à l'heure,

[Nicolas_Bats]

Suite aux nombreuses questions & remarques qui ont été posées pendant la présentation, voici un retour plus argumenté.

[16:35] Bertrand

Ok tu nous fais pas de démo : mais combien de temps il faut pour le mettre en oeuvre ?

Pour créer un provider, ajouter un menu et le VI qui s'exécute quand on clique sur le menu il faut une dizaine de minutes lorsqu'on sait faire. La plus grande partie du temps consacrée aux providers est clairement la phase d'apprentissage car le sujet est très peu documenté par NI.

[16:41] Bertrand

Si je comprends bien, "project provider" c'est le nom choisi par NI pour designer une espèce de plugin aux IDE de Labview ? Ce nom traduit bien les fonctionalités ? Pas vraiment, et heureusement que tu nous l'explique. Du coup, si tu devais leur donner un nom ... ce serait quoi ?

Je pense que les anglophones natifs de chez NI sont bien mieux placés que moi pour ce genre de questions, ils devaient certainement avoir de bonnes raisons de nommer le framework ainsi. Les project providers apportent ou "fournissent des fonctionnalités / éléments / services aux projets LabVIEW". La dénomination "project provider" n'est pas dénuée de sens je trouve, mais d'un point de vue très développeur je l'accorde. Il faut savoir que le framework n'a pas été créé pour être utilisé par nous mais bien en interne à l'origine.

Pour faire un parallèle cela peut correspondre (entre autres) à des plugins ou des extensions dans de nombreux autres IDE, ou encore à des "modules complémentaires" en bon français.

[16:42] Jérémy

Est-ce que l'on peut interdire l'ajout d'un certain type de fichiers au projet ?

Pas directement. En revanche il est possible d'attacher des actions aux types de fichier que tu ne souhaites pas voir apparaitre dans ton projet. Lorsque ces derniers seront ajoutés au projet, il sera ainsi possible d'afficher un popup d'erreur ou même de supprimer l'élément du projet par scripting.

[16:44]  Bertrand

Intéressant le PP release : est ce que ce code est accessible à la communauté ?

J'attends de finir quelques fonctionnalités et le code sera open sourcé oui.

[16:44] Cyril 

Qu'est ce qui est executé quand un menu final est choisi ? un VI ?

Oui tout est VI dans les project providers :
- Les VIs interface permettent de renvoyer les chemins vers les autres VIs.
- Les VIs OnPopup permettent de construire les menus qui apparaissent.
- Les VIs OnCommand sont appelés lorsque l'utilisateur clic sur un menu.
- Et bien d'autres ...

Mais rien n'empêche dans les VIs appelés d'utiliser SystemExec ou tout autre communication avec un système externe.

[16:47] Bertrand

Est ce rétro compatible : genre si je développement en 2019 ... ça marchera pour 2017 ?

Non. Un project provider est du code G appelé par LabVIEW il faut donc que LabVIEW soit d'une version au moins égale à celle du project provider. C'est comme pour les toolkits.

[16:48] Cyril

Donc un prject provider n'est pas backward compatible avec des anciennes version de LV ?

Les project providers sont installés dans un sous-répertoire du répertoire d'installation de LabVIEW. Il faut donc installer le provider pour chaque version de LabVIEW comme les toolkits.

Je n'ai pas réussi à trouver de documentation sur le sujet mais les exemples fournis par NI sont en LabVIEW 9. Je peux vérifier si c'est compatible avec des versions plus anciennes mais j'imagine qu'il n'y a plus beaucoup de monde qui utilise ces versions.

[16:49] Loïc

On peut l'installer par VIPC ?

Il est possible d'installer un project provider via VIPM donc j'imagine qu'il doit être possible de l'inclure dans un VIPC. A vérifier je ne l'ai jamais fait.

[16:50] Bertrand

c'est hors la loi ... c'est bien

Carrément ^^

[16:54] Mathieu

Serveur de release : solution maison moins chère, ça dépend du temps à passer à le mettre en place, le maintenir, mettre en place la stratégie de backup/sauvegarde/continuité de service dudit serveur... Faut voir ce que coûte une solution commerciale.

Tout à fait d'accord, à fonctionnalités équivalentes la solution commerciale sera forcément moins cher. Les 2 solutions commerciales citées permettent de faire bien plus que du stockage de fichiers.

La remarque était plutôt dans le sens où si des personnes souhaitent s'essayer à utiliser un serveur de releases, un premier pas peu couteux est déjà d'utiliser un répertoire partagé sur le réseau ou une clé USB. Ca n'est pas le top mais ça peut déjà enclencher une démarche. Et c'est dans cette optique que dans le project provider qui a été présenté, un type de serveur est "Explorer". Il permet d'utiliser un simple chemin sur le disque. Le jour où la personne décide de basculer sur une autre solution de serveur elle doit uniquement changer la configuration de ce serveur dans le projet LabVIEW mais sa façon de travailler et les menus restent les mêmes.

[16:55] Olivier

Gitlab, en plus de la gestion des sources, des issues, de la CI, propose également un serveur de release.

Pas de pub pour Gitlab Olivier, GitHub c'est mieux 😉

[17:01] Olivier

est-ce que les actions faite par ton PP ne pourraient pa être faite via des scripts de CI/CD ?

Le project provider qui a été présenté est un début d'automatisation pour faire du CI/CD. C'est un peu le liant qui fait le lien entre l'IDE LabVIEW et les scripts de CI/CD pour déployer les fichiers. Mais l'outil se positionne de façon un peu intermédiaire entre un tout manuel et une chaîne de production complètement automatisée.

L'outil a été créé pour répondre à un besoin où le développeur souhaite garder l'étape de compilation manuelle sur sa machine (étape laissée en blanc dans les slides) pour différentes raisons (infrastructure IT non disponible, besoin d'une licence LabVIEW supplémentaire pour le serveur de compilation, coûts et délais de mise en place). Mais effectivement si l'étape de compilation est automatisée et externalisée le PP présenté n'a plus d'utilité car on fait directement "serveur de code source > serveur de compilation > serveur de release" sans repasser par LabVIEW.

[17:01] Cyril

Est-il possible de supprimer le besoin de cliquer sur le build d'exe -> Upload ?

Pas pour le moment mais dans la slide "Improvements" que l'on a passée un peu rapidement, il est prévu d'ajouter la fonctionnalité "Automatic upload if available" sous forme d'un menu à cocher positionné sous le menu upload. Ce menu permettra (si il est coché) de pousser automatiquement tous les build sans action utilisateur.

Mais cette fonctionnalité est conditionnée par d'autres améliorations préalables (ex : mode asynchrone sans fenêtre de progression) et demande d'être complétée d'autres améliorations d'usage (ex : possibilité de protéger l'espace disque sur le serveur en ne gardant que les N derniers builds).

[17:05] Cyril

Ca rejoins un peu la tienne : il reste encore une étape manuelle : uplaoder le build. Comment supprimer cette étape si possible via le PP ?

C'était volontaire de conserver cette étape manuelle mais simple en 2 clics. Une amélioration permettra de s'affranchir de cette étape (cf. message ci-dessus) mais il y aura toujours la possibilité d'avoir les 2 modes de fonctionnement upload manuel et upload automatique.

[17:06] Cyril

Hors PP : Les version sont changées dans le projet ou sur les fichiers buildés eux même ?

Dans le projet pour garder trace, sinon en faisant "new fix > fermer le projet > réouvrir le projet > new fix" on reviendrait au même numéro de version. L'idée était aussi de rester compatible et intégré à la gestion des numéros de version faite par LabVIEW via la fenêtre de propriétés. La les 2 systèmes fonctionnent ensemble, si l'un est modifié l'autre aussi et inversement. L'incrémentation du built number dans la version reste gérée par LabVIEW.

[17:09] Jean-Louis

Comment sont gérées "releases notes" ?

Elles ne sont pas gérées par ce project provider. En revanche si les release notes sont intégrées au build (ex : Source Files > Always included) elles seront déployées sur le serveur de release en même temps que l'EXE.

Le PP présenté permet de fournir une interaction avec le serveur de releases uniquement. La génération d'une release note doit offrir une connectivité au gestionnaire de tickets qui pour moi devait faire l'objet d'un PP séparé (plus simple à maintenir et à déployer, mieux découplé, meilleure visibilité et permet d'utiliser l'un sans l'autre). J'ai un autre PP qui vient ajouter d'autres menus permettant de générer des releases notes automatiquement.

J'avais préparé une slide d'ouverture sur ce sujet mais nous n'avons pas eu le temps de la passer en revue. Elle sera dans le powerpoint en ligne. Peut-être une autre présentation LUGE si il y a des intéressés.

[17:10] Bertrand

Prévois tu une fonction de mise à jour automatique des versions (côté client ?)

Non car il s'agit d'un tout autre besoin qui ne fait pas partie du scope prévu pour le project provider. L'outil qui a été développé s'intègre dans l'environnement de développement et a pour seul objectif de faire le lien entre l'IDE LabVIEW et le serveur de releases. Les mises à jour coté client font partie de l'environnement de production et pour moi ces 2 environnement n'ont pas à communiquer directement du moins pas via cet outil. Le serveur de releases est un bon candidat pour faire le lien entre ces 2 environnements mais un autre outil doit être utilisé coté client.

[17:13] Cyril

il reste un clic menu !

Heureusement sinon ce serait la suprématie des machines et ça finirait en Terminator !!!