On Nov 12, 12:08 pm, Jason Grout <jason-s...@creativetrax.com> wrote: > I think you can also use gdb; it seems I've done it once before, at least.
I have used gdb for stack examination after a segfault. For "C-like" pieces of Cython it works quite well. For "Python-like" pieces it's horrible, because python objects are virtually impossible to investigate with gdb (i.e., C-level). There is the added problem that gdb will happily give you the source context, but that will refer to the C that cython produced, not the original ".pyx". That means you have to deal with mangled identifier names too (which isn't too bad for C-like cython, which allows an almost 1-1 translation to C). A thing that would make gdb-debugging of cython immensely more useful would be if one could set breakpoints in a sensible way. I haven't used it, but gdb allows setting breakpoints by filename and linenumber. Those would be ".c" filename and linenumber, though. If we could somehow have a convenient translation tool from ".pyx" filename +linenumber to ".c" filename+linenumber, setting breakpoints would be much more doable. Is this something the cython people have thought about? Does this need a "cydb" wrapper around gdb or does gdb have its own customization options that allow something along these lines? People tend to say that debuggers provide a more efficient investigation tool than print-and-recompile, but I doubt this is presently true for cython. Perhaps this can be improved? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
