|Re: [hatari-devel] fopen traces|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On tiistai 26 toukokuu 2015, Nicolas Pomarède wrote:
> Le 26/05/2015 21:41, Eero Tamminen a écrit :
> > Hatari has few thousand prints, of which 1/3 goes to stderr, see:
> > $ find src/ -name '*.c' | xargs grep -e printf -e fput |\
> > grep -v -e gencpu.c -e build68k.c -e Dprintf -e ':\w*//'
> > Looking at the output there are some clear inconsistencies
> > which should be fixed, but error messages seems to go fairly
> > consistently to stderr. For debugger to be usable, error
> > messages for its commands should naturally also be visible.
> > I don't think changing all Hatari error messages which could
> > be triggered by debugger, to go to stdout, is worth this.
> Still, I think I will change those in cpu/* uae-cpu/* to use stdout when
> it's supposed to be called from the debugger.
> In src/*, I think some could be easily fixed in the "xxx_Info()"
> functions (for example Video_Info). It would be better to add a "FILE *"
> parameter and let the uppper level calling function pass the correct
I like the idea.
It's a bit more work though, because debugInfo.c has it's
tentacles everywhere (including DSP & CPU memory dumping &
disassembly and debugger command parsing), and those would
need to be changed to take FILE* arg too.
Probably better done after the release (might add todo.txt
item for it).
> (stdout, stderr, or even a real file in case we want to use
"--trace-file" should contain only trace output. This
is important if external program (e.g. Hatari Python UI)
gives fifo as file and data from that to a separate trace
data viewer window.
"--log-file" might be more suitable for normal debugger output.