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<http://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]<mailto:[email protected]>> wrote:
On Wed, Sep 15, 2010 at 2:55 AM, mark florisson
<[email protected]<mailto:[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]<mailto:[email protected]>
http://codespeak.net/mailman/listinfo/cython-dev
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
