smarter `riml_include` re-orders inclusions based off dependency graph for classes

[luke-gru]

implement dependency graph and automatic dependency management for riml_include.

[dsawardekar]

+:100:

[dsawardekar]

@luke-gru I've released the plugin I've been working on with Riml, It's called Portkey, it's a file navigation plugin similar to vim-rails. Thanks again for Riml!, it made this plugin possible.

If you implement this feature and need to test it out try sorting the includes in this include file, and then recompiling with rake or speckle. If the test suite still runs, you've succeeded. :)

[luke-gru]

@dsawardekar Portkey looks really cool, I'm going to check it out this weekend for sure.

Thanks for the update, and thanks again for pushing riml to its limits. I'll definitely look into that monster include file and use Portkey for benchmarking this feature :smile:

[luke-gru]

Finally wrote this feature, and it's available in master. I tested with portkey's include file, and it definitely was a good use case :+1: Helped a lot.

This feature can be turned off by flag --no-include-reordering, but it doesn't add much overhead, so it should be fine to leave it on.

Let me know how it's working when you get to use it in the wild.

Thanks!

[dsawardekar]

Damn! I wish I had this feature when I was building Portkey.

Would I be able to move the includes to within the individual includes? Portkey mostly consists of command objects. If I riml_include the dependencies in those classes would it be able to figure out the dependencies if I only include the main command include?

[luke-gru]

Hmm, not sure exactly what you mean, but the dependency resolution is recursive, so it should work. If you could provide me a specific example I could tell you whether or not it works, but I would have to check it first with the actual compiler to make sure.

If you run into anything that doesn't work, and you expect it to, let me know. I still haven't unit tested the feature very much, but I did fuzz the include orders in portkey, and everything worked as it should.

[dsawardekar]

@luke-gru I'm thinking on the lines of imports.

Take AlternateFileCommand. It's inheritance chain is SwitchFileCommand > PortkeyCommand > BaseCommand. My current approach is manual. Making sure that the parent classes are present before the class in which they are used. Instead If I could put the includes in the individual file the main include would be to only include that command file. Something like,

In portkey_command.riml,

riml_include 'base_command'

In switch_file_command.riml,

riml_include 'portkey_command'

In alternate_file_command.riml,

riml_include 'switch_file_command'

And finally in portkey_inc.riml. Which would bring in the parent classes without directly importing them in portkey_inc.riml.

riml_include 'alternate_file_command'

There are other dependencies that command objects have that I've left out. But the general idea is the includes go in the source code somewhat like import statements. This also makes things easier for tests where they only need include the class that they are testing.

[luke-gru]

Ahh, okay yeah, I understand what you mean. This will definitely work now :+1:

In fact, you could even have this:

In switch_file_command.riml,

class SwitchFileCommand
  ...
end

In alternate_file_command.riml,

riml_include 'switch_file_command'

In portkey_inc.riml,

riml_include 'alternate_file_command'
riml_include 'base_command'
riml_include 'portkey_command'
...

That is, all include files for an entire compilation are walked recursively before any dependencies are resolved. After dependency resolution, the riml_includes are reordered based on class dependency, then compilation continues.

Let me know if you run into any issues! Thanks!

[dsawardekar]

Awesome stuff! This feature is looking even better. Are you going to cut a release with this?

[luke-gru]

This is in 0.3.6, which I just released.