hey IOhannes,
Why generate verbosity levels on the fly? So far we've been using the syslog levels, I think we should stick with that and use that throughout.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=...
.hc
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
On 2010-03-17 17:51, Hans-Christoph Steiner wrote:
hey IOhannes,
Why generate verbosity levels on the fly? So far we've been using the syslog levels, I think we should stick with that and use that throughout.
so far nobody has been using "syslog" levels. i don't know when they entered the game.
however, the main reason to "generate on the fly" was, that i prefer to say "i want loglevels up to 7" rather than i want loglevels "1" and "2" and "3" and "4" and "5" and "6" and "7".
at a central point in the code i define a "maxverbosity". the code then generates menuitems for each loglevel. in the past there was a "maxverbosity"; and then there was a menu, where you could chose totally unrelated loglevels; code relying on maxverbosity (e.g. colouring code), would work only by chance with the loglevels selected by the menu. i prefer to change values in a single place. and i prefer to let computers do what they are better at than me (e.g. counting)
if "syslog" for you means you have loglevels 0..7, then go ahead and set maxverbosity to "7" and that's it.
if instead of system administration, you want to go with many programming frameworks (log4j and it's various clones like log4c, log4perl, log4..), set the maxverbosity to "5".
i agree that we should eventually agree on a common maxverbosity. but this should still be managed centrally, and not cluttered around the code.
fgamsdr IOhannes
On Mar 17, 2010, at 1:29 PM, IOhannes m zmoelnig wrote:
On 2010-03-17 17:51, Hans-Christoph Steiner wrote:
hey IOhannes,
Why generate verbosity levels on the fly? So far we've been using the syslog levels, I think we should stick with that and use that throughout.
so far nobody has been using "syslog" levels. i don't know when they entered the game.
however, the main reason to "generate on the fly" was, that i prefer to say "i want loglevels up to 7" rather than i want loglevels "1" and "2" and "3" and "4" and "5" and "6" and "7".
at a central point in the code i define a "maxverbosity". the code then generates menuitems for each loglevel. in the past there was a "maxverbosity"; and then there was a menu, where you could chose totally unrelated loglevels; code relying on maxverbosity (e.g. colouring code), would work only by chance with the loglevels selected by the menu. i prefer to change values in a single place. and i prefer to let computers do what they are better at than me (e.g. counting)
if "syslog" for you means you have loglevels 0..7, then go ahead and set maxverbosity to "7" and that's it.
if instead of system administration, you want to go with many programming frameworks (log4j and it's various clones like log4c, log4perl, log4..), set the maxverbosity to "5".
i agree that we should eventually agree on a common maxverbosity. but this should still be managed centrally, and not cluttered around the code.
This sounds a lot more complicated without much real gain. How about just emulating syslog? Its a tried true way to do it, and it is already widely understood and documented.
- messages post at log levels 0-7 - the menu item sets the "all levels up to X" - the messages are tagged with level to be optionally colorized
.hc
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
On 2010-03-17 21:18, Hans-Christoph Steiner wrote:
This sounds a lot more complicated without much real gain. How about
where do you see any complication? it can't be on the code side: it's exactly one more line of code to have a centrally configurable system instead of having hardcoded defaults everywhere in the sources. maintaining code with hardcoded assumptions is "complicated" without _any_ gain.
there is certainly some complication going on in this conversation.
i really don't understand why you even mention me removing the "1 2 3 4 5 6 7" by a list generated on the fly. it's not that anybody would be particularily proud of this line (nor its replacement).
it's not that we are talking about 100 lines of code that are to be written in the future, but about 1 line written in the past.
just emulating syslog? Its a tried true way to do it, and it is already widely understood and documented.
true, for system administrators in *nix world.
- messages post at log levels 0-7 - the menu item sets the "all levels up to X" - the messages are tagged with level to be optionally colorized
hmm
i think the tried and accepted (as well as widely understood and documented) standard for logging in "programming environments" is rather log4j ([1]); there is a clone for virtually any widespread language; on any operating system; the target audience is programmers rather than system administrators, and i think most Pd'ers are more of the former (even if they don't like it) than of the latter.
features:
- messages post at log levels 0-5 - the menu item sets the "all levels up to X" - the messages are tagged with level to be optionally colorized
you see the main difference is the maximum log level. instead of ranting that i set the loglevel down to 0..4 you could have set a single number to "7" and be happy. i don't know why ignored this possibility in the first place.
gmsdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig