Bitácora electrónica

martes, 19 de febrero de 2008

Mesa OpenGL - cannot restore segment prot after reloc

Descargué y compilé Mesa en mi directorio local y quise usarlo localmente, para no afectar lo que ya tenía instalado en el sistema. Todo iba perfecto, hasta que intenté ejecutar uno de los ejemplos: ./gears, tal y como indican las instrucciones bajo "Running the demos". El error que apareció fue el siguiente:

./gears: error while loading shared libraries: /home/[...]/Mesa-7.0.2/lib/libGL.so.1: cannot restore segment prot after reloc: Permission denied

No fue difícil encontrar en la red que este error se debe a SELinux. Lo que tomó un poco más fue encontrar cómo repararlo y resultó extremadamente sencillo. Entrando al directorio lib/ de Mesa, se modifica el contexto de las bibliotecas con el comando siguiente:

chcon -t texrel_shlib_t *.so

Al utilizar ls -lZ, podremos ver el nuevo contexto de las bibliotecas:


lrwxrwxrwx  _______ _______ user_u:object_r:user_home_t      libGL.so -> libGL.so.1
lrwxrwxrwx  _______ _______ user_u:object_r:user_home_t      libGL.so.1 -> libGL.so.1.5.070002
-rwxrwxr-x  _______ _______ user_u:object_r:textrel_shlib_t  libGL.so.1.5.070002
lrwxrwxrwx  _______ _______ user_u:object_r:user_home_t      libGLU.so -> libGLU.so.1
lrwxrwxrwx  _______ _______ user_u:object_r:user_home_t      libGLU.so.1 -> libGLU.so.1.3.070002
-rwxrwxr-x  _______ _______ user_u:object_r:textrel_shlib_t  libGLU.so.1.3.070002
...

Después de esto las bibliotecas recién compiladas de Mesa pueden ser utilizadas asignando la variable de ambiente LD_LIBRARY_PATH, tal y como se indica.

miércoles, 30 de enero de 2008

Páginas centradas con divs y css

¡Al fin lo logré!

Después de una cantidad increíble de intentos he encontrado dos formas verdaderamente sencillas de hacer páginas centradas.

El caso más trivial es cuando el tamaño del contenido es variable, como en esta página. Aquí basta con poner un margen simétrico para body:

body { padding-right: 30%, padding-left: 30%}

Puede hacerse con porcentajes o pixeles. No recuerdo si funciona igual con magin, para el caso, el problema está resuelto.

El problema se vuelve algo más complicado si lo que se quiere centrar tiene un ancho fijo. Este blog tiene esa propiedad, aunque no encontré entre todo el css una forma clara de cómo lo lograron. Encontré la mía. Funciona perfectamente en Firefox (linux y windows) pero desafortunademente, por alguna ilógica razón, alinea a la derecha en IE. El sitio resultante se encontrará aquí.

Se requiere crear dos divs (y un tercero por simetría). La primera funciona como una especie de marco, se usará para calcular el centro de la pantalla; la otra es para el contenido. La tercera es para rellenar el espacio vacío a la derecha. Algunos navegadores pueden pintar esta mitad de otro color si no se la rellena con algo.

El html deberá quedar así:

<body>
<div id="izquieda">
<div id="centro">  ...
</div>
</div>
<div id="der"/>
</div>
</body>

El css correspondiente es:

body { background:black; color:cyan; padding: 0px; margin: 0px;  font-family:arial; }
#izquierda { padding: 0; margin: 0; width:50%; position:relative; left:374px; }
#centro { padding: 0; margin: 0; float:right; width:748px; }
#der { padding: 0; margin: 0; float:right; }

Todos los margin y padding igual a cero están ahí porque no quiero márgenes, en otros diseños alguien podría querer experimentar con otros valores.

Ahora veamos porqué funciona:

Nótese que se desea que la región central mida 748 pixels. Con izquierda, al 50% de ancho, se obtiene la mitad de la pantalla. Ahora, lo que uno querría es utilizar la coordenada del centro de la pantalla para calcular e indicar alguna de las esquinas de la región central. Prové con varias combinaciones, pero la única que funcionó fue esta:

Con float:right, el lado derecho de la región central es alineada con el lado derecho de "izquierda", que se encuentra a la mitad de la pantalla. Lo que resta, es recorrerla 374 pixeles más a la derecha (la mitad de su tamaño). Sin embargo, los navegadores no entienden la petición si las cosas se salen de sus nodos padres. Por ello la solución fue empujar la región izquierda esta cantidad. Concecuentemente, su borde derecho se recorre y la región "centro" queda, efectivamente, en el centro.

jueves, 4 de octubre de 2007

Django, mod_python y SELinux

Hoy pasé algunas horas buscando una forma fácil de configurar mis aplicaciones de Django con Apache. Algo que me permitiera agregar aplicaciones sencillas y mantenerlas funcionando como si fueran scripts de php.

Lo más sencillo fue usar mod_python. Mi Apache ya lo cargaba y las instrucciones en la documentación de Django son claras. Como me agrada usar anfitriones virtuales, basta tener:

ServerName midominio.net
DocumentRoot /var/www/html

MaxRequestsPerChild 1 #Sólo para pruebas, si no es una grosería.

ServerName subdominio.dominio.net

SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonPath "['camino_a_un_directorio_arriba_del_proyecto', 'camino_uno_arriba_de_las_aplicaciones'] + sys.path"
SetEnv DJANGO_SETTINGS_MODULE [proyecto].settings
PythonDebug On

SetHandler None

SetHandler None

La parte truculenta vino de SELinux. Los proyectos de Django (y sus aplicaciones) no deben ir en la ruta de Apache, lo cual lo hace especialmente seguros. Sin embargo, al tener mis archivos, inocentemente, en algún profundo lugar de mi hogar, aunque agregara el directorio con PythonPath, me aparecía un error indicando que el módulo [proyecto].seetings no existía:

EnvironmentError: Could not import settings '____.settings'
(Is it on sys.path? Does it have syntax errors?): No module named wap.settings

El verdadero problema es que, no sólo apache debe tener los permisos normales de lectura, sino que toda la ruta hasta el proyecto (y todos los archivos de éste) deben tener el contexto para la web:

user_u:object_r:httpd_sys_content_t

Copiar mis archivos a un directorio en el que pudiera otorgar dichos permisos con

$ chcon -R user_u:object_r:httpd_sys_content_t [directorio]

resolvió el problema.

martes, 24 de julio de 2007

Script que obtiene el nombre del día de ayer

Por increíble que parezca, este ejemplo no es una ociosidad, lo utilicé el vida real para nombrar carpetas de archivos de respaldo:


#!/bin/bash
# +++++++++
# Calcula el dia de ayer.
# +++++++++

#
# Obtiene el nombre del dia de la semana almacenado en $NDIA.
#
getDia () {
  case $1 in
  1) DIA=lunes ;;
  2) DIA=martes ;;
  3) DIA=miercoles ;;
  4) DIA=jueves ;;
  5) DIA=viernes ;;
  6) DIA=sabado ;;
  7) DIA=domingo ;;
  *) echo "$1 No es un dia de la semana valido"
     exit $DIA_MAL
     ;;
  esac
}

NDIA=`date +%u`
getDia $NDIA
echo Hoy es $DIA

let "NAYER=$NDIA - 1"
if [ $NAYER -eq 0 ]
then
NAYER=7
fi
getDia $NAYER
echo Ayer fue $DIA

sábado, 19 de mayo de 2007

Capturas de pantalla - VLC

Dejo esto como un recordatorio:
* Tomado en parte del FAQ de VLC

Para poder tomar capturas de un video en ejecución se require:
(Linux)

Iniciar con vlc -V x11
Seleccionar Opciones -> Preferencias... En la pestaña Video, inidicar el directorio y el formato donde se guardarán las imágenes y el formato.
Presionar "Captura de pantalla" cada vez que quiera :)

Si no se cumple el paso 1, los otros dos no bastan, no se guarda nada. Sin embargo, tampoco es recomendable dejar vlc con -V x11 por defecto, pues la reproducción pierde calidad.

jueves, 12 de abril de 2007

MVC. Datos, lógica y vista.

Las vistas no tienen objetos, los objetos tienen forma de ser vistos.

Llevo un rato tratando de programar un manejador de contenido para páginas en la red. No es la primera vez que intento separar las tres famosas capas "datos, lógica y vista". Tradicionalmente, o al menos eso entendí en ingeniería de software, la capa de lógica se monta sobre la de los datos, y la vista sobre ésta. Sin embargo, surge de modo más natural escribir en los objetos cómo se ven estos, en lugar de tener una vista genérica que pueda mostrar a cualquier objeto y creo que la razón es sencilla: la forma en que se ven los objetos depende de sus propiedades. Entonces, una de dos, o no he logrado entender el concepto de las tres capas, o algo está chueco en su concepción. ¿Cómo puedo separar la presentación? Es claro que, el cómo se ve una cosa depende fundamentalmente de qué tipo de atributos tiene; si no conozco sus atributos y más aún, la semántica de esos atributos, es imposible que decida cómo debe verse.

En todo caso, se me ocurre que la idea de que las tres capas son independientes en, realidad, una falasia. A lo más, pensándolo como una pila, le concedo que la capa de datos sea independiente, ésta no requiere ser modificada si hay cambios en la lógica (control), ni en la vista. Pero a la inversa en ningún modo se cumple, por el contrario, si modifico el modelo, debo modificar la lógica que lo controla y la forma en que se ve. En el siguiente nivel: si modifico en control, lo más seguro es que tenga que modificar la vista. Por último, puedo modificar la vista (la puritita presentación gráfica, auditiva, etc.) sin tocar el control, ni el modelo.

