Re: [julia-users] Conditional printing of logging info

[John Myles White]

I don't think there's a standard way. The thing that seems most natural to me would be defining a @log macro like:

macro log(s)
quote
if logging
print($s)
end
end
end

This inserts a global variable called logging everywhere, but there should be solutions for that problem.

-- John

On Sep 10, 2013, at 6:18 PM, Aditya Mahajan <adi.m...@gmail.com> wrote:

> Hi,
>
> What is the standard method of printing logging info in Julia?
>
> I have an iterative algorithm, say iteration(initial), and I want to invoke it in two ways:
>
> 1. iteration(initial; logging=true) which should print the value of some internal variable onto the screen,
>
> 2. iteration(initial; logging=false) which should not display this diagnostic information.
>
> Of course, I can use
>
> if logging
> @print("....")
> end
>
> inside the function, but that seems like a kludge. Is there a standard way of writing such logging functions in Julia.
>
> Thanks,
> Aditya
>

[Aditya Mahajan]

[Stefan Karpinski]

We really should come up with a single simple but flexible approach to this so that everyone doesn't have to do it themselves.

[Aditya Mahajan]

On Tue, 10 Sep 2013, Stefan Karpinski wrote:

> We really should come up with a single simple but flexible approach to this
> so that everyone doesn't have to do it themselves.

Yes, something along the lines of the Logging library of Java[1] or
Ruby[2] will be nice.

[1]: http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html
[2]: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html

Aditya

[Kevin Squire]

I wrote a basic logging package the other day, based somewhat on the python logging model.  I just cleaned it up and put it on Github:

https://github.com/kmsquire/Logging.jl.git

I haven't added it to METADATA yet, but to try it, you can do 

Pkg.clone("https://github.com/kmsquire/Logging.jl.git")

Basic usage is to do

using Logging

Logging.configure(level=INFO)  # DEBUG, INFO, WARNING, ERROR, CRITICAL

debug("some debug message")
info("some info message")
warn("some warning message")
err("some error message")
critical("some critical message")

Messages print in color if you're working at the Julia REPL, and in plain text otherwise.

Comments/suggestions welcome.  If this looks reasonable to others and no one objects, I'll add it to METADATA.

Kevin

[Stefan Karpinski]

Cool. (Also cool to see this being installed as an unregistered package – I think that's a good way to for packages to start out until they're more mature.) Would it make sense for normal errors and logging errors to have some integration? Also, would it make sense for these to be macros so that there can be zero overhead if you want to turn logging off?

[John Myles White]

Might also be nice to cycle back to the macro compile time zero overhead assertions brought up on the mailing list before.

 -- John

[WANG]

It's really nice! When would it go to METADATA?

在 2013年9月11日星期三UTC+8下午2时27分55秒，Kevin Squire写道：

[Kevin Squire]

I worked on it a little today.  I was hoping to get a version which included macro versions of the various log functions, but I haven't yet figured out a good way to do so.  My latest attempt is here:

https://github.com/kmsquire/Logging.jl/tree/with_macros

The master branch also contains some minor updates.

Does anyone have any suggestions on a good way to either

1) redefine macros if someone changes the logging level, or, if not,

2) suggest a good way to organize the code so that the user can choose a logging level and then have the appropriate macros defined

The function based interface will have more functionality than the macro-based interface, so ideally I'd like to have both.  One current issue with the interface is a name clash with `warn()` in Base--I couldn't come up with an alternate name.  I also would have preferred to use `error()` instead of `err()`, but again, Base already has `error()` and I didn't want to clash.  Suggestions also welcomed here.

[Stefan Karpinski]

The way that makes the most sense to me is to have a global flag in the Logging module that is consulted by the macro and code generation time indicating whether to emit any code or not. E.g.:

macro log(stuff...)

  enabled || return :nothing

  # generate logging code

end

I'm not entirely sure if this is the best approach, but it does allow zero-cost when the logging is disabled. On the other hand, it can't be changed at run-time.

[Aditya Mahajan]

> I'm not entirely sure if this is the best approach, but it does allow
> zero-cost when the logging is disabled. On the other hand, it can't be
> changed at run-time.

My use case was the following. I am writing a module Foo which does some
complicated calculation. So I want to log some information for debuging if
needed.

------------------------
module Foo

using Logging

complicated_function(...)

...

debug("message")
....

end
----------------------------


Now when using module Foo, I want to be able to set the logging level.

---------------------

using Foo
using Logging

Logging.configure(level=DEBUG)

complicated_function(....)

---------------------

Can something like this be done without run-time modification of logging
macros?

Aditya

[Kevin Squire]

Yes.  This works fine with the current function-based interface, which won't go away.  With the (not-yet-available) macro interface, you can set the level once, and use it, as in your example. The only thing you won't be able do easily with the macro interface is change the debug level of the code you're testing.  (In some cases, it might be possible to change the level by reloading the Logging module, but in many cases this won't work.)

I'll try to get this ready soon.

Kevin

[Matthias Bussonnier]

Why not have the logging-macro call the logging function ? 

That way you can enable/disable logging (at launch) and have zero-overhead. And dynamically change the logging level at run time if logging had been enabled.

-- 

M

Envoyé de mon iPhone

[Stefan Karpinski]

Well, you can't have zero overhead and turn the functionality back on at run-time without doing something more dramatic like rebuilding a lot of code – we don't have hooks for that kind of trickiness.

[Matthias BUSSONNIER]

Le 1 oct. 2013 à 20:55, Stefan Karpinski a écrit :

> Well, you can't have zero overhead and turn the functionality back on at run-time without doing something more dramatic like rebuilding a lot of code – we don't have hooks for that kind of trickiness.

What I meant was, 0-overhead if program is launch with logging off.
The macro part would be loggin on/off , and the function part would allow to select the logging level dynamically.
But the of course you couldn't change the logging level if logging is off.

--
M