Guardar código en una base de datos consultable.
Leía en Storing Code in Queryable Data Structures? (via @3DGiordano) la posibilidad de guardar el código en estructuras donde fuera mas fácil consultar su composición y la relación que existen entre las diferentes partes, que lo que lo hacen hoy en archivos planos de código.
En lo que mas programo es en GeneXus, que ya guarda la información del objetos que componen una Knowledge Base en una base de datos, pero el código mismo de los mismos se sigue almacenando como texto, que debe ser parseado* cada vez para ser editado/ especificado/ generado. En ese proceso se lee el código y se arma un árbol con la estructura de dicho programa.
No seria mas eficiente guardar dicha estructura en una base de datos orientada a almacenar grafos y guardar el código en forma de árbol?.
Algunas de las tareas que se necesitan para el manejo de KB grandes, como por ejemplo conocer cuales son los objetos que se verán afectados al realizar un determinado cambio, podrían hacerse de forma mas rápido que lo que se hace hoy.
Al almacenar el código en forma mas fácil de consultar, puede habilitar la realización de herramientas por terceros, que permitan resolver estos problemas de forma mas fácil:
Algunas que se me ocurren:
* Navegador de KB grafico (mostrar el grafo de la KB)
* Analizador de UTL en forma gráfica
* Detección de código no alcanzable
* Detección de objetos no usados/ Variables no usadas
* Detección de módulos (objetos relacionados)
* Detección de objetos públicos (interfaces entre módulos)
Me parece un proyecto de investigación interesante y si lo tuviera que hacer como prototipo, propondría cargar el código GX en una base de datos como neo4j y almacenar en ella tanto los objetos como el código representado como un árbol. Luego tendría que hacerse algunos programas de consultas y ver que performance tiene. Podría tener buenos resultados.
* Parseado es una palabra inventada, pero decir análisis sintáctico, me parece que no se entiende bien.
En lo que mas programo es en GeneXus, que ya guarda la información del objetos que componen una Knowledge Base en una base de datos, pero el código mismo de los mismos se sigue almacenando como texto, que debe ser parseado* cada vez para ser editado/ especificado/ generado. En ese proceso se lee el código y se arma un árbol con la estructura de dicho programa.
No seria mas eficiente guardar dicha estructura en una base de datos orientada a almacenar grafos y guardar el código en forma de árbol?.
Algunas de las tareas que se necesitan para el manejo de KB grandes, como por ejemplo conocer cuales son los objetos que se verán afectados al realizar un determinado cambio, podrían hacerse de forma mas rápido que lo que se hace hoy.
Al almacenar el código en forma mas fácil de consultar, puede habilitar la realización de herramientas por terceros, que permitan resolver estos problemas de forma mas fácil:
Algunas que se me ocurren:
* Navegador de KB grafico (mostrar el grafo de la KB)
* Analizador de UTL en forma gráfica
* Detección de código no alcanzable
* Detección de objetos no usados/ Variables no usadas
* Detección de módulos (objetos relacionados)
* Detección de objetos públicos (interfaces entre módulos)
Me parece un proyecto de investigación interesante y si lo tuviera que hacer como prototipo, propondría cargar el código GX en una base de datos como neo4j y almacenar en ella tanto los objetos como el código representado como un árbol. Luego tendría que hacerse algunos programas de consultas y ver que performance tiene. Podría tener buenos resultados.
* Parseado es una palabra inventada, pero decir análisis sintáctico, me parece que no se entiende bien.
Hola Enrique, muchas gracias por mencionar mi publicación en twitter.
ResponderBorrarSucede que justamente, publiqué ese articulo porque es parte de la linea de invetigación en la que estamos trabajando para el proyecto Genoma.
Pienso comentar un poco de lo que estamos investigando y desarrollando en torno a Genoma el día de mañana en la reunión GUG Montevideo.
no logro imaginar cómo guardar el código en forma de arbol
ResponderBorrarJavier:
ResponderBorrarPodes ver algo en http://en.wikipedia.org/wiki/Abstract_syntax_tree
Puede resultar medio complicado, pero si la sintaxis del lenguaje es clara, puede representarse como arbol binario que es mas facil de procesar luego por los que tienen que interpretarlo.
Algun libro de introduccion a los compiladores ( como el de Aho http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886) puede explicar mejor este punto.
Se construye un AST (como dice enrique). Por ejemplo en nuestro UML Almighty el código NO es una cadena de texto sino un AST. Ejemplo con la clase SoftwareFactory.
ResponderBorrarSoftwareFactory
startNewFaseOfUMLProject
| umlProject |
umlProject := self in: Project detect: [:e | e name = 'UML'].
umlProject startNewFase: 4.
"este codigo lo que hace es seleccionar de la clase SoftwareFactory el proyecto que tenga #name igual a 'UML'".
El arbol AST es el siguiente:
aStMethod
aStSequenceNode
aStAssignmentNode
aStMessage
aStMessage
Mas claro:
aStMethod(SoftwareFactory>>startNewFaseOfUMLProject)
aStSequenceNode
aStAssignmentNode(umlProject := ....)
aStMessage(self in:detect:)
aStMessage(umlProject startNewFase: 4).
El AST los construye el Parser de tu lenguaje. Tener un AST permite realizar tareas de refactoring mucho mas poderosas que en texto suelto.
Lo que hace el parser es crear un objeto (un estructura de datos si no es OOP) por cada posible sentencia del lenguaje.
Saludos,
Bruno
Perdon pero el AST salio sin tabs...
ResponderBorrar+aStMethod(SoftwareFactory>>startNewFaseOfUMLProject)
++aStSequenceNode
++++aStAssignmentNode(umlProject := self in: Project detect: [:e | e name = 'UML'])
++++++aStMessage(self in: Project detect: [:e | e name = 'UML'])
++++aStMessage(umlProject startNewFase: 4).
Ahora podes recorrer el AST.
Lo que hacemos nosotros en tomar este AST y adjuntarle un ExecutionSnapshot (es un contexto de ejecucion) --> con el [AST + Contexto de Ejecución] podemos Simular Ejecución de comportamiento, esta es la forma que lo hace el UML Almighty, pero esto puede variar dependiendo de tu objetivo final.
Bruno:
ResponderBorrarMuy buen comentario y comparto que tener el codigo en AST trae muchas ventajas en su manipulacion.
Creo que la url del nombre es:
http://uml-almighty.com/ que le falta una l, no?
Espero el 3 de mayo para bajarme una beta..
Enrique,
ResponderBorrarTenes razon: me falto la l.
http://www.uml-almighty.com
Aclaro que el AST es un resumen, no esta completo.
PQ faltan poner otras cosas, por ejemplo:
variables y constantes --> aStVariableNode
arrays, true, false --> aStLiteralNode
La jerarquía de clases de [StProgramNode] es bastante grande, pero cubre todo el lenguaje.
Saludos,
Bruno
Enrique y Bruno ya dieron algunas pistas de cómo hacerlo.
ResponderBorrarLo que generalmente se hace es construir desde el código fuente el AST, y luego el AST generado puede almacenarse de tal forma de no gastar procesamiento en la "recreación" del mismo.
Visual Studio, Eclipse, Netbeans y otros por lo que tengo entendido ya usan parte de éstas características (o muy similar, almacenan en memoria mucha de ésta información).
Principalmente lo usan para poder realizar análisis e inspección en tiempo real. Existen soluciones "offline" que usan técnicas similares para realizar inspección, los compiladores usan también el AST para poder implementar algunas de esas técnicas, así como también transformación (optimización).
Luego que se tiene el AST, hay varias opciones para "almacenarlas", por un lado pueden usar la más simple si están en un orientado a objetos, serialización/deserialización almacenando la información en modo texto en una base de datos o archivos, la otra opción es almacenar el AST en una base de datos orientada a objetos/grafos/ modelos/metadatos.
En las primeras, es posible usar lenguajes de query para objetos (linq para objetos como para dar un ejemplo conocido).
En el caso de "base de datos" es posible expresar el AST en estructuras especiales según el dbms y consumirlas mediante sentencias que permitan explotar en tiempo real la información (con una visión global, sin importar el tamaño/volumen, lo cual choca contra la implementación en memoria de los orientados a objetos).
Algo así como hacer una sentencia Select en donde te retorne todos los objetos GeneXus que usen una variable definida como numérico de 5,2, pero que no sean objetos con la propiedad "main" en "true" y que se encuentren en la cadena de llamado de un determinado programa Y. Todo resuelto en segundos sobre una base de conocimiento GeneXus de + de 10.000 objetos. (como para darles un ejemplo desde el punto de vista GX)
Hoy para implementar algo así, es necesario hacer muchos pasos en programación "pulmón" (C#), siendo que en realidad todo tiene su modelo/ estructura, por lo que podría ser consultado si existiera un lenguaje que lo permita (y claro, que sea performante para resolverlo en poco tiempo).
No importa para estos casos la redundancia, sino el poder de consultar y obtener lo que se quiere en un tiempo razonable.
Aún el tema está verde, pero hay muchas movidas que permitirán que el día de mañana pueda resolverse como si fuera lo más común.
Pienso que la web semántica y las redes sociales son algunas de las cosas que más van a hacer avanzar éstas tecnologías para su uso "general".
Perdón Enrique por tomar un comentario para escribir "un discurso". Me parece un tema interesante para discutir.
David:
ResponderBorrarEscribo un blog para poder intercambiar ideas con otros, por lo que cualquier comentario es bienvenido.
Si es largo y aporta, mejor.
También se pueden crear reglas de sustitución de AST. Por ejemplo, el AST_x es equivalente al AST_y, pero el AST_y es más eficiente. Esto permite hacer transformaciones masivas de código de un AST por otro. Dolphin Smalltalk (como todos los Smallalks) trae una herramienta llamada "Code Rewrite" que permite reemplazar patrones de código complejos. Si en tu fabrica detectas un error (patrón)que comenten los que no tienen mucha experiencia --> podes hacer el AST_y que "lo cura", así podes hacer transformaciones masivas. También se ha usado esto para reemplazar capas enteras de software. El "code rewriter" es una herramienta que usa un meta lenguaje que te permite recorrer AST ,especificar otro equivalente, aplicar una transformación ,etc.
ResponderBorrarEn UML Almighty no hay archivos de texto, lo métodos son Nodos parseados en un Árbol. El texto que se ve es la recorrida del árbol por todos los nodos y pidiendo a cada uno #printMessage.
Saludos,
Bruno
Bruno:
ResponderBorrarUna pregunta, donde almacenan los grafos del codigo o de los diagramas?
Podes explicarlo en forma facil para publico no experto?
En el caso del UML Almighty tenemos un Máquina Virtual. A esta Máquina Virtual se le pueden instalar diagramas UML, cada diagrama tiene clases y las clases métodos.
ResponderBorrarMi "objeto global" (para que se entienda) es la Maquina Virtual en la Maquina Virtual hay instalados diagramas UML, estos tienen clases y las clases tienen métodos.
Virtual Machine>>UML Model>>MyAccountClass>>myMethod>>parsedCode
El [parsedCode] es el AST. Cada vez que creo un método el Parser me crea un AST y este AST se cuelga de la estructura anterior.
Ejemplo: creo el método:
increaseBy: anInteger
^accountBalance := accountBalance * anInteger
Este método #increaseBy: es convertido por el Parser en el AST llamemosle AST_incB. Ahora este AST_incB se cuelga de la estructura:
Virtual Machine>>UML Model>>MyAccountClass>>increaseBy:>>AST_incB
Y de esta forma los arboles AST se guardan dentro del UML Almighty.
Luego toda la Máquina Virtual es persistida en disco con todos los objetos. Es decir, que los objetos son serializados en un archivo en disco, luego cuando se levanta la aplicación nuevamente se lee este archivo serializado y se tiene la VM trabajando nuevamente.
Espero que se hayan entendido como funciona ...
Saludos,
Bruno
PD: la VM sola pesa 170kb aprox, luego cuando se le empiezan a instalar diagramas y crear objetos --> crece.
Smalltalk le da vuelta a muchos, de eso no hay duda, siempre fue pionero en varios de estos temas.
ResponderBorrarLas primeras referencias que tengo con respecto lo que hoy se conoce del AST (y refactoring así como la inspección "en línea") se remontan a la época en que apareció VisualAge para Smalltalk.
Me apunto investigar un poco más al respecto para Genoma.
La idea ya existe, tenemos la idea de implementar algo de refactoring en GeneXus para un CP "futuro".
En una de esas para este CP pueda existir algo relacionado con suplantar/inyectar en el AST pero no se ilusionen mucho por ahora con esa idea.
Por lo visto estás usando la implementación de serialización y objetos en memoria.
Daría problemas para implementaciones en donde se tiene que acceder de forma masiva a los miles o millones de datos (hoy solo tienes herramientas para recorrer estructura de objetos, no existe indexación, por lo que tendrías que recorrer toda la estructura para resolver una consulta).
Y por el tema de usarlo en memoria podrías llegar a tener algunos problemas de escalabilidad.
Claro que para la idea de la herramienta es una idea simple y que funciona!!!, no se necesita más que eso.
Creo que el Visual Works lo tuvo antes (el Smalltalk de Cincom), personalmente lo vengo usando desde 2002 con el Dolphin Smalltalk. Tenes razon con lo que decis del tema memoria.
ResponderBorrarPero el UML Almighty es un simulador de aplicaciones, no es para ponerlo en producción ni para usarlo con esa carga.
Si alguien que usara el UML Almighty me planteara que quiere poner el sistema en producción --> se lo paso/convierto a GemStone/S (que no es muy difícil ya lo había pensado el problema).
GemStone/S soporta hasta 8.192 TeraBytes. La arquitectura es algo asi:
1. Repositorio (8.192 TeraBytes)
2. Las VM que acceden al sistemas, multiples VM.
3. SPC (shared page cache - max 32.768 GB) donde los objetos son consultados, creados y eliminados.
(Soporta indexacion sobre los objetos)
http://smalltalkuy.wordpress.com/2009/10/19/gemstones-el-oracle-de-las-oodbms/
En esta entrada hay bastante datos sobre GemStone/S, mi opinión es que este producto (OODMS) es excelente !
Con respecto al tema de escalabilidad del UML Almighty también hay otro detalle. Que el UML Almighty viene con un Web Server incluido y este mismo Web Server ya corre sobre GemStone/S.
Este es un tema de las futuras versiones del UML Almighty (esperemos que las haya), pero me animaría decir que, pasar la aplicación del UML Almighty a GemStone/S se puede hacer casi de forma automática. Por lo que así tendría escalabilidad.
Hablando de ese tema hace tiempo estaba (como analista funcional) en un proyecto que usaban GeneXus 9. Pero los funcionales hacíamos los diagramas de clases en UML, por que hubo varias idas y venidas con ese tema. En ese momento (no conozco mucho de GeneXus) empece a escribir arriba del UML Almighty un framework que me pasaba el diagrama de clases UML a Transacciones Genexus, obviamente solamente la definición de la transacción, nunca lo termine, pero lo habia avanzado bastante con los datos que me daban los programadores de GX. La idea era recorrer el UML Metal Model que genera el UML Almighty para un diagrama de clases, recorrer esta estructura y escribir un archivo XML con la definición de todas las transacciones. Este pasaje (UML --> Tx de Gx) que es parecido al mapeo de Objetos a Tablas Relaciones, y tiene algunos incovenientes pero se puede solucionar. Habia cerca de 300 clases por lo que si se podia pasar aunque se la estructura --> ya valía la pena.
Saludos,
Bruno
PD: me quedo largo el mail... perdón
Otra cosa que se puede hacer es usar un Esquema de Persistencia para poder manejar gran cantidad de objetos. Solamente levantas porciones de objetos a demanda, lo he usado esto y anda bastante bien, podes tener la cantidad de datos que quieras. Es decir, vas a tener que hacer un cache de métodos a medida se vayan necesitando los métodos, pero si queres hacer una transformación de código --> quizas tengas que recorrer todo el universo (todos los AST) y el cache --> no sirve.
ResponderBorrarNo se bien en que esta construido el entorno GX (en C# o java o Prolog escuche una vez) pero por ejemplo en mi Dolphin Smalltalk tengo 640.000 objetos y el proceso del SO ocupa 47 megas. Y NO crece de forma exponencial, esto es porque por ejemplo el numero 9 es el mismo (el mismo espacio de memoria) para todo el sistema.
Si una Persona tiene su variable [peso] un 9, y una Calificacion tiene [puntaje] 9 --> es el MISMO objeto. Esto no es asi en las RDBMS y asi con otra cantidad de objetos.
A lo que voy es que si mi herramienta de desarrollo es pesada a la hora de crear objetos --> para procesar AST voy a tener problemas de performance.
He llegado a tener varios millones de objetos dentro de Smalltalk sin ningún problema, por que los objetos pesan poco (el sistema esta armando desde su base para tener muchos objetos). Varios millones de objetos (muchos muchos AST) me ocuparian entre 100 y 200 megas, que para un ambiente de desarrollo esta OK. Y podría en este ambienet hacer todo lo que quisiera con los muchos AST.
Saludos,
Bruno
Vuelvo a repetir... Smalltalk siempre fue pionero en varios de estos temas. (los otros simplemente le copian ;) ...o reinventan la rueda, lo cual no digo que esté mal)
ResponderBorrarConozco GemStone/S pero apoyo OODBMS más abiertos como db4o (que seguramente no se compara con lo que hace GemStone/S).
Lo de persistencia con cache, es un método muy utilizado (mismo GX usa algunas técnicas similares).
Lo que menciona Enrique es que hoy en día GeneXus almacena el código fuente en forma "plana" (no así el resto de la metadata del objeto y de la base de conocimiento).
Con lo cual no solo existe "reproceso" en la generación del AST, sino que no existen herramientas que permitan mediante "query" consultar todas esa metadata de forma fácil (por no estar todo montado sobre algo que permita hacer semejante acción como algunos pocos OODBMS si lo permiten).
No hay duda de que el código fuente es algo chato y que puede seguir siéndolo (es una vista), el tema está en las herramientas asociadas al análisis de esa parte "plana" en su conjunto con el resto de su entorno.
La alternativa que existe hoy en día es ir identificando cada cosa que se necesite creando vistas y usando "cache" para solventarlo (seguimos en la misma no?).
Muchos IDE's usan esa técnica y no resuelven el problema de fondo, porque asumen que lo que se hará con los metadatos a lo sumo es lo que hoy usan para hacer lo que les permite desde el IDE.
Hoy los sistemas se vuelven complejos y se necesita encontrar la forma de explotar toda esa información almacenada, de una forma + "humana".
Ya el simple hecho de tener el AST no alcanza, el volumen de información es tan grande y granular que hace necesario un cambio en la forma en cómo se procesa toda esa información.
No conozco la estructura interna de GX por lo que puedo estar tirando verdura.
ResponderBorrarPero por ejemplo en Smalltalk cuando buscas referencias a un método, o referencias a un texto NO se genera ningún AST.
Las definiciones, referencias a métodos y a texto se resuelve a nivel de la estructura del método.
Cada vez que aceptas un método en Smalltalk pasan varias cosas:
* Se crean los ByteCodes del método.
* Se crea el código assembler del método.
* Se crean los literales del método.
Lo importante aca es el punto 3, la creación de lo literales.
Los literales es simplemente un Array como:
#('UML Project' #storeObject: #commitTransacction 'Show Selected')
Este array simplemente contiene los Strings que aparecen en el método y tambien Symbol que son referencias a otros metodos (#commitTransacction).
Por lo que cuando se hace una búsqueda de texto, de referencias a un método, o de definiciones de un método --> se consulta "los Literals" de cada metodo, que es algo bastante rapido, y NO hay que generar ningún AST.
Por lo que GX deberia poner una estructura llamada GXMethod.
GXMethod
- source
- literals
Cada vez que se compila un método generas el Literal y luego haces busquedas por los GXMethod.literals.
No me parece muy dificil de implementar (acordarse que no conozco la interna de GX). No se cuantos elementos puede contener una método/operación de genexus, pero trabajaría por ese lado.
Saludos,
Bruno
Ok, parte del tema es.. la herramienta guarda esa "tabla" de literales en algún lado?
ResponderBorrarCuando abre el proyecto/solución.. ¿se regenera esa y otras "tablas" con información sobre las definiciones?
Si el entorno de desarrollo fuera una base de datos.. ¿podría tener control en el backend de todo?
El IDE solo se encargaría de consultar la información que el "dbms" almacenaría en sus tablas internas.
No tiene sentido que cada cliente IDE esté calculando y analizando cosas que seguramente se están realizando también en otro IDE de otro desarrollador.
El día de mañana los IDE's para tener escalabildiad/tiempo real todo lo que hacen hoy "en caliente" pasará a ser "preprocesado" y almacenado en algún tipo de estructura en un servidor central, dejando al cliente IDE simplemente como un cliente "liviano".
Hoy GeneXus tiene un mix de todo esto, tiene todo su conocimiento en base de datos y parte de algunas cosas se hacen en el cliente (se usa la base como repositorio centralizado de toda la metadata).
Me imagino que cuando se vuelva popular programar en la nube y trabajar de forma colaborativa en tiempo real, todo esto que hoy estamos discutiendo nos parecerá "básico" y evidente (cuando otros comiencen a adoptarlo).
Ahora bien, una cosa es conocer métodos, interfaces y tipos de datos de una clase, otra es conocer el AST, y otra es tener acceso al árbol de sintaxis concreta (CST).
GeneXus ya almacena todo los códigos fuentes en base de datos, está en posibilidad de aprovechar más esa info.
Si bien el código se encuentra en la base de datos, parte del mismo está en modo "texto" (código procedural) que podría ser explotado si se almacenara "como estructurado".
Parte de lo interesante del artículo comentado por Enrique son esos temas que se discuten.
GeneXus está adelantado en muchos de ellos, desde hace 20 años que almacena el código fuente + metadatos en base de datos.
Tiene el poder de refactoring y de referencias, trazabilidad y versionado.
Poder cambiar una estructura de base de datos y que la herramienta tenga la información que algo pasó de nombre A, a B, y a C, no es un tema de discusión en GX (lo digo porque en otros si se discute el problema de cambiar el nombre de cosas o tener la info de crossref cuando tienen un flat file).
Muchos de los temas "discutidos" en el mundo "flat file" (orientado a objetos?) no aplican o ya fueron resueltos en GeneXus.
Algunos temas cada tanto sales a la luz como interesantes (query del código fuente por ejemplo, o formas de visualizar diferente el mismo).
Como comenté en un principio, en algo estoy es ese "Query" sobre todos los fuentes de un proyecto (Base de Conocimiento GeneXus y el AST de la parte procedural).
En cuanto tenga algún ejemplo o "preview" lo estaré presentando en mi blog.
Todo esto igual me despierta algunas cosas..¿y si tenemos en la base de datos almacenado todo en un formato de estructura que el compilador en el fondo puede entender...¿no estaremos permitiendo que pueda existir un nuevo tipo de compilador?
Hoy los compiladores utilizan métodos rudimentarios para descubrir e inspeccionar, luego recrean estructura en memoria (CST, Tablas de símbolos, etc) y tienen mucho IO leyendo todos esos "Flat File" + clases/dlls por reflexión para poder encontrar lo que necesitan (jar's, dll's, .java, .cs...).
Teniendo todo en un dbms con la visión global y las estructuras necesarias precargadas... sólo se deberían de encargar de la optimización e ir directo a compilación.. realmente todo podría ser mucho más rápido a la visión que hoy tenemos de "compilación".
Muy interesante tu comentario.
ResponderBorrarTrabajar o no con archivos planos tiene sus diferencias a nivel de usuario individual, pero se hacen más profundas a nivel de equipo de trabajo.
La diferencia es que todas la herramientas usan "flat file", Smalltalk utiliza una "image" (imagen), y esto cambia todo el contexto, por lo que los problemas y soluciones para una y otra forma de trabajo son muy diferentes.
Cada imagen Smalltalk (que usa cada programador de forma individual) esta compuestas de 3 archivos (4 con el de errors).
Archivo .chg (un log de cambios en el sistema)
archivo .img (los objetos del sistema)
archivo .sml (los fuentes de las clases)
Cada programador tiene su image.
Como vos decis en tu comentario, aca pasa algo parecido.
El archivo [img] es un grafo de objetos en disco (OODB) sobre el cual la Virtual Machine (no un compilador) opera y accede.
La VM a medida que necesita métodos y objetos los lee "on demand" (a demanda) del archivo.
Los objetos están "congelados" en disco, se levantan a memoria con la misma estructura. Notar que se leen a demanda.
En este caso tenes la VM que al conocer la estructura de clases, métodos, objetos, etc puede operar sobre el archivo [img].
Ahora de aquí se ve que cada programador tiene "SU" imagen. Cada programador versiona sus Packages (clases, metodos, etc) en el repositorio. Cuando se trabaja en equipo hay que estar haciendo siempre "continuous integration" para mantener unificado el trabajo. Esta es una practica muy buena ! (hay herramientas para hacer esta tarea)
Otra vez el tema de poder mantener todo tu sistema en memoria depende de la tecnología de tu ambiente de desarrollo.
Pero las diferencias entre trabajar en archivos planos y un ambiente totalmente integrado son abismales. Esto lo saco de la practica ya que trabaje para una empresa que tenia un framework en C#, que usaba muchos archivos (xml,xslt,xsd,etc). Era muy tedioso de configurar para los programadores, en este caso implemente una herramienta que integraba todo al estilo Smalltalk.
http://smalltalkuy.wordpress.com/2009/11/27/mitigando-el-dolor-causado-por-un-framework-en-c/
El titulo es medio en broma, se leen los archivos iniciales (xml, etc) y se crea la estructura en memoria, luego se opera sobre esta estructura usando la IDE desarrollada y luego esta estructura se le "deploy" en disco en forma de xml, xst, etc , y el framework usa los archivos generados por esta IDE. Esto abrió la posibilidad de hacer "cross-file refactoring" para cambiar elementos distribuidos en múltiples archivos.
Pero si no podes encontrar una forma eficiente de manejar millones de objetos sin tener que mandarlos a una base --> que el problema se puede complicar.
Una forma seria hacer un Virtual Machine GX, permitiendo generar un formato interno de código fuente (xml u otro) y que esta VM GX puediera operar sobre esto. Y luego construir una IDE para poder usar la funcionalidad de la VM GX.
Mira que hacer algo así no esta tan difícil. Habría que poder exportar el código GX a archivos XML u otro formato, leer los archivos y crear las estructura correspondientes.
Y luego la IDE. Por ultimo un test de stress para ver cuanto código soporta la estructura.
Esto depende de las estructuras internas de los objetos GX, pero podría quedar algo interesante.
Saludos,
Bruno
David y Bruno:
ResponderBorrarMuy interesante el intercambio!. Creo que de este tipo de charlas, entre personas que resuelven problemas complejos desde puntos de vistas diferentes y con diferentes herramientas, es donde se enriquece toda la comunidad.
Bruno:
GX ya tiene forma de exportar todo su codigo a xml, en un formato XPZ, que no es publico, y se le puede hacer ingenieria inversa, aunque da un trabajo grande.
Enrique
Bruno, estoy en eso, viendo de cargar "la estructura" (que parte la proporciona la API de BL de GX) para almacenarla en una "base de datos" (me voy por db4o) para poder luego consultarla de forma fácil.
ResponderBorrarLa idea es que otros puedan construir herramientas en torno a todo esto.
Como menciona Enrique, es bueno todo esto del intercambio. :)