Performed a clean merge with cython-devel.
On 3 November 2010 17:57, Robert Bradshaw <[email protected]> wrote: > On Wed, Nov 3, 2010 at 2:55 AM, mark florisson > <[email protected]> wrote: >> Most of the Cython debugger is implemented, it can be pulled from >> hg.cython.org/cython-gdb. > > Cool! Have you recently pulled from main? > >> To use it, you need Cython to export some debug >> information, which can be done using 'cython --debug mymod.pyx', or 'python >> setup.py build_ext --pyrex-debug'. You can also pass 'pyrex_debug=True' as >> an argument to Cython.Distutils.extension.Extension. > > How much overhead (runtime, codesize, extra files, etc.) does > compiling with this option incur? Too much to enable by default? > >> You can then start gdb by typing 'cygdb' (which should be installed as a >> script) in your project directory. Then 'help cy' gives an overview of >> commands. It currently supports breapoints, stepping, stepping-over, >> backtraces, source code listing, going up and down the stack, printing >> variables with regard to context, listing locals or globals and running and >> continuing the program. If pygments is installed it will colorize source >> code which is configurable through cy_* parameters. >> It basically works on three levels: the Python, Cython and C level. >> Depending on the context cygdb does the right thing. For stepping it >> considers the following stack frames relevant: any Python frame, any Cython >> frame and any C frame from a C function called directly by Cython user-code. >> So, it would be great if some people could test and try it (unit tests are >> written but some system testing is always great). It works with gdb 7.2 (the >> 7.1 python api was too incomplete and broken). So if you guys like it I >> could write documentation that explains to Cython users how to install and >> use it. > > I'm not a gdb expert, but I definitely want to try this out. > Documentation would be great--either as a wiki or, preferably, the > main documentation (with a little note mentioning it's pending > release). I've given you push access to > http://hg.cython.org/cython-docs > >> Any suggestion or criticism is most welcome! >> The Python support (libpython.py) was also modified. I'd like to push this >> mainstream (and process any suggestions and criticism) before supplying a >> patch to Python. >> Kind regards, >> Mark >> >> On 15 September 2010 17:49, Robert Bradshaw <[email protected]> >> wrote: >>> >>> On Wed, Sep 15, 2010 at 2:55 AM, mark florisson >>> <[email protected]> wrote: >>> >>> >> It ought to be possible to do something similar with cython code. It >>> >> may not even be necessary to modify cython: perhaps some searching for >>> >> locals named "__pyx_*" iirc would get you 70% of the way there? >>> > >>> > Although that sounds like a wonderful idea, I think there are also >>> > issues with that. One issue is that a user must be able to set Cython >>> > breakpoints before the Cython module would be loaded, and for that the >>> > symbol name would be needed beforehand. Also, I don't know if these >>> > mangled names are consistent now and in the future and if you would be >>> > able to unambiguously associate a Cython variable name with a mangled >>> > name. >>> >>> Mangled names are deterministic and, though they're not guaranteed to >>> be consistent from release to release, almost always are. >>> >>> >> I can attest that having the prettyprinters enabled does make it much >>> >> easier to debug cython code: all of the PyObject* get prettyprinted. >>> > >>> > I've been looking at the code and this is pretty neat. I did encounter >>> > some issues, for instance if you load the script before loading the >>> > python interpreter you get this traceback because these types are not >>> > defined at that time: >>> > >>> > Traceback (most recent call last): >>> > File "<string>", line 1, in <module> >>> > File ".libpython.py", line 49, in <module> >>> > _type_size_t = gdb.lookup_type('size_t') >>> > RuntimeError: No type named size_t. >>> > >>> > So I think it would be a good idea to not make that code module-level. >>> > >>> >> >>> >> One other thought: if it's possibly to expose the cython structures in >>> >> some meaningful way, perhaps we could change upstream python's gdb >>> >> hooks >>> >> to simply integrate them into the py-* commands I mentioned above? (so >>> >> e.g. cython c functions get somehow treated as python frames; currently >>> >> I have a test predicate: >>> >> Frame.is_evalframeex() >>> >> which perhaps could be generalized?) >>> >> >>> >> (Not sure; it would complicate the selftests within python itself) >>> >> >>> > >>> > I think it would be hard to make them actual Python frames because >>> > creating frames in the inferior process from gdb is probably quite >>> > dangerous, and the alternative would be to modify Cython so that it >>> > creates Python stack frames (this sounds feasible but I think it might >>> > be a little bit of work). However, if this could be done (it would >>> > only do so if this 'debug' flag is active), then tracebacks and locals >>> > inspection etc wouldn't need special attention and the code would >>> > appear as normal Python code (apart from the Code objects obviously). >>> > However, this would form a problem for non-primitive C-type Cython >>> > variables. >>> > >>> > So at the very least we could have a 'py-locals' or some such command >>> > that would show the value of all the locals (the Python locals would >>> > be printed by py-print and C locals by gdb print). For regular python >>> > code it would show the locals from the current stack frame. For the >>> > Cython part to work we would need information from the Cython compiler >>> > because we wouldn't want to list any temporary or irrelevant >>> > variables. >>> >>> Yes, this is what I was thinking, at least in terms of exposing stuff >>> to pdb (which is a complementary project). BTW, frames are already >>> created for functions when profiling is enabled. >>> >>> > So I think we should be able to integrate these two projects into one >>> > fruitful project, and with proper documentation it could help both >>> > regular Python users and Cython users. >>> >>> +1 >>> >>> - Robert >>> _______________________________________________ >>> Cython-dev mailing list >>> [email protected] >>> http://codespeak.net/mailman/listinfo/cython-dev >> >> >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> >> > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
