JSL 4.0¿Tiene sentido usar la plataforma Scripters Club para debatir sobre las mejoras nuevas y futuras de JSL? El objetivo sería organizar ideas, informar sobre las nuevas funciones y anunciar futuras mejoras.
Cambiadores de juego:
Nuevas funciones interesantes y útiles:
Es bueno tener:
Re: JSL 4.0No sé si varios usuarios pueden tener acceso de escritura a la lista en la publicación principal.
¿Qué mejoras de JMP19 te gustan más?
¿Qué falta?
¿Qué enfoques pueden considerarse "revolucionarios"?
Re: JSL 4.0Hola Hogi, ¿JMP ofrece algún resumen que destaque las nuevas características de JSL para JMP19? Todavía no he leído la documentación, sigo explorando y probando la versión 19.0.01 comparándola con mis instalaciones anteriores (17.2 y 18.2).
En el creador de complementos:
Durante los últimos 10 años, desarrollé varias barras de herramientas complementarias con iconos personalizados (jpg, etc.) almacenados en una unidad de red. Debido a la forma en que las programé y configuré, JMP descargaba todos esos iconos cada vez que se abría una ventana, ya que necesitaba mostrar las barras de herramientas. Cuando me di cuenta del problema (con alrededor de 40 scripts), abrir una ventana de JMP podía tardar varios segundos. El problema se fue agravando gradualmente porque, después del primer año, solo añadía un nuevo script de vez en cuando.
Ahora, JMP19 tiene un nuevo creador de complementos que incluye automáticamente los archivos JSL y de iconos como parte del complemento. Así, cuando un usuario lo instala, las imágenes JSL y de iconos se copian a su carpeta de inicio local. Sin embargo, lo he configurado para que los usuarios de JMP (en la versión 19 o superior) detecten automáticamente que el complemento se ha actualizado cuando su instalación de JMP detecte una actualización en el archivo .jmpaddin del servidor, y se les solicitará que instalen la actualización al reiniciar JMP. El proceso es un poco diferente a mi método anterior, pero fue la solución perfecta en el momento perfecto... Descubrí la causa raíz hace un par de meses. Así que me fue muy útil, pero sospecho que mi caso es bastante inusual. Aunque quizás no tanto en este foro. Gracias al equipo de soporte de JMP y a los desarrolladores por ayudarme con la solución.
Gracias,
Micro
Re: JSL 4.0Que yo sepa, no hay notas de lanzamiento ("con todos los detalles").
Descripción general: Nuevas funciones y notas de la versión de JMP
y esta página con información sobre actualizaciones de seguridad: https://www.jmp.com/en/company/trust-center
Por eso pensé que sería útil ofrecer aquí una breve descripción general.
Cualquier comentario o enlace a funciones adicionales es bienvenido.
Re: JSL 4.0Complementos -
Además del "Creador de complementos" estándar que se incluye en JMP, se puede (¡DEBERÍA!) usar
Administrador de complementos @Justin_Chilton -> ahora disponible en el Marketplace: Administrador de complementos
https://community.jmp.com/t5/Learn-JMP-Events/Scripters-Club-Managing-Your-JMP-Add-Ins-with-Justin-Chilton/ev-p/887937
Novedad en JMP19: la comprobación de actualizaciones, que se incluye directamente en JMP.
En versiones anteriores, se podía configurar una funcionalidad similar a través de UpdateCheck.jsl (desde el Administrador de complementos).
¿Alguien comparó la velocidad de ambos métodos?
Por ejemplo, ¿para 40 comprobaciones de actualización de complementos mediante UpdateCheck frente a la nueva funcionalidad?
¿La nueva función compara la fecha del archivo o algún contenido?
Por cierto: @mikedriscoll
Un concepto interesante, muy similar al anterior:
Estrategias de gestión de complementos empresariales (2025-US-30MP-2576) @MikeD_Anderson
La diferencia importante del concepto propuesto:
La carpeta con la versión "actual" de los scripts (¿e iconos?) se almacena en OneDrive/SharePoint y está disponible en el sistema local a través de una carpeta sincronizada.
Re: JSL 4.0Creé mi propio script de actualización basado en el que Justin incluyó originalmente, pero no lo he comparado directamente con los nuevos métodos de la versión 19. Diría que puede ser más rápido con los métodos de JMP, ya que buscan el archivo actualizado en una carpeta de origen, mientras que los métodos de Justin (al menos los que yo uso) pueden presentar retrasos dependiendo de la ubicación de los archivos maestros de metadatos. En las pocas ocasiones en que JMP me ha solicitado actualizar un complemento en la versión 19, la velocidad es similar a la de mi implementación anterior.
Dado que los nuevos métodos de la versión 19 parecen buscar archivos nuevos en una ubicación sin estar vinculados a metadatos de fecha de compilación, si bien me gusta este enfoque en general, no hay un control real sobre qué constituye una "carpeta de origen". Por ejemplo, si arrastro un complemento desde mi carpeta de descargas y me pregunta si quiero buscar actualizaciones, mostrará la carpeta de descargas como la fuente de búsqueda. Además, no distingue entre versiones de producción y de prueba de un complemento, y la carpeta de "origen" podría ser incorrecta si un usuario busca actualizaciones, pero se trata de una versión de prueba instalada desde una ubicación diferente.
He solicitado aquí que se nos permita codificar estas piezas (principalmente para este hilo, ya que hablamos brevemente sobre el otro punto de la lista de deseos).
Re: JSL 4.0@nathan-clark Por lo que veo en el creador de complementos de JMP19, no es exactamente así. Desafortunadamente, no tengo tiempo ahora mismo para documentar mi experiencia por completo, pero resumiré lo que he observado. No soy un experto. Mi objetivo era replicar por completo mi antigua versión de la unidad compartida, pero en una ubicación diferente, utilizando el método de JMP19.
Crea un complemento usando Archivo->Nuevo->Complemento.
Configura el complemento añadiendo tus scripts/iconos. En mi caso, están en una unidad compartida.
Configúrelo para que actualice automáticamente los archivos (en la pestaña "Archivos incluidos") y compruebe si hay actualizaciones cuando se inicie JMP en la pestaña "General".
Guarda el archivo para crear una nueva carpeta .jmpaddin en una ubicación accesible. Déjala ahí y permite que otros instalen desde esa ubicación.
Otros usuarios de JMP instalarán desde esa ubicación y su versión de JMP comprobará esa ubicación para detectar cambios.
Para editar cualquier archivo, abra el editor de complementos (archivo jmpaddin) y realice los cambios necesarios en el script. El botón "Guardar" debería aparecer visible en el editor de complementos. También puede usar la opción "Guardar como" y guardar el complemento con el mismo nombre. Si simplemente arrastra un archivo de script actualizado o edita el archivo JSL y lo cierra, y luego abre el editor de complementos, no verá la opción de guardar. Este error ya se ha reportado al desarrollador.
Los usuarios de JMP con versiones anteriores deberán actualizar el complemento reinstalando el archivo .jmpaddin. Los usuarios de JMP19 recibirán una notificación para actualizar el complemento si lo instalaron desde la misma ubicación. Desconozco qué ocurriría si enviamos el archivo .jmpaddin por correo electrónico; presumiblemente, JMP no sabría dónde buscar actualizaciones posteriormente.
Re: JSL 4.0Tiene sentido, @mikedriscoll . Desafortunadamente, eso depende de la implementación de JMP para la creación de complementos. Tengo demasiados complementos para eso y, ahora que los gestionamos todos a través de GitHub, esos métodos no son escalables, por lo que solicité que se codificaran los detalles en el archivo addin.def.
Creo que JMP19 está logrando avances importantes en la gestión de complementos, pero a largo plazo se necesitan más opciones para la escala que manejan las distintas personas y organizaciones. Con algunas actualizaciones de JMP, creo que podré empezar a descontinuar parte de mi infraestructura actual de actualización de complementos.
Re: JSL 4.0Te guste o no, es una pena que la velocidad de respuesta al hacer clic sea un poco más lenta que en la versión anterior (la 18). Claro que depende de las especificaciones del ordenador, pero creo que hay una diferencia clara en la velocidad de respuesta.
Re: JSL 4.0También veo que algunas cosas pueden resultar más fáciles en JMP 19 con respecto a los complementos.
Esta es la forma en que más me gusta desarrollar mis complementos:
- en una carpeta descomprimida en mi carpeta de documentos
- Para instalarlo, abro el archivo .def en JMP.
- Edito el archivo .jmpcust en un editor de texto (esto es un poco complicado, pero me funciona perfectamente, ya que no es necesario hacerlo para la mayoría de los cambios).
- Los elementos del menú hacen referencia a los scripts de esta carpeta.
- Puedo probar/editar los scripts directamente en esta carpeta (lo cual me parece una gran ventaja, ya que copiar y actualizar los archivos en .jmpaddin a través del menú me resulta bastante tedioso, innecesario y propenso a errores).
- Para la implementación, tengo un pequeño script de PowerShell que empaqueta el complemento y lo mueve a una ubicación compartida para otros usuarios (y, por cierto, crea una copia de la versión anterior para que se pueda realizar una reversión si surgen problemas).
Re: JSL 4.0Sí, me gustaría hablar sobre futuras mejoras, etc., en el club de Scripters; es decir, este tema podría formar parte del mismo, pero no debería ser el único. Gracias por la sugerencia.
Re: JSL 4.0@hogi Sería revolucionario si hubiera una mejor gestión de errores, como propuse en una entrada de la lista de deseos . La gestión de errores, al menos en la versión 17.1, no es única ni está bien documentada. Actualmente (y creo que también en la 18.2), parece haber dos tipos diferentes de mensajes de error disponibles en exception_msg(), que tampoco están documentados en el Índice de Scripting ni en ninguna otra documentación.
El mensaje de error también debe ser independiente del lenguaje para su verificación en la gestión de errores, o debe tener un código de error único que pueda verificarse en una rutina de errores. Esto podría verse así:
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 función Abrir actualmente devuelve un mensaje de error como una entrada de lista con argumentos adicionales:
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"))};
);
Ninguno de estos argumentos está documentado en ninguna parte o aún no lo he encontrado.
En mi opinión, sería bueno tener un objeto de error (en un formato de clase) que contenga toda la información sobre el error, por ejemplo:
try(
<ACTION>
<BR /> ,
<BR /> if (exception() << code == exception.FILENOTFOUND,
<BR /> Print( exception() << message );
<BR /> ...
</ACTION>
Luego está la función throw, que es útil, pero no parece admitir los argumentos utilizados en exception_msg(). Sería útil que los valores de los argumentos se pudieran transferir a la rutina de gestión de errores.
try(
throw("Error"(1,2));
,
Show (exception_msg());
// Arguments to the thrown "Error" are lost.
);
En conclusión, la gestión de errores podría mejorarse. Agradecería que se implementaran estas mejoras.
Re: JSL 4.0Enlace: Mejorar y documentar los mensajes de error
Gracias, lo agregué como "nueva característica interesante y útil"; lo moveré a "Cambio de juego" una vez que llegue al top 10.
Para la parte de documentación, hay un índice de scripts completo .
Siguiendo la idea del "top ten", la paso de "interesante/útil" a "cambiador de juego".
¿Más candidatos?
Re: JSL 4.0¿Con qué frecuencia utiliza la agregación Col? ¿Con qué frecuencia utiliza las "restringidas" con expresiones Si() complicadas?
Por favor, eche un vistazo a Es necesario completar el número de entradas únicas
y votar: Col Median (y otros): agregar opción "Dónde"
