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
Change the stdout dynamically within the same interpreter instance? #1631
Comments
Unfortunately, it looks like the |
Sorry for the churn here: the proper workaround here is to give yaegi a set of wrappers that we can then redirect ourselves. |
Hello, have you tried Lines 301 to 304 in 381e045
|
Yes, but I need to be able to change those after creating the interpreter! |
You can use a writer wrapper, something like that: https://go.dev/play/p/sxFkJGLgmH1 You wrap the writer inside another writer and you can change the writer when you want. |
After more thinking, your suggestion can lead to concurrency problems. |
Yep that sounds good -- I implemented the wrapper and it works well. It seems that some writers are already concurrency-safe and others are not, so a lock is a good idea. I will go ahead and close this issue and anyone else looking for this functionality could presumably find this ticket. You could also maybe add a note in the relevant docs at some point.. :) |
Proposal
It would be nice if we could change the default stdout etc used by fmt.Print* within the same running interpreter instance. For example we're writing a shell using yaegi (which is working really well and would not have been possible without this amazing package!), and we want to be able to dynamically redirect output based on standard shell
>
kind of syntax.Background
In
fixStdlib
ininterp/use.go
, it looks like you replace these methods with functions that use local copies of theinterp.std*
variables. Thus, even if you had a way of updating thoseinterp.std*
values, it wouldn't actually update thePrint*
functions, which seem to be permanently tied to these initial values.Thus, one simple change would be to change this code to use
interp.std*
and then add aSetStdIO
or similar such method that sets those values. Or aSetOptions
to use theOptions
values to set them, but that might be more problematic in terms of making the new settings take effect everywhere.e.g., the new code would be, on line 168:
would you accept a PR along these lines? Any thoughts about the
SetStdIO
function name? SeparateSetStdout
etc instead?Workarounds
for now, we will try to revert the "fixed" mapTypes to use the original os.Stdout functions so we can control by changing os.Stdout.
The text was updated successfully, but these errors were encountered: