Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

construct 'lnotab' byte string for code objects #93

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

scoder commented Mar 14, 2012

The intention of this change is to eventually be able to support runtime mapping of line numbers for code objects. What CPython does is to pack a byte code offset to line number offset map into a byte string and store it in the code object. This is what this patch does as well, so that the line number could be computed by CPython by simply using current source line - first source line of function as a fake byte code offset for Cython functions when tracing or raising an exception. This will allow reuse of the code object over the whole body of a function.

A current problem is the syntax tree layout for Cython functions that have a code object. Here, the code object lives outside of the function, specifically in the fused functions object. It would be better to move it inside of the function itself, where the function code could use it. This is not entirely trivial because the fused function code currently reuses one code object for all specialisations, which doesn't work well with the idea of letting each separate function own it.

By itself, this patch isn't very interesting because Cython does not currently use byte code offsets in frame objects. But it's the first non-trivial step in that direction and should be applied at some point before refactoring the syntax tree.

@scoder scoder construct 'lnotab' byte string for code objects to eventually support…
… runtime mapping of line numbers

--HG--
extra : transplant_source : %B8%83%8A%1E%0B3%BE%9D%03%C0%E6%B8%EBE%24B%F8%AA%103
a6d2d73
Contributor

thedrow commented Feb 2, 2015

Can you please rebase this PR?
It has some merge conflicts.

Contributor

scoder commented Feb 6, 2015

updated to latest master

Contributor

thedrow commented Feb 6, 2015

woot and everything works.
Why isn't this merged yet?

Contributor

scoder commented Feb 6, 2015

because there is no use case that I know of - what do you use it for?

Contributor

scoder commented Feb 6, 2015

Or, well, let's put it differently - it isn't useful all by itself for existing tools. I guess custom user code could make use of it, though.

Contributor

thedrow commented Feb 6, 2015

To my understanding this PR will allow coverage.py to report coverage on cython modules which is useful.

Contributor

scoder commented Feb 6, 2015

did you try it?

Contributor

thedrow commented Feb 6, 2015

Nope not yet.

Contributor

scoder commented Feb 6, 2015

Tried it (it's been a while...) and it doesn't help. In fact, tracing works just fine, it's just that coverage.py gets it wrong somehow (it fails to keep track of when it's in a function or not). Might be something simple to improve in Cython, but it might also just be a bug (or missing feature) in coverage.py. But that's not related to this pull request. The users mailing list is a better place to discuss this if you're interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment