freerange / method_log Goto Github PK

From Further Work section of blog post:

At the moment the code delves rather too deeply into the innards of the parser gem i.e. it calls Parser::Source::Buffer#decompose_position to determine the last line number of the method definition. It would probably be better to submit a patch to the parser gem to make the last line available directly on Parser::Source::Buffer.

Attempting to install method_log results in the following:

ERROR: While executing gem ... (Gem::DependencyError)
Unable to resolve dependencies: method_log requires rugged (>= 0), diffy (>= 0), trollop (>= 0)

Tried to install the rugged gem by itself and got:

Temporarily enhancing PATH to include DevKit...
ERROR: While executing gem ... (Errno::EINVAL)
Invalid argument - C:/Ruby193/lib/ruby/gems/1.9.1/gems/rugged-0.19.0/test/fixtures/status/h?↓

While I think they should already be parsable in the sense that they are valid Ruby, I suspect an individual example might not correspond to an individual method definition.

I noticed that Rugged now supports alternative backends, including Rugged::InMemory::Backend. This would be worth considering, at least for the tests, and possibly for the real implementation.

From Further Work section of blog post:

It might be nice to convert this tool a git extension. Simply renaming the binary to git_method_log and ensuring it is present in the user’s PATH would be enough to make it available as a git method-log command, but it might be nicer to extend the existing git log command itself with extra command line switches.

From Further Work section of blog post:

I have a bunch of ideas that could make use of the MethodFinder functionality, so I think it might be worth extracting this into its own gem, e.g. having a pre-commit hook to annotate commit messages with method events, and enhancing GitHub source file pages to have links to a "method log".

• For method_log, it would be good to default to the current branch, but allow that to be overridden.

• For build_methods_repo, it would be good to default to master, but allow that to be overridden.

https://rubygems.org/gems/progressbar

I suspect I took some shortcuts and it would be worth investigating whether that can potentially lead to confusion or errors.

Just installed this gem on OSX 10.11.6
But I get the next error.

method_log
Traceback (most recent call last):
	9: from /Users/jgd/.rvm/gems/[email protected]/bin/ruby_executable_hooks:24:in `<main>'
	8: from /Users/jgd/.rvm/gems/[email protected]/bin/ruby_executable_hooks:24:in `eval'
	7: from /Users/jgd/.rvm/gems/[email protected]/bin/method_log:23:in `<main>'
	6: from /Users/jgd/.rvm/gems/[email protected]/bin/method_log:23:in `load'
	5: from /Users/jgd/.rvm/gems/[email protected]/gems/method_log-0.2.0/bin/method_log:6:in `<top (required)>'
	4: from /Users/jgd/.rvm/gems/[email protected]/gems/optimist-3.0.0/lib/optimist.rb:921:in `options'
	3: from /Users/jgd/.rvm/gems/[email protected]/gems/optimist-3.0.0/lib/optimist.rb:921:in `new'
	2: from /Users/jgd/.rvm/gems/[email protected]/gems/optimist-3.0.0/lib/optimist.rb:103:in `initialize'
	1: from /Users/jgd/.rvm/gems/[email protected]/gems/optimist-3.0.0/lib/optimist.rb:103:in `call'
/Users/jgd/.rvm/gems/[email protected]/gems/method_log-0.2.0/bin/method_log:7:in `block in <top (required)>': uninitialized constant MethodLog::VERSION (NameError)

Any hints?

From Further Work section of blog post:

While writing this article, I came across the undocumented Rugged::Diff class - it might be better to use this rather than the diffy gem that I’m using at the moment.

I'm hoping that this is a drop-in replacement: http://manageiq.github.io/optimist/

From Further Work section of blog post:

A possible optimisation would be to stop parsing a file at the point where the method definition is found - at the moment the whole file is always parsed.

From Further Work section of blog post:

Running the tool against a very large repo (e.g. Rails) is still very slow, so I suspect in the end it might be necessary to build a “database” of method metadata vs commits.

I think this idea lead me to building a parallel git repo with the same commits, but with module & classes represented as directories and methods represented as files. I think the code for this is in this branch and there are a couple of example repos: mocha.methods & method_log.methods.

e.g. by comparing ASTs of implementations