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
