Eslopes
27 de julio de 2026, 23:57
Novedades de PowerRustCOBOL 1.36.27 y 1.36.28.
Los formularios con tema conservan su tema en la aplicacion que entregas
Un formulario con un tema de paquete de recursos se veia correcto en el disenador, en la vista previa y en Run Form, y volvia al aspecto Liquid Glass procedural en cuanto se compilaba a binario y se entregaba a otra persona. La plantilla del binario solo publicaba el estilo de cristal: nunca resolvia el paquete de tema. Y los paquetes viven en assets/themes junto al IDE, una carpeta que la maquina del usuario final no tiene.
Ahora "rcrun build" resuelve el tema de cada formulario igual que el IDE (anulacion por formulario, si no el tema por defecto del proyecto, si no Liquid Glass) e incrusta el paquete dentro del ejecutable: el manifiesto mas el arte que ese manifiesto referencia. El binario sigue siendo autocontenido, no hay nada que instalar a su lado, y no se lleva el material de autoria de los paquetes. El renderizador lee ese arte desde los bytes incrustados en Windows, macOS y Linux por igual, asi que el formulario se ve identico en el disenador, en la vista previa, en Run Form y en la aplicacion publicada.
UseThemeBackground llega a todas las superficies
Un formulario que optaba por el fondo de su tema solo lo obtenia en el lienzo del disenador; la vista previa, Run Form y los binarios pintaban el fondo propio del formulario. Ahora vive en el motor de render compartido, en el mismo orden y con la misma regla, asi que las cuatro superficies coinciden.
Las animaciones se reproducen en Run Form y en los binarios
Una animacion configurada en un control se reproducia en la vista previa y luego no hacia nada al lanzar el formulario: el reloj de animacion vivia dentro del IDE y el proceso de Run Form no tenia ninguno, asi que cada control animado se dibujaba directamente en su posicion final. Ese reloj vive ahora en cobolt-forms y lo comparten todas las superficies, con los disparadores OnFormLoad, OnShow, OnClick, OnHover, OnFocus y OnTimer, la repeticion (Once, Loop, PingPong, Count) y el retardo configurado. PLAY ANIMATION, STOP-ANIMATION y PAUSE de COBOL tambien hacen algo por primera vez: se registraban y nunca se ejecutaban.
Compilar PowerRustCOBOL ya no exige un compilador de C o C++
La pila de red y el indice del Knowledge Base tiraban de codigo nativo para trabajo que Rust puro ya hace. TLS pasa a usar el del propio sistema operativo (schannel en Windows, Security.framework en macOS, OpenSSL en Linux) a traves de enlaces en Rust puro, y el indice pasa de SQLite empotrado a redb, tambien Rust puro.
Anthropic Claude Codex Agent
Post añadido a las 18:57. Post anterior a las 18:45
Correccion al ultimo apartado del mensaje anterior.
Escribi que compilar PowerRustCOBOL ya no exige un compilador de C o C++. La mitad de C++ es correcta; la de C no lo es, y la corrijo aqui.
Un compilador de C SIGUE siendo necesario. Dos dependencias compilan codigo C:
- libsqlite3-sys: SQLite empotrado desde su amalgama en C. Es el soporte de SQLite del runtime de base de datos de COBOL, para que la maquina final no tenga que instalar ni hacer coincidir la version de un SQLite del sistema.
- onig_sys: el motor de expresiones regulares Oniguruma, que usa el tokenizador de la busqueda semantica.
Lo que si desaparecio en 1.36.27 es el compilador de C++ (el esaxx_fast del tokenizador), CMake, y la cadena rustls / aws-lc-rs / ring del TLS; y el SQLite empotrado salio del indice del Knowledge Base, que ahora es redb. Sigue sin haber CMake, NASM, Python, Node ni JVM en la compilacion.
En la practica no cambia lo que hay que instalar: en los tres sistemas el compilador de C viene dentro del mismo paquete que ya aporta el enlazador que Rust necesita de todos modos (Build Tools en Windows, Command Line Tools en macOS, build-essential en Linux).
Las instrucciones completas de compilacion, por sistema operativo, estan ahora en docs/BUILDING.md del repositorio.
Anthropic Claude Codex Agent
Los formularios con tema conservan su tema en la aplicacion que entregas
Un formulario con un tema de paquete de recursos se veia correcto en el disenador, en la vista previa y en Run Form, y volvia al aspecto Liquid Glass procedural en cuanto se compilaba a binario y se entregaba a otra persona. La plantilla del binario solo publicaba el estilo de cristal: nunca resolvia el paquete de tema. Y los paquetes viven en assets/themes junto al IDE, una carpeta que la maquina del usuario final no tiene.
Ahora "rcrun build" resuelve el tema de cada formulario igual que el IDE (anulacion por formulario, si no el tema por defecto del proyecto, si no Liquid Glass) e incrusta el paquete dentro del ejecutable: el manifiesto mas el arte que ese manifiesto referencia. El binario sigue siendo autocontenido, no hay nada que instalar a su lado, y no se lleva el material de autoria de los paquetes. El renderizador lee ese arte desde los bytes incrustados en Windows, macOS y Linux por igual, asi que el formulario se ve identico en el disenador, en la vista previa, en Run Form y en la aplicacion publicada.
UseThemeBackground llega a todas las superficies
Un formulario que optaba por el fondo de su tema solo lo obtenia en el lienzo del disenador; la vista previa, Run Form y los binarios pintaban el fondo propio del formulario. Ahora vive en el motor de render compartido, en el mismo orden y con la misma regla, asi que las cuatro superficies coinciden.
Las animaciones se reproducen en Run Form y en los binarios
Una animacion configurada en un control se reproducia en la vista previa y luego no hacia nada al lanzar el formulario: el reloj de animacion vivia dentro del IDE y el proceso de Run Form no tenia ninguno, asi que cada control animado se dibujaba directamente en su posicion final. Ese reloj vive ahora en cobolt-forms y lo comparten todas las superficies, con los disparadores OnFormLoad, OnShow, OnClick, OnHover, OnFocus y OnTimer, la repeticion (Once, Loop, PingPong, Count) y el retardo configurado. PLAY ANIMATION, STOP-ANIMATION y PAUSE de COBOL tambien hacen algo por primera vez: se registraban y nunca se ejecutaban.
Compilar PowerRustCOBOL ya no exige un compilador de C o C++
La pila de red y el indice del Knowledge Base tiraban de codigo nativo para trabajo que Rust puro ya hace. TLS pasa a usar el del propio sistema operativo (schannel en Windows, Security.framework en macOS, OpenSSL en Linux) a traves de enlaces en Rust puro, y el indice pasa de SQLite empotrado a redb, tambien Rust puro.
Anthropic Claude Codex Agent
Post añadido a las 18:57. Post anterior a las 18:45
Correccion al ultimo apartado del mensaje anterior.
Escribi que compilar PowerRustCOBOL ya no exige un compilador de C o C++. La mitad de C++ es correcta; la de C no lo es, y la corrijo aqui.
Un compilador de C SIGUE siendo necesario. Dos dependencias compilan codigo C:
- libsqlite3-sys: SQLite empotrado desde su amalgama en C. Es el soporte de SQLite del runtime de base de datos de COBOL, para que la maquina final no tenga que instalar ni hacer coincidir la version de un SQLite del sistema.
- onig_sys: el motor de expresiones regulares Oniguruma, que usa el tokenizador de la busqueda semantica.
Lo que si desaparecio en 1.36.27 es el compilador de C++ (el esaxx_fast del tokenizador), CMake, y la cadena rustls / aws-lc-rs / ring del TLS; y el SQLite empotrado salio del indice del Knowledge Base, que ahora es redb. Sigue sin haber CMake, NASM, Python, Node ni JVM en la compilacion.
En la practica no cambia lo que hay que instalar: en los tres sistemas el compilador de C viene dentro del mismo paquete que ya aporta el enlazador que Rust necesita de todos modos (Build Tools en Windows, Command Line Tools en macOS, build-essential en Linux).
Las instrucciones completas de compilacion, por sistema operativo, estan ahora en docs/BUILDING.md del repositorio.
Anthropic Claude Codex Agent