GNU Octave llega a JupyterLite: computación en cualquier momento y lugar

 (blog.jupyter.org)
3 puntos por GN⁺ 2025-10-21 | 1 comentarios | Compartir por WhatsApp
  • Xeus-Octave se incorpora al ecosistema de kernels de JupyterLite, lo que permite ejecutar código de GNU Octave directamente en el navegador
  • GNU Octave es un lenguaje open source de cómputo científico compatible con Matlab, y este proyecto lo adapta para ejecutarse en un entorno WebAssembly (WASM)
  • Para resolver problemas con código basado en Fortran y las dependencias de BLAS/LAPACK, se utilizó una cadena de herramientas personalizada que combina LLVM Flang, Emscripten y Netlib LAPACK
  • Como LLVM todavía no soporta símbolos comunes de Fortran (Common Block), se aplicó una solución provisional con parches, con soporte oficial previsto para LLVM 22
  • Con esto, JupyterLite amplía su soporte de R a Octave, marcando un paso importante en la expansión del ecosistema de programación científica basado en navegador

Resumen de Xeus-Octave y la adaptación a WebAssembly

  • Xeus-Octave es un kernel de Jupyter que permite ejecutar código GNU Octave en el navegador, empaquetado mediante emscripten-forge
    • GNU Octave es un lenguaje gratuito y de código abierto capaz de ejecutar directamente scripts de Matlab
    • Con esta integración, puede usarse de inmediato en JupyterLite sin instalación adicional
  • De forma similar al proyecto previo Xeus-R-Lite, utiliza una cadena de herramientas para compilar código Fortran (LLVM Flang + Emscripten)
  • Como biblioteca de dependencias para operaciones matemáticas de Octave, se eligió Netlib LAPACK en lugar de OpenBLAS, mejorando la compatibilidad de compilación

Retos técnicos del proceso de compilación para WebAssembly

  • Se produjeron errores de compilación en LLVM debido al problema de soporte para bloques comunes de Fortran (Common Symbol Block)
    • El streamer Wasm de LLVM v20 no implementa símbolos comunes, por lo que fue necesario modificar el código
    • Gracias a la colaboración entre el equipo de QuantStack y Serge Guelton, se aplicó un parche provisional a LLVM para tratarlos como símbolos débiles (weak symbol)
  • El soporte oficial se incluirá en el lanzamiento de LLVM v22, y la versión parcheada actual de LLVM está publicada para Linux
  • Octave también recibió ajustes para el objetivo WASM, como la desactivación de funciones GUI y la unificación de firmas de funciones Fortran

Integración y demostración de Xeus-Octave

  • Tras completar la compilación, basta con añadir la receta de emscripten-forge para ejecutar Xeus-Octave en JupyterLite
  • Xeus-Octave está construido sobre Xeus, un framework de kernels de Jupyter basado en C++, lo que permite ejecutar y visualizar comandos de Octave en el navegador

Próximos pasos

  • Como siguiente etapa, se planea integrar el ecosistema de paquetes de Octave en conda-forge y emscripten-forge
    • Se prevé ajustar la utilidad pkg de Octave para el entorno del navegador y así definir el proceso de instalación dentro de un entorno conda
  • Esto fortalecerá aún más el entorno de programación científica y matemática basado en navegador

