Hi Mark Thanks for the quick response.
Actually I was also able to reproduce the bug on a test case which does not use the --cplus flag, but it seems fixed now in both cases. Now, onwards with trying cygdb out! Cheers, Paul -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of mark florisson Sent: 04 November 2010 10:20 To: [email protected] Subject: Re: [Cython] Cython debugger Hey Paul, thanks for the feedback, I hadn't tried the --cplus option yet. Apparently I was using an attribute (that indicates where to write the C file) that is set to None when writing C++ files. I changed that and gave it a quick test, so hopefully it's fixed now :) Kind regards, Mark On 4 November 2010 10:36, Connell, Paul <[email protected]> wrote: > Hi > > > > I just pulled the tip out of hg.cython.org/cython-gdb as I’m excited > to try this out. > > > > However, when running “cython –cplus –debug” on a pyx that I know is > correct and works, I always get the following output: > > > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 777, in > _raise_serialization_error > > "cannot serialize %r (type %s)" % (text, type(text).__name__) > > TypeError: cannot serialize None (type NoneType) > > > > > > I have not yet had the opportunity to try reducing my pyx (it is > fairly large and getting larger every hour), but is this any kind of > known problem – what might be causing it? > > > > Here’s the full traceback: > > > > File "/projects/ctg/build/bin/cython.py", line 3, in <module> > > main(command_line = 1) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 780, in main > > result = compile(sources, options) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 755, in compile > > return compile_multiple(source, options) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 727, in compile_multiple > > result = run_pipeline(source, options) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 596, in run_pipeline > > err, enddata = context.run_pipeline(pipeline, source) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 237, in run_pipeline > > data = phase(data) > > File "C:\Python26\lib\site-packages\Cython\Compiler\Main.py", line > 160, in generate_pyx_code > > module_node.process_implementation(options, result) > > File "C:\Python26\lib\site-packages\Cython\Compiler\ModuleNode.py", > line 72, in process_implementation > > self.generate_c_code(env, options, result) > > File "C:\Python26\lib\site-packages\Cython\Compiler\ModuleNode.py", > line 302,in generate_c_code > > self._serialize_lineno_map(env, rootwriter) > > File "C:\Python26\lib\site-packages\Cython\Compiler\ModuleNode.py", > line 327,in _serialize_lineno_map > > tb.serialize() > > File "C:\Python26\lib\site-packages\Cython\Debugger\DebugWriter.py", > line 71,in serialize > > et.write(os.path.join(self.output_dir, fn), encoding="UTF-8", > **kw) > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 663, in write > > self._write(file, self._root, encoding, {}) > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 707, in _write > > self._write(file, n, encoding, namespaces) > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 698, in _write > > _escape_attrib(v, encoding))) > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 830, in > _escape_attrib > > _raise_serialization_error(text) > > File "C:\Python26\lib\xml\etree\ElementTree.py", line 777, in > _raise_serializa > > tion_error > > "cannot serialize %r (type %s)" % (text, type(text).__name__) > > TypeError: cannot serialize None (type NoneType) > > > > Regards, > > Paul > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of mark florisson > Sent: 03 November 2010 09:56 > To: [email protected] > Subject: Re: [Cython] Cython debugger > > > > Most of the Cython debugger is implemented, it can be pulled from > hg.cython.org/cython-gdb. 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. > > 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. 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
