[Freemint-list] Handling of PRGs/APPs which console output

Sat Jan 7 07:44:05 MSK 2017

I see the discussion is advancing nicely. ;-) I'll try to present my
counter-arguments for every statement.

On 6 January 2017 at 23:38, Vincent Rivière <vincent.riviere at freesbee.fr>
wrote:

> 1) TOS compatibility is to trash the screen
True but that doesn't mean FreeMiNT can't evolve, we used to have six ACCs
and one app only.

> 2) Better behaviour would be to buffer console output somewhere, and
display it (including old lines) only when requested, for example when
TosWin2 console is opened.
Yeah, that's basically how /dev/xconout2 works if opened. Currently,
TosWin2 doesn't read old content when console is opened but as I think
about it, it could. And we'd need to enlarge the buffer in /dev/xconout2.

> 3) A more complicated approach would be to automatically open a private
TosWin2 terminal as soon as some GEM program does text output. Probably
overkill.
TosWin2 actually offers this feature.

Only problem I see is that TosWin2 is not something which is setup
implicitly. So you still have to make it auto run in xaaes.cnf, set it to
log the output and keep it running in the background. If you fail to do
that -- your desktop will break on an occasion.

On 7 January 2017 at 03:14, Jo Even Skarstein <joska at online.no> wrote:

> 1. A tiny program that simply opens /dev/xconout2 and doesn't care about
it's output. This will effectively eat all output to stdout as long as this
program runs. Autostart it from the auto-folder, xaaes.cnf or desktop. Then
if you need to see debug output you must either start the program from a
shell, or tell Teradesk that it's a TOS/TTP which will run it from TosWin2
(or whatever is installed as TOSRUN).

Compare to this: you go to XAAES.CNF, enter one line in the "app_config"
section telling the app to use $TOSRUN and forget about it. See, it's even
less text to explain the feature. ;-) This approach has at least two flaws:
1. you must start an external tool (which can get lost, deleted etc) 2. you
rely on TeraDesk's functionality

> 2. A tiny program that takes the path/name to an executable as parameter.
This program will redirect stdout to /dev/null, launch the program
specified on it's commandline, restore stdout and exit. This will eat all
output to stdout for this particular program.

This is better but then again, from user perspective I see the problem that
I must know about this. I.e. I get corrupted screen, I must realise that
"Oh no, the Evil Developers let stdout open, I must go on and start it with
the Magic Launcher!". So you see, letting OS handle it for me and
optionally, when I suspect something is wrong (or the program's author
tells me to do so) I go and enable the output seems much more user friendly.

> Let's be honest, we're talking about one particular program here :)

Peter has mentioned MyMail as another. Pierre has mentioned a library
output. That's already three. So this is again the "we live in a perfect
world" and "I don't see any problem on my setup" argument which I don't
buy. :)

> frequently see popups with notifications from apps and the OS. MiNT/XaAES
does not have such a system.

You're saying that GEM apps can't communicate with the user using dialogs?
Or that even FreeMiNT/XaAES can't? Come on. Now I use the same argument as
you: if there's a super important stuff written to stdout in the kernel,
make it an alert, in other words, fix it there and don't create artificial
arguments why we need destroyed screens. ;)

> If you eat all output to stdout by default, you will never know that
Papyrus aborted due to lack of memory

It's unfortunate that the authors had chosen such way for such an important
message and of course we can't change it (it's rather confusing that in
this case you propose to bend OS features due to the non-fixable nature of
this situation while in the case of the output you don't like you refuse to
accept it as status quo, i.e. consider it non-fixable as well).

Case in point: just a few days back an user tried Sqward's uIP Tool for
EtherNEC. It worked well on his Falcon and refused to work on his ST. And
it's a TOS (console) program. There was virtually no help from the console
at all. So you see, same problem, you did have the console and yet you had
to ask the author. Because that's what users do. Ask people. They do not
study stdout.

On 7 January 2017 at 03:54, Thorsten Otto <admin at tho-otto.de> wrote:

> if it is a debug build, then users should know to expect output from it.
In that case its their fault if they are complaining about it

Sorry Thorsten but this is awfully close to Lennart Poettering's arguments
about how systemd can break anything and if it does, it's the user who
should adapt, not them fixing the broken environment. Never heard of a
developer shipping debug version by mistake? That's an excuse in your eyes
to destroy user's desktop?

> There are some runtime libraries that print an error, then abort the
program on certain fatal conditions. Since the program is going to exit
anyway, i think this output is acceptable,

Guys, you're missing the point. Users don't care, users don't read, users
don't wanna know. Sure our Atari world is little bit specific (we've
hardened our users, not only technically but also linguistically, see all
the German-only apps ;-)) but that's not an excuse for "it's not our
problem but the user's".

> especially because in most cases those libraries usually wait for a
keypress for confirmation. I think you don't want to have a program hang
around forever waiting for a  key and don't know what happened because you
did not see the error message...

If there's a GEM program which silently waits for getchar() then the
program is seriously flawed, what if my console is redirected to a file?
(mind you, this is already present in FreeMiNT!) I wouldn't use such an
extreme case as support for visible stdout.

On 7 January 2017 at 06:43, Helmut Karlowski <helmut.karlowski at ish.de>
wrote:

> Maybe it would be possible to test in xconout if the output-file is
> connected to a pipe OR if no physical workstation is open (or let
> XaAES set a flag in the kernel)  and if not
> just don't print anything.
>
> Don't know if it can be done effectively atm (and if I'd want it).
>
> _______________________________________________
> Freemint-list mailing list
> Freemint-list at mail.atariforge.org
> http://mail.atariforge.org/mailman/listinfo/freemint-list
>

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170107/aafe726c/attachment.html 