Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Primera versión subida al repositorio

leave a comment »

Bueno, ¡por fin!

Tras varios meses de pulido, mezclados con exámenes de la universidad, el examen de japonés, trabajos y otras cosas, he podido subir una versión “potable” al repositorio.

Mi enfoque en este concurso ha sido el de, además de ampliar las capacidades de mi PFC, convertirlo en un producto software completo, bien documentado y probado. Durante este tiempo he tenido que reescribir buena parte del visor para implementar una interfaz TDI (Tabbed Document Interface), ya que en el momento de presentar el PFC sólo manejaba un documento a la vez.

Esto no sirve cuando tenemos documentos que enlazan a otros documentos y queremos verlos todos de una vez, como en el caso de las demostraciones de ACL2 que usan libros (es decir, colecciones de teoremas y funciones ya demostrados). A partir de ahora se puede pulsar en un enlace que nos lleve a otro documento sin más problemas, siguiendo un esquema particular de direcciones URL.

He aprovechado el componente InfoNode Tabbed Pane, que se halla bajo la GPL para uso no comercial, y he cambiado un poco los patrones de diseño detrás de la interfaz. Antes intenté un esquema MVC, pero no funcionó del todo, y se quedó en el MVC “mutilado” de Swing, en el que se integra la vista y el controlador. Extendido a la ventana principal, esto era un galimatías.

Así que probé a cambiar un poco el enfoque, usando “modelos de presentación” además de los modelos normales. Estos modelos factorizan propiedades útiles para varias vistas a la vez, e inútiles para el modelo, dejando a la vista mucho más sencilla. De esa forma podré en el futuro definir casos de prueba para aspectos relacionados con la presentación del documento, sin tener que comunicarme con los propios controles Swing.

Otras mejoras incluyen la posibilidad de que un usuario sin permisos de administrador edite los tipos definidos por el usuario (que siguen la filosofía de los ficheros de menú FreeDesktop.org) para personalizar las órdenes relacionadas con el post-procesador desde el tipo no XML original. Realmente el fichero original no se sobreescribe, sino que se escribe uno nuevo bajo el $HOME del usuario que toma prioridad sobre él.

Además, la actualización del documento es realmente “automática”: antes me limitaba a ejecutar de nuevo el post-procesador y reabrir el fichero cuando el usuario cerraba el editor. Ahora se usa un hilo en segundo plano que monitoriza el fichero en busca de cambios. Para ACL2, eso permitiría tener Emacs por un lado y el visor por otro, editando y grabando en un lado y viendo los cambios en el otro.

Esto ha hecho ya que el visor deje de ser “el visor para ppACL2” y pase a ser “el visor XMLEye” propiamente dicho. De hecho, pienso definir algún que otro formato adicional en estas semanas para demostrar su flexibilidad.

Por el lado del post-procesador, he seguido exactamente el mismo enfoque: hasta el momento era una colección “informe”, por así decirlo, de módulos y scripts Perl. He refactorizado el código siguiendo las recomendaciones para módulos del CPAN, estructurándolo con casos de prueba en base al módulo Test::More. Un desarrollador puede instalarse el módulo Module::Install y generar fácilmente tarballs de distribucióncon “make dist” desde la versión de Subversion. Estos tarballs son autocontenidos y se descargarán las dependencias del post-procesador cuando el usuario ejecute el script de instalación.

En el apartado de funcionalidad, el post-procesador es capaz ahora de seguir el grafo de dependencias a partir del fichero principal de una demostración y de enlazar todos los libros y demás usados, para que después en el visor se pueda saltar entre ellos.

A nivel general, el propio post-procesador se ha vuelto más “inteligente”: antes el visor tenía que lanzar él mismo ACL2 y luego ejecutar el post-procesador sobre el fichero principal. Para evitar que el visor tuviera que conocer el detalle de cómo se enlazan entre sí las demostraciones, ahora el post-procesador dirige el proceso completo a partir del fichero .lisp que abramos, e incluso evita tener que volver a analizar un mismo fichero varias veces, al estilo de la herramienta GNU Make.

Esto me deja así con un post-procesador mucho más funcional y un visor realmente genérico, por lo que en las últimas semanas he comenzado a pensar en las bestias negras de todo programador :-D: el manual y los paquetes Debian / instaladores para Windows. Por el lado de los paquetes Debian lo tengo casi listo (queda pulirlo un poco y subirlo al SVN), pero el manual voy a tener que empezarlo ahora.

Tomaré el manual sencillo del PFC como base, pero lo reescribiré usando DocBook y añadiré un tutorial en cómo definirse uno mismo un nuevo tipo de documento.

En fin, esto es todo por hoy😀, que ya me vale. Lo siguiente: paquetes Debian para Gutsy.

Written by bluezio

25 de febrero de 2008 a 19:04

Publicado en Desarrollo

Tagged with , , , , ,

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: