[pyar] Problema con deadlock/starvation en __import__ dinamico dentro de un thread usando xmlrpc en el principal

[SAn]

2011/4/14 Leonardo M. Rocha <leo.m.rocha en gmail.com>:
>>
>> La idea está genial. Yo vengo hace rato dándole vueltas a lo de las
>> cadenas de procesamiento. El mayor problema que encuentro es que la
>> simplicidad va casi siempre en contra de la performance y no me decido
>> en qué punto quiero pararme para que sea fácil de usar y pensar pero
>> que sirva.
>
> Yo estuve con el dilema por varios meses y me decidí por lo siguiente:
> Armarlo lo más genérico posible, que la configuración sea difícil no
> me importa, mientras después pueda armar una herramienta que me
> facilite armar las configuraciones.

Claro, entiendo. Es una buena opción. Sobre todo teniendo en cuenta a
lo que apunta.

Otra cosa que podrias mirar, que está muy bien diseñada, es Clam (C++
http://clam-project.org/). Está pensado para procesamiento de audio,
pero el tema de las configuraciones y modificaciones online está
buenisimo. Incluso están trabajando en uan interfaz python para
modificar las redes.

> Por la performance no me molesté al principio, pero después hice
> muchas pruebas (la idea era publicar algo pero no llegamos a hacer lo
> suficiente antes del deadline) y comparamos resultados de aplicaciones
> de video, incluso haciendo cambios dinámicos de configuración con
> varias distintas cosas. Los resultados; negligible overhead comparando
> con aplicaciones estáticas (sin reconfiguración) escritas puramente en
> C++ (al menos para nuestros experimentos de video). Un caso: face
> detection usando como módulos las librerías de OpenCV haar: con
> framework ~5 fps, en C++ puro ~5 fps. (notese que la librería clave
> está en C .. es OpenCV)

Muy bueno!

> Si hay alguien interesado en colaborar, ver, usar, saber un poco más
> por curiosidad, me contacta por privado y continuamos.
>
>>
>> La verdad es que no conocia PylabWorks...genial el dato, lo voy a mirar.
>>
>> Te paso un proyectito que estuve haciendo que hace algo *mucho menos*
>> ambicioso que PylabWorks: https://bitbucket.org/san/stream_grapher/.
>> Ahora lo que quería era portarlo de Pyglet a PyQt, (en realidad quería
>> usar pyglet + pyqt pero parece que no se puede sin armar un bardo).
>
> Gracias!
> Le voy a dar una mirada en estos días

No te entusiasmes mucho! Es *muy amateur* pensado para que lo puedan
hackear amateurs. Justamente en esta última afirmación es que el tema
de los filtros todavía no lo pude resolver. Quiero que todo el
framework sea sencillo de entender hasta para alguien que no sabe
python o está aprendiendo.

Mantenenos al tanto del proyecto ;)

Saludos y éxitos,
SAn