kmsquire
Namespace clash with Debug.jl
There's a namespace clash with Debug.jl (there may already have been before):
julia> using Logging
julia> @Logging.configure(level=INFO)
Logger(root,INFO,TTY(open, 0 bytes waiting),root)
julia> using Debug
Warning: using Debug.@debug in module Main conflicts with an existing identifier.
There is also a clash with Base.info, although strangely it only occurs if you have used info prior to bringing in Logging
john@john-kubuntu1404:~$ julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "help()" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.1-pre+8 (2014-08-24 17:00 UTC)
_/ |\__'_|_|_|\__'_| | release-0.3/853644c (fork: 34 commits, 15 days)
|__/ | x86_64-linux-gnu
julia> info("print some info")
INFO: print some info
julia> using Logging
Warning: using Logging.info in module Main conflicts with an existing identifier.
julia> Logging.configure(level=DEBUG)
Logger(root,DEBUG,TTY(open, 0 bytes waiting),root)
julia> debug("print some info")
25-Aug 15:46:56:DEBUG:root:print some info
julia> info("print some info")
INFO: print some info
julia> warn("print some info")
25-Aug 15:47:04:WARNING:root:print some info
julia> err("print some info")
25-Aug 15:47:12:ERROR:root:print some info
julia> critical("print some info")
25-Aug 15:47:16:CRITICAL:root:print some info
julia> methods(info)
# 1 method for generic function "info":
info(msg::String...) at util.jl:207
Note that the info() call does not output the Logging format - it has used the Base version
julia> versioninfo()
Julia Version 0.3.1-pre+8
Commit 853644c (2014-08-24 17:00 UTC)
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
julia> Pkg.installed()
Dict{ASCIIString,VersionNumber} with 35 entries:
"REPLCompletions" => v"0.0.3"
"PDMats" => v"0.2.4"
"Distributions" => v"0.5.4"
"Datetime" => v"0.1.6"
"SortingAlgorithms" => v"0.0.1"
"FixedPointNumbers" => v"0.0.2"
"SHA" => v"0.0.2"
"ImmutableArrays" => v"0.0.6"
"PyCall" => v"0.4.8"
"Debug" => v"0.0.4"
"Color" => v"0.3.3"
"ZMQ" => v"0.1.13"
"ArrayViews" => v"0.4.6"
"Compose" => v"0.3.6"
"JSON" => v"0.3.7"
"DataArrays" => v"0.2.0"
"DataStructures" => v"0.3.1"
"Hexagons" => v"0.0.2"
"IJulia" => v"0.1.13"
"Iterators" => v"0.1.6"
"KernelDensity" => v"0.0.2"
"PyPlot" => v"1.3.0"
"Loess" => v"0.0.2"
"GZip" => v"0.2.13"
"StatsBase" => v"0.6.4"
"Gadfly" => v"0.3.6"
"BinDeps" => v"0.3.3"
"Distance" => v"0.4.0"
"DataFrames" => v"0.5.7"
"Logging" => v"0.0.4"
"Codecs" => v"0.1.2"
"Contour" => v"0.0.2"
"Reexport" => v"0.0.1"
"Nettle" => v"0.1.4"
"URIParser" => v"0.0.2"
Hi @kmsquire what's the best way of resolving the name clash with Base.info ?
I'll have to take a closer look when I get to a computer. When this was discussed on the mailing list ages ago, there was some question of whether or not this functionality belonged in Base. I'm wondering if basic logging functions shouldn't all be available there, with more advanced logging relegated to packages.
Cc: @StefanKarpinski
@aviks, @johngrogan, I finally pushed a fix for the clash with Base.info, and tagged a new version of Logging.
Because Logging.info is still always available, and because info only refers to Base.info if Base.info is called before using Logging, I'm curious how much a problem this really is?
At any rate, the current solution (dba0e9f) is to allow the user to explicitly ask that Base.info be overridden with @Logging.configure(override_info=true). See the README for details.
I would be open to hearing arguments to make overriding the default.
@debug is still a conflict. As with all packages, fully qualifying the names always works, so I'm inclined to close this, as it is generally expected with the way Julia qualifies names.
(I don't remember what I was thinking above when I said that both of these issues was fixable...)
Feedback welcome! Cheers!
That sounds like a series of gotcha's that users will have to be aware of. Particularly since any of these invocations can be in imported libraries, rather than in the user's own code. If you change the order in which you import stuff, you might loose all info logging...
I think overriding as the default will make things slightly easier. If you are using logging, then we effectively redirect all output through the logging system. Which seems reasonable. However, this is still problematic if you don't know anything about Logging.jl, and some library deep down your dependency chain uses it. But that is, I think, less of a problem than the previous paragraph.
Maybe we should just change the API, and just use Logging.log(level, message) ?
Maybe we should just change the API, and just use
Logging.log(level, message)?
That would work as well.
@aviks, would you be interested in taking over this package? The other thought I had was to see if there was interest in having it be part of the JuliaLang organization, but it might be good to settle this issue first. (Or it might be good to move it and get more feedback...)
Thanks for the update.
... As with all packages, fully qualifying the names always works, so I'm inclined to close this, as it is generally expected with the way Julia qualifies names.
I agree with this - I typically would use the fully qualified function / macro names now.
@aviks, would you be interested in taking over this package
If you give me write access to this repository, that might be good enough, unless you want to completely dissociate yourself from this.
Done! I don't mind either way--it's just that I've found minimal time to work on Julia recently, so I've been rather slow at getting to issues.
BTW, if you have time, feel free to change the override behavior above to be the default. Regarding Logging.log: that would be fine too, with the caveat that log means something different in Base. I don't think people would get confused, though.