Julia: means of suppressing ambiguity warnings

[catawbasam]

This issue is carried over from JuliaLang/IJulia.jl#116.

It would be useful at times to have a means of suppressing warnings such as the example below without suppressing errors.

@staticfloat has expressed interest in this issue, as has @StefanKarpinski. /base/util.jl lines 418:446 contains what looks like the seed of a lightweight logging approach along the lines @StefanKarpinski mentioned in the IJulia discussion

julia> using Winston
Warning: New definition
    |(SynchronousStepCollection,Any) at C:\Users\keithc\.julia\BinDeps\src\BinDe
ps.jl:283
is ambiguous with:
    |(Any,NAtype) at C:\Users\keithc\.julia\DataArrays\src\operators.jl:502.
To fix, define
    |(SynchronousStepCollection,NAtype)
before the new definition.
Warning: New definition
    |(Any,SynchronousStepCollection) at C:\Users\keithc\.julia\BinDeps\src\BinDe
ps.jl:286
is ambiguous with:
    |(NAtype,Any) at C:\Users\keithc\.julia\DataArrays\src\operators.jl:502.
To fix, define
    |(NAtype,SynchronousStepCollection)
before the new definition.

[JeffBezanson]

The way to deal with warnings is to fix them, not to disable printing them.

[StefanKarpinski]

These warnings are getting so rampant, I'm almost tempted to turn them into errors so people can't not fix them :-|

[staticfloat]

I think it's wrong to punish users for package managers not fixing deprecation warnings; if Julia _can_ compute something, she should. Stubborn languages are no fun to work with. The reason deprecation warnings exist is to notify the users that would modify the package sources, not to nag users who don't know what those deprecation warnings mean/how to fix them. For general IJulia work, I think it would be useful to have a method of ignoring 2nd-level deprecation warnings. (2nd-level meaning deprecation warnings that stem from code called from user code, not warnings that stem from the user code itself)

In general I agree that warnings should not be ignored, but the number of warnings that are spit out by Julia right now is prodigous. (Whether deprecation warnings from Gadfly, duplicate symbol warnings from Accelerate, or something that the user actually has control over)

[catawbasam]

Perhaps some more context will help. I've been building IJulia notebooks as a way to learn Julia but also to, I hope, illustrate the merits of Julia to my colleagues.

While I'm creating a notebook, the warnings are useful. For example, they often indicate that it is time to update installed packages.

However, when the time comes to publish and share those notebooks, large blocks or pink text become an annoying distraction, and it would be convenient to be able to suppress them from the command line.

In both the examples I posted, the warnings have been addressed. Both Winston and Gadfly are a credit to their developers. Nonetheless, in an ecosystem evolving as quickly as Julia's, packages with many dependencies will generate warnings from time to time.

[StefanKarpinski]

I wasn't really serious about making these warnings fatal, but it would be nice to get rid of them in common packages.

[StefanKarpinski]

It would be nice if there was some way to have library-level warnings visible only by clicking through in IJulia.

[stevengj]

A reasonable principle is that (by default) I should only see warnings from _my_ code (for some definition of "my").

For example, how about suppressing warnings from modules in packages that are checked out at master, not those under control of the metadata (I forget Stefan's terminology for this)?

That way the only people to see the warnings in the module will be developers of the package or people who knowingly use bleeding-edge versions.

[StefanKarpinski]

For example, how about suppressing warnings from modules in packages that are checked out at master, not those under control of the metadata (I forget Stefan's terminology for this)?

Don't you mean not checked out at master? If you're on a branch, then presumably you are developing and should see the warnings.

[stevengj]

I mean suppress them for any package for which Pkg.free is a no-op.

[StefanKarpinski]

Right, so suppress them for "free" packages. We're in agreement then.

[nalimilan]

I think there still needs to be a distinction between deprecation warnings, which should only be visible for the maintainers of the code, and general warnings, which indicate that something may have wrong and the user should know about it. This happens quite often when people use a package in a way that has not been very well tested, and a function gets an unexpected input (e.g. numerically close to singular matrix). Or are all these cases supposed to trigger plain errors? Sometimes you need to warn but still not fail to allow inspection of the result.

[malmaud]

Ultimately it would be nice if error, warn, etc. were integrated with a logging system (like Python's Logging package), and the user had control over the severity threshold and printing destination of their output.

[kmsquire]

There is a (non-integrated) Logging.jl. package (
https://github.com/kmsquire/Logging.jl).

Kevin

On Thu, Dec 12, 2013 at 9:36 AM, Jonathan Malmaud
[email protected]:

Ultimately it would be nice if error, warn, etc. were integrated with a
logging system (like Python's Logging package), and the user had control
over the severity threshold and printing destination of their output.

—
Reply to this email directly or view it on GitHubhttps://github.com/JuliaLang/julia/issues/4895#issuecomment-30443798
.

[WestleyArgentum]

Also check out Lumberjack.jl! I tried yesterday -as @malmaud suggested- to go re-implement error, warn, and info (so that they go through the logging system but also generate exceptions and behave as before) and I'm fairly happy with the results.

[malmaud]

Thanks, @kmsquire and @WestleyArgentum.

[wildart]

@malmaud Log4jl

[JeffBezanson]

subsumed by #6190

[SimonDanisch]

Not sure since when ambiguities are the only warnings you can get in Julia :P
I think this issue is alive: It's still not easy to present Julia nicely with e.g. Notebooks, since they might be swamped with warnings from packages that are not under your control ;)
Or am I missing some other feature?

[nalimilan]

You're likely seeing a different kind of warnings. Would need to see a concrete example to tell (and which Julia version?).

[SimonDanisch]

I'm talking about general warnings, like overwritten functions, or any package calling warn(...).
I guess I could just overwrite warn for that purpose, but is that what we want as the solution to this issue? ;)

[alanedelman]

I wish I could suppress warnings nearly every time I give a demo,
and almost every time I compute.

[KristofferC]

Can't you just redirect them now with the new logging functionality?

[SimonDanisch]

Is there new logging functionality? Would that also work on 0.5?

[KristofferC]

https://github.com/JuliaLang/julia/pull/16213

[SimonDanisch]

Nice. So we can label this as fixed on 0.6!

[tkelman]

this issue is about ambiguity warnings which were fixed in 0.5

[SimonDanisch]

haha, duh! Guess the discussion got me a bit side tracked... Also this is the first result you get when googling for suppressing warnings! ;)