Mariano Reingart: A new web2py online python debugger

I've finished a new online debugger, based on my previous work on qdb module (bdb/pdb enhancement):

In contrast with pdb, this debugger is based on a client/server model, so it should be more stable and extensible than my previous approach (a piped command line loop, see current module, a naive attempt to use pdb in a web environment, it is mostly undocumented as it requires some advanced python skills to use pdb commands without blocking the whole web2py server).
In fact, qdb is based on the python bdb debugger framework (borrowing most commands from pdb), and it comes with a CLI, a separate GUI frontend (using wxpython), and for web2py, this totally web based interface.

Although this blog post is about web2py, qdb can be used to make debuggers for other frameworks too, you can use WebDebugger as a base to make controller/views with your favourite web stack.

Currently, this web2py debug implementation uses threads (debug and web ui, automatically managed by default web2py development server) and queues to communicate between them, but this can be extended to use multiprocessing client/listeners or anything with that interface (send, recv and poll, using socket or pipes).


The web2py package with integrated debugger can be downloaded from my site:

The full source code and revisions are in my web2py repo clone in googlecode:

You can download it with mercurial: 

Also, if you have the latest trunk, you can patch it with:

(the changes are in the default branch so will not create nasty repository effects)

Brief Changelog:

web2py is great because it is small and concise, so most changes are less than 100 lines (and some were trivial):
  • added gluon.contrib.qdb , the debug backend and basic frontend
  • updated gluon.debug to create the qdb client/server debug queues and the web frontend
  • updated applications/admin/controller/debug with interact and breakpoints controllers
  • added applications/admin/views/debug/interact.html and breakpoints.html
  • updated applications/admin/views/default/edit.html to add toggle breakpoint button
  • updated applications/admin/models/ to add top-level debug menu
  • updated applications/admin/js/static/ajax_editor.js (toggle breakpoints) and style.css
  • updated gluon.html.CODE and gluon.highligh to show the context relevant lines 
The full change log is available in the repository here. It took me less than 8 hours to add a debugger to web2py, very nice!


Basic interaction (step, next, continue, return, stop, etc.), with the highlighted code, locals/globals and a interactive console to execute python statements in the debug environment.
Access it from the added "Debug" main menu button (or go to http://localhost:8000/admin/debug/interact):

To evaluate an expression, enter it in the second textarea, press enter and it will be executed in the debugger.

The result, if any, will be shown in the upper textarea. You can execute any valid python command, including python assignment statements.

To execute the current statement, press step. If you do not want to enter to functions, press next. To run the program until it finish or a breakpoint is reached, press continue. To cancel execution, press stop.

Breakpoints (including temporary and conditional ones, with hit count) can be accessed from the Breakpoints button at the main debug page (or go to http://localhost:8000/admin/debug/breakpoints):

Temporary breakpoints are deleted automatically after the first hit, and conditional breakpoints only matches if the associated python expression evaluates to True. 
Also, the breakpoint page can show the context source code according to the line number specified.

The breakpoints can also be added and removed from the edit window (new Toggle Button near back/docs, for example, in http://localhost:8000/admin/default/edit/welcome/controllers/


It also can debug exceptions (handled or unhandled, note the exception info and traceback). After you inspect the local or global variables, press continue so normal exception handling will be done:


With this changes, web2py can offer a complete online and ubiquitous Integrated Development Environment, so you don't need to learn any external tool to create web sites!

This debugger was tested this on Ubuntu and Windows XP, but it should work in mac and other linux flavours too, as it is pure-python and no third-party dependencies are required.

Future enhancements (supported by the backend, but not implemented already in the web frontend):
  • Jump to line and Run to line
  • Moving Up/down through the stack trace
  • Watch variable list (now they can be manually inspected with the interactive console)
Current drawbacks and limitations:
  • from gluon.debug import dbg;  dbg.do_debug() or dbg.set_trace() should be called from the model/controller to run under debug control (if not, normal web2py dispatch occurs, no breakpoint is honoured). UPDATE: the debugger is automatically started if debug interaction page is opened or breakpoints are set (see wsgibase web2py entry point to run controllers)
  • The debugger is threaded, so beware of apache prefork and similar (the backend supports remote debugging, but it is more trickier to set the breakpoints). This also applies to the current shell and similar tools like paste. See modwsgi Debugging Techniques (Browser Based Debugger). Anyway, I'm working in a full remote multiprocess debugger (that is supported by qdb CLI and GUI right now)
  • Secondary effects can appear if debug more than a function at a time (it will not die, but it is more difficult to follow)
  • I didn't find a way to add markers to editarea yet (ie. a red circle near the line number to indicate a breakpoint)
  • Debugging cannot be limited per application (FILTER_APPS and multi user mode cannot be enforced)
  • Compiled apps cannot be debugged as easily as non-compiled ones (breakpoints must be set manually with set_trace)
  • Some style/layout details are missing

So, if you want to try it, just set breakpoints and execute your controller to start debugging and enjoy ;-)

Mariano Reingart: pg8000 1.09 maintenance version (fork) released

pg8000 is a DB-API 2.0 compatible Pure-Python interface to the PostgreSQL database engine.
It is one of many PostgreSQL interfaces for the Python programming language. pg8000 is somewhat distinctive in that it is written entirely in Python and does not rely on any external libraries (such as a compiled python module, or PostgreSQL’s libpq library).
This pure-python connector approach allows to run it where C compiled libraries cannot be installed, it allows deeper access to PostgreSQL protocol internals and it enables easier flexibility and extensibility for Python developers (like support for parameterized prepared statements using qmark, numeric, named, format or pyformat DBAPI paramstyle).

The highlights of this 1.09 maintenance release are: two-phase commit support, autocommit feature, server_version property and bug fixes for almost all reported issues since 1.08 (2010-06-08) 

For details of the changes in this release, please see the notes at:

pg8000 maintenance version may be downloaded from:

For more information see:

For the original version see:

Acknowledgements to Mathieu Fenniak for the original version and thanks to the contributors that reported and/or sent patches applied for this release.

PS: I've been working with this library since the last year, it helped me where psycopg2 couldn't be installed (dependency compilation issues in older systems) or when I needed more flexibility (i.e. paramstyle). As it seems that the original author don't maintain it anymore, I've decided to make a fork in googlecode, with the hope it could be useful to other people too.

Mariano Reingart: pg8000 1.09 versión de mantenimiento (fork) liberado (conector python para postgresql)

pg8000 es una interface DB-API 2.0 compatible puramente hecha en Python para el motor de base de datos  PostgreSQL.
Al no depender de bibliotecas externas (libpq) o modulos compilados, puede ser instalada practicamente en todos los entornos, y habilita un acceso más profundo al protocolo de PostgreSQL, permite flexibilidad y extensibilidad más simple y para los desarrolladores Python como ser el soporte para sentencias preparadas parametrizadas usando qmark, numeric, named, format o pyformat según el paramstyle de la DBAPI).

Las características principales de esta versión 1.09 de mantenimiento son: commit en dos fases, soporte para autocommit, propiedad server_version property y corrección de errores para casi todas las incidencias reportadas desde la versión 1.08 (2010-06-08)

Para los detalles de los cambios en esta liberación, ver las notas en:

La versión de mantenimiento de pg8000 puede ser descargada de:

Para más información ver:

Para la versión original ver:

Mis agradecimientos a Mathieu Fenniak por la versión original y a los contribuidores que han reportado y/o enviado sus correcciones que se han aplicado en esta versión.

PD: Vengo trabajando con esta bibilioteca hace más de un año, me ayudo donde psycopg2 no pudo ser instalado (por no poder compilarlo por cuestiones de dependencias viejas) y cuando necesité más flexibilidad (el tema de paramstyle). Como se ve que el autor original no la mantiene más, decidí hacer el fork en googlecode, con la esperanza de que les sea útil a otros.

Maximiliano Robaina: 2012 Resolutions. Part 1.

I don’t know if call this resolutions or maybe wishes for the next year, but I’ll try to acomplish, at least one:

1. django-firebird: update to django 1.3

2. Implement my modifications to south for firebird support.

3. Build a web based firebird manager (like ibWebAdmin) on top of django.

4. Help to test pyfirebirdsql and analyze a possible replacement of kinterbasedb into django-firebird.

Ok, this is only referred to open source projects.

Ramiro Algozino: [Fedora] Habilitar la selección del tema para gnome shell

Después de haber actualizado a Fedora 16, me encuentro con que al querer cambiar de tema para el shell, la opción se encuentra deshabilitada y tiene un signo de admiración amarillo con la leyenda: «Extensión del tema de usuario de GNOME-Shell no activada»

Siendo que si tengo instalada y activada la extensión user-theme, me puse a investigar. Este error se debe a un bug en gnome-tweak-tool. Aparentemente ya está solucionado pero todavía no tenemos la actualización en los repos. Del mismo reporte del bug veo que para solucionar este error y poder cambiar de tema, almenos hasta que nos llegue el update, basta con editar como root el archivo:


cambiando la línea que dice:


por esta otra:


guardamos los cambios, ejecutamos Gnome-Tweak Tool nuevamente y deberíamos poder cambiar de theme sin problemas.. 😉

Por lo que veo, por lo menos a un visitante del blog (Thaizir) le pasó lo mismo, espero que le sirva a alguien con el mismo inconveniente. Si no saben como editar el archivo siendo root chiflen y actualizo el post.

Ramiro Algozino: [Fedora] ERROR en el chequeo de la transacción vs resolución de dependencias: WTF?

Intentando actualizar Fedora hoy me encuentro con que por el administrador de paquetes fallaba la actualización con un cartel medio extraño. Inmediatamente me voy a una consola, tiro un yum update y me encuentro con este error:

ERROR en el chequeo de la transacción vs resolución de dependencias:
kernel-uname-r = is needed by kmod-wl-
kernel-uname-r = is needed by kmod-wl-
kernel-uname-r = is needed by kmod-wl-
Por favor, informe este error en

Recuerden que hice un preupgrade (es decir actualicé de Fedora 15 a 16 sin reinstalar), con lo que aparentemente tengo un quilombo importante de paquetes.. Luego de investigar un rato largo y probar un par de comandos pude actualizar haciendo lo siguiente:

  1. Ejecutar yum check
  2. Desinstalar todos los paquetes que lista el comando anterior con yum erase <nombre de paquete o listado de los nombres de los paquetes>
  3. Actualizar felizmente con yum update o con la interfaz gráfica (no probé esta última).
  4. Profit!

Espero que les sirva de ayuda!


Ramiro Algozino: Nuevo Theme

Sólo quería comentarles eso.. Cambié el theme del sitio por uno un poco más limpio y liviano, con colores claros. Me cansé del anterior con colores tan oscuros y pesados, creo que el nuevo tema ayuda a la lectura. 😀 El tema que elegí se llama Reddle por si alguien se lo preguntaba 😉



Andrés Gattinoni: Resolver problema con la resolución de un monitor ViewSonic con nVidia en Linux




Un monitor ViewSonic VG2021wm y una placa de video nVidia GeForce 6500 dejan de entenderse espontáneamente en Linux Mint y el Xorg pasa a funcionar sólo en modo 640×480. ¿La solución? Deshabilitar el uso de EDID y configurar manualmente los datos del monitor en el xorg.conf.


Ayer me sucedió algo muy raro. Hace varios meses vengo usando Linux Mint sin mayores inconvenientes en mi máqunia. Cuando ayer fui a encender la máquina (sin que mediara ningún cambio extraño, ningún update de los drivers de la placa de video ni ninguna instalación de software), el X iniciaba sesión solamente en resolución 640×480. Teniendo un monitor de 20″, cuya resolución óptima es de 1680×1050, se darán cuenta que la imagen era espantosa: no entraba nada en la pantalla.

Después de varias horas sin entender bien cuál era el problema, postear en el foro de Linux Mint sin respuesta, y buscar en Internet, me puse a revisar los logs del X y encontré que mencionaba errores para leer el EDID. Por ejemplo:

Unable to get display device CRT-0's EDID; cannot compute DPI

¿Qué es el EDID? Extended display identification data, es una estructura de datos que ofrecen los dispositivos de visualización (ej.: los monitores) y que permiten, por ejemplo, a una placa de video conocer sus cualidades. De esta manera, la operatoria normal habría sido que mi placa de video obtuviera los datos del monitor de su EDID y conforme a ello me diera las opciones adecuadas para configurar mi pantalla. Más concretamente, el Xorg lo que hace es obtener a través de la placa de video, entre otros datos, la frecuencia horizontal (HorizSync) y la tasa de refresco vertical (VertRefresh) (para más información sobre qué es cada una de estas variables, pueden consultar esta página).

La cuestión es que de buenas a primeras, el Xorg dejó de poder leer el EDID de mi monitor y por eso levantaba con los datos default para un monitor CRT (por cierto, entre las cosas que aprendí ayer, el driver de nVidia le pone de nombre “CRT” a cualquier dispositivo que se conecte al puerto VGA, no tiene nada que ver con lo que efectivamente esté conectado). Eso quiere decir que tomaba un HorizSync y un VertRefresh que solamente eran compatibles con una resolución de 640×480@50 Hz.

¿Por qué pasa esto? La verdad, no lo sé a ciencia cierta. Encontré a este usuario que le pasó lo mismo, y levantando de un Live CD se dio cuenta que no era un problema de configuración, entonces lo resolvió cambiando su cable DVI por un cable VGA con un adaptador. Yo comprobé lo mismo, el problema no estaba en la configuración de mi Xorg, pero como yo sólo tenía cable VGA, probé cambiandolo por otro cable VGA, pero no hizo diferencia. Entonces seguí buscando y llegué a este otro post donde alguien lo resolvió sencillamente cambiando los HorizSync y VertRefresh en el xorg.conf.

Me bajé el manual de mi monitor (ViewSonic VG2021wm) y busqué los datos correspondientes (HorizSync y VertRefresh), y los puse en el xorg.conf. Este tipo de configuración manual del Xorg es lo que viene a evitar el EDID. El tema es que al reinicar el X, el Xorg seguía intentando leer el EDID y como no podía, seguía dando el mismo problema.

Finalmente, y casi por casualidad, me di cuenta que el nvidia-xconfig tenía unos parámetros para que configurara el xorg.conf indicándole al Xorg ignorar el EDID. Entonces ejecuté el siguiente comando:

sudo nvidia-xconfig --no-use-edid --no-use-edid-dpi --no-use-edid-freqs --mode=1680x1050

Y con eso me quedó generado el siguiente xorg.conf

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 280.13  (pbuilder@cake)  Mon Aug  8 15:37:15 UTC 2011

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"

Section "Files"

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"

Section "Monitor"

    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "LCD-1"
    HorizSync 24.0 - 82.0
    VertRefresh 50.0 - 85.0
    Option         "DPMS"

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option "UseEdidFreqs" "False"
    Option "UseEdid" "False"
    Option "UseEdidDpi" "False"
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050" "1680x1050_60.00"

Si ven los parámetros resaltados, en la sección Monitor defino el HorizSync y el VertRefresh. Y luego en la sección Screen, los parámetros que evitan que se use el EDID (anteriormente existía una opción IgnoreEDID que fue deprecada, ver los comentarios de este artículo).

Una vez modificado el xorg.conf solamente tuve que reiniciar el X y volvió a la normalidad. Después tuve que pelearme un rato con GDM para volver a configurar la resolución adecuada (1680×1050@60 Hz) utilizando nvidia-settings. Pero esto puede tener que ver con todas las vueltas que dí antes de encontrar la solución.