To be fair, the message would be much better if it read "TypeError: T: in
type definition, expected Type{T}, got Function 'bool'
(etc)
while loading ".I don't think this requires a better line number, just a little more info. On Friday, October 9, 2015, Tomas Lycken <[email protected]> wrote: > > 1. > > This is a known problem, which is being actively worked on (but due to > Julia’s very powerful metaprogramming capabilities, it is far from easy to > solve). Search the github issues for keywords such as “stacktrace” > “backtrace” “line numbers” etc to find out more. > 2. > > I usually call workspace() before re-importing the module, which > removes that kind of warning. (Sometimes I get ambiguity warnings instead, > but not always - not sure why or what could be done about it. But it’s > worth testing in your use case.) > 3. > > This is because there is an exported function bool from Base, so > there’s not much that can be done here without special-casing this specific > typo. Both the methods of bool are deprecated, so they will eventually > be removed and that typo will result in the same error message as for > other, similar, typos: > > julia> immutable T end > > julia> immutable Y > foo::t > end > ERROR: UndefVarError: t not defined > > This I think is just what you expected to see for the bool case as well. > > // T > > On Friday, October 9, 2015 at 6:57:21 AM UTC+2, vav…@uwaterloo.ca wrote: > > I have three suggestions concerning improving error- and warning-reporting >> in 0.4.0-rc4: >> >> (1) First, there appears to be an actual bug with error system. My >> program is giving BoundsError for an array subscript out of range, but the >> line number of the source statement in the error message is wrong. Even >> worse, the error message is plausible because the reported line number >> indeed has an array subscript operation. My program is too long (nested >> 'includes', lots of packages) to helpfully post as a Julia issue, but I'm >> wondering if there is some home-grown debugging using code_llvm, etc., that >> I could carry out myself in order to report this issue in a more helpful >> way. >> >> The other two items are not bugs but suggestions. >> >> (2) Consider the module: >> >> module testwarning >> import Base.* >> *(a::Tuple{Float64,Float64},s::Float64) = (a[1]*s,a[2]*s) >> println((6.4,5.4)*3.2) >> end >> >> The first time I load this module, no problem. But every time I reload, >> I get a warning about redefining *. In my actual application program, I >> get screenfuls of similar warnings. My understanding is that the >> software-development loop involves loading a module, executing a function, >> finding bugs, and then reloading the module. So the repeated and lengthy >> warnings about redefining Base operators are unhelpful in this context. >> >> (3) Consider the following code: >> >> immutable T >> t1::Int >> t2::Int >> t3::Int >> t4::bool >> t5::Int >> end >> >> Notice the programmer's error: bool instead of Bool, a quite likely error >> for a former C++ programmer. Here is the message from Julia: >> >> ERROR: LoadError: TypeError: T: in type definition, expected Type{T}, got >> Function >> (etc) >> while loading c:\Users\vavasis\Documents\Projects\julia\testerror1.jl, in >> expression starting on line 3 >> >> The line number is misleading (it is number of the "immutable T") and the >> error message itself does not mention bool. So this particular error >> message could be improved. >> >> -- Steve Vavasis >> >> >
