Crystal::Compiler Ruby API..? Refactoring bin/crystal? about crystal HOT 8 CLOSED

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?

from crystal.

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.

from crystal.

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

from crystal.

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.

from crystal.

@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.

from crystal.

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.

from crystal.

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)

from crystal.

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.

from crystal.