-
Notifications
You must be signed in to change notification settings - Fork 12
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
Separate run time environments #418
Comments
I'm finally back. I don't think this is a regression. We have never tried to do what you're doing. I think part of the problem is that there is a single global variable that tracks the (single) runtime system instance: Frankly, this is just bad design. There may be other issues too. We're happy to work on this. @sp1tz this could be something to look at |
Okay, thanks! I did a brief hack to turn all instances of the runner to use a This is a blocker for viebel/klipse#314 (Stopify support for Klipse) so let me know if there a branch with a hacky fix for me to look at. |
That won't help. It's a genuine global variable. Look at the code that Stopify generates. It assumes a single global variable, I think |
Quick ping to see if there is anything for this. If there is a design doc with an outline for what needs to be done, I can try to hack it up. |
Nope, go for it! It would be great to have this in. |
- require() pauses the current computation, finds and loads the file with a new AsyncRun, then resumes with the result - makeRequireAsync() returns a promise to deal with the delayed/async result - Everything gets stopified, no control over stopifying some modules and not others, or some functions and not others
Subsequent calls to
stopifyLocally
should not interfere each other:Expected behaviour: print both “x:…” and “y:…”
Actual behaviour: print only “x:…”
@rachitnigam do you think it's a regression?
The text was updated successfully, but these errors were encountered: