Iniciar Sesión

Ver la Versión Completa : [Noticia] Bob está regresando, pero esta vez no es un juego


Eslopes
27 de agosto de 2024, 14:25
Hola a todos,

Desde hace algún tiempo he estado pensando en lo que aún me gustaría hacer con Cobol. Este lenguaje siempre ha sido una enorme fuente de frustración para mí, con su verbosidad, falta de recursos y dificultad para integrarse con nuevas tecnologías. Sin embargo, recientemente, al revisar la documentación de GnuCOBOL, me di cuenta de que era posible integrarlo con Python y TCL (dos lenguajes de programación que conozco). Esto empezó a germinar en mi cabeza una idea un poco loca... ¿y si pudiéramos crear una aplicación gráfica que la integración con TCL/TK de GnuCOBOL permite, demostrando el uso de Quantization for Large Language Models (quizás algún modelo 7B) y RAG (Retrieval Augmented Generation) a través de la integración con Python de GnuCOBOL y con datos provenientes de una base de datos del usuario (ISAM o, ya que estamos mezclando conceptos, datos provenientes de tablas de un SQLITE)? Esto permitiría que una aplicación de GnuCOBOL pudiera ofrecer al usuario la posibilidad de un chatbot con Inteligencia Artificial Generativa, permitiendo al usuario hacer preguntas sobre los datos, como: ¿cuál es el crecimiento de ventas previsto para 2025 con base en los primeros 6 meses de 2024? Pensé en publicar por aquí el progreso. Si alguien quiere seguirlo, sugiero que configure un entorno Linux o Mac. Windows y GnuCOBOL son vasos no comunicantes para mí. Debería publicar novedades los domingos. Espero que sea factible y divertido.

¡Saludos!

Kuk
28 de agosto de 2024, 10:23
@Eslopes, menuda movida que estás montando, será un espectáculo fabuloso verlo en funcionamiento!!! :apl::apl::apl:

Fito
28 de agosto de 2024, 13:59
Hola: coincido con Carlos. Sería algo maravilloso.

Saludos

Fito...

Eslopes
30 de agosto de 2024, 16:00
Hola, ya tengo esta solución funcionando con Angular, NodeJS y Python en la AWS. La novedad aquí es eliminar Angular e incorporar GnuCOBOL y sustituir los modelos en la nube por un modelo de código abierto que se ejecute localmente (en tu máquina). Vamos a ver cómo evoluciona esto. En este momento, estoy seleccionando un modelo de LLM que sea adecuado. Los modelos de LLM requieren tarjetas gráficas sofisticadas, pero algunos modelos más simples pueden funcionar sin una GPU (con resultados inferiores, pero suficientes para demostrar cómo funciona este tipo de tecnología). Un producto destinado a ejecutarse en los clientes probablemente requerirá el uso de servicios en la nube como AWS.

Eslopes
1 de septiembre de 2024, 17:33
¡Qué bestia salvaje es gnuCOBOL 3.x! La instalación en el Mac M3 Pro es simplemente una pesadilla. En el pasado, ya había creado funciones Lambda con OpenCOBOL y no recuerdo la complejidad que estoy enfrentando ahora. ¿Alguien tiene un entorno funcional de gnuCOBOL 3.x con TCL en el Macintosh M1? ¿Alguien tiene un paso a paso explicando cómo instalar esta versión?

Estoy usando el branch https://sourceforge.net/p/gnucobol/code/HEAD/tree/branches/gnu-cobol-builtin-script/

Muy agradecido.

Kuk
1 de septiembre de 2024, 21:20
@Eslopes, sinceramente no conozco a nadie con Mac con Cobol... Yo creo será más fácil si lo haces en Linux, aunque sea en una máquina virtual.

Por cierto nunca he usado Tcl, ni lo conocía. Cuál es la ventaja de usarlo? Que se puede usar en casi todas las SO ? O para a través de este usar Tk (Tcl/Tk) para GUI ?

Eslopes
2 de septiembre de 2024, 02:15
Hola, la integración entre gnuCOBOL y TCL es un proceso directo. De hecho, existen dos o tres formas de hacer esta integración. Dado que TCL existe en varias plataformas y TK (el Toolkit gráfico) la aplicación es independiente del sistema operativo (Windows, Mac, Linux, etc.). El problema es que el soporte depende de una versión de gnuCOBOL que aún está en desarrollo. La versión 4.0 parece que va a consolidar los recursos, pero en este momento aún está lejos. Una de las integraciones, por lo que entendí, se abandonó desde 2020 cuando el desarrollador (Rildo Pragana) murió a causa del COVID (Dios lo tenga) y nadie parece haber continuado con su trabajo. Encontré otra biblioteca para crear aplicaciones gráficas, pero parece que solo funciona en Windows. El equipo italiano que la creó la llama GuiCobol. Es bastante interesante y tentador, ya que adopta la sintaxis de Fujitsu PowerCOBOL para manejar propiedades y métodos (https://gnucobol.altervista.org/how-guicobol-runs/). En fin, podría hacer la aplicación en modo carácter, pero realmente quería una interfaz gráfica.

Saludos

Kuk
2 de septiembre de 2024, 10:22
@Eslopes, has mirado esto? https://www.cobolforo.es/showthread.php?523-Desarrollar-programa-con-GUI-bajo-Linux&p=4044&viewfull=1#post4044
Nunca llegué a probar gran cosa, pero de base funcionaba bien cuando lo probé.

....
Ahora acabo de entrar en el enlace que has publicado y veo que se utiliza justamente LibAGAR que te he pasado arriba :D

Lo que han hecho, según entiendo, es integrarlo a nivel clase con una capa de abstracción para que podamos trabajar con LibAGAR vía OO Cobol, como en PowerCOBOL. Es eso?

Joseg
2 de septiembre de 2024, 13:55
Hola, la integración entre gnuCOBOL y TCL es un proceso directo. De hecho, existen dos o tres formas de hacer esta integración. Dado que TCL existe en varias plataformas y TK (el Toolkit gráfico) la aplicación es independiente del sistema operativo (Windows, Mac, Linux, etc.). El problema es que el soporte depende de una versión de gnuCOBOL que aún está en desarrollo. La versión 4.0 parece que va a consolidar los recursos, pero en este momento aún está lejos. Una de las integraciones, por lo que entendí, se abandonó desde 2020 cuando el desarrollador (Rildo Pragana) murió a causa del COVID (Dios lo tenga) y nadie parece haber continuado con su trabajo. Encontré otra biblioteca para crear aplicaciones gráficas, pero parece que solo funciona en Windows. El equipo italiano que la creó la llama GuiCobol. Es bastante interesante y tentador, ya que adopta la sintaxis de Fujitsu PowerCOBOL para manejar propiedades y métodos (https://gnucobol.altervista.org/how-guicobol-runs/). En fin, podría hacer la aplicación en modo carácter, pero realmente quería una interfaz gráfica.

Saludos

Na minha opinião, neste momento o GnuCobol já esta estável como linguagem de programação. No entanto, desenvolvimentos GUI/UI ainda não existe uma solução que me convença (venho do Powercobol).
Uma solução Web(izada) seria interessante, mas admito que teria que passar pelo domínio do Javascript...
Acesso a BD, já existem algumas opções estaveis, mas com a versão 4.0 (o desenvolvimento ainda esta numa fase inicial), todo o processo podera ficar ainda melhor e com mais opções.

José

Eslopes
2 de septiembre de 2024, 15:56
¿Quién sabe si no construimos con esta aplicación un modelo para la creación de interfaces gráficas con gnuCOBOL que sea simple de instalar, desarrollar y distribuir?

Saludos



"Una interfaz de usuario es el lugar donde la persona y la computadora se encuentran. Si te enfocas en hacer que el lenguaje de programación sea lo mejor posible, pero no piensas en la interfaz de usuario, has fracasado."

Alan Kay
https://es.wikipedia.org/wiki/Alan_Kay

Kuk
3 de septiembre de 2024, 10:01
@Eslopes, yo siempre me he interesado por las GUI, pero sobre todo en Editores GUI en modo WYSIWYG. Tuve un intento de ampliar PowerCOBOL 3 en su momento, pero con código C decompilado de un exe era superior a mis fuerzas.

Hasta donde recuerdo, la idea de un WYSIWYG es:

Uso de componentes GUI con subclassing para que actúen en modo Diseño como bloques gráficos en pantalla (sin funcionalidades)
Un "algo" que al poner un componente en tu Form o modificar alguna de sus opciones, te genera código en un lenguaje de programación y lo inserta donde debe, para cuando se compile tu proyecto, el componente GUI se crée po el código generado de manera transparente para el programador


Básicamente creo que es lo que pasa en PowerCOBOL y otros. Esto se veía bien también en Delphi y C++ Builder (al menos antes, llevo más de 10 años sin tocarlo).


Estuve dándole vueltas a la siguiente idea: puesto hoy existen muchas librerías GUI con sus APIs, por código no hay problema salvo la complejidad del mismo. Pero qué pasa con el dichoso WYSIWYG? Yo quería encontrar un Framework GUI con su editor GUI en modo WYSIWYG que permitiese asignar código e indicar el compilador... Es decir, que se pudiese "configurar" el editor GUI diciéndole qué código tiene que generar.
Si hubiera algo así, se necesitaría bastante tiempo, pero se podría crear/traducir código (por ejemplo) C en Cobol y obtener algo similar a PowerCOBOL pero con GnuCOBOL y GUI multiplataforma.

Pero no encontré nada que permitiese reemplazar/parametrizar código generado para componentes GUI.

Eslopes
3 de septiembre de 2024, 15:21
Hola,

La idea inicial era usar la integración con TCL/TK. TK (ToolKit) es una biblioteca/framework que permite crear interfaces gráficas. Un poco verboso, es cierto, pero bastante fácil de usar. El guiCOBOL parecía una opción para GUI, pero el propio creador, con quien hablé por correo electrónico ayer, me desaconsejó su uso. Abandonó el código hace mucho tiempo. Me sugirió otro proyecto que genera interfaces web (Makeform). Aún no he tenido tiempo de revisarlo, pero las opciones están volviéndose cada vez más limitadas. Todavía no he desistido del gnuCOBOL, pero me preocupa que esta parte de la interfaz gráfica termine consumiendo buena parte del tiempo que planeaba dedicar a este proyecto.

Saludos

Eslopes
4 de septiembre de 2024, 01:34
Hola,

después de una cuidadosa investigación y, para mi gran decepción, decidí usar FastCGI con gnuCOBOL. La sensación es como volver a 1996 (CGI), pero ¿qué se le va a hacer? Todas las demás integraciones con GUI son experimentales, sin una posibilidad real de ser utilizadas en un entorno productivo. Bueno, es lo que tenemos por ahora.

Saludos

Kuk
4 de septiembre de 2024, 21:22
@Eslopes, tú lo que quieres es que sea GUI con la sintaxis OO obligatoriamente?

Conozco un poco Python y creo recordar que también tiene biblioteca GUI, descartas esta opción?

De lo que todos hablan bien es de Qt, pero nunca llegué a verlo la verdad.

Eslopes
6 de septiembre de 2024, 21:28
Hola,

FastCGI es suficiente para lo que necesitamos.

Saludos

Kuk
8 de septiembre de 2024, 21:38
Hurgando un poco me he encontrado esto: https://nappgui.com/en/home/web/home.html

Más info: https://nappgui.com/res/nappgui_es.pdf

Tiene pinta interesante :piensa:

Eslopes
9 de septiembre de 2024, 01:36
Hola,

Después de verificar varias alternativas, realmente me quedaré con FastCGI. No es lo ideal, pero al menos permitirá una interfaz decente con Javascript (JQuery y otros componentes web).

Sobre el proyecto, en este momento estoy produciendo los elementos gráficos. No son muchos, pero le darán un aspecto más interesante a la aplicación, que básicamente es un chatbot. También estoy evaluando el uso de componentes que soporten Markdown para la generación de tablas, gráficos y otros elementos a partir del texto. Sugiero que echen un vistazo al siguiente sitio para entender cómo funciona Markdown (es fácil y rápido de aprender).

https://mermaid.js.org/syntax/flowchart.html

Un componente esencial del proyecto es el LLM (Modelo de Lenguaje Grande). Un LLM es un modelo de Inteligencia Artificial preentrenado que comprenderá las preguntas del usuario, las transformará en SQL y hará consultas a la base de datos (SQLITE). Voy a probar algunos modelos (LLama3 de Facebook, Gemma2 de Google o PHI3 de Microsoft) para evaluar cuál de ellos da el mejor resultado. El primer paso es instalar el modelo en tu máquina (usaremos OLLama):

https://towardsdatascience.com/running-local-llms-is-more-useful-and-easier-than-you-think-f735631272ad

Para aquellos que quieran comenzar a estudiar lo que vamos a hacer, sugiero el siguiente artículo:

https://medium.com/@OmkarSadekar/text-to-sql-using-llm-and-context-injection-with-rag-for-large-databases-8a2ae4f171ee

Esto se está poniendo interesante. ¿Quién sabe si en el futuro no hacemos una versión para PowerCobol? Probablemente necesitará ser una versión más reciente, pero por ahora sigamos con gnuCOBOL.

Saludos.

1000

Eslopes
13 de agosto de 2025, 14:28
Encontré diversos problemas con los componentes en C/C++ usados para hacer el puente entre gnuCOBOL y Python (versiones muy antiguas y ya no soportadas, código que fallaba en la compilación, etc.). Hace algunos días, Kuk mencionó en una publicación el gCobol, una versión GCC ("open source") de Cobol que podría ser una alternativa a gnuCOBOL. Me puse en contacto con la empresa que lo está implementando. A pesar de la cordialidad al responder mis preguntas, la verdad es que no hicieron ningún esfuerzo por ayudar a integrar su compilador con Python. Alegaron estar ocupados con eventos y presentaciones de lo que tenían entre manos y que el ejemplo del FAQ del propio gnuCOBOL debería funcionar.

Terminé encontrando, en su falta de visión, la motivación que necesitaba para sumergirme de lleno en el problema. Después de cierto esfuerzo, logré que GNU Cobol finalmente se comunicara con Python. No es perfecto, pero cumple con lo que necesitaba. Debo finalizar algunos detalles, pero grabaré un vídeo y pondré el enlace aquí para mostrar cosas que pueden hacerse con esta integración.

Es una pena que no se hayan interesado. Probablemente acabarán beneficiándose de las ideas una vez que las vean funcionando, pero no tendrán una gran ventaja competitiva para impulsar su solución. No es de extrañar que Cobol sea un artículo de museo: solo hay momias haciendo compiladores.

Por cierto, dado que la integración se da entre la capacidad de gnuCOBOL de llamar a una rutina en C que a su vez llama a Python, creo que no debería haber problema en hacer lo mismo con PowerCOBOL. Tal vez mi memoria me engañe, pero creo haber leído en algún manual de Fujitsu algo sobre cómo llamar LIBs o DLLs en C, o algo parecido. Si esta integración fuera posible, se podría abrir un nuevo mundo para quienes usan Power (creo que incluso la versión 3 podría utilizarse en este caso).

Emerson

Fito
13 de agosto de 2025, 15:03
Hola:

Yo en estos dias voy a empezar a hacer pruebas con esto Cobol + Python - Cobol Foro (https://www.cobolforo.es/showthread.php?t=1858)

Veremos qué tan práctico es.

Saludos.

Fito...

Eslopes
14 de agosto de 2025, 07:01
Cobol + Python - Cobol Foro (https://www.cobolforo.es/showthread.php?p=10091#post10091)

Kuk
14 de agosto de 2025, 10:36
creo que no debería haber problema en hacer lo mismo con PowerCOBOL. Tal vez mi memoria me engañe, pero creo haber leído en algún manual de Fujitsu algo sobre cómo llamar LIBs o DLLs en C, o algo parecido. Si esta integración fuera posible, se podría abrir un nuevo mundo para quienes usan Power

Confirmo que en PowerCOBOL se puede hacer todo lo que se hace en C, incluso recibir parámetros BY VALUE: Ventanas Flotantes - Página 3 - Cobol Foro (https://www.cobolforo.es/showthread.php?p=8555)

Por otro lado he visto tu vídeo y es alucinante !!! :apl::apl::apl: