-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add support for non-STDOUT streams #5
Comments
I agree that it should use I believe |
Thanks for creating that issue, and for the information about Regarding changing the output to |
The idea is that you could at least do |
Any change, including bug fixes, can break existing code. I'm not sure I see a good usecase that would be broken this way. Do you? |
Now I understand how you were accommodating the other streams, by temporarily modifying
I have no investment in this, I don't have any use case of my own -- but I can imagine that someone, somewhere, might be relying on having the benchmark output go to FWIW, I'm willing to be the one to modify the code to implement this, assuming I don't run into any weird hugely difficult obstacles. |
If someone needs to benchmark output to |
Yes, easy, but requires additional code, at a level lower than merely specifying an output stream. Seeing the option in the benchmarking docs would be much more obvious to a not-very-experienced Rubyist who might not know about the |
99.99... of programs and programmers are used to the idea that there's stdin, stdout, stderr, and then other files. Having $stdout, STDOUT, my_stdout,... and so on differ may make the code a tiny bit shorter occasionally, but isn't worth breaking the model in most programmer's head. |
@duerst Could you elaborate? I don't understand what you are advocating. |
@keithrbennett I'm advocating the same thing as Marc-André. Sorry if that wasn't clear. |
@marcandre @duerst Could you help me understand why you object to supporting an output stream parameter? I understand that you are pointing to saving and restoring Also, is I think the code change would be pretty simple. Is it that you believe this feature would be used extremely rarely? |
Yes. Also consider using Or if you are testing complex systems (with other threads and Ractors that would output to stdout ??) consider using |
Closing; lib will now use |
For methods that print to standard output (
benchmark
,bm
, andbmbm
), it would be nice to be able to specify that they go to another stream instead, such as an open file or a string buffer (StringIO
), or even$stdout
, in case it has been changed to something other thanSTDOUT
.In cases where the method signature would not support another parameter, an alternate method could be added in which the stream is a parameter, the body of the original method moved there, and the original method remaining to call the new method with
STDOUT
, e.g.:...could become...
...and...
I believe all the likely objects for output would support
puts
,print
, etc. I'm not sure aboutsync
, but I suppose we could put arespond_to?
guard around that call.The text was updated successfully, but these errors were encountered: