Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.8 Compatibility via TracePoint #57

Closed
trans opened this issue Jul 9, 2011 · 6 comments
Closed

1.8 Compatibility via TracePoint #57

trans opened this issue Jul 9, 2011 · 6 comments
Labels

Comments

@trans
Copy link
Contributor

trans commented Jul 9, 2011

I believe I can give you 1.8 compatibility, and in fact compatibility with any ruby engine that supports #set_trace_func.

A long time ago I wrote a tool called TracePoint. It should be pretty trivial to provide a result from it that exactly mimics Coverage.result. Would that do the trick? If so I will write it for you.

@colszowka
Copy link
Collaborator

That is exactly what would be required :)

Please go ahead if you think you can build something that returns a Coverage.result compatible with 1.9.x, that'd be awesome!

@trans
Copy link
Contributor Author

trans commented Aug 6, 2011

Okay, preliminary work on this is here:

https://github.com/rubyworks/tracepoint/blob/master/lib/tracepoint/coverage.rb

It's not 100% exact to 1.9's Coverage library but it looks like it will be close enough. Here is an example of coverage for foo.rb in tracepiont's try/ directory:

tracepoint:  [nil, nil, 2, 1, nil, nil, 2, nil, nil, nil, 1]
ruby 1.9  :  [nil, nil, 1, 1, nil, nil, 1, 0, nil, nil, 1, nil]

The difference being that tracepoint counted one line twice, and does not include trailing blank lines.

The bigger issue though, is that I have not figured out a way to exclude files that aren't relevant from the coverage results b/c $LOADED_FEATURES in Ruby 1.8 doesn't use absolute paths. Any ideas?

@colszowka
Copy link
Collaborator

Pretty awesome! Did you try to do File.expand_path on the $LOADED_FEATURES array?

@trans
Copy link
Contributor Author

trans commented Aug 8, 2011

Unfortunately File.expand_path won't work b/c that would make the path relative to the current working directory rather than the lib directories from which they are actually found.

I could match against the end of the path, that would probably work fine most of the time, but on occasion a false positive could creep in.

@colszowka
Copy link
Collaborator

Closing since basic compatibilty seems to be hard to achieve, nothing has happend on this for a while and also Ruby 1.8 is on the way out (official support even stops soon) and has a decent coverage lib in RCov, I don't think this is a subject worthwile of further keeping around. Please update if there are objections to this, and thanks for trying to make this work!

@trans
Copy link
Contributor Author

trans commented Jan 27, 2012

Yep, I agree. 1.8 is finally about done.

Ironically it was thanks to this endeavor that I discovered Ruby 1.9's #set_trace_func is broken. And from conversation on core it sounds like no one plans to fix it. Rather the vibe I got was that #set_trace_func itself is on the way out. That being the case TracePoint has no means for working beyond 1.8 :-(

So it's a good thing I tried any way. C'est la vie.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants