Depurar con gdb no es realmente complicado, al principio uno se siente tentado de usar printf’s(C)/std::couts(C++) como método de depuración, pero no!, invertir tiempo en aprender a usar mínimamente gdb es más práctico, más eficiente y además ahorra mucho tiempo. Hay mil manuales sobre gdb, aquí os propongo dos que he encontrado buscando a bote pronto, gdb-quickreference y esta guía, aunque la documentación oficial es genial.

En cualquier caso, ya de puestos, y suponiendo que os habéis mirado algo de gdb, buscando interfaces gráficas para el gdb encontré este que me ha gustado especialmente, cgdb. Es básicamente un gdb, en ncurses, pero con una ventana para ver el código con resaltado de sintaxis y la posibilidad de abrir el tty de la aplicación en otra subventana (para no mezclar la entrada/salida del programa con la linea de comandos del depurador).

Si ya sabes gdb, esto solamente será azúcar para tu debug

luarefvim es un plugin de vim que integra el manual de lua (actualizado a 5.1) y atajos de teclado para buscar en él.

+– — – — – + — – —  — – — + — – — – — – — – — –  — – — – — – — – — +
|#  edit  #|#    key     #|                                        |
|#  mode  #|#  sequence  #|#             action                   #|
+– — – — – + — – —  — – — + — – — – — – — – — –  — – — – — – — – — +
|@ normal @|  <Leader>lr  |  reference for word under cursor       |
|@ visual @|  <Leader>lr  |  reference for visually selected text  |
|$ any    $|  <Leader>lc  |  manual’s table of contents            |
+– — – — – + — – —  — – — + — – — – — – — – — –  — – — – — – — – — +

Aunque no se muy bien cómo titular esta entrada, este es un pequeño truco para desarrolladores. Vamos a tomar como ejemplo C++ y que cada uno lo extienda a su caso particular. Casi siempre en un proyecto el esqueleto de una cabecera para una clase y de su fichero cpp es muy similar, tanto que yo siempre acabo por crearme un “Dummy.h” y un “Dummy.cpp”, con esta pinta:

#ifndef _MyProject_DUMMY_HPP_
#define _MyProject_DUMMY_HPP_
#include "Referenced.h"
namespace MyProject {
    class Dummy : public Referenced
    {
    public:
        Dummy();
    protected:
        ~Dummy();
        Dummy & operator= (const Dummy&) { return *this; }
    private:
    };
} // end of MyProject namespace
#endif
//—— y este es el cpp ————–
#include <MyProject/Dummy.h>
namespace MyProject {
} // end of MyProject namespace

El código en si no es lo importante, en lo que hay que fijarse es que si usamos este fichero como plantilla hay mucho “Dummy” que cambiar por el nombre de la nueva clase. Para ello nada más fácil que:

:%s/Dummy/MiClase/g
:%s/DUMMY/MICLASE/g

El primero va bien, el segundo también, pero cuando llevas 15 te hartas de los “:%s”, y aquí viene el truco, dejemos que vim haga su faena:

function Dummy()
    let name = expand("%:t:r")
    execute "%s/DUMMY/".toupper(name)."/g"
    execute "%s/Dummy/".name."/g"
endfunction

Se invoca con “: call Dummy()” y hace toda la faena por ti tomando como nombre a reemplazar el nombre del fichero que estamos editando.

Glee es una pequeña librería multiplataforma + cabecera (gl.h) que permite programar siempre con la última versión de la especificación de OpenGL, en este caso la versión 2.1.

Glee cargará por ti dinámicamente aquellas extensiones que soporte tu tarjeta, sólo hay que tener en cuenta que aunque estés progrmando contra el API de OpenGL 2.1, es posible que tu tarjeta NO soporte ciertas llamadas, o ciertos formatos… las comprobaciones de las capabilities de la tarjeta se tienen que seguir haciendo ( en tiempo de ejecución ).

En resumen, el que prueba esta librería no vuelve a complicarse la vida con las extesiones de OpenGL.

Desde: OpenGL.org

Dado que no existía, hemos decidido crear una lista de lua en castellano. Se ha montado en google (ya total, con todo lo que saben de mi…) y se puede encontrar aquí:

http://groups-beta.google.com/group/lua-es?hl=es

Espero que todo aquel que quisiera preguntar, o bien que pueda ayudar y quiera hacerlo se apunte a dar soporte a la comunidad

Que un programa escrito en OpenGL hace diez años compile hoy día puede decir dos cosas: o bien que OpenGL es fenomenal y su diseño ha permitido crecer de forma monótona (siempre incrementando su api y nunca dejando algo deprecated) sin consecuencias o por el contrario OpenGL es compatible hacia atrás pero usar un estilo de programación de hace diez años tiene consecuencias.

La respuesta es: tiene consecuencias (y graves). ¿Cómo hacer que OpenGL vaya mucho más deprisa? para averiguarlo podéis ver este video de la última Blender Conference. Este video nos viene a contar desde qué punto de vista hemos de enfocar el uso de OpenGL hoy día, ya que el hecho de poder programar como hace 10 años no justifica el hacerlo teniendo en cuenta la penalización que eso supone.

Me ha gustado tanto que intentaré desglosar su contenido en pequeños posts, por si alguien tiene dificultades con el inglés.
Noticia original OpenGL performance programming.

Mientras que en Dreamhost no hay Goodie para instalar Trac, los usuarios se las han apañado para instalarlo y documentarlo. Pero lo mejor de todo es que se han currado un Script DreamTracInstall para hacerlo todo automático.

y funciona!

El RTTI(RunTime Type Identification) se puede usar para muchas cosas, lo más típico es invertir la herencia con un dynamic_cast:

    Base *ptr_base = ...;
    Derived *ptr = dynamic_cast<Derived*>(ptr_base);

Aquí las clase Derived hereda de Base, y un dynamic_cast permite saber si un puntero de tipo Base es en realidad de la clase Derived o no. Si devuelve algo distinto de 0 es que la conversión ha tenido éxito.

También se suele usar mucho el Typeid, tyepid( variable ) devuelve una clase que representa el tipo de esa clase, eso permite que los tipos se puedan comparar en tiempo de ejecución, obtener una representación en string del nombre de la clase typeid(variable).name()… etc.

Lo que no tenía tan claro es qué pasa cuando se hace algo como esto:

    Base *ptr = ... ;
    std::cout << typeid(*ptr).name() << std::endl;

¿Cuál es el resultado?
(más…)