Tal vez alguien más familiar con la técnica me diga ¡felicidades! ¡acabas de entender cómo se hace el hilo negro!

Sin embargo toda esta preocupación surge de un caso muy concreto: la intefaz de administración de django. Leyendo entre los correos de usuarios y desarrolladores, hay cierta molestia por el hecho de que el código que define la presentación en la administración está dentro de los modelos, siendo que estas dos capas no debieran trabar contacto.

El problema, como he llegado a verlo, es que los modelos (tablas en una base de datos) no representan más que una manera de hacer persistentes a los objetos, pero las bases de datos no pueden incluir toda la lógica de sus interacciones, ésta en realidad se mantiene en la capa siguiente (gracias al artículo de la Wikipedia). El problema es que ¿quién puede saber de antemano lo que será puesto en la capa lógica? Las implementaciones en las bases de datos limitan claramente qué puede ser almacenado ahí (tipos de datos, relaciones, etc.), pero en la lógica uno puede escribir prácticamente lo que sea. ¿Cómo podría entonces crearse una vista genérica, sin descender a los modelos?

Peor aún, y aquí viene mi muy particular dilema: ¿qué pasa cuando uno requiere hacer persistente cómo se ven los objetos? Es decir, que la forma en que los modelos son vistos en pantalla, también forma parte de los datos. ¿Cómo mantener aquí la consistencia sin que la capa lógica se convierta en una locura?

Por el momento intento que cada nuevo elemento contenga 3 cosas: su propia forma de ser persistido, su lógica y ... opciones para ser visto pero... éstas son las que ya me cuesta más trabajo definir en una manera consistente para todos los elementos (evitando abundar en los códigos especializados a cada caso), esto debe ser lo más general posible.

Me gustaría que los elementos que están contenidos dentro de otros simplemente extendiesen la presentación de sus contenedores, como funcionan los css y evitando persistir la información de la presentación en los mismos modelos (tablas) que el contenido en sí del objeto. De modo que, hasta donde voy ahora... mi modelo parece quedar igual que la administración de django: el objeto tiene la liga a "cómo se ve". ¿pero qué no es eso lo natural? ¿que las cosas tengan una apariencia y no la apariencia a las cosas?

miércoles, 4 de abril de 2007

Juegos II y pygtk

Se me ocurrió actualizar python, pasándome a la versión 2.5. Obvio, tuve que reinstalar todo lo que ya tenía :( django, psycopg, etc., etc. y pygame!

Siguiendo el procedimiento de Juegos I, ahora debí bajar Numeric, ojo, debe ser el viejito (el del 2005), Numpy no satisface los requerimientos.

También hubo que reinstalar OpenGL y pygtk. Este último fue el más problemático: hubo que instalar un nuevo pyobject, en Fedora 5, éste quedó en /usr/local/lib/python2.5/site-packages/gtk-2.0/gobject pero al hacerlo aún detectaba la versión anterior (Requested 'pygobject-2.0 >= 2.12.1' but version of PyGObject is 2.8.4). Tal parece que esto es porque no se instaló como biblioteca del sistema, de hecho, al instalar, aparece el siguiente mensaje:

/usr/bin/install -c -m 644 'pygobject.h' '/usr/local/include/pygtk-2.0/pygobject.h'
...
----------------------------------------------------------------------
Libraries have been installed in:
/usr/local/lib/python2.5/site-packages/gtk-2.0/gobject
...
----------------------------------------------------------------------

configure usa libtool, por lo que debe bastar con indicarle este directorio de alguna manera.

Entonces, antes de invocar .configure, intento exportar las variables:

# export PYGOBJECT_CFLAGS="-I/usr/local/include/pygtk-2.0/"
# export PYGOBJECT_LIBS=/usr/local/lib/python2.5/site-packages/gtk-2.0/gobject

Pero aún falta pycairo (intenté compilar sin él, pero sigue habiendo errores).
Con cairo es la misma historia: compilo e instalo cairo 1.4.2 y queda en:

----------------------------------------------------------------------
Libraries have been installed in:
/usr/local/lib
...
----------------------------------------------------------------------
/usr/bin/install -c -m 644 'cairo.h' '/usr/local/include/cairo/cairo.h'
...

Así que, para pycairo asigno:
# export CAIRO_CFLAGS="-I/usr/local/include/cairo"
# export CAIRO_LIBS="-I/usr/local/lib"

Y sigo las instrucciones de instalación... Dice que sí... ¡pero pygtk sigue sin funcionar! Y ya me cansé... me voy a dormir y ya mañana veo.