Otros temas que te pueden interesar
|
||||
| Tema | Autor | Foro | Respuestas | Último post |
| [Noticia] Bob está regresando, pero esta vez no es un juego | Eslopes | GnuCOBOL (OpenCOBOL) | 20 | 14 de agosto de 2025 10:36 |
| [Compilador] Otterkit | Estamos buscando ayuda de la comunidad | KTSnowy | COBOL - General | 8 | 15 de febrero de 2023 15:13 |
| [Compilador] Otterkit | Languages & Runtime Community Standup | KTSnowy | COBOL - General | 2 | 9 de febrero de 2023 23:10 |
| [Sintaxis] Saber si un EXE se esta ejecutando ?? | Hrmcobol | PowerCOBOL y WinAPI | 1 | 24 de noviembre de 2020 13:11 |
| [Sintaxis] Controlar si un Form ya está abierto | Armando | PowerCOBOL (ActiveX, v4 - v11) | 6 | 23 de agosto de 2017 19:54 |
![]() |
|
Representante Oficial
![]()
|
Después de ~11500 líneas de descenso recursivo escrito a mano, el análisis sintáctico en el analizador ahora está completo. Esto significa que el analizador ahora está completo, gramatical y estructuralmente hablando. Ahora trabajaremos en la implementación del análisis semántico que incluye la verificación de errores, la recuperación de errores y la resolución de nombres de identificadores.
La mayor parte de la infraestructura necesaria para la resolución de nombres (la tabla de símbolos y los tipos relacionados) ya se ha implementado, y ahora solo es cuestión de refinarla y poner todo junto. La recuperación de errores también se implementó utilizando "puntos de anclaje", pero aún necesitamos encontrar los mejores lugares para usarlos. Dato curioso: Otterkit ahora tiene (hasta donde sabemos) el único analizador escrito a mano para COBOL 2023, y estamos comprometidos a trabajar para crear el mejor analizador COBOL estándar del mercado. Hacer que el analizador esté completamente escrito a mano significa que no estamos limitados por un generador de analizador y su funcionalidad proporcionada, o los (a veces) mensajes de error que no son muy útiles. Podemos ajustar absolutamente todo hasta exactamente cuándo y dónde mostrar un error al usuario, incluido el contenido del error. Y aunque es una enorme cantidad de trabajo escribir un analizador de descenso recursivo escrito a mano para COBOL, todavía creemos firmemente que esta es la opción correcta para Otterkit. Publicación de actualización completa en GitHub: https://github.com/orgs/otterkit/discussions/18 |
||||||||
|
|
|
|
Moderador Global
![]()
|
@KTSnowy, Deseando "catar" ese compilador cuanto antes
y, esperando también que el informe de errores que nos muestre cuando compilemos, estén en español, ya que parece que hay mucho hispanohablante metido en el "ajo"... ![]() ![]() Un salu2.- |
||||||||
|
|
|
|
Administrador
![]()
|
@KTSnowy, el reporte de errores es algo muy importante y valioso. Me gusta ver como de serio os lo tomáis. Como te dije en el otro hilo, aquí me tenéis, y seguro que a muchos de los foreros, para echaros una mano en lo que humildemente podamos.
Pequeño offotp: yo más de una vez he pensado en montar un eco-systema con GnuCobol y un GUI designer, que sea cross-platform, algo sólido y rico tipo Qt, pero.... no tengo tiempo. @Josber, qué cabroncete ![]() NORMAS DEL FORO - para garantizar el buen funcionamiento del Foro. ![]() ¿Te han ayudado? NO TE OLVIDES de darle a ![]() ¿Quieres dirigirte a alguien en tu post? Notifícale haciendo clic en su Nick |
||||||||
|
|
|
|
Guru de COBOL
![]()
|
No se lo que puede salir de lo que estáis haciendo y menos si llegaré a probarlo (por la edad), pero merece todos mis respetos el simple hecho que estéis dedicando tiempo a algo que llevan diciendo hace años que está muerto.
Sabéis algo que sería super interesante, poder retomar Netcobol con PowerCobol y seguir actualizando, ya que Fujitsu tiene claro que su fin está cerca. No se si sería posible, pero sigo pensando que es el mejor compilador y el mejor IDE |
||||||||
|
|
|
|
Representante Oficial
![]()
|
@Kuk, Muchas gracias. Es posible que necesitemos ayuda para determinar qué bibliotecas debemos incluir con el compilador, no queremos codificar extensiones no estándar directamente en la sintaxis, por lo que incluiremos bibliotecas y módulos para clases y funciones adicionales.
Estamos planeando trabajar en una biblioteca de GUI para Otterkit, tendrá que ser una biblioteca debido a que la naturaleza de la GUI es específica del sistema operativo en general. No queremos codificar extensiones de GUI no estándar directamente, ya que creemos que desviarse demasiado del estándar es un error que cometieron demasiados proveedores. Codificarlo directamente en la sintaxis también dificulta que los usuarios elijan una biblioteca diferente. No queremos que los usuarios se vean obligados a usar una sola biblioteca. @Nitzer, No creo que COBOL esté muerto, el lenguaje es bastante bueno, especialmente con los estándares más nuevos y también hay un montón de código en producción. Usar código COBOL orientado a objetos es mucho más fácil. El ecosistema solo necesita un poco de amor, y espero poder ayudar a mejorarlo y darle una nueva vida a COBOL. Quiero darle al ecosistema un compilador de código abierto y gratuito para COBOL moderno, porque en este momento no hay un compilador de acceso gratuito para COBOL moderno. He mirado NetCOBOL, pero desafortunadamente solo es compatible con COBOL 85. Otterkit admitirá el estándar COBOL 2023, espero que podamos hacerlo mejor que los compiladores existentes actuales, porque COBOL necesita mejores herramientas. También estamos planeando trabajar en un servidor de lenguaje COBOL para compatibilidad con VSCode e IDE. @Josber, Desafortunadamente, los mensajes de error solo están en inglés en este momento, tal vez podamos trabajar en los mensajes en español en el futuro, pero necesitaríamos ayuda de la comunidad COBOL de habla hispana. Así es como se ven los mensajes de error en este momento: [ATTACH=CONFIG]901[/ATTACH] |
||||||||
|
|
|
|
Administrador
![]()
|
@Nitzer, yo en su día les contacté por mail para pedirles el código fuente del PowrCOBOL v3L10, quería añadirle más controles etc. pero 0 respuestas. No creo que vayan a ceder el código del IDE, del compilador ya ni te hablo. Aunque sería muy guay si le dieran más vida a PowerCOBOL que coincidiendo contigo, es el que más me gusta.
@KTSnowy, estoy completamente de acuerdo. Una biblioteca GUI con código estándar autogenerado (modo WYSIWYG), como por ejemplo lo hacía Delphi. Creo que si llegáis a enchufarle el Qt sería la bomba: https://gitlab.com/ddobrev/QtSharp NORMAS DEL FORO - para garantizar el buen funcionamiento del Foro. ![]() ¿Te han ayudado? NO TE OLVIDES de darle a ![]() ¿Quieres dirigirte a alguien en tu post? Notifícale haciendo clic en su Nick |
||||||||
|
|
|
|
Administrador
![]()
|
@KTSnowy, qué tal? Cómo va la cosa? Habréis avanzado bastante, imagino
![]() NORMAS DEL FORO - para garantizar el buen funcionamiento del Foro. ![]() ¿Te han ayudado? NO TE OLVIDES de darle a ![]() ¿Quieres dirigirte a alguien en tu post? Notifícale haciendo clic en su Nick |
||||||||
|
|
|
![]() |
|
|
| Archivo - Cobol Foro | Contactar con Nosotros - Cobol Foro | |||||||