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
>
>
