Genie, o por qué tuve que dejar Python

Expositor: Sandino Flores (tigrux)

Moderador: Sergio Infante (neosergio)

Sabado 27 de Febrero del 2010 17hrs UTC

irc.gnome.org #gnome-hispano 

Saludos a todos.

o/ tigrux 

:)

hola sandino

que tal

Hoy quiero contarles una historia.

No, no será un tutorial de Genie.

Tampoco será uno de python.

será una aventura?

Les voy a contar una historia.

Y les pongo un poco de contexto: tengo 7 años usando python.

Lo he usado para aplicaciones de escritorio, servidores y hasta embebido en bases de datos.

Es un lenguaje que conozco bien, si ser experto.

tigrux, antes q sigas, no sé si todos te conocen

Ahh... cierto.

Soy graduado en física, trabajé primero en Ximian, luego en Novell cuando el pez grande comió al chico.

Sandino Flores, graduado en física, usuario de gnome desde 1999, actualmente trabaja como contractor para Dextra Technologies, desarrollando aplicaciones para embebidos con software libre, para la división de inalámbricos de Texas Instruments, basadas en gstreamer, gtky omx.

sandino es un hacker mexicano buena onda

Eso, eso!

:)

:)

Pues bien, llego a mi trabajo actual.

Y va agarrando forma.

Gstreamer comienza a trabajar bien,

En la plataforma omap de TI.

Básicamente, teníamos multimedia en protos.

Donde esos protos, dependiendo del cliente, se vuelven celulares, pdas, etc.

Básicamente es el mismo hardware que tiene un smartphone.

Por supuesto, necesita un sistema operativo

Desde aquellos años (2006) linux era ya muy importante.

Porque, al no requerir "royalties", es parte de lo que Texas Instruments provee como parte de sus paquetes.

Tal que los clientes estudian el entregable de TI, y derivan lo suyo.

Pero había un problema:

Teníamos casi todo.

Teníamos linux en el omap, un escritorio muy básico, pero no teníamos aplicaciones!

Aplicaciones gráficas me refiero.

Para hacer pruebas internas.

Algo en que el tester pudiera simular lo que haría un cliente.

Como sabrán, es muy fácil hacer compilación cruzada.

Bueno, hay detalles, pero en general parece fácil hacer compilacíon cruzada.

Es decir, que compiles en tu máquina 386.

Pero el código generado sea ejecutable en un arm.

Y entonces, python parecía muy buena opción.

A saber: es portátil, permite desarrollar rápido, y tiene muchos bindings.

Suena bonito.

Y lo fue.

Durante mucho mucho tiempo.

Pero.... pasó el tiempo, de hecho dos años.

Y se fueron añadiendo más y más requerimientos.

El software original escrito en python se hacía más y más grande.

Y requríamos más y más cosas.

Y comenzaron los problemas....

Cuando el software era chico, era muy fácil considerar prácticamente todas las situaciones.

este era solo software para pruebas, no? es decir no era para usuarios finales en absoluto

diegoe: Así es, era interno.

Pero, precisamente, querían algo que los clientes pudieran recibir.

Sigo...

Sabrán ya que python es interpretado.

O sea que puedo hacer lo siguiente:

n = get_algo_de_algun_lado()

has_algo(n)

Pero.... cómo sabes de qué tipo es lo que se recibe?

Cómo garantizas que siempre mandes el tipo correcto?

Esa flexibilidad de python, se fue haciendo un problema.

Detalle numero 1: el ser tan dinámico, hacía que python fuera difícil de depurar.

Luego, vino lo de los requerimientos que había que soportar.

Por ejemplo, tuvimos que añadir un control de volumen.

Cómo controlas el volumen del audio? Fácil, con alsa.

Y en python? Pues con pyalsa.

Y suena tan simple como: apt-get install python-alsa. Cierto?

Pues no!

Porque en un proyecto, hay integradores.

Y esos integradores, necesitan cierto tiempo para meter los paquetes a la mini distribución.

