We can't always use stdio since Mruby is designed to use "embedded" to another softwares.
It can be both of applications and bare-metal.
And some might think he could another logging destination per each mrb_state.
For example It's possible each mrb_state runs on individual threads.
Based on such requirements, I suggest to add new logging framework.
It have library default logging destinations. They are pluggable in the runtime.
It also have logging destinations per mrb_state. They also are pluggable.
Please have a look mrb_log_print() in log.c.
You'll got the rule how logging framework choice the destination of message.
This is still trial-ballon version. So I applied this framework only to test/driver.c.
I'll apply to whole code if this plan was accepted.
Please review and comments.
Add logging framework.
Use new logging framework.
I'm all for such a feature. I'm actually all the time in the need to redirect stdio to UART etc.
But I'm wondering about the naming. Is it wise to call the printing prototype mrb_log_print? It might confuse people that the function is only been used for logging and not for talking to the current STDIO replacement. Just a suggestion: Maybe we can define at compile time a GEM which is an instance of IO to be the STDIO? In this case the standard would be screen but it could be replaced with a file, serial or even a network socket.
This would make the feature transparent.
Thanks for your comment. I think we need two layers for supporting character printing I/O.
The aim of this framework is to provide lower (C lang) level debug logging.
Their destinations will be Debug Communication Channels (by ARM), dual port memories, and so on.
Also it can redirect to UART as you say. But, they are all for debug logs.
So now I don't prepare Ruby API access to this framework.
Of couse I agree it's good to get high level layer framework, too.
It should have Ruby API.
It might have some compatibility with IO class described in ISO Ruby.
It's so excited. But I prefer to discuss about it as an another topic.
Ok I got it and I think seperating debugging and normal printing is a good idea. But then I just wondering that you consider the info message from mrbtest as debug output. Was this just for testing purpose? I wouldn't consider it relevant for debugging.
I thought that mrbtest may run on the target with no I/O.
But if my thought is true, we need to Ruby API as test results are printed by Ruby code.
I see it's not a good idea to patch for test/ now.
We might add Ruby API for debug output in the future. But it isn't now.
So I reject the patch for test/.
And I'll add patches for codegen.c or somewhere, instead.
Please keep this issue open until I re-push to here.
I should close it because this PR is too silly.