for unknown reasons, the values accepted by verbose() and logpost() have an offset.

I have to admit I only checked with verbose() (which is used extensively in the Pd source code) and naively assumed that logpost() would work the same...

Here's a possible solution:

If we let PD_CRITICAL start at 5 (or even higher), then both verbose() and logpost() can differentiate between the old and the new log levels and add the respective offsets.

if (loglevel >= PD_CRITICAL) {
    // new log level
} else {
    // old log level
}

Since people would just use the enum values, they don't have to care about the actual numeric values anyway. I know, it is not aesthetically pleasing, but it would solve the issue at hand.

Christof

TL;DR i'd like to propose to unify the loglevels as used by verbose() and logpost()


for unknown reasons, the values accepted by verbose() and logpost() have an offset.

the current loglevels are like this:

logpost(x, 0,...) -> CRITICAL
logpost(x, 1,...) -> ERROR
logpost(x, 2,...) -> NORMAL
logpost(x, 3,...) -> DEBUG
logpost(x, 4,...) -> extra VERBOSE

verbose(-3,...) -> CRITICAL
verbose(-2,...) -> ERROR
verbose(-1,...) -> NORMAL
verbose(0,...) -> DEBUG
verbose(1,...) -> extra VERBOSE

for Pd-0.52, christof has created an enum to use labels that are easier to read and understand (PD_CRITICAL, PD_ERROR, PD_NORMAL, PD_DEBUG, PD_VERBOSE).
to add a bit of confusion, this enum is called "t_loglevel" but actually declares values that are usable by verbose() rather than logpost()

i would like to have both logpost() and verbose() use the same values (which should be aliased via the "t_loglevel" enum).


unfortunately, both methods are used by (a few) externals, so unifying the levels will change the verbosity of these externals.

my gut feeling tells me, that i would prefer the current behaviour or logpost() (with the most severe loglevel starting at 0, rather than some negative value).
alternatively, i think that a loglevel=0 should be the verbosity of [print] (aka NORMAL). however, this would change the verbosity of *all* libraries using any of verbose() or loglevel().

to see how bad a change would be, i've tried to check how many externals are actually using any of the two functions:

and luckily, there are not that many externals involved.

these results are based on externals i found on my harddisk

* externals using `verbose()`
- zexy: mostly uses verbose(1) to report errors
- iemguts (canvasdelete, autoabstraction): only calls verbose() once!
- triggerize-plugin, doublechord-plugin: uses verbose(10), which is "extra verbose" in all scenarios, so can be ignored)
- mediasettings
- hexloader
- Gem
- ggee (shell): uses verbose(4) which is always "extra verbose"
- hcs (folderlist)
- tclpd
- vstplugin~

* externals using `logpost()`
- hcs (ce_path, folder_list, passwd, helppath, classpath, stat, group, colorpanel)
- vbap
- iemnet
- iemmatrix: only extra VERBOSE
- maxlib: only extra VERBOSE
- unauthorized: only extra VERBOSE
- libdir: only DEBUG and above
- mrpeach (midifile, tcpclient): only DEBUG
- lua: only DEBUG
- tclpd: only DEBUG
- cyclone: original version uses only extra VERBOSE; porres' version doesn't use logpost() at all
- creb
- smlib
- log

i'm sure i missed many libraries, but i checked quite a few.


anyhow:

changing the levels used by verbose() to be "0"-based will make externals (that use verbose()) more chatty.
however, afaict, Gem and vstplugin~ are the only libraries in wide use where this might actually become an issue. and i guess "vstplugin~" is being actively enough developed to fix the problem by just pushing out a new version.

otoh, changing the levels used by logpost() to be "-3"-based will make externals (that use logpost()) less chatty.
in general this shouldn't be a big deal (as people can always raise the verbosity to see these messages).
in particular, many libraries using logpost() are very quiet anyhow (using DEBUG or extra VERBOSE), so there won't be that much change.


what do you think?


fdasr
IOhannes

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev