Documentation:ToDo

ToDo (in spanish)

• Que el código del auxiliary pueda acceder al objeto del módulo, o sea, al internal status.

• Añadir posibilidad de externals que no se empotren en el .ice.

• Pensar en la posibilidad de servicios privados: cuando se necesita la concurrencia dentro del módulo sólo se debería hacer mediante servicios; el problema es que los parámetros de los mismos pueden ser objetos privados y, además, no interesa que esos servicios implementadores de concurrencia interna sean llamados desde fuera.

• Añadir llamadas no bloqueantes a servicios.

• IMPORTANTE: Posible "no thread-safe" al llamar a un servicio. En Debug peta al acceder a "threadsInfo" (o algo asi). TODO: Hacer crit. section en ese std::map ??

• Parece que el diseñador de módulos tiene un límite de 32Kb a la longitud del código que puede editar. Ha sucedido con un auxiliary logic de más de 32Kb que ha provocado un error de VBasic al pulsar en el botón de Auxiliary logic (el módulo sí se carga bien). Así que es un error del interfaz gráfico y sus llamadas a BABEL_RetrieveGlobalCode (de hecho hay sólo una llamada y usa un maxlen==0, que es bastante sospechoso).

• Pensarse si agregar un "Auxiliary data" para tipos globales internos / constantes globales internas. Pensarse también si mover el Auxiliary Logic como métodos private de la clase del ...i.cpp en los generadores para CORBA.

• Editor de código del MD: mejorar y permitir ver el internal status en cualquier trozo de código sin salirse, así como mostrar la lista de argumentos de entrada y salida en la ventana de edición

• Añadir una aracne atom para saber el nombre del módulo, y otra para saber el nombre del módulo llamante

• Añadir una aracne atom para saltar hasta el final de un servicio (útil para los permanentes)

• Corregir la versión del babel_core.h a "3.9.1", que ahora está como "0.3.9.1"

• El MD muestra como plataforma de comunicaciones para Endymion la ACE 5.4 + TAO 1.4, lo cual no es cierto. Requiere cambiar la dll del core de babel, que seguramente estará utilizando un código erróneo para extraer la plataforma del .cps

• ¿Pensarse si es bueno que al indicar en el non-portable design una librería se hagan automáticamente sus includes? Quizás sería bueno que eso lo hiciera el usuario... Quizás no. (JL: Ya está hecho desde hace un tiempo).

• Un servicio de tipo event o notification handler no debe tener visibles las ventanas de input/output arguments en el MD

• He cambiado "-ORBInitRef NameService=..." por "-ORBInitRef NamingService=..." en la máquina virtual de Ana Gago, en el EM, para lanzar al servidor de eventos (y por tanto a todos los módulos también, porque es la rutina "formaparametronaming"), y con eso a Ana le ha funcionado (no le funcionaba sin eso). Sin embargo hay que revisarlo, porque hasta ahora, según la documentacón, debía ser como estaba: "-ORBInitRef NameService=...". Chequear libro de ACETAO a ver y o bien a) volver a NameService en esa rutina del EM o bien b) cambiar todo a NamingService, tanto en la cabecera del formsequencer como en el script que genera el main de los módulos, donde también aparece aún NameService

• ESTADO DEL CAMBIO: nonportables y CMake
  • Como sacar fuera mrpt opencv (Ya incluye: Añadir nombre IDL mientras compila )
  • Hecho en parte. Queda ver metodo mas generico de incluir librerias aparte de OpenCV / MRPT.
  • Quitar las with* del generador Endymion y de la DLL del interfaz con el MD/EM.
  • Poner private los atributos (mapas) que JL ha añadido en el generador de Endymion.

• Añadir flag a babel_generator.exe para saltarse el esperar tecla al final...
  • hecho con flag: "-nokeyatend"

• ESTADO DEL CAMBIO: Nuevos tipos de datos
  • Meter en babel.idl algunos tipos de datos genéricos que puedan ser de utilidad, añadiendo su documentación a la wiki de BDL. Hecho. Metidos todos menos timestamp.

• Comprobar posible error con eventos en Endymion/Hyperion: cuando se lanzan muchos eventos sin esperas con un número determinado de módulos (unos 15-20), llega un momento en que los nuevos módulos que arrancan les falla la llamada al ->for_suppliers. Parece que se reduce la probabilidad de error si se lanzan todos los módulos antes de que empiece la avalancha de eventos, aunque aún así hay aplicaciones en donde todos los módulos pasan bien el for_suppliers pero luego se pierden eventos...
  • Probar una aplicación minimalista para descartar del todo que sea cosa de los módulos de la arquitectura ACHRIN, que es con quienes se ha probado siempre.
  • JL (11-nov-09): Ya se probó app. minima y falló, pero debería repetirse ahora tras corregir tema de secciones críticas al mandar eventos, quizás ya esté el tema resuelto...

• Tema: Bases de datos
  • http://babel.isa.uma.es/babel2/wiki/index.php/Architecture:The_RPD_and_APP_databases

• En EM / Modulos: que el -RemoteMandatory se pueda configurar dentro del modulo en si, o al menos que tenga un valor x defecto si no hay parametro en linea de comando. Parametros del modulo dentro de la "application"... formalizar en BABEL en sí???

• Programa Visual_RPD_Editor:
  • Cambiar nombre,
  • Hacer generico para RPDs y "apps-configs?".
  • Meter en BABEL/CMake y Execution Directory??

• Soporte para distintos compiladores con el mismo generador de código...
  • Posible idea: Mostrar un nuevo combo en el BABEL_MD para elegir compilador a la vez q se elige generador.

• Permitir definiciones de tipos en el lenguaje de programación escogido para tipos internos (un botón más parecido al auxiliary logic)

• Permitir uso de tipos de otros módulos en los parámetros BDL de un servicio de un módulo dado
  • El usuario lo introduciría como BABEL::<modulodefinitorio>::tipo
  • Se metería como dependencia de módulo (sin servicio) en la lista de dependencias
  • Cosas que faltan:
    • Incluir en Endymion, en el idl del cliente, después del include babel.idl, el idl del servidor de tipos. Usar los preceptivos #ifdef para evitar inclusiones múltiples
    • Tratar a las dependencias diferentemente si son de servicio que si son de módulo: si sólo son de módulo (y no hay ninguna que sea de un servicio de ese módulo), meterlas en el idl pero no crear objetos ni buscarlos en el servidor de nombres. En cualquier otro caso (lo cual incluye por ejemplo, las actuales dependencias de módulo que se necesitan para definir los manejadores de eventos), crear objetos remotos y buscarlos en el servidor de nombres.
      • En el MD, al añadir una Dep. pregunta si se quiere añadir solo un servicio o todo el modulo. Avisar de las consecuencias en ese aviso al usuario...

• Terminar el intérprete de átomos de aracne sobre trozos de código para a) hacer un mejor uso de las dependencias y b) detectar cuándo no se envía eventos, en cuyo caso no hace falta generar el código para event_supplier en Hyperion/Endymion.

• Montar un repositorio de módulos teniendo en cuenta sus dependencias y versiones

• Port a ACE+TAO-5.6
  • Parece que esto solucionaría un bug del TAO 1.1 que hace perder eventos y otros errores al conectarse al servidor de eventos

• Cambiar la gestión de cadenas de texto como tipo de datos mapeado de BDL a C++. Quizas, cambiar tb los sequences a std::vector<T> para que sea igual que en otros generadores futuros, ademas de evitar que el usuario tenga que hacer el "new Sequence" como ahora...
  • Todos estos cambios tienen la mala parte de que en el gen. de ACETAO, podriamos apañar todos los tipos de datos complejos, pero cuando esten dentro de estructuras ya seria demasiado...
  • De todas formas, ahora mismo YA hay que tratar los tipos de forma distinta si estan dentro de structs que cuando no lo estan, asi que quizas no es tan grave

• Sacar los ficheros de ayuda de la distribución y hacer referencia a esta wiki

• Añadir una aracne atom que dé información (nombre) del módulo

• Abordar genericidad (H)

• Abordar repetición de módulos (H)

• Generador para Player/Stage

• Docs sobre componentes del babel system

Cosas extra de referencia

• ACE-5.1+TAO-1.1.zip