Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Languages cannot be dynamically registered, require a 'reload' command #5

Open
4 tasks
Pathemeous opened this issue Jun 6, 2017 · 4 comments
Open
4 tasks
Labels

Comments

@Pathemeous
Copy link
Member

JVM and GraalVM cannot hotswap the java code of the language interpreter, meaning that a new JVM must be run for each new build of the language.

To trigger this, we could start simple with a :reload user command, that spins a new JVM with the currently build interpreter.

  • Find out how to boot a new JVM from within Java
  • Articulate the steps in order to 'reboot' (will be interface towards Client to implement)
  • Implement in Eclipse
  • Provide framework/interface with as much language agnostic code as possible
@justinvdk
Copy link

Find out how to boot a new JVM from within Java
Trivial case not that hard.
Challenge: how do we load up the new jvm with the correct classes.

@Pathemeous
Copy link
Member Author

Pathemeous commented Jun 19, 2017

With the StrategoEvaluationStrategy this no longer poses an issue, because GraalVM is not used there.

Correct @justinvdk? We can close this.

@hendrikvanantwerpen
Copy link

Note that you do need to recreate the Spoofax interpreter after the language is rebuilt.

@justinvdk
Copy link

recreate the Spoofax interpreter

This is part of the build process right? I think what @Pathemeous means is that we don't have to reload the language definition in the shell at runtime, a rebuild is all that is needed to make use of a new interpeter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants