You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, log.lvl uses a skip argument to select how many stackframes to drop. log.lvl{d,f} both set it at 3 before forwarding the call. Sadly, there is no way to set the relevant call depth from the outside. That's useful in order to provide preciser logging: sometimes, you want all the logger's call in a given function to prepend some identification string, which can be easily done by having some logger oneliner in the preamble; depending on how much a project using onet grows, it usually wants to build a logger upon the existing logging infrastracture, so, control over skip would be nice.
One trivial (but wrong) fix would be to have a var Skip uint in the log pkg, but as it is shared by everyone, some other parts might except a certain skip value, not the one you set.
Using a logger object, providing an interface similar to the one existing would allow for this use case separation.
The text was updated successfully, but these errors were encountered:
Currently,
log.lvl
uses askip
argument to select how many stackframes to drop.log.lvl{d,f}
both set it at 3 before forwarding the call. Sadly, there is no way to set the relevant call depth from the outside. That's useful in order to provide preciser logging: sometimes, you want all the logger's call in a given function to prepend some identification string, which can be easily done by having some logger oneliner in the preamble; depending on how much a project using onet grows, it usually wants to build a logger upon the existing logging infrastracture, so, control overskip
would be nice.One trivial (but wrong) fix would be to have a
var Skip uint
in the log pkg, but as it is shared by everyone, some other parts might except a certain skip value, not the one you set.Using a logger object, providing an interface similar to the one existing would allow for this use case separation.
The text was updated successfully, but these errors were encountered: