morg (formato de documentacion basado en org-mode)

[nasciiboy]

una pequeña alucinacion/sueño sobre un nuevo formato para forjar documentacion. la idea es que se unan programadores nivel dios, cualquera con propuestas al formato o que proponga un buen diseño de como se hace un conversor de formatos decente

https://github.com/nasciiboy/morg

si queren compilar el codigo de la carpeta

gcc main.c regexp3.c exportToHtml.c fileUtils.c ripperMorg.c

y para ejecutar

./a.out -e test.morg

[TrOnTxU]

Yo utilizo org-mode todos los días, y lo que lo diferencia (para mejor) respecto a otros similares como Markdown, creo que es el poder editar el texto con los shortcuts y comandos de emacs org-mode, mas que nada.
Lo malo de org-mode es que necesitas emacs para exportar (aunque hay algunas utilidades en varios lenguajes para parsear un fichero sencillo).

Ten en cuenta que ya hay varios formatos de este tipo como el Markdown y el RestructuredText, pero si sigues queriendo crear algo "más especifico", yo te recomendaría que utilizaras python, ruby, u otro lenguaje por el estilo para el parser; igual hacerlo en C es matar moscas con explosivo plástico.

Por si te sirve de algo, puedes echar un vistazo a este post, es muy sencillo:
http://bitsquid.blogspot.com.es/2011/09/simple-roll-your-own-documentation.html

Un saludo

[nasciiboy]

a mi parecer emacs es lo que hace grande a org, de otra forma implementar los bloques de codigo seria un desproposito, y otra cosa que lo hace grande es el outline-mode que le da vida y funcionalidad, aun asi  no termina de funcionar muy bien.

markdown, org y similares solo son intentos de minimizar la orible necesidad de utilizar html o tex, se conforman con esto y no terminan de dar el salto, ser validos por si mismos sin depender de nada,

en cuanto a el lenguage, sinceramente creo que el buen codigo y el buen diseño se impone a cualquer cosa. con esto en mente (segun yo) pues si has de hacer esto, usemos c y no millones de lineas de codigo en c disfrasadas de otra cosa como phyton, java o lo que sea, como en el caso de org-mode que esta escrito en elisp y con poco que el documento se extienda o complique la exportacion suele demorar su tiempo y en ocaciones no terminar nunca. programar bien es indistinto de lenguages, todo depende del tiempo que le dediques y de los conocimientos de los que dispongas.

[TrOnTxU]

Como aclaración, por abrir un poco el debate (espero que no te importe), y que conste que no me parece mal que lo hagas en C, sobre lo que dices de "millones de lineas de código C", como bien sabrás, es más bien una definición bastante imprecisa.

Sobre la eficiencia de org-mode, no he notado ningun problema exportando un .org por muy grande que este sea. Más que la lentitud ya intrínseca de emacs para realizar algunas acciones.
El problema viene cuando tienes un proyecto con varios archivos, pero estos problemas de tiempo estan asociados con la forma que tiene emacs de abrir los ficheros como "buffers" (tiempo que se incrementa al tener que hacer la comprobación de las caches).

Y respecto al tiempo ganado con C respecto a python (perl, lua, ruby, etc.) para este tipo de programas (sobretodo de parsing y generacion de texto) se nota más que nada en el arranque del "python.exe", pero si tienes pensado parsear varios archivos en una llamada al script, entonces la cantidad de tiempo es despreciable, ya que apenas lo vas a notar desde que invocas el programa hasta que recibes el resultado (generas los archivos, etc.).
Me convenceria más la idea de que es "mejor" usar C por evitarse las depencias del runtime de python o ruby. Pero en la mayoria de sistemas no Windows (linux, MacOsX) ya viene defecto alguna instalación. Y tener siempre instalado algun tipo de interprete de script de este estilo es un plus.
La gran ventaja de estos lenguajes es que puedes crear programas sencillos en mucho menos tiempo, con muchisimas menos lineas de codigo, y por norma general más fácil de mantener (a no ser que comiences a crear un mega super programa que lo hace todo, pero yo creo que es mejor mantener unos pocos scripts independientes por proyecto).

Y intento respaldar mi posicion con algún que otro ejemplo:

• Sony Santa Monica empaquetaba todos sus recursos para los wad de los God Of War con scripts de Perl.
• Naughty Dog utiliza DC (DSL in-house dialecto de lisp PLT-Scheme/Racket) para compilar sus datos y lambdas de script ejecutable en run-time.
• Insomniac tambien utiliza perl para procesar archivos de codigo fuente.
• El mismo enlace que te he pasado antes es un post del Engine Architect del Bitsquid/Stingray.
• Y la lista puede seguir un buen rato más ...

Mi punto de vista es que la mayoria empresas que optimizan mucho en C/C++ y ASM para los run-time de sus juegos (que creo que son de los más "optimizados" del mercado a mi entender), utilizan lenguajes de scripts para procesar datos de forma "offline" (entiendase aqui como software que no se utiliza en el producto final, sino para su desarrollo).

Por tanto, y vuelvo a decir que no tengo nada en contra de el parser este en C, yo creo que cada herramienta es la más adecuada para cada problema.
Y una ultima cesión retórica :P, estoy de acuerdo con lo que dices que "lo importante es el buen diseño", pero discrepo un poco con lo del buen código.
Parafraseando al gran Mike Acton, "un buen programador no lo és porque escribe código, el código es una herramienta, un buen programador lo és porque sabe resolver problemas de datos y transformaciones".


Un saludo.

EDIT:
Respecto al formato (que lo queria comentar y se me habia olvidado), yo lo veo muy completo y pensado :), pero tienes una buena cantidad de trabajo por delante. Pero quizás echar un ojo a los parser que ya hay de org-mode te puede dar alguna ayuda o servir de guia de consulta: http://orgmode.org/worg/org-tools/.

Yo personalmente ya utilizo org, y los parser de documentacion que tengo son más especificos (como uno para generar winhelp-html, y las definiciones de los bindings de C con lua, y cosas por el estilo), así que no me apunto, sorry ^^

[nasciiboy]

gracias por tanta info, ya le habia dado una revision al vuelo al codigo de org, como apenas y empiezo con elips no entendi nahhh.

el primer lenguaje con el que tome contacto fue C con el deitel 6ta edicion, hay mismo ley un poco de c++, el primer libro de piensa en C++, cuyo codigo me paracere una pasada, algo de bash y en algun momento comence con un libro de phyton que termine abandonando a las 100 paginas por aburricion. luego segui con el c de K&R, para luego regresar al daitel intentando todos los ejercicios. voy por el sexto capitulo. todo esto va a lo que pienso de la programacion:

- las cosas automagicas son aburridas, vease phyton, o lisp
- si no soy capas de entender por que y como funciona no puedo aprobechar correctamento lo que tengo y terminare con un monton de codigo redundante
- mientras mas codigo tiene un componente menos lo entiedes,

  la abstraccion esta en el diseño no en el lenguaje, si entiendes el problema cualquer lenguaje esta bien, y si cualquer lenguaje esta bien usa el mas eficiente C (no toco asm por desconociemiento y por aquello de la portabilidad), en muchas ocaciones he leido de lo elegante que es tal o cual lenguaje, de lo rapido del desarrollo en tal o cual, que ahora funciona 50% menos lento. programar es duro, aprender como hacerlo es mas duro y hasta entender perfectamente como funcionan dos o tres paginas de tu propio codigo es complicado. La belleza de la programacion esta en hacer como programadores nuestro codigo elegante, que lo tomes un dia y te pongas erecto de orgullo al ver tu creacion a prueba del tiempo, cambios  y lenguages de moda que ban y bienen. El codigo no es una herramienta, es un legado hay plasmo mi forma de enterder las cosas y las herramientas mentales con las que cuento. como analogia podria decir que culaquer cueva te cubre de la lluvia, sin embargo no vivimos en cuavas, hacer funcionar codigo a base de apaños es una verguenza, por ello pido consejo para en buen diseño incluso que alguien capasitado tome el mando, si estubiera al nivel ya lo haria yo mismo.

esto lo saco desde la frustracion de abrir gawk, emacs, ncurses y cualquer otro que me despierta interes y nunca entender ni una puta mierda, el codigo siempre esta desparramado en incontables ficheros, macros cripticas funciones incomprensibles, y librerias de proveniencia desconocida, sinceramente es una pena que el programador de esto le preste tan poca atencion ha hacer las cosas bien, por ejempro la libreria regexp de emacs tiene 6000 lineas, la ge gawk 14000, la de plain 9 unas 3000, todas ellas sin incluir las librerias a las que llaman, sin embargo alquien entiende el codigo? probablemente ni los programadores, quien mantendra esto en un par de años? algun entusiasta con el lenguage facilon de moda. la implementacion regexp para el proyecto que escribri tiene menos de 500 lineas y esta en c puro sin recurrir a ninguna libreria su diseño me tomo bastante y en ocaciones dude de su eficacia, sin embargo a cada necesidad que ha surgido se ha mantenido de pie y sigue siendo sencilla a la ves que detallada o eso intento y cada vez que me sugerjo en su codigo no puedo evitar sentirme orgulloso de su "maquinaria" de adamantium y diamante.