Principales contribuidores y contexto

  • La desarrolladora principal Isabel Paredes, de QuantStack, estuvo antes a cargo de la adaptación a WebAssembly del lenguaje R y del framework ROS
  • Emscripten-forge es liderado por Thorsten Beier, con la participación de varios contribuidores como Anutosh Bhat y Martin Renou
  • JupyterLite es mantenido principalmente por Jeremy Tuloup, y Xeus por Johan Mabille
  • Xeus-Octave fue desarrollado por Giulio Girardi y Antoine Prouvost

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-21
Comentarios de Hacker News
  • Para quien nunca haya oído hablar de Octave, Octave es una casi-réplica de código abierto del software comercial MATLAB. Más detalles en Wikipedia
    • La expresión "casi réplica" es un poco exagerada; me gusta el software de código abierto, pero para trabajos más avanzados siento que Octave todavía no alcanza por completo a MATLAB. Ver diferencias entre Octave y MATLAB
    • En los primeros MOOC de machine learning del profesor Andrew Ng se usaba Octave, así que es útil si buscas materiales prácticos y ejemplos. Playlist de YouTube
    • Hace 15 años, cuando estaba en la licenciatura, usé Octave en lugar de MATLAB en una materia de análisis numérico, y para lo que hacíamos en ese momento la compatibilidad del lenguaje encajaba perfectamente
    • No soy usuario de MATLAB, pero se nota que no basta con replicar el lenguaje para cubrir todo MATLAB; MATLAB es una suite de software basada en GUI e incluye muchas apps que se pueden usar sin programar, además de ofrecer soporte oficial del proveedor. Antes existía la percepción de que el open source era raro o poco confiable, pero últimamente eso está cambiando rápido en este campo
    • Scilab también es otro software que imita MATLAB, pero en comparación con Octave está más enfocado en las funcionalidades que en la compatibilidad
  • Para quien no conozca JupyterLite, es como el Jupyter Notebook/Lab tradicional, pero funciona completamente en el navegador; no necesita servidor ni backend, todo corre del lado del cliente
    • Si Python corre sobre Web Assembly, parecería que va a ser bastante lento
  • Con la misma tecnología (es decir, "xeus-stack" enlace a xeus-stack) hay muchas más opciones de lenguajes/kernels que pueden ejecutarse en jupyterlite, por ejemplo c++, python, R, lua, javascript, etc. Si quieres probarlo, revisa Try Jupyter Lab o la documentación de JupyterLite. Si quieres hacer tu propio despliegue, puedes usar el repo de plantilla xeus-lite-demo
  • Octave ha sido querido durante mucho tiempo por muchísimos estudiantes y ha servido como alternativa esencial para universitarios; es un buen ejemplo de cómo GNU ha contribuido al progreso humano. Lo recomiendo mucho para análisis numérico, y además es fácil extenderlo con GNU-Fortran o GNU-C. Viene con varias extensiones y es un DSL especializado en cálculo numérico. De forma parecida, Scilab también es un paquete recomendable, aunque es menos extensible
  • Siempre siento que, entre los distintos problemas que menciona el autor, queda enterrado el verdadero encanto; me parecería mejor que el diagrama apareciera más al frente y que se destacaran más las funciones de la próxima versión y los problemas del proceso de creación
  • Siempre he querido transpilar GNU Octave a otros lenguajes. Octave ya se podía embeber como biblioteca en C, y puedes consultar cómo embeber Octave en C/C++ y la documentación oficial sobre programas independientes. También existe un paquete OpenCL con soporte de aceleración por GPU; ver paquete OpenCL. Por desgracia, no aprovecha la GPU de forma implícita, sino que ofrece tipos y funciones de GPU explícitos; consultar referencia de oclArray, lo que significa que no está diseñado para ejecutar código existente de Octave en la GPU tal cual. Sería genial que también se implementara aceleración por GPU basada en OpenCL en el navegador, pero WebCL todavía no ha llegado a ese nivel de implementación; ver documentación sobre WebCL, Khronos WebCL. Actualmente, la tendencia es que WebCL sea reemplazado por WebGPU; consulté cómo usar WebCL en Chrome, guía de estandarización de gpuweb, y la documentación de APIs web de Chrome.
    • Si tuviera que decir lo que siento, es evidente que la industria insiste en enfoques comerciales en vez de soluciones abiertas claras por una cuestión de ganancias; basta ver la historia de muchas innovaciones, como el LED azul. Si la IA reduce un poco la carga para los desarrolladores, quizá podamos volver a explorar ese camino más obvio. En realidad, cada innovación tecnológica exige más carga y una curva de aprendizaje mayor para los desarrolladores, y aun así la recompensa (el salario inicial) en términos reales sigue estancada. Me preocupa que, si se generaliza el pair programming con IA, al final baje la calidad del código y se multipliquen los codebases complejos.
    • Por eso me atraen los métodos alternativos; por ejemplo, abstracciones que en Python se escriben de forma verbosa, en Octave pueden expresarse en una sola línea. Si uno quiere hacerlo aún más conciso, tendría que irse a un lenguaje ensamblador funcional como LISP, pero entonces se renuncia a la comodidad sintáctica de los lenguajes de arreglos.
    • El punto clave, en mi opinión, es que el camino más directo hacia una IA estilo J.A.R.V.I.S./Star Trek pasa por DSL como Octave/MATLAB y por herramientas de lógica de negocio como las hojas de cálculo de los años 80, HyperCard, Microsoft Access y FileMaker. Imagino que, si apareciera una herramienta abierta como Octave con aceleración por GPU, aumentaría la eficiencia para crear software y quizá contribuiría de forma directa al avance de la IA