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

Deprecating automatic variable transfer #253

Closed
BoPeng opened this issue Sep 19, 2019 · 10 comments
Closed

Deprecating automatic variable transfer #253

BoPeng opened this issue Sep 19, 2019 · 10 comments

Comments

@BoPeng
Copy link
Contributor

BoPeng commented Sep 19, 2019

We currently have a feature that variables with names starting with sos are transferred implicitly.

This looks like a decent feature but it comes at a cost that all languages need to check if there are variables with names starting with sos, each time when a kernel switch happens. This can be a performance issue, and it makes it a bit difficult to implement language modules since not all languages can check variables easily.

I am wondering if we can disable this feature, and/or replace it with something like

%global myvar

to have explicit specification of "cross kernel" variables.

@gaow
Copy link
Member

gaow commented Sep 19, 2019

I think it is good idea to make the transfer explicit. It's not lots of typing and it would be nice to explicitly declare all global variables.

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 19, 2019

It is ok to remove auto transfer, but do you like the %global magic? Is this a good name?

@gaow
Copy link
Member

gaow commented Sep 19, 2019

I think it is a good name; otherwise %shared?

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 19, 2019

It is a bit awkward to remove a feature that I have been introducing in my talks, but I think explicit is better than implicit, especially because we are in Python camp.

Note that the implicit stuff was inspired by Beaker Notebooks, and it is the only method there.

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 19, 2019

global may lead to the perception that the variables are in some global place and cannot be modified in subkernels. shared is better in this sense although it may be understood of a single cross-kernel instance.

However, the global concept can be useful in case we do not want the variables to change values, because one problem with the current variable transfer is that variables can change values after kernel switch. For example, if we say

%global a = 12345678901234567890

if will be a double in R, and if we switch back then a will be double in SoS again, so having a "readonly" global variable that will keep its value in SoS can be useful. That is to say, instead of introducing something that can be done with %get, we might be able to introducing something different and conceptually clearer.

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 19, 2019

image

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 20, 2019

Implemented in the global_magic branch. It more or less works, but complications arise if users change the global var in a subkernel. Because the global variable will be re-sent to the subkernel each time, the user-changed value will be overwritten, leading to confusion.

image

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 20, 2019

Global defined from subkernel

image

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 20, 2019

%global would put variables to SoS kernel, overriding existing values.

image

@BoPeng
Copy link
Contributor Author

BoPeng commented Sep 20, 2019

Basically if the users only defines global in SoS and do not override it anywhere, it could be useful to "broadcast" variables to all subkernels (even if they have not started yet). Otherwise the behavior could be confusing.

BoPeng pushed a commit to vatlab/sos-docs that referenced this issue Sep 25, 2019
@BoPeng BoPeng closed this as completed Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants