-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i move that to the list, as it makes discussion easier.
On 2012-02-27 15:32, SourceForge.net wrote:
Comment By: Hans-Christoph Steiner (eighthave)
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense.
i totally agree that "+4" doesn't make sense at all. i wonder though what you mean by "leave verbose()'s custom level numbering the same". the same as what?
from the start of verbose() (which was long before the "custom" loglevels of logpost()) the idea was as follows: verbose() should be used for messages that are more verbose (==less important) than post(). you can increase verbosity by passing one or more "-verbose" arguments to the cmdline. when raising verbosity, you will suddenly see messages that you did not see with a lower verbosity.
"verbose(0)" is meant to be a default (low) verbosity, that is still less important than post() keep in mind that this was all before the loglevel stuff; from that pov it would make no sense at all to have verbose(1) to be more important than post() and verbose(3) to be less important than post(). instead, all ordinary (that is: >0) verbose-levels are always considered less important than the "show always" post.
this should still hold true!
furthermore, verbose(0) was meant to have a "similar" verbosity than post() (but - again - never a higher priority).
somebody (while i remember you saying that the arbitrary number '4' was introduced by me after much fighting with you and miller, i still cannot remember that; what i can remember is that i wanted verbose() to use the loglevel implementation) introduced a random offset of "4", which makes verbose(0) to only output things if you switch the loglevel to "all", rather than "debug", which is precisely the loglevel for which verbose() was meant.
the only reason i see to keep verbose() at "+4" is to discourage it's use. (which might be what you want, if you think that loglevel() is more easily understandable)
leaving our differences aside, what i think could be an interesting change in semantics here, is to output all verbose() messages at loglevel:=3 (debug) though still apply the filtering based on verbosity. e.g. both verbose(0, "foo") and verbose(1, "bar") will show at "debug" level, but the latter will only show up if the user manually raised the verbosity with the "-verbose" flag to at least "1".
and yes, it makes sense to differentiate between a gui-loglevel and a system-verbosity, if you generate loads and loads of messages for debugging which you normally would like to never see on the wire between pd & pd-gui.
g fasdmr IOhannes
If post(), error(), etc. are your examples, then verbose() should have no level argument, just the fmt, then it could post at level 4. That makes sense to me. If verbose() is meant to post messages at varying levels, then it should use the same numbering scheme as everything else, i.e.
logpost(1) == verbose(1)
.hc
On Feb 27, 2012, at 10:15 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i move that to the list, as it makes discussion easier.
On 2012-02-27 15:32, SourceForge.net wrote:
Comment By: Hans-Christoph Steiner (eighthave)
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense.
i totally agree that "+4" doesn't make sense at all. i wonder though what you mean by "leave verbose()'s custom level numbering the same". the same as what?
from the start of verbose() (which was long before the "custom" loglevels of logpost()) the idea was as follows: verbose() should be used for messages that are more verbose (==less important) than post(). you can increase verbosity by passing one or more "-verbose" arguments to the cmdline. when raising verbosity, you will suddenly see messages that you did not see with a lower verbosity.
"verbose(0)" is meant to be a default (low) verbosity, that is still less important than post() keep in mind that this was all before the loglevel stuff; from that pov it would make no sense at all to have verbose(1) to be more important than post() and verbose(3) to be less important than post(). instead, all ordinary (that is: >0) verbose-levels are always considered less important than the "show always" post.
this should still hold true!
furthermore, verbose(0) was meant to have a "similar" verbosity than post() (but - again - never a higher priority).
somebody (while i remember you saying that the arbitrary number '4' was introduced by me after much fighting with you and miller, i still cannot remember that; what i can remember is that i wanted verbose() to use the loglevel implementation) introduced a random offset of "4", which makes verbose(0) to only output things if you switch the loglevel to "all", rather than "debug", which is precisely the loglevel for which verbose() was meant.
the only reason i see to keep verbose() at "+4" is to discourage it's use. (which might be what you want, if you think that loglevel() is more easily understandable)
leaving our differences aside, what i think could be an interesting change in semantics here, is to output all verbose() messages at loglevel:=3 (debug) though still apply the filtering based on verbosity. e.g. both verbose(0, "foo") and verbose(1, "bar") will show at "debug" level, but the latter will only show up if the user manually raised the verbosity with the "-verbose" flag to at least "1".
and yes, it makes sense to differentiate between a gui-loglevel and a system-verbosity, if you generate loads and loads of messages for debugging which you normally would like to never see on the wire between pd & pd-gui.
g fasdmr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9LnfoACgkQkX2Xpv6ydvQp6ACgyXpUe5tlt02EWXEXn+KKljf/ DoQAoPNxLBHmQTFCd5Y7+xBHexfeS7sH =jTRm -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
On 02/27/12 19:34, Hans-Christoph Steiner wrote:
If post(), error(), etc. are your examples, then verbose() should have no level argument, just the fmt, then it could post at level 4. That makes sense to me. If verbose() is meant to post messages at varying levels, then it should use the same numbering scheme as everything else, i.e.
it's the other way round. if you insist on that, then logpost() should have the same numbering scheme as everything else: logpost(0)==post() logpost(1)==verbose(1) logpost(-1)==error()
fgmadsr IOhannes
On Mon, Feb 27, 2012, at 22:30, IOhannes m zmölnig wrote:
On 02/27/12 19:34, Hans-Christoph Steiner wrote:
If post(), error(), etc. are your examples, then verbose() should have no level argument, just the fmt, then it could post at level 4. That makes sense to me. If verbose() is meant to post messages at varying levels, then it should use the same numbering scheme as everything else, i.e.
it's the other way round. if you insist on that, then logpost() should have the same numbering scheme as everything else: logpost(0)==post() logpost(1)==verbose(1) logpost(-1)==error()
I don't think a numbering range from -2 to 2 makes much sense, like you suggest here. Programmers start counting from 0, not -2. You might want to double-check the code if you are wondering how everything else works:
src/s_print.c static void dopost(const char *s) { ... sys_vgui("::pdwindow::post {%s}\n", strnescape(upbuf, s, MAXPDSTRING));
tcl/pdwindow.tcl proc ::pdwindow::post {message} {logpost {} 2 $message}
proc ::pdwindow::verbose {level message} { incr level 4 logpost {} $level $message
The numbers on the Pd window are 0 - 4 and the verbose proc uses "incr level 4" to add 4 to the level before posting, thereby making its own level numbering scheme that is off by four from the rest.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-28 04:32, Hans-Christoph Steiner wrote:
On Mon, Feb 27, 2012, at 22:30, IOhannes m zmölnig wrote:
On 02/27/12 19:34, Hans-Christoph Steiner wrote:
If post(), error(), etc. are your examples, then verbose() should have no level argument, just the fmt, then it could post at level 4. That makes sense to me. If verbose() is meant to post messages at varying levels, then it should use the same numbering scheme as everything else, i.e.
it's the other way round. if you insist on that, then logpost() should have the same numbering scheme as everything else: logpost(0)==post() logpost(1)==verbose(1) logpost(-1)==error()
I don't think a numbering range from -2 to 2 makes much sense, like you suggest here. Programmers start counting from 0, not -2. You might want to double-check the code if you are wondering how everything else works:
that is entirely not the point [*]
you suggest that "loglevel "does it right, whereas "verbose" is the odd player here. my point was that it is not. all the problems come from trying to force verbose() into the loglevel() syntax, and finding that it has a different bias. neither loglevel() nor verbose() have the 'right' bias. unfortunately the 2 biases are different.
src/s_print.c static void dopost(const char *s) { ... sys_vgui("::pdwindow::post {%s}\n", strnescape(upbuf, s, MAXPDSTRING));
tcl/pdwindow.tcl proc ::pdwindow::post {message} {logpost {} 2 $message}
proc ::pdwindow::verbose {level message} { incr level 4 logpost {} $level $message
afaik, "::pdwindow::verbose" is nowhere used on the C-side (you might want to double-check the code)
The numbers on the Pd window are 0 - 4 and the verbose proc uses "incr
what do those numbers prove? how come you think those numbers normative (apart from you being involved in their introduction and you not being involved in verbose()-levels?)
mfgasdr IOhannes
[*] btw, with "programmers start counting at 0" you imply that they only count in one direction. i was not suggesting that the numbering range is - -2..+2 but rather than "0" is the _default_ post level and lower numbers are more important than higher numbers. this allows for more error levels (grave, critical, fatal, atomic,...). all negative numbers would be errors, while all positive numbers would be infos. in linux you have a similar scheme with process priorities (where negative numbers denote realtime priorities)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
trying to take the heat out of this:
my patch suggested to change the loglevel offset from "+4" to "+3". is there anything speaking against this specific change?
(it seems that all discussion is centered around the question whether there should be an offset at all, rather than how big it should be)
fgmasdr IOhannes
Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest.
.hc
On 02/28/2012 04:45 AM, IOhannes m zmoelnig wrote:
trying to take the heat out of this:
my patch suggested to change the loglevel offset from "+4" to "+3". is there anything speaking against this specific change?
(it seems that all discussion is centered around the question whether there should be an offset at all, rather than how big it should be)
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-28 16:03, Hans-Christoph Steiner wrote:
Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest.
may i ask why? what makes "4" better than "3"?
fgmasdr IOhannes
On 02/28/2012 10:06 AM, IOhannes m zmoelnig wrote:
On 2012-02-28 16:03, Hans-Christoph Steiner wrote:
Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest.
may i ask why? what makes "4" better than "3"?
+4 already there. +3 an incompatible change that does not fix things.
.hc