|Re: [hatari-devel] Logging prefixes|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 05/07/2018 12:26 AM, Roger Burrows wrote:
On 6 May 2018 at 22:03, Thomas Huth wrote:
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
Mis-alignment was by design, to make different log level messages
stand out better from each other.
(This is mainly for warning messages, errors are normally
drastic enough to be obvious, but warnings could be easily
missed from Hatari output if one isn't especially looking
I don't have the feeling that the different lengths really help here.
It's rather that the output looks just some kind of untidy to me this
way. But that's likely just a matter of taste. What do the others here
I think unaligned messages are harder to read, so I favour Thomas's suggestion.
What I'm really hoping for in the next release is fewer messages during startup
(I know this was discussed earlier). I think most users don't want or need to
see most of the messages that appear in the current release. I count 37 lines
output by Hatari during startup; the only ones I care about are:
. Hatari version
. options (CPU, FPU etc)
. mount of hard drive image
. GEMDOS HDD emulation mapping
So IMO nearly 90% of startup messages are useless (& annoying actually) to the
Try the Mercurial version. Currently it gives following by default
on EmuTOS boot:
$ hatari --tos etos512k.img hd/
INFO: Hatari v2.1.0, compiled on: May 6 2018, 20:19:18
INFO: GEMDOS HDD emulation, C: <->
WARNING: Bus Error at address $ffff8006, PC=$e0006a addr_e3=e0006e
WARNING: Bus Error at address $ffff8282, PC=$e00156 addr_e3=e0015a
WARNING: Bus Error at address $ffff8400, PC=$e00170 addr_e3=e00174
WARNING: Bus Error at address $4fffff, PC=$e00c24 addr_e3=e00c26 op_e3=4a10
INFO: OS clock ticks / second: 100
WARNING: Bus Error at address $fffffa40, PC=$e00542 addr_e3=e00546
WARNING: Bus Error at address $fffffe00, PC=$e00c24 addr_e3=e00c26
WARNING: No GEMDOS dir
Above warnings are on warning level, because in some cases they
are real issues that explain why something user tried won't
work. Unfortunately on boot they're rarely useful.
BUT you can now remove *all* this output with "--log-level error"