JSL 4.0Wäre es sinnvoll, die Scripters Club-Plattform zu nutzen, um neue und zukünftige Erweiterungen für JSL zu diskutieren? Ziel wäre es, Ideen zu strukturieren, über neue Funktionen zu informieren und zukünftige Verbesserungen anzukündigen.
Spielveränderer:
Coole/hilfreiche neue Funktionen:
Schön zu haben:
Betreff: JSL 4.0Ich weiß nicht, ob mehrere Benutzer Schreibzugriff auf die Liste im Hauptbeitrag erhalten können?
Welche Verbesserungen in JMP19 gefallen Ihnen am besten?
Was fehlt?
Welche Ansätze können als bahnbrechend betrachtet werden?
Betreff: JSL 4.0Hallo Hogi, gibt es von JMP eine Zusammenfassung der neuen JSL-Funktionen für JMP 19? Ich habe noch keine Dokumentation gelesen, sondern teste gerade Version 19.0.01 im Vergleich zu meinen vorherigen Installationen (17.2 und 18.2).
Im Add-in-Builder:
In den letzten zehn Jahren habe ich einige Add-in-Toolbars entwickelt, die größtenteils benutzerdefinierte Symbole (JPGs usw.) auf einem Netzlaufwerk speicherten. Aufgrund meiner Programmierung und Konfiguration lud JMP diese Symbole jedes Mal neu, wenn ein JMP-Fenster geöffnet wurde, da JMP die Toolbars anzeigen musste. Als ich die Ursache des Problems erkannte (es waren mittlerweile etwa 40 Skripte), konnte das Öffnen eines JMP-Fensters mehrere Sekunden dauern. Das Problem trat so schleichend auf, weil ich nach dem ersten Jahr nur noch gelegentlich neue Skripte hinzufügte.
JMP 19 verfügt nun über einen neuen Add-in-Builder, der die JSL- und Symboldateien automatisch in das Add-in einbindet. Bei der Installation werden die JSL-Dateien und die Symbolbilder in den lokalen Benutzerordner kopiert. Ich habe es so eingerichtet, dass JMP-Benutzer (ab Version 19) automatisch erkennen, wenn ihre JMP-Installation eine Aktualisierung der Serverdatei `.jmpaddin` erkennt. Beim Neustart von JMP werden sie dann zur Installation des Updates aufgefordert. Der Prozess unterscheidet sich etwas von meiner alten Methode, war aber die perfekte Lösung zum perfekten Zeitpunkt. Ich habe die Ursache erst in den letzten Monaten entdeckt. Daher war es für mich sehr hilfreich, aber ich vermute, mein Fall ist eher selten. Vielleicht aber nicht so selten in diesem Forum. Vielen Dank an das JMP-Supportteam und die Entwickler für die Unterstützung bei der Behebung des Problems.
Danke,
Mikrofon
Betreff: JSL 4.0Meines Wissens gibt es keine Versionshinweise („mit allen Details“).
Nur ein allgemeiner Überblick: JMP – Neue Funktionen und Versionshinweise
und diese Seite mit Informationen zu Sicherheitsupdates: https://www.jmp.com/en/company/trust-center
Deshalb dachte ich, es wäre hilfreich, hier einen kurzen Überblick zu geben.
Kommentare und Links zu weiteren Funktionen sind willkommen.
Betreff: JSL 4.0Add-Ins -
Neben dem standardmäßigen „Add-In Builder“, der in JMP enthalten ist, kann (und SOLLTE!!!) man verwenden
Add-In-Manager @Justin_Chilton -> jetzt über den Marketplace: Add-In-Manager
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-Chilton/ev-p/887937
Neu in JMP19: die Aktualisierungsprüfung, die direkt in JMP integriert ist.
In früheren Versionen konnte eine ähnliche Funktionalität über UpdateCheck.jsl (aus dem Add-In-Manager) eingerichtet werden.
Hat jemand die Geschwindigkeit der beiden Anfahrtswege verglichen?
z. B. 40 Add-In-Update-Prüfungen über UpdateCheck im Vergleich zur neuen Funktionalität?
Vergleicht die neue Funktion das Dateidatum oder den Inhalt?
Übrigens: @mikedriscoll
Ein interessantes Konzept, sehr ähnlich Ihrem vorherigen:
Strategien für das Management von Unternehmens-Add-Ins (2025-US-30MP-2576) @MikeD_Anderson
Der wesentliche Unterschied des vorgeschlagenen Konzepts:
Der Ordner mit der "aktuellen" Version der Skripte (und Symbole?) wird auf einem OneDrive/SharePoint gespeichert und ist über einen synchronisierten Ordner auf dem lokalen System verfügbar.
Betreff: JSL 4.0Ich habe mein eigenes Update-Skript basierend auf Justins ursprünglichen Update-Funktionen erstellt und es noch nicht direkt mit den neuen Methoden in Version 19 verglichen. Ich würde sagen, dass es mit den JMP-Methoden schneller sein könnte, da diese den Quellordner nach einer aktualisierten Datei durchsuchen, während Justins Methoden (zumindest die von mir verwendeten) je nach Speicherort der Metadaten-Masterdateien verzögert sein können. Die wenigen Male, die ich von JMP aufgefordert wurde, ein Add-in in JMP 19 zu aktualisieren, fühlte es sich genauso schnell an wie meine bisherige Implementierung.
Da die neuen Methoden in Version 19 scheinbar im Wesentlichen nach neuen Dateien an einem bestimmten Ort suchen und nicht an Metadaten zum Build-Datum gebunden sind, gefällt mir dieser Ansatz zwar grundsätzlich, aber es gibt keine wirkliche Kontrolle darüber, was als „Quellordner“ gilt. Wenn ich beispielsweise ein Add-in aus meinem Download-Ordner hineinziehe und gefragt werde, ob ich nach Updates suchen möchte, wird der Download-Ordner als zu prüfende Quelle angegeben. Außerdem wird nicht zwischen Produktions- und Testversionen eines Add-ins unterschieden, und der „Quellordner“ könnte falsch sein, wenn ein Benutzer nach Updates sucht, es sich aber um eine Testversion handelt, die von einem anderen Ort installiert wurde.
Ich habe hier darum gebeten, dass wir diese Punkte kodifizieren dürfen (hauptsächlich für diesen Thread, da wir uns kurz über den anderen Punkt auf der Wunschliste unterhalten haben).
Betreff: JSL 4.0@nathan-clark Soweit ich das mit dem Add-in-Builder von JMP19 sehe, ist es nicht ganz so. Leider fehlt mir momentan die Zeit, meine Erfahrungen ausführlich zu dokumentieren, aber ich möchte kurz zusammenfassen, was ich bisher herausgefunden habe. Ich bin allerdings kein Experte. Mein Ziel war es, meine alte Version mit dem gemeinsamen Laufwerk in einem anderen Bereich mithilfe der JMP19-Methode vollständig nachzubilden.
Erstellen Sie ein Add-In über Datei->Neu->Hinzufügen.
Richten Sie das Add-In ein, indem Sie Ihre Skripte/Symbole hinzufügen. Meine befinden sich auf einem Netzlaufwerk.
Lassen Sie die Dateien automatisch aktualisieren (im Reiter „Dateien einbeziehen“) und prüfen Sie beim Start von JMP im Reiter „Allgemein“ auf Aktualisierungen.
Speichern Sie die Datei unter einem neuen Namen, um eine neue .jmpaddin-Datei an einem leicht zugänglichen Ort zu erstellen. Lassen Sie sie dort, damit andere Benutzer sie von diesem Ort aus installieren können.
Andere JMP-Benutzer installieren von diesem Speicherort, und ihre JMP-Version überprüft diesen Speicherort auf Änderungen.
Um Dateien zu bearbeiten, öffnen Sie den Add-In-Builder bzw. die JMPaddin-Datei, sodass der Add-In-Editor sichtbar ist. Nehmen Sie dann die gewünschten Änderungen am Skript vor. Anschließend sollte die Schaltfläche „Speichern“ im Add-In-Builder erscheinen. Alternativ können Sie „Speichern unter“ verwenden und das Add-In unter demselben Namen speichern. Wenn Sie lediglich eine aktualisierte Skriptdatei einfügen oder die JSL-Datei bearbeiten und schließen und später den Add-In-Builder öffnen, wird die Speicheroption nicht angezeigt. Dieser Fehler wurde dem Entwickler bereits gemeldet.
JMP-Nutzer älterer Versionen müssen das Add-in aktualisieren, indem sie die .jmpaddin-Datei neu installieren. JMP19-Nutzer werden zur Aktualisierung aufgefordert, sofern sie das Add-in vom selben Speicherort installiert haben. Ich weiß nicht, was passiert, wenn wir die .jmpaddin-Datei per E-Mail versenden … vermutlich weiß JMP dann nicht, wo es später nach Updates suchen soll.
Betreff: JSL 4.0Das leuchtet ein, @mikedriscoll . Leider basiert das auf der JMP-Implementierung der Add-in-Erstellung. Ich habe viel zu viele Add-ins dafür, und da wir sie jetzt alle über GitHub verwalten, sind diese Methoden nicht skalierbar. Deshalb habe ich die Kodifizierung der Details in der addin.def-Datei angefragt.
Ich denke, JMP19 macht gute Fortschritte im Bereich Add-In-Management, aber langfristig müssen mehr Optionen für die unterschiedlichen Anwendungsbereiche von Nutzern und Organisationen bereitgestellt werden. Mit einigen Updates von JMP kann ich meiner Meinung nach Teile meiner aktuellen Add-In-Update-Infrastruktur nach und nach ablösen.
Betreff: JSL 4.0Unabhängig davon, ob es einem gefällt oder nicht, ist es bedauerlich, dass die Reaktionsgeschwindigkeit beim Anklicken etwas langsamer ist als in der Vorgängerversion 18. Natürlich hängt das von der PC-Spezifikation ab, aber ich denke, es gibt einen deutlichen Unterschied in der Reaktionsgeschwindigkeit.
Betreff: JSL 4.0Ich sehe auch, dass einige Dinge in JMP 19 im Hinblick auf Add-Ins einfacher werden könnten.
Diese Art der Entwicklung meiner Add-Ins gefällt mir am besten:
- in einem entpackten Ordner im Ordner „Eigene Dokumente“
- Zur Installation öffne ich die .def-Datei in JMP.
- Ich bearbeite die .jmpcust-Datei in einem Texteditor (das ist etwas knifflig, funktioniert aber perfekt für mich, da ich nur sehr wenige Änderungen vornehmen muss).
- Die Menüpunkte beziehen sich auf Skripte in diesem Ordner
- Ich kann die Skripte in diesem Ordner direkt testen/bearbeiten (was ich als großen Vorteil empfinde, da ich das Kopieren und Aktualisieren der Dateien in .jmpaddin über das Menü als ziemlich mühsam, unnötig und fehleranfällig empfinde).
- Für die Bereitstellung verwende ich ein kleines PowerShell-Skript, das das Add-In packt und es an einen gemeinsamen Speicherort für andere Benutzer verschiebt (und nebenbei eine Kopie der älteren Version erstellt, damit bei Problemen ein Rollback durchgeführt werden kann).
Betreff: JSL 4.0Ja, ich würde zukünftige Erweiterungen usw. gerne im Scripters Club diskutieren. Dieses Thema könnte Teil davon sein, sollte aber nicht das einzige sein. Danke für den Vorschlag.
Betreff: JSL 4.0@hogi Eine verbesserte Fehlerbehandlung, wie ich sie in einem Wunschlisteneintrag vorgeschlagen habe, wäre ein echter Durchbruch. Die Fehlerbehandlung ist zumindest in Version 17.1 weder eindeutig noch gut dokumentiert. Aktuell (und ich glaube auch in Version 18.2) scheinen zwei verschiedene Fehlermeldungen in `exception_msg()` verfügbar zu sein, die weder im Skriptindex noch in der übrigen Dokumentation beschrieben sind.
Die Fehlermeldung sollte sprachunabhängig sein, um sie in der Fehlerbehandlung prüfen zu können, oder einen eindeutigen Fehlercode enthalten, der in einer Fehlerroutine überprüft werden kann. Dies könnte wie folgt aussehen:
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>
Die Funktion „Open“ gibt aktuell eine Fehlermeldung als Listeneintrag mit zusätzlichen Argumenten zurück:
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"))};
);
Keines dieser Argumente ist irgendwo dokumentiert, oder ich habe es bisher nicht gefunden.
Meiner Meinung nach wäre es wünschenswert, ein Fehlerobjekt (im Klassenformat) zurückzugeben, das alle Informationen über den Fehler enthält, z. B.:
try(
<ACTION>
<BR /> ,
<BR /> if (exception() << code == exception.FILENOTFOUND,
<BR /> Print( exception() << message );
<BR /> ...
</ACTION>
Dann gibt es noch die `throw`-Funktion, die zwar praktisch ist, aber die in `exception_msg()` verwendeten Argumente scheinbar nicht unterstützt. Es wäre wünschenswert, wenn beliebige Argumentwerte an die Fehlerbehandlungsroutine übergeben werden könnten.
try(
throw("Error"(1,2));
,
Show (exception_msg());
// Arguments to the thrown "Error" are lost.
);
Abschließend lässt sich sagen, dass die Fehlerbehandlung noch verbessert werden könnte. Ich würde es begrüßen, wenn diese Verbesserungen umgesetzt würden.
Betreff: JSL 4.0Link: Fehlermeldungen verbessern und dokumentieren
Danke, ich habe es als "coole/hilfreiche neue Funktion" hinzugefügt – ich werde es in die Kategorie "Game Changer" verschieben, sobald es die Top 10 erreicht.
Für den Dokumentationsteil gibt es einen umfassenden Skriptindex .
In Anlehnung an die Idee der „Top Ten“ stufe ich die Kategorie von „cool/hilfreich“ zu „bahnbrechend“ hoch.
Weitere Kandidaten?
Betreff: JSL 4.0Wie häufig verwenden Sie die Spaltenaggregation – wie oft die „eingeschränkten“ Aggregationen mit komplizierten If()- Ausdrücken?
Bitte beachten Sie den Abschnitt „Anzahl eindeutiger Einträge muss angegeben werden“.
und abstimmen: Col Median (und andere): Option „Wo“ hinzufügen
