Instalando con python

Para instalar con python, el paquete estandar es distutils [distutils-sig].
Una alternativa es usar setuptools, que se supone incorpora ciertas mejoras sobre distutils.

Para distribuir código python nos vale. Si ademas nuestro proyecto require de versiones de librerías o de aplicaciones externas y queremos comprobar las dependencias, necesitaremos alguna herramienta adicional, tipo GNU Build System (GBS).

La mayor limitación de GBS es que es para UNIX, por lo que si queremos instalar en windows, necesitaremos cygwin. Una alternativa a usar cygwin es MinGW.

Me pasan hoy este link: How To Write Unmaintainable Code .
Antiguo, pero a la vez actual.

MAC OS X

Estos tios de apple la verdad es que son unos genios. Me he enterado hace poco que el OS de apple está basado en BSD, vamos... que está basado en UNIX. Un motivo mas para querer un MAC. Podeis comprobarlo.

Configuración de arranque de windows

Hoy he descubierto un comando superutil para ver que programas/servicios se ejecutan cuando arrancamos un windows, y para poder modificar el comportamiento. Se trata de msconfig.

Cuanta razón en estas palabras: Cuando la Informática se pervirtió.

Alternativas a SWIG

Me está siendo duro usar swig...
¿Porque estoy usando swig? Pues sencillo porque en otra parte del proyecto se ha usado para acceder a C++.
Pero buscando información me he encontrado con que hay alternativas:

• SIP
• ctypes
• Boost::Python

Parece que la gente del grupo de python o que menos le gusta es SWIG. Por ejemplo:

"The best thing to do is to offer your C++-lib with a C-style interface. Then you can use python's ctypes (included since python2.5) to access the shared library.
If you insist on using C++, you can expose the lib using several available wrapper generators. I know of three: SIP, Swig & Boost::Python. The first I've got some very good first-hand experience. The second is somewhat primitive IHMO. The third I never used. "

El que diga que ctypes está incluido desde python2.5 no quiere decir que no se pueda usar con versiones anteriores.

Al respecto ver los mitos sobre swig.

Otro módulo interesante es pyrex.

Va de clientes Jabber...
Si queremos acceder a esta red tenemos varias opciones (entre otras) de gratis:

• miranda (windows)
• adium (MacOSX)
• pidgin (fka: gaim)
• kopete (linux)

Estoy que lo rompo!

Me pasan un portatil para el curro y creo que no me ha durado ni un mes.
Se ve que venía de serie con un 'xp media center' y lo transformaron en un 'xp pro' y así ha ido.
Bueno el jueves me lo dan ya de nuevo en teoria con un 'xp pro' instalado desde cero. Pues na que me pongo a enredar con el linux (live cd) para ver si logro hacer una imagen del sistema y ya me lo he cargado.

¡¡¡¡¡GAAAAAAAAAAAAAAAAAÑAAAAAAAAAAAAAAAAAAAAAAAAN!!!!!

No se como, pero supongo que me he cargado el MBR. La verdad es que el particionamiento que tiene es raro de cojones.... Como me de la lata lo particiono de otra manera...

C: es la unidad de datos (/dev/sda2 y bootable)
D: es la del sistema (/dev/sda5 (unidad lógica sobre /dev/sda1)

Y luego tengo espacio libre para meter un linux.

Antes de enredar me salve el MBR (por supuesto) pero no se porque me da que va a estar en sda2...
También salvé la tabla de particiones y según vi seguia igual.
Resumiendo no se que puede haber pasado.

Seguiremos indagando...

Con que cara les voy a llevar a los pobres chavales de sistemas el portatil de nuevo para qu eme lo instalen.... Me da que voy a apañarmelas por mi mismo.

[swig] Primeros pasos

La forma mas simple de generar los bindings es usar %include [el_fichero.h].
Pero es dificil que sea una buena idea, a no ser que lo que se quiera usar sea algo muy sencillito.
Según la documentación recomiendan una serie de pasos:

• "Identify the functions that you want to wrap. It's probably not necessary to access every single function in a C program--thus, a little forethought can dramatically simplify the resulting scripting language interface. C header files are particularly good source for finding things to wrap.
• Create a new interface file to describe the scripting language interface to your program.
• Copy the appropriate declarations into the interface file or use SWIG's %include directive to process an entire C source/header file.
• Make sure everything in the interface file uses ANSI C/C++syntax.
• Make sure all necessary `typedef' declarations and type-information is available in the interface file.
• If your program has a main() function, you may need to rename it (read on).
• Run SWIG and compile."

Resumiendo.... que mejor solo hagas bindings para lo que realmente necesitas.
A continuación pongo otra parrafada interesante, sobre porque usar interface files.

"Although SWIG can parse many header files, it is more common to write a special .i file defining the interface to a package.
There are several reasons why you might want to do this:

• It is rarely necessary to access every single function in a large package. Many C functions might have little or no use in a scripted environment. Therefore, why wrap them?
• Separate interface files provide an opportunity to provide more precise rules about how an interface is to be constructed.
• Interface files can provide more structure and organization.
• SWIG can't parse certain definitions that appear in header files. Having a separate file allows you to eliminate or work around these problems.
• Interface files provide a more precise definition of what the interface is. Users wanting to extend the system can go to the interface file and immediately see what is available without having to dig it out of header files."
  

Un ejemplo de dos posibilidades de definicion. Una primera teniendo el fichero de interfaz:


/* File : interface.i */
%module mymodule
%{
#include "header.h"
%}
extern int foo(double);
extern double bar(int, int);
extern void dump(FILE *f);


Y la segunda (que en este caso estaría justificada por ser el fichero muy sencillo):



/* File : interface.i */
%module mymodule
%include header.h


Por ejemplo si usamos la ultima aproximación con libcroco, debemos usar el flag --includeall e indicar con -I las rutas de todos los ficheros necesarios (incluyendo los del sistema), generandose mucho codigo, cuando lo que necesitaremos será simplemente una función y acceder a unas estructuras de datos.
Es mas.... posiblemente al final la aproximacion mas facil será crear unas funciones de utilidad en C, y ya hacer los wrappers a dichas funciones de utilidad con swig.

Nota: un flag interesante es -v.

[swig] Formato del fichero de interfaz

Una cosa que no esta bien explicada, o al menos no como un punto en la documentación (o al menos no lo he visto) que es el formato del fichero de interfaz, y una lista con las directivas soportadas.

En el fichero hay una serie de bloques que el formato [etiqueta] %{ %}.
Donde [etiqueta] puede ser:

• %runtime
• %header
• %wrapper
• %init
• %inline
  

Si no se pone la etiqueta, estamos ante un bloque de tipo header.
El '%' es porque es el formato de las instrucciones para swig.
Por ejemplo el nombre del modulo en python se especifica con %module.

Todas esas etiquetas, con la excepcion de inline) sirven para incluir codigo que será includo en el fichero generado para el hacer el wrapper. No se parsean ni se generan los wrappers.
La excepción es inline: el codigo inline se da al compilador de C y a swig.

Un ejemplo de uso de inline lo tenemos en el primer ejemplo de swig: simple. Como no existe un header se meten las declaraciones en un bloque inline.

Si por el contrario tenemos un header, lo normal será usar el bloque %header y luego ya a continuación indicar las funciones para las cuales queremos generar los wrappers.

swig

En este post os presento a swig, el cual es una herramienta que nos permite 'conectar' programas escritos en C/C++ con programas escritos en lenguajes de script: como python, ruby, ...

Básicamene lo que hace es coger unas definiones y generar los wrapper necesarios para acceder al codigo C/C++,

En mi caso lo usaré para acceder a libcroco desde python. O bueno al menos eso intentaré.
Lo suyo es usar la version mas actual de swig, la 1.3.X. Sobre todo si estas con python 2.X.

Una de las cosas que sorprende es la calidad de la documentación. Da una imagen de un producto currado.

La mejor forma de empezar es tras bajarlo e instalarlo, echarle un vistazo a los ejemplos, que vienen bien documentados.

Según lo vaya creyendo conveniente pondrá algun post...

Hacía mucho no visitaba a Telendro. Demoledor post sobre la información que puede manejar google sobre una web: Regalar toda la información sobre tu web a google.

Google is sicko.