make sure the demos are printing messages to stderr, not stdout

[sleeptightAnsiC]

arbitrary logging should all go to stderr

stdout is only meant for "meaningful" output (aka something that other program can consume)

I've talked about this at least once at...
https://discord.com/channels/922234432071548968/922234432071548973/1471664190774313062
...where this behavior was annoying to deal with during #902

This wasn't a big deal back then, but recently the idea about dumping style and color tables to pipe/file was born at #914, and obviously if some random logging message appears at stdout before the dump was done, it will corrupt it.

Here is a gist showing (most?) occurrences:
https://gist.github.com/sleeptightAnsiC/3231edf75b8f4edec82bf9ceab6f6f0e
I can probably replace them all programmatically with SED

This is NOT urgent at all. Just wanted to track it somewhere. Any thoughts?

cc @rswinkle , @PavelSharp , @RobLoach

[rswinkle]

arbitrary logging should all go to stderr

stdout is only meant for "meaningful" output (aka something that other program can consume)

The standard only says:

" stderr
stdin
stdout

which are expressions of type ``pointer to FILE '' that point to the
FILE objects associated, respectively, with the standard error, input,
and output streams."

And if we look at cppreference it says:
"2) Associated with the standard output stream, used for writing conventional output. At program startup, the stream is fully buffered if and only if the stream can be determined to not refer to an interactive device.
3) Associated with the standard error stream, used for writing diagnostic output. At program startup, the stream is not fully buffered."

"Meaningful" is subjective, because meaningful to who/what?. I would say "normal" output but again, subjective. And for your parenthetical, well, all output is consumable by other programs. The line between "normal" and "diagnostic" or "error" messages is fuzzy.

I know I'm being a bit pedantic but there is no universally agreed upon clear cut delineation between stdout and stderr and to pretend there is is disingenuous.

I've talked about this at least once at... https://discord.com/channels/922234432071548968/922234432071548973/1471664190774313062 ...where this behavior was annoying to deal with during #902

Not all of us use discord, just FYI

This wasn't a big deal back then, but recently the idea about dumping style and color tables to pipe/file was born at #914, and obviously if some random logging message appears at stdout before the dump was done, it will corrupt it.

Again, this is a DRAFT, and was not meant to be the final form, just a proof of concept and spark for discussion/ideas. Also, note I specifically made every function take a FILE* parameter fully intending to pass something other than stdout at some point, whether that be a hard coded "styles.txt" or something the user selected once we integrated the right GUI elements (file selector, or simple edit field even).

Here is a gist showing (most?) occurrences: https://gist.github.com/sleeptightAnsiC/3231edf75b8f4edec82bf9ceab6f6f0e I can probably replace them all programmatically with SED

I do agree that using fprintf with a hard coded stdout is always pointless because you might as well be using printf at that point.

While none of that output bothers me (less/file redirection and grep/search exist for a reason when a program truly has a flood of output, regardless of if it's stdout or stderr), I'm fine with making the startup info go to stderr. However I feel like the GUI interaction (ie "button pressed\n") output should remain with stdout. I consider that more "normal" output than "diagnostic" output.

This is NOT urgent at all. Just wanted to track it somewhere. Any thoughts?

cc @rswinkle , @PavelSharp , @RobLoach

[sleeptightAnsiC]

https://discord.com/channels/922234432071548968/922234432071548973/1471664190774313062

Not all of us use discord, just FYI

Sure - https://gist.github.com/sleeptightAnsiC/fb0ef6b751a094ea4b38fbf62db7ef9e - If you see similar DC links anywhere, let me know and I'll copy the contents for you. I'm aware you don't use it.

I know I'm being a bit pedantic but there is no universally agreed upon clear cut delineation between stdout and stderr

Logging not going to stdout, I always thought it was common sense. This was the reason behind why they created separate file descriptor for stderr to begin with: https://en.wikipedia.org/wiki/Pipeline_(Unix)

The thing from cppreference says "[stderr] used for writing diagnostic output.", and message saying "button pressed" kinda falls under "diagnostic output". This seems to be proving my point (?)

the idea about dumping style and color tables to pipe/file was born at #914

this is a DRAFT, and was not meant to be the final form

Your draft wasn't the first time when I thought about this problem, and it surely won't be the last time. Dumping configs to stdout is reasonable. Someone will want to do something similar sooner or later.

I'm fine with making the startup info go to stderr. However I feel like the GUI interaction (ie "button pressed\n") output should remain with stdout.

I feel like that would make things even worse. Why would someone expect these to differ?

Honestly, not sure why I'm getting such pushback on this one? If the demo runs from terminal (which I've seen you doing) it doesn't matter where it goes. stderr and stdout appear in the same way there. It only matters for people who redirect it. Do you have some script that listens for "button pressed" or something similar? I'm really confused.

[RobLoach]

stderr would be for error. stdout is the standard output. "button pressed" is not an error.

Makes sense for "[GFLW] failed to init!\n" to be stderr.

[RobLoach]

Aside, but maybe it makes sense for some of those to be NK_ASSERT, or program-specific SDL_Log or something.

[rswinkle]

Logging not going to stdout, I always thought it was common sense. This was the reason behind why they created separate file descriptor for stderr to begin with: https://en.wikipedia.org/wiki/Pipeline_(Unix)

The thing from cppreference says "[stderr] used for writing diagnostic output.", and message saying "button pressed" kinda falls under "diagnostic output". This seems to be proving my point (?)

Logging yes, though again for me personally I don't really care and sometimes it's easier if it's all it one stream and it's easier to just do > than &2>1 or remember &> is a shortcut for "command > file.txt 2>&1"

See below.

Your draft wasn't the first time when I thought about this problem, and it surely won't be the last time. Dumping configs to stdout is reasonable. Someone will want to do something similar sooner or later.

Fair enough.

I'm fine with making the startup info go to stderr. However I feel like the GUI interaction (ie "button pressed\n") output should remain with stdout.

I feel like that would make things even worse. Why would someone expect these to differ?

Honestly, not sure why I'm getting such pushback on this one? If the demo runs from terminal (which I've seen you doing) it doesn't matter where it goes. stderr and stdout appear in the same way there. It only matters for people who redirect it. Do you have some script that listens for "button pressed" or something similar? I'm really confused.

I don't feel strongly about this, and you're right that in this case with a visible terminal it's moot most of the time, but I consider messages like "button pressed" here, especially as it's a demo/overview program that everyone is going to look at to see how things work, to be a stand-in for GUI output. In other words, it's no different than your "TextInputActive? Yes/No" in the SDL3 demo. It may technically be "diagnostic" but in this context it is purposeful, user informative normal output for a demo that shows how things work, ie This is a normal button, vs this is how a repeater triggers, etc.

Again, you're right and for someone just running in the terminal it's all the same unless the redirect, but even though it's traditionally used for logging/diagnostic things and we can quibble over whether those apply here, I just can't help but feel that stderr shouldn't be used for things that we want the people using something to see under all conditions (Windows with it's broken GUI/terminal design notwithstanding).

Maybe this is just me talking myself around to taking all those print statement indicators/feedback and advocating for them to be integrated into the GUI somehow ....

[rswinkle]

stderr would be for error. stdout is the standard output. "button pressed" is not an error.

Makes sense for "[GFLW] failed to init!\n" to be stderr.

Exactly. You have summed up my position in two lines.

I was partially trying to avoid saying it so bluntly that these are not errors and so shouldn't be on stderr because I am at least ok with logging/diagnostic output being on it even though I'm just as happy with it on stdout.

[sleeptightAnsiC]

What? You guys think that "err" in "stderr" means "only for errors" ?

Alright, I've seen enough. Closing this one.

[sleeptightAnsiC]

Aside, but maybe it makes sense for some of those to be NK_ASSERT, or program-specific SDL_Log or something.

SDL_Log prints to stderr

[RobLoach]

For webversion one specifically, we should likely use SDL_LogInfo or SDL_LogError, and then in the frontend use console.log() or console.error() respectively.

We don't need that ugly textarea log box 😉

[rswinkle]

What? You guys think that "err" in "stderr" means "only for errors" ?

I specifically avoided saying that. That is the extreme form of my (our?) position.

I prefer to focus on the other side. Stdout is for what you want users to see. This makes obvious sense if you've ever developed a purely terminal based program. You output plenty of "diagnostic"/"feedback" on stdout to let the user know things are actually happening. Just because you add a GUI, doesn't the same idea doesn't apply, it's just because of Windows most people don't think about the terminal output and also partially because of Windows, that sort of stuff should be visible/accessible from the GUI if it really is important for all users, vs just power users for example.

Stderr is for everything else, especially for everything exceptional.

For webversion one specifically, we should likely use SDL_LogInfo or SDL_LogError, and then in the frontend use console.log() or console.error() respectively.

We don't need that ugly textarea log box 😉

Give me some credit, I was thinking more like what you did for the input section. We only ever print one line at a time, it could just be a label next to the element we're responding to, combined with a counter when necessary to show trigger differences and things like that.