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 debug.py 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).
Download:
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/menu.py 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!
Usage:
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.
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/default.py):
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 ;-)