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

Polyglot shell does not seem to support local variables #1695

Closed
fniephaus opened this issue May 23, 2019 · 9 comments

Comments

4 participants
@fniephaus
Copy link
Contributor

commented May 23, 2019

Tested with GraalVM CE 19.0.0 on macOS:

irb

$ irb --jvm
irb(main):001:0> x = 42
=> 42
irb(main):003:0> x
=> 42

Polyglot Shell

$ polyglot --jvm --shell
GraalVM MultiLanguage Shell 19.0.0
  Ruby version 2.6.2
ruby> x = 42
42
ruby> x
undefined local variable or method `x' for main:Object (NameError)
        at <ruby> <top (required)>(<shell>:1:0)
        at <ruby> parsing-request(Unknown)
ruby> $x = 42
42
ruby> $x
42

Expected behavior: identical

@eregon

This comment has been minimized.

Copy link
Member

commented May 23, 2019

We were discussing this issue with the team not long ago.
I agree it should work for the polyglot shell.

However, it's unclear to me whether different Context#eval should share top-level local variables, particularly if using File sources like

Context.eval(Source.newBuilder("ruby", new File("foo.rb").build()));

Do you have other use cases for sharing local variables with Context#eval except REPLs?

@eregon eregon added the polyglot label May 23, 2019

@fniephaus

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2019

@eregon thanks for the info. I'd also be interested in support for different scoping mechanisms in the polyglot API. In this case, users expect the identical behavior to irb I'd say. In terms of other use cases, I can only think of something like Jupyter Notebooks (which would still be an important use case to support I think).

@eregon

This comment has been minimized.

Copy link
Member

commented May 23, 2019

For Jupyter Notebooks (and also e.g., Galaaz), it's always possible to use language-specific APIs like Kernel#eval(code, binding) and pass binding around as desired.

For the case of the polyglot shell, I think one way to detect if we want to share local variables would be to use Source#isInteractive(). Then other use cases like Jupyter Notebooks could set that too to be language-agnostic.

@fniephaus

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2019

Sounds reasonable. Nonetheless, I'd be curious to know what @chumer thinks about this.

@fniephaus

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2019

For Jupyter Notebooks (and also e.g., Galaaz), it's always possible to use language-specific APIs like Kernel#eval(code, binding) and pass binding around as desired.

In a polyglot notebook implementation, we might want to implement the notebook kernel e.g. with the embedder API or based on an existing NodeJS server. Should the notebook kernel include this language specific eval/scoping information for all languages?

@chumer

This comment has been minimized.

Copy link
Member

commented May 27, 2019

We have discussed this internally and we came to the conclusion that is probably best that Context#eval shares top-level locals by default. We have plans to add a scoped eval capability in the Context API.

@chrisseaton

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

Fix for this on the way.

@chrisseaton

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

Fixed in a84b16f.

@chrisseaton chrisseaton self-assigned this Jun 10, 2019

@chrisseaton chrisseaton added this to the 20.0.0-beta2 milestone Jun 10, 2019

@chrisseaton

This comment has been minimized.

Copy link
Member

commented Jun 29, 2019

Just confirmed this work as expected in the release that's in a couple of days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.