[Scummvm-devel] MT-32 option causing crashes / silent exits in 1.3.0

[Miguel Bernabeu]

>>On Sun, Jun 5, 2011 at 1:14 PM, Miguel Bernabeu <mukik182 at gmail.com>
wrote:
>> Hi Max,
>>
>> I'm sorry this is kind of unrelated, but it looks to me as if scummvm
>> doesn't have a centralized logger system. I mean a class that manages
where
>> to publish the log entries. By the last mails it looks to me as if every
>> error has to be handled independently instead of in a similar way.
>>

> Since error handling is more than just  error displaying that is
> pretty much clear. And a central logger doesn't really sound like it
> would make handling the error any easier, except if by "handling" you
> mean "displaying it to the user and quit when he noticed".

Yes, I wasn't referring to error handling but to the problem of no error
message being seen by the user and thus no report and maybe sense of lack of
care. I consider error handling and error reporting two separate subjects
related only in that all errors should be reported in one form or another.

>> I'm asking because I think a central log class in which you publish a
>> message and level of logging and the class itself handles where the
message
>> should be displayed (debug console, GUI, logfile, etc) could come in
handy
>> if it could be supported on all ports.
>>

> We have the debug*, warning, error functions which print to both
> stdout/stderr and our log file. error in fact also prints to the
> ingame debug console. In case of debug we also have debug levels and
> debug channels.

I wasn't completely sure of how was the logging managed, I supposed you had
some functions but didn't know how you did it.

> It shouldn't be too much effort to extend debug/warning to also print
> the debug messages to the ingame debug console, if there is any.

Extending those functions is mainly what I would accomplish with the central
system. You could have done the logging in several ways, some of them
non-extensible or at least not easily. That was the main reason for me to
ask.

> Anyway this gets pretty much off topic.

I agree. I'm now informed, thank you very much

2011/6/5 Johannes Schickel <lordhoto at gmail.com>

> On Sun, Jun 5, 2011 at 1:14 PM, Miguel Bernabeu <mukik182 at gmail.com>
> wrote:
> > Hi Max,
> >
> > I'm sorry this is kind of unrelated, but it looks to me as if scummvm
> > doesn't have a centralized logger system. I mean a class that manages
> where
> > to publish the log entries. By the last mails it looks to me as if every
> > error has to be handled independently instead of in a similar way.
> >
>
> Since error handling is more than just  error displaying that is
> pretty much clear. And a central logger doesn't really sound like it
> would make handling the error any easier, except if by "handling" you
> mean "displaying it to the user and quit when he noticed".
>
> > I'm asking because I think a central log class in which you publish a
> > message and level of logging and the class itself handles where the
> message
> > should be displayed (debug console, GUI, logfile, etc) could come in
> handy
> > if it could be supported on all ports.
> >
>
> We have the debug*, warning, error functions which print to both
> stdout/stderr and our log file. error in fact also prints to the
> ingame debug console. In case of debug we also have debug levels and
> debug channels.
>
> It shouldn't be too much effort to extend debug/warning to also print
> the debug messages to the ingame debug console, if there is any.
>
> Printing directly to some GUI is also not always possible, mostly in
> case it's debug messages from the sound thread (i.e. some audio
> driver, audio stream etc. code). Since the code is run from another
> thread it can not access the graphics functionality, since for example
> backends like Android or in generally most OpenGL based backends, do
> only allow to access OpenGL functionality from the thread where the
> OpenGL context was initialized.
>
> Anyway this gets pretty much off topic.
>
> // Johannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110605/c218f1a7/attachment.html>