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

Extending the embedded documentation #440

Open
nickheyer opened this issue Aug 25, 2024 · 5 comments
Open

Extending the embedded documentation #440

nickheyer opened this issue Aug 25, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@nickheyer
Copy link
Contributor

Feature Description

I feel as though I have now read through every issue (current and closed), as well as every doc available to me. I honestly believe that the ability to embed this runtime/dsl into Rust is undervalued relative to the amount of supporting documentation. There isn't really a whole lot of offerings in this category, and you've made something really great - which is why it should capitalize on comprehensive documentation and rust extensibility.

That being said, my actual need for this documentation is to essentially do one "simple" (from my uninformed perspective) thing. I'd like a method or buffer I can tap into containing the stdout of the runner::run_script* methods.

For example: If I echo "Hello, World!", it is printed to my terminal. I'd like to use the Hello, World! dynamically within Rust application that executed the duckscript. A good use case would be redirecting output to a log, or via a websocket connection to a webapp, etc.

A "nice" but maybe not possible implementation would be similar to how it's done with context.variables, where I can access the variables set in the duckscript after the duckscript was ran - and use that data as needed. A context.stdout would be great. If that already exists, then I apologize in advance for my rant - I am somewhat new to Rust and it's documentation style.

@sagiegurari
Copy link
Owner

@nickheyer thanks a lot.
redirecting the output to a given stream is a nice idea but not trivial as the runner simply invokes the commands.
each command may do whatever it wants including writing to the standard output directly bypassing everything or calling a sub process.
so its nice idea, but not 100% sure how to go at it.

1 simple way, would be to redirect the standard out/err before calling the runner to some memory buffer.
i prefer not to do it inside the runner as it is not bullet proof (for example what if you are running a multi threaded app).
wdyt?

@sagiegurari sagiegurari added help wanted Extra attention is needed investigation labels Aug 30, 2024
@nickheyer
Copy link
Contributor Author

I was thinking some form of callback function could be passed to the runner, and be called on standard output.

@sagiegurari
Copy link
Owner

@nickheyer maybe instead it would make more sense that you will provide a writer for out+err so those will be streamed to there.
than if not provided it goes to stdout/err and if provided you have access to it.

@sagiegurari sagiegurari added enhancement New feature or request and removed help wanted Extra attention is needed investigation labels Aug 31, 2024
sagiegurari added a commit that referenced this issue Aug 31, 2024
@sagiegurari
Copy link
Owner

in dev branch 0.10.0 i've added the ability to provide a custom stream for out/err so you can get all that output instead of having it printed to stdout/err

@nickheyer
Copy link
Contributor Author

@sagiegurari This is awesome. It feels great to know that you'll continue to be actively maintaining this library and seeking improvements, as I invest time in projects that will likely be dependent on it.

While I work on integrating this and replacing my very hacky stdout redirect workaround which used the Gag Crate ... I think a nice general objective for outlining rust implementation would be to provide example usage for env as well as the other extensible features/arguments provided to the runner/runtime/context/etc - maybe at some point I can contribute when I become more acclimated with duckscript.

nickheyer pushed a commit to nickheyer/duckscript that referenced this issue Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants