JSL 4.0Ha senso utilizzare la piattaforma Scripters Club per discutere di miglioramenti nuovi e futuri di JSL? L'obiettivo sarebbe quello di organizzare le idee, informare le persone sulle nuove funzionalità e pubblicizzare i miglioramenti futuri.
Fattori di svolta:
Nuove funzionalità interessanti/utili:
bello avere:
Re: JSL 4.0Non so se più utenti possono ottenere l'accesso in scrittura all'elenco nel post principale?
Quali miglioramenti di JMP19 apprezzi di più?
Cosa manca?
Quali approcci possono essere considerati "rivoluzionari"?
Re: JSL 4.0Ciao Hogi, JMP fornisce un riepilogo che evidenzia le nuove funzionalità JSL per JMP19? Non ho ancora letto la documentazione, sto ancora solo curiosando e testando la versione 19.0.01 rispetto alle mie installazioni precedenti (17.2 e 18.2).
Nel generatore di componenti aggiuntivi:
Negli ultimi 10 anni e più, ho sviluppato un paio di barre degli strumenti aggiuntive che contenevano per lo più icone personalizzate (jpg, ecc.) memorizzate su un'unità di rete. Per come le ho programmate e configurate, JMP recuperava tutte quelle icone ogni volta che si apriva una finestra JMP, perché JMP aveva bisogno di visualizzare le barre degli strumenti. Quando ho capito cosa stava causando il problema (erano circa 40 script), ci volevano diversi secondi per aprire una finestra JMP. È successo gradualmente perché, dopo il primo anno, ho aggiunto un nuovo script solo di tanto in tanto.
Ora, JMP19 ha un nuovo generatore di componenti aggiuntivi che include automaticamente i file jsl e delle icone come parte del componente aggiuntivo, quindi quando un utente lo installa, le immagini jsl e delle icone verranno copiate in una cartella home locale, ma l'ho impostato in modo che gli utenti JMP (dalla versione 19 in poi) possano rilevare automaticamente che il componente aggiuntivo è stato aggiornato quando la loro installazione di JMP "vede" un aggiornamento al file .jmpaddin del server, e verrà loro richiesto di installare l'aggiornamento al riavvio di JMP. Il processo è leggermente diverso dal mio vecchio metodo, ma è stata la soluzione perfetta al momento giusto... Ho scoperto la causa principale del problema solo negli ultimi due mesi. Quindi è stato davvero utile per me, ma sospetto che il mio sia un caso piuttosto oscuro. Anche se forse non così oscuro in questo forum. Grazie al team di supporto JMP e agli sviluppatori per avermi aiutato con la soluzione.
Grazie,
Microfono
Re: JSL 4.0A mia conoscenza non ci sono note di rilascio ("con tutti i dettagli"),
solo una "panoramica" generale: nuove funzionalità e note di rilascio di JMP
e questa pagina con informazioni sugli aggiornamenti di sicurezza: https://www.jmp.com/en/company/trust-center
Ecco perché ho pensato che sarebbe stato utile fornire qui una breve panoramica.
Sono benvenuti commenti e link a funzionalità aggiuntive.
Re: JSL 4.0Componenti aggiuntivi -
Oltre allo standard "AddIn Builder" incluso in JMP, si può (DOVREBBE!!!) usare
Gestore componenti aggiuntivi @Justin_Chilton -> ora tramite Marketplace: Gestore componenti aggiuntivi
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-Chilton/ev-p/887937
Novità di JMP19: il controllo degli aggiornamenti è incluso direttamente in JMP.
Nelle versioni precedenti era possibile impostare una funzionalità simile tramite UpdateCheck.jsl (da AddIn Manager).
Qualcuno ha confrontato la velocità dei due approcci?
ad esempio per 40 controlli di aggiornamento dei componenti aggiuntivi tramite UpdateCheck rispetto alla nuova funzionalità?
La nuova funzione confronta la data del file o alcuni contenuti?
A proposito: @mikedriscoll
Un concetto interessante, molto simile al tuo precedente:
Strategie di gestione dei componenti aggiuntivi aziendali (2025-US-30MP-2576) @MikeD_Anderson
La differenza importante del concetto proposto:
La cartella con la versione "corrente" degli script (e delle icone?) è archiviata su OneDrive/Sharepoint ed è disponibile sul sistema locale tramite una cartella sincronizzata.
Re: JSL 4.0Ho creato il mio script di aggiornamento basato sul materiale di aggiornamento originariamente incluso da Justin e non l'ho testato parallelamente ai nuovi metodi della versione 19. Devo dire che potrebbe essere più veloce con i metodi di JMP, dato che cercano un file aggiornato in una cartella sorgente, mentre i metodi di Justin (almeno quelli che uso io) potrebbero essere lenti a seconda di dove si trovano i file master dei metadati. Dalle un paio di volte in cui JMP mi ha chiesto di aggiornare un componente aggiuntivo in jmp19, "sembra" veloce quanto quello che ho già implementato.
Poiché i nuovi metodi nella versione 19 sembrano fondamentalmente cercare nuovi file in una posizione specifica e non essere vincolati ad alcun metadato di builddate, sebbene questo approccio mi piaccia in generale, non c'è un vero controllo su cosa costituisca una "cartella sorgente"... ad esempio, se trascino un componente aggiuntivo dalla cartella dei download e mi chiede se voglio verificare la presenza di aggiornamenti, elencherà la cartella dei download come sorgente da controllare. Inoltre, non distingue tra versioni di produzione e di prova di un componente aggiuntivo, e la cartella "sorgente" potrebbe essere errata se un utente verifica la presenza di aggiornamenti, ma si tratta di una versione di prova installata da una posizione diversa.
Ho chiesto qui che ci sia consentito di codificare questi pezzi (soprattutto per questa discussione, dato che abbiamo parlato brevemente dell'altro elemento della lista dei desideri).
Re: JSL 4.0@nathan-clark, da quello che vedo con il generatore di componenti aggiuntivi di JMP19, non è proprio così. Purtroppo al momento non ho tempo di documentare completamente la mia esperienza, ma vi racconterò brevemente cosa ho fatto. Non sono un esperto, però. Il mio obiettivo era replicare completamente la mia vecchia versione di unità condivisa, ma in un'area diversa, utilizzando il metodo JMP19.
Crea un componente aggiuntivo tramite file->nuovo->aggiungi.
Configura il componente aggiuntivo aggiungendo i tuoi script/icone. Nel mio caso, si trovano su un'unità condivisa.
Aggiorna automaticamente i file (nella scheda Includi file) e verifica la presenza di aggiornamenti all'avvio di JMP nella scheda Generale.
Salva con nome per creare un nuovo file .jmpaddin in una posizione accessibile. Lascialo lì e chiedi ad altri di installarlo da quella posizione.
Altri utenti JMP installeranno da quella posizione e la loro versione di JMP controllerà quella posizione per rilevare eventuali modifiche.
Quando vuoi modificare un file, apri il generatore di componenti aggiuntivi/file jmpaddin in modo da visualizzare l'editor del componente aggiuntivo. Quindi apporta le modifiche allo script. Il pulsante "Salva" dovrebbe quindi apparire visibile nel generatore di componenti aggiuntivi. In alternativa, usa "Salva con nome" e salva il componente aggiuntivo con lo stesso nome. Se trascini semplicemente un file di script aggiornato o modifichi il file jsl e lo chiudi, per poi aprire in seguito il generatore di componenti aggiuntivi, non vedrai l'opzione di salvataggio. Questo è un bug che è stato segnalato allo sviluppatore.
Gli utenti di JMP che utilizzano versioni precedenti dovranno aggiornare il componente aggiuntivo reinstallando il file .jmpaddin. Agli utenti di JMP19 dovrebbe essere richiesto di aggiornare il componente aggiuntivo se lo hanno installato dalla stessa posizione. Non so cosa succederebbe se inviassimo il file .jmpaddin via email... presumibilmente JMP non saprebbe dove cercare gli aggiornamenti in seguito.
Re: JSL 4.0Ha senso @mikedriscoll . Purtroppo, questo si basa sull'implementazione di JMP per la creazione di componenti aggiuntivi. Ho troppi componenti aggiuntivi per questo e ora che li gestiamo tutti tramite GitHub, quei metodi non sono scalabili, motivo per cui ho richiesto la codifica delle specifiche nel file addin.def.
Penso che JMP19 stia facendo buoni progressi nella gestione dei componenti aggiuntivi, ma a lungo termine saranno necessarie più opzioni per adattare la gestione dei componenti aggiuntivi a diverse persone/organizzazioni. E con alcuni aggiornamenti di JMP, credo di poter iniziare a deprecare parte della mia attuale infrastruttura di aggiornamento dei componenti aggiuntivi.
Re: JSL 4.0Che vi piaccia o no, è un peccato che la velocità di reazione quando cliccate sia un po' più lenta rispetto alla versione precedente della 18. Naturalmente dipende dalle specifiche del PC, ma credo che ci sia una netta differenza nella velocità di reazione.
Re: JSL 4.0Vedo anche che alcune cose potrebbero diventare più semplici in JMP 19 per quanto riguarda i componenti aggiuntivi.
Il modo che preferisco per sviluppare i miei componenti aggiuntivi è questo:
- in una cartella decompressa nella mia cartella documenti
- Per installarlo, apro il file .def in JMP
- Modifico il file .jmpcust in un editor di testo (è un po' complicato, ma per me funziona perfettamente, dato che non è necessario farlo per la maggior parte delle modifiche)
- Le voci di menu fanno riferimento agli script in questa cartella
- Posso testare/modificare direttamente gli script in questa cartella (cosa che trovo un grande vantaggio, poiché trovo che copiare e aggiornare i file in .jmpaddin tramite il menu sia piuttosto noioso, inutile e soggetto a errori).
- Per la distribuzione, ho un piccolo script PowerShell che impacchetta il componente aggiuntivo e lo sposta in una posizione condivisa per altri utenti (e, tra l'altro, crea una copia della versione precedente in modo che sia possibile eseguire un rollback in caso di problemi).
Re: JSL 4.0Sì, mi piacerebbe discutere di futuri miglioramenti ecc. nel club degli Scripters, ad esempio questo argomento potrebbe farne parte, ma non dovrebbe essere l'unico. Grazie per il suggerimento.
Re: JSL 4.0@hogi Sarebbe un punto di svolta se ci fosse una migliore gestione degli errori, come ho proposto in una voce della Wishlist . La gestione degli errori, almeno nella versione 17.1, non è univoca e non è ben documentata. Allo stato attuale (e credo anche nella versione 18.2), sembrano essere disponibili due diverse forme di messaggi di errore in exception_msg(), che non sono documentate né nell'Indice di scripting né in altra documentazione.
Il messaggio di errore dovrebbe inoltre essere indipendente dalla lingua per poter essere controllato nella gestione degli errori oppure dovrebbe avere un codice di errore univoco che possa essere controllato in una routine di errore. Potrebbe apparire così:
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 funzione Open restituisce attualmente un messaggio di errore come voce di elenco con argomenti aggiuntivi:
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"))};
);
Nessuna di queste argomentazioni è documentata da nessuna parte, oppure non l'ho ancora trovata.
Secondo me sarebbe bello avere un oggetto errore (in un formato di classe) restituito che contenga tutte le informazioni sull'errore, ad esempio:
try(
<ACTION>
<BR /> ,
<BR /> if (exception() << code == exception.FILENOTFOUND,
<BR /> Print( exception() << message );
<BR /> ...
</ACTION>
Poi c'è la funzione throw, che è utile ma non sembra supportare gli argomenti utilizzati in exception_msg(). Sarebbe utile se i valori degli argomenti potessero essere passati alla routine di gestione degli errori.
try(
throw("Error"(1,2));
,
Show (exception_msg());
// Arguments to the thrown "Error" are lost.
);
In conclusione, la gestione degli errori potrebbe essere ulteriormente migliorata. Apprezzerei molto se la gestione degli errori ricevesse questi miglioramenti.
Re: JSL 4.0link: Migliorare e documentare i messaggi di errore
Grazie, l'ho aggiunto come "nuova funzionalità interessante/utile". Lo sposterò in "Game Changer" non appena raggiungerà la top 10.
per la parte relativa alla documentazione, è disponibile l'indice di scripting completo .
Seguendo l'idea della "top ten", la sposto da "cool/utile" a "Game Changer".
più candidati?
Re: JSL 4.0Con quale frequenza utilizzi l'aggregazione Col? Con quale frequenza utilizzi quelle "limitate" con espressioni Se() complicate?
Si prega di dare un'occhiata a È necessario popolare il numero di voci univoche
e vota: Col Median (e altri): aggiungi l'opzione "Dove"
