-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instrumenting a module with logging #16
Comments
Unfortunately, this is an intrinsic limitation of the logging macros right now: the macro definitions that are used are the ones that are available at parse time, which happens when you load the module. Calling For uses where you want the user to be able to redefine the logging level, you're probably going to need to use debug functions instead. So, for your example, this would be: module SomeModule
export some_function;
using Logging
Logging.configure(level=OFF)
function some_function()
debug("Run for cover!")
end
end and using SomeModule
using Logging
Logging.configure(level=DEBUG) # The default logger is the one being used in SomeModule
some_function() |
Thanks @kmsquire. That makes sense, and now I understand your |
Do you have a suggestion as to how the README might be clearer about this point? In some ways, this is a limitation in Julia herself. For example, if you redefine a function that has been used inside of another function, the previous version is still called: julia> f() = "hi"
f (generic function with 1 method)
julia> g() = f()
g (generic function with 1 method)
julia> g()
"hi"
julia> f() = "bye"
f (generic function with 1 method)
julia> f()
"bye"
julia> g()
"hi" This is because So I agree that it's less than ideal, but there's not much I can do about it until Julia starts keeping track of function dependencies and invalidating/recompiling functions when the functions and macros they call are redefined. |
I've been looking at adding logging to my modules and wonder about this as well. The more common pattern I've seen is that the logging level is queried on each evaluation. What a macro is great for is effectively inserting the That is especially important if you want structured log messages which are increasingly supported by logging back-ends. For instance, you might want to say this
And a logger might add some additional detail to it (The https://github.com/forio/Lumberjack.jl package does this nicely, though with some gimmicky names) The problem with calling this as a function is that even if your log level is less than info, you still endure the cost of creating that dictionary. A standard solution in a functional language is to wrap that in a lambda, which is only executed when the log level is high enough
But here again, you endure the cost of creating an anonymous function. Some languages make that cheap, Julia at the moment doesn't really. But even so, a macro is even more efficient
can just be converted into
and you have the best of both worlds: avoiding object creation overhead but still doing a (fairly cheap) runtime check so that logging levels can be jacked up if necessary without restarting existing code. I'm curious if this approach has appeal to you? |
Given the shortcomings of the current approach, I'd say it makes sense and sounds like a good alternative. (It also might make sense to simply borrow code from Lumberjack, but renaming to something more boring.) |
I'm also curious if there's some clever way to put a |
How do you suggest one instrument a module with logging? In the situation I have in mind, functions exported by the module call logging macros, but logging is turned off by default. Users should be able to enable logging in their own scripts if they want to. Something in the vein of
In the user's script,
I can't seem to find the intended syntax to achieve this.
The text was updated successfully, but these errors were encountered: