Crystal::Compiler Ruby API..? Refactoring bin/crystal?

[farleyknight]

I'd like to be able to compile Crystal code directly from Ruby, like this:

compiler = Crystal::Compiler.new
compiler.compile_from_source(File.read("my_code.cr"), output: "my_executable")

However, I noticed that most of this code is heavily coupled to the command line program bin/crystal. How would the team feel about me doing some refactoring to decouple the compiler from bin/crystal, provided I give enough test cases, so that both pieces still work as expected?

[bcardiff]

In the mid term the ruby compiler will go away actually (as soon as the bootstrap is ready). So, if you wan't that API, I will suggest to treat the crystal compiler as an external executable.

BTW, why do you need that API?

[asterite]

Even though the compiler will eventually be written in Crystal itself I don't think it's a bad idea to refactor the Crystal::Compiler class to be used as a gem to compile a source file. We could use this in a website to let users play with the language without having to install it. They could see the generated LLVM IR, for example, or the types graph or class hierarchy.

I say "go for it" :-)

But I'm also very curious about why you need such an API.

[farleyknight]

@asterite I think you came up with a better use than I would have thought of 😄

[farleyknight]

Basically, I don't "need" such an API. It's just that I want to learn more about this project and the main starting point is, for myself, the compiler tool. To be able to compile & run Crystal programs from Ruby would be the ideal way to learn more about the language, and (I feel) also for other Ruby developers.

[farleyknight]

@asterite Okay, so what small step can I make towards this? I don't want to bang away at a branch and have it get rejected. I'd love some more guidance on this.

[asterite]

If you want to refactor the Crystal::Compiler class you can touch that file and add specs to it. I don't see the need to change the Gemfile, spec_helper.rb or any other file.

[farleyknight]

Right, however refactoring it won't help if I can't get test results around it, nor can I see if my tests are actually calling all the necessary parts of the compiler class. Having SimpleCov locally tells me if I'm covering all the files in the Compiler class (and at this point, it's not being covered much: https://coveralls.io/files/54609883)

[farleyknight]

Decentralization is a huge benefit for developers. Having all the information in one central place makes it difficult for other people to participate.

Github is founded on git, which is markedly different from subversion in the sense that you can commit to locally with git and push your changes later, whereas subversion requires all changes be pushed to the server immediately. If the subversion server goes down, you can't commit at all. That makes merging difficult later on.

The changes I'm proposing are similar, in that they are ways for developers to run tests and run test coverage locally before having to push them to github to get results.