JSL 4.0Est-il judicieux d'utiliser la plateforme Scripters Club pour discuter des améliorations actuelles et futures de JSL ? L'objectif serait d'organiser les idées, d'informer les utilisateurs des nouvelles fonctionnalités et de promouvoir les améliorations à venir.
Les acteurs du changement :
Nouvelles fonctionnalités intéressantes/utiles :
Agréable à avoir :
Re: JSL 4.0Je ne sais pas si plusieurs utilisateurs peuvent obtenir un accès en écriture à la liste dans le message principal ?
Quelles améliorations de JMP19 appréciez-vous le plus ?
Qu'est-ce qui manque ?
Quelles approches peuvent être considérées comme des « innovations majeures » ?
Re: JSL 4.0Salut Hogi, existe-t-il un résumé de JMP présentant les nouvelles fonctionnalités JSL de JMP 19 ? Je n'ai pas encore consulté la documentation, je suis en train de découvrir et de tester la version 19.0.01 par rapport à mes installations précédentes (17.2 et 18.2).
Sur le générateur d'extensions :
Au cours des dix dernières années, j'ai développé plusieurs barres d'outils complémentaires contenant principalement des icônes personnalisées (jpg, etc.) stockées sur un lecteur réseau. Avec la façon dont j'avais codé et configuré le tout, JMP récupérait toutes ces icônes à chaque ouverture d'une fenêtre, car il avait besoin d'afficher les barres d'outils. Lorsque j'ai finalement compris l'origine du problème (une quarantaine de scripts étaient concernés), l'ouverture d'une fenêtre JMP pouvait prendre plusieurs secondes. Ce problème est apparu progressivement car, après la première année, je n'ajoutais de nouveaux scripts que très rarement.
Désormais, JMP19 dispose d'un nouvel outil de création d'extensions qui inclut automatiquement les fichiers JSL et d'icônes. Ainsi, lors de l'installation, ces fichiers sont copiés dans le répertoire personnel de l'utilisateur. J'ai configuré le système pour que les utilisateurs de JMP (version 19 et ultérieures) détectent automatiquement la mise à jour de l'extension lorsque leur installation de JMP détecte une mise à jour du fichier .jmpaddin du serveur. Ils seront alors invités à installer la mise à jour au redémarrage de JMP. La méthode est légèrement différente de l'ancienne, mais elle s'est avérée être la solution idéale au moment idéal… J'ai découvert la cause du problème il y a seulement quelques mois. Cette solution m'a donc été très utile, mais je soupçonne que mon cas est assez rare. Peut-être pas si rare sur ce forum, cependant. Merci à l'équipe de support JMP et aux développeurs pour leur aide précieuse.
Merci,
Micro
Re: JSL 4.0À ma connaissance, il n'existe pas de notes de version (« avec tous les détails »),
Aperçu général : Nouvelles fonctionnalités et notes de version de JMP
et cette page contenant des informations sur les mises à jour de sécurité : https://www.jmp.com/en/company/trust-center
C’est pourquoi j’ai pensé qu’il serait utile de fournir un bref aperçu ici.
Tous les commentaires et liens vers des fonctionnalités supplémentaires sont les bienvenus.
Re: JSL 4.0Modules complémentaires -
Outre l'outil standard « AddIn Builder » inclus dans JMP, on peut (et on DEVRAIT !) utiliser
Gestionnaire de modules complémentaires @Justin_Chilton -> maintenant disponible via le Marketplace : Gestionnaire de modules complémentaires
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-Chilton/ev-p/887937
Nouveauté de JMP19 : la vérification des mises à jour directement intégrée à JMP.
Dans les versions précédentes, il était possible de configurer une fonctionnalité similaire via UpdateCheck.jsl (depuis AddIn Manager).
Quelqu'un a-t-il comparé la vitesse des deux approches ?
Par exemple, pour 40 vérifications de mise à jour de compléments via UpdateCheck par rapport à la nouvelle fonctionnalité ?
La nouvelle fonction compare-t-elle la date du fichier ou un autre contenu ?
Au fait : @mikedriscoll
Un concept intéressant, très similaire au précédent :
Stratégies de gestion des modules complémentaires d'entreprise (2025-US-30MP-2576) @MikeD_Anderson
La principale différence du concept proposé :
Le dossier contenant la version « actuelle » des scripts (et des icônes ?) est stocké sur un OneDrive/Sharepoint et disponible sur le système local via un dossier synchronisé.
Re: JSL 4.0J'ai créé mon propre script de mise à jour en me basant sur les éléments initialement inclus par Justin, et je ne l'ai pas encore comparé directement aux nouvelles méthodes de la version 19. Je dirais que les méthodes de JMP sont potentiellement plus rapides, car elles recherchent un fichier mis à jour dans le dossier source, tandis que celles de Justin (du moins celles que j'utilise) peuvent être plus lentes selon l'emplacement des fichiers maîtres de métadonnées. Lors des quelques mises à jour d'un module complémentaire effectuées avec JMP 19, j'ai eu l'impression que la mise à jour était aussi rapide que celle que j'avais déjà implémentée.
Les nouvelles méthodes de la version 19 semblent se concentrer sur la recherche de nouveaux fichiers dans un emplacement donné, sans tenir compte des métadonnées de date de compilation. Bien que j'apprécie globalement cette approche, il n'existe aucun contrôle précis sur ce qui constitue un « dossier source ». Par exemple, si je glisse un module complémentaire depuis mon dossier Téléchargements et qu'il me demande si je souhaite rechercher des mises à jour, il indiquera le dossier Téléchargements comme source. De plus, il ne fait pas la distinction entre les versions de production et de test d'un module complémentaire, et le dossier « source » pourrait être incorrect si un utilisateur recherche des mises à jour alors qu'il s'agit d'une version de test installée depuis un autre emplacement.
J'ai demandé ici que nous soyons autorisés à codifier ces éléments (principalement pour ce fil de discussion, car nous avons brièvement évoqué l'autre point de la liste de souhaits).
Re: JSL 4.0@nathan-clark D'après ce que je vois avec l'outil de création d'extensions de JMP19, ce n'est pas tout à fait comme ça. Malheureusement, je n'ai pas le temps pour le moment de documenter entièrement mon expérience, mais je vais vous résumer rapidement ce que j'ai fait. Je ne suis pas un expert, cependant. Mon objectif était de reproduire fidèlement la version de mon ancien lecteur partagé, mais dans un autre emplacement, en utilisant la méthode JMP19.
Créez un complément en utilisant Fichier -> Nouveau -> Complément.
Configurez le module complémentaire en ajoutant vos scripts/icônes. Dans mon cas, ils se trouvent sur un lecteur partagé.
Configurez la mise à jour automatique des fichiers (dans l'onglet « Fichiers inclus ») et la vérification des mises à jour au démarrage de JMP (onglet « Général »).
Enregistrez le fichier sous un nouveau nom, .jmpaddin, dans un emplacement accessible. Laissez-le à cet emplacement et laissez les autres utilisateurs l'installer à partir de là.
Les autres utilisateurs de JMP installeront le logiciel à partir de cet emplacement et leur version de JMP vérifiera cet emplacement pour détecter les modifications.
Pour modifier un fichier, ouvrez l'éditeur de modules complémentaires (fichier jmpaddin) afin d'afficher l'éditeur. Apportez ensuite vos modifications au script. Le bouton « Enregistrer » devrait alors apparaître. Vous pouvez également utiliser « Enregistrer sous » et enregistrer le module complémentaire sous le même nom. Si vous déposez simplement un fichier de script mis à jour, ou si vous modifiez le fichier JSL et le fermez, puis rouvrez l'éditeur de modules complémentaires ultérieurement, l'option « Enregistrer » ne sera pas visible. Il s'agit d'un bug qui a été signalé au développeur.
Les utilisateurs de JMP qui utilisent des versions antérieures devront mettre à jour le module complémentaire en réinstallant le fichier .jmpaddin. Les utilisateurs de JMP 19 devraient être invités à mettre à jour le module complémentaire s'ils l'ont installé au même emplacement. Je ne sais pas ce qui se passe si nous envoyons le fichier .jmpaddin par e-mail… JMP ne saurait probablement pas où rechercher les mises à jour ultérieurement.
Re: JSL 4.0C'est logique, @mikedriscoll . Malheureusement, cela dépend de l'implémentation de la création d'extensions par JMP. J'ai beaucoup trop d'extensions pour cela, et maintenant qu'elles sont toutes gérées via GitHub, ces méthodes ne sont pas évolutives. C'est pourquoi j'ai demandé la codification des spécificités dans le fichier addin.def.
Je trouve que JMP19 fait de grands progrès en matière de gestion des modules complémentaires, mais à long terme, il faudra davantage d'options pour s'adapter à l'échelle à laquelle les utilisateurs et les organisations ont recours. Avec quelques mises à jour de JMP, je pense pouvoir commencer à abandonner progressivement une partie de mon infrastructure actuelle de mise à jour des modules complémentaires.
Re: JSL 4.0Que cela vous plaise ou non, il est regrettable que la vitesse de réaction au clic soit légèrement inférieure à celle de la version précédente (18). Bien sûr, cela dépend des spécifications du PC, mais la différence de vitesse de réaction est perceptible.
Re: JSL 4.0Je constate également que certaines choses pourraient devenir plus faciles dans JMP 19 en ce qui concerne les modules complémentaires.
Je préfère cette méthode de développement de mes modules complémentaires :
- dans un dossier décompressé de mon dossier Documents
- Pour l'installer, j'ouvre le fichier .def dans JMP.
- Je modifie le fichier .jmpcust dans un éditeur de texte (c'est un peu délicat, mais cela fonctionne parfaitement pour moi, car cela ne sera fait que pour de très rares modifications).
- Les éléments du menu font référence à des scripts contenus dans ce dossier.
- Je peux tester/modifier directement les scripts dans ce dossier (ce que je trouve très avantageux, car je trouve la copie et la mise à jour des fichiers dans .jmpaddin via le menu assez fastidieuses, inutiles et sujettes aux erreurs).
- Pour le déploiement, j'ai un petit script PowerShell qui compresse le module complémentaire et le déplace vers un emplacement partagé pour les autres utilisateurs (et, au passage, crée une copie de l'ancienne version afin qu'une restauration puisse être effectuée en cas de problème).
Re: JSL 4.0Oui, j'aimerais discuter des améliorations futures, etc., au sein du club des Scripteurs ; ce sujet pourrait en faire partie, mais ne devrait pas être le seul. Merci pour la suggestion.
Re: JSL 4.0@hogi Une meilleure gestion des erreurs, comme je l'ai suggéré dans ma liste de souhaits , changerait radicalement la donne. Dans la version 17.1, la gestion des erreurs n'est ni uniforme ni bien documentée. Actuellement (et je crois que c'est également le cas dans la version 18.2), il semble exister deux types de messages d'erreur disponibles dans `exception_msg()`, qui ne sont mentionnés ni dans l'index des scripts ni dans aucune autre documentation.
Le message d'erreur doit être indépendant de la langue pour permettre sa vérification lors de la gestion des erreurs, ou bien comporter un code d'erreur unique pouvant être vérifié par une routine de gestion des erreurs. Voici un exemple :
try (
<SOME action="https://community.jmp.com/">
,
<BR /> // we have to check for the exact message in all languages to handle a specific error:
<BR /> If (error_msg()[1] == "File not found" || error_msg()[1] == "Datei wurde nicht gefunden", // better would it be to have a language independent code // If (error_code() == 93 or better: ...== error_code["FileNotFound"] print("File not found: ");
<DO something="" because="" file="" was="" not="" found="">
, ... ); );
</DO>
</SOME>
La fonction Open renvoie actuellement un message d'erreur sous forme d'entrée de liste avec des arguments supplémentaires :
try(
open ("table");
,
Show(exception_msg());
//
// Returns in german language setting
// exception_msg() = {"Tabelle kann nicht geöffnet werden"(1, 2, "Open", Open /*###*/("table"))};
//
// Returns in english
// exception_msg() = {"Cannot open table"(1, 2, "Open", Open /*###*/("table"))};
);
Aucun de ces arguments n'est documenté nulle part, ou alors je n'ai rien trouvé à ce sujet.
À mon avis, il serait souhaitable de renvoyer un objet d'erreur (sous forme de classe) contenant toutes les informations relatives à l'erreur, par exemple :
try(
<ACTION>
<BR /> ,
<BR /> if (exception() << code == exception.FILENOTFOUND,
<BR /> Print( exception() << message );
<BR /> ...
</ACTION>
Il y a ensuite la fonction throw, qui est pratique mais ne semble pas prendre en charge les arguments utilisés dans exception_msg(). Il serait souhaitable de pouvoir transmettre les valeurs des arguments à la routine de gestion des erreurs.
try(
throw("Error"(1,2));
,
Show (exception_msg());
// Arguments to the thrown "Error" are lost.
);
En conclusion, la gestion des erreurs pourrait être améliorée. Je vous serais reconnaissant de bien vouloir mettre en œuvre ces améliorations.
Re: JSL 4.0Lien : Améliorer et documenter les messages d’erreur
Merci, je l'ai ajouté comme « nouvelle fonctionnalité intéressante/utile » - je le déplacerai dans la catégorie « Révolutionnaire » une fois qu'il aura atteint le top 10.
Pour la partie documentation, il existe un index complet des scripts .
En suivant l'idée du « top dix », je la fais passer de « cool/utile » à « révolutionnaire ».
Plus de candidats ?
Re: JSL 4.0À quelle fréquence utilisez-vous l'agrégation de colonnes ? Et plus particulièrement les agrégations « restreintes » avec des expressions Si() complexes ?
Veuillez consulter la section « Nombre d'entrées uniques à renseigner ».
et votez : Colonne Médiane (et autres) : ajouter l’option « Où »
