I appreciate the hard work you've done and look forward to the incorporation of your patch.

However, you indicate that you haven't completed testing yet ("the patch [...] might not compile without that"; assurance that the patch won't break compiles wold be reassuring.

Also, it would be easier to appreciate if your email employed standard spelling and punctuation.

Especially for our colleagues whose native languages are not English, figuring out "i" ("I"), "u" ("you"), "iv" or "ive" ("I've"), "r" ("are"), "rekon" ("reckon"), "coz" ("because"), "wont" ("won't"), and ",,," ("..." unnecessary ellipses which should be replaced with periods) makes understanding your email unnecessarily difficult.



Jonathan Gordon wrote:
hey,
last week i got the idea of getting logf used in the standard build in
the hope that it could be used to trace some of the painful bugs (i.e
wierd playback issues), so iv started work on making logf a bit
nicer,,,
so ive attached a patch with the my work so far hopefully to get some
feedback...
(i know we r in the freeze, but i rekon if this is used it might help
speed up the freeze....)
stuff ive changed so far:
removed some ROCKBOX_HAS_LOGF defines (u should still define it if u
want to test out the patch coz it might not compile without that
defined just yet)
added syslogf which is supposed to replace logf. the difference is
syslog allows a level for the log message.
the level is a combination of the subsystem (main thread, playback,
etc), and a error level warning, error, info, etc).

the idea with the levels is that errors with less severity then your
choice wont get logged, and even if the severity is higher than your
level, it will only get logged if its one of the sub-systems your
monitoring..
so, all that is left to do is remove the rest of the ROCKBOX_HAS_LOGF
defines, add a nice log viewer and get the rest of rockbox using it...

so yeah... whatcha think?

Reply via email to