|Re: [hatari-devel] Recent Hatari change problems|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I commited updated version of the change and some other
output reductions for the default log level.
Few of these probably should also be using Log_Printf():
grep printf src/*.c|grep -i warn
I also reverted the broken CMake test for bashisms.
Don't use find. In my case your test wanted to wrangle with ~500
shell scripts (I have some of my own tests stuff in subdirectories
in my local Hatari Mercurial repo, and they include symlinks
If you don't want to explicitly list the relevant
files, limit them to the files in the repository:
hg files | grep '\.sh$'
hg files -I 're:.*\.sh$'
(I tried fixing that, but after that CMake complained about
the REGEX lines which I didn't touch so I gave up.)
As all the shell files are now fine, I think best would be
to have *one* test (script) that checks all shell scripts:
for i in $(hg files -I 're:.*\.sh$'); do
echo "*** $i ***"
errors=$(($errors + $?))
echo "ERRORS: $errors"
If you check shell scripts, you might also consider checking
relevant Python scripts for v2 & v3 compatibility:
hg files | grep '\.py$' | grep -v python-ui
(Python-UI is Python v2 only due to PyGtk dependency.)
Not sure what's the best way for that though. For example:
pylint --disable=all --reports=n --enable=E
E.g. in Debian stable seem to be broken:
* it reports bogus errors about print statement (although print
is used as function, not statement) for all the scripts:
* it claims that socket object is missing sendall() member,
although both v2 & v3 have that:
(And pychecker had problems with system ssl module.)
On 04/24/2018 01:00 AM, Eero Tamminen wrote:
On 04/19/2018 01:43 PM, Thomas Huth wrote:
On 19.04.2018 00:08, Eero Tamminen wrote:
I though it best to change all options.c logging to respect log
levels, instead of logging being a flag for option parsing. See
Bad idea. That way, all those "debug" log messages would show up during
normal program start again (with log level == info) and we're back to
where we started. So no, please don't do this.
The main thing was to make it respect logging level. That way
user can control the verbosity instead of it being hard-coded
like now. What level should be used for each individual message
is another thing .
I started to think best would be just fixing log.c to work better.
Attached is patch for that, after which the Opt_Log() stuff can be
changed to using Log_Printf().
 I guess debug level is OK for most of the messages, but
couple of them are such that they need to be output by default:
-D/--debug toggle, --debug-except, --disasm options
(These are relevant only when using debugger, so it should
be fine even with you :-). VDI messages I mentioned earlier,
come from vdi.c not options.c, and I already changed that to
output info only if it needed to modify user requested screen