Refactoring: embedded "compiler/crystal" by crystal commandline

[faustinoaq]

Currently Scry uses a huge amout of memory because the crystal compiler is embedded on it.
Scry analyze files every time a file is saved without checking if the file have been truly changed increasing even more the footprint (aprox. over 300 MB RAM on Linux)

Also maybe we can use external crystal processes instead of using require "compiler/crystal/**" ('cause, compiler is very heavy) I think using processes will free memory easier and improve Scry performance.

Also new features as types on hover and refactoring could be easier to implement.

[keplersj]

I'm not sure this is a good idea. Can we get the opinion from someone on the language team? @mverzilli? @bcardiff?

[bcardiff]

Maybe for some tasks like syntax error and compilation error calling the compiler as an external process could work, but at the end of the day, if there is some analysis like extracting type information for subexpressions or variables in scope either the compiler need to provide that functionality or the compiler needs to be embebed.

I am unaware of what features scry already build on top of crystal compiler, but that is the aspect that needs to be analyzed to decide whether it is feasible or not.

[bcardiff]

Shipping a custom crystal compiler can be done but need to be done carefully. crystal env serves for extracting the environment information used in the wrapper scripts. The compiler should be built in release mode, and maybe the whole compiler is not needed. But right now at most the compiler can be required in ast/parser/lexer/full modes depending on directories AFAIK. That could help to minimize the size of the binary and memory footprint, but again, depending on the needed features by scry

[faustinoaq]

@bcardiff Thanks your for your comments, I will do some tests to check performance between embedded crystal vs external crystal processes.

Maybe for some tasks like syntax error and compilation error calling the compiler as an external process could work

I agree with you, currently all features Scry has are supported by crystal tool commands

• full analysis: crystal build --no-codegen
• parser analysis: crystal tool format --check
• find implementations: crystal tool implementations ...
• find macros (not implemented yet): crystal tool expand depends on Allow to find macros using tool implementations. crystal-lang/crystal#4766
• formatting: crystal tool format ...

I think require "compiler/crystal/**" will be useful for other things.

Also we are thinking on implement completion using external tool like cracker [0]

[0] - https://github.com/TechMagister/cracker

The only missing tools right now on crystal compiler are rename and list symbols, do you think can we have these on crystal compiler too?

Are transformations or visitor examples like refactoring ? WDYT @asterite ?

[faustinoaq]

Would be awesome to have something like this on crystal 😅

Reference https://twitter.com/rachsmithtweets/status/907350440634748928

[faustinoaq]

Rename is likely to be achieved using something like #101 (comment)