Jugando con ActionScript 3.0

Estuve jugando con esta nueva versión del lenguaje, que se basa ECMAScript, utilizado por Macromedia Flash (que se introduce en Flash Creative Suite 3 y que creo que todaía no salió al público).

Las mejoras al lenguaje se notan «cuando las papas queman» (por lo menos en las cosas que probé) y han arreglado varios de los problemas de ActionScript 2.0 que eran muy molestos. Algunos detalles :

Runtime Exceptions : Antes cuando ocurria un error en runtime (por ejemplo si llamabamos a un método que no existía) Flash simplemente pasaba de largo para evitar errores «feos» como los que pasan con JS en el browser. Claro, debbugear un problema así es muy molesto, cualquier typo pasa desapercibido. Ahora se pueden activar estos errores.

Sealed Classes : En AS 2.0, uno puede agregarle cualquier cosa a cualquier clase (al estilo de Python) en cualquier momento. Si uno quiere ahora puede «blockear» la clase para que en Runtime no se le pueda agregar nada más. Las ventajas práctica son : minimiza el consumo de memoria ya que no tiene el hash interno para soportar el «dinamismo»; y ayuda a minimizar errores boludos (ya que ahora va a tirar un Runtime Exception por lo dicho anteriormente). De todos modos, podemos usar clases totalmente dinámicas si queremos.

Method closures : Tal vez lo más importante que arreglaron :). Antes había métodos anónimos, pero al invocarlos se perdía el contexto de donde fueron creados, teniendo que guardar uno el entorno donde se ejecutaba. Si bien en AS 2.0 hay un workarround usando la clase Delegate, era molesto. Ahora hay closures de verdad.

ECMAScript for XML : AS 3.0 introduce esta nueva extensión del lenguaje para manipular XML que hablando profesionalmente, le rompe el totó a DOM 🙂 (en comodidad, el resto ni idea :P). Esto hace que uno manipule XML como si fuera un tipo nativo y a la vez es un stream.

Regular expressions : Muy útil 🙂

W3C DOM Events : El manejo de eventos se cambio por un estandar de la W3C. Todavía no vi mucho de como se usa, pero lo veo como un cambio positivo.

MTASC todavía no tiene soporte de AS3, por lo que habrá que esperar para los que quieren la solución libre.

Creo que eso destacaría por ahora. Feliz Día de la Independencia!!! … a no, eso es en el otro pais 😀

Dependencias Funcionales y Cubrimiento Minimal

Muchas veces nos encontramos con cosas que molestan, y las dos que nombro en el título son claros ejemplos, o por lo menos lo son cuando uno estudia Bases de Datos (al menos en mi facultad :D).

En realidad el tema en sí no es complicado ni difícil, sino más bien molesto. El algorítmo de Cubrimiento Minimal es uno de los peores y consta de 4 pasos (3 en realidad, el paso 0 no existe como tal :P) y hacer un solo ejercicio a mano me llevó 5 carillas y unas cuantas decenas de minutos.

La molestia viene dada por dos ciclos anidados que se complica por un tercer ciclo para un calculo intermedio, lo que lo convierte en 3 ciclos anidados :). Creo que no hice cosa más inútil en mi carrera (mentira, si me esfuerzo seguro algo encuentro). Sin contar que hay que recalcular un conjunto en cada paso para verificar condiciones. En fin, nada útil si no van a cursar la materia :D.

Todo esto viene a que implementó (literalmente a como está en el libro, nada de hacerse el loco y querer optimizar, de hecho lo empeoro copiando mil veces las cosas por las dudas no pisar nada sin querer :D) el algoritmo de Cubrimiento Minimal para un conjunto de Dependencias Funcionales, lo que me permite corregir los ejercicios en cuestión de segundos.

Les dejo el código por si alguno cae por acá y lo encuentra útil.

Seguir leyendo «Dependencias Funcionales y Cubrimiento Minimal»

emerge -av life

Ha pasado un buen rato, y la verdad que no ha pasado mucho en mi vida. Estoy bastante ocupado con boludeces de la facultad (trabajos, entregas, parciales, etc) y principalmente con mi tesis que dio un giro que no me esperaba :), se recorto por todos lados lo que yo tenía pensado hacer (o más bien lo que yo había entendido que tenía que hacer :D).

Resumido en un párrafo de un mail en la charla con uno de mis directores de Tesis :

Tal vez para resumir mi idea sobre el proyecto, lo que estarías haciendo es un «reificador de mensajes entre objetos», configurable de forma que la reificación pueda encenderse y apagarse de forma dinámica por motivos de performance. Casi la palabra aspecto se puede suprimir 😀

En fin, parece tan simple, que complica. Para empezar estoy analizando diferentes weavers y como realizan su trabajo, para poder comprender los cambios que se necesitan en la VM.

