查找

摘要
· 8 hr 前

Publications des développeurs d'InterSystems, semaine Janvier 12 - 18, 2026, Résumé

Janvier 12 - 18, 2026Week at a GlanceInterSystems Developer Community
公告
· 9 hr 前

Notas de la versión 0.10.5 de IPM

IPM versión 0.10.5 se ha lanzado el 15 de enero de 2026. Esta nueva versión incluye un montón de mejoras y correcciones de errores, así que aseguraos de echarle un vistazo, ya sea directamente desde la página de GitHub o desde el Registro de la Comunidad.

Los cambios más importantes incluyen lo siguiente:

  • Una reescritura de la resolución de dependencias que mejora drásticamente el rendimiento, incluyendo un aumento de velocidad de 200 veces en casos muy complicados.
  • Un registro de historial que realiza el seguimiento de las instalaciones, cargas, actualizaciones y desinstalaciones de IPM, que podéis consultar usando zpm "log" 
  • Las expresiones del sistema, como ${namespace}, y las macros $$$ ahora se evalúan en los archivos de combinación CPF, lo que permite una mayor flexibilidad en la configuración inicial.
  • <Invoke> en module.xml se comporta de forma más intuitiva al comprobar siempre el valor de retorno %Status si y solo si la firma del método declara que se devuelve %Status. Esto significa que se lanzará un error si no se devuelve nada, si el valor devuelto no es un %Status o si no es $$$OK.

Aquí tenéis la lista completa de cambios:

Añadidos

  • #938: Añadida la opción -export-python-deps al comando package
  • #462: El comando repo para la configuración de repositorios ahora admite el modo de entrada secreta por terminal para contraseñas con la opción -password-stdin
  • #935: Se añade un procesador genérico de recursos tarball de JFrog Artifactory para empaquetar artefactos con un paquete y desplegarlos en una ubicación final durante la instalación
  • #950: Añadido soporte para listar paquetes de Python instalados usando list -pythonlist -py and list-installed -python
  • #822: El procesador de recursos CPF ahora admite expresiones del sistema y macros en archivos de combinación CPF
  • #578: Añadida funcionalidad para registrar y mostrar el historial de IPM de instalación, desinstalación, carga y actualización
  • #961: Se añade la creación de un archivo de bloqueo para un módulo usando la opción -create-lockfile durante la instalación
  • #959: En repositorios ORAS, el nombre externo ahora puede usarse indistintamente con el nombre (predeterminado) para instally update; es decir, un módulo publicado con su nombre (predeterminado) puede instalarse usando su nombre externo
  • #951: El comando unpublishomitirá la solicitud de confirmación al usuario si se proporciona la opción-force
  • #1018: Se requiere el nombre del módulo para desinstalar cuando no se utiliza la opción -all

Cambiados

  • #316: Todos los parámetros, excepto el modo desarrollador, incluidos en un comando loadinstall o update se propagarán a las dependencias
  • #885: Cargar siempre las dependencias de forma síncrona y permitir que cada módulo gestione el multihilo según sea necesario para la carga usando multicompile, en lugar de intentar gestionar el multihilo propio de la carga de elementos, lo que provoca contención de bloqueos al evitar el compilador de IRIS
  • #481: Mejora del rendimiento de BuildDependencyGraph realizando lo siguiente:
    • Eliminar la recursión y usar iteración.
    • Eliminar la búsqueda en profundidad y usar únicamente búsqueda en anchura.
    • Mejorar el almacenamiento en caché de los resultados de búsqueda de módulos colapsando las expresiones de búsqueda (reduciendo expresiones que son intersecciones).

Eliminados

  • #938: Eliminada la gestión de la opción secreta NewVersion en %Publish()

Corregidos

  • #943: El comando load, cuando se usa con una URL de repositorio de GitHub, vuelve a aceptar un argumento branch
  • #701: Corregidos comentarios de ayuda engañosos sobre el comando search
  • #958: El comando update ya no falla de forma prematura si se utiliza el nombre externo
  • #970: Corregido error en el procesamiento del comando 'generate' de WebApp
  • #965: FileCopy en un directorio con un Name sin la barra inicial ahora funciona
  • #937: Publicar un módulo con un <WebApplication> que contiene un Path ya no provoca errores
  • #957: Mejorados los mensajes de error para la ejecución de comandos del SO. Ahora, cuando un comando falla, el mensaje de error incluye el comando completo y su código de retorno. También se corrigió la separación de argumentos para el comando attrib de Windows y se eliminó el manejo de errores engañoso para comandos ausentes
  • #789: Corregido error al listar módulos para un repositorio ORAS con un namespace especificado
  • #999, #1000: La instalación de IPM ahora limpia las asignaciones obsoletas usadas en versiones anteriores de IPM
  • #1007: La expresión ${ipmDir}ahora funciona en el <Arg>de un <Invoke>
  • #1015: Corregidos errores en la resolución de dependencias donde * como requisito de versión y rangos que se intersectan no funcionaban correctamente
  • #1036: El comando update ya no propaga el modo desarrollador a las dependencias

Obsoletos

  • #828: La opción CheckStatus para la acción <Invoke>ha quedado obsoleta. El comportamiento predeterminado ahora es comprobar siempre el estado del método si y solo si la firma del método devuelve %Library.Status
  • #885: La opción -synchronous ha quedado obsoleta, ya que cargar las dependencias de forma síncrona ahora es el comportamiento predeterminado

Seguridad

  • Se ha actualizado el paquete urllib3 wheel a la versión 2.6.3

Si tenéis alguna pregunta, sugerencia o error que queráis reportar, no dudéis en comentarlo aquí o en la página de GitHub. (En GitHub, las preguntas y sugerencias deben ir a la página de discusiones, y los errores a la página de issues.)

讨论 (0)1
登录或注册以继续
文章
· 9 hr 前 阅读大约需 1 分钟

Um exemplo de cobertura parcial de código por um teste unitário

A nova versão do InterSystems Testing Manager, que lancei na semana passada, traz a incrível Test Coverage Tool do @Timothy Leavitt para o VS Code e é a minha participação no concurso Developer Tools 2025.

Aqui está uma imagem de prévia mostrando como os testes unitários do projeto IPM ainda não cobrem um recurso que aparentemente permite que um repositório IPM sobrescreva sua ordem de classificação.

 

Observe como a linha 88 é destacada em vermelho como um aviso para o desenvolvedor.

Uma decoração no estilo “indicador de bateria” na visualização do Explorer do VS Code aparece em âmbar porque os testes cobrem apenas 76% das linhas executáveis nos métodos desta classe. Ao passar o mouse sobre o indicador, mais informações são exibidas, e a cobertura de métodos (8 de 9) também é mostrada como um segundo indicador na barra opcional de Test Coverage no editor.

Os limites (thresholds) podem ser configurados no VS Code, assim como as cores, caso o esquema vermelho-âmbar-verde seja difícil de distinguir.

Gostou do que viu? Se você já utiliza o framework InterSystems %UnitTest, experimente por conta própria. Feedback é bem-vindo, assim como votos no consurso antes do encerramento da votação no domingo, 3 de agosto, à meia-noite (horário do leste).

讨论 (0)1
登录或注册以继续
文章
· 10 hr 前 阅读大约需 2 分钟

"Los errores HTTP ocultos" (detrás de IIS)

Enviáis una petición HTTP y recibís un error HTTP, pero con una página de error HTML que no esperabais… ¿qué está pasando? 🤔

Por ejemplo, puede que hayáis intentado LEER un recurso FHIR (por ejemplo, /Patient/123) y recibáis una página de error 404, aunque con otros IDs de Patient sí obtenéis la carga útil del recurso. Es decir, “la página” definitivamente existe… ¿por qué os está devolviendo una página de error 404? 🙄

La respuesta a estas preguntas está relacionada con el comportamiento del servidor web IIS respecto al manejo de errores.

IIS tiene 3 opciones para mostrar errores:

  • Mostrar siempre solo páginas de error personalizadas
  • Mostrar siempre errores detallados del servidor
  • Para solicitudes locales, mostrar errores detallados, pero para solicitudes remotas, mostrar las páginas de error personalizadas

Esta última opción es más segura (que mostrar siempre errores detallados) porque, en ocasiones, los detalles del error podrían exponer información interna que no queréis que usuarios externos vean. Por eso, esta es la configuración por defecto de IIS.

Pero esto significa que si estáis probando contra un servidor remoto, los errores reales estarán ocultos. Por ello, querréis cambiarlo a “Errores detallados” (al menos durante las fases de depuración, teniendo en cuenta el acceso externo y, quizá, limitándolo).

Consultad más detalles sobre esta configuración en un artículo relacionado de IIS (y también podéis ver esta sección relacionada en nuestra documentación que lo explica).

El ejemplo específico de FHIR que mencioné es un caso interesante, ya que un error 404 podría simplemente significar que un recurso FHIR concreto no se encontró (el ID que intentabais leer no está en el repositorio), y no que haya algún problema con el servidor (“página no encontrada”).

Por ejemplo, si podéis ver el error detallado, veríais algo como esto:

Pero sin el error detallado, solo recibiríais una página de error personalizada, así:

Y esto podría ser engañoso, así que tened en cuenta esta configuración de IIS.

讨论 (0)1
登录或注册以继续
摘要
· 14 hr 前

【週間ダイジェスト】 1/12 ~ 1/18 の開発者コミュニティへの投稿

1/12 ~ 1/18Week at a GlanceInterSystems Developer Community