Qué ocurre?

Que mientras el integrador hace su trabajo de leer tu correo, tomar su café, pedir autorización, recibirla, buscar fuentes y parches....

Y un largo etc...

Estás parado!

Porque no tienes los bindings.

Sin embargo, te frustra porque tu stack ya tiene alsa.

Pero no la puedes usar directamente!

Detalle número 2: con python requieres tener los bindings disponibles.

Como referencia, para ese control de volumen, quise usar el control de volumen de gtk 2.14.

Porque tenemos gtk 2.14 en la distro.

Pero.... oh decepción....

El pygtk que el integrador puso, es el 2.10.

Con la excusa de que, por un widget, no va arriesgarse a actualizar y romper todo....

Burocrático, pero es el común en cualquier empresa.

Luego de la charla: el log estara aqui http://es.gnome.org/Eventos/CharlasIRC/CharlaFebrero2010

Y siguen los problemas.....

Los dispositivos de nueva generación, hacen maravillas.

Como desplegar videos a 1080p.

Sí, una cosita que cabe en tu manos puede decodificar videos de esa resolucíon.

Pero.....

Eso requiere muuuuuuuucha memoria.

Y entones, nos topamos con la sorprecita, que cuando tienes python con digammos gtk, alsa y otras cosas, tienes muchas cosas en memoria.

Y la gente que hace los decoders, valida que su código requiera, digamos 240 megas de ram.

Y el sistema tiene, digamos 256.

tip para los que usan mibbit: coloquense un nick para poder identificarlos con algún nombre

Ya sabrán.... no queda mucha memoria disponible.

Detalle número 3: un lenguaje interpretado requiere no sólo la memoria del intérprete, también la de sus bindings.

O sea, al usar pygtk, tienen el runtime cargado de glib, gtk, pygtk, etc.

Así que me prohibieron usar python. :-P

Ohhhhhhhh frustración, qué iba a hacer?

tigrux, lo q normalmente en un escritorio no consideramos como diferencia significativa, no?

diegoe: Exacto.

Para fines prácticos, te importa un pepino que tu firefox se trague 50 megas.

Porque tienes 2 gigas de ram.

Pero en el embebido, tus recursos son limitados.

No había más remedio: había que recurrir a C.

O no?

Han oído hablar de Vala?

Vala es bueno, ya habló de él Alberto Ruiz.

Pero, el detalle es que ya tenía mucho código en python.

No quería reescribir todo, o de hacerlo, que fuera lo más fácil posible portarlo.

Y aquí entra Genie. :-)

Genie usa el mismo compilador que Vala.

Porque el nombre de Genie?

OberPorta: Supongo que fue idea del creador.

No hablaré de Vala, más que decir que es un lenguaje inspirado en C#, para gnome, y que se compila a C.

Y genie?

http://live.gnome.org/Genie

Echémosle un vistazo.

Se parece a python.

De hecho combina lo mejor de python, con características de otros lenguajes.

Pero, como se compila a C, lo trabajo desde mi escritorio.

Genero fuentes en C.

Y esas fuentes en C las paso a mi árbol de fuentes, en git o lo que sea.

El integrador no ve que haya fuentes en Genie.

El sólo cuida de que sea C, y que se compile como el tux manda: con autotools.

Nada de setup.py y que si tu python no se instala donde debe....

Acá es simple y plano ./configure && make && make install

O en términos de poky y OpenEmbedded: inherit autotool

(autotools, perdón)

Ventajas de Genie:

1) Tiene una sintaxis casi igual a la de python.

Entonces, es muy fácil portar.

2)Se compila a C.

Entonces, no requiere runtime, y puedes armar fácilmente bibliotecas compartidas, etc.

3) Es de tipado fuerte

Eso quiere decir, que tienes garantía de que tu código atrapará muchos errores que en python requerirían tedioso prueba-y-error.

Permítanmente elaborar en este aspecto:

En python, los errores de semántica, no se atrapan sino hasta que entra a ese código afectado.

Es decir, no porque algo esté bien escrito, quiere decir que haga las cosas bien.

En Genie y Vala, muchos de esos errores son atrapados por el compilador.

Por ejemplo, algo como lo siguente:

process_list(una_lista)

Supongamos que sea python.

Cómo sería la función?

def process_lista(lista): ...

Dónde ves lo que recibe?

Dónde ves lo que regresa?

Entonces, podrías pasarle un argumente equivocado, y no te darías cuenta hasta probarlo.

Ahora, supongamos que es C.

Sería algo así:

void process_lista( GList *lista)

En el peor de los casos, si le pasas un argumento equivocado, te dirá el compilador que estás pasando un puntero de otro tipo.

En el mejor, sólo validará si le pasas algo que no sea puntero a lista.

Entonces, no tienes garantía de pasarle la lista que contenta lo que quieres.

Y en Vala?

void process_lista( List<string> lista)

Ahora sí, vemos claramente que es una función que recibe una lista de cadenas.

Y en Genie?

process_lista(mi_lista: List of string)

Lo cual es aun más expresvo.

Código código han de gritar algunos!

http://github.com/tigrux/omap-media-apps/

Allí tengo algunos de los programas que he tenido qué hacer.

Pero veamos un poquito de azúcar sintáctica.

Supongan que tienen un control de vista de íconos.

Donde los íconos obtenidos de procesar imágenes.

Pero, las imágenes se deben decodificar por hardware.

Por supuesto, no esperas que la vista de íconos se bloquee mientras los lees.

Deben aparecer suavemente.

Ello implica una operación asíncrona:

Leer y desplegar los íconos, al tiempo que tu UI es responsiva.

En otors lenguajes, tendrías que echar mano de hilos.

Pero los hilos, tienen riegos inherentes.

Y en glib, echarías manos de functiones como g_idle_add, pero requiere un buena abstracción de tu parte.

En genie como en vala, ya hay soporte de funciones asíncronas.

http://github.com/tigrux/omap-media-apps/blob/master/imageview-app/iconlist-control.gs#L114

eso no sabía, q maravilla

Ese método, se mira perfectamente lineal.

Allí ven que dice: tu pipeline de imagen leerá una imagen, y espera a que termine.

Le dices que espere en el yield.

Y entonces gstreamer comienza a trabajar.

qué hace yield precisamente?

Y cuando haya terminado, la función continúa y rellena el ícono y lo agrega a la vista.

diegoe: Hace que la función espere.

Es decir, la función hace "yield" (cede el control).

Las señalesde tránsito "Ceda el paso", en inglén dicen "Yield".

(http://live.gnome.org/Vala/Tutorial#Multi-Threading)

Ohhhh..... no.

Esto no requiere hilos. :-)

:o

Es a través del mecanismo de g_idle_add de glib.

Pero eso es tema de otra charla, basta decir que le dices que glib ejecute cosas en cuanto pueda.

Ahora bien...

Quién lo despierta?

Gstreamer.

http://github.com/tigrux/omap-media-apps/blob/master/imageview-app/iconlist-control.gs#L170

Eso fue una muestra de las muchas facilidades que da Genie.

Puntualizando:

1) Nunca estés dispuesto a dar la vida por tu lenguaje favorito a menos que tengas tendencias suicidas.

2) Los lenguajes de script, como python o ruby, son buenos para hacer prototipos, pero no esperes algo muy grande.

Porque?

qué sería algo "muy grande"?

OberPorta: Porque, por ser dinámicos, muchos errores que de ordinario serían errores de compilación, terminan siendo desastres en tiempos de ejecución.

ceronman: Básicamente, un programa grande es aquel donde es imposible que tú mismo pruebes todos las posibilidades de ejecución.

Por ejemplo, si tienes una ventana donde quieres ver mensajitos de twitter en tu escritorio, es algo que está bien controlado.

Pero cuando tienes algo con muchas posibilidades de fallo, no te arriesgues a dejar pasar errores que bien atraparía tu compilador.

3) Con Vala y Genie, no quieres bindings, así no te limitas a paquetes adicionales de tu distribución.

4) Genie y Vala, pese a ser compilados a C, proveen facilidades de muy alto nivel.

Y en todo....

De esto quería platicarles hoy. :-)

(Quise decir: es todo)

Luego de la charla: el log estara aqui http://es.gnome.org/Eventos/CharlasIRC/CharlaFebrero2010

Osea C  va a seguir siendo como la madre de todos :)

hackob: Tú eres apasionado de C# y mono. Cierto?

tigrux luego podriamos contar contigo para algo mas de genie como algunas demos?

+/-

neosergio: Claro, de hecho ahora es mi pan de cada día.

no moriría por él :)

:D excelente tigrux ya programamos para una proxima charla de puros ejemplos

hackob: El ceyusa ahora también es fan de Vala. Sabías?

tigrux: muy buena la charla, yo no conocía Genie

Gracias, y gracias por tenerme paciencia.

http://code.valaide.org/

al contrario, gracias tigrux por el tiempo invertido

Allí hay muchos ejemplos de vala y genie.

gracias tigrux excelente charla

tengo una duda/comentario

gracias tigrux

Así le hacemos.

Gracias a diegoe por invitarme.

en el ejemplo de process_list(), es cierto que Genie mostraría los errores de tipos al momento de compilar, python, en cambio, no lo haría

pero pueden haber otros errores en la forma en que se programó process_list(), errores de programación

ceronman: Y tampoco C, por desgracia. :-/

esos no los advertiría el compilador

ceronman: Claro, pero la idea de un lenguaje de tipado fuerte, es que atrape la mayor cantidad de errores.

los programadores siempre cometemos errores, por lo cual un buen programador siempre debe probar su código

por ende siempre hay que probar process_list

tigrux, valac no te avisaba de posibles burradas tmb?

diegoe: Claro que te avisa.

y si probamos process_list en python nos daríamos cuenta de cualquier error de tipo

diegoe: Por eso puse cómo sería la firma de función en Vala y Genie.

es decir que si como buenos programadores, siempre probamos nuestro código, no vamos a tener errores de tipos en python

no?

ceronman: Es cierto, pero el problema es que es imposible no equivocarse.

tigrux, digo, de cosas q no son errores indiscutibles, sino de errores q pueden ser mala programación

diegoe: Vala te avisa de errores potenciales.

Pero eso ya pasa por el programador :(

diegoe: Por ejemplo, al usar una variable no instanciada.

ya, igual más o menos como gcc no?

diegoe: De hecho, en vala no puedes usar una variable si no está instanciada.

diegoe: Sí, pero en cc son warnings.

diegoe: En Vala, son errores.

Bueno, regreso a programas.

si hacemos process_list y simplemente no la probamos, Vala o Geanie nos van a servir porque nos van a avisar de posibles errores con los tipos de los datos

programar

pero es mala práctica dejar las cosas sin probar

ceronman: Exacto!

Y es que, consideren el siguiente caso.

:o

si sí las probamos, entonces vamos a captar no sólo los errores de tipos sino otros posibles errores

Tienen una API, muy bella.

sea con python, vala o lo que sea

Que tiene módulos cargables.

Y entonces, alguien hace módulos para su programa.

Quién les garantiza que esa persona sea disciplinada y haya leído la referencia de su API?

Por eso la importancia de atrapar errores lo más pronto posible.

el punto de mi comentario, es que creo que si uno es juicioso a la hora de probar el software que uno escribe, no va a haber mucha ventaja de Vala o Genie sobre Python

ceronman: Sí, pero la vida no es blanco y negro, tiene matices.

tigrux, Siempre puedes usar -Werror ;)

jjardon: La cual no atrapará errores como el de la lista.

Nos leemos.

Tengo que irme ya.

Un placer estar aquí.