Entries for C

Esto se puede deber a que se ha devuelto NULL en una función en la que se debería devolver algo (None por ejemplo):

static PyObject*
example(PyObject *self, PyObject* args, PyObject* kwargs)
{
    // do something
    return NULL;
}

se corrige de la siguiente forma:

static PyObject*
example(PyObject *self, PyObject* args, PyObject* kwargs)
{
    // do something
    Py_RETURN_NONE;
}

o porque al lazar una excepción, no hemos indicado de que excepción se trata:

static PyObject*
example(PyObject *self, PyObject* args, PyObject* kwargs)
{
    PyObject* var;
    // ...
    if(!PyBool_Check(var))
    {
        return NULL;
    }
}

y se corrige:

static PyObject*
example(PyObject *self, PyObject* args, PyObject* kwargs)
{
    PyObject* var;
    // ...
    if(!PyBool_Check(var))
    {
        PyErr_SetString(PyExc_TypeError, "Not boolean");
        return NULL;
    }
}

Llevaba cerca de dos días con un problema implementando el subscriptor MQTT. Aún no está hecho el diagrama de flujo ya que de momento estoy probando que las llamadas de la biblioteca funcionan. El escenario es el siguiente:

1. mqtt_connect
2. mqtt_subscribe
3. mqtt_unsubscribe
4. mqtt_disconnect

Conectamos el cliente, nos subscribimos a un topic, nos desubscribimos y desconectamos el cliente. Algo que a priori es sencillamente elemental.

Para comprobar que todo esto funciona he hecho uso del script para Wireshark que ya comenté. Pero el caso es que estaba encontrando errores en Wireshark que no eran lógicos. Yo mandaba un paquete de 17bytes y Wireshark decía que el paquete tenía 19bytes. ¿Qué estaba pasando aquí?

Continuando con el ejemplo de ayer, hoy voy a explicar cómo podemos parsear los parámetros de entrada. El estado actual es que hemos definido unos prototipos y los hemos añadido al módulo. Ahora vamos a darle contenido a las funciones add y hello.

Ejemplo en GitHub: mema_methods.

Para los programadores de C, C++, Java, ... puede resultar un tanto extraño la forma de gestionar los parámetros que tiene Python.

Voy a explicar en esta entrada los tipos de parámetros y cómo podemos hacer uso de ellos.

Ayer explicaba cómo se monta una estructura básica para crear un módulo. Pero para que el módulo sirva para algo, tendremos que añadir funciones.

Ahora vamos a ver cómo podemos crear nuevas funciones y cómo integrarlas al módulo mema. El objetivo para hoy será crear dos funciones: hello y add.

El resultado debería ser algo similar a lo siguiente:

>>> import mema
>>> mema.hello()
Hello mema!
>>> mema.hello('Vicente')
Hello Vicente!
>>> 
>>> from mema import add
>>> add(1, 2)
3
>>> add(400, 4)
404
>>>

Ejemplo en GitHub: mema_methods.

La semana pasada empecé ha hablar sobre los Bindings en Python. Hoy vamos a ver cómo es una estructura muy básica, cómo compilar y probar que todo funciona.

Un problema que me estoy encontrando, es que el API C de Python ha ido cambiando con las versiones. Entonces, muchos ejemplos que he encontrado no compilan y hay código muy diferente por ahí.

Inicialmente voy a centrarme en Python 2.7 (última versión de la rama 2.x) y si encuentro tiempo, haré lo mismo para Python 3.

Ejemplo en GitHub: mema_bare.

Hoy voy a hablar acerca de bindings para Python. Un binding es un módulo Python, escrito en lenguaje C, que permite realizar llamadas a funciones en C desde un script hecho en Python. Se puede ver como un "puente" desde C a Python.

Pueden existir distintos motivos para desear hacer un binding. En principio, puede parecer un poco contraproducente, ya que se pierde portablidad

Entonces, ¿por qué crear un binding? Bien es sabido por todos que C es más eficiente que Python, por tanto, si se trata de una parte crítica de una aplicación, perfectametne se puede hacer el procesamiento en C y dejar Python para la lógica.

Otra razón es aprovechar código existente en C. Como comenté, estoy trabajando en libemqtt, la cuál está escrita en C. Podría hacer una nueva implementación completa en Python, pero teniendo el código disponible, lo lógico es hacer un binding.

Los próximos días intentaré escribir una pequeña guía sobre cómo hacer un binding para esta bibliotecta.

Actualización (27/03/2012): He creado un repositorio en GitHub con los ejemplos que estoy implementando:

https://github.com/menudoproblema/menudoproblema-examples/tree/master/python/bindings

Hace unas semanas empecé a trabajar en una librería MQTT, con dispositivos empotrados en mente. La idea es que esta librería provea de las funciones de MQTT y así los clientes puedan encargarse de la gestión de la red. Con esto se puede reutilizar este código para distintas plataformas, cómo pueden ser Arduino ó LPC1768, pero también desde Linux.

Todo empezó cuando estaba evaluando distintas alternativas. Por casualidad me encontré con liblwmqtt en Google Code, desarrollada por Filipe Varela. Tras hablar con él, decidí hacer un fork y así nace libemqtt.

El código está disponible en Github:

https://github.com/menudoproblema/libemqtt

Continuando con la serie de artículos acerca de GTK, voy a seguir con Glade. Glade es una herramienta que nos permite crear las interfaces gráficas de forma gráfica :)

Esta herramienta es parte oficial de Gnome y se integra bastante bien con Anjuta, aunque esto no viene al caso. Glade genera archivos xml, que después, de forma simple y sencilla podremos cargar en nuestra aplicación. Estos ficheros pueden tener cualquier nombre y/o extensión, aunque tal vez la extensión más usada sea .ui (de User Interface) y será la que yo utilice.

Dado que ya expliqué como se realiza la compilación para GTK en el primer artículo, no lo volveré a explicar. Si alguien tiene dudas puede consultarlo aquí.

Código fuente

Aprovechando las prácticas de una de mis asignaturas, Informática Gráfica, voy a escribir unos artículos relacionados con interfaces gráficas, más concretamente GTK y algo más adelante, GTK y OpenGL. Como lenguaje de programación voy a utilizar C (la otra alternativa era Java, es decir, impuesto por la asignatura) y como sistema operativo utilizaré Ubuntu 10.10.

En este primer artículo vamos a ver qué necesitamos tener instalado, como crear una simple ventana y como compilar esto. Asumo que ya has programado alguna vez en C (y/o C++) y que build-essential lo tienes instalado.

Código fuente

Hace pocos días escribía acerca de como crear un toolchain para compilar para una arquitectura distinta: MIPS. Ahora voy brevemente a contar como podemos compilar un intéprete de Python para un dispositivo integrado.

El principal problema que hay es que para compilar para arquitecturas como MIPS o ARM es necesario un parche, por lo que la compilación directa no es posible. Yo he seguido este tutorial y he usado la misma versión, Python 2.7.1, y el mismo parche y todo ha funcionado perfectamente.

Ayer terminaba un artículo acerca de cómo construir un toolchain con crosstool-ng, pero ahora voy a explicar como utilizar uno de los ejemplos disponibles para partir desde una base concreta. Como ya comentaba, en la página de croostool-ng hay disponible una serie de ejemplos desde los cuales podemos partir.

Hace un rato explicaba en qué consiste la compilación cruzada y ahora vamos a ver como montar un toolchain para poder hacer esto. Para ello he elegido la herramienta crosstool-ng ya que nos permite automatizar el proceso.

En mi caso voy a generar una toolchain para generar código en una arquitectura MIPS, ya que voy a implementar algunos programitas para un router. Además, he elegido Debian Squeeze como plataforma de trabajo, pero también lo he probado sobre Ubuntu 10.04 con el mismo resultado.

Ayer hablaba brevemente acerca de newlib. Hoy voy a analizar otras dos librerías importantes: uClibc y EGLIBC. Ambas son compatibles con GLIBC, la biblioteca C de GNU.

¿Qué es newlib? Es una implementación de la librería C pensada para dispositivos empotrados y desarrollada por RedHat. Esta es la librería que algunos utilizan para dispositivos empotrados, ya hablaré más adelante de ella.