Les dejo acá buen paper sobre el weaving en AspectJ.

En otro aspecto de la vida, mi hermana juró por su título hace un par de semanas, y ahora oficialmente soy el único miembro no-titulado de mi familia :), lo que suma una presión extra a completar mi carrera de grado. Tengo una foto que predice el futuro, donde estoy posando muy sonriente con el título de mi hermana (total enrollados todos son iguales!!), pero voy a tener que esperar a viajar a Cipolletti para obtener una copia :).

Antispam en el GForge

Ya hace un largo tiempo que los spammers nos estaban dando batalla en el GForge que tenemos en el LugFI. Este sábado, mientras me recuperaba decidí finalmente mirar el código y ver que se podía hacer.

Lo primero que me encontré es que el código apesta, y mucho :). No existe una forma simple o modular de extender la interfaz, así que recurrí a hackear directamente el código. Luego de un ratito le mande el diff a Des para que lo aplique.

El resultado : los reportes de bug/feature request/etc requieren ahora un campo más que es el antispam, así como también dejar comentarios en registros ya abiertos. El antispam no hace diferencia entre usuarios registrados y anónimos, así que espero que los users registradon no se ofendan :).

El parche en cuestión está acá a y aplica seguro sobre la versión 4.5.19 (yo use el orig.tar.gz que provee Debian para asegurarme que el patch aplicara en nuestro servidor). No puedo garantizar que aplique en otra versión.

NgSpice ha vuelto!

Luego de haber sido mutilado, el soporte de NgSpice para Oregano fue reescrito hoy. No está probado ni el 10% de todo lo que debería funcionar, pero ya me doy por satisfecho y es ahora de que me siente a esperar los reportes de los usuarios (Ping Tulku!!) con sus afamados problemas :-).

El parser nuevo, a diferencia del viejo estilo preprocesado en perl externamente al programa, utiliza el formato RAW que exporta NgSpice, haciendo mucho más simple la lectora de los valores de los análisis, sin tener que parsear texto.

El shot obligado :

ngspice.png
Con esto ya estarán dadas las condiciones para hacer un nuevo release, que supongo que será este fin de semana, aprovechando que sigo de vacaciones :-). Hay varias cosas que ameritan este release :
  • Nuevo esquema para los engines : Más flexible, más prolijo, más fácil de extender a nuevos engines, y sobre todo, anda. [1]
  • Scons cleanups
  • Instant-apply dialogs!
  • Nuevo log (colorsitos, ordenado, etc)
  • El ProgressDialog ahora muestra que operación se está realizando
  • Models y SubCKT
  • Menu cleanup
  • Mejora en la ventana de ploteo : los ejes son mas claros y se muestra la unidad actual en lugar de usar notacion cientifica.
  • Unos cuantos bugs de usabilidad y detalles reportados por Tulku!

[1] : Antes la salida de ngspice cambiaba segun detalles de la simulacion (db, no db, AC o Trans, etc) y el script en perl se colgaba mal 🙂

Oregano migra a GtkPrint!

Si señores, ya era hora de tener un motor de impresión como la gente :-). Luego de varias consultas por parte de mis beta-testers me decidí migrar el soporte de impresión a la nueva API de impresión de Gtk+.

La migración fue simple, por lo menos para dar un soporte básico. Lo primero que hice fue borrar print.[h|c] que tenían el código de soporte de GnomePrint. Luego portá las funciones de modelo a Cairo (en lugar de usar las viejas API de Art) y por último le agregué el código para que se abra el diálogo de impresión.

oreganoprint.png

No se ilusionen mucho que faltan bastantes cosas por hacer antes de que tenga alguna utilidad :-). Una ventaja de esta migración es que ya tengo el código en el modelo para poder exportar el esquemático a un PNG, PDF, PS, SVG o cualquier otro backend que soporte Cairo, cosa que creo que varios van a agradecer :-).

Por ahora no voy a subir los cambios al repositorio principal, ya que esto me obliga a depender de Gtk+ 2.10, recién salida del horno, por lo que voy a mantener un branch privado hasta completar el código.

Mi pequeño TODO :

  • Agregar Labels de los componentes y textos.
  • Impresión Color y B&W (Qué colores te gustarían???!!)
  • Rótulo y orientación default de la página. (El tamaño es configurable y el circuito se adapta a la página)
  • Si ves algo que debería soportar, y no está en esta lista, dejó un comentario 🙂

UPDATE:

Ya tengo funcionando el diálogo y la código para exportar el esquemático. Actualmente hay soporte (dependiendo si la versión de Cairo instalada lo soporta) para PDF, PS, PNG y SVG (el Inkscape no lo abre bien, pero otros programas si). El ónico que anda realmente bien es el de PNG, el resto tiene varios problemas que sospecho que son de Cairo (ya sean bugs o que me está faltando llamar alguna función).

Models y SubCkt

Una cosa que le venía faltando a Oregano era la posibilidad de utilizar modelos complejos para la simulación, y que por suerte ya quedó en el pasado ;).

Hoy luego de mucho leer sobre Spice, NgSpice y GnuCap logré entender un poco como se usan los modelos (a través del comando .model) y los subcircuitos (a través del comando .subckt). Esto sumado a la magia del .include hacen posible, por ejemplo, utilizar un componente «Diode Bridge» en lugar de tener que poner cuatro diodos :-).

La historia empieza modificando el componente «Diode Bridge» de la biblioteca default para que en lugar de usar el template que no andaba utilice : X_@refdes %1 %2 %3 %4 @model, siendo Mode = DiodeBridge. El X_ le dice al backend que es una llamada a un subcircuito y @refdes es completado con el nombre elegido.

El siguiente paso es crear un archivo DiodeBridge.model en el directorio data/models que contenga la descripción del circuito. El resto de la mágia está ya en el código de generación de la netlist.

El objetivo ahora es tratar de extender más aún este nuevo feature y para eso voy a empezar con los ejemplos que encontró acá. Un punto importante y que yo realmente desconozco, es qué componentes son sumamente necesarios y deberían funcionar out-of-the-box. Si fuera por mí con resistencias ideales me sobra :P, por lo que escucho ofertas!.
El screenshot obligado (perdón, la ventana de plot ocupa mucho lugar y me tapa el fondo :-))

oreganomodels.png

Life

Facultad

Hoy empezaron las clases, y a diferencia de otros cuatrimestres tengo ganas de cursar :-). Tendré algo que ver que me anote en materias copadas?, seguramente ;-).

Estoy haciendo principalmente Teoría de Algorirmos II y Teoría del Lenguaje, y planeo aprovechar que curso con mi directora de Tesis para ponerle pilas.

Evince

Ya hace tiempo vengo aportando algún que otro parche a Evince, el visor de documentos de GNOME. Desde que comencía cerrar bugs de GNOME Love, había uno que me tenía atraido, y es el de agregarEvince New soporte para los comandos DVI Specials al backend de DVI. No es una tarea fácil, ya que me costó encontrar documentación sobre los comandos, y entender el código que se encarga de leer el archivo DVI.

Este fin de semana finalmente mande la primer versión del parche, a la que ya le contré por lo menos dos bugs :-), y eso que solo agregaba soporte para el color del texto :-D.

Anoche en un ataque de furia arregle los problemas anteriores y sume soporte para el comando background para ver el color de fondo de las páginas. Todavía tengo que arreglar un par de problemas pero ya casi está listo.

Evince OldLuego de eso quedan dos retos interesantes. El primero es el soporte de HyperText, que ya estuve jugando en mi primer intento de arreglar este bug y tengo idea de como hacerlo. Me falta resolver un problema de coordenadas y nada más. El componente más dificil va a ser mostrar las imágenes, ya que no siempre están presentes y pueden estar en diversos formatos. Veremos si logro hacerlo antes de aburrirme :-).

O.L.E. screencast!

Para aquellos curiosos hice un pequeño screencast de editor de componentes. Lo nuevo respecto de mi último post es la habilidad de modificar los puntos de control de los elementos y darles nuevas y alocadas formas :).

Por razones de sueño, no pude completar los puntos de control de lo elipces, por lo que no lo muestro en el video.

El screencast lo hice, como siempre, con vnc2swf y está acá y pesa casi 3Mb.

Oregano Library Editor!

Así como lo leen, ya estoy trabajando en un editor para las bibliotecas de componentes de Oregano. En principio para poder cambiar algunas que no me gustan mucho o que tienen detalles, después veré si la aplicación queda lo suficientemente linda como para hacerla crecer :-).

OreganoLibraryEditor.pngLuego de una frustrada búsqueda de algún Canvas (no iba a repetir los errores del pasado y usar GnomeCanvas :-)) decidí hacer uno minimalista, que soporte las operaciones básicas que requiero : Agregar cosas, moverlas y rotarlas. Salvo esta última, las demás están andando, con soporte Group y UnGroup

Y si, como ya se pueden imaginar la aplicación está escrita en C#, con Gtk# y Cairo#. Como el buildsystem depende enteramente de Monodevelop, no creo que libere código alguno por el momento.
En la captura se puede ver el diseño de un componente místico, conocido como Futirifoken 😀

UPDATE: Unos toque mágicos con el Stetic, un poco de magia de System.Xml.Serialization y un par de hacks para sacar la cosa más rápido y …

OreganoLibraryEditorWorking.png